תארו לעצמכם: אפליקציית המובייל שלכם עם מיליון משתמשים באיחוד האירופי. רשות הגנת המידע (DPA) דורשת תיעוד פעולות עיבוד (Records of Processing Activities) — הוכחה לעמידה בדרישות. אם אין יומן, קנס של עד 4% מהמחזור השנתי. זה בדיוק מה שקרה לאחד הלקוחות שלנו: לאחר ביקורת, הם קיבלו אזהרה על העברת נתונים לא מתועדת לרשת פרסום. יישמנו את היומן תוך 3 ימים, ובבדיקה חוזרת, הקנס נמנע.
GDPR (סעיף 30) דורש לא רק קבלת הסכמה, אלא תיעוד כל פעולה: מתי, אילו נתונים, לאילו מטרות, ועל בסיס חוקי מה. עבור אפליקציות B2C עם קהל באיחוד האירופי, זה אומר שמירת יומן קריא למכונה. אנו מציעים מחזור מלא: ביקורת של התשתית הנוכחית שלכם, עיצוב סכמה, הטמעת middleware, וממשק לקוח.
בפועל, 60% מהאפליקציות שביקרנו אינן מתעדות העברות נתונים לשירותי אנליטיקה. זו הפרה ישירה. הפתרון שלנו מתערב אוטומטית בפעולות כאלה ומתעד אותן ביומן append-only.
אילו פעולות דורשות תיעוד?
פעולות שחייבות להיות מתועדות:
- איסוף נתונים במהלך הרשמה: שדות, חותמת זמן, בסיס חוקי (הסכמה/חוזה/אינטרס לגיטימי)
- העברה לצדדים שלישיים: שליחת דוא"ל ל-Mailchimp, אנליטיקה ל-Firebase, פרסומות ל-AdMob—כל העברה עם מקבל ומטרה
- עדכוני נתונים: שינויי פרופיל, דוא"ל, טלפון
- מחיקה: לפי בקשת משתמש או לאחר תום תקופת השמירה
- גישה: מתי ואיזה חבר צוות צפה בנתונים (לאפליקציות ארגוניות)
למה היומן חייב להיות append-only?
עריכה או מחיקה של רשומות יומן היא בעצמה הפרת GDPR. לכן, היומן הוא append-only. לא ניתן לשנות או למחוק רשומות. תקופת השמירה היא לפחות 3 שנים. עבור אפליקציות מובייל עם תדירות פעולות גבוהה, זה יכול להיות 50,000 עד 500,000 רשומות בחודש. אינדוקס נכון (data_processing_logs: id UUID PK user_id UUID FK NULLABLE -- null для анонимных операций operation_type VARCHAR -- 'collect', 'transfer', 'update', 'delete', 'access' data_categories TEXT[] -- ['email', 'location', 'purchase_history'] purpose VARCHAR -- 'analytics', 'marketing', 'service_provision' legal_basis VARCHAR -- 'consent', 'contract', 'legitimate_interest' third_party VARCHAR NULLABLE -- 'firebase', 'mailchimp', null actor_type VARCHAR -- 'user', 'system', 'staff' actor_id UUID NULLABLE -- ID сотрудника при actor_type='staff' ip_address INET NULLABLE metadata JSONB -- доп. контекст created_at TIMESTAMPTZ DEFAULT NOW() , class DataProcessingLogMiddleware: LOGGED_ENDPOINTS = { 'POST /api/auth/register': ('collect', ['email', 'name'], 'contract'), 'PUT /api/user/profile': ('update', ['profile_data'], 'contract'), 'DELETE /api/user': ('delete', ['all_user_data'], 'legal_obligation'), } def process_response(self, request, response): key = f"{request.method} {request.path}" if key in self.LOGGED_ENDPOINTS and response.status_code < 400: op_type, categories, basis = self.LOGGED_ENDPOINTS[key] DataProcessingLog.objects.create( user_id=request.user.id if request.user.is_authenticated else None, operation_type=op_type, data_categories=categories, legal_basis=basis, ip_address=get_client_ip(request) ) return response , user_id) מבטיח חיפוש מהיר במהלך ביקורות.
סכמת היומן
data_processing_logs:
id UUID PK
user_id UUID FK NULLABLE -- null для анонимных операций
operation_type VARCHAR -- 'collect', 'transfer', 'update', 'delete', 'access'
data_categories TEXT[] -- ['email', 'location', 'purchase_history']
purpose VARCHAR -- 'analytics', 'marketing', 'service_provision'
legal_basis VARCHAR -- 'consent', 'contract', 'legitimate_interest'
third_party VARCHAR NULLABLE -- 'firebase', 'mailchimp', null
actor_type VARCHAR -- 'user', 'system', 'staff'
actor_id UUID NULLABLE -- ID сотрудника при actor_type='staff'
ip_address INET NULLABLE
metadata JSONB -- доп. контекст
created_at TIMESTAMPTZ DEFAULT NOW() פרטים על בחירת סוגי נתונים
עבור קטגוריות נתונים, אנו משתמשים במערך מחרוזות ולא בטבלה נפרדת—זה מאיץ כתיבות. אינדקסים על `user_id` ו-`operation_type` מפחיתים את זמן החיפוש ל-10 אלפיות השנייה עבור מיליון רשומות.איך ליישם את היומן בצד השרת?
הגישה הנוחה ביותר היא באמצעות middleware/aspects, ולא ידנית בכל שירות. זה מפחית את הסיכון להחמצת פעולה. דוגמה ב-Django:
class DataProcessingLogMiddleware:
LOGGED_ENDPOINTS = {
'POST /api/auth/register': ('collect', ['email', 'name'], 'contract'),
'PUT /api/user/profile': ('update', ['profile_data'], 'contract'),
'DELETE /api/user': ('delete', ['all_user_data'], 'legal_obligation'),
}
def process_response(self, request, response):
key = f"{request.method} {request.path}"
if key in self.LOGGED_ENDPOINTS and response.status_code < 400:
op_type, categories, basis = self.LOGGED_ENDPOINTS[key]
DataProcessingLog.objects.create(
user_id=request.user.id if request.user.is_authenticated else None,
operation_type=op_type,
data_categories=categories,
legal_basis=basis,
ip_address=get_client_ip(request)
)
return response
מה המשתמש רואה בקטע 'הנתונים שלי'?
לפי GDPR, למשתמשים יש זכות לראות כיצד הנתונים שלהם עובדו. באפליקציה, ספקו קטע: "הגדרות → פרטיות → היסטוריית עיבוד נתונים". הציגו רשומות יומן מסוננות: רק רשומות עם struct DataProcessingEntry: Identifiable, Decodable { let id: UUID let operationDescription: String // "Ваши данные переданы аналитическому сервису" let date: Date let dataCategories: [String] let purpose: String } של המשתמש הנוכחי, ללא פרטים טכניים, עם תיאורי פעולות מובנים.
struct DataProcessingEntry: Identifiable, Decodable {
let id: UUID
let operationDescription: String // "Ваши данные переданы аналитическому сервису"
let date: Date
let dataCategories: [String]
let purpose: String
}צדדים שלישיים מוצגים בשמות הרשמיים שלהם (Google Analytics, Meta Pixel)—המשתמש צריך לזהות את השירות.
אינטגרציה עם ניהול הסכמות
כאשר נסוגים מהסכמה למטרה מסוימת (למשל, שיווק), צרו רשומת יומן operation_type='consent_revoked' והפסיקו להעביר נתונים לצדדים השלישיים המתאימים. זה מתעד את רגע הנסיגה—חשוב לביקורות DPA.
איך אנחנו עושים את זה: שלבי יישום
- ביקורת זרימת נתונים — זיהוי כל נקודות האיסוף וההעברה. ניתוח קוד, תצורות בקשות רשת, אינטגרציות SDK (Firebase, AppsFlyer).
- עיצוב סכמת יומן — מותאם לתשתית שלכם (PostgreSQL, MongoDB, BigQuery). בחירת מודל אופטימלי לעומס שלכם.
- הטמעת middleware/aspects — תיעוד אוטומטי של פעולות מפתח. הגדרת טריגרים על נקודות קצה קריטיות.
- API להיסטוריית משתמש — עם סינון, פגינציה, זכויות גישה.
- פיתוח ממשק לקוח — ב-SwiftUI / Jetpack Compose / Flutter — הצגת היסטוריה מובנת.
- אינטגרציה עם CMP (פלטפורמת ניהול הסכמות) וטיפול בנסיגה מהסכמה.
- תיעוד API וביקורת, הדרכת צוות.
לוחות זמנים ואחריות
| שלב | משך |
|---|---|
| ביקורת זרימת נתונים | 1–2 ימים |
| עיצוב סכמה | 0.5–1 יום |
| Middleware + API | 2–3 ימים |
| ממשק לקוח | 1–2 ימים |
| אינטגרציית CMP | יום אחד |
| תיעוד | 0.5 יום |
פרויקט מלא מ-5 עד 10 ימים. אנו מספקים אחריות לעמידה בדרישות GDPR וסיוע במהלך ביקורות DPA. הניסיון שלנו: מעל 5 שנים בפיתוח אפליקציות מובייל ופתרונות ציות. קבלו ייעוץ: שלחו תיאור של האפליקציה שלכם, ואנחנו נעריך את היקף העבודה.
צרו קשר לביקורת—נבדוק את היומן הנוכחי שלכם תוך יום אחד. הזמינו יישום יומן עיבוד נתונים והגנו על העסק שלכם מקנסות.
השוואת גישות לתיעוד
| גישה | מאמץ | סיכון להחמצת פעולות | גמישות |
|---|---|---|---|
| ידני בכל שירות | גבוה | גבוה | נמוך |
| Middleware/aspects | בינוני | נמוך | גבוה |
| מסגרת DPA (OneTrust) | נמוך | בינוני | בינוני |
עבור רוב הפרויקטים, אנו ממליצים על גישת ה-middleware. היא מאזנת בין עלות היישום לבין שלמות הכיסוי. אם שינויי API תכופים, ניתן לעבור למסגרת DPA הצהרתית.







