מנהל מוצר בברלין דוחף עדכון תכונה. צוות צמיחה בלונדון מנהל קמפיין באמצעות סוכנות שנחאי. ספק SaaS בסינגפור מאחסן בשקט תמלילי תמיכת לקוחות הכוללים את השמות, מספרי הטלפון ושברי הזיהוי של משתמשים בצ'נגדו. אף אחד מהצוותים האלה לא חושב על עצמו כפועל בסין. כולם, למטרות חוק הגנת מידע אישי, מעבדים של מידע אישי סיני - וכולם נמצאים בגדר.
שלוש שנים לאחר כניסת חוק הגנת מידע אישי לתוקף, התמונה הרגולטורית התייצבה מספיק כדי ש"אנחנו מחכים לראות איך זה מתנער" היא כבר לא עמדה שניתנת להגנה. מינהל מרחב הסייבר של סין פרסם אמצעי יישום, תיקן אותם והבהיר את הספים. לעסקים זרים יש כעת מספיק איתות כדי לבנות קו בסיס עמידה בתאימות. היצירה הזו מגדירה איך נראה קו הבסיס הזה בפועל.
הטריגר החוץ-טריטוריאלי שרוב הצוותים מזלזלים
PIPL חל על עיבוד בתוך סין, ובאופן קריטי - על עיבוד מחוץ לסין המכוון לאנשים בסין לצורך אספקת מוצרים או שירותים, או ניתוח התנהגותם. הניסוח רחב ומכוון. אפליקציית צרכנים זמינה במנדרינית בחנות אפליקציות גלובלית, אתר B2C שנשלח לכתובות ביבשת, צינור ניתוח שמפלח משתמשים לפי עיר סינית: כל אחד מהם הוא טריגר סביר.
התוצאה המעשית היא שהיקף הוא רק לעתים רחוקות כן או לא נקי. השאלה היא אילו קווי מוצרים, אילו קבוצות משתמשים, ואילו מערכי נתונים נמצאים בהישג יד של החוק. לכן, משימת הציות הראשונה אינה ניסוח הודעת פרטיות. זה מיפוי נתונים: זיהוי היכן המידע האישי הסיני נכנס למערכות שלך, היכן הוא מאוחסן, מי נוגע בו והיכן הוא יוצא. עד שהמפה הזו תתקיים, כל שליטה במורד הזרם היא ניחוש.
הסכמה: בסיס חוקי, לא תיבת סימון
PIPL מתואר לעתים קרובות כמשטר בהסכמה, ובחדרי ישיבות זרים זה מתורגם ל"הוסף תיבת סימון". זה ממעט את החובה. PIPL מכיר בכמה בסיסים חוקיים - נחיצות חוזית, חובה סטטוטורית, ניהול משאבי אנוש, אינטרסים ציבוריים ואחרים - אך ההסכמה נשארת סוס העבודה, והחוק קובע רף גבוה למה שחשוב.
הסכמה במסגרת PIPL חייבת להיות מושכלת, מרצון ומפורשת. כאשר העיבוד כולל מידע אישי רגיש (חשבונות פיננסיים, בריאות, נתונים ביומטריים, מידע אישי של קטינים מתחת לגיל 14, מעקב אחר מיקום וקטגוריות דומות) או העברה חוצת גבולות, נדרשת הסכמה נפרדת. "נפרד" פירושו בדיוק זה: מעשה הסכם מובהק וספציפי, לא פסקה שקבורה בתוך הסכמה כללית לתנאים.
ארכיטקטורת הסכמה ישימה עבור עסקים זרים כוללת בדרך כלל:
- הודעה מרובדת המציינת, בסינית פשוטה, את זהות המעבד, קטגוריות המידע האישי, המטרות, תקופת השמירה וזכויות המשתמש.
- מתגים גרנוריים לקטגוריות עיבוד רגישות ולשיווק, מופרדים מהסכמת השירות הליבה.
- זרימת הסכמה חוצת גבולות מובהקת הנותנת שמות של הנמען בחו"ל, אזור השיפוט של היעד ומטרת ההעברה.
- מנגנון נסיגה קל לשימוש כמו זרימת ההסכמה המקורית, ללא דפוסים כהים.
- יומן ביקורת המתעד, לכל משתמש, למה התקבל, מתי ונגד איזו גרסה של ההודעה.
הנקודה האחרונה חשובה יותר ממה שהקבוצות מצפות. הרגולטורים והצדדים הנגדיים מבקשים יותר ויותר ראיות, לא הצהרות.
העברה חוצת גבולות: שלושה מסלולים, החלטה אחת
העברת מידע אישי סיני לחוף הים הוא האזור שבו עסקים זרים מגלים לרוב שהארכיטקטורה הקיימת שלהם אינה תואמת. PIPL מספק שלושה מנגנונים עיקריים, משוכללים על ידי מדדי CAC הבאים:- הערכת אבטחת CAC. חובה למפעילי תשתיות מידע קריטיות, למעבדים המטפלים במידע אישי מעל ספי נפח שנקבעו, ולהעברת "נתונים חשובים". זוהי סקירה בראשות הממשלה, לא אישור עצמי.
- סעיפים חוזיים סטנדרטיים (סין SCCs). חוזה תבנית בין היצואן הסיני לבין הנמען בחו"ל, המוגש ל-CAC המחוזית יחד עם הערכת השפעה על הגנת מידע אישי. מתאים להעברות באמצע נפח מתחת לספי ההערכה.
- אישור הגנת מידע אישי. הונפק על ידי גופים מוסמכים של CAC. בפועל מסלול זה שימושי ביותר עבור העברות תוך קבוצתיות בתוך חברות רב לאומיות.
ההקלות של 2024 הציגו פטורים עבור העברות מסוימות בנפח נמוך, העברות הנחוצות לביצוע חוזה עם האדם (מסחר אלקטרוני חוצה גבולות, הזמנת נסיעות, בקשות לוויזה), והעברות משאבי אנוש הנחוצות לניהול תעסוקה חוצה גבולות. הפטורים הללו אמיתיים אך צרים. הם מפעילים ספירת נפח, על אופי ההכרח החוזי, והאם מדובר במידע אישי רגיש. התייחסות לפטור כמנח קבוע ללא בדיקה תקופתית היא טעות נפוצה.
לא משנה באיזה מסלול חל, כל העברה חוצת גבולות דורשת הערכת השפעה על הגנת מידע אישי - מתועדת, נשמרת למשך שלוש שנים לפחות, ומתעדכנת כאשר העיבוד משתנה באופן מהותי.
קו הבסיס הריאלי של תאימות
עבור עסק זר בגודל בינוני המטפל בנתוני משתמשים סיניים, קו בסיס בר הגנה נראה בערך כך:
- מפת נתונים המכסה את כל זרימת המידע האישי הסינית, מתרעננת לפחות מדי שנה.
- הודעת פרטיות בשפה הסינית וארכיטקטורת הסכמה המייחדת הסכמה כללית, רגישה וחוצת גבולות.
- נציג או ישות ייעודיים בתוך סין, במידת הצורך, עם פרטי התקשרות שפורסמו.
- מנגנון העברה חוצה גבולות נבחר - הערכה, SCCs או אישור - עם הערכת ההשפעה הבסיסית בקובץ.
- בדיקת ספקים המכסה כל מעבד המשך הנוגע בנתונים, כולל ספקי ענן ואנליטיקה.
- נוהל תגובה לאירוע העומד בציפיות ההודעה של PIPL הן לרגולטורים והן לאנשים מושפעים.
- הכשרה פנימית לצוותי מוצר, הנדסה ושיווק על מה שמפעיל הערכת השפעה חדשה.
כל זה לא אקזוטי. בגדול, זוהי אותה דיסציפלינה שתוכנית GDPR בוגרת כבר מתרגלת, עם שכבות-על ספציפיות לסינית על פירוט הסכמה, הגשות חוצי גבולות ושפה.
היכן שקבוצות זרות בדרך כלל טועים
שלושה דפוסים חוזרים על עצמם. ראשית, התייחסות ל-PIPL כאל תרגיל תרגום בהודעת GDPR - שני המשטרים חופפים אך חלוקים בהסכמה, במכניקה חוצת גבולות ובתפקיד של המדינה. שנית, בהנחה שמכיוון שהנתונים מתארחים מחוץ לסין, PIPL אינו חל; אקסטריטוריאליות היא הכלל, לא היוצא מן הכלל. שלישית, השארת ההגשה חוצת הגבולות עד שרגולטור או צד סיני מסחרי יבקש זאת, עד אז ציר הזמן כבר לא שלך לשלוט בו.
מסלול הערכת האבטחה של CAC בפרט אינו תהליך שמתגמל הכנה ברגע האחרון. הגשות SCC מהירות יותר אך עדיין דורשות הערכת השפעה מוכחת כראוי מאחוריהן.
תאימות לפרטיות מידע בסין היא, בסופו של דבר, שאלה של בגרות תפעולית ולא של פיקחות משפטית. ניתן לדעת את הכללים. עלות ההתעלמות מהם - פעולות אכיפה, העברות חסומות, עסקאות מסחריות אבודות עם שותפים סיניים ששואלים כעת את השאלות בעצמם - הולכת וגוברת.
לצוותים זרים שזקוקים לייעוץ מוסמך PRC לגבי מבנה העברה, זרימת הסכמה או הגשה ספציפיים, השירות עורך הדין הסיני של Serene Jade משלב אותך עם עורך דין ביבשת והונג קונג.
שאלות נפוצות
האם אנחנו צריכים ישות בסין רק כדי להגיש SCCs? לא בהכרח. היצואן הסיני במסגרת ה-SCCs הוא מי שמחזיק במידע האישי בתוך סין - זה עשוי להיות חברת הבת המקומית שלך, שותף למיזם משותף או פלטפורמה סינית שאתה פועל דרכה. אם אין לך נוכחות כלל, השאלה הופכת אם עליך למנות נציג ייעודי לפי סעיף 53 של PIPL.האם שליחת נתונים להונג קונג נחשבת כהעברה חוצת גבולות? כן. למטרות PIPL מתייחסים להונג קונג כאל מחוץ ליבשת סין, ולכן העברות לשם דורשות אחד משלושת המנגנונים או פטור תקף, באותה בסיס כמו העברות ללונדון או פרנקפורט.
האם נוכל להסתמך על הפטור מהצורך החוזי עבור נתוני לקוחות ה-SaaS שלנו? רק כאשר ההעברה נחוצה באמת כדי לבצע את החוזה שהאדם התקשר בו - למשל, מילוי הזמנה שהוציא. העברות B2B SaaS של נתוני משתמש קצה, ניתוחים ורוב מקרי השימוש בשיווק נופלות מחוץ לה וזקוקים ל-SCCs, הסמכה או הערכה.