ניהול שינויים רגולטוריים: להסתגל לשינויים בחכמה

כשהרגולציה משתנה, המסגרת שלכם לא אמורה להישבר

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

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

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

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

לכן השאלה החשובה ל-CISOs היא לא רק: האם אנחנו עומדים בדרישות היום?

אלא: אם הרגולציה תשתנה מחר, כמה ממסגרת האבטחה שלנו נצטרך לבנות מחדש?

עיקרון 1: לבנות סביב אבטחה, לא סביב הרגולציה

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

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

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

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

מודל עמיד יותר מפריד בין דרישת האבטחה לבין הדרישה הרגולטורית.

לדוגמה, הארגון יכול להחזיק בקרה פנימית אחת לניהול חולשות שמגדירה:

• בעלות ואחריות
• זיהוי חולשות
• תיעדוף מבוסס סיכון
• ציפיות לתיקון
• טיפול בחריגים
• דיווח
• דרישות ראיות

לאחר מכן ניתן למפות דרישות רגולטוריות שונות לאותה בקרה.

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

רגולציות שונות מתכנסות לעיתים קרובות לתוצאות אבטחה דומות. בניתוח החוצה-רגולציות שלהם, Canavese ואחרים מתמקדים במפורש בתרגום דרישות משפטיות לתוצרים מעשיים כמו בקרות אבטחה, אילוצים ארכיטקטוניים ותהליכים ארגוניים.

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

רק הפער שנותר צריך ליצור עבודה חדשה.

עיקרון 2: להפוך את המיפוי לברור ומפורש

כדי שהמודל הזה יעבוד, הקשר בין בקרות לדרישות רגולטוריות לא יכול להתקיים רק בגיליון אקסל של מישהו או בידע הארגוני הלא-מתועד.

הוא צריך להיות מפורש.

לחבר דרישות לבקרות

מסגרת ה-security-by-design של Akinsanya מ-2025 כוללת רכיב ייעודי למיפוי תאימות, שנועד לחבר בקרות אבטחה עם דרישות רגולטוריות. המודל מדגיש עקיבות דו-כיוונית, שמאפשרת לארגון לראות גם אילו דרישות רגולטוריות נתמכות על ידי בקרה וגם אילו בקרות תומכות בדרישה מסוימת.

העקיבות הזו הופכת לחשובה במיוחד כאשר הרגולציה משתנה.

לעקוב אחרי מסלול השינוי

נניח שלארגון כבר יש בקרה לתגובה לאירועים. תיקון רגולטורי חדש מציג מועד דיווח קצר יותר.

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

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

בלי עקיבות כזו, אפילו תיקון רגולטורי קטן יכול להפוך לתרגיל גילוי כלל-ארגוני.

עיקרון 3: לתכנן לפי הפער

המטרה של ניהול שינויים רגולטוריים היא לזהות את ה-delta: מה באמת השתנה בין המסגרת הנוכחית של הארגון לבין הדרישה החדשה.

זה נשמע פשוט, אבל זה דורש מסגרת שתוכננה לכך.

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

אותו עיקרון חל על כמה רגולציות.

Canavese ואחרים טוענים שיש לראות חקיקת סייבר כמערכת מקושרת ולא כאוסף של משטרים נפרדים. הניתוח שלהם בוחן במפורש כיצד ניתן לטפל בחובות חופפות בדרכים שנמנעות מכפילות.

מה באמת צריך להשתנות?

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

בדרך כלל נקבל שלוש קבוצות:

1. כבר מכוסה:
   הבקרה הקיימת והמדיניות התומכת כבר עומדות בדרישה.
2. מכוסה חלקית:
   הבקרה הקיימת רלוונטית, אבל פרמטר, נוהל, דרישת ראיות או היקף צריכים להשתנות.
3. לא מכוסה:
   הרגולציה מציגה חובה חדשה באמת שדורשת בקרה חדשה או הרחבה משמעותית של בקרה קיימת.

רק הקטגוריה השלישית אמורה בדרך כלל לדרוש תכנון או יישום נוספים של בקרות.

לשמור על ליבת האבטחה יציבה

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

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

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

הגמישות הזו חשובה כאשר דרישות משתנות.

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

שינויים כאלה צריכים להיות אפשריים בלי לערער את תוכנית האבטחה כולה.

ארכיטקטורת האבטחה צריכה לספק המשכיות. השכבה הרגולטורית צריכה לספק יכולת הסתגלות. 

לבנות פעם אחת, למפות לרבים: איך CISOteria עושה את זה

CISOteria בנויה סביב מבנה תאימות משותף, במקום להתייחס לכל מסגרת כאל פרויקט נפרד.

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

גם המדיניות מחוברת למסגרות ולבקרות. כאשר דרישה רגולטורית משתנה, ה-Cyber OS של CISOteria מתעדכן ומציג אילו מדיניות מושפעות מהשינוי, כך שהצוותים לא צריכים לעבור מחדש על כל ספריית המדיניות.

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

במקום לבדוק מחדש את כל תוכנית התאימות, הצוותים יכולים לראות איפה נדרשת פעולה, מה צריך לעדכן או להשלים, ואילו בקרות ומדיניות עדיין תקפות.

סיכום: לבנות לשינוי

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

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

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

המטרה היא לא רק לעמוד ברגולציה שקיימת היום, אלא לבנות מסגרת שיכולה להתאים את עצמה גם לרגולציה שתגיע מחר.

לקריאה נוספת

פוסט זה מבוסס על תובנות וניתוחים מן המקורות הבאים:

• Akinsanya, Ayokunle. "Security by design: a risk-based framework for cybersecurity compliance and critical infrastructure protection." International Journal of Information Security 24.6 (2025): 234. 

https://doi.org/10.1007/s10207-025-01155-4   

• Canavese, Daniele, et al. "Uncovering challenges of cybersecurity cross-regulation in EU legislation." Information and Software Technology (2026): 108033. 

https://doi.org/10.1016/j.infsof.2026.108033