ספקי ענן אחרי תיקון 13: מה לבדוק בחוזה עם AWS, גוגל או SaaS ישראלי

רוב מאגרי המידע של הלקוחות שלכם כבר לא יושבים אצלכם. הם ב-AWS, ב-Google Cloud או ב-Azure; רשימת הדיוור ב-Mailchimp; הכרטסת ב-CRM ישראלי; קבצי המשכורות בלשכת שכר בענן. ההנחה השקטה של רוב העסקים היא ש״זו הבעיה של הספק״ — הרי הם מחזיקים בשרתים, הם אחראים לאבטחה. אחרי תיקון 13 לחוק הגנת הפרטיות ההנחה הזו לא רק שגויה — היא מסוכנת. מבחינת החוק, הספק שמחזיק את מידע הלקוחות שלכם הוא מחזיק; אתם נשארתם בעל השליטה במאגר — והאחריות המשפטית לא עוברת לספק יחד עם הקבצים. במאמר הזה נפרק בדיוק מה תקנה 15 דורשת מכם בהתקשרות עם ספק ענן, מה עושים מול הענקיות שאיתן אי אפשר לנהל משא ומתן, ומה לדרוש מספק SaaS ישראלי קטן שאולי אין לו בכלל חוזה עיבוד — כולל צ׳קליסט בן 12 סעיפים שאפשר להצמיד לכל התקשרות.

תקנה 15: מה החוק דורש מכם בהתקשרות עם ספק

החובות שלכם כלפי מחזיק חיצוני לא נולדו עם תיקון 13 — הן מעוגנות בתקנה 15 לתקנות הגנת הפרטיות (אבטחת מידע), התשע״ז-2017, שכותרתה ״מיקור חוץ״. מה שתיקון 13 הוסיף הוא השיניים: עיצומים כספיים משמעותיים ואכיפה אקטיבית. התהליך הכללי של ניהול סיכוני ספקים — מיפוי, תיעדוף ושאלון — מכוסה אצלנו במאמר ניהול סיכוני צד שלישי לעסק קטן; כאן אנחנו מתמקדים בשכבה שרוב העסקים מדלגים עליה — החוזה עצמו, שהוא ה-DPA (Data Processing Agreement / הסכם עיבוד נתונים).

תקנה 15 מציבה שתי דרישות מסגרת ופירוט מדויק של מה שחייב להופיע בחוזה. הדרישה הראשונה: הערכת סיכונים לפני ההתקשרות — עוד לפני שחתמתם, עליכם לבחון את סיכוני אבטחת המידע הכרוכים בהעברת המידע לאותו ספק ספציפי. הדרישה השנייה: הסכם בכתב שמכיל את כל הרכיבים הבאים.

• סוגי המידע, היקף העיבוד והמטרות המותרות — אילו נתונים הספק מקבל, מה מותר לו לעשות איתם, ולאילו מטרות בלבד.
• המערכות שהספק רשאי לגשת אליהן — הגדרה של הנכסים והמאגרים שבתחום ההתקשרות.
• סוגי העיבוד והפעולות המותרים — מה הספק רשאי לבצע במידע (אחסון, ניתוח, שליחה) ומה לא.
• משך ההתקשרות והחזרה או השמדה של המידע בסיומה — כולל חובת הודעה לבעל השליטה על סיום, ומה קורה לנתונים ביום שאחרי.
• יישום חובות האבטחה לפי התקנות — התחייבות הספק לעמוד בחובות אבטחת המידע לפי רמת האבטחה של המאגר, ולהנחיות אבטחה נוספות שתיתנו.
• התחייבויות סודיות של עובדי הספק — חובה להחתים את עובדיו על התחייבות לסודיות ולעמידה באמצעי האבטחה.
• קבלני משנה תחת אותם תנאים — כל קבלן משנה של הספק חייב להיות כפוף להוראות הגנה זהות (שקיפות שרשרת עיבוד המשנה).
• דיווח שנתי ודיווח על אירועים — חובת דיווח של הספק, לפחות אחת לשנה, על עמידתו בהתחייבויות, וחובת הודעה על אירועי אבטחה.

ולא נגמר בחתימה: תקנה 15 מחייבת גם לשלב את הוראות ההסכם בנוהל האבטחה של המאגר, ולהפעיל אמצעי בקרה ופיקוח על הספק בהתאם לסיכונים שזוהו. כלומר — לא רק לחתום, אלא גם לתעד, ומדי פעם לבדוק שהספק באמת עומד בהתחייבויותיו. שימו לב לפטור אחד: תקנה 15 אינה חלה על התקשרות עם יחיד (אדם פרטי) — היא נועדה להסדרת מיקור חוץ לגורמים עסקיים.

הענקיות: AWS, גוגל ומיקרוסופט — לא מנהלים איתן משא ומתן

יש כאן פרדוקס מרגיע: דווקא הספקים הגדולים ביותר, שאיתם אין לכם שום סיכוי לנהל משא ומתן על נוסח החוזה, הם אלה שהכי קל לסגור איתם את דרישת ה-DPA. הסיבה: לשלוש הענקיות יש הסכם עיבוד נתונים סטנדרטי מוכן ומפורסם, שנכתב כדי לעמוד בדרישות ה-GDPR האירופי — והוא מכסה את מרבית מה שתקנה 15 דורשת (חובות אבטחה, סודיות, קבלני משנה, החזרה/מחיקה בסיום, דיווח על אירועים).

• AWS — ה-AWS Data Processing Addendum משולב אוטומטית בתנאי השירות (Service Terms) וחל על כל לקוח בעולם המעבד מידע אישי, ללא צורך בחתימה נפרדת.
• Google Cloud — ה-Cloud Data Processing Addendum (CDPA) משולב בהסכם מול הלקוח וכולל את ה-Standard Contractual Clauses להעברות בין-לאומיות.
• Microsoft (Azure / Microsoft 365) — ה-Microsoft Products and Services Data Protection Addendum (DPA) הוא נספח לתנאי המוצר וחל אוטומטית על לקוחות שירותי הענן שלה.

ה-SaaS הישראלי הקטן: כאן מתחילות הבעיות האמיתיות

ה-CRM הישראלי, מערכת הסליקה, ספק הדיוור, כלי הניהול שכתב מתכנת עצמאי — כאן, בשכבת הספקים הקטנים, מתגלה שברוב הפעמים אין בכלל DPA. שאלתם ״יש לכם הסכם עיבוד נתונים?״ ומקבלים שתיקה, או ״יש לנו מדיניות פרטיות באתר״ (שזה לא אותו דבר). זו בדיוק ההתקשרות שבה אתם, כבעלי השליטה, חשופים — כי החוק מטיל עליכם את החובה גם אם הספק לא יזם אותה. מולם, הנה הסעיפים שאתם צריכים לדרוש בכתב:

• התאמת רמת האבטחה לסיווג המאגר. אם המאגר שלכם ברמת אבטחה בינונית או גבוהה — הספק חייב לעמוד באותה רמה. אל תניחו; בדקו לאיזו רמה המאגר שייך במדריך רמות האבטחה של התקנות.
• SLA לדיווח על אירוע — בשעות, לא בימים. דרשו התחייבות מספרית: תוך כמה שעות מגילוי אירוע אבטחה הספק מודיע לכם. אם המאגר שלכם ברמה בינונית/גבוהה, החובה שלכם מול הרשות היא לדווח מיד — ואתם לא יכולים לעמוד בה אם הספק ״שכח״ לספר לכם.
• שקיפות קבלני משנה. הספק חייב לומר לכם על מי הוא נשען (אירוח, גיבוי, שליחת מיילים) ולהחיל עליהם תנאים זהים. ספק שלא יודע לומר מי קבלני המשנה שלו — לא יודע איפה המידע שלכם.
• מחיקה בסיום ההתקשרות — עם אישור בכתב. לא ״נמחק כשנספיק״, אלא התחייבות למחיקה תוך פרק זמן מוגדר ומתן אישור מחיקה (deletion certification) חתום.
• מיקום ואזור אחסון המידע. באיזו מדינה יושבים השרתים? העברה לחו״ל כפופה לתקנות ההעברה — הספק חייב לדעת לענות.

הרשות כבר בודקת: מבצע האכיפה בסחר האלקטרוני

זו לא תיאוריה. בדצמבר 2025 הרשות להגנת הפרטיות פתחה מבצע פיקוח רוחב — הראשון מאז כניסת תיקון 13 לתוקף — בחמישה מגזרים, ובהם חברות סחר אלקטרוני. לפי דיווח גלובס (30.12.2025), בין ההפרות שנבדקו במבצע: מדיניות פרטיות חסרה או מיושנת, מנגנוני עוגיות והסכמה לא תקינים, אבטחה חלשה — ובמפורש, היעדר הסכמי עיבוד נתונים מול ספקים. במילים אחרות: הרשות מגיעה, שואלת ״איפה ה-DPA שלכם מול ספק הענן?״ — וסעיף שהיה נראה כמו פורמליות משפטית הופך פתאום לחשיפה לעיצום.

כדי לעמוד בביקורת כזו, מה שהמפקחים רוצים לראות הוא מסלול ביקורת (audit trail) מסודר: רשימת כל המחזיקים/מעבדים שלכם, ה-DPA החתום מול כל אחד, ותאריכי הסקירה התקופתית. זה נבנה ישירות על גבי מיפוי מאגרי המידע — אי אפשר לנהל DPA-ים לספקים שלא מיפיתם. מיפוי המאגרים הוא הבסיס; טבלת הספקים וה-DPA-ים היא השכבה שמעליו.

דגלים אדומים: מתי לעצור ולא לחתום

בליווי לקוחות אנחנו רואים שלושה סימנים שכמעט תמיד מעידים על ספק שלא בשל להחזיק מידע רגיש — ושכדאי לפחות לעצור ולחשוב לפני שממשיכים איתו:

• הספק מסרב לחתום על DPA — או ״מבטיח״ בעל פה שהכול מאובטח אבל לא מוכן להתחייב בכתב. אם אין התחייבות חוזית, אין לכם דרך לעמוד בתקנה 15, ואין לכם על מי לחזור אם קורה אירוע.
• הספק לא יודע לומר איפה המידע יושב — באיזו מדינה, אצל איזה ספק אירוח, מי קבלני המשנה. ספק שלא יודע איפה הדאטה שלכם — לא יכול להגן עליה, ובוודאי לא לדווח לכם בזמן.
• אין התחייבות למחיקה בסיום — כשאתם עוזבים, המידע נשאר אצל הספק ״עד שיתפנו״. מידע שנשאר אצל ספק לשעבר הוא חשיפה מתמשכת שאתם עדיין אחראים לה.

צ׳קליסט ה-DPA בן 12 הסעיפים

זו הרשימה המעשית שאפשר להצמיד לכל התקשרות עם ספק ענן או SaaS. חוזה עיבוד תקין מכסה את כל 12 הסעיפים — ובאינפוגרפיקה למטה הם מסודרים לצילום מסך ושליחה.

1. סוגי המידע והמטרות — אילו נתונים הספק מקבל ולאילו מטרות בלבד.
2. היקף העיבוד — אילו פעולות מותר לספק לבצע במידע, ואילו אסורות.
3. רמת אבטחה תואמת — הספק עומד ברמת האבטחה של המאגר (בינונית/גבוהה) לפי התקנות.
4. הצפנה — במנוחה (at rest) ובתעבורה (in transit).
5. בקרת גישה וסודיות עובדים — הרשאות מינימליות והחתמת עובדי הספק על סודיות.
6. SLA לדיווח על אירוע אבטחה — לוח זמנים מספרי בשעות מרגע הגילוי.
7. שקיפות קבלני משנה — רשימה, והחלת תנאים זהים על כל קבלן משנה.
8. מיקום ואזור אחסון — המדינה/region שבו יישמר המידע, ותאימות לתקנות ההעברה.
9. דיווח תקופתי — דיווח של הספק, לפחות שנתי, על עמידה בהתחייבויות.
10. זכות ביקורת/פיקוח — יכולתכם לבקש אסמכתאות (הסמכות, דוחות) ולבצע בקרה.
11. מחיקה/החזרה בסיום עם אישור — לוח זמנים למחיקה ומתן deletion certification.
12. שילוב בנוהל האבטחה שלכם — הוראות ה-DPA משוקפות בנוהל האבטחה של המאגר.

צ׳קליסט ניקוי לספקים הקיימים — לשבוע הזה

רוב העסקים לא מתחילים מדף חלק — יש להם כבר עשרה, עשרים או חמישים ספקים פעילים בלי DPA. הנה סדר הפעולות לניקוי המצאי הקיים, בלי לנסות לבלוע הכול בבת אחת:

1. הוציאו רשימת ספקים. כל שירות חיצוני שנוגע במידע לקוחות — ענן, SaaS, לשכת שכר, ספק דיוור, קבלני פיתוח. אם יש לכם מיפוי מאגרים, שלפו אותו משם.
2. תעדפו לפי רגישות. סמנו קודם את הספקים שנוגעים במידע ברגישות מיוחדת (רפואי, פיננסי, ביומטרי) או במאגרים גדולים — שם החשיפה הגבוהה ביותר.
3. לענקיות — אספו את ה-DPA הקיים. הורידו/הצמידו את ה-DPA הסטנדרטי של AWS/גוגל/מיקרוסופט, ודאו הגדרת region, ותייקו.
4. לספקים הקטנים — שלחו את הצ׳קליסט. בקשו DPA חתום שמכסה את 12 הסעיפים. אין להם נוסח? שלחו נוסח משלכם.
5. בנו את טבלת המסלול. ספק, סוג המידע, רמת אבטחה, סטטוס DPA, תאריך חתימה, תאריך סקירה הבא — זה המסמך שהמפקח יבקש.
6. קבעו סקירה שנתית. תזמנו תזכורת לבחון מחדש את ההתקשרויות ולעדכן DPA-ים אחת לשנה — כפי שתקנה 15 מצפה.

השורה התחתונה

תיקון 13 לא שינה את העובדה שהמידע שלכם יושב בענן — הוא שינה את המחיר של ההתעלמות מכך. הספק הוא מחזיק; אתם נשארתם בעל השליטה, והאחריות המשפטית לא הועברה יחד עם הקבצים. מול הענקיות העבודה פשוטה: קבלו את ה-DPA, הגדירו region, תעדו. מול ה-SaaS הישראלי הקטן העבודה אמיתית: דרשו בכתב את 12 הסעיפים, או אל תתקשרו. וכשהרשות תדפוק בדלת — כמו שכבר עשתה בסחר האלקטרוני — התשובה ״יש לנו רשימת ספקים, DPA חתום מול כל אחד ותאריכי סקירה״ היא ההבדל בין ביקורת שגרתית לבין עיצום כספי.

*האמור במאמר זה הוא מידע כללי בלבד ואינו מהווה ייעוץ משפטי מחייב. ניסוח הסכם עיבוד נתונים והתאמתו לרמת האבטחה של המאגר תלויים במאפייני הארגון והמידע, ומחייבים בחינה פרטנית.*