מהו SoA בתקני ISO ואיך מחברים בין סיכונים, בקרות ו-Evidence
ה-Statement of Applicability, או בקיצור SoA, הוא אחד המסמכים המרכזיים במערכת ניהול אבטחת מידע לפי ISO/IEC 27001:2022.
המסמך מציג את הבקרות שהארגון בחר ליישם, את הסיבות לבחירה או להחרגה שלהן, ואת הקשר ביניהן לבין תהליך ניהול הסיכונים.
בפועל, ה-SoA הוא המסמך שמחבר בין סקר הסיכונים, תוכנית הטיפול בסיכונים והבקרות המיושמות בארגון.
מה כולל ה-SoA?
ה-SoA צריך להציג, לכל הפחות:
- אילו בקרות רלוונטיות לארגון
- אילו בקרות נבחרו ליישום
- מהי ההצדקה להכללת כל בקרה
- אילו בקרות הוחרגו ומדוע
- מהו סטטוס היישום
- היכן נמצאות הראיות ליישום
בגרסת ISO/IEC 27001:2022, ה-SoA מתייחס ל-93 הבקרות המופיעות ב-Annex A. עם זאת, הארגון אינו חייב להסתפק רק בהן, והוא רשאי לכלול גם בקרות נוספות ממקורות אחרים אם הן נדרשות לטיפול בסיכונים.
איך מכינים Statement of Applicability (SoA) בפועל?
בניית SoA מתחילה מהערכת הסיכונים ומתוכנית הטיפול בהם, ולא מרשימת הבקרות עצמה. הארגון בוחן אילו בקרות נדרשות כדי לטפל בסיכונים שזוהו, משווה אותן לבקרות ב-Annex A ומנמק אילו בקרות נכללות, אילו אינן רלוונטיות ומהו מצב היישום שלהן. התקן אינו מחייב שה-SoA ייראה בדיוק כמו Annex A, והוא יכול לכלול גם בקרות נוספות מעבר לנספח כאשר הן נדרשות לטיפול בסיכוני
בפועל, מומלץ לבנות טבלה שמאפשרת לעקוב אחר הקשר בין הסיכון, הבקרה והראיה:
| בקרה | סטטוס | נימוק | סיכון רלוונטי | Evidence / מקור ראיה |
|---|---|---|---|---|
| בקרת גישה | מיושמת | נדרשת להגבלת גישה למידע רגיש | גישה לא מורשית | מדיניות הרשאות / דוח הרשאות |
| בקרה שאינה רלוונטית | מוחרגת | אינה חלה על סביבת העבודה או ה-Scope | — | נימוק מתועד |
נימוק איכותי אינו צריך להסתפק ב-"רלוונטי" או "לא רלוונטי". לדוגמה, ניתן להסביר שבקרה נכללה משום שהיא מטפלת בסיכון שזוהה ב-Risk Assessment, או שהוחרגה משום שהתהליך או הטכנולוגיה שאליהם היא מתייחסת אינם קיימים בתוך ה-Scope של ה-ISMS.
מי אחראי על ה-SoA ומתי מעדכנים אותו?
ה-SoA הוא מסמך של מערכת הניהול ולכן חשוב להגדיר עבורו Owner, תהליך אישור ובקרת גרסאות. בפועל, הכנתו מערבת בדרך כלל את מנהל אבטחת המידע או ה-ISMS Owner, בעלי תהליכים רלוונטיים והנהלה בהתאם למבנה הארגון.
יש לבחון ולעדכן את המסמך כאשר חל שינוי מהותי בסיכונים, ב-Scope, במערכות, בספקים, בתהליכים העסקיים או בבקרות, וכן בעקבות ממצאי Audit או שינוי בתוכנית הטיפול בסיכונים. המאמר הקיים כבר מדגיש שה-SoA צריך להשתנות עם שינויים במערכות, בענן, בספקים ובסיכונים — ולכן הבלוק החדש משלים את ההסבר הזה בצורה טבעית.
בסופו של דבר, SoA טוב צריך לאפשר לעבור בקו ברור אחד:
- Risk
- Control
- Justification
- Implementation
- Evidence
למה ה-SoA חשוב?
ה-SoA מספק תמונה מרוכזת של מערך הבקרות הארגוני. הוא מאפשר להבין כיצד הארגון מתרגם סיכונים לדרישות יישומיות, ואילו אמצעים נבחרו לצמצום החשיפה.
המסמך חשוב במיוחד לצורך:
- הכנה למבדקי הסמכה ומעקב
- הצגת עקיבות בין סיכונים לבקרות
- ניהול פערים ותוכנית עבודה
- חלוקת אחריות בין בעלי תפקידים
- הצגת ראיות להנהלה, לקוחות ומבקרים
- בחינת התאמה לדרישות רגולטוריות וחוזיות
ה-SoA אינו רשימת סימון
טעות נפוצה היא להתייחס ל־SoA כאל טבלה טכנית שמטרתה לסמן “מיושם” או “לא מיושם”.
בפועל, מבקר מצפה לראות קשר ברור בין הבקרה לבין הסיכון שבגינו נבחרה. סימון של בקרה כמיושמת אינו מספיק אם אין מדיניות, תהליך, אחריות וראיות תפעוליות שתומכות בכך.
לדוגמה, אם הארגון מציין שבקרת גיבויים מיושמת, עליו להיות מסוגל להציג לא רק נוהל, אלא גם תוצאות גיבוי, בדיקות שחזור, טיפול בכשלים ועמידה ביעדי התאוששות.
מה נחשב SoA איכותי?
SoA איכותי צריך להיות:
- מעודכן בהתאם לשינויים בסיכונים ובמערכות
- תואם להיקף ה־ISMS
- מקושר לסקר הסיכונים ולתוכנית הטיפול
- ברור ביחס לסטטוס היישום
- מבוסס על ראיות
- מאושר ומנוהל תחת בקרת מסמכים
המסמך צריך להשתנות כאשר הארגון מכניס מערכת חדשה, עובר לענן, מחליף ספק, משנה תהליך עסקי או מזהה סיכון חדש.
מסיכון ועד לראיות יישום: כיצד נראה SoA אפקטיבי?
SoA איכותי אינו מסתיים בהחלטה איזו בקרה רלוונטית. הוא מאפשר ליצור רצף ברור בין הסיכון שזוהה, החלטת הטיפול, הבקרה שנבחרה, האחריות ליישומה והראיות שמוכיחות שהיא פועלת.
- Risk
- Control
- Owner
- Implementation
- Evidence
לדוגמה, כאשר הארגון מזהה סיכון של גישה בלתי מורשית למידע רגיש, עליו לקבוע אילו בקרות נדרשות לצמצום החשיפה, מי אחראי ליישומן, כיצד הן פועלות וכיצד ניתן לאמת את האפקטיביות שלהן.
ראיות מתאימות עשויות לכלול סקירות הרשאות, תיעוד של אישורי גישה, רשומות ניטור, טיפול בחריגות ותוצאות ביקורות.
כך ה-SoA משמש כלי עבודה לניהול סיכונים ולשיפור מתמשך, ולא רק מסמך המוגש במסגרת ביקורת.
טעויות נפוצות בניהול SoA
בין הפערים הנפוצים ניתן למצוא:
- העתקת SoA מארגון אחר
- הכללת כל הבקרות ללא ניתוח אמיתי
- החרגת בקרות ללא נימוק מספק
- חוסר התאמה בין ה-SoA לסקר הסיכונים
- סטטוס יישום שאינו נתמך בראיות
- אי־עדכון המסמך לאחר שינוי טכנולוגי או ארגוני
- שימוש במסמך ישן המבוסס על גרסת 2013
ארגונים שעדיין משתמשים במסמך SoA המבוסס על ISO/IEC 27001:2013 צריכים לבצע התאמה למהדורת 2022. ההתאמה כוללת בדיקה של כל 93 הבקרות ב-Annex A, עדכון ההצדקות להכללה ולהחרגה, בחינת סטטוס היישום וקישור לראיות מתאימות.
פערים אלה עלולים להוביל לממצאים בביקורת, אך חשוב מכך – הם עלולים להעיד שמערכת ניהול הסיכונים אינה משקפת את מצב הארגון בפועל.
לביצוע התאמות ומעבר לANNEX עדכני – דברו איתנו
SoA – מסמך ניהולי ולא רק דרישת תיעוד
ה-Statement of Applicability הוא הרבה יותר מדרישת תיעוד של ISO 27001. זהו מסמך ניהולי שמציג כיצד הארגון בחר להתמודד עם סיכוני אבטחת המידע שלו.
כאשר הוא נבנה ומתוחזק נכון, ה־SoA מאפשר להנהלה, למבקרים ולבעלי התפקידים להבין אילו בקרות פועלות, מדוע הן נדרשות, ומה עדיין דורש טיפול.
כיצד אינפוגארד יכולה לסייע?
אינפוגארד מסייעת לארגונים בבניית ועדכון Statement of Applicability, בביצוע תקינה ורגולציה, הסמכה לתקני ISO, ביצוע Gap Assessment, עדכון סקר סיכונים, בניית Statement of Applicability, בחינת אפקטיביות ובקרות.
צרו איתנו קשל לגבי
הסמכה לתקן ISO 27001
מידע נוסף במאמרים הבאים:
