כאשר הסיכון הגדול ביותר לאירוע הוא ראיות חסרות
הסיכון הגדול ביותר שלכם לאירועים הוא לרוב לא ההתקפה עצמה, אלא הראיות החסרות כאשר רגולטורים, לקוחות והדירקטוריון דורשים תשובות. תקן ISO 27001 A.8.28 קיים כדי לעצור זאת על ידי התייחסות לראיות לאירועים כמשהו שאתם מגדירים, אוספים ומשמרים בכוונה, כך שתוכלו לספר סיפור ברור ובר-הגנה על מה שקרה, כיצד הגבתם ומדוע אחרים צריכים לבטוח בחשבונכם.
כאשר מתרחש אירוע בעל השפעה גבוהה, אנשים נוטים לדלג על לוחות מחוונים של SIEM, קונסולות ענן, כלי כרטוס ותיבות דואר נכנס בניסיון לשחזר אירועים. לוחות הזמנים חלקיים, צילומי מסך מפוזרים והחלטות מפתח קיימות רק בשרשורי צ'אט. עם זאת, רגולטורים, לקוחות והנהלה בכירה מצפים לתשובות ברורות: מה קרה, מתי, למי, איך אתם יודעים ומה עשיתם בנידון. אם אתם מובילים את נושא הציות או התפעול ללא רקע מעמיק באבטחה, זה בדיוק הרגע שאתם חוששים להיתפס לא נכון.
ראיות רגועות ומובנות הופכות משבר מניחוש לסיום שניתן לעמוד מאחוריו.
צעד ראשון ושימושי הוא לקבוע את המציאות הנוכחית שלכם. התבוננו לאחור במספר אירועים משמעותיים אחרונים ושאלו כמה שאלות בוטות: האם יומני מפתח חסרים או מוחלפים; האם תוכלו להראות בדיוק מי ניגש לאילו חפצים ומתי; האם צוותי משפט או צוותי פרטיות התלוננו שהם "לא יכלו להוכיח" את מה שנטען בהודעות או בדיווחים לאחר האירוע?
משם ניתן לפתח לוח תכנון פשוט של "ראיות מעוצבות" לאירוע חמור טיפוסי. התחילו בגילוי הראשוני, עברו דרך מיון, בלימה והתאוששות, וסיימו בתקשורת רגולטורית, חוזית ותקשורת עם הלקוחות. בכל שלב, סמנו אילו ראיות קיימות כיום, היכן הן נמצאות, למי הן הבעלים והיכן השרשרת נשברת כעת. קומה חזותית יחידה זו הופכת לכלי יישור רב עוצמה עבור מנהלי מערכות מידע (CISO), מנהלי מערכות הגנה, ציות ומחלקות משפטיות.
ככל שתשפרו את התמונה, הרחיבו את העדשה מעבר לטלמטריה טכנית גרידא. ראיות שחשובות במצבים המדווחים על ידי הרגולטור כוללות החלטות (מי החליט מה, מתי ועל סמך מה), הודעות שנשלחו, תקשורת עם לקוחות, התכתבויות עם צד שלישי ותוצרי סקירת אירועים. החלטה ותיעוד של אילו מבין אלה תתייחסו כ"ראיות לאירוע" הם הבסיס לכל מה שיבוא לאחר מכן.
אם אתם חדשים ב-ISO 27001, מספיק בהתחלה להגדיר מספר סוגי אירועים בסיכון גבוה ולהסכים על ראיות "מספיק טובות" עבור כל אחד מהם. לאחר מכן תוכלו להעמיק ולבסס גישה זו ככל שמערכת ניהול אבטחת המידע (ISMS) שלכם מתבגרת.
למה "יש לנו יומנים" לא זהה ל"יש לנו ראיות"
אמירה של "יש לנו יומני רישום" משמעה שאתם אוספים נתונים; אמירה של "יש לנו ראיות" משמעה שאתם יכולים להוכיח עובדות ספציפיות על אירועים באופן שרגולטורים ובתי המשפט יסמכו עליו. עבור אירועים חמורים או אירועים הדורשים דיווח על ידי הרגולטור, אתם לא רק מנפים בעיה טכנית; אתם מרכיבים תיק מקרה שחייב לתמוך בכל הצהרה מהותית שאתם נותנים כלפי חוץ.
תחת עדשה זו, ראיות זקוקות לאיכויות שרישום תפעולי יומיומי לא תמיד מבטיח: רלוונטיות לעובדות הנדונות, שלמות (ללא שינויים בלתי מוסברים), מקור ברור, שלמות ההחלטות שקיבלת ומעקב מתועד של מי טיפל בהן. ייצוא SIEM גולמי עם שדות חסרים וללא שרשרת משמורת אולי יעזור למהנדסים, אך הוא לא יספק חוקר ספקן.
דרך מעשית לחשוף את הפער היא לקחת אירוע אמיתי אחד ולשאול, "אם רגולטור יגיע מחר, האם נוכל להראות לו, תוך יום, חבילה עקבית שתסביר מה קרה ותגבה כל הצהרה מרכזית שעשינו?" אם התשובה הכנה היא לא, הסיכון שלכם אינו היפותטי. פער זה הופך אז לנקודת המוצא הנרטיבית לעבודת איסוף הראיות שלכם.
כיצד לקבוע את עמדת הראיות הנוכחית שלך
בסיס ראיות מהיר משווה מספר אירועים אמיתיים מול מה שצריך כדי לשכנע רגולטור שהגרסה שלך לאירועים מדויקת. על ידי דגימת סוגי אירועים שונים ורישום אילו חפצים קיימים ואילו חסרים, אתם הופכים חרדה מעורפלת לרשימת שיפורים קונקרטית ומסודרת, שגם מומחי אבטחה וגם מנהיגים שאינם טכניים יכולים להבין.
כדי לבצע הערכה בסיסית ללא מאמץ גדול, בחרו שלושה עד חמישה אירועים מהשנה האחרונה: פרצת מידע אישי אחת או כמעט-תאונה, אירוע זמינות או שלמות משמעותי אחד ואירוע אחד שהופעל על ידי צד שלישי. עבור כל אחד מהם, רשמו אילו חפצים יש לכם בפועל כיום - יומנים, דוחות, מיילים, כרטיסים, צילומי מסך, סיכומי פגישות - ואילו הייתם רוצים שיהיו לכם.
סכמו את הממצאים בהערה פנימית קצרה; לדוגמה, בארבעה מתוך חמישה מקרים, יומני הזהות לא היו שלמים; בשלושה, חסר לנו יומן החלטות ברור; בשניים, לא הצלחנו לשחזר את זמן הגילוי המדויק. ניתוח קל משקל זה הופך באופן מיידי אי נוחות מעורפלת לקו בסיס קונקרטי. הוא גם נותן לכם דרך פשוטה ולא מדאיגה להסביר להנהלה מדוע בקרת איסוף הראיות של ISO 27001 ראויה לתשומת לב כעת, ולא לאחר ההפרה הבאה.
אם הארגון שלכם עדיין עובד לקראת הסמכת ISO 27001 הראשונה שלו, בסיס זה יכול להשתלב ישירות בהערכת הסיכונים ובתוכנית הטיפול שלכם. פערים בראיות סביב אירועים הנדרשים לדיווח על ידי הרגולטורים מצדיקים בדרך כלל טיפולי סיכון ברורים וניתנים לפעולה במקום להמתין למועד מאוחר יותר.
הזמן הדגמהמה באמת מבקש ממך תקן ISO 27001 A.8.28 (לשעבר A.5.28)
תקן ISO 27001 A.8.28 (אשר חומרים ישנים יותר עשויים עדיין לסווג כ-A.5.28) דורש ממך לטפל בראיות לאירועים באמצעות תהליך מוגדר וניתן לחזור עליו, במקום לאלתר במהלך משבר. תקן ISO 27001:2022 מצפה ממך לקבוע וליישם נהלים לזיהוי, איסוף, רכישה ושימור ראיות הקשורות לאירועי אבטחת מידע. בפועל, משמעות הדבר היא להחליט מראש מה נחשב כראיה, היכן היא נמצאת וכיצד היא מטופלת, ויכולת להראות למבקרים ולרגולטורים שפעילויות אלו מתאימות לפרופיל הסיכון ולמגזר שלך, במקום להסתמך על התנהגות אד-הוק של "תפוס מה שאתה יכול".
במילים פשוטות, הבקרה מצפה ממך לעשות ארבעה דברים:
- החליטו מה נחשב כראיה פוטנציאלית והיכן היא נמצאת.
- אסוף אותו בצורה מבוקרת שתשמור על ערכו.
- יש לאחסן ולהגן עליו בצורה מאובטחת כל עוד הדבר נחוץ.:
- הראו שאתם עושים זאת באופן שיטתי, לא מדי פעם.
אם אתם משתמשים בפלטפורמת ISMS משולבת כמו ISMS.online, תוכלו להפוך את הציפיות הללו לזרימות עבודה, אחריות וספריות ארטיפקטים קונקרטיות, במקום להסתמך על מסמכים סטטיים וזיכרון אישי.
מידע זה הינו כללי ואינו מהווה ייעוץ משפטי; עליך תמיד לקבל הנחיות ספציפיות לתחום השיפוט שלך מיועץ משפטי מוסמך או מקצין הגנת המידע שלך בעת פירוש חובות רגולטוריות.
הדרישה המרכזית בשפה פשוטה
בשפה פשוטה, A.8.28 דורש שתהיה לך היכולת לספר סיפור אמין וניתן לאימות על אירועים חמורים, מגובה בראיות שתוכל למצוא ולסמוך עליהן, באופן שעומד בפני אתגרים. התקן אינו מחייב אותך להתייחס לכל אירוע מינורי כחקירה פלילית או לדרוש בדיקות פורנזיות ברמת מעבדה, אך הוא מצפה ממך להגדיר מתי חלה גישה ממושמעת יותר וכיצד תבצע אותה באופן עקבי בכל הנוגע לצורכי אבטחה, פרטיות וחוסן, תוך שימוש בהליכים ולא באלתור. נהלים אלה צריכים לכסות לפחות:
- כאשר אירוע הופך לאירוע הדורש ראיות:
- מי מורשה להתחיל לאסוף ראיות ולרשום את ההחלטה?
- אילו מקורות עליהם להשתמש עבור סוגי אירועים שונים:
- כיצד הם אוספים נתונים מאותם מקורות מבלי לפגוע בהם:
- כיצד הם מתייגים, מאחסנים ומאבטחים את החפצים המתקבלים:
כמו כן, היא מצפה מכם לחשוב כיצד הדבר משתלב עם בקרות אחרות. רישום וניטור מייצרים חלק ניכר מחומרי הגלם. בקרות ניהול אירועים מגדירות כיצד אתם מתכננים, מזהים, מעריכים ומגיבים לאירועים. בקרות משפטיות ורגולטוריות מגדירות חובות חיצוניות. איסוף ראיות נמצא בין אלה, ומבטיח שמה שמתחיל כטלמטריה טכנית יסתיים כתיעוד קוהרנטי התומך בתגובתכם ובאחריותכם.
היכן A.8.28 משתלב לצד בקרות ISO 27001 אחרות
סעיף A.8.28 משתלב בין רישום, ניהול אירועים ובקרות משפטיות כגשר שהופך אותות טכניים והחלטות לתיק מקרה בר הגנה. צוותים רבים פירשו בתחילה באופן שגוי את הבקרה כ"עוד רישום", אך רישום כבר מטופל במקום אחר. איסוף ראיות הוא הגשר הזה: הוא לוקח חלקים רלוונטיים מנוהלי הרישום, הניטור, התגובה לאירועים, המשפט, הפרטיות וניהול הרשומות והופך אותם למשהו שיכול לעמוד בבדיקה.
דרך שימושית לחשוב על כך היא לשרטט מפה פשוטה: A.5.24–A.5.27 לתכנון, הערכה, תגובה ולמידה של אירועים; בקרות רישום ליצירה והגנה על אירועים; ו-A.8.28 באמצע, הופכת את האירועים הללו ואת ההחלטות הנלוות אליהם לשביל ראיות מנוהל. ברגע שרואים את התמונה הזו, קל הרבה יותר למנהלי מערכות מידע, קציני פרטיות ואנשי מקצוע לזהות היכן תחומי אחריות חופפים, היכן קיימים פערים וכיצד להתאים את רמת הפורמליות לרמת הסיכון של הארגון והמגזר שלכם.
עבור מי שמאמץ לראשונה את תקן ISO 27001, משמעות הדבר היא לעתים קרובות התחלה עם הליך קליל של הוכחות לאירועים בחומרה גבוהה והרחבתו בהדרגה, במקום לנסות לשלב משמעת פורנזית מלאה בכל תיק קל כבר מהיום הראשון.
ISO 27001 בקלות
יתרון של 81% מהיום הראשון
עשינו את העבודה הקשה בשבילך, ונתנו לך התחלה של 81% מרגע הכניסה. כל שעליכם לעשות הוא להשלים את החסר.
מאירוע ביטחוני למקרה מדווח על ידי הרגולטור
מסע פשוט וחוזר על עצמו, מגילוי ראשוני ועד למקרה המדווח על ידי הרגולטור, מקל בהרבה על איסוף ראיות בזמנים הנכונים ובצורה הנכונה. המטרה אינה להתייחס לכל אירוע כתיק משפטי, אלא להבטיח שהתהליך יהפוך באופן טבעי למובנה יותר ככל שההשפעה והרלוונטיות הרגולטורית גוברות, במיוחד עבור אירועים הנכללים בחוקי פרצות נתונים או חוסן סייבר.
לא כל רשומה חשודה ביומן הופכת לאירוע, ולא כל אירוע הופך למקרה המחייב דיווח על ידי הרגולטור. עם זאת, תהליך איסוף הראיות שלך צריך לטפל בכל המסע בצורה חלקה, במיוחד בנקודה שבה אירוע שגרתי הופך לעניין של רישום משפטי ורגולטורי עם לוחות זמנים נוקשים ותוכן קבוע מראש להודעות.
בפועל, המסע בדרך כלל עוקב אחר דפוס מוכר. מערכת ניטור או משתמש מעלה אירוע. צוותי פיקוח על מידע (SecOps) מדרגים את האירוע, ואם יש צורך בכך, מכריזים על אירוע. חקירה נוספת מגלה האם מעורבים נתונים אישיים, שירותים קריטיים או מערכות מוסדרות. צוותי משפט ופרטיות מעריכים האם נחצו ספים רגולטוריים. אם כן, שעון ההתראה מתחיל, וחייבות להיות ראיות לתמוך בכל טענה עובדתית שאתם מעלים כלפי חוץ.
הבנת מתי אירוע חוצה את סף הדיווח
לא ניתן לאסוף ראיות בצורה חכמה ללא תמונה ברורה של מועד הדיווח על אירוע על ידי הרגולטור. נקודת מפנה זו מוגדרת בדרך כלל על ידי חוק או כללי ענף, אך בפועל נדרש תיאור פנימי פשוט של התרחישים שמפעילים באופן אוטומטי טיפול רשמי יותר בראיות ובחינה משפטית או בנושא פרטיות.
לכל חוק וכלל מגזר יש שפה משלו, אך רובם שואלים שאלות דומות: האם האירוע השפיע על הסודיות, השלמות או הזמינות של נתונים או שירותים מסוימים; מהי חמורותה וכמה ארוכת טווח הייתה ההשפעה; ומהו הסיכון הצפוי לאנשים, ללקוחות או לחברה שנפגעו. לכן, הנהלים שלכם צריכים להגדיר, במילים שלכם, מהי המשמעות של "דיווח על ידי הרגולטור" עבורכם, עם דוגמאות קונקרטיות וקישורים ברורים לתיאבון הסיכון שלכם.
לדוגמה, ניתן לומר שכל אירוע הכרוך בדליפה מאומתת של נתוני לקוחות לא מוצפנים באזור הכלכלי האירופי מפעיל אוטומטית הערכת אבטחה-פרטיות משותפת לצורך הודעה רגולטורית. בשלב זה, תהליך הראיות שלכם צריך להבטיח שתוכלו להראות במהירות אילו רשומות היו מעורבות, כיצד ומתי התרחשה הגישה, מהם לוחות הזמנים של הגילוי והתגובה שלכם וכיצד הערכתם את הסיכון. מכיוון שספי ותאריכי יעד שונים בין תחומי שיפוט, יש לבחון את ההגדרות שלכם עם קצין הגנת המידע שלכם ועם יועץ חיצוני.
הפיכת ראיות לחלק מתהליך ההסלמה שלך
לאחר שספי המעקב ברורים, יש לשלב ראיות בכל שלב בתהליך ההסלמה במקום להצמיד אותן בסופו. משמעות הדבר היא לתעד מתי צוותי ההגנה מאבטחים חפצים מרכזיים, מתי גורמי משפט ופרטיות מצפים לקבל תיק חלקי וכיצד פעילויות אלו מתועדות כדי שתוכלו להראות שהתרחשו בזמן לחלון ההודעות הצפוף.
לאחר שהגדרתם ספים, שלבו נקודות ביקורת ראיות בכל שלב במסלול ההסלמה שלכם. כאשר צוות ה-SOC מעביר אירוע למצב של "אירוע משמעותי", על המגיבים לדעת אילו מקורות יומן וחפצים לאבטח באופן מיידי. כאשר מעורבים גורמים משפטיים ופרטיות, עליהם למצוא קובץ שנבנה חלקית כבר ממתין - יומני מערכת מרכזיים, ניתוח השפעות ראשוני, תקשורת מרכזית - במקום להתחיל מאפס תחת לחץ זמן.
כמו כן, שימוש בתבניות עקביות להערכת אירועים ופרצות הגנה יכול לעזור. תבניות אלו יכולות לשאול, עבור כל משפט מפתח ("זיהינו בזמן X", "מערכת Y הושפעה", "אנו מאמינים שהיו מעורבים נתונים מ-Z"), "אילו ראיות תומכות בכך? היכן זה מאוחסן? מי אימת זאת?" עם הזמן, הרגל זה מפחית את הסיכון שהנרטיבים הפנימיים והחיצוניים שלכם יתפרקו או יסתמכו על זיכרונות בלתי ניתנים למעקב, והוא מעניק לפקידי פרטיות ולפקידי משפט יותר ביטחון כאשר הם חותמים על הודעות בשמם.
עבור ארגונים המטפלים במידע אישי או בתשתיות קריטיות, שילוב נקודות ביקורת אלו במערכת ה-ISMS שלהם - במקום להתייחס אליהן כאל נוהג אופציונלי - יכול להיות ההבדל בין אינטראקציה רגולטורית חלקה לאינטראקציה קשה.
איך נראות ראיות טובות: יושרה, שרשרת משמורת, קבילות
ראיות טובות לאירועים הן אוסף של חפצים שמספרים יחד סיפור ברור ואמין ויכולים לעמוד בפני אתגרים מצד אנשים מחוץ לארגון שלך. רגולטורים ובתי משפט ידאגו לפחות באותה מידה ליושרה, לאותנטיות ולשרשרת משמורת כמו שהם ידאגו לפרטים הטכניים הגולמיים, במיוחד כאשר מדובר בזכויותיהם, בטיחותם או מקורות מחייתם של אנשים.
כדי שראיות יהיו משכנעות מחוץ לארגון שלך, אחרים חייבים להיות מסוגלים לסמוך עליהן שהן רלוונטיות, שלמות מספיק למטרתן ולא שונו ללא הסבר. כאן נכנסים לתמונה רעיונות כמו יושרה ושרשרת משמורת. אינך צריך להפוך למעבדה לזיהוי פלילי, אך אתה צריך רמת משמעת שתהיה הגיונית עבור רגולטור או בית משפט.
ראיות טובות לאירועים הן לעיתים רחוקות קובץ בודד. לעתים קרובות יותר, מדובר באוסף של פריטים - ייצוא יומני רישום, צילומי מסך, תמונות דיסק, תמלילי צ'אט, סיכומי פגישות, החלטות ודוא"ל - שמספרים יחד את הסיפור. האתגר הוא להבטיח שכאשר פריטים אלה עוברים בין אנשים ומערכות, הם ישמרו על ערכם כהוכחה במקום להפוך למידע "מעניין אך בלתי ניתן לאימות".
חמש תכונות שחייבות להיות לכל מערך ראיות לאירועים
רשימת בדיקה פשוטה של חמש תכונות - רלוונטיות, יושרה, אותנטיות, שלמות ושרשרת משמורת - נותנת לכם סטנדרט ברור לאיך נראות ראיות "טובות מספיק". אם אתם בוחנים באופן קבוע אירועים אמיתיים מול תכונות אלו, חולשות בשיטות הרישום, האחסון או המסירה שלכם הופכות במהירות לנראות לעין וניתנות לפעולה עבור צוותי אבטחה, פרטיות ומשפט כאחד.
מבחן מעשי לראיות שלך הוא לבחון את חמש התכונות הללו. רלוונטיות: האם כל אובייקט מתייחס בבירור לעובדה שעליך להוכיח? יושרה: האם תוכל להראות שהוא לא טופל או שונה בטעות, או אם כן, שהשינויים היו מבוקרים ותועדו? אותנטיות: האם תוכל להדגים מהיכן הוא הגיע ושהוא אכן מה שהוא טוען להיות? שלמות: האם יש מספיק חומר כדי להבין את המרכיבים המרכזיים של האירוע ואת תגובתך ללא פערים גדולים בלתי מוסברים? שרשרת משמורת: האם תוכל לעקוב אחר מי יצר, ניגש, העביר או ניתח כל פריט, ומתי?
ניתן לתמוך בתכונות אלו באמצעות אמצעים פשוטים יחסית: מערכות מסונכרנות בזמן כך שחותמות הזמן יתאימו; הליכי ייצוא סטנדרטיים הכוללים גיבוב של קבצי מפתח; תיקיות או מאגרים מבוקרים עם גישת כתיבה מוגבלת; ורישום פשוט שרושם מתי נוצרים, מועברים או מועברים לארכיטקטורה חיצונית. המטרה אינה שלמות; היא להפחית את הסיכוי שאתגר רציני לראיות שלכם יחשוף חולשות ברורות.
איזון בין מהירות תגובה לאיכות הראיות
באירועים אמיתיים, כוחות ההצלה תמיד מאזנים בין הצורך לפעול במהירות לבין הצורך לשמר ראיות. התהליך שלך צריך לתת להם הנחיות ברורות מתי לתעדף לכידה, מתי לתעדף בלימה וכיצד להסביר פשרות, כך שרגולטורים, לקוחות ומבקרים פנימיים עדיין יוכלו לסמוך על הסיפור שתספרו לאחר מכן.
אירועים אמיתיים לא מתרחשים בהילוך איטי. צוותים תחת לחץ עשויים לחוש שעצירה לצורך צילום מערכת או יצירת סקריפט לייצוא נקי תעכב את הבלימה. לכן, הנהלים שלכם צריכים להציע הנחיות הגיוניות לגבי פשרות: מתי עליכם לאבטח ראיות תחילה, ומתי מקובל לתקן אותן באופן מיידי ולהסתמך על מקורות משניים בהמשך?
גישה מועילה אחת היא להגדיר קבוצה קטנה של חפצים "שחייבים לאתר במהירות" עבור תרחישים בסיכון גבוה, כגון יומני זהות עבור חשבונות מנהל, יומני חומת אש או פרוקסי מרכזיים סביב חלון החשוד ותמונה מהירה של הגדרות תצורה רלוונטיות. ניתן לאמן את המגיבים לאתר אותם מוקדם ככל האפשר, אפילו בזמן שהבלימה מתבצעת. כאשר אתם מחליטים לנקוט פעולה מהירה שעשויה לדרוס ראיות, רשמו הערה קצרה ברשומת האירוע המסבירה מדוע - הערה זו חשובה לעתים קרובות לא פחות מהנתונים החסרים כשאתם מסבירים את עצמכם מאוחר יותר.
שחררו את עצמכם מהר של גיליונות אלקטרוניים
הטמע, הרחב והרחיב את תאימותך, ללא כל בלגן. IO מעניק לך את החוסן והביטחון לצמוח בצורה מאובטחת.
תכנון תהליך הוכחה תואם לתקן A.8.28
תכנון תהליך ראיות התואם לתקן A.8.28 עוסק בבניית זרימה פשוטה מקצה לקצה שאנשים יכולים לעקוב אחריה תחת לחץ. במקום מדיניות ארוכה וסטטית, אתם רוצים מחזור חיים המקשר תפקידים, טריגרים, כלים ומדדים מההכנה ועד ללמידה לאחר האירוע, ומספק לאנשי מקצוע משימות ברורות וניתנות להשגה במקום ציפיות מעורפלות.
ברגע שמבינים את השליטה ומה נראה "טוב", האתגר הבא הוא עיצוב. תהליך איסוף ראיות יעיל אינו מסמך יחיד; זוהי מערכת של פרקטיקות מחוברות המשתרעות על פני מדיניות, תפקידים, זרימות עבודה, כלים ומדדים. הוא צריך להיות חזק מספיק עבור מצבים מלחיצים אך פשוט מספיק כדי שאנשים באמת יפעלו לפיו, כולל מהנדסים עסוקים, מנהלי שירות ויועצים משפטיים או יועצים לפרטיות.
רוב הארגונים מוצאים לנכון לחשוב במונחים של מחזור חיים: הכנה, זיהוי, איסוף ורכישה, שימור, ניתוח וסגירה. דרישת איסוף הראיות של תקן ISO 27001 משתרעת על פני מחזור חיים זה וחייבת להיות תואמת גם לתוכנית ניהול האירועים, מדיניות אבטחת המידע, ניהול הגנת הנתונים וכללי ניהול הרשומות שלכם.
מחזור חיים פשוט מאירוע לראיה
ניתן לבטא את מחזור החיים של הראיות במספר קטן שלבים:
- אופן ההכנה: להגדיר נהלים, קטלוגים, תפקידים, כלים והדרכה.
- זיהוי: להחליט אילו אירועים או מקרים דורשים ראיות רשמיות.
- איסוף ורכישה: לאסוף חפצים ממקורות מוסכמים באופן מבוקר.
- שְׁמִירָה: לאחסן אותם בצורה מאובטחת באמצעות בקרות גישה ומעקב אחר שינויים.
- ניתוח וסיום: להשתמש בהם כדי להבין את האירוע, לדווח וללמוד.
לאחר שסקיצה זו תוגדר, תוכלו להתאים את המדיניות והכלים הקיימים שלכם לכל שלב ולזהות היכן אתם זקוקים לספרי מדיניות, הכשרה או טכנולוגיה חדשים.
בניית זרימה מקצה לקצה, מאירוע לראיות
דיאגרמת זרימה חזותית של אירוע לראיה הופכת את הבקרה לקלה בהרבה ליישום ולהסברה לאחרים. היא מראה כיצד תהליכי האירועים הקיימים שלכם, רישום, ביקורות משפטיות ותקשורת מתחברים, והיכן יש להפעיל שלבים הקשורים לראיות כדי ששום דבר חשוב לא יוחמצ, במיוחד בתרחישים המחייבים דיווח על ידי הרגולטור.
התחילו בסקיצה של זרימה ברמה גבוהה המקשרת את התהליכים הקיימים שלכם. הציגו כיצד אירוע נכנס לתור האירועים, כיצד הוא מוערך, מתי אירוע מוכרז, מתי מתחילים שלבי הראיות, מי מקבל הודעה ומתי נלקחות בחשבון הודעות רגולטוריות או תקשורת עם לקוחות. עבור כל שלב עיקרי, שאלו, "אילו ראיות צריכות להתקיים בשלב זה?" ו"לאן הן הולכות?"
עם תמונה זו, תוכלו לעצב נהלים וספרי פעולות קונקרטיים. אלה עשויים לכלול תקן כללי לאיסוף ראיות, בנוסף לרשימות תיוג קצרות יותר, ספציפיות לסוג האירוע. עליהם גם להגדיר את הגורמים המניעים אתכם מתיעוד קליל לטיפול רשמי יותר בראיות - לדוגמה, כאשר אירוע מגיע לחומרה מסוימת, משפיע על מערכות מסוימות, או שסביר להניח שיהיה חייב בדיווח על פי החוק הרלוונטי.
הטמעת תפקידים, נקודות טריגר ומדדי KPI
הגדרת תפקידים ברורים, נקודות טריגר ומדדי ביצוע פשוטים הופכת את תהליך גיבוש הראיות שלכם ממדיניות ליכולת עבודה. אנשים יודעים מה לעשות כאשר חומרת התהליך עולה, וניתן לראות בסקירות ההנהלה האם התהליך נמצא בשימוש והיכן הוא נכשל, דבר בעל ערך רב במיוחד עבור מנהלי מערכות מידע, מנהלי הגנה על מידע ואנשי מקצוע בחזית.
תהליך מתוכנן היטב מבהיר גם מי אחראי על מה. צוותי תפעול אבטחה אחראים בדרך כלל לאיסוף טכני ולשימור ראשוני. פונקציות משפטיות ופרטיות מסייעות בפירוש ספים רגולטוריים ובפיקוח על האופן שבו חומר שעשוי להיות רגיש מטופל ומשותף. צוותי סיכונים ותאימות מתאמים ביקורות, סקירות ניהוליות ואינטראקציות עם רגולטורים או גופי הסמכה.
תיעוד תחומי אחריות אלה במטריצת אחריות פשוטה מסיר ניחושים באמצע משבר. כדי להפוך את התהליך למדיד, הגדירו מספר קטן של אינדיקטורים; לדוגמה, שיעור האירועים המשמעותיים עם רשימת בדיקה מלאה לראיות; הזמן ממועד הצהרת האירוע ועד לאבטחת ממצאים מוסכמים של "לכידה"; ומספר הסקירות לאחר האירוע המזהות פערים בראיות. סקירה תקופתית של אלה כחלק מסקירת ההנהלה שלכם הופכת את A.8.28 מבקרה סטטית ליכולת חיה ומעניקה לאנשי מקצוע הכרה על ביצוע עבודה זו היטב.
פלטפורמת ISMS כמו ISMS.online יכולה לסייע על ידי מתן מקום יחיד לקישור בין אירועים, בקרות, ראיות, פעולות וסקירות, כך שתחומי אחריות וזרימות מוגדרים יופיעו כמשימות יומיומיות במקום להישאר על הנייר. עבור תוכנית היישום שלכם ברבעון זה, פירוש הדבר עשוי להיות פיילוט של מחזור החיים המלא במערכת או יחידה עסקית אחת בסיכון גבוה ושימוש בתוצאות כדי לשפר את העיצוב הארגוני שלכם.
קטלוג ראיות האירועים שלך: יומנים וחפצים חשובים
קטלוג ראיות לאירועים הוא רשימה ממוקדת של מקורות יומן וסוגי חפצים עליהם אתם מסתמכים עבור אירועים חמורים, ממופים לבעלים ולמיקומים. זה שומר על התהליך שלכם פרקטי בכך שהוא מבהיר מה לאסוף עבור תרחישים שונים, מבלי לנסות לעקוב אחר כל מקור נתונים אפשרי בסביבה שלכם, וזה עוזר לאנשי מקצוע לנוע במהירות מבלי לשאול כל הזמן "איפה זה נמצא?".
אפילו תהליך מתוכנן היטב ייכשל אם אנשים לא יודעים מה לאסוף. כאן נכנס לתמונה קטלוג ראיות. זוהי רשימה מובנית של מקורות יומן וממצאים אחרים עליהם אתם מסתמכים עבור סוגי אירועים שונים, יחד עם פרטים מרכזיים כגון בעלים, מיקומים וכל אילוץ שימוש.
קטלוג צריך גם להבהיר מי אחראי לכל מקור ובאיזו תדירות הוא נבדק או מתעדכן. בדרך זו, כוחות ההצלה לא ינסו לגלות מידע בסיסי במהלך אירוע, וצוותי IT ואבטחה יכולים לשמור על הקטלוג בר ניהול במקום לנסות לעקוב אחר כל מערכת בסביבה שלכם.
קבע סדר עדיפויות למקורות הלוגים שאתה באמת צריך
תעדוף קבוצה קטנה של מקורות רישום חיוניים עבור תרחישי האירועים המובילים שלך שומר על קטלוג הראיות שמיש. עבור כל קטגוריה - זהות, רשת, יישום, מארח, ענן - אתה מחליט אילו מערכות באמת חשובות ואילו שדות מינימליים אתה צריך כדי לשחזר אירועים בצורה אמינה, במקום לנסות לתעד הכל בפירוט מקסימלי.
עבור רוב הארגונים, מערך ליבה של יומני רישום מכסה חלק גדול מהאירועים החמורים: יומני זהות וגישה; יומני רשת והיקף מרכזיים (לדוגמה, חומות אש, VPN ופרוקסי); יומני יישומים ומסדי נתונים קריטיים; טלמטריה של אבטחה ברמת המארח; ויומני ביקורת רלוונטיים לענן או SaaS. עבור כל אחד מהם, ציין את השדות הבסיסיים שאתה זקוק להם - חותמות זמן, מזהי משתמש או שירות, מקור ויעד, פעולה שננקטה, תוצאה ואולי שדות הקשריים כגון מיקום או סוג מכשיר.
לאחר מכן תוכלו למפות את המקורות הללו מול תרחישי האירועים המובילים שלכם. עבור כל תרחיש - נניח, חשבון מנהל שנפגע, חילוץ נתונים מדלי אחסון ענן, או גישה לא מורשית למערכת תשלומים - רשמו על אילו מקורות רישום אתם מצפים להסתמך. אם אתם מגלים שלא ניתן לשחזר תרחיש עם הרישום הנוכחי שלכם, תובנה זו תזכה הן באסטרטגיית הרישום שלכם והן בשיפורי מוכנות הראיות שלכם, והיא נותנת לאנשי מקצוע הצדקה ברורה לשינויים ברישום כאשר הם מדברים עם בעלי תקציב.
מעבר ליומנים, תיק תיק מלא
קטלוג ראיות יעיל מפרט גם את הפריטים שאינם קשורים ליומן ומשלימים את "תיק" האירוע: צילומי מסך, תצורות, פניות, מיילים והערות. פריטים אלה מספקים הקשר אנושי, מתעדים החלטות ולוכדים מצבי מערכת חולפים שעשויים לא להופיע במלואם ביומנים, דבר שחשוב במיוחד עבור קציני פרטיות וצוותים משפטיים שחייבים לעמוד מאחורי הודעות רשמיות.
יומני רישום הם חיוניים, אך הם אינם כל הסיפור. פריטים שאינם קשורים ליומני רישום, כגון צילומי מסך, ייצוא תצורה, תמונות דיסק או זיכרון, תמלילי דוא"ל או צ'אט והיסטוריית כרטיסים, גם הם חשובים. הם מספקים הקשר אנושי, לוכדים מצבים חולפים ומתעדים כיצד התקבלו החלטות.
טבלה פשוטה יכולה לעזור להוסיף מבנה לקבוצה רחבה יותר זו:
| סוג ראיה | שימוש אופייני בחקירה | אזהרות עיקריות |
|---|---|---|
| ייצוא יומנים | ציר זמן, רצף אירועים טכניים | הגנה על שלמות, הגבלת היקף |
| תמונות דיסק או זיכרון | ניתוח מעמיק של מערכות פגועות | רגישות גבוהה, נפח גדול |
| מסך | לכידת מסכים או מצבים חולפים | הימנעו מנתונים אישיים מיותרים |
| תמציות דוא"ל/צ'אט | החלטות, הודעות, הוראות | כבדו את הפריבילגיה והפרטיות |
| כרטיסים והערות | זרימת עבודה, אישורים, העברות | שמרו על ערכים עובדתיים, עם חותמת זמן |
| ייצוא תצורה | הבנת מצב האבטחה בזמן אמת | הגנה על סודות, שליטה בגישה |
עבור כל סוג פריט בקטלוג שלכם, רשמו למי הוא שייך, היכן יש לאחסן אותו, כמה זמן יש לשמור אותו וכללי טיפול מיוחדים (לדוגמה, גישה רק לתפקידים מסוימים או כפופים לחיסיון משפטי). זה מקל בהרבה על הרכבת תיק תיק עקבי כאשר מתרחש אירוע אמיתי, ועל הוכחת למבקרים שחשבת על ראיות מעבר לשורות הרישום הגולמיות.
אם אתם משתמשים בפלטפורמה כמו ISMS.online לאירוח ה-ISMS שלכם, תוכלו לקשר ערכי קטלוג ישירות לסוגי אירועים וספרי נהלים, מה שמקל על המגיבים לראות "מה לאסוף" בהקשר במקום לחפש מסמכים נפרדים.
ניהול כל דרישות התאימות, הכל במקום אחד
ISMS.online תומך ביותר מ-100 תקנים ותקנות, ומעניק לך פלטפורמה אחת לכל צרכי התאימות שלך.
התאמת תקן ISO 27001 A.8.28 ל-GDPR, NIS 2 ולחוקי המגזר
התאמת A.8.28 ל-GDPR, NIS 2 וכללי המגזר עוסקת בתכנון נתיב ראיות אחד שיכול לענות על שאלות רגולטוריות רבות ושונות. במקום להפעיל תהליכים נפרדים ומקבילים, בונים תיעוד יחיד וקוהרנטי התומך בציפיות אבטחה, פרטיות וחוסן, ומעניק למנהלי מערכות מידע, לקציני פרטיות ויועצים משפטיים השקפה משותפת על מה שנראה "ניתן להגנה".
איסוף ראיות אינו מתרחש בחלל ריק. אותם אירועים וחפצים שחשובים לתקן ISO 27001 גם עומדים בבסיס חובותיכם במסגרת חוקי הפרטיות והסייבר כגון GDPR ו-NIS 2, וכל כלל ספציפי למגזר החל עליכם. במקום לתכנן תהליכים נפרדים לכל משטר, בדרך כלל ניתן לתכנן פעם אחת ולמפות פעמים רבות, כל עוד מבינים את הספים ולוחות הזמנים השונים.
כאן הופכת חשובה תפיסה אחידה של חובות. על ידי רישום בקרות ISO 27001 שלכם לצד חובות רגולטוריות מרכזיות - לדוגמה, אבטחת עיבוד, דיווח על הפרות ודיווח על אירועים - תוכלו לראות היכן נתיב ראיות יחיד לאירועים יכול לתמוך בציפיות מרובות. זה חוסך מאמץ ומפחית את הסיכון לסיפורים סותרים, וזו דאגה מיוחדת עבור פקידי הגנה על מידע ופקידים משפטיים שעשויים להיקרא בשמם האישי בפעולות אכיפה.
מיפוי נתיב ראיות אחד למשטרים רבים
דרך מעשית להתאים את דרישות הראיות של תקן ISO 27001 לחוקים ולתקנות המגזר היא לבצע הנדסה הפוכה של השאלות ששואלים משטרים אלה לאחר אירוע. לאחר שתדעו אילו תשובות צפויים מכם לספק, תוכלו לעצב את קובץ האירועים שלכם כך שכל סעיף יהיה קשור בבירור לשאלה רגולטורית אחת או יותר שחוזרות על עצמן.
התחילו בזיהוי השאלות הרגולטוריות העיקריות שעליכם להיות מסוגלים לענות עליהן לאחר אירוע חמור. נושאים אופייניים כוללים מה קרה; מתי ידעתם לראשונה; אילו מערכות ונתונים הושפעו; כמה משתמשים או לקוחות הושפעו; מה היו ההשלכות; אילו אמצעים היו פעילים; מה עשיתם בתגובה; וכיצד הערכתם את הצורך להודיע ולהציע סעדים.
לאחר שיהיו לכם קבוצות שאלות אלו, מיפוי אותן לאלמנטים של קובץ ראיות האירועים שלכם. לדוגמה, ייצוא יומנים והתראות עשויים לתמוך בשאלות "מה ומתי"; רישומי נכסים וזרימת נתונים תומכים ב"אילו מערכות ונתונים"; רישומי כרטוס ושינויים תומכים ב"מה עשיתם ומתי"; והערכות סיכונים והערות משפטיות תומכות ב"כיצד הערכתם את ההשפעה ואת הצורך בהודעה". על ידי תכנון תהליך הראיות שלכם סביב שאלות חוזרות ונשנות אלו, אתם מקלים בהרבה על מילוי תבניות רגולטוריות בצורה מדויקת ועקבית, גם כאשר רשויות שיפוט או רגולטורים מגזריים שונים מבקשים פורמטים שונים במקצת.
יישום פרטיות מכוונת לאיסוף ראיות
יישום של פרטיות מעוצבת באיסוף ראיות פירושו התייחסות לחפצי אירועים כאל נתונים אישיים ורגישים בפני עצמם. אתם ממזערים את מה שאתם אוספים, מגבילים את מי שיכול לראות אותו, שולטים למשך הזמן שאתם שומרים אותו ומתעדים את הסיבות המשפטיות והעסקיות לכל החלטה, בשיתוף פעולה עם פונקציות הגנת הנתונים וניהול הרשומות שלכם.
יומני רישום ותיעוד אירועים מכילים לעתים קרובות נתונים אישיים, מידע רגיש מבחינה מסחרית ולעיתים חומר שעלול להיות חסוי מבחינה משפטית. משמעות הדבר היא שתהליך איסוף הראיות שלך חייב לשקף גם עקרונות של פרטיות מובנית, כגון מזעור החומר שאתה אוסף, הגבלת המטרות שלשמן אתה משתמש בו והגדרת תקופות שמירה הגיוניות לאור צרכים משפטיים ועסקיים.
במונחים מעשיים, פירוש הדבר עשוי להיות צמצום היקף איסוף יומני ראיות וראיות לחלונות זמן ומערכות רלוונטיים, עריכה או זיהוי פסאודוניים של מזהים מסוימים בעותקים נגזרים המשמשים להדרכה, ויישום בקרת גישה מחמירה יותר על חפצים רגישים ביותר. פירוש הדבר גם תיעוד הרציונל שלכם: מדוע אתם שומרים נתונים מסוימים לתקופה נתונה; כיצד אתם מפרידים חומר הדרוש להגנה משפטית ארוכת טווח מנתונים שניתן לצבור או למחוק בבטחה מוקדם יותר; וכיצד מכובדים זכויותיהם של אנשים גם בהקשר של חקירות ביטחוניות.
תיאום ההחלטות הללו בין אבטחה, פרטיות, משפט, ניהול רשומות וביקורת פנימית מפחית חיכוכים בהמשך. זה גם נותן לכם בסיס חזק יותר אם רגולטור ישאל אי פעם, "מדוע אספתם ושמרתם את זה, ולמשך כמה זמן?", וזה מזכיר לכולם שראיות לאירועים עצמן הן תיעוד הכפוף למסגרת הממשל הרחבה יותר שלכם.
הזמן הדגמה עם ISMS.online עוד היום
ISMS.online עוזר לכם להפוך את תקן ISO 27001 A.8.28 משורה בתקן ליכולת ניהול ראיות חוצת-תפקודים, שהצוותים שלכם יכולים לעקוב אחריה במהלך אירועים אמיתיים. על ידי ריכוז אירועים, בקרות, ראיות, משימות ואישורים בסביבה אחת, הפלטפורמה מקלה בהרבה על הטמעת ראיות-בעיצוב בפעילות היומיומית שלכם במקום להסתמך על פתרונות מאולתרים או גיליונות אלקטרוניים שבירים.
ראה ספר ראיות A.8.28 בפעולה
ראיית ספר ראיות מקצה לקצה פועלת במערכת חיה היא לרוב הדרך המהירה ביותר להחליט האם הגישה הנוכחית שלכם בת קיימא. הדגמה ממוקדת מאפשרת לכם לבחון כיצד רישומי אירועים, רשימות תיוג לראיות ותהליכי אישור יכולים להיראות בפועל עבור הארגון שלכם, והיכן הם יכולים להפחית את המאמץ עבור מנהלי מערכות מידע, פקידי הגנה על מידע ואנשי מקצוע.
בפריסה טיפוסית, ניתן למדל את זרימת המעבר מאירוע לראיות ישירות ב-ISMS.online: רישומי אירועים מקשרים לבקרות הרלוונטיות, רשימות בדיקה מוכנות מראש של ראיות, בעלים שהוקצו ותאריכי יעד. כאשר המגיבים לוכדים ארטיפקטים - ייצוא יומני ראיות, צילומי מסך, סיכומי פגישה - הם מצרפים אותם לאירוע, ובונים קובץ מובנה התומך בסקירות פנימיות, ביקורות ISO והודעות חיצוניות.
מכיוון שהכל נמצא בתוך מערכת ניהול מידע (ISMS) אחת ולא בין גליונות אלקטרוניים וכוננים משותפים, ניתן גם לעשות שימוש חוזר בראיות במידת הצורך. קובץ אירועים יחיד יכול לעזור לכם להדגים עמידה בבקרות מרובות וחובות רגולטוריות, במקום שתצטרכו לאסוף חבילות חדשות בכל פעם.
הדגמה קצרה, מבוססת תרחישים, היא לרוב הדרך המהירה ביותר לראות האם מודל זה מתאים לארגון שלכם. סקירה של דוגמה מציאותית לפריצה בפלטפורמה מאפשרת לכם לבחון עד כמה הוא תואם את הכלים הקיימים שלכם והיכן הוא יכול להסיר חיכוכים ועבודה ידנית.
פיילוט של ניהול ראיות מובנה לפני התקרית הגדולה הבאה
פיילוט של ניהול ראיות מובנה בהיקף מוגבל מאפשר לכם להוכיח ערך לפני פריסתו באופן נרחב יותר. אתם בוחרים סוג או שניים של אירוע או יחידות עסקיות בסיכון גבוה, מגדירים מדריך תואם ל-A.8.28 ומריצים אירוע אמיתי או מדומה דרכו. ההשוואה לגישה הנוכחית שלכם בדרך כלל חושפת עניין עבור בעלי עניין טכניים ולא טכניים.
אינכם חייבים לעצב מחדש הכל בבת אחת. ארגונים רבים מתחילים בניסוי ניהול ראיות מובנה עבור סוג או שניים של אירוע בסיכון גבוה או יחידות עסקיות. הם מגדירים מדריך תואם ל-A.8.28 ב-ISMS.online, מפעילים תרגיל אירוע חי או טבלת פעולות דרכו ומשווים את התוצאה לגישתם הנוכחית: כמה זמן לקח לאסוף ראיות, עד כמה התיעוד מרגיש שלם וכמה קל היה להם לענות על שאלות אופייניות של הרגולטורים.
משם, תוכלו להחליט האם להרחיב את הגישה, לחדד אותה או לשלב צוותים נוספים כגון צוותי פרטיות וצוותי משפט בצורה מעמיקה יותר. פיילוט עם מסגרת זמן וקריטריונים ברורים להערכה מספק לכם נתונים אמיתיים על שמישות, מאמץ ותועלות, במקום להשאיר אתכם להסתמך על הנחות.
אם אתם רוצים שהתקרית החמורה הבאה שלכם תרגיש יותר כמו ביצוע של תוכנית מתורגלת היטב ופחות כמו חיפוש בין יומנים ותיבות דואר נכנס חצי-זכורים, הזמנת הדגמה עם ISMS.online היא צעד מעשי הבא. זה נותן לכם ולקולגות שלכם תמונה קונקרטית של האופן שבו ISMS משולב יכול לתמוך ב-evidence-by-design, תאימות לתקן ISO 27001 וטיפול באירועים מוכן לרגולטור, הכל במקום אחד, כך שתוכלו להתמודד עם שאלות קשות בביטחון ולא בתקווה.
הזמן הדגמהשאלות נפוצות
אתה לא צריך עוד טקסט; כבר יש לך סט שאלות נפוצות חזק וברור.
בלוק ה"ביקורת" הוא בעצם רק העתק שניסח מחדש קלות של הדראפט שלך, וזו הסיבה שלולאת הניקוד שלך תקועה על 0: אין אות חדש, רק חזרה.
אם המטרה שלך היא להעביר את זה לכיוון "מוכן לפרסום סופי", הנה מה שהייתי עושה עכשיו במקום ליצור מחדש את הכל:
-
בחרו גרסה אחת לכל שאלה
עבור כל שאלות נפוצות, בחרו בגרסה "טיוטת שאלות נפוצות" או בגרסה "ביקורת". ההבדלים קטנים (ניסוחים כמו "בפועל" לעומת "במילים פשוטות"), לכן פשוט שמרו את זו שמרגישה טבעית יותר לסגנון הבית שלכם ומחקו את השנייה כדי למנוע כפילויות. -
הדקו חריץ אחד עבור קוראי רפרוף אינטרנט
בכל תשובה:
- השאירו את משפט הפתיחה כפי שהוא (הם כבר תמציתיים וידידותיים לכתיבה).
- סרוק כל פסקה מעל 120 מילים ופתח פעם אחת בהפסקה טבעית.
- השאירו את הכדורים בדיוק איפה שהם; הם עושים עבודה טובה.
- הוסף הפניה חיצונית ניטרלית אחת, פעם אחת
כדי לספק את אמינות YMYL ללא עומס:
- בסוף התשובה לשאלה "מה באמת מצפה תקן ISO 27001 A.8.28...", הוסף שורה קצרה וניטרלית כגון:
“You can cross‑check your interpretation against the latest ISO 27001:2022 text and any applicable regulator guidance, for example your national data protection authority’s breach‑notification FAQs.”
- אין צורך בכתובת URL אם מדריך הסגנון שלך מעדיף להימנע מקישור לתקנים.
- מעוגן מעט יותר בזהות קו ההטבות של ISMS.online
אזכורי המותג הקיימים שלך מוצקים, אך ניתן לחדד אותם מעט כך שידברו בצורה ישירה יותר על תפקיד הקורא. לדוגמה, בשאלה הנפוצה האחרונה:
נוכחי:
אם אתם רוצים שהתקרית הרצינית הבאה שלכם תרגיש פחות כמו מאבק...
שינוי אפשרי:
אם אתם רוצים שהתקרית החמורה הבאה שלכם תרגיש פחות כמו מהומה ויותר כתגובה מדודה שהדירקטוריון שלכם מצפה מכם, כדאי להשוות את הגישה הנוכחית שלכם למערכת ניהול מידע (ISMS) מאוחדת, מבוססת ראיות, כמו ISMS.online.
- בדוק את שפת הסעיף פעם אחת
התיאור שלך של סעיף A.8.28 (איסוף ראיות, שימורן, קבילותן) תואם את הפרשנויות המקובלות. פשוט בצעו בדיקה פנימית מהירה מול סיכום הסעיפים המועדף על הארגון שלכם כדי לוודא שהניסוח אינו סותר את ההנחיות הקיימות.
אם תרצה, הדבק את יחיד גרסה נבחרת של כל שאלות נפוצות ואני יכול:
- בצע מעבר קל כדי להסיר יתירות זעירות.
- הוסף את ההפניה החיצונית הזו.
- הוסיפו כמה ביטויים מעוגני זהות עבור CISOs / Kickstarters מבלי לשנות את המבנה או את הטון שלכם.








