ISO 27001:2022 — 11 הבקרות החדשות והמעבר מגרסת 2013
מועד המעבר ל-ISO 27001:2022 עבר ב-31.10.2025 — תעודות 2013 בטלות. מדריך לעידן שאחרי: מה השתנה במבנה Annex A (114/14 ← 93/4), 11 הבקרות החדשות והמשמעות המעשית של כל אחת, ומסלול ההסמכה מחדש לארגונים שהתעודה שלהם פגה.
אם פתחתם את המאמר הזה כי מצאתם במגירה תעודת ISO 27001:2013 ואתם לא בטוחים אם היא עדיין שווה משהו — הנה התשובה הקצרה: היא כבר לא. מועד המעבר הרשמי לגרסת ISO/IEC 27001:2022 נקבע ל-31 באוקטובר 2025 בהחלטת פורום ההסמכה הבינלאומי (IAF), ומאז אותו תאריך כל תעודות 2013 שלא הוסבו בטלות. גופי ההסמכה משכו אותן. המשמעות המעשית: מי שהתמהמה כבר לא עומד בפני ״מבדק מעבר״ מקוצר, אלא בפני מסלול הסמכה מלא מחדש. במאמר הזה נסביר מה בדיוק השתנה ב-2022, מהן 11 הבקרות החדשות ומה כל אחת מהן אומרת בפועל לחברה קטנה, ואיך נראה מסלול ההסמכה מחדש בעידן שאחרי המועד — בין אם אתם מסמיכים מחדש, מסמיכים בפעם הראשונה, או פשוט רוצים להבין מה קרה כאן.
המועד עבר, אבל השאלות רק התחדדו. המאמר נכתב לשלושה קהלים: (1) ארגונים שנתנו לתעודת 2013 שלהם לפוג וצריכים להסמיך מחדש על בסיס 2022; (2) ארגונים שניגשים להסמכה בפעם הראשונה — עבורכם אין בכלל שאלת ״מעבר״, פשוט מתחילים ישר מ-2022; (3) צוותים שרוצים להבין מה השתנה במבנה התקן ובבקרות. אם אתם בקהל השני, כדאי לקרוא קודם את חמשת הצעדים המעשיים להסמכת ISO 27001 בחברת SaaS — המדריך המלא למסע — ולחזור לכאן להבנת הבקרות החדשות.
מה בעצם השתנה בין 2013 ל-2022
השינוי המשמעותי ביותר אינו בגוף התקן (סעיפים 4–10, הדרישות הניהוליות) אלא ב-Annex A — נספח הבקרות. בגרסת 2013 היו 114 בקרות ב-14 תחומים. בגרסת 2022 הן ארוגנו מחדש ל-93 בקרות בארבע קבוצות בלבד: בקרות ארגוניות (37), בקרות אנשים (8), בקרות פיזיות (14) ובקרות טכנולוגיות (34). זו לא הפחתה של דרישות — זו ארגון מחדש. רוב הצמצום המספרי נובע ממיזוג: 57 בקרות ישנות אוחדו ל-24 בקרות חדשות. 58 בקרות נשארו כמעט זהות (עם עדכוני נוסח קלים), ו-11 בקרות הן חדשות לגמרי — לא היו קיימות ב-2013.
נוספה גם שכבה שלא הייתה קודם: כל בקרה בגרסת 2022 מתויגת ב-attributes (מאפיינים) — תגיות שמאפשרות לחתוך את הבקרות בכמה צירים: סוג הבקרה (מונעת/מגלה/מתקנת), תכונות אבטחת מידע (סודיות/שלמות/זמינות), מושגי סייבר (זיהוי/הגנה/גילוי/תגובה/התאוששות — במיפוי ל-NIST), יכולות תפעוליות ותחומי אבטחה. המאפיינים אינם דרישה — אי אפשר ״להיכשל״ בהם — אבל הם כלי מיפוי חזק שעוזר לחבר בין ה-SoA שלכם למסגרות אחרות.
בגוף התקן עצמו השינויים מינוריים אך אמיתיים. הבולט שבהם: סעיף 6.3 — Planning of changes, דרישה חדשה שכאשר הארגון מזהה צורך בשינוי במערכת ניהול אבטחת המידע, השינוי יבוצע בצורה מתוכננת. נוספו גם חידודי נוסח בסעיפים 4.2 (הבנת צורכי בעלי העניין), 6.2 (יעדים ותכנון להשגתם), 8.1 (תכנון ובקרה תפעוליים) ו-9.3 (סקר הנהלה). מי שיש לו ISMS מתפקד לרוב עומד ברוחם ממילא — אבל צריך לתעד את זה מפורשות.
11 הבקרות החדשות — ומה כל אחת אומרת לחברה קטנה
כאן נמצא הלב של גרסת 2022. אחת-עשרה הבקרות החדשות משקפות בדיוק את מה שהשתנה בנוף הסייבר בעשור שבין הגרסאות: מעבר לענן, איומים ממוקדים, פרטיות, ופיתוח מהיר. הנה כל אחת, ומשמעות מעשית אחת לחברת SaaS קטנה:
| בקרה | שם | מה זה אומר לכם בפועל |
|---|---|---|
| 5.7 | Threat Intelligence — מודיעין איומים | לאסוף ולנתח מידע על איומים רלוונטיים לכם (למשל התראות מערך הסייבר, פידים, CVEs) ולפעול לפיו — לא לחכות שהמתקפה תגיע. |
| 5.23 | אבטחת מידע לשירותי ענן | להגדיר תהליך מסודר לבחירה, הגדרה, ניהול ויציאה משירותי ענן — מי אחראי על מה מול AWS/GCP/Azure ומול ספקי SaaS. |
| 5.30 | מוכנות ICT להמשכיות עסקית | לוודא שתשתית ה-IT יכולה לחזור לפעולה בזמן שהגדרתם (RTO/RPO) אחרי כשל — גיבויים שנבדקו, לא רק שנעשו. |
| 7.4 | ניטור אבטחה פיזית | לנטר פיזית אזורים רגישים — אצל SaaS לרוב הכוונה למשרד/חדר שרתים; חלק גדול מהאחריות עובר לספק הענן ומתועד בהסכם. |
| 8.9 | ניהול תצורה (Configuration Management) | לתחזק baseline מאובטח למערכות ולשרתים ולזהות סטיות — hardening של תמונות ותשתית, לא הגדרות ברירת מחדל. |
| 8.10 | מחיקת מידע | למחוק מידע שכבר אין בו צורך, בצורה מבוקרת — קריטי לעמידה בדרישת המחיקה של תיקון 13 ושל לקוחות. |
| 8.11 | מיסוך מידע (Data Masking) | להסתיר או לטשטש מידע רגיש היכן שהחשיפה המלאה מיותרת — למשל בסביבות פיתוח, בדיקות וניתוח נתונים. |
| 8.12 | מניעת דליפת מידע (DLP) | למנוע הוצאה לא מורשית של מידע רגיש מהמערכות — הגבלות על ערוצי יצוא, שיתוף והדבקה. |
| 8.16 | ניטור פעילות (Monitoring Activities) | לנטר מערכות ורשתות באופן שוטף כדי לזהות התנהגות חריגה — לוגים שנאספים ונבדקים, לא נשכחים. |
| 8.23 | סינון אינטרנט (Web Filtering) | לחסום גישה לאתרים זדוניים/לא מורשים מהרשת הארגונית, כדי לצמצם חשיפה לתוכנות עוינות ופישינג. |
| 8.28 | פיתוח מאובטח (Secure Coding) | להטמיע עקרונות כתיבת קוד מאובטח לאורך מחזור הפיתוח — כדי לצמצם פגיעויות עוד לפני שהן מגיעות לייצור. |
מהשטח, ומדיווחי גופי הסמכה על מבדקי המעבר: שתי הבקרות שנמצאו הכי לא בשלות הן דווקא 5.7 (מודיעין איומים) ו-5.23 (אבטחת שירותי ענן). הסיבה דומה בשתיהן — הן דורשות תהליך מתועד ומתמשך, ולא הגדרה טכנית חד-פעמית. ארגונים ״עושים״ ניטור איומים וצריכת ענן, אבל לא מתעדים את זה כתהליך מנוהל עם אחריות ברורה. אם אתם ניגשים למבדק, השקיעו שם קודם.
מסלול ההסמכה מחדש — לארגונים שהתעודה שלהם פגה
עד 31.10.2025 היה קיים ״מבדק מעבר״ (Transition Audit) — הליך מקוצר יחסית שבו גוף ההסמכה בדק רק את הדלתא מול 2022 והנפיק תעודה מעודכנת. החלון הזה נסגר. ארגון שהתעודה שלו פגה נמצא היום במעמד זהה למי שלא היה מוסמך מעולם: נדרש מסלול הסמכה מלא, כולל Stage 1 ו-Stage 2 מלאים. זה יקר ואיטי יותר ממה שהיה זמין קודם — אבל בהחלט בר-ניהול. כך זה נראה:
- Gap Assessment מול 2022. בודקים איפה אתם עומדים מול גוף התקן (כולל סעיף 6.3 החדש) ומול 93 הבקרות. אם היה לכם ISMS של 2013, רוב התשתית קיימת — מתמקדים ב-11 הבקרות החדשות ובמיפוי מחדש.
- סגירת פערים. מטמיעים את מה שחסר — לרוב מודיעין איומים, ניהול ענן מסודר, DLP ומיסוך מידע — ומייצרים את התהליכים והתיעוד הנלווים.
- שכתוב ה-SoA. בונים מחדש את מסמך תחולת הבקרות מול 93 הבקרות והמבנה הרביעוני (ראו טיפים בהמשך).
- תקופת תפעול. מריצים את ה-ISMS המעודכן, כולל ביקורת פנימית וסקר הנהלה שכבר התקיימו — גופי הסמכה מצפים לראות מערכת שרצה בפועל וצברה ראיות.
- Stage 1 ו-Stage 2. מבדק בשלות התיעוד ואז מבדק האפקטיביות המלא, שבסופו — תעודת ISO 27001:2022 חדשה בתוקף לשלוש שנים.
לגבי לוח זמנים: ארגון שכבר היה מוסמך ב-2013 ורק ״נשר״ בגלל המועד — כלומר התשתית והתרבות קיימות — יכול לרוב לחזור לתעודה תוך שלושה עד חמישה חודשים, כשעיקר העבודה היא סגירת 11 הבקרות החדשות ושכתוב ה-SoA. ארגון שה-ISMS שלו התרופף בפועל, או שמעולם לא באמת חי אותו, יתקרב יותר לטווח של הסמכה ראשונה — ארבעה עד שמונה חודשים — כפי שפירטנו במדריך חמשת הצעדים המעשיים.
מסמיכים בפעם הראשונה? פשוט תתחילו מ-2022
אם אתם ניגשים להסמכה עכשיו בלי היסטוריה של 2013 — יש לכם יתרון: אין שאלת מעבר, אין נטל לגרור מסמכים ישנים. אתם בונים ISMS על בסיס 2022 מהיום הראשון, עם המבנה הרביעוני ו-93 הבקרות. כל התהליך — הגדרת Scope, ניהול סיכונים, בניית ISMS, הטמעה ומבדק — זהה לחלוטין למה שתיארנו במדריך חמשת הצעדים להסמכת ISO 27001 בחברת SaaS. ההבדל היחיד: כשאתם ממפים בקרות, אתם עובדים ישר מול הרשימה החדשה, כולל 11 הבקרות שלמעלה. אין צורך להכיר את 2013 בכלל.
שכתוב ה-SoA — הטיפים שחוסכים זמן
ה-SoA (Statement of Applicability) הוא המסמך שהמבקר פותח ראשון, ובמעבר ל-2022 הוא נכתב כמעט מאפס כי מספרי הבקרות ומבנה הנספח השתנו. כמה עקרונות מהשטח:
- התחילו ממיפוי 2013→2022, לא מדף חלק. ISO מפרסמת טבלת המרה רשמית בין הבקרות. רוב הבקרות הישנות שלכם ״נוחתות״ על בקרה חדשה — אל תמציאו מחדש מה שכבר החלטתם.
- הבינו את היגיון המיזוג. כשמספר בקרות 2013 מוזגו לאחת (למשל בקרות גישה שאוחדו), התיעוד וההצדקה שלכם צריכים לכסות את כל הרכיבים תחת הבקרה החדשה האחת.
- ה-11 החדשות דורשות החלטת תחולה מפורשת. לכל אחת מהן החליטו במפורש: חלה/לא חלה, ואם חלה — איך היא ממומשת. ״לא חלה״ בלי נימוק אמיתי הוא דגל אדום למבקר.
- נצלו את ה-attributes. תיוג הבקרות ב-SoA לפי מאפיינים מקל אחר כך על מיפוי ל-SOC 2, לתיקון 13 או ל-NIST — עבודה שנעשית פעם אחת ומשרתת כמה מסגרות.
ומה עם הפרטיות? החוליה ל-ISO 27701
אם ארגון ישראלי מסמיך (או מסמיך מחדש) על בסיס 2022, זה גם הרגע הנכון לשקול הרחבת פרטיות. [ISO 27701](/cyber-insights/iso-27701-privacy-standard) הוא תקן ניהול פרטיות שנבנה כהרחבה ל-27001 — הוא מוסיף בקרות ותהליכים לניהול מידע אישי (PII) ומספק תשתית מסודרת שמתכתבת ישירות עם דרישות תיקון 13. היתרון בעיתוי: כשאתם ממילא בונים או משכתבים את ה-ISMS על בסיס 2022, הוספת שכבת 27701 חוסכת פרויקט נפרד — אותן בקרות ליבה, אותה מערכת ניהול, אותם מבדקים. חברה שמוכרת ללקוחות שרגישים לפרטיות תגלה שהצירוף הזה עונה על שני שאלוני ספקים במכה אחת.
צ׳קליסט למעבר או להסמכה מחדש — מה לעשות השבוע
- בדקו את סטטוס התעודה שלכם. אם היא נושאת ISO 27001:2013 — היא בטלה. אם 2022 — ודאו את תאריך התוקף ואת מועד מבדק המעקב הקרוב.
- הריצו Gap מהיר מול 11 הבקרות החדשות. לכל אחת סמנו: קיים / חלקי / חסר. זה נותן תמונה מיידית של היקף העבודה.
- זהו את שתי נקודות התורפה הקלאסיות — מודיעין איומים (5.7) וניהול ענן (5.23) — ובדקו אם יש לכם תהליך מתועד, לא רק פעילות.
- אספו את טבלת ההמרה 2013→2022 לפני שנוגעים ב-SoA, ומפו את הבקרות הקיימות לפני שכותבים חדשות.
- תעדו את סעיף 6.3 — נהל מסודר לתכנון שינויים ב-ISMS. קטן, אבל דרישה חדשה שמבקרים בודקים.
- החליטו על ה-Scope וגוף ההסמכה מוקדם. מועדי Stage 1/Stage 2 מתואמים חודשים מראש — פרט לוגיסטי שמפתיע ארגונים בסוף הדרך.
- שקלו את חוליית 27701 אם פרטיות היא חלק מהסיפור מול הלקוחות — עדיף לתכנן אותה עכשיו ולא בפרויקט נפרד.
השורה התחתונה
המועד עבר, וזה מפשט את התמונה: אין יותר מסלול ביניים. או שיש לכם תעודת 2022 בתוקף, או שאתם ניגשים למסלול הסמכה מלא על בסיס 2022 — בין אם מדובר בהסמכה מחדש או בפעם הראשונה. החדשות הטובות: מי שכבר חי ISMS אמיתי לא מתחיל מאפס, וכל העבודה מתרכזת ב-11 בקרות ברורות ובשכתוב מסודר של ה-SoA. גרסת 2022 אינה ״עוד רגולציה״ — היא פשוט מתארת נכון יותר את מה שחברת תוכנה מודרנית צריכה ממילא לעשות: לנהל ענן, לנטר איומים, למסך מידע ולכתוב קוד מאובטח. מי שבונה את זה נכון יוצא לא רק עם תעודה מעודכנת, אלא עם תשתית אבטחה שמתאימה למאה ה-21.
Cybertis מלווה ארגונים ישראליים במעבר ל-ISO 27001:2022 ובהסמכה מחדש — מ-Gap Assessment מול 11 הבקרות החדשות, דרך שכתוב ה-SoA וסגירת הפערים, ועד ליווי במבדקי Stage 1 ו-Stage 2. הפגישה הראשונה עלינו.
לשירות הסמכת ISO 27001*האמור במאמר זה הוא מידע כללי בלבד ואינו מהווה ייעוץ מקצועי מחייב. תהליך הסמכה או מעבר בפועל תלוי במאפייני הארגון, ב-Scope שנבחר ובדרישות גוף ההסמכה, ומחייב בחינה פרטנית.*
תקן ISO 27001
הסמכה בינלאומית מהיום הראשון ועד התעודה — בלי הפתעות במבדק.
לעמוד השירות המלא