סיכוני יציאה משירותי MSP שלעתים קרובות מתעלמים מהם
יציאה מהרשת (Offboarding) היא מסוכנת עבור ספקי שירותי ניהול שירותים (MSPs) משום שנתוני לקוחות נשארים מפוזרים לעתים קרובות בכלים, גיבויים ופלטפורמות זמן רב לאחר סיום החוזים. אפילו כאשר מבטלים גישה וסוגרים את הפניות האחרונות, מזהים ותוכן עדיין יכולים להישאר במקומות שאף אחד לא מנהל באופן פעיל. אם נתונים אלה נחשפים או מוטלים בספק מאוחר יותר, תתקשו להצדיק את נוכחותם בפני רואה חשבון, רגולטור או לקוח לשעבר. יציאה מהרשת יכולה להרגיש גמורה כאשר הפנייה הסופית נסגרת, אך עבור ספקי שירותי ניהול שירותים רבים, זה בדיוק הזמן שבו הסיכון השיורי גדל. נתונים שנותרו במערכות ישנות, גיבויים או מאגרי הערות עדיין נמצאים בשליטתכם, למרות שאין לכם עוד סיבה לגיטימית להחזיק בהם, ו-ISO 27001 A.8.10 מצפה מכם לנהל את שלב סוף החיים הזה במכוון ולא להשאיר אותו להרגל או לזיכרון. סיכומים עצמאיים של ISO 27001, כגון סקירה זו של מערך הבקרה 27001, מדגישים כי מידע שכבר אינו נדרש צריך להיות מוסר או להפוך לבלתי נגיש באופן מתוכנן ומונע מדיניות ולא להשאיר ליד המקרה.
מאמר זה מציע הנחיות כלליות ל-MSPs בנוגע למחיקה מאובטחת ויציאה מהמערכת. אין מדובר בייעוץ משפטי; עליכם לאשר התחייבויות ספציפיות עם היועצים המשפטיים, הפרטיות והרגולטוריים שלכם.
הסיכון לא נעלם כאשר חוזה מסתיים; הוא פשוט משנה צורה אם הנתונים שלך נשארים מאחור.
מדוע "offboarded" לעיתים רחוקות פירושו "הנתונים נעלמו"
""Offboarded"" לעיתים רחוקות פירושו "כל הנתונים נעלמו" מכיוון שערכת כלים טיפוסית של MSP משאירה עקבות של לקוח במערכות רבות ושונות. סוכני ניטור וניהול מרחוק, כרטיסי תמיכה, תמלולי צ'אט, ויקי תיעוד, ארכיוני יומנים, תמונות מצב בענן וערכות גיבוי שומרים לעתים קרובות מזהים, תצורות ולפעמים ערכות נתונים מלאות זמן רב לאחר סיום החוזה. אם תכבה רק שירותים חיים, ייתכן שעדיין תחזיק כמות משמעותית של מידע שהיה אמור לעבור לנתיב מחיקה או אנונימיזציה מתוכנן.
עבור לקוחות מפוקחים, נתונים שיוריים אלה יכולים להפוך לבעיה בכמה דרכים. אירוע מאוחר יותר עלול לחשוף רשומות שהייתם אמורים להסיר, בדיקת נאותות עלולה להדגיש נתיבי גישה "זומביים", או שביקורת עלולה לבקש ראיות לכך שנתוני לקוחות מחוץ למערכת נמחקו בהתאם לכללי השמירה. ללא תצוגה מובנית של היכן נמצא המידע וכיצד הוא מנוקה, אתם מסתמכים על הזיכרון והכוונות הטובות של המהנדסים האינדיבידואליים.
בסקר שנערך בשנת 2025, רק כאחד מכל חמישה ארגונים אמר כי נמלט לחלוטין מאובדן נתונים בשנה הקודמת.
כיצד יציאה לא מלאה מהחברה הופכת לבעיית אבטחה ותאימות של ממש
יציאה לא שלמה הופכת לבעיית אבטחה ותאימות חמורה כאשר גישה, עותקי נתונים ופתרונות לא רשמיים ממשיכים להתקיים גם לאחר סיום הקשר. חשבונות שירות ישנים, מפתחות אוטומציה או הערות לא מנוהלות יכולים ליצור נתיבי תקיפה שאף אחד כבר לא מחזיק בהם. מנקודת מבט של תקן ISO 27001 A.8.10, משמעות הדבר היא שהמידע עדיין בשליטתך למרות שאין עוד סיבה לגיטימית לשמור אותו.
רוב הארגונים בסקר ISMS.online לשנת 2025 אמרו כי הושפעו מלפחות אירוע אבטחה אחד של צד שלישי או ספק בשנה האחרונה.
סיכון היציאה מהמחלקה אינו נובע רק מקבצים שנותרו. נתיבי גישה יכולים להימשך בדרכים עדינות, לדוגמה:
- אישורי מנהל משותפים שנשארים תקפים במערכות שנוהלו בעבר
- מפתחות API וחשבונות שירות לאוטומציה שלעולם לא מבוטלים
- פורטלים של SaaS של צד שלישי שמשכפלים נתונים לאחר שהשירות הראשי מפסיק לפעול
צללים של מערכת יחסים ישנה יכולים להמשיך לחיות בדרכים שאף אחד מחברי צוות לא מבין במלואן.
מערכות מידע צלליות (Shadow IT) מעצימות זאת. טכנאים יוצרים לעיתים שיתופי קבצים אד-הוק, מאגרי רשימות אישיות או גיבויים של ערוצי צד כדי לבצע עבודה במהירות. אם מיקומים אלה חסרים במלאי הנכסים והנתונים שלך, הם לא יופיעו באף רשימת בדיקה ליציאה מהמערכת. עם זאת, אם מידע במיקומים אלה ייחשף מאוחר יותר, הלקוח והרגולטור עדיין יראו זאת כאחריותך.
כדי לנהל סיכון זה באופן העומד בתקן ISO 27001 A.8.10, עליכם להתייחס ליציאת לקוחות מהחברה כאל אירוע מחזור חיים בעל סיכון גבוה. משמעות הדבר היא הבנת שטח הנתונים האמיתי שלכם, הוספת תרחישי יציאה מהחברה למאגר הסיכונים שלכם ותכנון בקרות שעובדות על כל מערך הכלים שלכם, ולא רק על התשתית המרכזית שלכם. סיכונים אלה אינם רק טכניים; הם גם מעצבים את האופן שבו לקוחות פוטנציאליים ולקוחות לשעבר שופטים את המקצועיות שלכם כשהם שואלים מה באמת קורה לנתונים שלהם בסוף הקשר.
הזמן הדגמהמדוע מחיקת מידע היא כיום גורם בידול אסטרטגי
מחיקת מידע היא כיום גורם מבדיל אסטרטגי עבור ספקי שירותי ניהול נתונים (MSPs) משום שהיא מעצבת את מי שבוחר בכם, כיצד ביקורות מרגישות וכמה חלק מסתיימות מערכות יחסים. קונים שואלים יותר ויותר מה קורה לנתונים שלהם ביציאה, לא רק במהלך השירות החי, ושאלוני אבטחה ופרטיות כוללים יותר ויותר שאלות מפורשות על שמירה, מחיקה וטיפול בסוף חוזה, כפי שמשתקף בהנחיות בסגנון הערכה משותפת על שמירת נתונים ושאלונים המותאמים ל-GDPR כמו דיון זה על שאלוני אבטחה ושמירת נתונים. אם אתם יכולים להסביר ולהוכיח מחיקה בצורה ברורה, אתם מאותתים על בגרות, מפחיתים חיכוכים ונמנעים ממחלוקות כאשר חוזים נסגרים, במקום להתייחס למחיקה כאל אינסטלציה שקטה מוסתרת מאחורי מדדי שירות גלויים יותר. כיום, זה משפיע יותר ויותר על מי שבוחר בכם, כיצד מתנהלת בדיקת נאותות אבטחה וכמה יקרות הופכות מחלוקות, כך שעבור MSP המתמקד בצמיחה, היכולת להסביר ולהוכיח מחיקה יכולה להיות חשובה לא פחות מהוכחת זמינות וזמן פעולה, במיוחד כאשר לקוחות מטפלים בנתונים רגישים או מוסדרים.
סקר מצב אבטחת המידע ISMS.online לשנת 2025 אסף תשובות מכ-3,001 אנשי מקצוע בתחום אבטחת מידע ברחבי בריטניה וארה"ב.
כיצד מחיקה ויציאה משירות משפיעות על מכירות וחידושים
מחיקה ויציאה משירות משפיעות על מכירות וחידושים, משום ששאלוני אבטחה, בקשות להצעות מחיר וראיונות עם בעלי עניין חוקרים יותר ויותר את נוהלי סיום השירות שלכם בפירוט. צוותי סיכונים, פרטיות ומשפט רוצים לשמוע סיפור ברור על החזרת נתונים, שמירתם והשמדתם במערכות ייצור, גיבויים ושירותי צד שלישי. קונים ארגוניים ומגזר ציבורי שואלים כיום באופן שגרתי שאלות מפורטות על מה שקורה למידע שלהם בגיבויים, יומנים ופלטפורמות צד שלישי, לא רק בייצור. מסגרות הערכה משותפות ותבניות שאלונים בודקות בדרך כלל כיצד אתם מטפלים באחסון לטווח ארוך, שמירת גיבויים וזרימת נתונים של צד שלישי בסיום החוזה ואחריו, מה שמחזק ציפייה זו ומקשה על הסתרת נוהלי עבודה חלשים מאחורי תשובות מעורפלות.
נוהלי מחיקה ברורים תומכים גם בציפיות לפרטיות ולהגנת נתונים. עקרונות כגון מזעור נתונים והגבלת אחסון מחייבים אותך לשמור נתונים אישיים לא יותר מהנדרש למטרות המוסכמות. עקרונות אלה משתקפים במפורש ב-GDPR ובפרשנויות על חובות שמירה ומחיקה מצד רגולטורים ומומחי פרטיות, המדגישות כי ארגונים לא צריכים לשמור נתונים אישיים יותר מהנדרש למטרות המוצהרות, כפי שנדון בניתוחים כגון סקירה זו של חובות שמירת ומחיקת נתוני GDPR. כאשר אתה יכול להסביר שמידע של לקוחות מוחזר, הופך לאנונימי או נמחק בצורה מאובטחת ברגע הנכון, אתה מציג טיעון חזק בפני פקידי הגנת המידע של הלקוחות, צוותים משפטיים ומנהלי מערכות מידע של לקוחות שהשירות שלך לא ייצור עבורם חשיפה ארוכת טווח.
מנקודת מבט של מערכת יחסים, הסבר פשוט וכנה על מה שאתם מוחקים, מה אתם שומרים ולכמה זמן מפחית אי הבנות בעת היציאה. מחלוקות לגבי "מי עדיין מחזיק במה" הן לעתים קרובות סימן לכך שהציפיות מעולם לא היו תואמות. התייחסות למחיקה כחלק מהצעת הערך שלכם מאפשרת למנהלי לקוחות ולמנהלי מערכות מידע וירטואליות למקם את היציאה מהחברה כשלב מובנה וצפוי במחזור חיי הלקוח ולא כסוף מבולגן ועוין.
מדוע סיפור מחיקה מתועד בונה אמון
סיפור מחיקה מתועד בונה אמון משום שהוא מפגין משמעת, שקיפות וכבוד לנתוני הלקוח. סיפור מחיקה מוסבר היטב עושה יותר מסתם סימון של תיבה של תאימות; הוא מראה שיש לך גישה ממושמעת ומכבדת למידע של אנשים אחרים. כאשר אתה יכול להראות שאתה:
- להבין היכן מאוחסנים נתוני הלקוח
- הסכימו על כללים כתובים לשמירה ומחיקה
- עקוב אחר ספר הפעלה חוזר על עצמו
- יכול להציג סט תמציתי של ראיות אם מתבקש
אתם מפחיתים את העומס הקוגניטיבי על צוותי הסיכון והרכש של לקוחות פוטנציאליים. הם משקיעים פחות זמן בחיפוש אחר הבהרות, ואתם משקיעים פחות זמן בכתיבה מחדש של תשובות מותאמות אישית. עם הזמן, זה מקצר את מחזורי בדיקת הנאותות של האבטחה וממצב את ספק שירותי ה-MSP שלכם כשותף בטוח יותר לטווח ארוך.
כאן גם פלטפורמה כמו ISMS.online יכולה לעזור. על ידי ריכוז מדיניות, תהליכים ורשומות למחיקה ויציאה, תוכלו לתמוך בצוותים מסחריים עם שפה ומידע עקביים ומאושרים מראש, במקום להמציא מחדש הסברים לכל הזדמנות. התאמה זו עם מערכת ניהול חיה גם מאותתת למבקרים שסידור המחיקה שלכם הוא חלק מממשל מתמשך, ולא רק נרטיב מכירות.
ISO 27001 בקלות
יתרון של 81% מהיום הראשון
עשינו את העבודה הקשה בשבילך, ונתנו לך התחלה של 81% מרגע הכניסה. כל שעליכם לעשות הוא להשלים את החסר.
A.8.10 'מחיקת מידע' מפוענח עבור ספקי שירותי ניהול נתונים (MSPs)
נספח A.8.10 של תקן ISO 27001:2022 דורש ממך למחוק או להפוך לאנונימי כאשר הוא אינו נחוץ עוד, תוך שימוש בשיטות מאובטחות ומתוכננות. זה נראה קצר על הנייר, אך עבור MSP עם כלים מרובי דיירים, גיבויים ושירותי ענן, יש לכך השלכות רחבות, מכיוון שמידע במערכות, במכשירים ובמדיה האחסון שלך חייב להיות מוסר כאשר הוא אינו נחוץ עוד, תוך שימוש בשיטות המתאימות לכל סביבה בנוף עשיר בכלים ורב-דיירים שבו נתונים עוברים דרך ידיים ופלטפורמות רבות. טקסט הבקרה והערות היישום המשותפות מבהירים כי מידע שאינו נדרש עוד מסיבות עסקיות, משפטיות או רגולטוריות צריך להיות מוסר בצורה מאובטחת או מאנונימיזציה בהתאם לנהלים מתועדים, נקודה המשתקפת בסיכומים עצמאיים של ISO 27001 כמו סקירה כללית זו של בקרה אחר בקרה.
מה A.8.10 באמת מצפה ממך לעשות
סעיף A.8.10 מצפה מכם לנהל את כל מחזור חיי המידע: לאסוף, להשתמש, לאחסן, לגבות, לאחסן בארכיון ובסופו של דבר למחוק או להפוך נתונים לאנונימיים כאשר הם אינם נדרשים עוד. "לא נדרש עוד" צריך להיות מוגדר על ידי מדיניות השמירה שלכם, כמו גם בכל התחייבות משפטית, חוזית או רגולטורית מחמירה יותר. לאחר מכן, אתם זקוקים לשיטות מעשיות וראיות כדי להראות שזה אכן קורה.
מבחינה מעשית, הבקרה מצפה שתגדיר:
- איזה מידע אתם מחזיקים והיכן
- כאשר כל קטגוריה מפסיקה להיות נדרשת
- כיצד זה יימחק או יהפוך לאנונימי
- איך תוכיח שזה באמת קורה
עבור ספק שירות ניהול שירותים (MSP), התחום כולל מידע הקשור ללקוח בסביבות ייצור שאתה מארח, במאגרי תצורה, בכלי אבטחה, בפלטפורמות ניטור, ביומנים וגיבויים, ובכלי שיתוף פעולה המשמשים לאספקת השירות. הוא משתרע גם על שירותים רלוונטיים של צד שלישי שבהם אתה שולט בקשר או בתצורה.
סעיף A.8.10 אינו דורש שלמות או מחיקה מיידית של כל עותק בסוף החוזה. הוא דורש שתשקלו היטב כיצד יטופל כל סוג מידע, שתיישמו שיטות מתאימות, ושניתן יהיה לייחס את החלטותיכם למדיניות, כללי שמירה והערכת סיכונים.
כיצד A.8.10 מתחבר לחלקים אחרים של מערכת ה-ISMS שלכם
A.8.10 מתחבר קשר הדוק לבקרות אחרות של תקן ISO 27001, כגון ניהול נכסים, הגבלת גישה וגיבויים. לא ניתן לנהל מחיקה היטב אם אינך יודע אילו מערכות מחזיקות נתוני לקוחות, מי יכול לגשת אליהם וכמה זמן נשמרים הגיבויים. מחיקה מקיימת גם אינטראקציה עם בקרות ספקים, מכיוון שספקי ענן ו-SaaS ממלאים לעתים קרובות תפקיד באופן שבו נתונים מוסרים בפועל.
מחיקת מידע אינה עומדת בפני עצמה. היא קשורה קשר הדוק לבקרות גיבוי (כגון A.8.13), רישום וניטור, ניהול גישה (כגון A.8.3), ניהול נכסים והסכמי ספקים. לדוגמה, אסטרטגיית הגיבוי שלך קובעת כמה זמן הנתונים נשמרים וכיצד מתבצעת ניקוי בסוף חיי המדיה. נוהלי רישום משפיעים על אילו נתונים אישיים ומזהי לקוחות מופיעים בארכיונים ארוכי טווח. בקרות ספקים מכתיבות כיצד ספקי ענן וספקי SaaS מטפלים במחיקה בשמך. מדריכי יישום ISO 27001, כמו סקירת יישום BSI זו, מדגישים כי יש לתכנן כללי מחיקה לצד בקרות גיבוי, רישום, גישה ובקרות ספקים, מכיוון שכל שכבה משפיעה על כמה זמן המידע באמת נשמר.
בהקשר של ניהול מערכות ניהול (MSP), טריגרים של מחזור חיים חשובים במיוחד. טריגרים נפוצים כוללים:
- סוף הסכם שירותים ראשי
- סוף שירות ספציפי כגון גיבוי מנוהל
- פקיעת חובת שמירה חוקית או חוזית
- סגירת אירוע או חקירה ביטחונית
כל טריגר צריך לבוא לידי ביטוי בלוח הזמנים של שימור הנתונים ובספר ההדרכה של הצוות, כך שצוותים ידעו מתי לעבור מ"שמירה" ל"מחיקה או אנונימיזציה".
כ-41% מהארגונים בסקר ISMS.online לשנת 2025 ציינו ניהול סיכוני צד שלישי ומעקב אחר תאימות ספקים כאתגר מוביל.
זה גם עוזר להבהיר את ההבדל בין מחיקה, אנונימיזציה ופסודנונימיזציה:
- מחיקה: מסיר נתונים כך שלא ניתן עוד לשחזר אותם, לדוגמה מחיקה מאובטחת של דיסק.
- אנונימיזציה: מסיר מזהים כך שלא ניתן עוד לקשר את המידע לאדם או ללקוח, כגון צבירת נתוני יומן למדדים ללא כתובות IP.
- פסאודונימיזציה: מחליף מזהים אך עדיין מאפשר זיהוי מחדש עם נתונים נוספים, לדוגמה החלפת שמות משתמש באסימונים הפיכים.
תחת A.8.10, אנונימיזציה יכולה לעתים קרובות לספק את הדרישה שבה ברצונך לשמר נתוני מגמה מבלי לשמור רשומות ניתנות לזיהוי. ההנחיות בנושא אנונימיזציה וערך נתונים מציינות כי מערכי נתונים אנונימיים כראוי ניתנים לעתים קרובות לשמור לצורכי ניתוח מבלי להפר את ציפיות מגבלות האחסון, בתנאי שאנשים אינם ניתנים עוד לזיהוי, כפי שמודגש בדיונים כמו מאמר זה על חשיבות אנונימיזציה לעסקים מונעי נתונים.
מה למחוק, לשמור או להפוך לאנונימי בסוף החוזה
בסוף החוזה, אתם זקוקים למדיניות ברורה וניתנת להגנה לגבי אילו נתונים יימחקו, אילו יישמרו ואילו יהיו אנונימיים, מכיוון שהשאלות הקשות ביותר הן לעיתים רחוקות טכניות: הן מתמקדות במה תמחקו, מה תשמרו וכיצד תצדיקו את ההחלטות הללו אם יועמדו בפניהן ערעור מאוחר יותר. אם תוכלו להסביר ולתעד את הבחירות הללו במונחים פשוטים, יציאה מהחברה תהפוך לתהליך צפוי ולא משא ומתן מתוח, ובהירות זו גם עוזרת לכם להתאים את A.8.10 לפרטיות ולחובות חוזיות.
מתן קו ברור בין נתוני לקוחות לרשומות MSP
פריצה נקייה מתחילה בהפרדת נתונים שבבעלות הלקוח מהרשומות התפעוליות שה-MSP שלך זקוק להן באופן לגיטימי. בדרך כלל יש להחזיר או לייצא נתוני לקוחות ולאחר מכן למחוק אותם מהמערכות שלך לאחר שתקופות השמירה המוסכמות יפוגו. ניתן לשמור רשומות MSP מסיבות עסקיות או משפטיות מוגדרות, אך רק בצורה מינימלית ותחת כללי הגנה ומחיקה ברורים.
דרך מעשית להתחיל היא להבחין בין:
- מידע שהלקוח בבירור הבעלים שלו ושולט בו
- רישומים תפעוליים שה-MSP שלך צריך לשמור באופן חוקי
נתונים שבבעלות הלקוח כוללים בדרך כלל מערכי נתונים של ייצור, קבצי משתמשים, תיבות דואר, תוכן יישומים וגיבויים ספציפיים ללקוח שתחזקת בשמם. בדרך כלל יש להחזיר או לייצא נתונים אלה בפורמט שסוכם בחוזה ולאחר מכן למחוק אותם מהמערכות שלך לאחר תום תקופת השמירה.
רשומות תפעוליות בבעלות MSP כוללות לעתים קרובות פרטי חיוב, הערות תצורה, אירועי אבטחה ברמה גבוהה, רשומות שינויים ויומני רישום מינימליים הנדרשים כדי להדגים כיצד סופקו השירותים. ייתכן שתזדקקו לרשומות אלו לצורך דיווח כספי, ניתוח איכות השירות, סכסוכים מאוחרים יותר או חקירות אבטחה. שמירתן יכולה להיות מתאימה, אך רק אם:
- הקטגוריות מוגדרות בבירור במלאי הנתונים שלך
- תקופת השמירה מוצדקת על ידי צרכים משפטיים או עסקיים
- ההיקף מצטמצם למה שבאמת נחוץ
- הנתונים מוגנים ונמחקים בסוף התקופה שנקבעה
הבחנה זו עוזרת לך להצדיק מה נשאר, מה הולך ומדוע. התייחסות לכל קטגוריה כאל "לשמור ליתר ביטחון" פוגעת הן בעקרונות A.8.10 והן בעקרונות הגנת המידע.
הטבלה שלהלן מסכמת תוצאות אופייניות עבור קטגוריות מידע נפוצות בסוף החוזה.
| קטגוריה | דוגמאות אופייניות | תוצאת ברירת מחדל |
|---|---|---|
| נתוני ייצור של הלקוח | קבצי משתמש, תיבות דואר, תוכן יישומים, גיבויים של לקוחות | החזרה או ייצוא, ולאחר מכן מחיקה לאחר המונח |
| תצורה וניטור | תצורות RMM, רשימות מכשירים, כללי התראות | שמור על תצוגה מינימלית, לאחר מכן מחק/הפוך לאנונימי |
| רישומי שירות מבצעיים | כרטיסים, רישומי שינויים, אירועי אבטחה ברמה גבוהה | שמור לתקופה מוגדרת, ולאחר מכן מחק |
| נתוני מגמה מצטברים | מדדים אנונימיים, סטטיסטיקות אירועים | אנונימיזציה ושמירה לצורך ניתוח נתונים |
חריגים, העדפות לקוחות ודרישות ראיות משמעם שלוחות הזמנים הסטנדרטיים למחיקה אינם יכולים להיות נוקשים לחלוטין. החזקות משפטיות, חקירות או כללי מגזר עשויים לדרוש ממך להשהות את המחיקה עבור רשומות מסוימות. לקוחות עשויים לרצות מחיקה חזקה או חלשה יותר מברירת המחדל שלך. את כל אלה יש לטפל באמצעות אפשרויות מובנות, אישורים מתועדים ונקודות סקירה ברורות.
המורכבות גוברת כאשר חלים החזקות משפטיות, חקירות רגולטוריות או כללים ספציפיים למגזר. במקרים אלה, יש להשהות את לוחות הזמנים הרגילים למחיקה עבור הרשומות המושפעות תוך תיעוד מדוקדק ותחזוקתן בזמן. עליכם לתעד את הסיבה להחזקה, מי אישר אותה, איזה מידע נמצא בהיקף ומתי היא תיבדק. לאחר סיום ההחזקה, יש לחדש את המחיקה או האנונימיזציה בהתאם למדיניות שלכם.
ייתכן שללקוחות יהיו העדפות שונות. חלקם ירצו מחיקה אגרסיבית של כל החומר לאחר עזיבתם; אחרים יצפו לשמירה ממושכת של יומני רישום או היסטוריית אירועים מסוימים. במקום לכופף את התהליך מחדש עבור כל לקוח, ניתן להגדיר קבוצה קטנה של אפשרויות שמירה סטנדרטיות, שלכל אחת מהן השלכות תפעוליות ברורות, ולאפשר ללקוחות לבחור במסגרת מגבלות אלו במהלך הקליטה או משא ומתן מחדש על חוזה.
עבור כל החלטה של מחיקה לעומת שמירה, מומלץ לתעד נתיב ראיות. יומני החלטות, אישורים, הפניות למדיניות או סעיפים חוזיים רלוונטיים וקישורים להערכות סיכונים תומכות - כל אלה יכולים להימצא בתוך פלטפורמת ניהול הכרטיסים או מערכת ה-ISMS שלכם. כאשר שאלה מתעוררת חודשים או שנים לאחר מכן, תוכלו להראות שהתוצאה התבססה על תהליך מובנה ומותאם למדיניות ולא על העדפה אישית.
הטמעת היגיון זה בלוח הזמנים של שימור העובדים ובמפות נתוני הלקוחות פירושה שצוותי יציאה מהארגון אינם צריכים עוד להמציא כללים ברגע זה. הם פשוט מיישמים מודל מתועד שכבר נבדק על ידי בעלי עניין בתחום המשפט, הפרטיות והאבטחה.
שחררו את עצמכם מהר של גיליונות אלקטרוניים
הטמע, הרחב והרחיב את תאימותך, ללא כל בלגן. IO מעניק לך את החוסן והביטחון לצמוח בצורה מאובטחת.
בניית ספר הפעלה מאובטח וחוזר על עצמו ליציאה מהחברה
מדריך ליציאה מהמערכת (Offboarding) הניתן להחזרה על עצמה הופך מחיקה מאובטחת מפרויקט חד פעמי מלחיץ לחלק סטנדרטי במחזור חיי השירות שלכם. לאחר שאתם יודעים מה אמור לקרות לקטגוריות שונות של מידע, השלב הבא הוא לארוז אותו למדריך שצוותים יכולים לעקוב אחריו תחת לחץ, כך שיהיה להם נתיב ברור מהודעת חוזה למחיקה מאומתת, גם כאשר מערכות היחסים מתוחות או המערכות מורכבות. כאשר מדריך הפעולות קל לעקוב אחריו, יציאה מאובטחת הופכת צפויה וניתנת לביקורת ולא הרואית. אותו מדריך מספק גם חומר המועיל ישירות לפעילויות ביקורת פנימית וסקירת הנהלה במערכת ה-ISMS שלכם.
תהליך עבודה יעיל של שחרור חשבונות משקף את אופן פעולתם של ספקי שירותי ניהול שירותים (MSPs), הכולל כרטיסים, תורים, העברות ולחץ זמן. תהליך העבודה צריך להתחיל מטריגר ברור, להתקדם דרך שלבי גילוי והסכמה, ולהסתיים במחיקה מאומתת. כל שלב זקוק לבעלים וארטיפקטים ברורים, כך ששום דבר לא יהיה תלוי בזיכרון בלבד.
תהליך עבודה מעשי של שחרור מתחיל בדרך כלל עם טריגר ברור, כגון הודעה רשמית במסגרת הסכם השירותים הראשי. משם ניתן להגדיר שלבים כגון תכנון, הסכם, ביצוע ואימות.
שלב 1 – תכנון וגילוי נתונים
אשר את היקף השירותים, זיהוי מערכות המחזיקות נתוני לקוחות ופתיחת פניות מתואמות לכל זרם עבודה.
שלב 2 – הסכמה על פורמטים ולוחות זמנים של מסירה
הסכימו על פורמטי ייצוא, שיטות אספקה ולוחות זמנים כך שהצוותים הטכניים והלקוח יחוו את אותן ציפיות.
שלב 3 – ביטול או שינוי גישה
הסרה או התאמת חשבונות, מפתחות ותפקידים בתשתיות, פלטפורמות SaaS ושירותי צד שלישי ברצף מבוקר.
שלב 4 – ייצוא נתונים וקבלת אישור הלקוח
ייצוא מערכי נתונים מוסכמים, מסירתם בצורה מאובטחת ותפיסת אישור בכתב שהלקוח קיבל את מה שציפה לו.
שלב 5 – מחיקה או אנונימיזציה של מידע שיורי
יש ליישם את שיטות המחיקה והאנונימיזציה הסטנדרטיות שלכם בכלי הייצור, היומנים, הגיבויים וכלי שיתוף הפעולה.
שלב 6 – אימות וחתימה
ודא שהמחיקה עבדה, סגור פניות ותעד אישורים כדי שתוכל להראות מה קרה אם תישאל מאוחר יותר.
ייצוג זרימה זו כדיאגרמת מסלול שחייה פשוטה, עם נתיבים עבור דלפק השירות, תשתית, אבטחה, ניהול חשבונות ומשפט, עוזר לכולם להבין כיצד פעולותיהם משתלבות. זה גם חושף צווארי בקבוק, כגון תלות במהנדס יחיד או פערים שבהם אף אחד לא אחראי במפורש לאימות המחיקה.
מודל אחריות, כמו RACI, מבהיר עוד יותר את נושא הבעלות. תפקיד אחד עשוי להיות אחראי על אישור מחיקה לאחר בדיקת התחייבויות חוזיות ועמידות משפטיות. תפקידים אחרים יהיו אחראים על יישום צעדים טכניים ספציפיים או על אימות ראיות. כאשר מודל זה מוטמע במחברות ריצה, קליטה של עובדים חדשים ותצורת זרימות העבודה של שירותי ה-PSA שלכם, אתם נמנעים מהשארת החלטות קריטיות למי שקורה שאוסף כרטיס.
הפיכת תהליך היציאה מהארון לעקבי, יעיל וגמיש
כדי להיות שימושי, מדריך העבודה חייב להרגיש מציאותי עבור המהנדסים ומנהלי החשבונות המשתמשים בו. הוא צריך להתמודד עם מצבים מביכים כמו חשבוניות שלא שולמו, סכסוך עם לקוח שעוזב או תקריות לא פתורות, תוך הבטחה שעבודות אבטחה חיוניות מתבצעות בזמן. אתם זקוקים גם ללולאות משוב כדי שכל יציאה מהשירות תשפר את הבאה.
יציאה מהחברה מתרחשת לעיתים רחוקות בתנאים אידיאליים. ייתכנו חשבוניות שלא שולמו, מערכות יחסים מתוחות או חקירות אירועים מקבילות. התכנון שלך צריך לצפות את המציאות הזו. לדוגמה, ייתכן שתדרוש שצעדי אבטחה מסוימים, כגון ביטול גישה וייצוא נתונים, לא יהיו תלויים בפתרון סכסוכים מסחריים, ועדיין לאפשר לך להשהות עבודה לא חיונית אם החוזים מאפשרים זאת.
פיילוט של מדריך הפעולה על לקוחות בסיכון נמוך תחילה יכול להפחית את הסיכון באימוץ. ניתן לעקוב אחר מדדים כגון זמן השלמת יציאה מהשירות, מספר פניות מעקב וכמות חשבונות נותרים או נתונים שהתגלו לאחר מעשה. לקחים שנלמדו מהרצות מוקדמות יכולים להחזיר רשימות בדיקה משופרות, הנחיות טובות יותר במודעות השיווק שלכם או חומרי הדרכה נוספים.
הדרכה ותקשורת פנימית הן חיוניות. מהנדסים ומנהלי לקוחות צריכים לראות את תהליך היציאה מהשירות כחלק ממחזור חיי השירות הרגיל, ולא כמשחק סופי לא נעים. מפגשי הדרכה קצרים, מדריכים חזותיים והנחיות "בדיוק בזמן" בתוך כרטיסים או מאמרים בבסיס ידע עוזרים לחזק את התהליך. עם הזמן, ספר נהלים טוב הופך להרגל משותף, לא למסמך שמופיע רק במהלך ביקורות.
יישור מדריך זה עם פלטפורמת ISMS כגון ISMS.online מאפשר לכם לקשר כל שלב לבקרות, סיכונים ומאגרי ראיות בסיסיים. בדרך זו, המציאות התפעולית שלכם ותיעוד ISO 27001 הרשמי שלכם נשארים מסונכרנים, ואנשי מקצוע יכולים לראות כיצד עבודתם היומיומית תומכת בתאימות לתקן A.8.10.
בקרות טכניות ופרוצדורליות למחיקה ניתנת לאימות
בקרות טכניות ופרוצדורליות הופכות את המחיקה למאובטחת וניתנת להוכחה במערכות המגוונות שלכם. אתם זקוקים לשיטות סטנדרטיות לכל סוג אחסון, כללים ברורים לגבי מי יכול להפעיל מחיקה, ודרכים להראות שהפעולות עבדו, מכיוון שמדריך רק מגדיר מה אמור לקרות; בקרות מבטיחות שזה אכן יקרה בטכנולוגיות מגוונות, החל משרתים מקומיים ועד פלטפורמות SaaS וגיבויים ארוכי טווח.
בחירה וסטנדרטיזציה של שיטות מחיקה
בחירת שיטות מחיקה מתחילה בהבנת אמצעי האחסון והשירותים שבהם אתם משתמשים: נקודות קצה, שרתים, תשתית וירטואלית, אחסון ענן, SaaS וגיבויים. כל אחד מהם דורש גישה מתאימה, החל ממחיקה קריפטוגרפית ומחיקה מאובטחת ועד למדיניות מחזור חיים וניקוי נתונים המנוהל על ידי הספק. סטנדרטיזציה של גישות אלו מעניקה למהנדסים ביטחון שהם עושים את הדבר הנכון תחת לחץ.
סוגים שונים של אחסון ושירותים דורשים גישות מחיקה שונות, לדוגמה:
- נקודות קצה ושרתים: מחיקה מאובטחת או מחיקה קריפטוגרפית של דיסקים, בנוסף להסרה מכלי ניהול
- תשתית וירטואלית: טיפול זהיר בתמונות, אמצעי אחסון ותמונות כך שביטול הקצאת הנתונים באמת מסיר נתונים
- אחסון אובייקטים בענן ושיתופי קבצים: מדיניות מחזור חיים שפג תוקף הנתונים לאחר תקופות שמירה מוגדרות
- יישומי SaaS: פונקציות ניהוליות לניקוי חשבונות משתמשים, תוכן ומטא-נתונים
גיבויים רגישים במיוחד. ייתכן שלא תוכלו להסיר באופן כירורגי את הנתונים של לקוח אחד ממערכות גיבוי היסטוריות מרובות דיירים. במקום זאת, השליטה שלכם יכולה להיות לקצר את משימות השמירה עבור עבודות גיבוי ספציפיות, להצפין מדיה עם מפתחות ספציפיים ללקוח ולהבטיח שהמדיה עוברת חיטוי או השמדה מאובטחת בסוף חייה. בסביבות רבות, מחיקה קריפטוגרפית באמצעות השמדת מפתחות היא דרך מוכרת להפוך גיבויים ישנים לבלתי קריאים, ויכולה להיות בחירה מעשית כאשר כתיבה מחדש או החלפה של כל בלוק אינה אפשרית, בהתאם להנחיות לחיטוי נתונים כגון NIST SP 800‑88, הכוללת מחיקת קריפטו בין שיטות החיטוי המקובלות.
בכל המקרים, עדיף להכיר באילוצים טכניים ולנהל אותם באחריות. הימנעו מהבטחות מחיקה מושלמת שאינכם יכולים לספק. סטנדרטיזציה של שיטות אלו בתקן מחיקה או בהנחיה טכנית עוזרת למהנדסים להימנע מבחירות אד-הוק. עבור כל סוג של מאגר נתונים, ניתן לתעד שיטת מחיקה ראשונית, שיטת גיבוי כאשר הראשונית אינה אפשרית ואת שלב האימות הנדרש. אוטומציה באמצעות סקריפטים, מדיניות RMM או כלי תזמור יכולה לאחר מכן להחיל שיטות אלו באופן עקבי וליצור יומני רישום תוך כדי הפעלתן.
בקרות המאפשרות הוכחת מחיקה
מחיקה משכנעת אחרים רק כאשר ניתן להראות מתי, כיצד ועל ידי מי היא בוצעה. בקרות פרוצדורליות כגון רישומי שינויים, אישור כפול, בדיקות אימות ורישום הופכות פעולות טכניות לראיות. הן גם מגנות על הצוות שלכם על ידי הבטחת מחיקות בסיכון גבוה לא יוכלו להתרחש בשקט או ללא בדיקה.
מנקודת מבט של ביקורת ואמון לקוחות, השאלה החשובה ביותר היא לא רק "האם מחקת?" אלא "איך אתה יודע, ואיך אתה יכול להראות את זה?". מספר בקרות פרוצדורליות מסייעות כאן:
- שינוי רשומות או כרטיסים למחיקות בסיכון גבוה, תוך התייחסות לכללי שמירה ואישורים
- שליטה כפולה להשמדת מפתחות או סילוק מדיה, כך שאף אדם אחד לא יוכל למחוק ראיות קריטיות
- בדיקות לאחר מחיקה שחשבונות, חיפושים או שחזורים אינם חושפים עוד את נתוני הלקוח
- יומני רישום עבור משימות מחיקה אוטומטיות וידניות שניתן לייצא לחבילות ראיות
גם לניטור יש תפקיד. התראות על משימות מחיקה שנכשלו, שינויים חריגים בשמירה או אנומליות בהתנהגות השכפול והגיבוי צריכות להיות מנותבות לצוותים המתאימים עם ספרי ריצה נקיים. בדיקות תקופתיות של ספרי ריצה למחיקה באמצעות תרגילים ושחזורים לדוגמה מאמתות שהבקרות עדיין פועלות ככל שטכנולוגיות ותצורות מתפתחות.
איחוד האלמנטים הללו מעניק לכם לא רק את הביטחון שהנתונים נמחקים בצורה מאובטחת, אלא גם את הארכיטקטים הדרושים לכם כדי לשכנע אחרים, החל ממבקרים פנימיים ועד ללקוחות ארגוניים תובעניים.
ניהול כל דרישות התאימות, הכל במקום אחד
ISMS.online תומך ביותר מ-100 תקנים ותקנות, ומעניק לך פלטפורמה אחת לכל צרכי התאימות שלך.
הוכחת מחיקה והטמעתה במערכות ה-ISMS והחוזים שלך
הוכחת מחיקה פירושה היכולת לספר סיפור קוהרנטי ומגובה בראיות על מה שקורה לנתוני הלקוח בעת היציאה, וזה דורש יישור קוהרנטי על פני שלוש שכבות: מדיניות ותקנים, חפצי תהליכים ורישומים ספציפיים לאירועים, כולם חיים בתוך מערכת ה-ISMS שלכם ומהדהדים בחוזים שלכם, כך שמה שאתם מבטיחים תואם את מה שאתם יכולים לספק באופן עקבי. מבקרים, רגולטורים ולקוחות אינם חווים את כוונותיכם; הם רואים את התיעוד וההתנהגות שלכם, כך שהפיכת המחיקה למשהו שאתם יכולים להוכיח תלויה בהפיכת A.8.10 לגלוי בבירור בכל אחת מהשכבות הללו.
רואי חשבון, רגולטורים ולקוחות אינם חווים את כוונותיכם; הם רואים את התיעוד וההתנהגות שלכם. הפיכת המחיקה למשהו שניתן להוכיח דורשת יישור של מערכות ה-ISMS, החוזים והראיות התפעוליות שלכם, כך ש-A.8.10 יהיה גלוי בבירור בכל אחד מהם.
בניית ערכת ראיות למחיקה מוכנה לביקורת
חבילת ראיות מוכנה לביקורת מאגדת כללים ברמה גבוהה, תכנון תהליכים ורישומים ספציפיים מאירוע יציאה מהמערכת, כך שכאשר מישהו שואל "הראה לי מה קרה עבור הלקוח הזה", תוכל לאחזר את שלושתם במהירות. זה מפחית לחץ עבור הצוותים שלך, מקל על הוכחת ש-A.8.10 פועל בפועל ולא רק על הנייר, וחבילת ראיות יעילה עבור לקוח ספציפי יציאה מהמערכת כוללת בדרך כלל שלוש שכבות:
- מדיניות ותקנים: מדיניות מחיקת המידע שלך, לוח הזמנים לשמירה וכל הסטנדרטים הטכניים המגדירים שיטות ואחריות. אלה מראים את העקרונות שאתה מיייש.
- ארטיפקטים של תהליך: מדריך ההשקה שלכם, RACI, תבניות וכל הנחיה פנימית שמתרגמת מדיניות לפעולה. אלה מציגים את תהליך העבודה שתוכנן.
- רשומות ספציפיות לאירוע: כרטיסים או רישומי שינויים המכסים את תהליך היציאה מהמערכת, אישורים להחלטות מחיקה, יומני רישום ממערכות המציגים מחיקה או תפוגה וכל אישורי השמדה או מחיקה שהונפקו. אלה מראים מה קרה במקרה זה.
לדוגמה, ייתכן שיש לכם כרטיס שינוי המתייחס להסכם השירותים הראשי, מצביע על לוח הזמנים של השמירה, כולל צילומי מסך של שינויים בעבודות גיבוי וקטעי יומן ממערכות מפתח, ומסתיים באישור רשמי. חבילה אחת זו מקלה בהרבה על דיון ביציאה מהמחלקה עם רואה חשבון או לקוח לשעבר מאשר חיפוש בין מיילים וכלים מפוזרים.
כאשר אלמנטים אלה מקושרים בתוך פלטפורמת ISMS כמו ISMS.online, ניתן לעבור ממבט ריק לסיכום קוהרנטי כאשר מבקר אומר, "הראה לי כיצד טיפלת במחיקת נתונים עבור הלקוח האחרון שפיטרת". אותו דבר, בסיכום הולם, יכול להרגיע לקוח לשעבר שרוצה הוכחות לכך שעמדת בהתחייבויות שלך.
יישור חוזים, מערכות מידע ומערכות מערכות (ISMS) ושיפור מתמיד
התאמת חוזים למערכת ה-ISMS שלכם מבטיחה שאתם מבטיחים רק את מה שהאנשים והכלים שלכם יכולים לספק באופן מהימן. הסכמי עיבוד נתונים והסכמי שירותים ראשיים צריכים לשקף את מודל המחיקה שלכם, כולל תקופות שמירה, התנהגות גיבוי ואחריות במערכות צד שלישי. אם לשון החוזה סוטה מהמציאות התפעולית, אתם יוצרים סיכון לשני הצדדים. הנחיות חוזיות בנוגע לחובות הגנת נתונים ממליצות בדרך כלל להתאים את לשון DPA לנוהלי העיבוד והמחיקה בפועל שבהם משתמש הארגון שלכם, כך שהבטחות חוזיות בנוגע לשמירה ומחיקה יהיו מציאותיות וניתנות לאכיפה, כפי שנדון בפרשנויות כמו סקירה זו של התקשרויות להתחייבויות הגנת נתונים.
סעיפים צריכים להתאים גם למושגי פרטיות כגון הגבלת אחסון וזכויות הקשורות למחיקה, תוך הכרה בצרכים לגיטימיים של שמירה ובעמידה משפטית. במקרים בהם חוקים או כללי ענף מחייבים אותך להשהות את המחיקה, הדבר צריך לבוא לידי ביטוי הן במדיניות שלך והן בניסוח החוזי שלך.
כשני שלישים מהארגונים שנסקרו אמרו כי המהירות והיקף השינויים הרגולטוריים מקשים על שמירה על הציות.
חוזים והסכמי עיבוד נתונים צריכים לתמוך, ולא לסתור, את מודל המחיקה שלך על ידי תיאור:
- מה קורה לסוגים שונים של נתונים בסוף החוזה
- כמה זמן גיבויים יכולים להמשיך להתקיים ותחת אילו הגנות
- איזה צד אחראי לפעולות במערכות של צד שלישי
- איזו צורת אישור או דיווח הלקוח יכול לצפות
יש לכתוב סעיפים אלה בהתייעצות עם המחלקה המשפטית והתפעולית כאחד, כך שההבטחות יתאימו למה שספר ההוראות והבקרות שלכם יכולים לספק בפועל. עיקרון פשוט עוזר כאן: הבטיחו רק את מה שאתם יכולים לבצע באופן עקבי ולהוכיח. ניסוח שאפתני מדי או לא ברור עשוי להיראות אטרקטיבי בשיחות מכירה אך יוצר בעיות חמורות של תאימות וחבות בהמשך.
סעיפים צריכים להתאים גם למושגי פרטיות כגון הגבלת אחסון וזכויות הקשורות למחיקה, תוך הכרה בצרכים לגיטימיים של שמירה ובעמידה משפטית. במקרים בהם חוקים או כללי ענף מחייבים אותך להשהות את המחיקה, הדבר צריך לבוא לידי ביטוי הן במדיניות שלך והן בניסוח החוזי שלך.
בתוך מערכת ה-ISMS שלכם, סעיף A.8.10 לא צריך להיות פריט בודד ברשימת בקרה. רישומי נכסים צריכים לציין אילו מערכות מחזיקות נתוני לקוחות ואילו שיטות מחיקה רלוונטיות. הערכת סיכונים צריכה לשקול תרחישי יציאה מהמערכת. סקירות ספקים צריכות לבדוק כיצד ספקים במורד הזרם תומכים בהתחייבויות המחיקה שלכם. ביקורות פנימיות וסקירות ניהוליות צריכות לבחון מעת לעת את יישום סעיף A.8.10, לזהות פערים ולקדם פעולות מתקנות.
על ידי התייחסות למחיקה כחלק חי ממערכת הניהול שלכם, אתם יוצרים לולאת משוב שבה כל אירוע יציאה משפר את הבא אחריו. זה, בתורו, הופך את המחויבויות שלכם ללקוחות ולמבקרים לחזקות יותר ויותר ומחזק את המוניטין שלכם בטיפול אחראי בנתונים לאורך כל מערכת היחסים ומעבר לה.
הזמן הדגמה עם ISMS.online עוד היום
ISMS.online עוזר לכם להפוך את תקן ISO 27001 A.8.10 מדרישה מעורפלת לתהליך עבודה חי של הטמעה, עם ראיות מקושרות שתוכלו להציג למבקרים וללקוחות. על ידי ניהול מדיניות, ספרי נהלים, כרטיסים ורשומות במקום אחד, תוכלו להפוך מחיקה מאובטחת לחלק שגרתי ממחזור חיי השירות שלכם במקום פרויקט חד פעמי מלחיץ.
מה שתוכלו להשיג ב-90 הימים הקרובים
בתשעים הימים הקרובים, תוכלו להפוך את המחיקה והיציאה ממשימה אד-הוק לספר סטנדרטי ואחראי. תוכלו לאשר מי אחראי לכל שלב וליישר קו עם כללי השמירה והמחיקה שלכם לחוזים שלכם. הגדרת אלמנטים אלה בתוך ISMS.online פירושה שהם לא רק מסמכים על מדף אלא חלקים פעילים בתהליכים היומיומיים שלכם, כאשר משימות, רשומות וסקירות מניעות התנהגות עקבית בכל ספק שירותי הניהול הניהולי (MSP) שלכם.
פגישת עבודה קצרה עם צוות ISMS.online יכולה לעזור לכם למפות את הרגלי היציאה הנוכחיים שלכם אל מול A.8.10, להדגיש פערים אמיתיים ולתעדף שינויים המחזקים הן את הציות והן את הרווחיות. יחד תוכלו לזהות קבוצה קטנה של מדדים - כגון זמן מחזור היציאה, גילויים שיוריים של חשבונות וממצאי ביקורת - שיראו האם הגישה החדשה שלכם מניבה ערך.
למה לראות ISMS.online בפעולה עכשיו
הצגת ISMS.online בפעולה מראה כיצד פלטפורמת ISMS יכולה להפוך את המחיקה והיציאה לחיזויים, ניתנים להוכחה וקלים יותר לניהול עבור הצוותים שלכם. הדגמה ממוקדת מחברת את הרעיונות במדריך זה לבסיס הלקוחות, הכלים והחוזים האמיתיים שלכם, כך שתוכלו לשפוט עד כמה הגישה תעבוד בהקשר הספציפי שלכם.
חיזוק מחיקת מידע וקליטת לקוחות כיום מכין אתכם גם למסגרות וציפיות עתידיות. ככל שתקנות כגון חוקים המותאמים ל-NIS ותקני לקוחות מתפתחות, יכולת מחיקה מובנית ומוכנה לראיות הופכת את ההסתגלות לקלה בהרבה מאשר התחלה מאפס בכל פעם. אם אתם מוכנים להיות ספק שירותי ניהול מידע (MSP) שיכול להוכיח שנתוני לקוחות באמת עוזבים כאשר מערכת היחסים מסתיימת, הזמנת הדגמה עם ISMS.online היא צעד ראשון ומעשי.
הזמן הדגמהשאלות נפוצות
מה באמת מצפה מ-ISO 27001 A.8.10 שספק שירותי ניהול (MSP) יוכיח לגבי נתוני לקוחות כאשר חוזה מסתיים?
תקן ISO 27001 A.8.10 מצפה ממך להוכיח שמידע שאינו נדרש עוד הוא זוהה, מטופל בצורה מבוקרת ומוכח – לא רק נמחקים באופן לא רשמי כשמישהו זוכר. עבור ספק שירותים מנוהלים, משמעות הדבר היא שתוכלו להראות היכן נמצא מידע הקשור ללקוח, מתי כל קטגוריה מפסיקה להיות נחוצה, ומה קרה לה בעת ואחרי היציאה מהשירות.
מה המשמעות של "לא נדרש עוד" בהקשר של MSP?
אתם צפויים להגדיר את המונח "לא נדרש עוד" באופן שיהיה הגיוני עבור רגולטור, רואה חשבון ועורך דין:
- אתה לוקח בחשבון שמירה חוקית (מיסוי, פיננסים, תעסוקה, חוקי מגזר).
- אתה מתיישר עם תנאים חוזיים (תקופות התיישנות, סכסוכי SLA, אחריות).
- אתה משקף צרכים עסקיים לגיטימיים (רישום אבטחה, היסטוריית שירות, ביטוח).
כללים אלה צריכים להיות גלויים במדיניות מחיקה/שמירה ובלוח זמנים המבחין בין תוכן לקוחות לבין הרישומים התפעוליים שלך.
מה רואה חשבון רוצה לראות בדרך כלל עבור A.8.10?
רוב רואי החשבון ירצו שתעשו את הדברים הבאים:
- הצבע על א מדיניות ולוח זמנים לשמירה המכסים תוכן לקוחות ורשומות MSP.
- הצג א זרימת עבודה חוזרת של יציאה מהבמה שמפנה לחוקים האלה.
- ללכת דרך א יציאה אחרונה ולספק:
- כללי סוף החיים המוגדרים עבור מידע זה.
- השלבים שתכננת (ייצוא, שמירה, מחיקה, אנונימיזציה).
- הראיות: כרטיסים, רישומי שינויים, יומני רישום, רשימות ייצוא, אישורים.
אם אתם יכולים להראות ברוגע "כך אנו מחליטים שמידע אינו נחוץ עוד, זהו תהליך העבודה שאנו מפעילים תמיד, וזה מה שעשינו עבור הלקוח הזה", אתם פוגשים את רוח A.8.10 בצורה משכנעת הרבה יותר מאשר להסתמך על "אנחנו בדרך כלל מוחקים דברים כאשר לקוח עוזב".
כיצד צריך ספק שירותי ניהול שירותים (MSP) להחליט מה למחוק, לשמור או להפוך לאנונימי כאשר מערכת יחסים עם לקוח מסתיימת?
אתם מקבלים את ההחלטות הללו על ידי סיווג מידע מראש ויישום כללים כתובים פשוטים לכל כיתה, במקום לאלתר בכל פעם שחוזה מסתיים. בלי כללים אלה, אנשים או אוגרים הכל "למקרה הצורך" או מוחקים יותר מדי ומאבדים רשומות שעדיין צריכים.
כיצד אתם מפרידים בין תוכן הלקוחות לבין הרישומים התפעוליים שלכם?
חלוקה מעשית שרוב חברי הכנסת מכירים בה היא:
- תוכן הלקוח: – מידע שבבעלות הלקוח או שהוא אחראי עליו ישירות:
- נתוני דיירים, תיבות דואר, מאגרי קבצים ומסדי נתונים.
- מכונות וירטואליות ועומסי עבודה מתארחים.
- תמונות של נקודות קצה וגיבויים של הסביבות שלהן.
- ניטור וטלמטריה ספציפיים ללקוח.
- רישומי תפעול של MSP: – מידע שאתם צריכים כדי לנהל ולהגן על העסק שלכם:
- חוזים, חשבוניות, רישום שעות והזמנות רכש.
- יומנים מצטברים וסיכומי אירועים.
- הערות תצורה, דיאגרמות, ספרי ריצה ודוחות שירות.
- אירועי אבטחה והיסטוריית שינויים בפלטפורמות שלכם.
תוכן הלקוח הוא בדרך כלל מוחזר או מיוצא, ולאחר מכן נשמרות ניתנות לשחזור לתקופה מוסכמת לפני מחיקתן. רשומות תפעוליות נשמרות בצורה מקוצרת לתקופות מוגדרות כך שתוכלו:
- לעמוד בכללי המימון והמיסוי.
- טיפול בתלונות, סכסוכים ותביעות ביטוח.
- ניתוח מגמות אבטחה ושירות.
תיעוד פיצול זה במערכת ה-ISMS שלכם מקל הרבה יותר על ההסבר ללקוחות ולמבקרים מדוע מערכי נתונים שונים עוקבים אחר מסלולי סוף חיים שונים.
מתי כדאי למחוק לחלוטין לעומת להפוך לאנונימי ולשמור?
עבור כל קטגוריית מידע, קבעו ארבעה יסודות:
- מטרה: – למה אתה מחזיק את זה.
- תקופת שמירה: - כמה זמן אתה באמת צריך את זה.
- פעולה בסוף החיים: – למחוק, להפוך לאנונימי או להעביר לארכיון מוגבל.
- מיקומים: – מערכות, אחסון וצדדים שלישיים.
השתמש מחיקה כאשר אין סיבה משפטית, חוזית או תפעולית מתמשכת לשמור את המידע. אנונימיזציה כאשר אתם עדיין רוצים תובנות - לדוגמה, מגמות בקשות או שיעורי אירועים - אך אינכם צריכים עוד לזהות לקוח או אדם קודם מסוים.
הנקודה המכרעת עבור A.8.10 היא שדפוסים אלה קיימים לפני היציאה, נכתבים ומיושמים באופן עקבי. פלטפורמה כמו ISMS.online מקלה על כך על ידי קישור סוגי מידע, כללי שמירה ופעולות סוף חיים ישירות לנכסים ולבקרות שלך, כך שהצוות שלך תמיד יודע מה צריך לקרות הלאה.
כיצד יכול ספק שירותי ניהול שירות (MSP) להפוך את תהליך הוצאת הלקוח מהרשת לתהליך חוזר הכולל תמיד מחיקה מאובטחת?
אתם הופכים את היציאה מהאוטבורד לחזרה על ידי התייחסות אליה כאל... זרימת עבודה סטנדרטית של שירות עם ספר הליכים ברור, לא כפרויקט מזדמן שכל מהנדס מנהל בצורה שונה. ספר ההכנה הזה צריך להגדיר שלבים, בעלים, חפצים וראיות כך שכל יציאה תכלול מחיקה מאובטחת מכוונת.
מה כולל מדריך פרקטי ליציאה מהארון עבור A.8.10?
זרימה מעשית עבור רוב ספקי ה-MSP נראית כך:
- טריגר וקביעת היקף:
הודעת חוזה או אי-חידוש חוזה יוצרים רישום של יציאה מהחברה בכלי ה-PSA או ה-ITSM שלכם. אתם מתעדים את היקף הפרויקט, תאריכים מרכזיים, אנשי קשר עם לקוחות, מערכות נלוות וכל אילוץ (כגון החזקות משפטיות, רגולטורים או סכסוכים פתוחים).
- סקירת נתונים ונכסים:
אתם סוקרים את מפת הנכסים והנתונים של הלקוח: דיירים, סביבות, מכשירים, גיבויים, SaaS, ניטור ושירותי צד שלישי. זה מבהיר היכן נמצאים תוכן הלקוח והרשומות שלכם.
- הסכם ייצוא ושמירה:
הנך מסכים/ה מה יוחזר (נתונים, תיעוד, אישורים), באיזה פורמט, כמה זמן הנתונים יישארו ניתנים לשחזור ומתי בדיוק יתחילו המחיקות או האנונימיזציה.
- שינויי גישה ותצורה:
אתה מסיר או משנה חשבונות, מפתחות, VPN, אינטגרציות וניטור ב- רצף מתוכנן אשר אינו מפריע לייצוא מוסכם או משאיר נתיבי גישה לא מנוהלים.
- ביצוע מחיקה / אנונימיזציה:
אתם מיישמים את כללי השמירה: גיבוי גיבויים, מדיניות מחזור חיי אחסון, ניקוי ברמת הדייר, מחיקת מכשירים, הסרת פניות. כל פעולה מתועדת, ובמידת הצורך, נבדקת על ידי אדם שני.
- סגירה ואישור:
אתם מתעדים מה יוצא, מה נמחק או הועבר לאנונימיזציה, מה נשאר (עם נימוק ותקופת שמירה), ולוכדים אישורים פנימיים ו-במידת הצורך - אישורים של הלקוח.
תיעוד תהליך עבודה זה כמערכת ניהול המערכות (ISMS) שלכם שומר על השלבים גלויים וניתנים לביקורת. ב-ISMS.online תוכלו לבנות את מדריך הפעולה הזה ישירות לתוך מערך הבקרה שלכם ולקשר אותו לרשומות שינוי, כך ש-A.8.10 תמיד מגובה בתהליך בר-מעקב ולא בידע שבטי.
איך מבטיחים שמהנדסים אכן פועלים לפי מדריך ההפעלה של המשרד?
אנשים עוקבים אחר תהליכים שהם יכולים לראות ושמתאימים באופן טבעי לכלים שלהם:
- הטמעת שלבי וצ'קים של יציאה מהמערכת תבניות PSA/ITSM עם משימות, שדות וקודי סטטוס סטנדרטיים.
- הקצה תפקידים בעלי שם עבור כל שלב – דלפק שירות, פרויקטים, פלטפורמה, אבטחה, כספים – כך שהבעלות ברורה.
- השלמה שטחית של משימות הסרה ומחיקה של גישה למפתחות ב לוחות מחוונים או ביקורות שירות.
- הפעלה ביקורות על לקחים שנלמדו על יציאות מוקדמות כדי לחדד את זרימת העבודה לפני יישומה על לקוחות מורכבים או מוסדרים יותר.
אם אתם מנהלים את ה-ISMS שלכם ב-ISMS.online, תוכלו לקשר את זרימת העבודה של היציאה ישירות ל-A.8.10, להקצות בעלים, לקבוע תאריכי סקירה ולאסוף ראיות, כך שהמעקב אחר מדריך הפעולות יהפוך ל"איך אנחנו עושים אקזיטים כאן" ולא לתרגיל ניקיון של פעם בשנה.
אילו בקרות טכניות ותהליכיות מספקות ל-MSP הוכחה משכנעת לכך שמידע אכן נמחק?
אתה בונה הוכחה משכנעת על ידי שילוב בקרות טכניות חזקות עם הליכים קלים וחוזרים על עצמם שתמיד משאירים עקבות. לקוחות ומבקרים רוצים לראות שאתם יודעים מה עשיתם עבור אקזיט ספציפי ויכולים להראות זאת, לא רק שאתם בעלי מוצרים מרשימים.
אילו בקרות טכניות תומכות בראיות מחיקה מהימנות?
עבור רוב חברי ה-MSP, הדברים הבאים הם גם פרקטיים וגם משכנעים:
- מדיניות מחזור חיים של אחסון וגיבוי: – תפוגה אוטומטית של נתונים וגיבויים לאחר תקופות מוגדרות, עם יומני שינויי מדיניות ותוצאות משימות.
- מחיקה קריפטוגרפית: – הוצאה משימוש או השמדה של מפתחות כך שלא ניתן עוד לקרוא נתונים מוצפנים במנוחה, במיוחד בפלטפורמות ענן ובאחסון הצפנה עצמית.
- פונקציות ניקוי שסופקו על ידי הספק: – שימוש במחיקה מובנית של דיירים, חשבון או סביבת עבודה בשירותי SaaS וענן במקום מחיקה ידנית, פריט אחר פריט.
- ניקוי מכשירים מנוהל: – מחיקה, בנייה מחדש או סילוק מאובטח בשליטה מרכזית עבור מחשבים ניידים, שרתים, חומות אש ומכשירי רשת שאתם מנהלים.
בקרות שתצורתן מוגדרת היטב מייצרות דוחות, יומנים או לוחות מחוונים – לדוגמה, עבודות מחזור חיים שהושלמו, מפתחות שהושמדו, דיירים שהוסרו – אותם תוכלו לצרף לתיעוד היציאה מהפרויקט כחלק מהראיות שלכם לפי סעיף A.8.10.
אילו שלבי תהליך הופכים את ההוכחה לאמינה יותר?
בצד התהליך, אתם מחזקים את הקומה שלכם אם אתם:
- להעלות שינוי רשומות עבור מחיקות משמעותיות או השמדת מפתחות, תיעוד אישורים, היקף וסיכון.
- החל שליטה כפולה לפעולות בעלות השפעה גבוהה (כגון מחיקת אחסון משותף או הוצאת מפתחות ראשיים מהמערכת) כך שאף אחד לא יבצע את השינויים האלה לבד.
- לכלול בדיקות אימות, כגון אישור כי:
- הלקוח הקודם כבר לא מופיע ברשימות משימות הגיבוי.
- חשבונות שהושבתו נכשלים באימות.
- דיירים או מנויים נעלמו מקונסולי הניהול.
- צג משימות מחיקה והתראות, כך שכשלים או שינויים בלתי צפויים בשמירה מזוהים ומתוקנים במהירות.
ISMS.online מסייע כאן בכך שהוא מאפשר לך לקשר את הבקרות הטכניות והתהליכיות הללו ישירות ל-A.8.10, לאחסן את הראיות הנלוות ולסקור את תפקודן בביקורות פנימיות ובסקירות הנהלה. זה מקל על ההוכחה שמחיקה היא משהו שאתה עושה באופן עקבי, לא רק כשמישהו שואל שאלות קשות.
כיצד יכולים ספקי שירותי ניהול שירותים (MSPs) לארוז ולהציג ראיות לפי A.8.10 כך שניתן יהיה לטפל במהירות בביקורות ובשאלות של לקוחות?
אתם מקלים על ביקורות ושאלות של לקוחות לשעבר על ידי סטנדרטיזציה של חבילת ראיות ליציאה מהארון שאתם משתמשים בו שוב בכל יציאה. כשמישהו שואל "מה עשיתם עם הנתונים שלנו?", אתם רוצים לשלוף חבילה שלמה תוך דקות במקום לרדוף אחרי מיילים ויומנים ישנים.
מה צריכה להכיל חבילת ראיות סטנדרטית ליציאה מהארון?
מבנה פשוט בן שלוש שכבות עובד היטב:
- שכבה עליונה - כללים וכוונה:
- מדיניות מחיקת/שמירת מידע, כולל הגדרת "לא נדרש עוד".
- לוח זמנים לשמירה המציג קטגוריות, תקופות שמירה ופעולות ברירת מחדל לסוף חיים.
- תפקידים ואחריות עבור יציאה מהמערכת ומחיקה.
- שכבה אמצעית - איך מיישמים אותה:
- מדריך ליציאה מהבורד ומטריצת אחריות.
- רשימות תיוג או טפסים סטנדרטיים המשמשים במהלך יציאות.
- הנחיות פנימיות בנוגע למחיקה, אנונימיזציה וטיפול בחריגים כגון החזקות משפטיות.
- שכבה תחתונה - מה קרה עבור הלקוח הזה:
- רשומת ההוצאה מה-PSA/ITSM וכרטיסי שינוי קשורים.
- רשימת הייצוא המוסכמת ואישור הלקוח על קבלה ושימושיות.
- יומנים או דוחות ממערכות מפתח (ענן, גיבוי, SaaS, RMM, ניטור) המציגים מחיקה, תפוגה או הסרת גישה.
- כל תעודות השמדה או אישורים בכתב שהנפקת.
- פתק סיום קצר המתאר מה נמחק, מה נשמר, מדוע ולכמה זמן.
קישור חבילה זו לרשומת הלקוח במערכת ה-ISMS שלך מאפשר אחזור ושימוש חוזר מהירים. ב-ISMS.online, תוכל לאחסן את הפריטים הללו כראיות כנגד A.8.10 ובקרות קשורות, מה שהופך ביקורות פנימיות וחיצוניות לפשוטות הרבה יותר.
כיצד גישה זו מסייעת מעבר לעמידה בתקן ISO 27001?
חבילות יציאה סטנדרטיות עושות יותר מאשר לעמוד ב-A.8.10:
- הֵם להפחית את החיכוך כאשר לקוחות לשעבר מבקשים הבטחה שהנתונים שלהם אינם עוד בסביבה שלך.
- הם תומכים חידושים והפניות, כי אתם יכולים להראות שאתם מטפלים ביציאות באותה זהירות כמו בקליטה.
- הם נותנים חברי צוות חדשים דוגמאות ברורות שכדאי לעקוב אחריהן, כך שהיכולת להפגין יציאה טובה מהפרויקט אינה תלויה באחד או שניים מהנדסים ותיקים.
אם מטפלים בזה היטב, יציאה מהחברה הופכת לנקודת מכירה שקטה: אתם נראים כמו ספק שסוגר את המעגל כראוי, ואתם יכולים להוכיח זאת באמצעות דוגמאות חיות במהלך שאלוני אבטחה, בקשות להצעות מחיר ובדיקות נאותות.
מדוע ניהול A.8.10 דרך פלטפורמת ISMS כמו ISMS.online הופך את תהליך הפעלת והוכחת תהליך ה-MSP לקל יותר?
ניהול A.8.10 דרך פלטפורמת ISMS מפשט את תהליך היציאה מהארון מכיוון שהוא מחבר מדיניות, סיכונים, נכסים, זרימות עבודה וראיות במקום אחד, במקום לפזר אותם על פני מסמכים, כרטיסים וזיכרון אישי. במקום להסתמך על אנשים שיזכרו כללים ויומנים, ניתן לתת למערכת להדריך ולתעד את הפעולות הנכונות.
כיצד פלטפורמת ISMS משפרת את הבקרה היומיומית עבור A.8.10?
בעזרת פלטפורמה כמו ISMS.online תוכלו:
- קישור A.8.10 ישירות לנכסים וזרימת נתונים רלוונטיים, כך שהמפה שלך, המציגה היכן נמצא מידע על הלקוחות, ניזונה ישירות מתכנון היציאה.
- לצרף כללי שמירה ופעולות בסוף החיים לסוגי מידע ספציפיים, כך שמהנדסים יוכלו לראות בתוך הפלטפורמה האם יש למחוק, להפוך לאנונימיים או לארכיון פריטים.
- בנה את שלך זרימת עבודה של יציאה מהבורסה, RACI ורשימות בדיקה כפריטים חיים בתוך מערכת ה-ISMS, עם בעלים, תאריכי סקירה והיסטוריית שינויים, ולא קבצים סטטיים בכונן משותף.
- ללכוד כרטיסים, אישורים, יומני רישום ואישורים כראיה כנגד הבקרה, כך שכל מה שאתם צריכים לביקורות ולהרגעת הלקוחות כבר נמצא במקום אחד.
- כלול את A.8.10 ב ביקורות פנימיות וסקירות הנהלה, כך שתוכלו לאתר פערים - לדוגמה, מערכת שבה מחיקות עדיין לא נרשמות - ולעקוב אחר שיפורים לאורך זמן.
זה הופך את המחיקה והיציאה מהמערכת לחלק מקצב הציות הרגיל שלך, במקום פרויקט צדדי שאתה חוזר אליו רק כאשר חידושי הסמכה מתקרבים.
כיצד זה משנה את האופן שבו אתם נראים בפני לקוחות ומבקרים?
כאשר יציאה מהמערכת ומחיקה מונעים באופן גלוי על ידי מערכת ה-ISMS שלכם ולא מאולתרים עבור כל חוזה, תוכלו:
- ענו על שאלוני אבטחה ובקשות הצעות מחיר (RFP) עם הסברים עקביים וספציפיים של האופן שבו אתם מטפלים בסוף החיים לצורך קבלת מידע, מגובה בדוגמאות אמיתיות מחבילות הראיות שלכם.
- תנו לרואי חשבון קו ראייה ברור מ-A.8.10 ועד לסיכונים, נכסים, זרימות עבודה והוכחות, מה שמפחית את הזמן שהם משקיעים בבדיקת הגישה שלכם.
- הרגיעו לקוחות לשעבר ש הנתונים שלהם באמת עוזבים ברגע שאין בסיס לגיטימי לשמור אותו, הנתמך על ידי חפצים שניתן לאחזר במהירות.
אם אתם רוצים שספק שירותי ה-MSP שלכם יוכר כספק שמטפל ביציאות באופן מקצועי כמו בקליטה – ויכול להוכיח זאת תחת תקן ISO 27001 A.8.10 – הצבת מחיקה ויציאה מהשירות (ISMS) בלב מערכת ה-ISMS שלכם, בעזרת פלטפורמה כמו ISMS.online, היא דרך מעשית להשיג זאת ולשמר זאת ככל שתצמחו. זה מאותת ללקוחות, למבקרים ולצוות שלכם שטיפול בסוף חיי השירות הוא חלק מרכזי בשירות שלכם, ולא מחשבה שלאחר מעשה.
