כיצד סעיף 35 כותב מחדש את הכללים בנוגע לדליפות מידע אישי - ומי באמת משלם את המחיר?
זה כבר לא מספיק לשמור על ציות ברקע. מאז שנכנסה לתוקף תקנה (EU) 2024/2690, סעיף 35 של NIS 2 מבטל את טלאי התקנות הלאומיות השונות - וקובעות את אותו רף גבוה לכל ארגון, ללא קשר לתעשייה או למיקום. הפרת מידע אישי נשפטת על פי ספר חוקים אחד; עליכם להראות שתגובתכם מבוססת ראיות, מסונכרנת בין שכבות המשפט, ה-IT והניהול, ומסוגלת לעמוד תחת בדיקה ישירה של רואה חשבון. אם אתם מאמינים ש"זו רק בעיה של ה-IT" או חושבים ששרשור דוא"ל שמציל פנים יכסה את האחריות של הדירקטוריון שלכם, המשטר החדש מוכיח אחרת.
כיום, תיעוד חסר ברישום אירועים מסתכן באותה בדיקה - וקנס - כמו כשל אבטחה טכני.
מה שהשתנה הוא לא רק הקצב, אלא גם הציפייה: ראיות לפני מומחיות, והדגמה של הדירקטוריון לפני פתרון עוקף במשרד. בעבר, ארגונים רבים חיכו לדחיפה של הרגולטור המקומי, ואז מיהרו להפיק פרוטוקולי ישיבות או יומני ביקורת לאחר מעשה. כעת, אם אינכם יכולים להראות פעולה משותפת ניתנת להוכחה ומתועדת על ידי המערכת, החל מגילוי ועד לסגירת עסקה ברמת הדירקטוריון, פער הראיות שלך הפך לפרצה, והאכיפה מהירה. זו לא רק תיאוריה: בשנה האחרונה, למעלה מ-40% מהקנסות בגין הפרות מידע אישי גדולות באיחוד האירופי ציטטו מעורבות לא מספקת של הדירקטוריון, ולא רק חסרות ניירת IT.
המציאות החדשה? "סביר" אינו נקבע על ידי כוונה אלא על ידי לוחות זמנים של הוכחות מוכנות לביקורת, מסירות ותוצאות. אם יש פער בתהליך האירוע, אם התפקידים מעורפלים, או אם ראיות שנרשמו תקועות בדוא"ל במקום במערכת, הקנס יוטל למעלה. עבור דירקטוריונים, פקידי הגנה על מידע והנהלת ה-IT כאחד, סעיף 35 הפך את המוכנות לפריצות לספורט קבוצתי שבו אף אחד לא יכול לצפות מהיציע.
מדוע "כשל בתהליך" נחשב כעת מבחינה חוקית לדליפת נתונים - ומה המשמעות של זה עבורך?
לפי סעיף 35, החמצת מועד אחרון להודעה, יומן לא שלם או אירוע לא מתועד מהווים כעת בעצמם הפרה חייבת בדיווח של ספר החוקים-לא עוד עניין צדדי. זה מעלה את הרף: לא רק האבטחה הטכנית חשובה, אלא גם המשמעת התפעולית שלכם - המעקב המפורט והחי של החלטות, ביקורות ואישורים.
כישלון ברישום, כישלון בשמירה או כישלון בהקצאה - שרשרת האמון שבורה, לא משנה כמה קטן התיקון הטכני.
למה? כי הסיכון האמיתי בנוגע למידע אישי אינו טמון רק בפריצה או בחשיפה מקרית, אלא בנקודה העיוורת של הארגון. תקרית "הושלמה", שבוצעה במהירות ללא ייחוס מלא או ראיות עם חותמת זמן, מהווה כעת את האינדיקטור הראשון להזנחה של הרגולטור. אם לא ניתן למפות אותה משלב הגילוי ועד לסגירת העניינים, ואם הדירקטוריון אינו יכול להראות בזמן אמת היכן החל והסתיים הפיקוח שלו, אי-ציות אפוי ברישום התאגידי.
עבור אנשי מקצוע - משפטיים, ציות ו-IT - המסר בוטה. פתקים מדור קודם, שיחות לא רשמיות או "חריגים" ספציפיים לתחום שיפוט הם פחות מחסרי ערך: הם יוצרים ראיות לחוסר תשומת לב. במקום זאת, יומני עבודה משותפים, זרימות עבודה ניתנות לביקורת ותזכורות מונחות מערכת הפכו לבסיסמנהלים אחראים כעת ישירות להוכחה שכל הפרה, ללא קשר לתוצאה, טופלה באמצעות תהליך שעמד בבדיקה - ללא יוצאים מן הכלל.
מה המחיר של טעות זו? קנסות שכבר אינם מכוילים רק על ידי רישומים שאבדו, אלא נובעים לעתים קרובות מפערים במסירה, הסלמה שלא אושרה, או אי עדכון יומן הלקחים הסופי. שיטתי את תהליך האירועים שלך עכשיו, אחרת ייתכן שההפרעה הבאה בהודעה תהיה זו שתזרז בדיקה מלאה. חקירת ציות.
שלטו ב-2 שקלים ללא כאוס בגיליונות אלקטרוניים
מרכז סיכונים, אירועים, ספקים וראיות בפלטפורמה אחת נקייה.
כיצד פרגמנטציה מעמידה את הארגון שלך בסיכון ישיר לעונשים?
פרצות מידע אישי אינן נעצרות בגבולות העיר שלך - וכך גם פעולות רגולטוריות. תחת סעיף 35, רגולטורים המחפשים סיבה חופרים במהירות בכל פיצול של תגובה, תפקיד או יומןחלפו הימים שבהם "סיפור טוב" באירלנד היה יכול לתקן פער בניירת בגרמניה. אם תהליך הפריצה שלך משאיר יומני רישום או פעולות מפוזרים על פני מחלקות או תחומי שיפוט, למעשה הכפלת את החשיפה שלך.
כל עיכוב שמקורו בבלבול בבעלות או במסירה ידנית מהווה סיכון תאימות ממשי כמו ההתקפה הראשונית.
למה מצפים רואי החשבון כעת? ציר זמן: מי ידע, מי פעל, מי חתם ומתי. רישום זה חייב לקשור כל טריטוריה, יחידה עסקית ובעל עניין משפטי לזרם אחד - ללא פיצולים, ללא ענפים חסרים. ברגע שאירוע חוצה גבולות - של קו עסקי או מדינה - הנטל הוא לשמור על דיווח מקיף ויחיד של גילוי, הודעה וסגירה. כל דבר פחות מזה מזמין גם החמצת מועדים וגם גילויים סותרים, מה שמכפיל את הסכנה הרגולטורית.
רוב העיכובים בתגובה לפריצות נובעים מתפקידים לא ברורים, רשומות לא מקוונות ומעקב מיותר. פלטפורמות כמו ISMS.online חושפים, באמצעות נתוני אירועים אמיתיים, שיותר ממחצית מההאטות במחזור חיי האירועים נובעות מתהליכים ידניים מרובי בעלים (https://iw.isms.online/incident-management-platform). העלות? ימים שאבדו, חקירות שהופעלו, קנסות שהוסיפו - לא בגלל כשל טכני, אלא בגלל עיכוב תפעולי.
כדי לשבור את השרשרת הזו:
- הקצו מנהלי אירועים ברורים ורב-תחומיים כבר מההודעה הראשונה.
- השתמש ביומן שעוקב אחר כל מסירה עסקית בכפייה.
- אוטומציה של תזכורות ודרישה של קבלה/אישור בכל שלב.
- ארכיון נתיחה שלאחר המוות כאופציה חובה, לא אופציונלית, עם גישה הן למערכות מידע והן למשרד המשפטי.
שלטו במכניקות האלה, ובמקום לכבות שריפות בקצב של הרגולטור, תוכלו להתאים את כלל המקור היחיד של סעיף 35 לכל פעולה, בכל פעם.
כיצד נראית "הטמעת" סעיף 35? משמעת, ראיות וניהול מועדים
לא מספיק להיות בעל פוליסה; עליך להניע אותה. סעיף 35 דורש שגרות תגובה לאירועים חוצות-צוותים שמשאירות עקבות ניתנות לביקורת - שחקנים אמיתיים, מועדים נוקשים וקישורי ראיות חייםהקצאת מחלקה אינה מספיקה; כעת, יש לקשור אנשים ספציפיים לכל שלב, כאשר הראיות ממופות בזמן אמת.
מועדים אחרונים - הידוע לשמצה של 24 שעות ביממה, 2 שקלים ו-72 שעות. GDPR שעונים - נאכפים לא על ידי תקווה, אלא על ידי טכנולוגיה (https://iw.isms.online/policy-documentation). בכל אירוע - גילוי תחילה, הסלמה, מסירה לדירקטוריון, סגירה - אתם זקוקים ליומן מבוסס תפקידים עם חותמת זמן, אחרת הרגולטורים יתייחסו לכל פער כהוכחה להזנחה. תיעוד "כמעט בזמן", או התאמה לאחר מעשה, משאיר אתכם חשופים לחלוטין לאכיפה.
ארגונים המתעדים בזמן אמת, עם התראות מערכתיות לכל בעל עניין, עוברים ביקורות ונמנעים מקנסות - גם כאשר ההפרה עצמה מורכבת מבחינה טכנית.
עבור אלו הפועלים תחת מסגרת אחת, יש לדמות את השגרה של השנייה - צוותי GDPR צריכים להריץ תרגילים של 24 שעות ביממה, מפעילי NIS 2 צריכים להתאמן על מודל 72 השעות של GDPR. הצוותים המוכנים ביותר מנרמלים חזרות על אירועים בין המחלקות, כך שכל חוליה חלשה מזוהה ונאטמת לפני שמתרחשת פרצה.
מינוף שיטות העבודה המומלצות כיום פלטפורמות לניהול אירועים ששומרות על ראיות זרימת עבודה ניתנות לביקורת, להקצות כל גורם, ולהפוך תזכורות לביקורות לאוטומטיות לפני שמגיעים מועדי הציות (https://iw.isms.online/incident-management-platform). בעזרת מערכת כמו ISMS.online, המשימות ננעלות במקור, וחבילת הביקורת שלך הופכת לשיקוף ישיר של הדרישה החוקית של סעיף 35.
טבלת גישור לתקן ISO 27001: מיפוי התחייבויות סעיף 35 לבקרות תפעוליות וביקורת
להלן, דרישות רגולטוריות מרכזיות הופכות לפעולות תפעוליות ברורות ISO 27001 הפניות לבקרה:
| תוֹחֶלֶת | פלטפורמת תפעול | ISO 27001 / נספח א' |
|---|---|---|
| בעל הפרה אישי ייעודי | זרימת עבודה של מדיניות עם זיהוי אישי | א.5.24, א.8.13 |
| צילום בזמן שביל ביקורת של כל צעד | תפקיד רשום במערכת + שרשרת פעולות | א.5.27, א.8.13 |
| התראה דו-כיוונית מרובת מסגרות | סנכרון רשימת בדיקה מבוססת כללים | א.5.31, א.5.24 |
| הוכחת סגירה בתוספת אישור | "בנק ראיות" של הפלטפורמה מסונכרן עם SoA | א.5.35, א.8.13 |
מערכת ISMS בוגרת מציבה את הבדיקות התפעוליות הללו במרכז, ומאפשרת לך ליצור הצהרת תחולה (SoA) או חבילת מבקר בלחיצה אחת בלבד עבור כל סקירה אפשרית.
היו מוכנים ל-2 שקלים מהיום הראשון
הפעל עם סביבת עבודה ותבניות מוכחות - פשוט התאם אישית, הקצא וצא לדרך.
מדוע ציות מודרני דורש "מעברי חציה חיים" - וכיצד הם פועלים?
מדיניות של תיבות סימון מוסיפה ערך אפס אם היא לא ממופה לפעולות בזמן אמת. בסביבת הפרצות של ימינו, "שיטות עבודה מומלצות" הן מה שממופה, לא רק מה שכתוברגולטורים, וכיום רוב רואי החשבון החיצוניים, מבקשים לבדוק: עבור כל הודעה, האם הטריגר קשור לבקרה? האם האישור נקלט באמצעות ייחוס? ללא טבלת מיפוי ו... ראיות חיות קישורים, התהליך שלך בלתי נראה - ולכן אינו תואם לתקנות.
אם לא ניתן לחשוף את הראיות במעקב חי, זה כאילו הן לא קיימות עבור רואי חשבון ורגולטורים כאחד.
קחו בחשבון את האירוע הטיפוסי: גילוי, הקצאת בעלים ראשונית, טיימר של 24 שעות, הסלמה ל-DPO, סגירה ובדיקה. בכל נקודה, עליכם לתעד פעולות במערכת ה-ISMS שלכם עם בקרות ממופות-A.5.24 לדיווח, A.8.13 לראיות, A.5.31 להודעה, A.5.35 לסקירות.
כך נראה "מעבר חציה חי":
| הדק | עדכון סיכונים | קישור בקרה / SoA | ראיות שנרשמו |
|---|---|---|---|
| זוהתה פרצה | רישום סיכונים הערות | A.5.24 / A.8.13 | גילוי + בעלים שהוקצה |
| מועד אחרון של 24 שעות התקרב | אירוע טיימר | 5.27 א' (2 ₪),… | מתכנן התראה/סיבות |
| הסלמה ל-DPO | רשומת מסירה | A.5.31 / A.8.13 | אישור DPO |
| התקרית נפתרה | יומן סקירת מועצת המנהלים | A.5.27 / A.5.35 | לקחים שנלמדו + סיום |
הפעלת אלה כחלק ממחזור רציף - אוטומטי על ידי מערכת ניהול האירועים שלכם - הופכת כל אירוע פריצה להזדמנות לחוסן פרואקטיבי. ארגונים בעלי חשיבה קדימה מעדכנים כל פעולה, בכל פעם, כך שההכנה לביקורת או סקירה רגולטורית היא תוצר לוואי של העבודה היומיומית, ולא טלטלה ימים לפני מועד אחרון.
האם נתיב הביקורת שלך הוא בזמן אמת, חלק ומונע ראיות - או שהוא נמצא בסיכון ל"ציות לא פעיל"?
"ציות" כבר אינו קשור רק להפרה עצמה. מדובר ב מוכנות, רישום, סקירה ושיפור בכל תגובהפערים, רישומים מפוזרים, יומני רישום ידניים - אלה הם הנתיב המהיר לקנסות. בטוח יותר, וחכם יותר, לטעות בשקידה קיצונית. אף אחד לא נענש על מעקב רב מדי; כמעט כל הקנסות הגדולים מציינים פערים בתיעוד (https://iw.isms.online/incident-management-platform).
כל לולאה סגורה בנתיב הביקורת שלך - גילוי, תפקיד, ראיות, סקירה - מכפילה את הסיכוי שלך להימנע לא רק מקנסות, אלא גם מפגיעה בתדמית.
כיום, קציני ציות ומנהלי IT יכולים למנף פלטפורמות ISMS אשר רושמות אוטומטית כל שלב ומציעות ציר זמן אלקטרוני ובלתי משתנה - בין תפקידים טכניים ולא טכניים. המודל פשוט: ככל שתפגינו יותר לולאות משוב, כך תזכו ביותר קרדיט ואמון, הן מצד מבקרים והן בתוך חדר הישיבות. סקירות לאחר המוות, העלאת ראיות ואישורי הנהלה הופכים כל אחד לרישומים שגרתיים - מה שמכפיל את הביטחון ומפחית באופן דרסטי את העלות של... הכנת ביקורת.
במקום לחשוש מחקירה רגולטורית, ארגונים מנוסים מטפלים בכל דבר תגובה לאירוע כדלק לשיפור לטווח ארוך. ועם אוטומציה, התאימות שלכם לא עומדת במקום - היא מתפתחת כדי לעמוד בתקן לפני שהרגולטורים יכריחו אתכם להדביק את הפער.
כל 2 השקלים שלך, הכל במקום אחד
מסעיפים 20-23 ועד תוכניות ביקורת - להפעיל ולהוכיח עמידה בתקנות, מקצה לקצה.
תאימות מבוססת ראיות: בניית לולאת אמון, לא רשימת בדיקה
מובילי שוק מוגדרים לא על ידי מדריכי תהליכים, אלא על ידי יומני רישום חיים ואדפטיביים המשלבים ראיות, למידה קבוצתית ופיקוח על הדירקטוריוןלקוחות ISMS.online שמעבירים את רמת הציות מ"מעבר ביקורת" ל"הוכחת שיפור יומי" רואים את העלות, זמן ההתאוששות ושיעורי התקריות שלהם מצטמצמים (https://iw.isms.online/case-studies/). יומני ביקורת אינם רק לוחות מחוונים משותפים הגנתיים המעניקים לכל דירקטור או מנהל את התצוגה בזמן אמת שהרגולטורים מצפים לה.
ציות הוא פחות יעד ויותר נקודת שיגור - כזו שאתה מאפס ומחזק אחרי כל פרצה, כל תרגיל.
לקוח המטפל בנתוני בריאות רגישים באיחוד האירופי ניהל תרגילי הפרות תחום שיפוט חוצי-תחומי ב-ISMS.online. כל מטלה, פרסום ראיות, הודעה ושלב סקירה תועדו באופן מרכזי; כל לקח היה זמין באופן מיידי למחזור הבא. כאשר הגיעו המבקרים, הדירקטוריון הציג דוח פשוט: ללא חריגים, ללא חוליות חסרות, ללא פאניקה. התוצאה? אפס ממצאים, אמון לקוחות משופר, ודירקטוריון שצוין כ"מוכן לשוק" לגל הבא של ציפיות רגולטוריות.
כדי להגיע לרמה זו: מרכזו את נתיב הביקורת שלכם, אוטומצו מסירות, הניעו ביקורות ניהוליות ועדכנו את מדריך האירועים שלכם לאחר כל פרצה אמיתית או מדומה. כך, כאשר מגיע האתגר או המשטר הבא, החוסן כבר ימשיך לפעול כרגיל.
מה הלאה: מסעיף 35 לספקטרום החוסן המלא - האם המערכת שלכם מוכנה?
סעיף 35 הוא הצצה לסיומו, לא הסוף. עם DORA, מסגרות מגזריות והמתפתחות חוק AI של האיחוד האירופי, תאימות מבוססת ראיות ופלטפורמה היא כבר הציפייהמנדטים חדשים ירבו לוחות זמנים, העברות ותחומי אחריות חופפים. בסופו של דבר, לא אמביציה אלא חזרתיות והוכחות הן אלו שמגדירות "הטוב ביותר מסוגו".
היכולת שלך להציג שיפור בזמן אמת - תרגילי שיפור רבעוניים, עדכון ספרי הכנה, סקירות דירקטוריון - היא כבר המבדיל.
בנו קצב של סקירה, רישום שיפורים וסימולציה של איום הבא במערכת ה-ISMS שלכם עוד היום (https://iw.isms.online/policy-documentation). כעת מעקב אחר הדירקטוריונים מתבצע לפי הפעולות שהם מאשרים, ולא לפי מצגות שהם צופים בהן. היו מוכנים לעגן כל דיון בסיכונים אסטרטגיים בראיות אמיתיות - הדגימו את יומני התרגילים שלכם ואת מחזורי השיפור שלכם כמערכת חיה.
עסקים עמידים ומוכנים לביקורת קושרים בונוסים ואסטרטגיית דירקטוריון לראיות - ולא לשאפתנות. הם מדמיינים מחזורי תאימות כבלחי ביצועים, ולא כאבי ראש שנתיים. והשוק צופה: קונים ומשקיעים מוסדרים מעריכים ארגונים שממפים את איומי המחר לפני שהם נאלצים להגיב.
מודל ISMS.online: תאימות מתמדת, חוסן ניתן לביקורת, שיפור אמין
אף ארגון לא משיג חוסן באמצעות ניירת או זיכרון שרירים. בעידן הזה, תאימות פירושה מוכנות תמידית, שיטתית ועשירה בראיותמתהליכי עבודה של אירועים ועד חתימה של הדירקטוריוןISMS.online מספקת פלטפורמה מבוקרת ואמינה לאורך כל מחזור החיים - תגובה לאירועים, ניהול פרצות מידע אישי ושיפור מתמיד (https://iw.isms.online/incident-management-platform).
אירועים אינם חד פעמיים; מערכת הניהול שלכם חיה ונושמת עם כל אירוע. בין אם מדובר בעדכון סטטוס בקרה, הדרכת מנהל חדש או הטמעת משוב מביקורת, רישום הראיות המקוון של ISMS הוא חי, מאוחד וניתן לבדיקה על ידי כל רשות, בכל עת.
ארגונים שמקיימים תהליכי ציות בזמן אמת מראים את יכולתם לא בשאיפה, אלא בפועל. הוכחה אינה הנטל - היא המגן. כאשר סעיף 35 או גל החקיקה הבא יגיע, הצוות שלכם יוכל להצביע לא על כוונות טובות, אלא על תוצאות חיות.
מצוינות תפעולית לא נולדת לאחר מעשה; היא כתובה, יום אחר יום, ביומנים, סקירות ולוחות מחוונים חיים. כאשר הראיות שלך יכולות לנוע מהר כמו איומים, חוסן הוא אוטומטי.
שאלות נפוצות
מה מפעיל "הפרה הכרוכה בדליפת מידע אישי" לפי סעיף 35 לתקנת NIS 2?
כל אי עמידה בחובות הליבה של NIS 2 הגורמת לפגיעה במידע אישי - בין אם עקב אובדן, גישה בלתי מורשית או חשיפה בלתי חוקית - נחשבת כ"הפרה הכרוכה בפרצת מידע אישי" לפי סעיף 35. באופן מכריע, פרצה זו יכולה להיגרם לא רק על ידי מתקפות סייבר, אלא גם עקב תקלות בשגרת אבטחה, הודעות מאוחרות, הקצאת תפקידים לא ברורה, יומני רישום חסרים או תיעוד לא שלם. אם כשלים כאלה מובילים ישירות לפרצת מידע, הרשות המוסמכת של NIS 2 חייבת להעלות את האירוע לרשות הגנת המידע (DPA). חשיפה כפולה זו משמעותה... פערי ציות בתהליך, ניהול רישומים, או תגובה לאירוע לכפות על הארגון שלך את הדרישות הן של NIS 2 והן של GDPR בדיקה רגולטורית.
החמצת דד-ליינים, תפקידים מעורפלים או רישומים גרועים יכולים להפוך טעות שגרתית להפרה משפטית - ולשים את הצוות שלכם תחת זרקור של שני רגולטורים, לא רק אחד.
גורמים עיקריים להפרת רגולציה
- בקרות המחייבות NIS 2 שלא נבדקו, לא נבדקו או לא שלמות (למשל, פגיעויות שלא תוקנו או הערכות סיכונים שדלגו עליהן).
- איחור או חסר הודעות על אירוע-במיוחד אם לא נשלח בתוך חלון ה-24 שעות.
- אי הקצאת אנשים ששמם נקוב לצורך דיווח, הסלמה או תיעוד.
- הסתמכות על ראיות לא מובנות - גיליונות אלקטרוניים, יומנים מפוזרים, שרשראות דוא"ל.
- הזנחת תיעוד של "כמעט תאונות" ושל אירועים חוזרים ונשנים ברמה נמוכה.
רגולטורים, כולל ENISA, מתייחסים לפערים בתהליכים הגורמים לאובדן נתונים כאל הפרות בקנה מידה מלא – מה שמגביר את הדרישה לתאימות שיטתית המיוחסת לתפקידים.
כיצד סעיף 35 (שנים 2) וה-GDPR פועלים זה בזה בכל הנוגע להודעה ולקנס?
סעיף 35 משלב באופן הדוק את תקנות NIS 2 ואת ה-GDPR על ידי דרישה של הודעה כפולה מיידית אם פרצת מידע אישי נובעת מכשל ב-NIS 2. משמעות הדבר היא שאתם מחויבים להודיע לרשות המוסמכת ל-NIS 2 תוך 24 שעות ול-DPA תוך 72 שעות - כל אחת מהן באמצעות תהליכים וטפסים פורמליים. הרשויות מתאמות את החקירה שלהן, אך האכיפה והעונשים מתואמים: אם DPA מטילה עליכם קנס במסגרת תקנות ה-GDPR, רשות NIS 2 אינה יכולה להטיל גם קנס כספי על אותה הפרה, אם כי היא רשאית להוציא אזהרות או לחייב פעולות מתקנות.
תהליך ההודעה המשותפת, שלב אחר שלב
- 24 שעות: הודעה ראשונית לרשות 2 שקלים (גם אם העובדות אינן שלמות).
- 72 שעות: דוח מפורט ל-DPA תחת GDPR.
- חוצה גבולות?: כל רשויות השיפוט המושפעות מעורבות, מה שמוביל להרמוניזציה של ההודעות והרישומים שלכם.
- אין קנסות כפולים, אבל פיקוח מוגבר: סעיף 2 לחוק רשאי להורות על שינויים בתהליך, להשעות אישורים או לדרוש ביקורות חדשות, גם כאשר הקנס מגיע רק מרשות ההגנה על מידע (סעיף 2 לחוק רשאי, סעיף 35(4)).
רשויות מצפות לא רק להוכחה לפעולה, אלא גם להוכחה לארגון בזמן אמת המבוסס על תפקידים. אוטומציה ומשמעת תהליכים אינם "נחמדים" - הם כעת חובה.
מהו תהליך ISMS שלב אחר שלב לגילוי ודיווח על פרצות במסגרת סעיף 35 ותקנת ה-GDPR?
כדי להישאר תאימות ומוכנים לביקורת, מערכת ניהול האירועים (ISMS) שלכם חייבת לתאם בקפידה את התגובה ברגע שמתעורר חשד לפריצה - במיוחד כאשר מדובר בחשיפות תהליכיות:
זרימת עבודה שלבים לאירועים
- רישום אירועיםתיעוד מאובטח של הפרצה במערכת ה-ISMS שלך. תיעוד הזמן, המדווח, המערכות שנפגעו, ההשפעה ודירוג הסיכון הראשוני (ISO 27001: A.5.24, A.8.13).
- הפעלת זרימת עבודהאישור מראש של הטריגר ספרי התקריות עם חותמת זמן מדויקת והקצאה אישית לכל שלב.
- הודע לרשות 2 בניירות ערךיש להשתמש בפורטל הייעודי או בערוץ שנקבע במדינה תוך 24 שעות, ללא קשר למצב החקירה.
- הודע ל-DPAספקו את כל פרטי ההפרות וההקשר הנדרשים על פי GDPR תוך 72 שעות - כולל סוגי נתונים, מספר נושאי נתונים ואיומי תוצאה.
- הקצאת תפקידים בעלי שםיש לתעד בבירור מי אחראי על החקירה, התקשורת (פנימית וחיצונית) ופעולות הפחתה.
- לתקשר עם אנשים שנפגעואם ההפרה מהווה סיכון לזכויות נושא המידע, יש להודיע לו/לה באופן מיידי ולתעד את כל התקשורת.
- ריכוז רשומותמעקב אחר כל עדכון, שיחה, שינוי מערכת ופעולת הפחתה במערכת מאובטחת ועמידה בפני ביקורת (A.5.27, A.5.35).
- סקירה ושיפור לאחר האירועערכו מפגש על הפקת לקחים, קשרו ממצאים לעדכוני סיכונים ובקרה, ועדכנו את הצהרת הישימות (SoA) שלכם.
תמונת מצב של מעקב
| אירוע טריגר | עדכון סיכונים | הפניה לבקרה/SoA | ראיות שנרשמו |
|---|---|---|---|
| SOC מסמן גישה לא מורשית | הסיכון הסלים | א.5.24, א.8.13 | רישום אירועי ISMS |
| החמצת מועד אחרון של 24 שעות | אי-התאמה שהוגשה | A.5.35 | יומן ביקורת, התראות דוא"ל |
| הודעות שנשלחו לרשויות | האירוע נסגר | א.5.27, א.5.31 | יומני זרימת עבודה וסקירה |
רישום אירועים שנרשם במלואו, מיוחס לתפקידים ובלתי ניתן לשינוי הוא ההגנה החזקה ביותר שלך מפני סיכונים רגולטוריים וחשיפה לביקורת.
האם ניתן להטיל קנס גם במסגרת תקנת NIS 2 וגם במסגרת תקנת ה-GDPR על אותה הפרה - וכיצד מכוילים את העונשים?
סעיף 35(4) של חוק 2 ש"ח וה-GDPR מקדמים את עקרון "איסור סכנה כפולה" לקנסות כספיים על אותה הפרה. העונש של רשות המידע חוסם קנסות של 2 ש"ח במקביל עבור האירוע, אך רשות 2 ש"ח עדיין יכולה להטיל צעדים שאינם כספיים: אזהרות, תיקון חובה, השעיות וביקורות עתידיות מוגברות. העונשים תלויים בסיווג הישות שלך:
| ישות | קנס כספי מקסימלי | התייחסות משפטית |
|---|---|---|
| חִיוּנִי | 10 מיליון אירו או 2% מהמחזור הגלובלי | 2 שקלים / GDPR |
| חָשׁוּב | 7 מיליון אירו או 1.4% מהמחזור הגלובלי | 2 שקלים / GDPR |
- קנסות חמורים יותר כאשר אירועים אינם מדווחים, מועדים אחרונים מוחמצים, או רישומים אינם שלמים, מאחרים או ידניים.
- תיעוד שיטתי ותגובה מהירה ויסודית מפחיתים או מוקדמים באופן שגרתי את הסנקציות המקסימליות (Skillcast, 2025).
- פעולות שאינן כספיות - למשל, דרישה לביקורות חדשות או השעיית אישורים - הן תוספות נפוצות אם מתגלים כשלים בתהליך.
מה שחשוב ביותר הוא לא רק תיקון הפרצה, אלא כמה מהר, בשקיפות ובאופן שיטתי אתם מוכיחים את התהליך שלכם בעיני שתי הרשויות.
מה כוללת "חקירה מקבילה" טיפוסית לאחר הפרת סעיף 35?
אכיפה מודרנית כמעט תמיד מובילה לחקירה טכנית וגם לחקירה פרוצדורלית: רגולטורים דורשים לראות לא רק כיצד התרחשה ההפרה, אלא כיצד מערכת התגובה שלכם תפקדה בזמן אמת.
- פלטפורמות מטא: נקנס ב-91 מיליון אירו לאחר שהפרת אבטחה החמירה עקב התראות איטיות ומקוטעות ויומני רישום חסרים.
- טיק טוק: קיבל קנס של 530 מיליון יורו, בשילוב כשלים בהעברות עם חוסר ניהול רישומים שיטתי.
- וודאפון גרמניה: (45 מיליון אירו) צוטט בשל חוסר תאימות מתועדת לתהליכים חוצי גבולות והקצאה לקויה של תפקידי תגובה לאירועים.
בודק ביקורת חי מתמקד
- סקירה של כל מסירה - למי הוקצה מה ומתי.
- דרישה לרשומות זרימת עבודה בלתי ניתנות לשינוי, המיוחסות לתפקיד.
- בחינה מדוקדקת של כלים: גיליונות אלקטרוניים וקטעי דוא"ל מזמינים באופן עקבי בדיקות מעמיקות יותר.
- בחינת זרימת הנתונים הטכניים ושרשרת ההליכים - כאשר פערים "רכים" הוגדרו לממצאים חמורים.
בעולם הרגולציה של ימינו, הדבר הראשון שעולה בספק הוא הבהירות והשלמות של נתיב הביקורת שלכם - חסר הקשר או יומני רישום מאוחרים מהווים דגלים אדומים מיידיים לבדיקה כפולה.
אילו מסגרות וכלים שומרים עליכם עמידים ועמידים בתקנות לאחר סעיף 35?
- אוטומציה של אירועים: השתמשו במערכת ייעודית לניהול אירועים ורשומות המשלבת הקצאות תפקידים, התראות אוטומטיות, הסלמת זרימת עבודה ויומני רישום בזמן אמת הממופים ישירות לבקרות ISO 27001/נספח A ((https://iw.isms.online/incident-management-platform)).
- מִרכּוּז: אחסן את כל יומני האירועים, תהליכי העבודה והסקירות במיקום מרכזי ובלתי ניתן לשינוי - ללא קבצים מפוזרים או עקבות דוא"ל.
- מיפוי בזמן אמת: קשרו כל התחייבות רגולטורית לספרי ההפעלה התפעוליים שלכם ולהצהרת הישימות (SoA) לצורך עקיבות.
- תרגילים שגרתיים: סקירות רבעוניות של מחזורי "הפרות + הודעה", עדכון בקרות ונהלים תוך שימוש בתוצאות אמיתיות (ENISA, 2024).
- מטלה אישית: עבור כל שלב באירוע (גילוי, דיווח, תקשורת, סגירה), ציין את האדם האחראי, לא רק את המחלקה.
- שיפור מתמשך: ביקורות לאחר האירוע חייב לזרום ישירות לעדכוני SoA שלך ו ביקורות סיכונים, שמוכיח שאתה לומד ומסתגל.
גשר ISO 27001: ציפייה → תפיסת יישום → התייחסות לביקורת
| תוֹחֶלֶת | אופרציונליזציה | תקן ISO 27001/נספח א' |
|---|---|---|
| התראות רגולטוריות 24/72 שעות ביממה | אוטומציה של זרימת עבודה, מעקב אחר דד-ליינים | א.5.31, א.5.24, א.5.35 |
| נתיב ביקורת ספציפי לתפקיד | יומני רישום בלתי ניתנים לשינוי, כוח אדם שהוקצה | א.5.27, א.8.13 |
| מעורבות בסמכות כפולה | נתיב הראיות מתחבר ל-SoA | א.5.31, א.5.35 |
| לקחים שהופק, בקרות משופרות | סקירה מתועדת, SoA/רישום סיכונים | א.5.27, א.5.35 |
התקדמו על ידי הפיכת מערכות ה-ISMS שלכם לחזית הן של הגנה טכנית והן של חוסן פרוצדורלי - כך שכל הודעה, סקירה ומסירה כבר ממופות עוד לפני שמבקרים מבקשים.
קריאה לפעולה (CTA) בנושא זהות: עבור הנהלה, מנהלי סיכונים ובעלי מערכות ניהול מידע (ISMS), תאימות אמיתית לסעיף 35 אינה עניין של לעבור או להיכשל. זהו סימן ההיכר של מערכת שבה תהליך, ראיות ואחריות פועלים יחד כדי להפוך את המוניטין שלכם לניתן להגנה לפני שמשהו משתבש.
