การควบคุมที่อยู่ของข้อมูลตาม GDPR ต้องมีหลักฐาน ไม่ใช่คำสัญญา
เรียนรู้ว่าการควบคุมที่อยู่ของข้อมูลตาม GDPR แบบใดพิสูจน์ได้ว่าข้อมูลแอป AI ข้อมูลสำรอง การเข้าถึงเพื่อสนับสนุน และผู้ประมวลผลช่วงต่อดำเนินงานอยู่ที่ใดจริง

ตัวเลือกภูมิภาค EU มีประโยชน์ แต่ไม่ได้พิสูจน์ว่าข้อมูลส่วนบุคคลอยู่ในภูมิภาคนั้นเสมอไป ผู้ซื้อต้องติดตามสำเนาทุกชุดและทุกคนที่เข้าถึงได้ ทั้งฐานข้อมูลที่ใช้งานจริง ที่เก็บออบเจ็กต์ บันทึก การสำรองข้อมูล คำขอไปยังผู้ให้บริการโมเดล เทเลเมทรี และเซสชันสนับสนุน หากมีเส้นทางใดออกนอกขอบเขตที่สัญญาไว้ การอ้างเรื่องที่อยู่ของข้อมูลต้องมีกลไกการโอนและหลักฐานรองรับ
เพราะเหตุนี้ การควบคุมที่อยู่ของข้อมูลตาม GDPR ควรถูกประเมินเป็นห่วงโซ่ของข้อเท็จจริงที่บังคับใช้ได้ ภาพหน้าจอคอนโซลแสดงเพียงการตั้งค่า ไม่ได้บอกว่าการตั้งค่านั้นครอบคลุมอะไร ผู้ดูแลระบบเปลี่ยนได้หรือไม่ หรือเกิดอะไรขึ้นระหว่างเหตุการณ์ผิดปกติ ฝ่ายจัดซื้อควรขอคำมั่นในสัญญา คำอธิบายระบบ และการทดสอบที่ทำซ้ำได้สำหรับทุกข้ออ้างสำคัญ
บทความนี้เสนอเกณฑ์ใช้งานจริงสำหรับผู้ซื้อที่ประเมินผู้สร้างแอป AI ไม่ใช่คำแนะนำจากที่ปรึกษากฎหมายสำหรับการโอน เขตอำนาจศาล หรือระดับความเสี่ยงเฉพาะกรณี
การตรึงภูมิภาคต้องนิยามข้อมูลทุกประเภท
การตรึงภูมิภาคน่าเชื่อถือก็ต่อเมื่อผู้ให้บริการนิยามทั้งขอบเขตทางภูมิศาสตร์และข้อมูลที่อยู่ภายใต้ขอบเขตนั้น คำว่า «โฮสต์ใน EU» อาจหมายถึงฐานข้อมูลหลักอยู่แฟรงก์เฟิร์ต ขณะที่พรอมต์ไปยังปลายทางโมเดลที่อื่น บันทึกส่งไปยังบริการวิเคราะห์ทั่วโลก และข้อมูลสำรองทำซ้ำข้ามภูมิภาค ป้ายกำกับไม่ได้บอกอะไรนักจนกว่าผู้ให้บริการจะทำแผนผังการไหลของข้อมูล
ขอตารางตำแหน่งข้อมูลที่ระบุประเทศ หรือชุดประเทศที่อนุญาตสำหรับข้อมูลแต่ละประเภท อย่างน้อยควรครอบคลุมระเบียนแอปพลิเคชัน ไฟล์ที่อัปโหลด พรอมต์และคำตอบโมเดล เอ็มเบดดิง ข้อมูลลับ ข้อมูลยืนยันตัวตน บันทึก เมตริก เทรซ รายงานการขัดข้อง ไฟล์แนบสำหรับสนับสนุน และข้อมูลสำรอง ควรระบุด้วยว่า «EU» หมายถึงสหภาพยุโรป EEA ที่กว้างกว่า หรือกลุ่มที่ผู้ให้บริการนิยามเองซึ่งรวมประเทศอื่นด้วย
การควบคุมต้องมีขอบเขตที่ชัดเจน ภูมิภาคที่เลือกใช้กับพื้นที่ทำงานสำหรับสร้างแอป สภาพแวดล้อมจริงของแอปที่สร้างขึ้น หรือทั้งสองอย่างหรือไม่ ครอบคลุมสภาพแวดล้อมพรีวิว การปรับใช้ของแต่ละสาขา ผู้ปฏิบัติงานสร้างชั่วคราว คิว แคช ดัชนีค้นหา แคชของเครือข่ายส่งเนื้อหา และสำเนาสำหรับกู้คืนจากภัยพิบัติหรือไม่ ผู้สร้างแอปอาจเก็บฐานข้อมูลที่เสร็จแล้วไว้ในภูมิภาคหนึ่ง แต่ประมวลผลซอร์สโค้ด พรอมต์ และผลลัพธ์การสร้างที่อื่น
กำหนดให้ผู้ให้บริการระบุข้อยกเว้นเป็นลายลักษณ์อักษร ข้อยกเว้นที่แคบอาจจัดการได้ หากผู้ซื้อเข้าใจข้อมูล วัตถุประสงค์ ปลายทาง ระยะเวลาเก็บรักษา และมาตรการคุ้มครอง ข้อความที่ไม่กำหนดว่า «ข้อมูลการดำเนินงานอาจถูกประมวลผลทั่วโลก» ทำลายเป้าหมายของการควบคุม เพราะข้อมูลดังกล่าวมักมีตัวระบุผู้ใช้ เส้นทางคำขอ ส่วนหนึ่งของพรอมต์ และเพย์โหลดข้อผิดพลาด
หลักฐานที่ดีที่สุดรวมสามชั้น สัญญาหรือแบบฟอร์มสั่งซื้อระบุภูมิภาคที่ผูกพันและกระบวนการเปลี่ยนแปลง เอกสารสถาปัตยกรรมทำแผนที่ข้อมูลแต่ละประเภทไปยังบริการและตำแหน่ง บันทึกทางเทคนิค เช่น คำตอบ API หรือระเบียนการปรับใช้ พิสูจน์การตั้งค่าสำหรับผู้เช่าของผู้ซื้อเอง
ตัวอย่างเช่น ขอให้ผู้ให้บริการสร้างระเบียนผู้เช่าที่มีรูปแบบคงที่ดังนี้
{
"tenant_id": "acme-eu",
"workspace_region": "eu-central",
"runtime_region": "eu-central",
"backup_regions": ["eu-central", "eu-west"],
"support_access_policy": "eea_only",
"effective_at": "2026-07-01T00:00:00Z"
}
ชื่อฟิลด์อาจต่างกันไปตามผลิตภัณฑ์ สิ่งที่มีประโยชน์คือระเบียนแยกพื้นที่ทำงาน รันไทม์ ข้อมูลสำรอง และนโยบายการสนับสนุน แทนการรวมไว้ใต้ป้าย «EU» สีเขียวอันเดียว ถามว่าใครเปลี่ยนค่าเหล่านี้ได้ ผู้ซื้อตรวจพบการเปลี่ยนแปลงได้หรือไม่ และเกิดอะไรกับสำเนาที่มีอยู่หลังย้าย
ข้อมูลสำรองต้องมีคำมั่นเรื่องที่อยู่ของตัวเอง
ข้อมูลสำรองต้องอยู่ภายใต้นโยบายตำแหน่ง การเก็บรักษา การลบ และการกู้คืนที่ระบุชัด ข้อมูลเหล่านี้เป็นสำเนาแยกต่างหาก มีโครงสร้างพื้นฐาน เส้นทางเข้าถึง และอายุการใช้งานของตัวเอง ผู้ให้บริการที่รับปากเพียงตำแหน่ง «ข้อมูลลูกค้าขณะจัดเก็บ» อาจไม่ได้ผูกพันคลังสำรอง สแนปช็อต หรือสำเนาสำหรับกู้คืนจากภัยพิบัติไว้กับขอบเขตเดียวกัน
ถามว่าข้อมูลสำรองทุกชุดถูกเก็บที่ใด รวมถึงสแนปช็อตฐานข้อมูล เวอร์ชันออบเจ็กต์ โวลุ่มที่ทำซ้ำ ข้อมูลสำรองการตั้งค่า และสำเนากู้คืนที่ผู้ให้บริการโครงสร้างพื้นฐานจัดการ ขอให้ระบุว่าการทำซ้ำอยู่ในประเทศเดียว เคลื่อนย้ายระหว่างประเทศ EEA หรือข้ามไปยังประเทศที่สาม สถาปัตยกรรมเพื่อความพร้อมใช้งานอาจมีเหตุผลให้ใช้ภูมิภาคที่สอง แต่ไม่ได้ทำให้ตำแหน่งนั้นไม่มีความสำคัญ
คำตอบเรื่องการเก็บรักษาต้องมีตัวเลขและเหตุการณ์ ฝ่ายจัดซื้อควรได้รับระยะเวลามาตรฐานของข้อมูลสำรอง ชั้นเก็บถาวรที่นานกว่า ระยะเวลาจนสื่อที่หมดอายุไม่สามารถกู้คืนได้ และวิธีจัดการข้อมูลสำรองหลังสิ้นสุดสัญญา คำว่า «ลบตามนโยบาย» ทดสอบไม่ได้ ตารางที่ระบุว่าจุดกู้คืนรายวันหมดอายุหลังระยะเวลาที่กำหนด และข้อมูลสำรองของผู้เช่าที่สิ้นสุดสัญญาเข้าถึงไม่ได้แล้วค่อยหมดอายุตามกำหนด ทดสอบได้
การลบเชิงตรรกะกับการหมดอายุทางกายภาพไม่เหมือนกัน ระเบียนที่ลบแล้วอาจยังอยู่ในข้อมูลสำรองที่เข้ารหัสจนกว่าจุดกู้คืนนั้นหมดอายุ ซึ่งอาจสอดคล้องกับรูปแบบการเก็บรักษาที่บันทึกไว้ แต่ผู้ให้บริการควรอธิบายวิธีป้องกันไม่ให้การกู้คืนตามปกติเปิดใช้งานข้อมูลที่ลบแล้วกลับมาโดยไม่ตั้งใจ กระบวนการกู้คืนที่รัดกุมจะนำเครื่องหมายการลบกลับมาใช้ หรือกำหนดให้กระทบยอดหลังการกู้คืนก่อนคืนระบบสู่การใช้งาน
ขอหลักฐานการทดสอบกู้คืนล่าสุดหนึ่งรายการ โดยตัดรายละเอียดอ่อนไหวออก ควรระบุภูมิภาคต้นทางของข้อมูลสำรอง ปลายทางที่กู้คืน บุคคลหรือบทบาทบริการที่เกี่ยวข้อง ระเบียนการอนุมัติ และการกำจัดสำเนาที่กู้คืนแล้ว นโยบายกู้คืนจากภัยพิบัติแบบทั่วไปพิสูจน์แค่ว่ามีคนเขียนนโยบาย ระเบียนการกู้คืนพิสูจน์ว่ากระบวนการปฏิบัติรู้ว่าสำเนาไปอยู่ที่ใด
การเข้ารหัสไม่ได้ลบคำถามเรื่องตำแหน่งออกไป ช่วยลดความเสี่ยงได้ โดยเฉพาะเมื่อแยกกุญแจและบทบาทผู้ดูแล แต่ข้อมูลสำรองในประเทศที่สามยังอาจเป็นการโอนที่ต้องใช้กลไกและการประเมินที่ถูกต้อง ฝ่ายจัดซื้อควรบันทึกว่าใครเป็นเจ้าของกุญแจ กุญแจอยู่ที่ใด ใครอนุญาตการกู้คืน และบุคลากรผู้ให้บริการเข้าถึงข้อมูลที่ถอดรหัสแล้วระหว่างกู้คืนได้หรือไม่
รายชื่อผู้ประมวลผลช่วงต่อต้องอธิบายห่วงโซ่จริง
ทะเบียนผู้ประมวลผลช่วงต่อที่มีประโยชน์เชื่อมแต่ละบริษัทเข้ากับวัตถุประสงค์ ประเภทข้อมูล ตำแหน่งประมวลผล และฐานทางกฎหมายในการโอน รายชื่อโลโก้หรือชื่อนิติบุคคลเป็นเพียงรายการทรัพย์สิน ไม่ได้อธิบายว่าข้อมูลของผู้ซื้อเคลื่อนย้ายอย่างไร ผู้สร้างแอป AI มักพึ่งพาคลาวด์โฮสติ้ง ผู้ให้บริการโมเดล บริการสังเกตการณ์ระบบ การส่งอีเมล การยืนยันตัวตน การสนับสนุนลูกค้า และการตรวจจับการใช้งานในทางที่ผิด แต่ละบทบาทอาจเห็นข้อมูลคนละส่วน
GDPR มาตรา 28 กำหนดให้ผู้ประมวลผลต้องได้รับอนุญาตเป็นลายลักษณ์อักษรแบบเฉพาะเจาะจงหรือแบบทั่วไปล่วงหน้า ก่อนแต่งตั้งผู้ประมวลผลรายอื่น หากเป็นการอนุญาตแบบทั่วไป ผู้ประมวลผลต้องแจ้งผู้ควบคุมข้อมูลถึงการเพิ่มหรือเปลี่ยนผู้ประมวลผลที่ตั้งใจทำ เพื่อให้ผู้ควบคุมคัดค้านได้ ฝ่ายจัดซื้อควรเปลี่ยนกฎนี้เป็นข้อกำหนดในการดำเนินงาน ได้แก่ ทะเบียนที่คงที่ การแจ้งล่วงหน้าผ่านช่องทางที่ผู้ซื้อติดตาม ระยะเวลาแจ้งที่กำหนด และขั้นตอนคัดค้านที่ระบุไว้
ทะเบียนควรตอบห้าประเด็นสำหรับผู้ประมวลผลช่วงต่อทุกราย
- นิติบุคคลที่ได้รับหรือเข้าถึงข้อมูลได้
- บริการและวัตถุประสงค์การประมวลผลที่เจาะจง
- ประเภทข้อมูลส่วนบุคคลและฟีเจอร์ผลิตภัณฑ์ที่ได้รับผลกระทบ
- ประเทศที่จัดเก็บและเข้าถึงจากระยะไกล
- กลไกการโอนที่ใช้และเส้นทางผู้ประมวลผลช่วงต่อลำดับถัดไป
อย่ายอมรับคำว่า «โครงสร้างพื้นฐานคลาวด์» เป็นตำแหน่งของบริการโมเดล ถามว่าพรอมต์ถูกส่งไปยังผู้ให้บริการโมเดลหรือไม่ ผู้ให้บริการเก็บไว้หรือไม่ มนุษย์ตรวจทานได้หรือไม่ และผู้ซื้อปิดผู้ให้บริการหรือเลือกปลายทางได้หรือไม่ หากผู้สร้างใช้โมเดลผสมกัน ตรรกะการกำหนดเส้นทางสำคัญมาก ภูมิภาคโครงการที่เลือกควบคุมคำขอไม่ได้ หากชั้นกำหนดเส้นทางส่งคำขอไปยังปลายทางที่ไม่ได้อนุมัติ
การแจ้งการเปลี่ยนแปลงต้องมาก่อนการเปลี่ยนมีผล หน้าเว็บที่เปลี่ยนได้โดยไม่แจ้ง ทำให้ฝ่ายจัดซื้อต้องเฝ้าตรวจสอบด้วยมืออย่างต่อเนื่อง ภาษาสัญญาควรระบุว่าการแจ้งมีข้อมูลอะไร และจะเกิดอะไรหลังมีการคัดค้านที่มีเหตุผล ผู้ให้บริการไม่จำเป็นต้องรับปากว่าห่วงโซ่อุปทานจะไม่เปลี่ยนเลย แต่ผู้ซื้อต้องมีเวลาประเมินการโอนใหม่ก่อนที่ข้อมูลจะเริ่มไหล
ระหว่างการตรวจสอบ ขอให้ผู้ให้บริการกระทบยอดสามสิ่ง ได้แก่ ทะเบียนสาธารณะ ภาคผนวก DPA และแผนผังสถาปัตยกรรมหรือการไหลของข้อมูลฉบับปัจจุบัน ชื่อและตำแหน่งมักคลาดเคลื่อนระหว่างเอกสารหลังย้ายผู้ให้บริการ ความไม่ตรงกันไม่ได้แปลว่าการควบคุมล้มเหลวโดยอัตโนมัติ แต่หมายความว่าผู้ซื้อยังไม่มีระเบียนที่เชื่อถือได้จนกว่าผู้ให้บริการจะแก้ไข
DPA ควรเปลี่ยนการตั้งค่าให้เป็นหน้าที่ตามสัญญา
ข้อตกลงการประมวลผลข้อมูลควรระบุคำสั่งประมวลผล หน้าที่ด้านความปลอดภัย เงื่อนไขการลบ สิทธิในการตรวจสอบ และการควบคุมผู้ประมวลผลช่วงต่อสำหรับบริการที่ซื้อ เอกสารผลิตภัณฑ์อาจอธิบายฟีเจอร์ แต่ DPA และเอกสารสั่งซื้อเป็นตัวกำหนดว่าผู้ให้บริการรับปากอะไรกับผู้ซื้อรายนี้
GDPR มาตรา 28(3) ระบุองค์ประกอบที่สัญญาระหว่างผู้ควบคุมข้อมูลและผู้ประมวลผลต้องครอบคลุม รวมถึงเรื่องและระยะเวลา ลักษณะและวัตถุประสงค์ ประเภทข้อมูลส่วนบุคคล ประเภทเจ้าของข้อมูล การรักษาความลับ ความช่วยเหลือด้านความปลอดภัย การลบหรือส่งคืน และข้อมูลที่จำเป็นเพื่อแสดงการปฏิบัติตามแนวทาง Guidelines 07/2020 ของ European Data Protection Board เตือนอย่างมีประโยชน์ว่า ข้อตกลงประมวลผลไม่ควรแค่กล่าวซ้ำ GDPR แต่ควรมีข้อมูลเฉพาะว่าทำตามข้อกำหนดอย่างไร และต้องการระดับความปลอดภัยเพียงใด
ความเฉพาะเจาะจงนี้สำคัญต่อเรื่องที่อยู่ของข้อมูล แนบตารางที่ระบุภูมิภาคที่ผู้ซื้อเลือก สภาพแวดล้อมที่ครอบคลุม ประเทศที่อนุมัติให้เข้าถึงจากระยะไกล ตำแหน่งสำรองข้อมูล และผู้ประมวลผลช่วงต่อที่อนุมัติ ระบุว่าผู้ให้บริการไม่อาจขยายตำแหน่งเหล่านี้อย่างมีนัยสำคัญโดยไม่มีการแจ้งหรือขั้นตอนเปลี่ยนแปลงที่ตกลงกัน หากเอกสารการขายบอกว่า «EU เท่านั้น» แต่ DPA อนุญาตให้ประมวลผลได้ทุกที่ที่ผู้ให้บริการหรือบริษัทในเครือดำเนินงาน สัญญามีผลเหนือกว่าเมื่อทั้งสองขัดกัน
ทบทวนการแบ่งบทบาทด้วย สำหรับเนื้อหาลูกค้าที่ใช้เพื่อให้บริการตามคำสั่งของผู้ซื้อ בלבד ผู้ให้บริการมักทำหน้าที่ผู้ประมวลผล ผู้ให้บริการอาจอ้างบทบาทผู้ควบคุมข้อมูลแยกต่างหากสำหรับการเรียกเก็บเงิน ความปลอดภัยบัญชี การป้องกันการทุจริต หรือหน้าที่กฎหมายของตนเอง อย่าปฏิเสธวัตถุประสงค์แยกทุกข้อทันที ให้ผู้ให้บริการระบุวัตถุประสงค์ ประเภทข้อมูล ฐานกฎหมาย การเก็บรักษา และการแบ่งปัน แทนการซ่อนไว้ในสิทธิที่กว้างเกินไปในการใช้ข้อมูลบริการทั้งหมด
การฝึก AI ต้องมีข้อกำหนดที่ชัดเจน ถามว่าผู้ให้บริการหรือผู้ให้บริการโมเดลใช้พรอมต์ ข้อมูลแอปพลิเคชัน ซอร์สโค้ด หรือผลลัพธ์เพื่อฝึกหรือปรับปรุงโมเดลทั่วไปหรือไม่ หากคำตอบคือไม่ ให้บันทึกข้อจำกัดนี้ไว้ใน DPA หรือเงื่อนไขผลิตภัณฑ์ที่มีผลบังคับ และให้ครอบคลุมผู้ประมวลผลช่วงต่อด้วย หากคำตอบขึ้นกับการตั้งค่า ให้บันทึกค่าเริ่มต้น ผู้ดูแล ขอบเขต และร่องรอยการตรวจสอบ
ภาษาการตรวจสอบควรให้หลักฐานใช้งานได้ โดยไม่ต้องเรียกร้องสิทธิ์เข้าถึงสถานที่แบบผู้เช่าหลายรายอย่างไร้ข้อจำกัด รายงานการรับรองอิสระ สรุปการทดสอบเจาะระบบ เอกสารความปลอดภัย และคำตอบเป็นลายลักษณ์อักษรแบบเจาะจงอาจเพียงพอสำหรับการทบทวนตามปกติ ผู้ซื้อควรยังมีช่องทางขอข้อมูลเพิ่มหรือการตรวจสอบตามสัดส่วน เมื่อเอกสารเหล่านั้นไม่คลี่คลายข้อกังวลสำคัญ หรือเหตุการณ์ทำให้ต้องสงสัยว่าการควบคุมทำงานจริงหรือไม่
SCC แก้ได้เพียงส่วนตามสัญญาของการโอน
Standard Contractual Clauses อาจเป็นเครื่องมือการโอนตามมาตรา 46 แต่การลงนามไม่ได้พิสูจน์ว่าการโอนทุกครั้งชอบด้วยกฎหมายหรือได้รับการคุ้มครองเพียงพอ ผู้ซื้อต้องเลือกโมดูลที่ถูกต้อง กรอกภาคผนวก ทำแผนที่การโอนต่อ และประเมินว่าข้อสัญญาใช้ได้จริงกับปลายทางและข้อมูลนั้นหรือไม่
SCC ปี 2021 ของคณะกรรมาธิการยุโรปใช้สี่โมดูลตามบทบาทของคู่สัญญา ลูกค้าใน EEA ที่ส่งข้อมูลให้ผู้ประมวลผลนอก EEA มักใช้โมดูล 2 ผู้ประมวลผลที่ส่งข้อมูลให้ผู้ประมวลผลช่วงต่อในประเทศที่สามอาจต้องใช้โมดูล 3 ทางเลือกที่ถูกต้องขึ้นกับว่าใครเป็นผู้ส่งออก ใครเป็นผู้นำเข้า และผู้นำเข้าอยู่ภายใต้ GDPR สำหรับการประมวลผลนั้นอยู่แล้วหรือไม่ ที่ปรึกษากฎหมายจึงควรยืนยันห่วงโซ่ แทนการวางโมดูล 2 ลงในทุกสัญญา
ภาคผนวกที่กรอกครบเป็นหลักฐาน ควรระบุคู่สัญญา เจ้าของข้อมูล ประเภทข้อมูล ข้อมูลอ่อนไหวและมาตรการคุ้มครอง ความถี่การโอน วัตถุประสงค์ การเก็บรักษา หน่วยงานกำกับดูแลที่มีอำนาจ มาตรการทางเทคนิคและองค์กร และผู้ประมวลผลช่วงต่อ ภาคผนวกว่างเปล่า คำอธิบายกว้าง ๆ เช่น «ข้อมูลลูกค้าทั้งหมด» หรือสัญญาว่าจะกรอกรายละเอียดภายหลัง ทำให้ข้อสัญญาหลุดจากบริการจริง
Recommendations 01/2020 ของ EDPB เสนอแนวทางหกขั้นตอน ได้แก่ รู้จักการโอน ระบุเครื่องมือการโอน ประเมินกฎหมายหรือแนวปฏิบัติของประเทศที่สาม ใช้มาตรการเพิ่มเติมเมื่อจำเป็น ดำเนินขั้นตอนทางการให้ครบ และประเมินซ้ำตามช่วงที่เหมาะสม คำแนะนำนี้ยังถือว่าการเข้าถึงจากระยะไกลในประเทศที่สามเป็นการโอนด้วย จุดนี้ผู้ซื้อมักพลาดเมื่อมุ่งดูแผนที่จัดเก็บข้อมูล
การประเมินผลกระทบจากการโอนควรตรงกับบริการ แทนที่จะเป็นบันทึกกฎหมายทั่วไป ควรระบุผู้นำเข้าและปลายทาง ข้อมูลและบุคคลที่ได้รับผลกระทบ เส้นทางเข้าถึง กฎหมายและแนวปฏิบัติที่ใช้ ความเสี่ยงจากการเข้าถึงของรัฐ การโอนต่อ และมาตรการเพิ่มเติม บันทึกว่าใครอนุมัติการประเมิน และการเปลี่ยนแปลงใดจะทำให้ต้องทบทวนใหม่
การเข้ารหัสช่วยได้ก็ต่อเมื่อออกแบบมาเพื่อรับมือความเสี่ยงด้านการเข้าถึง หากบริการต้องถอดรหัสพรอมต์ให้เจ้าหน้าที่สนับสนุนหรือปลายทางโมเดลในประเทศปลายทาง การเข้ารหัสระหว่างส่งไม่ได้ป้องกันผู้รับนั้นจากการอ่านข้อมูล มาตรการเพิ่มเติมที่มีประโยชน์อาจเป็นการแยกสิทธิ์เข้าถึงอย่างเคร่งครัด การใช้นามแฝงเมื่อผู้รับไม่มีข้อมูลระบุตัวตนกลับได้ กุญแจที่ลูกค้าควบคุมสำหรับเวิร์กโหลดที่ทำให้ผู้ให้บริการมองไม่เห็นข้อมูลได้ บันทึกการเข้าถึง และหน้าที่ตามสัญญาในการโต้แย้งหรือแจ้งเมื่อกฎหมายอนุญาต
การตัดสินเรื่องความเพียงพออาจเปลี่ยนเส้นทางกฎหมายของปลายทาง แต่ไม่ได้ลบความจำเป็นต้องรู้ปลายทางหรือควบคุมผู้ประมวลผล ฝ่ายจัดซื้อควรถามผู้ให้บริการว่าการโอนใดอาศัยคำตัดสินเรื่องความเพียงพอ และการโอนใดอาศัย SCC หรือกลไกอื่น คำตอบควรอยู่ในบัญชีการโอน ไม่ใช่ในประโยคกว้าง ๆ ที่บอกว่าผู้ให้บริการ «ปฏิบัติตาม GDPR»
การเข้าถึงเพื่อสนับสนุนเป็นการประมวลผลในที่ที่ผู้ปฏิบัติงานอยู่
การเข้าถึงเพื่อสนับสนุนจากระยะไกลนอก EEA เป็นการโอนข้อมูล เมื่อผู้ปฏิบัติงานดูข้อมูลส่วนบุคคลได้ แม้ฐานข้อมูลจะไม่เคยออกจากภูมิภาค EU ให้ถือว่าตำแหน่งฝ่ายสนับสนุน การอนุญาต และหลักฐานเซสชันเป็นการควบคุมที่อยู่ของข้อมูล ตำแหน่งจัดเก็บและตำแหน่งเข้าถึงโดยมนุษย์ตอบคำถามคนละข้อ
ขอให้ผู้ให้บริการแยกการสนับสนุนตามปกติออกจากสิทธิ์วิศวกรรมระดับสูง เจ้าหน้าที่ด่านแรกอาจต้องใช้เมทาดาทาบัญชี แต่ไม่จำเป็นต้องเห็นเนื้อหาในระบบจริง วิศวกรเวรอาจต้องใช้สิทธิ์ชั่วคราวระหว่างเหตุการณ์รุนแรง การควบคุมควรให้แต่ละบทบาทเห็นข้อมูลน้อยที่สุดและใช้เวลาสั้นที่สุด พร้อมการอนุมัติที่เข้มงวดขึ้นสำหรับการเข้าถึงระบบจริง
ฝ่ายจัดซื้อควรขอตำแหน่งเข้าถึงที่ระบุชื่อ หรือนโยบายภูมิภาคที่บังคับใช้ได้ ไม่ใช่ «ฝ่ายสนับสนุนทั่วโลกตามเขตเวลา» ที่ไม่มีรายชื่อประเทศ ผู้ให้บริการควรเปิดเผยพนักงาน บริษัทในเครือ และผู้รับจ้างที่เข้าถึงระบบจริงได้ ประเทศที่พวกเขาทำงาน และกลไกการโอนสำหรับทุกเส้นทางนอก EEA หากสิทธิ์ฉุกเฉินลบล้างข้อจำกัดด้านตำแหน่งได้ ให้บันทึกเงื่อนไข ผู้อนุมัติ ระยะเวลา และการแจ้งผู้ซื้อ
ทำการทดสอบการเข้าถึงเพื่อสนับสนุนก่อนอนุมัติ หรือระหว่างการพิสูจน์แนวคิด
- สร้างผู้เช่าทดสอบในภูมิภาค EU ตามสัญญา และเพิ่มระเบียนลูกค้าสังเคราะห์ที่มีลักษณะเฉพาะ
- เปิดเคสสนับสนุนที่ตามปกติจะต้องตรวจสอบ แต่ห้ามวางระเบียนนั้นลงในทิกเก็ต
- ขอให้ผู้ให้บริการแสดงคำขอเข้าถึง ผู้อนุมัติ ประเทศของผู้ปฏิบัติงาน บทบาทที่ได้รับ และเวลาหมดอายุ
- ยืนยันว่าบันทึกเซสชันเก็บผู้เช่า การกระทำ เวลาประทับ และเหตุผล โดยไม่คัดลอกเนื้อหาอ่อนไหวลงในบันทึก
- เพิกถอนสิทธิ์ แล้วขอหลักฐานว่าบทบาทหรือเซสชันเข้าถึงผู้เช่านั้นไม่ได้อีก
ใช้ข้อมูลสังเคราะห์ เพราะการทดสอบเพื่อตรวจสอบก่อนตัดสินใจไม่ควรสร้างการเปิดเผยข้อมูลใหม่ ผลลัพธ์ที่คาดหวังคือชุดหลักฐานขนาดเล็ก ได้แก่ รหัสทิกเก็ต เหตุการณ์อนุมัติ สิทธิ์ชั่วคราว รายการตรวจสอบเซสชัน และเหตุการณ์เพิกถอน หากผู้ให้บริการทดสอบสดในบริการที่ใช้ร่วมกันไม่ได้ ให้ขอตัวอย่างล่าสุดที่ปกปิดข้อมูลแล้ว พร้อมการอธิบายที่ผูกกับการควบคุมที่บันทึกไว้
สิทธิ์ฉุกเฉินต้องได้รับการตรวจสอบอย่างเข้มงวดเช่นกัน อาจข้ามการอนุมัติตามปกติเพื่อกู้บริการ แต่ไม่ควรข้ามการยืนยันตัวตน การบันทึก เวลาให้สิทธิ์หมดอายุ และการทบทวนย้อนหลัง ถามว่าผู้ให้บริการป้องกันไม่ให้พนักงานใช้บทบาทฉุกเฉินเพื่อแก้บั๊กทั่วไปอย่างไร และผู้ซื้อจะทราบได้อย่างไรว่าเคยมีการเข้าถึงดังกล่าว
อย่าเรียกร้องการบันทึกหน้าจอเป็นค่าเริ่มต้น การบันทึกอาจสร้างสำเนาข้อมูลส่วนบุคคลและข้อมูลรับรองที่ละเอียดอีกชุด เหตุการณ์ตรวจสอบแบบมีโครงสร้างมักให้หลักฐานดีกว่าและเปิดเผยน้อยกว่า ได้แก่ ใครเข้าถึงผู้เช่ารายใด จากประเทศใด ภายใต้ทิกเก็ตใด ใช้บทบาทใด นานเท่าใด และทำการกระทำประเภทใด
หลักฐานต้องอยู่รอดเมื่อมีการเปลี่ยนแปลงและเหตุการณ์
ฝ่ายจัดซื้อควรรวบรวมหลักฐานพร้อมเจ้าของ วันที่ ขอบเขต และเหตุให้ต้องอัปเดต คำตอบที่ดูดีระหว่างการทบทวนฝ่ายขายจะล้าสมัยเมื่อผู้ให้บริการเพิ่มผู้ให้บริการโมเดล ย้ายทีมสนับสนุน เปลี่ยนรูปแบบสำรองข้อมูล หรือเปิดภูมิภาคใหม่ การจัดการหลักฐานเป็นส่วนหนึ่งของการควบคุม ไม่ใช่งานจัดแฟ้มหลังตัดสินใจ
ใช้ตารางเชื่อมการควบคุมกับหลักฐานในระเบียนอนุมัติ ให้แต่ละรายการมีสี่ช่อง ได้แก่ ข้ออ้างเรื่องการควบคุม หลักฐานตามสัญญา หลักฐานทางเทคนิค และเหตุให้ต้องอัปเดต
- สำหรับภูมิภาคพื้นที่ทำงานและรันไทม์ที่อนุมัติ เก็บแบบฟอร์มสั่งซื้อและตารางตำแหน่งไว้คู่กับระเบียนภูมิภาคผู้เช่าและแผนผังการไหลของข้อมูล อัปเดตหลังเปลี่ยนภูมิภาคหรือสถาปัตยกรรม
- สำหรับตำแหน่งสำรองข้อมูล จับคู่ตารางสำรองและการลบกับระเบียนทดสอบกู้คืน อัปเดตหลังเปลี่ยนผู้ให้บริการสำรองหรือการกู้คืนจากภัยพิบัติ
- สำหรับห่วงโซ่ผู้ประมวลผลช่วงต่อที่อนุมัติ จับคู่ข้อกำหนดการอนุญาตใน DPA กับทะเบียนที่กระทบยอดกับสถาปัตยกรรม ทบทวนหลังมีการแจ้งเพิ่มหรือเปลี่ยน
- สำหรับการโอนไปประเทศที่สาม จับคู่ SCC หรือเอกสารอ้างอิงความเพียงพอกับบัญชีการโอนและการประเมิน ทบทวนหลังเปลี่ยนปลายทาง กฎหมาย หรือการเข้าถึง
- สำหรับตำแหน่งฝ่ายสนับสนุน จับคู่ตารางการเข้าถึงเพื่อสนับสนุนกับบันทึกการอนุมัติ เซสชัน และการเพิกถอน อัปเดตหลังเปลี่ยนประเทศฝ่ายสนับสนุนหรือบทบาท
มอบหมายแต่ละแถวให้บุคคลจากทั้งสองฝ่าย เจ้าของฝั่งผู้ให้บริการตอบคำถามการเปลี่ยนแปลงและคำขอหลักฐาน เจ้าของฝั่งผู้ซื้อตัดสินว่าการแจ้งนั้นต้องให้ฝ่ายความเป็นส่วนตัว ความปลอดภัย วิศวกรรม หรือกฎหมายทบทวนหรือไม่ กล่องจดหมายรวมที่ไม่มีผู้ตรวจทานรับผิดชอบไม่ใช่การควบคุมที่ทำงานได้
กำหนดเกณฑ์การแจ้ง ผู้ประมวลผลช่วงต่อรายใหม่ที่ส่งเพียงอีเมลสถานะบริการอาจต้องทบทวนเบากว่าผู้ให้บริการโมเดลที่ได้รับพรอมต์ ประเทศสำรองข้อมูลใหม่ การขยายตำแหน่งฝ่ายสนับสนุน การเปลี่ยนการใช้เพื่อฝึกโมเดล หรือการลบล้างภูมิภาคตามสัญญา ควรหยุดการปรับใช้ข้อมูลอ่อนไหวใหม่จนกว่าผู้ซื้อจะประเมินเสร็จ
หลักฐานเหตุการณ์ควรแสดงว่าขอบเขตที่อยู่ของข้อมูลยังคงอยู่ กำหนดให้กระบวนการจัดการเหตุการณ์ของผู้ให้บริการเก็บรักษาการตั้งค่าภูมิภาคที่เกี่ยวข้อง การเปลี่ยนแปลงโดยผู้ดูแล การเข้าถึงเพื่อสนับสนุน เหตุการณ์ส่งออก และการมีส่วนร่วมของผู้ประมวลผลช่วงต่อ DPA ควรกำหนดหน้าที่แจ้งและเงื่อนไขความร่วมมือ ส่วนคู่มือเหตุการณ์ควรระบุระเบียนที่ตอบได้ว่าข้อมูลที่ได้รับผลกระทบถูกเก็บและถูกดูที่ใด
ใบรับรองช่วยสนับสนุนแฟ้มนี้ได้ แต่แทนคำตอบเฉพาะบริการไม่ได้ รายงานการรับรองอาจทดสอบการจัดการสิทธิ์เข้าถึงและการสำรองข้อมูล แต่ไม่กล่าวถึงภูมิภาคที่ผู้เช่ารายหนึ่งซื้ออย่างชัดเจน จับคู่ขอบเขตและข้อยกเว้นของรายงานกับแถวการควบคุม แล้วเติมช่องว่างที่เหลือด้วยหลักฐานในสัญญาหรือผู้เช่า
ข้อกำหนดควรให้คำตอบที่ทดสอบได้
เขียนข้อกำหนดเรื่องที่อยู่ของข้อมูลให้ผู้ให้บริการตอบได้ว่า ใช่ ไม่ใช่ หรือไม่เกี่ยวข้อง พร้อมแนบเอกสารที่ระบุชื่อ คำถามกว้างชวนให้ได้รับคำรับรองกว้าง ๆ คำถามว่า «อธิบายแนวทางของคุณต่อ GDPR» จะให้ข้อความสวยงามหลายหน้า แต่แทบไม่มีหลักฐานสำหรับอนุมัติ ข้อกำหนดที่ผูกข้อมูล ตำแหน่ง พฤติกรรม และหลักฐานเข้าด้วยกัน จะเผยช่องว่างได้รวดเร็ว
ข้อกำหนดที่ใช้งานได้สำหรับการโฮสต์อาจเขียนว่า «ผู้ให้บริการต้องจัดเก็บและประมวลผลเนื้อหาลูกค้าที่ใช้งานจริง พรอมต์ ซอร์สโค้ดที่สร้างขึ้น และระเบียนยืนยันตัวตน เฉพาะในประเทศที่ระบุในตาราง A เว้นแต่การโอนที่ระบุในตาราง B» ตารางสำคัญพอ ๆ กับประโยค ตาราง A นิยามขอบเขตที่อนุมัติ ตาราง B บังคับให้ทั้งสองฝ่ายระบุข้อยกเว้น แทนการพึ่งสิทธิ์ทั่วไปที่ซ่อนอยู่ที่อื่น
ใช้ข้อกำหนดแยกสำหรับการควบคุมแต่ละประเภท คำถามต่อไปนี้ใช้ได้ดีใน RFP หรือภาคผนวกความปลอดภัย
- ระบุองค์ประกอบบริการทุกส่วนที่ไม่รับช่วงภูมิภาคที่ผู้เช่าเลือก พร้อมข้อมูล ประเทศ วัตถุประสงค์ และการเก็บรักษา
- ระบุทุกประเทศที่บุคลากรเข้าถึงเนื้อหาในระบบจริงได้ และแนบมาตรฐานการอนุมัติกับการบันทึกสำหรับการเข้าถึงนั้น
- ระบุตำแหน่งสำรองและกู้คืนจากภัยพิบัติทุกแห่ง ระยะเวลาเก็บรักษา เหตุการณ์ลบ และปลายทางกู้คืนที่อนุญาต
- จัดทำทะเบียนผู้ประมวลผลช่วงต่อปัจจุบัน และทำเครื่องหมายว่านิติบุคคลใดรับพรอมต์ ซอร์สโค้ด ระเบียนแอปพลิเคชัน หรือไฟล์แนบสนับสนุนได้
- จับคู่การโอนสู่ประเทศที่สามทุกครั้งกับคำตัดสินเรื่องความเพียงพอ โมดูล SCC หรือกลไกอื่นที่ใช้อ้างอิง พร้อมชื่อเจ้าของการประเมินและวันที่ทบทวน
หลีกเลี่ยงถ้อยคำเด็ดขาดที่สถาปัตยกรรมทำได้ไม่สมเหตุสมผล เช่น «ไม่มีข้อมูลใดออกจากเยอรมนีเลย» อาจห้ามโดยไม่ตั้งใจไม่ให้ส่งอีเมลถึงผู้ดูแลของผู้ซื้อที่อยู่ต่างประเทศ หรือห้ามผู้ใช้ที่ได้รับอนุญาตอ่านแอปขณะเดินทาง ให้กำหนดว่าข้อกำหนดครอบคลุมการจัดเก็บและประมวลผลที่ผู้ให้บริการควบคุม การส่งผ่านเครือข่าย การเข้าถึงโดยผู้ใช้ของผู้ซื้อ หรือทั้งหมด ความแม่นยำทำให้การคุ้มครองเข้มแข็งขึ้น เพราะทุกคนระบุการละเมิดได้
แยกการควบคุมที่ต้องมีออกจากความต้องการก่อนออกแบบสอบถาม หากการเข้าถึงเพื่อสนับสนุนเฉพาะ EU เป็นข้อบังคับ ให้ระบุและปฏิเสธรูปแบบที่ขัดกัน หากเป็นเพียงความต้องการ ให้ประเมินเส้นทางผ่านประเทศที่สามที่มีเอกสาร พร้อมเครื่องมือการโอนและมาตรการคุ้มครอง ผู้ให้บริการจะตอบไม่น่าเชื่อถือ เมื่อผู้ซื้อเรียกทุกคำถามว่า «สำคัญมาก» แล้วผ่อนผันไปครึ่งหนึ่งระหว่างการเจรจาเชิงพาณิชย์
กำหนดความใหม่ของหลักฐาน แผนผังสถาปัตยกรรมและทะเบียนผู้ประมวลผลช่วงต่อควรมีวันที่มีผล ภาคผนวกสัญญาควรระบุเวอร์ชันบริการหรือข้อเสนอที่ครอบคลุม ตัวอย่างการปฏิบัติงานควรมาจากการควบคุมปัจจุบัน ไม่ใช่ระบบที่เลิกใช้แล้ว กำหนดวันหมดอายุหรือการทบทวนตามเหตุการณ์สำหรับหลักฐานที่เปลี่ยนได้ ส่วนเงื่อนไขที่ลงนามถาวรเก็บไว้ในแฟ้มจนกว่าจะมีการแก้ไข
ท้ายที่สุด ให้ระบุความขัดแย้งอย่างชัดเจน ผู้ให้บริการควรบอกคำตอบใดที่ขึ้นกับแพ็กเกจพรีเมียม การตั้งค่าเสริม การกระทำของลูกค้า หรือฟีเจอร์ที่วางแผนไว้ ฝ่ายจัดซื้อจะนำเงื่อนไขเบื้องต้นไปใส่ในคำสั่งซื้อและส่งต่อให้เจ้าของการติดตั้ง การควบคุมที่พึ่งการตั้งค่าจะล้มเหลว หากไม่มีใครรู้ว่าใครต้องเปิดการตั้งค่านั้น
ให้คะแนนข้ออ้าง ไม่ใช่ภาษาการขาย
ผู้ซื้อให้คะแนนความพร้อมด้านที่อยู่ของข้อมูลได้ โดยถามว่าเส้นทางข้อมูลสำคัญทุกเส้นทางมีหลักฐานทั้งสามรูปแบบหรือไม่ ได้แก่ คำมั่นที่ผูกพันได้ คำอธิบายระบบปัจจุบัน และหลักฐานเฉพาะผู้เช่าหรือหลักฐานปฏิบัติการล่าสุด การขาดชั้นใดชั้นหนึ่งทำให้เกิดคำถามติดตามที่ชัดเจน แทนการถกเถียงกว้าง ๆ ว่าผู้ให้บริการ «ปฏิบัติตาม GDPR» หรือไม่
ใช้สถานะตัดสินใจสี่แบบ
- ตรวจสอบแล้ว: หลักฐานสอดคล้องกัน ครอบคลุมบริการที่ซื้อ และมีกระบวนการอัปเดต
- อนุมัติแบบมีเงื่อนไข: ช่องว่างจำกัดมีเจ้าของ กำหนดเวลา และการควบคุมชดเชย
- จำกัดการใช้: บริการจัดการได้เฉพาะข้อมูลที่เหมาะกับกรณีใช้งานความเสี่ยงต่ำที่นิยามไว้
- ปฏิเสธ: เส้นทางการโอนหรือเข้าถึงสำคัญยังไม่ทราบ ไม่มีขอบเขต หรือสัญญาอนุญาตไว้ขัดกับข้อกำหนดของผู้ซื้อ
แนวทางนี้ยังป้องกันนิสัยไม่ดีสองอย่างของฝ่ายจัดซื้อ อย่างแรกคือปฏิเสธผู้ให้บริการทั่วโลกทุกรายเพียงเพราะมีพนักงานนอกยุโรป แม้พนักงานเหล่านั้นจะเข้าถึงสภาพแวดล้อมของผู้ซื้อไม่ได้ อย่างที่สองคืออนุมัติผลิตภัณฑ์ «โฮสต์ใน EU» โดยไม่ตรวจสอบการกำหนดเส้นทางโมเดลหรือการเข้าถึงเพื่อสนับสนุน รอยเท้าตามเขตอำนาจศาลเป็นเพียงบริบท การไหลของข้อมูลจริงและการควบคุมที่บังคับใช้ได้ต่างหากที่กำหนดระดับความเสี่ยง
ใช้คะแนนกับรุ่นและการตั้งค่าที่กำลังซื้ออย่างเจาะจง การควบคุมสำหรับองค์กรที่อธิบายในเอกสารความปลอดภัยอาจไม่มีในแพ็กเกจฟรีหรือแบบบริการตนเอง ตัวเลือกภูมิภาคอาจใช้ได้เฉพาะระบบจริงที่โฮสต์ ขณะที่พรีวิวหรือพื้นที่ทำงานสำหรับสร้างแอปใช้ตำแหน่งเริ่มต้น บันทึกเงื่อนไข แพ็กเกจที่จำกัด และการตั้งค่าไว้ในแบบฟอร์มสั่งซื้อ เพื่อให้รูปแบบที่อนุมัติตรงกับสิ่งที่ผู้ดูแลระบบปรับใช้ได้
Koder.ai สามารถรันแอปพลิเคชันบนโครงสร้างพื้นฐาน AWS ในหลายประเทศได้ แต่ผู้ซื้อควรยังกำหนดให้ประเทศที่เลือก องค์ประกอบที่ครอบคลุม และเส้นทางเข้าถึงปรากฏในชุดหลักฐาน ความสามารถของผลิตภัณฑ์เริ่มต้นบทสนทนา หลักฐานของฝ่ายจัดซื้อทำให้บทสนทนานั้นจบลงได้
อย่ายอมรับคำสัญญาในโรดแมปสำหรับการควบคุมที่จำเป็นก่อนข้อมูลส่วนบุคคลเข้าสู่บริการ โรดแมปช่วยการประเมินใหม่ในอนาคตได้ จนกว่าฟีเจอร์จะมีอยู่จริง และผู้ให้บริการผูกพัน อธิบาย และสาธิตได้ ให้จำกัดเวิร์กโหลดหรือเลือกการออกแบบอื่น
ระเบียนอนุมัติควรจบด้วยความเสี่ยงคงเหลือ ไม่ใช่คำตัดสินเชิงการตลาด ระบุการเข้าถึงข้ามพรมแดนที่อนุญาต เส้นทางกฎหมาย ข้อมูลที่เปิดเผย มาตรการเพิ่มเติม และบุคคลที่ยอมรับความเสี่ยงนั้น ระเบียนนี้ทำให้ทีมความเป็นส่วนตัวมีสิ่งที่ปกป้องได้ และให้วิศวกรมีขอบเขตที่ใช้งานได้จริง
คำถามที่พบบ่อย
การโฮสต์ในสหภาพยุโรปทำให้ผู้สร้างแอป AI ปฏิบัติตาม GDPR โดยอัตโนมัติหรือไม่?
ไม่ใช่ การโฮสต์ในสหภาพยุโรปครอบคลุมเพียงส่วนหนึ่งของการไหลของข้อมูล ข้อกำหนด GDPR ยังครอบคลุมวัตถุประสงค์ ความปลอดภัย ระยะเวลาเก็บรักษา เงื่อนไขสำหรับผู้ประมวลผล สิทธิของเจ้าของข้อมูล รวมถึงการโอนข้อมูลหรือการเข้าถึงจากระยะไกล ตรวจสอบการตั้งค่าจริงและสัญญา แทนที่จะถือว่าป้ายระบุภูมิภาคเป็นใบรับรองการปฏิบัติตามข้อกำหนด
การเข้าถึงเพื่อสนับสนุนจากนอก EEA ถือเป็นการโอนข้อมูลหรือไม่?
ควรถือว่าเป็นการโอนข้อมูลเมื่อบุคคลในประเทศที่สามสามารถดูข้อมูลส่วนบุคคลที่เก็บอยู่ใน EEA ได้ ขอข้อมูลประเทศที่ผู้ปฏิบัติงานอยู่ กลไกการโอน การอนุมัติ บันทึกเซสชัน และเวลาหมดอายุของสิทธิ์เข้าถึง
การตั้งค่าภูมิภาค EU ควรครอบคลุมอะไรบ้าง?
ควรระบุขอบเขตของพื้นที่ทำงานสำหรับสร้างแอป สภาพแวดล้อมจริง ฐานข้อมูล ไฟล์ พรอมต์ คำตอบจากโมเดล บันทึก แคช ระบบสร้าง และสภาพแวดล้อมพรีวิว การสำรองข้อมูล การกู้คืนจากภัยพิบัติ ผู้ให้บริการโมเดล และการสนับสนุนโดยบุคคล ต้องมีคำตอบที่ชัดเจน เพราะมักใช้เส้นทางแยกต่างหาก
สำรองข้อมูลของข้อมูลใน EU ไว้นอก EEA ได้หรือไม่?
ผู้ให้บริการอาจออกแบบการกู้คืนข้ามพรมแดนได้ แต่ต้องเปิดเผยตำแหน่ง ผู้ซื้อต้องมีกลไกการโอนที่ชอบด้วยกฎหมาย การประเมินเมื่อจำเป็น มาตรการคุ้มครองที่เหมาะสม และเงื่อนไขสัญญาที่ชัดเจนสำหรับตำแหน่ง การเข้าถึง การเก็บรักษา การกู้คืน และการลบ
รายการผู้ประมวลผลช่วงต่อควรมีข้อมูลอะไร?
ขอชื่อนิติบุคคล วัตถุประสงค์ของบริการ ประเภทข้อมูล ประเทศที่จัดเก็บ ประเทศที่เข้าถึงจากระยะไกล และกลไกการโอนของผู้ประมวลผลช่วงต่อแต่ละราย รายการควรอธิบายด้วยว่าผู้ซื้อจะได้รับแจ้งอย่างไรและเมื่อใด ก่อนการเพิ่มหรือเปลี่ยนผู้ประมวลผลช่วงต่อมีผล
Standard Contractual Clauses ทำให้การโอนข้อมูลปลอดภัยได้ด้วยตัวเองหรือไม่?
ไม่ใช่ คู่สัญญาต้องเลือกโมดูล SCC ที่ถูกต้อง กรอกภาคผนวก ทำความเข้าใจการโอนต่อ และประเมินว่ากฎหมายและแนวปฏิบัติของประเทศปลายทางกระทบต่อข้อสัญญาหรือไม่ อาจยังต้องมีมาตรการทางเทคนิค ตามสัญญา หรือเชิงองค์กรเพิ่มเติม
DPA ต่างจาก SCC อย่างไร?
DPA กำกับความสัมพันธ์ระหว่างผู้ควบคุมข้อมูลกับผู้ประมวลผล และเงื่อนไขการประมวลผลตามมาตรา 28 ส่วน SCC เป็นมาตรการคุ้มครองทางเลือกหนึ่งสำหรับการโอนข้อมูลระหว่างประเทศที่ระบุไว้ ผู้ให้บริการจึงอาจต้องใช้เอกสารทั้งสองฉบับกับบริการเดียวกัน
ฝ่ายจัดซื้อทดสอบข้อจำกัดการเข้าถึงเพื่อสนับสนุนได้อย่างไร?
ใช้ระเบียนข้อมูลสังเคราะห์ในผู้เช่าทดสอบ ขอเซสชันสนับสนุนที่ควบคุมได้ แล้วตรวจสอบการอนุมัติ ประเทศของผู้ปฏิบัติงาน บทบาทชั่วคราว เหตุการณ์ในเซสชัน และการเพิกถอน การทดสอบควรพิสูจน์การควบคุมโดยไม่เปิดเผยข้อมูลลูกค้าจริง
การเข้ารหัสเพียงพอสำหรับแก้ปัญหาที่อยู่ของข้อมูลหรือไม่?
การเข้ารหัสลดความเสี่ยง แต่ไม่เปลี่ยนตำแหน่งที่มีการประมวลผลหรือผู้ที่เข้าถึงข้อความที่ถอดรหัสได้ ตรวจสอบว่าใครถือกุญแจ ถอดรหัสที่ใด ฝ่ายสนับสนุนหรือผู้ให้บริการโมเดลอ่านข้อมูลได้หรือไม่ และการออกแบบการเข้ารหัสรับมือภัยคุกคามใดจริง ๆ
ผู้ซื้อควรทบทวนหลักฐานเรื่องที่อยู่ของข้อมูลบ่อยเพียงใด?
ทบทวนเมื่อมีการเปลี่ยนแปลงสำคัญ เช่น ผู้ประมวลผลช่วงต่อรายใหม่ ประเทศของฝ่ายสนับสนุน รูปแบบการสำรองข้อมูล เส้นทางโมเดล หรือตำแหน่งประมวลผลใหม่ และกำหนดรอบทบทวนหลักฐานที่อาจเปลี่ยนเงียบ ๆ เอกสารทุกชิ้นควรมีเจ้าของ ขอบเขต วันที่มีผล และเหตุให้ต้องอัปเดต