מסמך Compliance: מה זה ואיך מנהלים תיעוד ציות באבטחת מידע?

מהו מסמך Compliance?

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

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

ב-ISO/IEC 27001, לדוגמה, הארגון נדרש להקים, ליישם, לתחזק ולשפר באופן מתמשך מערכת לניהול אבטחת מידע – ISMS. המשמעות המעשית כוללת גם מידע מתועד שמאפשר לנהל ולהוכיח את פעילות המערכת.

לכן, כאשר מדברים בארגון על "מסמך Compliance", בדרך כלל נכון יותר לחשוב על מערכת של מסמכים וראיות, ולא על קובץ Word יחיד.

מה נכנס ל-Compliance Documentation?

תיק Compliance ארגוני יכול לכלול, בהתאם למסגרת הרלוונטית:

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

המשותף לכולם הוא שהם צריכים לאפשר לענות על שאלה פשוטה:

מה הדרישה, כיצד אנחנו מיישמים אותה, ומאיפה ניתן להוכיח שזה אכן קורה?

ארבע שכבות שכדאי להפריד ב- Compliance Documents

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

נכון יותר לחשוב על ארבע שכבות:

1. Requirement – מה דורשים מאיתנו?

לדוגמה:

• תקן ISO
• רגולציה
• חוזה עם לקוח
• NIST
• דרישת CMMC
• מדיניות פנימית

2. Policy & Procedure – מה החלטנו לעשות?

כאן נמצאים המדיניות והנהלים.

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

3. Control – איך מיישמים את הדרישה?

לדוגמה:

• רשימת משתמשים
• תהליך Access Review
• אישור מנהל
• הסרת הרשאות עודפות

4. Evidence – איך מוכיחים?

כאן נכנסים:

• דוח ההרשאות
• פרוטוקול הסקירה
• Ticket לסגירת הרשאה
• אישור מנהל
• Log של המערכת

Compliance איכותי מתקיים כאשר ארבעת הרבדים האלה מחוברים.

למה "יש לנו נוהל" כבר לא מספיק?

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

לדוגמה, נוהל יכול לקבוע כי:

הרשאות משתמשים ייבדקו אחת לרבעון.

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

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

זו אחת הסיבות לכך שארגונים עוברים בהדרגה מגישת Document-Based Compliance לגישה של Evidence-Based Compliance.

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

מה הקשר בין מסמך Compliance לבין SSP?

כאן חשוב לעשות הבחנה.

SSP – System Security Plan אינו תיק Compliance כללי.

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

ב-NIST, ה-System Security Plan הוא חלק מתפיסה רחבה יותר של System Plans ומניהול סיכונים ברמת המערכת.

אפשר לחשוב על היחסים כך:

Compliance Documentation = התמונה הארגונית הרחבה של עמידה בדרישות.

SSP = תמונת האבטחה המפורטת של מערכת או Scope מסוים.

לכן SSP יכול להיות אחד המסמכים החשובים בתוך תיק ה-Compliance, במיוחד בארגונים הפועלים מול NIST, ‏CMMC או דרישות פדרליות אמריקאיות.

להרחבה: מהו SSP? המדריך ל-System Security Plan באבטחת מידע וציות.

ומה ההבדל בין SSP לבין Gap Assessment?

גם כאן מדובר בשני כלים שונים.

Gap Assessment שואל:
איפה אנחנו עומדים ביחס לדרישה?

SSP שואל:
כיצד המערכת שלנו בנויה ואיך הדרישות מיושמות בה?

לדוגמה, סקר פערים עשוי לזהות שאין תהליך תקופתי לסקירת הרשאות.

תוכנית התיקון תגדיר שיש להקים תהליך כזה.

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

לכן Gap Assessment יכול להיות אחד השלבים שמזינים את כתיבת ה-SSP, ולהפך, SSP קיים יכול לחשוף פערים כאשר התיאור שבו אינו תואם את המציאות.

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

החיבור ל-ISO 27001

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

ארגון הפועל לפי ISO 27001 נדרש לייצר מערכת מסודרת של Governance ותיעוד סביב:

• Scope
• ניהול סיכונים
• מטרות אבטחת מידע
• מדיניות
• אחריות
• בקרות
• ניטור ומדידה
• ביקורות פנימיות
• טיפול באי-התאמות
• שיפור מתמשך

לכן ISO 27001 מספק בסיס מצוין ל-Compliance Documentation ארגוני.

החיבור ל-ISO 27002

בעוד ISO 27001 מגדיר את דרישות ה-ISMS, ‏ISO/IEC 27002 מספק הנחיות ליישום בקרות אבטחת מידע.

במילים פשוטות:

ISO 27001 עוזר להגדיר מה מערכת הניהול צריכה לעשות; ISO 27002 מסייע להבין כיצד ליישם בקרות.

במתודולוגיה של ISO 27002 ניתן לראות את החיבור המעשי בין Scoping, ‏Gap Analysis, בחירת בקרות, כתיבת נהלים ובניית תיק Evidence לביקורת.

Compliance וניהול סיכונים הם לא אותו דבר

עמידה בדרישה אינה בהכרח זהה לניהול סיכון.

Compliance שואל:

האם אנחנו עומדים בדרישה שהוגדרה לנו?

Risk Management שואל:

מה עלול לפגוע בארגון, מה ההשפעה ומה נכון לעשות ביחס לסיכון?

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

לכן נכון לחבר בין תיק ה-Compliance לבין סקר סיכוני אבטחת מידע, כך שתיעדוף הפעולות יתבסס לא רק על "Passed/Failed", אלא גם על ההשפעה העסקית והסיכון בפועל.

מהו Compliance Matrix?

אחד הכלים השימושיים לניהול ציות הוא Compliance Matrix.

מדובר בטבלה שממפה כל דרישה למסמכים ולבקרות התומכות בה.

לדוגמה:

דרישה	בקרה	בעל אחריות	Evidence	סטטוס
סקירת הרשאות	Access Review רבעוני	IT Manager	דוח סקירה	תקין
הדרכת עובדים	הדרכה שנתית	HR / CISO	רשימת משתתפים	תקין
ניהול ספקים	Vendor Assessment	רכש / CISO	שאלון ספק	חלקי
גיבויים	Backup Policy	IT	דוחות Backup	תקין

היתרון הגדול של ה-Matrix הוא יצירת Traceability:

Requirement → Control → Owner → Evidence → Status

כך ניתן לראות מהר מאוד אילו דרישות מיושמות, איפה חסרה ראיה ומה דורש טיפול.

מהו תיק Evidence?

אם Compliance Matrix הוא המפה, תיק Evidence הוא ההוכחה.

תיק Evidence יכול לכלול:

• Screenshots
• דוחות מערכת
• Logs
• Tickets
• אישורי מנהלים
• פרוטוקולים
• דוחות סקירה
• תוצאות סריקות
• תיעוד הדרכות
• דוחות Backup ו-Restore
• הערכות ספקים

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

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

ומה לגבי SOC 2?

SOC 2 הוא דוגמה טובה למסגרת שבה איכות הראיות משמעותית מאוד.

הדו"ח נועד לספק למשתמשים וללקוחות מידע וביטחון ביחס לבקרות של ארגון שירות בתחומים כגון Security, Availability, Confidentiality ו-Privacy.

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

זה בדיוק החיבור שבין Compliance לבין Evidence.

Compliance Documentation צריך להיות חי

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

בינתיים:

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

לכן מסמכי Compliance צריכים להתנהל כ-Living Documentation.

כדאי לקבוע:

• Owner לכל מסמך
• תאריך Review
• Version Control
• טריגרים לעדכון
• תהליך אישור
• מקור מוסכם ל-Evidence

איך מתחילים?

תהליך עבודה בסיסי יכול להיראות כך:

שלב 1: מגדירים את מסגרות היעד

לדוגמה:

• ISO 27001
• NIST
• CMMC
• SOC 2
• רגולציית פרטיות
• דרישות לקוחות

שלב 2: מגדירים Scope

אילו יחידות, מערכות, תהליכים וספקים נמצאים בתחולה?

שלב 3: בונים Compliance Matrix

כל דרישה מקבלת בקרה, Owner ו-Evidence.

שלב 4: מבצעים Gap Assessment

בודקים מה באמת מיושם.

שלב 5: סוגרים פערים

טכנולוגיה, נהלים, הדרכות, חוזים, ספקים או תהליכים.

שלב 6: בונים Evidence

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

שלב 7: מבצעים Review תקופתי

כי Compliance אינו אירוע שנתי – הוא תהליך.

כיצד אנחנו באינפוגארד יכולים להשתתף?

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

התהליך יכול לכלול:

• מיפוי דרישות
• הגדרת Scope
• Compliance Assessment
• GAP Analysis
• סקרי סיכונים
• בניית מדיניות ונהלים
• בניית Compliance Matrix
• מיפוי Evidence
• SSP
• הכנה להסמכה או Audit
• תחזוקה ושיפור מתמשך

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

מה דורשים מאיתנו?

איך אנחנו מיישמים את זה?

איך אנחנו מוכיחים שזה באמת קורה?

להרחבה ניתן לקרוא גם על Compliance ב-2026 – מציות פורמלי לניהול מתמשך ועל שירותי תקינה ו-ISO Compliance של אינפוגארד.

בשורה התחתונה – אין "מסמך Compliance" אחד שמתאים לכל ארגון.

Compliance Documentation היא המערכת שמחברת בין הארגון ל:

• דרישות
• בקרות
• תהליכים
• בעלי אחריות
• ראיות

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

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

יצירת קשר עם מומחי Compliance של אינפוגארד

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