האם הרגל "לשמור הכל" של מנהל ה-MSP שלכם הפך בשקט לסיכון אסטרטגי?
התייחסות לכל יומן, כרטיס וגיבוי כביטוח קבוע אולי הרגישה פעם זולה, אבל עבור ספק שירותי ניהול רשתות (MSP) היא יוצרת כיום סיכונים, עלויות וחיכוכים מיותרים בביקורת. כאשר שום דבר לא נמחק, הפרצות מכה חזק יותר, גילוי משפטי מעמיק יותר ובדיקת ISO 27001 ופרטיות נגררת על נתונים שכבר אינם משרתים אותך או את לקוחותיך. גישה מכוונת ומותאמת ל-ISO מאפשרת לך לצמצם את טביעת הרגל הזו, להסביר את הבחירות שלך ולהוכיח ללקוחות שהמידע שלהם מנוהל, לא נגנז.
רוב ספקי השירותים המנוהלים מעולם לא תכננו במכוון מודל של שמירת נתונים. הוא צמח מהגדרות ברירת מחדל בכלי גיבוי, מהנדסים זהירים שהאריכו חלונות רישום נתונים "למקרה הצורך", ולקוחות שמתעקשים שלעולם לא תמחק שום דבר שעשוי לעזור יום אחד בסכסוך. זה היה נסבל כאשר לקוחות שאלו רק שאלות אבטחה ברמה גבוהה; זה הרבה פחות בר הגנה עכשיו כשרגולטורים, צוותי רכש ומבקרים בודקים כמה זמן שומרים מערכי נתונים שונים ומה קורה בסוף חוזה.
רוב הארגונים בדוח מצב אבטחת המידע לשנת 2025 אומרים כי הושפעו מלפחות אירוע אבטחה אחד הקשור לצד שלישי או לספק בשנה האחרונה.
מידע זה הינו הנחיה כללית, אינו ייעוץ משפטי. לגבי התחייבויות משפטיות ספציפיות עליך להתייעץ עם עורך דין מוסמך בתחומי השיפוט הרלוונטיים.
שליטה אמיתית על נתונים מתחילה כשאתה בוחר מה לא לשמור.
לראות את טביעת הרגל האמיתית של הנתונים שלך
אתם רואים את טביעת הרגל האמיתית של הנתונים שלכם על ידי מיפוי היכן נמצא מידע הלקוחות, כמה זמן הוא נשאר שם והאם זה תואם את מה שהבטחתם. לאחר שתשוו את המציאות הזו לחוזים ולמדיניות שלכם, תוכלו להתייחס לשמירת יתר כסיכון מוגדר ולא לתחושה לא נוחה ש"אנחנו שומרים יותר מדי".
עבור ספקי שירותים ניהוליים (MSP) רבים, בדיקת מלאי מהירה של תמיכה, ניטור, גישה מרחוק, שיתוף פעולה, גיבויים והנדסת מכשירים חושפת פערים ניכרים בין מדיניות, חוזה למציאות. פרשנויות על שמירת נתונים ומזעור נתונים מציינות לעתים קרובות את אותה תבנית: ארגונים מתעדים כללי מחזור חיים אך אינם מיישמים אותם באופן עקבי במערכות חיות. ברגע שפערים אלה נראים לעין, ניתן להתייחס אליהם כסיכוני מחזור חיים ספציפיים ולא כדאגה מעורפלת לגבי "יותר מדי נתונים".
נקודת התחלה מעשית היא תרגיל מיפוי פשוט:
- רשום את המערכות העיקריות שלך - דלפק שירות, ניטור וניהול מרחוק, ניטור, גישה מרחוק, פלטפורמות קבצים ודואר, גיבויים, תיעוד, כספות ומכשירי הנדסה.
- עבור כל אחד מהם, רשום אילו נתוני לקוחות הוא מאחסן, למי הם שייכים, כמה זמן הם נשמרים כיום וכיצד זה קשור לחוזים, הודעות פרטיות ומדיניות פנימית.
- קשרו את המלאי הזה למרשם הסיכונים שלכם, כך שסיכוני מחזור חיי הנתונים יעמדו לצד בעיות מוכרות כמו תיקוני טלאים, בקרת גישה וכשל ספקים.
תוך מספר שעות בדרך כלל תמצאו תיבות דואר מדור קודם עם שנים של כרטיסים, מערכות יומן עם היסטוריה אינסופית למעשה, שרשראות גיבוי שמעולם לא נחתכו, ומהנדסים עם נתוני לקוחות ישנים המאוחסנים במטמון במחשבים ניידים. מציאות זו, ולא מה שהמדיניות אומרת שצריך לקרות, היא מה שמתוך מה יעבוד תוקף, רגולטור או עורך דין של תובע אם משהו ישתבש.
ברגע שניתן לראות את טביעת הרגל האמיתית, קל יותר להבחין בין שלושה סוגים של שמירה:
- מידע שעליך לשמור כדי לעמוד בחוקים, בתקנות או בחוזים.
- מידע שבחרת לשמור משום שהוא מסייע בתפעול, תמיכה או זיהוי פלילי.
- מידע שאתה שומר בטעות כי אף אחד מעולם לא הורה למערכת להפסיק.
רק את שני הראשונים ניתן להצדיק. השלישי הוא חשיפה טהורה.
פלטפורמה כמו ISMS.online יכולה לעזור בשלב זה על ידי מתן מקום מובנה לרישום מלאי הנתונים שלכם, קישור כל מאגר לסיכונים ובקרות, והדגשת תצוגה ברורה של היכן שמירה ומחיקה אינן מבוקרות כיום.
הפיכת כל דבר לסטוריית סיכונים כמותית
אתם הופכים את "שמירת הכל" לסיכון כמותי על ידי צירוף מספרים ותרחישים פשוטים להרגלים הנוכחיים שלכם, כך שההנהלה תוכל לשקול אותם מול סדרי עדיפויות אחרים. במקום להתווכח על עקרונות בצורה מופשטת, אתם מראים מה המשמעות של ההיסטוריה הנוכחית שלכם במקרה של פרצה, סכסוך או ביקורת, וכמה מאמץ נוסף דורשים אירועים, כי שום דבר לא נמחק לעולם.
ניתן למסגר מחדש את שימור עובדים כסיכון אסטרטגי על ידי שאילת שאלות כגון:
- אם לקוח מסוים סובל מפריצה, כמה שנים של הנתונים שלו שמורים במערכות ובגיבויים שלכם?
- עבור אירוע חמור, כמה זמן נוסף לוקח לסרוק היסטוריית יומנים וקרנות עצומה בהשוואה לחלון זמן מוגבל היטב?
- אם הייתם עומדים בפני תביעה משפטית, עד כמה זמן ניתן יהיה לגלות מידע בהתחשב בשיטות השמירה הנוכחיות שלכם?
אינכם זקוקים לסטטיסטיקה מושלמת כדי לספר סיפור משכנע. השוואות פשוטות, כמו שאנו מחזיקים כיום גיבויים מלאים של תיבות דואר עבור לקוח זה במשך שבע שנים, למרות שאף חוזה או תקנה אינם דורשים זאת, מספיקות כדי להראות שההרגלים הנוכחיים מעולם לא היו החלטה מודעת של סיכון. לאחר מכן תוכלו להדגיש מערכי נתונים רגישים במיוחד, כגון מאגרי זהויות, יומני גישה מועדפים, פרטי תשלום, נתוני בריאות או ילדים, או כרטיסים המכילים צילומי מסך וקטעי מסד נתונים. כאשר אלה מופיעים במערכות מרובות ובשרשראות גיבוי ארוכות, החיסרון של שמירה בלתי מבוקרת הופך ברור מאליו.
יחד, קו בסיס זה נותן לכם נרטיב רב עוצמה: הארגון שלכם נושא סיכון ועלויות בלתי נראים כתוצאה מנתונים שהוא לא באמת צריך. זה יוצר פתח ברור להצעת גישה תואמת ISO 27001 שתגן על העסק, מרגיע את הלקוחות ותמצב את ספק שירותי הניהול הניהולי שלכם כשותף בוגר ואמין ולא כאגרן נתונים מלא תקווה.
הזמן הדגמהמה באמת מצפה תקן ISO 27001 מספקי שירותי ניהול שירותים (MSPs) בנוגע לשמירה ומחיקת נתונים?
תקן ISO 27001 מצפה מספק שירותי ניהול (MSP) שלכם לתכנן ולהפעיל מודל מחזור חיים מבוסס סיכונים, במקום לנחש מספרים קבועים עבור כל יומן או כרטיס. גישה מבוססת סיכונים זו היא האופן שבו ISO 27001 והנחיות קשורות בדרך כלל מנסחים את ניהול מחזור החיים של מידע, תוך התמקדות בהבנת ההקשר ובטיפול בסיכונים במקום לקבוע מגבלות זמן אוניברסליות; פרשנות בתעשייה, למשל של Cloud Security Alliance, מחזקת פרשנות זו. עליכם להבין את הציפיות המשפטיות ואת הציפיות של הלקוחות, להגדיר כללי שמירה ומחיקה ברורים, למפות אותם לבקרות בנספח A ולאחר מכן להראות למבקרים שאתם מיישמים אותן באופן עקבי בכלים, לקוחות וחוזים. התקן דואג הרבה יותר לקוהרנטיות ולפעולה של מודל זה מאשר לכל תקופת זמן בודדת, ותקופות ספציפיות צריכות תמיד להיות מוסכמות עם יועצים משפטיים בתחומי השיפוט שבהם אתם ולקוחותיכם פועלים.
כשני שלישים מהארגונים בדוח מצב אבטחת המידע לשנת 2025 אומרים כי המהירות והיקף השינויים הרגולטוריים מקשים על שמירה על תאימות.
סעיפי מערכת הניהול קובעים את הציפיות. עליכם להבין את צרכי הצדדים המעוניינים (כולל לקוחות ורגולטורים), לזהות דרישות משפטיות וחוזיות, להעריך סיכונים למידע ולבחור בקרות לטיפול בסיכונים אלה. לאחר מכן עליכם להגדיר מדיניות ויעדים, ליישם בקרות תפעוליות, לנטר ביצועים, לבצע ביקורות פנימיות ולקדם שיפור מתמיד. שמירה ומחיקה נמצאות בתוך לולאה זו כמו כל מערך בקרה אחר ויש לבחון אותן באותו קצב כמו ניהול גישה או טיפול בפגיעויות.
נספח א' מבהיר את זווית מחזור החיים. העדכון של 2022 הציג וחיזק מספר בקרות אשר, יחד, מגדירות כיצד יש לחשוב על שמירה. סיכומים של עדכון 2022 לתקן ISO 27001 מדגישים בקרות חדשות ומתוקנות של נספח א' סביב מחיקת מידע, גיבוי ורישום, שכולן משפיעות על האופן שבו ארגונים מעצבים שמירה וסילוק כחלק ממערך הבקרות הכולל. סקירות בלתי תלויות של השינויים של 2022, כגון אלו שפורסמו על ידי משאבי סייבר מומחים, מדגישות את השינוי בדגש הזה.
כמעט כל הארגונים בסקר ISMS.online לשנת 2025 מציינים השגה או שמירה על אישורי אבטחה כגון ISO 27001 או SOC 2 כעדיפות.
- הגנה על רשומות: הבטחת שמירת רשומות חשובות ומוגנות למשך הזמן הנדרש.
- סיווג מידע: וידוא שהמידע מסווג, מכיוון ששמירה וסילוק ישתנו בהתאם לקטגוריה.
- גיבוי מידע: הבטחת גיבויים בהתאם לכללי שמירה ושחזור מתועדים.
- מחיקת מידע: הבטחת מחיקת מידע כאשר אינו נחוץ עוד ומחיקה זו מפחיתה את הסיכוי לשחזורו.
- סילוק או שימוש חוזר בטוחים של ציוד: וידוא שאמצעי אחסון אינם דולפים נתונים בעת שימוש חוזר או השמדה.
- רישום וניטור: שמירת יומני רישום למשך הזמן הנדרש לצורכי אבטחה ותאימות, ולאחר מכן סילוקם כראוי.
עבור מנהלי שירותים מרכזיים, ציפיות אלו מתבטאות בשלושה ממדים מעשיים.
אתם משלבים בין זכויות פרטיות, כללי שמירת רשומות וציפיות הלקוחות על ידי קבלת החלטות מודעות ומתועדות בנוגע לשמירה, במקום להשאיר למהנדסים או מנהלי לקוחות לאלתר. תקן ISO 27001 מצפה לראות כיצד אתם מאזנים בין מזעור נתונים, חובות שמירת רשומות ואינסטינקטים של "לשמור הכל" בהערכות הסיכונים, במדיניות ובחוזים שלכם.
לעתים קרובות אתה נתקע בין שלושה כוחות:
- חוקי פרטיות וציפיות להגנת נתוני לקוחות, אשר מדגישות מזעור נתונים ותקופות שמירה מוגדרות. רשויות פיקוח כגון משרד נציב המידע של בריטניה מדגישות במפורש הגבלת אחסון, מזעור נתונים ולוחות זמנים ברורים לשמירה בהנחיות שלהן בנוגע לשמירה ומחיקה.
- כללי שמירת רישומים של מגזרים ותאגידים, המחייבים שמירת נתונים מסוימים במשך שנים.
- לקוחות ומהנדסים שבוחרים כברירת מחדל "לשמור הכל" כי זה מרגיש בטוח יותר.
תקן ISO 27001 מצפה שתפתור את המתח הזה במפורש ולא לתת לו להתפתח אד-הוק. פתרון זה אמור להיות גלוי ב:
- הערכת הסיכונים שלך, שבה אתה מתעד את הסיכון של שימור יתר וחסר ואת ההיגיון בתקופות שנבחרו.
- מדיניות ונהלים הקובעים כמה זמן נשמרים סוגי מידע שונים וכיצד הם נמחקים או מאוחסנים בארכיון.
- חוזים, הסכמי רמת שירות והסכמי עיבוד נתונים שקובעים מי קובע את תקופות השמירה, כיצד מטופלות בקשות מחיקה ומה קורה בסוף חוזה.
אתם זקוקים גם לעמדה ברורה בנוגע לזכויות פרטיות, כגון מחיקה. חלק מהמסגרות מאפשרות לכם לשמור נתונים במקרים בהם יש לכם חובה חוקית או שאתם זקוקים להם כדי להגן על תביעות משפטיות, גם אם מישהו מבקש מחיקה. תקן ISO 27001 אינו פוסל זאת, אך הוא מצפה מכם לתעד את הבסיסים המשפטיים הללו ולהתייחס לשמירת יתר כסיכון בפני עצמו.
הפיכת שפת הסטנדרטים למודל מחזור חיים עובד
הופכים את שפת התקנים למודל מחזור חיים עובד על ידי תרגום סעיפים ורשימות בקרה לרצף פשוט שמראה היכן נוצרים, משתמשים, מאוחסנים, מאוחסנים ונמחקים נתונים. כאשר מהנדסים וצוותי תיקי לקוחות יכולים לראות היכן במחזור החיים הזה מתקבלות החלטות אמיתיות, שמירה מפסיקה להיות ויכוח מופשט על ניסוח והופכת לדיון עיצובי קונקרטי.
צוותים מבינים מחזורי חיים הרבה יותר בקלות מאשר רשימות ארוכות של מקורות בקרה. אם מתרגמים את דרישות ISO 27001 למחזור חיים פשוט וניתן לחזרה, אנשים יכולים לראות היכן מתקבלות באמת החלטות שמירה ומחיקה.
מחזור חיים פשוט יכול להיראות כך:
שלב 1 – יצירה וצילום
נתוני לקוחות נכנסים תחילה למערכות שלכם דרך כרטיסים, ניטור, טפסי קליטה, מפגשים מרחוק או אינטגרציות. אתם מחליטים מה אתם אוספים וכיצד הם מסווגים.
שלב 2 – שימוש ושיתוף
מהנדסים וכלים מעבדים את הנתונים הללו לצורך תמיכה, שינוי, ניטור, חיוב או דיווח. בקרת גישה והגבלת מטרה חשובות כאן.
שלב 3 – אחסון והגנה
הנתונים נמצאים במערכות פעילות, יומני רישום, מסדי נתונים ותיבות דואר, ומשוכפלים לגיבויים, ארכיונים ואנליטיקה. חלים דרישות שמירה ובקרות הגנה.
שלב 4 – אחסון בארכיון והגבלה
נתונים בזמן אמת מצטמצמים, מסוכמים או מועברים לאחסון לטווח ארוך יותר מסיבות משפטיות או עסקיות. אתם מצמצמים במכוון את מה שנשאר באינטרנט.
שלב 5 – מחיקה או אנונימיזציה
מידע שאינו נחוץ עוד נמחק בצורה מאובטחת או הופך לאנונימי באופן בלתי הפיך בעותקים ראשוניים ומשניים, כולל גיבויים ועותקים משוכפלים.
כל שלב ממופה לבקרות ספציפיות של ISO 27001 ולמערכות וצוותים ספציפיים. כאשר אנשים יכולים לראות את הקשר הזה, דיונים על שימור נתונים הופכים פחות מופשטים ויותר קשורים לתכנון: אילו בקרות חלות על אילו נתונים, היכן במחזור החיים ועם איזה סוג של ראיות.
ברגע שיש לכם את המודל המנטלי הזה, השלב הבא הוא להפוך אותו למדיניות שמירה סטנדרטית ולוח זמנים עבור ה-MSP שלכם, במקום לאפשר לכל לקוח או בעל מוצר להמציא את הכללים שלו.
ISO 27001 בקלות
יתרון של 81% מהיום הראשון
עשינו את העבודה הקשה בשבילך, ונתנו לך התחלה של 81% מרגע הכניסה. כל שעליכם לעשות הוא להשלים את החסר.
כיצד ניתן לעצב מדיניות שמירה סטנדרטית ולתזמן את ההגנה של ה-MSP?
אתם מעצבים מדיניות שימור נתונים ניתנת להגנה עבור ספק שירותי ניהול הנתונים (MSP) שלכם על ידי יצירת לוח זמנים אחד מבוסס סיכונים המכסה את כל קטגוריות הנתונים המרכזיות, תוך שימוש בקבוצה קטנה של טווחי זמן סטנדרטיים עם נימוקים ברורים, ולאחר מכן עטיפת לוח הזמנים הזה במדיניות, בעלות ובקרת שינויים. זה נותן לכם קומה אחת שתוכלו להסביר למבקרים, לקוחות ומהנדסים, במקום הסכמים חד-פעמיים שבירים או עשרות כללים מותאמים אישית שבלתי אפשרי ליישם באופן עקבי בפועל.
מדיניות שימור נתונים הגנתית אינה מנסה לחזות כל מקרה קצה. היא מגדירה כללי ברירת מחדל ברורים, הקשורים לרגולציה ולסיכון, ומספקת לך דרך מובנית לטפל בחריגים מוצדקים. עבור ספק שירותי ניהול שירותים (MSP), משמעות הדבר היא תכנון לוח זמנים ומדיניות שיכולים לכסות שירותים ולקוחות רבים, תוך שמירה על פשטות מספיק ליישום והסבר.
נקודת ההתחלה היא לוח זמנים ראשי לשמירת נתונים. זוהי תצוגה פנימית אחת של:
- אילו קטגוריות של מידע אתם מחזיקים, כגון יומני אבטחה, פניות תמיכה, נתוני תצורה, נתוני ניטור, מיילים, רישומי חוזים ותמונות גיבוי.
- מטרת כל קטגוריה והאם היא מכילה נתונים אישיים, מידע רגיש או רשומות עם דרישות שמירה חוקיות מפורשות.
- תקופות המינימום והמקסימום להן יש לשמור את המודול, יחד עם הסיבה (חוק, חוזה, צורך עסקי, תיאבון לסיכון).
- מה אמור לקרות בסוף תקופה זו: למחוק, לאחסן בארכיון אחר, להפוך לאנונימי או לסכם.
במקום להמציא מאות תקופות מותאמות אישית, רוב ספקי שירותי ה-MSP משרתים טוב יותר קבוצה קטנה של טווחי זמן סטנדרטיים, כגון שלושים יום, תשעים יום, שנה אחת, שלוש שנים, שבע שנים ו"סוף חוזה ועוד X". כל קטגוריה ממופה לאחת מהטווחים הללו כברירת מחדל, עם הצדקה מתועדת.
דוגמה זו מראה כיצד קבוצה קטנה של להקות יכולה לכסות צרכים רבים:
| קטגוריה | להקה אופיינית | הרציונל העיקרי |
|---|---|---|
| יומני אבטחה | תשעים יום - שנה אחת | חלונות גילוי וחקירה |
| כרטיסי תמיכה | שלוש-שבע שנים | מחלוקות והיסטוריית שירות |
| נתוני תצורה | סוף חוזה ועוד אחד | שחזור ופתרון בעיות |
| גיבויים (תמונות) | תשעים יום - שבע שנים | שחזור וחובות משפטיות |
| חוזים | שבע שנים או יותר | ניהול רישומים משפטיים ופיננסיים |
אלו הן דוגמאות, לא מרשמים, אך הן ממחישות כיצד ניתן לשמור על מספר קטן של רצועות ועדיין לענות על צרכים מגוונים. הנקודה החשובה היא שלכל תקופה יש מטרה ברורה וניתן להגן עליה.
מלוח זמנים למדיניות ובעלות
אתם הופכים לוח זמנים של שמירה למשהו שה-MSP שלכם יכול להפעיל על ידי הקפתו במדיניות, בעלות ברורה ותהליכי עבודה פשוטים להסכמה ושינוי של כללים. בלי זה, אפילו לוח זמנים מעוצב היטב יתנדנד עם הזמן והמהנדסים יחזרו בשקט ל"לשמור הכל".
מדיניות השמירה והמחיקה שלך צריכה:
- ציינו את העקרונות שאתם פועלים לפיה: מזעור, הגבלת מטרה, אבטחה, תאימות לחוק ושקיפות ללקוח.
- הצבע במפורש על לוח הזמנים כמקור הסופי של כללי השמירה ותאר כיצד הוא יתוחזק.
- מפו את הכללים הללו חזרה לדרישות ISO 27001 ולכל מסגרת אחרת שאתם טוענים שאתם פועלים לפיה.
- התחייבו לשיטות מחיקה מאובטחות ולהאריך את השמירה רק באמצעות תהליך קבלת החלטות רשמי.
חשוב לא פחות להחליט מי אחראי על לוח הזמנים. בחברות ממשל רבות מדובר באחריות משותפת, אך מישהו צריך להיות אחראי באופן ברור.
אפשר להסביר בעלות בגישה פשוטה כזו:
| תפקיד | אחריות עיקרית |
|---|---|
| ראש אבטחה/תאימות | התאמה לתקנים, לחוק ולתיאבון לסיכון |
| ראש תפעול | יישום טכני בכלים ופלטפורמות |
| צוותי חשבונות/משפט | השפעה מסחרית וחוזית של בחירות שימור |
| הנהלה/דירקטוריון | אישור שינויים משמעותיים ופשרות סיכונים |
שינויים בתקופות שמירה, או חריגים ספציפיים ללקוח, צריכים לעבור דרך תהליך עבודה פשוט: הצעה, הערכת השפעה, סקירת סיכונים, אישור, יישום והוכחות. פלטפורמת ISMS כמו ISMS.online יכולה לסייע כאן על ידי אחסון המדיניות והלוח הזמנים, מעקב אחר אישורים, קישור כל כלל לסיכונים ובקרות, ומתן נתיב ביקורת ברור עבור מבקרים פנימיים וחיצוניים.
כיסוי המציאות המבולגנת של נתונים לא מובנים
אתם מכסה את המציאות המבולגנת של נתונים לא מובנים על ידי התייחסות לדוא"ל, צ'אט, כוננים משותפים וסביבות עבודה אישיות כמקורות מהשורה הראשונה בלוח הזמנים של שמירת הנתונים שלכם, ולא כמחשבות שלאחר מעשה. משמעות הדבר היא הגדרת כללים פשוטים שהפלטפורמות שלכם יכולות לאכוף, סיוע למהנדסים ולצוותי תיקי לקוחות להבין אותם ובדיקת תרחישים מציאותיים כדי שתוכלו להסביר מה קורה לנתונים לא מובנים כאשר לקוחות עוזבים, רגולטורים חוקרים או אנשים פרטיים מממשים את זכויות המחיקה שלהם.
נתונים לא מובנים לעיתים קרובות פוגעים בלוח זמנים מסודר בדרך כלל. דוא"ל, צ'אט, כוננים משותפים וסביבות עבודה אישיות יכולים להכיל כמויות גדולות של מידע מלקוחות שכמעט ולא מכוסה על ידי כללי שמירה פורמליים.
כדי להפוך את לוח הזמנים והמדיניות שלכם לניתנים להגנה אמיתית, עליכם:
- התייחסו לחנויות לא מובנות כמקורות נתונים מהשורה הראשונה בלוח הזמנים, לא למחשבה שלאחר מעשה.
- הגדירו כללי שמירה שעובדים עם היכולות של הפלטפורמות שבחרתם, כגון שמירת הודעות בכלי שיתוף פעולה או יישור דוא"ל לארכיון ולאחר מכן מחיקה.
- היו ריאליים לגבי מה שמהנדסים וצוותי תיקי לקוחות יכולים לפעול לפיו; כללים מורכבים מדי בתחום זה צפויים להתעלם.
לפני שאתם מכריזים על גמור העיצוב, סקור כמה תרחישים מציאותיים:
- לקוח ותיק עוזב ומבקש ממך להסביר מה יימחק מתי, מה יועבר לארכיון ומה עליך לשמור מסיבות משפטיות.
- רגולטור חוקר אירוע המשפיע על לקוח ספציפי ושואל כמה רחוק ניתן להסתכל ומדוע.
- נושא מידע מממש את זכותו למחיקה ועליך להראות היכן נמצאו הנתונים שלו ומה עשית בנידון.
אם לוח הזמנים והמדיניות שלכם יכולים לייצר תשובות ברורות ואמינות בתרחישים אלה, אתם מוכנים להתאים את המודל להסכמי רמת שירות מגוונים של לקוחות מבלי לוותר על שליטה.
גבולות ברורים הופכים הרגלי נתונים מבולגנים לפרקטיקות ניתנות לניהול וניתנות לביקורת.
כיצד מתאימים את המודל הסטנדרטי שלכם להסכמי רמת שירות מגוונים של לקוחות מבלי לאבד שליטה?
אתם מתאימים את מודל שימור הלקוחות הסטנדרטי שלכם להסכמי רמת שירות מגוונים של לקוחות על ידי הצעת קטלוג קטן של אפשרויות מוגדרות מראש, שכולן ממוספרות ללוח הזמנים הראשי שלכם, במקום לנהל משא ומתן על מספרים ייחודיים בכל חוזה. בדרך זו, צוותי המכירות והלקוחות יכולים להתגמש בהתאם לצורכי המגזר, בעוד שתפעול ואבטחה עדיין מפעילים מודל מחזור חיים קוהרנטי אחד, ואתם נמנעים מהבטחות שימור שאינכם יכולים לספק באופן מציאותי.
דו"ח מצב אבטחת המידע לשנת 2025 מצביע על כך שלקוחות מצפים יותר ויותר מספקים להתאים את עצמם למסגרות פורמליות כגון ISO 27001, ISO 27701, GDPR או SOC 2 במקום להסתמך על נהלים כלליים מומלצים.
הסכמי רמת שירות וחוזים עם לקוחות הם המקום שבו העיצוב הפנימי שלכם עומד בציפיות החיצוניות. אם כל עסקה חדשה מייצרת הבטחות שימור לקוחות מותאמות אישית, לוח הזמנים שלכם הופך במהרה לבלתי אפשרי לתפעול. התשובה היא לחשוף את המודל הסטנדרטי שלכם כמספר קטן של אפשרויות ברורות ולהבהיר את תחומי האחריות המשותפים.
במקום לתת למכירות או ללקוחות לבחור מספרים שרירותיים, צרו קטלוג של אפשרויות שימור עבור רכיבי שירות מרכזיים:
- עבור יומני רישום: שלושים, תשעים או שלוש מאות ושישים וחמישה ימים של יומני אבטחה מקוונים, עם אפשרויות אחסון מוסכמות.
- עבור גיבויים: גיבויים יומיים למשך תשעים יום, בתוספת תמונות חודשיות למשך שנים עשר חודשים, בתוספת תמונות שנתיות למשך שבע שנים עבור לקוחות מוסדרים.
- עבור נתוני כרטיסים: שלוש שנים כברירת מחדל וטרווים ארוכים יותר עבור מגזרים עם חלונות זמן ארוכים יותר לסכסוכים.
- עבור נתוני אפליקציה מתארחת: משך החוזה בתוספת תקופת חסד קצרה.
כל אפשרות מתאימה בצורה ברורה לטווח מסוים בלוח הזמנים שלך. צוותים מסחריים יכולים להסביר את הפשרות, וצוותי תפעול יודעים בדיוק כיצד ליישם אותן.
הפיכת אחריות משותפת לגלויה
אתם הופכים את האחריות המשותפת לגלויה על ידי הגדרת מי מגדיר שמירת נתונים, מי גורם למחיקות ומי יכול להטיל החזקות משפטיות, במקום להניח שלכולם יש את אותו מודל מחשבתי. תפקידים ברורים ביניכם, בין הלקוחות שלכם ובין כל ספק צד שלישי מונעים הפתעות מכוערות ביציאה מהחברה, חקירות או ביקורות.
אחריות על שמירה ומחיקה מטופלת לעיתים קרובות במקום להיכתב. זה מוביל לחיכוכים כאשר לקוח מצפה שהנתונים ייעלמו אך עדיין יש לך אותם בגיבויים, או כאשר הוא מניח שתשמור לוגים למשך זמן רב יותר מהכלים שלך.
שימוש במודל RACI פשוט (Responsible, Accountable, Consulted, Informed) יכול למנוע זאת. עבור כל פעילות עיקרית, כגון הגדרת תקופת שמירה, אישור או דחייה של בקשת מחיקה, ביצוע מחיקה בסוף חוזה או העברת נתונים להחזקה משפטית, ניתן לציין:
- על מה אתה אחראי, כגון הגדרת כלים, תחזוקת גיבויים, הרצת משימות מחיקה ואספקת ראיות.
- על מה הלקוח אחראי, כגון החלטה כמה זמן הוא רוצה לשמור רשומות מסוימות והנחיה בכתב למחוק או לשמור אותן.
- כאשר האחריות משותפת, למשל כאשר אתה מספק יכולות אבל הלקוח מחליט כיצד ליישם אותן.
- מה עושים ספקי צד שלישי, והיכן מתחילות ומסתיימות חובותיך לפקח עליהם.
מודלים אלה לא צריכים להתקיים רק במסמכים פנימיים. עליהם לבוא לידי ביטוי בהסכמי שירות ראשיים, הסכמי רמת שירות והסכמי עיבוד נתונים. ניסוח ברור ותקני לגבי טיפול בנתונים בסוף השירות, חלונות מחיקה, סיוע בהעברת נתונים וציפיות לראיות הופך את היציאה מהשירות לחזויה יותר ופחות שנויה במחלוקת.
עליכם להיות כנים גם לגבי מה הפלטפורמות שלכם יכולות ומה לא יכולות לעשות. הבטחה לשחזור נקודתי בזמן במשך עשר שנים של גיבויים כאשר הכלי והתקציב שלכם תומכים רק בשלוש שנים אינה רק סיכון מסחרי; תחת ISO 27001 זוהי בעיה של תכנון ויעילות בקרה.
סיוע ללקוחות בבחירת פשרות ותיעודן
אתם עוזרים ללקוחות לבחור אפשרויות שימור ותעדו פשרות על ידי הסבר בשפה פשוטה מה המשמעות של כל דפוס עבור חקירות, פרטיות, עלות וסיכון חוזי. זה מעביר את הדיון מ"בחר מספר" ל"בחר תוצאה" ומספק לכם החלטות כתובות שתוכלו להתייחס אליהן בחזרה בתקריות, ביקורות וחידושים.
לקוחות מגיעים לעיתים רחוקות עם תמונה מלאה של צרכי שימור הלקוחות שלהם. אתם מוסיפים ערך אמיתי כשאתם עוזרים להם להבין את ההשלכות של בחירות שונות ומתעדים את ההחלטות הללו בצורה ברורה, כך שלא ייבחנו שוב בכל אירוע או ביקורת.
ניתן לתמוך בהחלטות טובות על ידי:
- הסבר במילים פשוטות מה המשמעות של אפשרויות שונות עבור חקירות, פרטיות ועלות.
- סיוע ללקוחות לנסח דרישות ספציפיות למגזר בשלב מוקדם של תהליך המכירה, כך שתוכלו למפות אותן לדפוסים מציאותיים.
- תיעוד האפשרויות שנבחרו והרציונל, לא רק המספרים.
לדוגמה, לקוח המספק שירותים פיננסיים עשוי להחליט על שמירת יומנים וקרשות ארוכה יותר כדי לתמוך בחקירות נגד הונאות, בעוד שלקוח המספק טכנולוגיית בריאות עשוי לבחור במחיקה אגרסיבית יותר של נתונים מסוימים כדי להפחית את סיכון הפרטיות. שתי האפשרויות יכולות להתאים למסגרת שלכם אם הן מודעות, מתועדות וניתנות ליישום טכנית.
ברגע שיהיו לכם דפוסים אלה, תוכלו להתאים את הכלים והתהליכים שלכם סביבם. זהו השלב הבא: לוודא שפלטפורמות הגיבוי, הרישום והשיתוף פעולה אכן אוכפות את מה שכתוב כעת בחוזים ובמדיניות שלכם.
שחררו את עצמכם מהר של גיליונות אלקטרוניים
הטמע, הרחב והרחיב את תאימותך, ללא כל בלגן. IO מעניק לך את החוסן והביטחון לצמוח בצורה מאובטחת.
כיצד אתם מתאימים גיבויים, יומני רישום ואפליקציות מתארחות למודל השמירה שלכם?
אתם מתאימים גיבויים, יומני רישום ויישומים מתארחים למודל השמירה שלכם על ידי הפיכת כל ערך בלוח הזמנים שלכם להגדרות, סקריפטים וזרימות עבודה קונקרטיות במערכות המחזיקות בנתוני הלקוח, ולאחר מכן ניטור תצורות אלו לאורך זמן. המטרה היא שהכלים שלכם ישקפו את טווחי השמירה שבחרתם, ולא את ברירת המחדל שלהם, ושתוכלו להוכיח התאמה זו כאשר מבקרים או לקוחות שואלים על ידי הצגת כיצד מדיניות, חוזים ובקרות ISO 27001 מתורגמים לתצורות אמיתיות.
לוח זמנים ומערכת של דפוסי SLA אינם משמעותיים במיוחד אם המערכות המחזיקות בנתונים שלכם עושות משהו שונה. עבור ספקי שירותי ניהול שירות (MSPs), העבודה הקשה ביותר היא לעתים קרובות תרגום המודל להגדרות, סקריפטים וזרימות עבודה על פני מגוון כלים.
גיבויים הם בדרך כלל בראש סדר העדיפויות. מבחינה היסטורית, ספקי שירותי ניהול שירותים (MSP) רבים התייחסו למערכות גיבוי כאל מאגרי מידע הניתנים לכתיבה חד פעמית וניתנים להרחבה לנצח. תחת ISO 27001 וציפיות פרטיות מודרניות, זה כבר לא בר קיימא. הן פרשנויות ISO 27001/27002 והן דיונים על תקני פרטיות בנושא מזעור נתונים ומגבלות אחסון מצביעים על כך שקשה להצדיק שמירת גיבויים ללא הגבלת זמן אלא אם כן קיימת דרישה חוקית או חוזית ברורה.
עליך להחליט, עבור כל מערך נתונים גיבוי:
- באיזו תדירות אתם לוקחים עותקים ובאיזו רמת פירוט.
- כמה גרסאות אתה שומר וכמה זמן אתה שומר אותן.
- כאשר נתונים פגים או מוסרים ממאגרי גיבוי ראשיים ומשניים.
- האם ניתן להשמיד מפתחות הצפנה כדי להפוך נתונים ישנים לנגישים.
החלטות אלו חייבות לבוא לידי ביטוי במדיניות הגיבוי, ולא רק לברירות המחדל. הן צריכות להתיישר עם יעדי ההתאוששות והדרישות החוקיות, ועליכם להיות מסוגלים להראות למבקרים וללקוחות היכן הגדרות אלו נמצאות וכיצד אתם מנטרים אותן.
שליטה ביומנים ובארכיונים
אתם מקבלים שליטה על יומני רישום וארכיונים על ידי סיווגם, קביעת תקופות שמירה ריאליות ושימוש בכלי היומנים והארכיון שלכם כדי ליישם ולנטר את ההחלטות הללו. יומנים שבעבר הרגישו חסרי משמעות יכולים להפוך לנטל משמעותי לפרטיות ולאחסון אם הם נשמרים ללא הגבלת זמן, ולכן עליהם לשבת תחת אותו לוח זמנים כמו כל דבר אחר במקום לחיות בפני עצמם.
יומני רישום הם מלכודת נפוצה. צוותי אבטחה רוצים לעתים קרובות חלונות זמן ארוכים כדי לסייע בציד איומים ובתגובה לאירועים. צוותי פרטיות וסיכונים מתמקדים בשמירה על נתונים ניתנים לזיהוי זמן רב מהנדרש. צוותי אחסון וביצועים מודאגים מנפח ועלות.
הדרך היא ל:
- סווג יומני רישום לפי מטרה ורגישות. יומן אימות שונה ממעקב ניפוי שגיאות מפורט.
- קבעו תקופות שמירה התואמות את חלונות הזמן שאתם באמת צריכים לגילוי, חקירה ותאימות, ולאחר מכן גבו את ההחלטות הללו בהערכות סיכונים. עבור ספקי שירותים ניידים מסוימים, פירוש הדבר הוא מספר חודשים עבור אירועי אבטחה ותקופות קצרות יותר עבור נתוני ניפוי באגים בנפח גבוה.
- השתמש בכלים לניהול יומנים או ניהול מידע אבטחה ואירועים כדי ליישם תקופות אלו ולסכם או להפוך נתונים לאנונימיים כאשר היסטוריה מפורטת אינה נדרשת עוד.
ארכיונים, בין אם מדובר בדואר, כרטיסים או תמונות, זקוקים גם הם לתשומת לב מפורשת. קל למערכות ארכיון להפוך לחניה ארוכת טווח של נתונים שאף אחד לא אמיץ מספיק למחוק. שילובם בלוח הזמנים פירושו הגדרה של:
- מה זכאי לארכיון במקום למחוק אותו לחלוטין.
- כמה זמן נשמרים ארכיונים ובאיזה פורמט.
- כיצד מוגנים ארכיונים ומי יכול לגשת אליהם.
- איך נראית מחיקה או אנונימיזציה בסוף החיים.
תיעוד התשובות הללו במערכת ה-ISMS שלכם וקישורן לבקרות ולסיכונים הופך את הדיונים עם רואי החשבון והלקוחות לחלקים הרבה יותר.
טיפול במציאות מרובת דיירים וענן
אתם מטפלים במציאות מרובת דיירים וענן על ידי תכנון דפוסי הפרדה ומחיקה לוגיים התואמים לאילוצים טכניים, ולאחר מכן הסבר ברור של דפוסים אלה בחוזים ובהודעות הפרטיות שלכם. ייתכן שלא תוכלו לבודד פיזית את הנתונים של לקוח אחד לפי דרישה, אך עדיין תוכלו לעמוד בציפיות סבירות על ידי שימוש במזהי דיירים, הצפנה וצבירה מוגבלת בזמן.
ספקי שירותי ניהול שירותים (MSP) רבים מספקים שירותים בפלטפורמות מרובות דיירים: צוברי יומנים המשלבים אירועים מלקוחות רבים, מערכות גיבוי המאחסנות תמונות זו לצד זו, שירותי ענן הממקמים יחד נתוני דיירים. זה מעלה שאלות קשות כאשר לקוח יחיד עוזב או מפעיל זכויות על הנתונים שלו.
ניתן לנהל את המציאות הזו על ידי:
- תכנון הפרדה לוגית, כגון מזהי דיירים עבור יומני רישום ונתונים, כך שתוכלו לסנן ולבודד את המידע של לקוח אחד.
- בחירת גישות מחיקה שמתאימות לאילוצים מרובי דיירים, לדוגמה השמדת מפתחות עבור מערכי נתונים מוצפנים או הסרת מזהי דיירים מיומני רישום מצטברים לאחר תקופה מסוימת.
- להיות ברור בחוזים ובהודעות פרטיות לגבי מה שניתן ומה אסור למחוק מסביבות משותפות.
חשוב גם לשלב הגדרות הקשורות לשמירה בתהליך ניהול השינויים שלכם. כאשר כלים משודרגים או תצורות מתאימות, מישהו צריך לבדוק ששמירה של יומן, גיבוי וארכיון עדיין תואמת את לוח הזמנים שלכם. בלי זה, יישור תהליכים שהושגו קשה יכול להיסחף בשקט עם הזמן.
ברגע שהמערכות שלכם ישקפו את כללי השמירה שלכם, אתם יכולים לדבר בצורה אמינה על מחיקה מאובטחת: לא רק ללחוץ על כפתור מחיקה על רשומה, אלא לוודא שהיא בלתי ניתנת לשחזור כאשר היא אמורה להיות ניתנת לשחזור, מבלי לפגוע בהבטחות השחזור.
כיצד ניתן למחוק נתונים בצורה מאובטחת מבלי להפר את הבטחות השחזור?
ניתן להשיג מחיקה מאובטחת מבלי לפגוע בשחזור על ידי הגדרת שיטות מאושרות למערכות חיות, מדיה וגיבויים, ולאחר מכן התאמתן ללוח הזמנים של השמירה וליעדי השחזור. בפועל, זה בדרך כלל אומר שילוב של מחיקה ברמת האפליקציה, ניקוי מדיה, ועבור גיבויים מוצפנים, השמדת מפתחות, עם כללים ברורים לגבי מתי משתמשים בכל שיטה, כיצד היא מאושרת וכיצד ניתן להראות שמחיקה באמת משמעותה בלתי הפיכה.
מחיקה מאובטחת עבור MSP אינה כלי או טכניקה יחידים; זוהי קבוצה של פרקטיקות אשר יחד הופכות מידע לבלתי ניתן לשחזור כאשר זמנו נגמר, תוך שמירה על היכולת לשחזר את מה שהלקוחות מצפים שיהיה לכם באופן לגיטימי.
הגישה הנכונה משתנה בהתאם למדיום ולהקשר:
- במערכות חיות, מחיקה או אנונימיזציה של רשומות ביישומים ובמאגרי מידע בהתאם ללוח הזמנים שלך, עם עקבות ביקורת.
- על מדיות אחסון, שימוש בדריסה מאובטחת, מחיקה קריפטוגרפית או השמדה פיזית לפני שימוש חוזר או סילוק.
- בגיבויים ובעותקים משוכפלים, נתונים שפג תוקפם המבוססים על מדיניות שמירה או השמדת מפתחות שהופכים ערכות מוצפנות ישנות יותר לבלתי קריאות.
עבור כל סוג עיקרי של נתונים ואחסון שאתם מטפלים בו, עליכם להגדיר אילו שיטות מקובלות, באילו מצבים ומי יכול לאשר אותן. הגדרות אלו צריכות להיות במערכת ה-ISMS שלכם לצד נהלים תפעוליים אחרים ולהשתקף בחוזים במידת הצורך.
הוכחה ש"מחק" באמת אומר "נעלם"
אתם מוכיחים שמחיקה באמת פירושה "נעלמה" על ידי בדיקת התהליכים שלכם, רישום התוצאות והצגת האופן שבו הן קשורות לחוקי השמירה וההתחייבויות המשפטיות שלכם. לקוחות ומבקרים שואלים יותר ויותר לא רק מה אומרים נהלי המחיקה שלכם, אלא האם הם עובדים. גופים מקצועיים והנחיות בתעשייה בנוגע למחיקת נתונים מאובטחת מדגישים לא רק את קיומם של נהלים מתועדים, אלא גם אימות שהמחיקה יעילה מבחינה טכנית בפועל, למשל על ידי בדיקת שיטות מחיקה במערכות מייצגות.
לקוחות ורואי חשבון שואלים יותר ויותר לא רק מה אומרים נהלי המחיקה שלכם, אלא האם הם עובדים.
ניתן לבנות ביטחון עצמי על ידי:
- הרצת בדיקות מחיקה על מערכות מייצגות ומערכות גיבוי. לדוגמה, מחיקת נתונים עבור רשומת בדיקה, אישור היעדרות ביישומים, דיווח על מאגרי מידע וגיבויים לאחר הזמן המיועד.
- הדגמה שסבב גיבויים, תפוגה וניהול מפתחות פועלים כמתוכנן, כולל עבור עותקים בלתי ניתנים לשינוי ועותקים מחוץ לאתר.
- רישום הבדיקות, התוצאות וכל פעולות מתקנות כחלק מתוכנית הביקורת הפנימית שלך.
כמו כן, חיוני לשלב החזקות משפטיות. יהיו מקרים בהם תצטרכו להשהות מחיקה עבור לקוח, אדם או מערך נתונים מסוים עקב התדיינות משפטית, חקירות או הוראות רגולטוריות. מערכות ה-ISMS, הכרטיסים והגיבוי שלכם צריכות לתמוך ב:
- סימון נתונים או לקוחות כבעיכוב.
- מניעת מחיקה אוטומטית עבור טווחים אלה בזמן שההחזקה פעילה.
- רישום מי אישר את העצירה, מדוע ולמשך כמה זמן.
- חוזרים לשמירה ומחיקה רגילים לאחר סיום ההחזקה.
ללא שילוב זה, מהנדסים נותרים לאלתר, וייתכן בקלות שתוצאותיה יהיו מחיקת ראיות לא מכוונת או שמירה בלתי מבוקרת הרבה מעבר למה שתוכנן.
מתן הדרכה מעשית למהנדסים
אתם נותנים למהנדסים הדרכה מעשית על ידי הפיכת כללי השמירה והמחיקה שלכם לספרי ריצה ורשימות תיוג ברורים וספציפיים למערכת עבור משימות נפוצות, במיוחד ברגעים כמו הוצאת לקוח מהמערכת או הוצאת מערכת משימוש. ללא רמת פירוט כזו, אפילו מדיניות טובה מיושמת באופן לא עקבי ולא תוכלו להראות בקלות למבקרים כיצד העבודה מתבצעת.
מדיניות והערכות סיכונים נחוצות, אך הן אינן אומרות למהנדס מה ללחוץ בבוקר יום שני.
כדי להפוך את המחיקה המאובטחת למציאות, עליך לספק:
- נקו את הוראות ההכנה למשימות נפוצות, כגון הוצאת שרת משימוש, מחיקת מחשב נייד המשמש לתמיכה מרחוק, הסרת לקוח מפלטפורמת ניטור או מחיקת דייר ממערכת גיבוי.
- הנחיות ספציפיות לכלי עבודה, תוך הכרה בכך שפלטפורמות גיבוי או ענן שונות מציעות יכולות שונות וכי "מחיקה" אינה תמיד מה שהיא נראית.
- רשימות תיוג פשוטות לפעילויות בסוף חוזה, כך שמהנדסים ידעו בדיוק אילו צעדים לנקוט במערכות שונות וכיצד לתעד את השלמתן.
רשימת בדיקה קצרה וחוזרת על עצמה למחיקה בסוף חוזה עשויה להיראות כך:
שלב 1 – זיהוי המערכות הנכללות במסגרת הפרויקט
רשום את כל הפלטפורמות, הגיבויים והארכיונים המחזיקים את נתוני הלקוח, כולל כלים משותפים וכלי עבודה מרובי דיירים.
שלב 2 – ביצוע המחיקות המוסכמות
החל את שלבי המחיקה או האנונימיזציה שתצורתם נקבעה בכל מערכת, בהתאם ל-runbooks שאושרו.
שלב 3 – אימות היעדרויות וחריגים
ודא שהנתונים אינם מופיעים עוד במערכות חיות וכי כל העותקים המוחזקים מתועדים בבירור.
שלב 4 – רישום ראיות ואישורים
רשמו פניות, דוחות ואישורים כדי שתוכלו להראות מה בוצע, מתי ועל ידי מי.
ספרי ריצה אלה יכולים להיות זמינים בפלטפורמת ה-ISMS שלכם, לצד המדיניות ולוח הזמנים של השמירה שהם תומכים בהם. בדרך זו, כאשר אתם מעדכנים כלל או משנים כלי, יש לכם מקום אחד לתחזק את התהליך ודרך ברורה להראות למבקרים כיצד אנשים יודעים מה לעשות.
עם מחיקה מאובטחת מוטמעת באופן מבצעי, החלק הסופי הוא היכולת להראות, באופן משכנע וללא פאניקה, שגישת השמירה והמחיקה שלכם עובדת כאשר לקוחות או מבקרים מבקשים זאת.
ניהול כל דרישות התאימות, הכל במקום אחד
ISMS.online תומך ביותר מ-100 תקנים ותקנות, ומעניק לך פלטפורמה אחת לכל צרכי התאימות שלך.
כיצד מוכיחים את רמת השמירה והמחיקה שלכם למבקרים וללקוחות?
אתם מוכיחים את רצף השמירה והמחיקה שלכם על ידי הצגת קו ברור מהכוונה להפעלה: מדיניות ולוחות זמנים מתועדים, הממופים לבקרות ISO 27001 ולהתחייבויות הלקוח, מגובים בתצורות, כרטיסים וסקירות המדגימים שאתם עושים את מה שאמרתם. מבקרים ולקוחות רוצים קוהרנטיות, כנות וראיות שאתם לומדים מפערים, לא פנטזיה של שלמות.
כ-41% מהארגונים בסקר ISMS.online לשנת 2025 אמרו כי ניהול סיכוני צד שלישי ומעקב אחר תאימות ספקים הם אחד מאתגרי אבטחת המידע העיקריים שלהם.
בתקן ISO 27001 ובביקורות תובעניות של לקוחות, לעיתים רחוקות מתבקשים להיות מושלמים; מתבקשים להיות שיטתיים, מודעים לסיכונים וכנים לגבי חולשות. חומרי ההסבר של ISO מתארים את התקן כמסגרת ניהול מבוססת סיכונים הבנויה על שיפור מתמיד, ולא דרישה לביצועי בקרה ללא רבב, דבר התואם היטב את הציפייה הזו.
הוכחת סיפור מחזור חיי הנתונים שלכם פירושה הוכחה שיש לכם תוכנית, שאתם מיישמים אותה, שאתם מנטרים ומשפרים אותה.
חבילת ראיות טובה לשמירה ומחיקה תכלול בדרך כלל:
- מדיניות ותקנים המכסים את מחזור חיי המידע, שמירה, מחיקה, גיבוי וסילוק.
- לוח הזמנים של השמירה וכל החריגים המתועדים.
- דוגמאות של תצורות מערכת המציגות הגדרות שמירה בכלים מרכזיים.
- רישומי בקשות מחיקה, פעילויות בסוף חוזה והשמדת מדיה.
- תוצאות של בדיקות או ביקורות פנימיות, עם ממצאים ופעולות תיקון.
המטרה אינה לקבור מבקרים או לקוחות בצילומי מסך. המטרה היא להציע קו ראייה ברור, החל מכוונה (מדיניות והערכת סיכונים), דרך תכנון (לוח זמנים והסכמי רמת שירות), דרך תפעול (הגדרות וקרשות), ועד לפיקוח (מדדים וסקירות).
הפיכת ניהול מחזור החיים לגלוי בתוך ה-MSP שלך
אתם הופכים את ניהול מחזור החיים לגלוי בתוך ה-MSP שלכם על ידי התייחסות לשמירה ומחיקה כנושא ניהול מתמשך, ולא כמעין טרום-ביקורת. כאשר מנהיגים, מבקרים ולקוחות רואים מדדי מחזור חיים לצד מדדי אבטחה אחרים, הם מבינים שהנתונים מנוהלים לאורך כל חייה אצלכם, לא רק ברגע ההסמכה.
ניתן להביא את ניהול מחזור החיים לקצב ניהולי רגיל על ידי:
- בניית לוחות מחוונים או דוחות פשוטים המציגים אילו מערכות תואמות ללוח הזמנים של השמירה, היכן קיימים חריגים והיכן פעולות איחרו.
- מעקב אחר קומץ מדדי KPI משמעותיים, כגון זמן השלמת בקשות מחיקה, שיעור המערכות עם הגדרות שמירה מאומתות, או מספר אירועים הקשורים לשמירה. לדוגמה, ייתכן שתשאפו לכך שיותר מ-95% מהמערכות הנכללות במסגרת התוכנית יהיו בעלות תצורת שמירה מאושרת שנתית.
- הכללת נושאי מחזור חיים בסקירות הנהלה לצד מדדים אחרים של ISO 27001, אירועים וביצועי בקרה.
זה לא רק מכין אתכם טוב יותר לבדיקה חיצונית; זה גם מקל על הצדקת עלויות אחסון וכלי עבודה, כי אתם יכולים להראות להנהלה בדיוק אילו החלטות שימור עובדים הם קיבלו וכמה עולה לקיים אותן.
זה גם נותן לכם יתרון משמעותי ללקוחות: אתם לא מתייחסים לנתונים שלהם כאל מחשבה שנייה, אלא כנכס מנוהל לאורך כל חייהם אצלכם.
שימוש חוזר בראיות ומשוב על לקחים
אתם מפחיתים מאמץ ומשפרים את הבקרות שלכם כשאתם מתייחסים לשאלות של ביקורת ולקוחות כהזדמנויות לחדד את מערך הראיות ואת מודל מחזור החיים שלכם, במקום כמשימות חד פעמיות. שימוש חוזר ומשוב הם המקום שבו ההבטחה לשיפור מתמיד של ISO 27001 הופכת לגלויה, והמקום שבו אתם יכולים להדגים ללקוחות שהמשוב שלהם משנה את אופן פעולתכם.
בעזרת סט מאורגן של חומרים ודוחות, תוכלו להגיב לשאלונים ולביקורות של לקוחות בצורה יעילה הרבה יותר. במקום לאסוף חומרים מאפס בכל פעם, תוכלו:
- ספק דוגמאות סטנדרטיות ומצומצמות של כרטיסי מחיקה, אישורי השמדת מדיה וייצוא תצורה.
- סקור את מודל מחזור החיים ואת לוח הזמנים שלך, והראה כיצד הוא חל על שירותיו של אותו לקוח.
- הדגימו שיפורים אחרונים שביצעת על סמך לקחים שנלמדו, ממצאי ביקורת או משוב מלקוחות.
שיפור מתמיד אינו רק סיסמה בתקן ISO 27001; זוהי חוזק אמיתי כאשר לקוחות רואים שאתם מתייחסים ברצינות לחששות שלהם ולשינויים הרגולטוריים שלהם ומשקפים אותם בעדכונים לבקרות שלכם.
פלטפורמת ISMS כמו ISMS.online יכולה להקל על כך הרבה יותר על ידי:
- משמש כבית יחיד עבור המדיניות, לוח הזמנים של שימור הנתונים, הסיכונים, מיפויי הבקרה, הביקורות הפנימיות ותוכניות הפעולה שלך.
- קישור ראיות בודדות לבקרות וסעיפים, כך שתוכלו להרכיב במהירות חבילות ממוקדות עבור קהלים שונים.
- אספקת כלי דיווח וסקירה פשוטים המאפשרים לך להראות לבעלי עניין פנימיים וחיצוניים כאחד כיצד גישת השמירה והמחיקה שלך מתפתחת עם הזמן.
עד שתוכלו להבחין בבירור בקומה הזו, העברת התהליכים שלכם לפלטפורמת ISMS ייעודית מפסיקה להיות מותרות והופכת לצעד מעשי הבא לשמירה על יישור הכל ככל שאתם גדלים.
הזמן הדגמה עם ISMS.online עוד היום
ISMS.online עוזרת לכם להפוך את שמירת ומחיקת הנתונים מאוסף הרגלים שביר למערכת אחת ניתנת לביקורת התומכת בתקן ISO 27001 ובהסכמי רמת שירות תובעניים עם לקוחות. כאשר אתם מוכנים לעבור מעבר לגיליונות אלקטרוניים וספרי ריצה אד-הוק, הדגמה קצרה יכולה להראות לכם כיצד הפרקטיקות הנוכחיות שלכם מתממשות למודל מחזור חיים שקל יותר להגן עליו בפני מבקרים ולקוחות.
בתוך הפלטפורמה תוכלו לתעד את מדיניות מחזור חיי המידע שלכם, להגדיר את לוח הזמנים הראשי לשמירה ולמפות אותו לבקרות של נספח א', התחייבויות משפטיות והתחייבויות הלקוח. תוכלו להקצות בעלות, ללכוד אישורים לחריגים ולקשר כל החלטה לסיכונים ולבקרות שהיא משפיעה עליהם. משימות וזרימות עבודה מאפשרות לכם לתאם פעולות הקשורות לשמירה ומחיקה בין צוותי שירות, תפעול ואבטחה, עם שבילי ביקורת ברורים במקום שרשראות דוא"ל.
כאשר לקוחות או נותני אישורים שואלים כיצד אתם מטפלים בשמירה ומחיקה, תוכלו לייצר ראיות ממוקדות מאותה מערכת בה אתם משתמשים להפעלת מערכות ה-ISMS שלכם, במקום לחפש צילומי מסך וקרשות ישנות. מכיוון ש-ISMS.online מיועד לניהול שוטף ולא לפרויקטים חד פעמיים של הסמכה, הוא תומך באופן טבעי בסקירות ובשיפורים שתקנים ורגולטורים מצפים להם כיום לאורך מחזור חיי הנתונים.
אם אתם מזהים את ה-MSP שלכם בתמונה של שמירה אד-הוק, גיבויים של "שמור הכל" ותשובות עצבניות בביקורות, עכשיו זה רגע הגיוני לפעול. כשאתם מוכנים לחזק את מחזור חיי הנתונים שלכם, בחרו ב-ISMS.online כפלטפורמת ה-ISMS שלכם והזמינו הדגמה קצרה כדי שתוכלו לראות כמה מהר תוכלו למפות את המציאות הנוכחית שלכם, לעצב מסגרת שמירה ומחיקה שמתאימה לבסיס הלקוחות שלכם ולהתחיל להפעיל אותה בביטחון.
שאלות נפוצות
כיצד צריך ספק שירותי ניהול נתונים (MSP) לבנות את שמירת ומחיקת הנתונים כך שיתאים לתקן ISO 27001 ולהסכמי רמת שירות מגוונים של לקוחות?
אתה מקבל את השליטה הרבה ביותר ואת העבודה החוזרת הפחותה אם אתה בונה מסגרת שימור אחת תואמת ISO בתוך מערכת ה-ISMS שלכם, ולאחר מכן לאפשר ללקוח SLA לבחור מתוך קבוצה קטנה של אפשרויות סטנדרטיות שמתחברות אליו.
התחל ממודל שימור פנימי יחיד
עיצוב א לוח זמנים ראשי לשמירה שבבעלות הארגון שלך ומכסה את כל השירותים המנוהלים:
- הגדירו קבוצה קטנה של מחלקות נתונים שקיימים ברוב החוזים: כרטיסי שירות, יומני ניטור ואבטחה, נתוני תצורה, תיעוד, גיבויים, דוא"ל וצ'אט, קבצים משותפים, חוזים ורישומים פיננסיים.
- בחרו מספר מוגבל של רצועות זמן (לדוגמה 30 / 90 / 365 ימים, שלוש שנים, שבע שנים, "סוף חוזה ועוד X") במקום להמציא תקופות חדשות לכל עסקה.
- עבור כל כיתה, יש לתעד:
- השמיים בסיס (חוק או תקנה, חוזה, קוד מגזר, חלון סכסוכים או החלטה פנימית בנושא סיכונים).
- השמיים פעולה בסוף החיים (למחוק, לאנונימיזציה, לארכיון או העברה להחזקה משפטית).
כאשר לוח זמנים זה נמצא בתוך מערכת ניהול אבטחת המידע (ISMS) שלכם, הוא מתיישב באופן טבעי עם המיקוד של ISO 27001 על הקשר, התחייבויות, סיכון ובקרה, וקל הרבה יותר להגן עליו בפני מבקרים ולקוחות.
הציעו דפוסי SLA במקום הבטחות חד פעמיות
חשפו את לוח הזמנים הזה ללקוחות כ- תפריט קצר של דפוסי SLA, במקום ניסוח מותאם אישית בכל חוזה. לדוגמה:
- "יומני אבטחה - סטנדרטי" → 12 חודשים מקוונים, 12 חודשים בארכיון.
- "יומני אבטחה – מורחבים" → שלוש שנים בסך הכל עבור מגזרים מוסדרים.
- "גיבויים - תפעוליים" → 30 יום מתגלגלים ועוד חודשיים למשך 12 חודשים.
- "גיבויים - תאימות" → שמירה של נתונים פיננסיים למשך שבע שנים
הסכמי רמת השירות והסכמי עיבוד הנתונים שלך, אם כן התייחסו לדפוסים אלה בשמם, עם תהליך חריג שבו חוק או תקנה ספציפיים דורשים משהו שונה. מהנדסים, צוותי מכירות וצוותים משפטיים מדברים על אותם דפוסים במקום ליצור מחדש כללים בשרשורי דוא"ל.
אם אתם מנהלים את הקטלוג והאישורים בפלטפורמה כמו ISMS.online, תוכלו להציג את לוח הזמנים בזמן אמת, מיפויים והחלטות במהלך ביקורות ומכרזים. זה לעתים קרובות הופך את השאלה "כמה זמן אתם שומרים את הנתונים שלנו?" משאלה עצבנית לראיה לכך שמערכת ה-ISMS שלכם מובנית ובשלה.
הבהירו את האחריות והפשרות
השתמש בחוזים, לוחות זמנים לאבטחה והודעות פרטיות כדי לתקן בעיה פשוטה מודל האחריות המשותפת:
- מי בוחר את התבנית עבור כל שירות ומחלקת נתונים.
- מי יכול לבקש מחיקה, ייצוא או החזקה משפטית וכיצד בקשות אלו מאומתות.
- מי מפעיל אילו בקרות בכל פלטפורמה (אתה, הלקוח או ספק צד שלישי).
- איך אתם מתמודדים עם מצבים שבהם חובות משפטיות דורשות שמירה ממושכת יותר מאשר העדפת לקוח.
בהירות זו עוזרת לצוותי החשבון שלכם להימנע מהבטחות יתר תחת לחץ ומעניקה לכם קו ראייה ברור לסעיפים של ISO 27001 בנוגע להקשר (4), מנהיגות (5) ותכנון (6). כאשר הכל מתועד במערכת ה-ISMS שלכם, תוכלו להפנות את המבקרים והלקוחות לאותה מסגרת עקבית במקום לשחזר החלטות מהזיכרון.
אילו סעיפים ובקרות בתקן ISO 27001:2022 ונספח A החשובים ביותר לשמירה ומחיקת נתוני MSP?
עבור MSP, שמירה ומחיקה נמצאות היכן הקשר, סיכון, פעילות וראיות לעמוד בדרישות. קבוצה צפופה של סעיפי ISO 27001 ובקרות נספח A מספקת לכם את תדריך התכנון למחזור חיי המידע שלכם.
עגן את הגישה שלך בסעיפים המרכזיים
מודל השמירה והמחיקה שלך צריך להתבסס בבירור על הסעיפים הבאים:
- סעיף 4 – הקשר הארגון: זיהית איזה חוקים, רגולטורים, חוזים ונורמות מגזריות לקבוע כמה זמן אתם שומרים נתונים ספציפיים, וכיצד זה משתנה בין תחומי שיפוט.
- סעיף 5 – מנהיגות: ההנהלה אישרה את מודל שמירה יחיד, במקום להשאיר את ההחלטות לעסקאות מכירה בודדות.
- סעיף 6 – תכנון: שמירה ומחיקה מופיעות ב הערכת סיכונים ותוכנית טיפול בסיכונים, כולל מתחים בין חובות סטטוטוריות, ציפיות הלקוח ועלויות תפעול.
- סעיף 8 – הפעלה: נהלים להקצאה, רישום, גיבוי, תמיכה ויציאה מתייחסים כולם לאותו לוח זמנים ראשי, כך שהצוות אינו מבצע שיחות אד-הוק.
- סעיף 9 – הערכת ביצועים: אתה בודק האם לוח הזמנים והבקרות עדיין מתאימים, והאם הם מבוצעים.
- סעיף 10 – שיפור: אירועים, תלונות או ממצאי ביקורת בנוגע לשמירת יתר או מחיקה כושלת מובילים לשינויים מדידים בבקרות שלכם.
אם לוח הזמנים, הנהלים ורישום הסיכונים שלכם מתייחסים במפורש לסעיפים אלה בתוך מערכת ה-ISMS שלכם, מבקרים יוכלו לראות ששמירה ומחיקה הן חלק מהמערכת, לא מותאמות בקצוות.
השתמשו בנספח א' כרשימת תיוג מעשית
חופן של בקרות נספח א' 2022 לשאת את רוב המשקל עבור MSPs:
- A.5.32 – הגנה על רשומות: אילו רשומות עליך לשמור, למשך כמה זמן, וכיצד הן מוגנות וניתנות לאחזור.
- A.8.10 – מחיקת מידע: להבטיח מחיקת מידע או אנונימיזציה בלתי הפיכה כאשר אינך זקוק לו עוד.
- A.8.13 – גיבוי מידע: גיבויים פועלים לפי כללי שמירה ושחזור מתועדים במקום "לשמור הכל לנצח".
- A.7.14 – סילוק או שימוש חוזר בטוחים בציוד: חיטוי והשמדה של דיסקים, קלטות ומכשירים שהכילו נתוני לקוחות.
- A.8.15 – רישום: ו A.8.16 – ניטור: כמה זמן נשמרים בולי עץ, כיצד הם מסובבים ומתי הם מוסרים.
דרך פשוטה ליישם זאת באופן אופרטיבי היא הוסף הערות ללוח הזמנים והנהלים של השמירה שלך באמצעות מזהי הבקרה האלה, ולאחר מכן שמור ראיות ברורות: לוח הזמנים עצמו, ייצוא תצורות מפתח, אישורי השמדה והערות סקירה. אחסון זה בפלטפורמת ISMS כמו ISMS.online פירושו שאותו מיפוי משמש לביקורות פנימיות, הסמכת ISO והערכות לקוחות תובעניות מבלי שתצטרך לבנות אותו מחדש בכל פעם.
כיצד יכול ספק שירותי ניהול נתונים (MSP) לתכנן לוח זמנים ריאלי לשמירת נתונים שעובד על פני לקוחות ותחומי שיפוט רבים?
לוחות זמנים שמחזיקים מעמד בקנה מידה של MSP מתחילים מ מה שאתה כבר מפעיל, לאחר מכן הוסיפו שכבות של חוק, חוזים וסיכונים עד שיהיה לכם מבנה קומפקטי שהצוותים שלכם יוכלו לנהל מדי יום.
תחילה תכננו את תמונת הנתונים האמיתית שלכם
התחל ברישום מה אתה מטפל בפועל עבור לקוח טיפוסי:
- השמיים מערכות אתה מנהל: דלפק שירות, כלי ניטור וניהול מרחוק, ניטור אבטחה וביצועים, ויקי לתיעוד, כספות סיסמאות, פורטלים בענן, חבילות דוא"ל ושיתוף פעולה, מאגרי קבצים, פלטפורמות גיבוי ו-DR, וכל שירותי צד שלישי שאתה מנהל.
- השמיים תשומות שמניעים שימור לקוחות: חוזי רמת שירות של לקוחות, דרישות מגזר (לדוגמה, פיננסים, בריאות, מגזר ציבורי), חובות פרטיות כגון GDPR או CCPA, ותקופות התיישנות או מחלוקות רגילות במדינות בהן אתם משרתים.
- לוגי מחלקות נתונים שחוזרים על עצמם בין לקוחות: יומני אבטחה, טלמטריה תפעולית, כרטיסי אירועים, רשומות תצורה, ספרי ריצה ותיעוד, מסמכים פיננסיים, גיבויים גולמיים, דוא"ל, צ'אט וקבצים לא מובנים.
זה נותן לך בסיס קונקרטי. אתה לא מתכנן בתיאוריה; אתה מחליט מה קורה לקבוצות נתונים מסוימות שאתה רואה כל יום.
דחיסת מורכבות לספרייה קטנה של רצועות זמן
לאחר מכן, הגדירו א קבוצה מוגבלת של רצועות זמן שתוכלו להסביר ללקוחות, לרגולטורים ולמהנדסים:
- רצועות קצרות (לדוגמה 7 / 30 / 90 ימים) עבור טלמטריה רועשת ונתוני אבחון חולפים.
- טווחי זמן בינוניים (לדוגמה, שנה או שלוש) המותאמים להתחייבויות שירות, תנאי חוזה וחלונות זמן אופייניים לסכסוכים.
- טווחי זמן ארוכים (לדוגמה שבע שנים) עבור רישומי מס או נתונים עם שמירה מפורשת על פי חוק.
- טווחי חלוקה יחסיים כגון "סוף חוזה ועוד 6/12/24 חודשים" עבור תוכן ותצורה ספציפיים לשוכר.
עבור כל מחלקת נתונים:
- לקבוע את שמירה מינימלית כאשר חוק או תקנה קובעים סף.
- בחר תקופה סטנדרטית תציע ברוב החוזים.
- לכידת א הצדקה בשפה פשוטה תוך התייחסות לתקנות ספציפיות, קודי מגזר, חוזים או החלטות פנימיות בנוגע לסיכונים.
- תגדיר את מצב קצהלמחוק, להפוך לאנונימי, לאחסן בארכיון או להחזיק תחת החזקה חוקית.
בדרך כלל ניתן לבטא זאת בטבלה אחת: "מחלקת נתונים ← טווח שמירה ← בסיס ← פעולה בסוף החיים". כאשר טבלה זו נמצאת במערכת ה-ISMS שלכם ומחוברת למדיניות, נהלים ותבניות SLA, הצוותים שלכם מפסיקים לנהל משא ומתן מאפס ויש לכם קומה ניתנת להגנה ומותאמת ל-ISO, בין אם הלקוח נמצא במנצ'סטר, דבלין או סידני.
פלטפורמת ISMS כמו ISMS.online מסייעת כאן בכך שהיא מספקת לכם מקום אחד לנהל את הטבלה, האישורים והראיות, ולעשות שימוש חוזר באותו דפוס בתקני ISO 27001, ISO 27701, SOC 2, NIS 2 ומסגרות אחרות.
כיצד יכולים ספקי שירותי ניהול נתונים (MSP) להוכיח מחיקת נתונים איתנה, כולל גיבויים ויומני רישום, בביקורות ISO ובסקירות לקוחות?
רואי חשבון ולקוחות רוצים לראות שאתם יודעים איך נראה "טוב" ושיש שובל חוזר שמראה שזה אכן קורה. אתם עושים זאת על ידי הפיכת העיצוב שלכם לגלוי וגיבויו בחפצים יומיומיים.
הפוך את עיצוב המחיקה שלך לקל למעקב
הגדירו את הציפיות שלכם בשפה שאנשי מקצוע לא יכולים להבין:
- כתוב נהלים למחיקה וסילוק נתונים המתייחסים ללוח הזמנים של השמירה שלך ולבקרות של נספח א' כגון A.8.10 (מחיקה) ו-A.7.14 (סילוק מדיה).
- ספרי ריצה של סוף שירות: תיאור מה קורה לכרטיסים, תצורה, גישה, תיעוד, יומנים וגיבויים בעת העברת לקוח מהחברה.
- סטנדרטים לטיפול במדיה: כיסוי דיסקים, קלטות ומדיה אחרת, כולל כאשר ספקים חייבים לספק אישורי השמדה.
- נקה כללי גיבוי ושמירת יומנים שמציגים כמה זמן נתונים נשארים באינטרנט, כמה זמן בארכיון ומתי מערכות פגות תוקפן או מחיקות אותו.
כאשר מסמכים אלה נמצאים יחד בתוך מערכות ה-ISMS שלכם, תוכלו להוביל את הבודקים ממדיניות ברמה גבוהה להליכים שלב אחר שלב ולבסוף להגדרות מערכת ספציפיות, מבלי לחפור בתיקיות מפוזרות.
גיבוי התכנון עם ראיות מבצעיות חיות
אסוף סט קטן של חפצים המדגימים את הפקדים בפעולה:
- כרטיסי ITSM או רשומות זרימת עבודה: שמציגים אירועי יציאה ומחיקה, עם אישורים, חותמות זמן וצוותים אחראים.
- דוחות ויומנים: מפלטפורמות גיבוי, SIEM, מערכות אחסון ודיירי ענן המאשרים כי משימות תפוגה, מדיניות שמירה ומשימות מחיקה בוצעו.
- תעודות השמדה: מקושרים למספרים סידוריים או מזהי נכסים ספציפיים, המראים כיצד מדיה פיזית נוקה או הושמדה.
- ייצוא תצורה או צילומי מסך: של הגדרות שמירה ותוקף בפלטפורמות מרכזיות כגון משימות גיבוי, כלי ניהול יומנים, כללי שמירת דוא"ל וחבילות שיתוף פעולה.
- פלטים מ בדיקות תקופתיות, כגון שחזור מהגיבוי הישן ביותר שאתה טוען שיש לך או אימות שנתונים מעבר לחלון השמירה אינם זמינים באמת.
במקרים בהם אתם מסתמכים על גיבויים בלתי ניתנים לשינוי או ארכיוני יומנים ארוכי טווח, תעדו את הרציונל, כגון חקירות הונאה או הנחיות מגזריות, ותעדו אמצעי פיצוי כמו הצפנה חזקה, גישה צרה ותהליכי החזקה משפטית ייעודיים.
מנהלי שירותים רבים אורזים את אלה לתוך חבילת ראיות סטנדרטית מתוחזק בפלטפורמת ISMS כמו ISMS.online, כך שאותו חומר מאורגן משמש לביקורות ISO, שאלוני בדיקת נאותות של לקוחות וסקירות חידוש. זה מקטין את זמן ההכנה ומראה שאתם מתייחסים למחיקה כתהליך מבוקר, ולא כמעין קשיים חד פעמיים.
כיצד על ספקי שירותי ניהול שירות (MSP) להתמודד עם התנגשויות בין הסכמי רמת שירות של הלקוחות, חובות שמירה חוקיות והמודל מבוסס הסיכונים של ISO 27001?
מתחים בין מה הלקוח רוצה, מה החוק דורש ומה מציע אבטחה טובה יעלה על דגלו במוקדם או במאוחר. הדרך הבטוחה ביותר היא ליישם היררכיה פשוטה ומתועדת ולתעד את הנמקתכם במערכת ה-ISMS.
החל היררכיית עדיפויות ברורה
הסכימו באופן פנימי, ולאחר מכן הצהירו בבירור שההחלטות שלכם פועלות לפי הסדר הבא:
- חוק ורגולציה – כולל הנחיות רגולטוריות וכללי ענף.
- חוזים והסכמי רמת שירות – כולל הסכמי עיבוד נתונים ולוחות זמנים לאבטחה.
- החלטות מתועדות בנוגע לטיפול בסיכונים – איזון בין אבטחה, פרטיות וצרכים עסקיים
כאשר לקוח מבקש שמירה קצרה מאוד או מחיקה מיידית שסותרת את כללי המס, ציפיות הרישום או חוקי הרגולציה, ניתן:
- הסבר שאתה לא יכול להתקשר בחוזה מחוץ לחוק, כך שחובות סטטוטוריות גוברות על העדפות חוזיות.
- הציעו את דפוס תואם קרוב ביותר מתפריט השמירה הסטנדרטי שלך, כגון שמירה מקוונת קצרה יותר עם ארכיון מוצפן ארוך יותר.
- תעדו את הדיון, את החלטתכם וכל דבר אחר אמצעי פיצוי כגון בקרות גישה מחמירות יותר, הצפנה, היקף נתונים מופחת או ניטור נוסף.
טיפול עקבי זה מונע משיחות מכירה ליצור התחייבויות שהצוותים התפעוליים או המשפטיים שלכם לא יוכלו לעמוד בהן בבטחה בהמשך.
התייחסו להחלטות אלו כחלק ממערכת ה-ISMS
תקן ISO 27001 מצפה מכם לנהל את ההתנגשויות הללו בתוך המערכת, ולא כהערות אגב:
- לתפוס אותם כ סיכונים בהערכת הסיכונים שלך, תוך תיאור היכן עליך לשמור נתונים למשך זמן רב יותר ממה שמעדיפים חלק מבעלי העניין, או היכן אתה מקבל במכוון שמירה קצרה יותר מסיבות מסחריות.
- מפו את הסיכונים והטיפולים הרלוונטיים בקרות נספח א' בהצהרת הישימות שלך, כך שההנמקה שלך תהיה גלויה בביקורות.
- לְהַגדִיר טריגרים לבדיקה כגון תקנות חדשות, כניסה למגזרים חדשים או שינויים טכנולוגיים מרכזיים, כך שתוכלו להראות שעמדתכם נבחנת מחדש ולא מתקבעת ללא הגבלת זמן.
- הכשירו מנהלי מכירות, מנהלי משפט ומנהלי תיקי לקוחות על היררכיה זו כדי שיוכלו להסביר אותה במונחים פשוטים ולהימנע ממתן הבטחות שפוגעות במערכת ה-ISMS שלכם.
אם תיעדו את הסיכונים, ההחלטות והמסמכים התומכים בפלטפורמת ISMS כמו ISMS.online, תוכלו לענות על שאלות של רגולטורים, שאלות ביקורת או אתגרי לקוחות עם עמדה מוכחת היטב במקום לחפור בשרשראות דוא"ל היסטוריות.
אילו תהליכים ובקרות עוזרים לספקי שירותי ניהול נתונים (MSPs) לאוטומטיים ולנהל ראיות למחיקת נתונים בסוף חוזה?
סוף חוזה הוא המקום שבו נוטים להסתתר עותקים נשכחים: דיירים לבדיקה, גיבויים ישנים, חשבונות יתומים או תיעוד בחנויות אישיות. מדריך סטנדרטי ליציאה מהארון, אוטומציה הגיונית ורישומים מוצקים שומרות על כך תחת שליטה ומקלות על הדגמה לצדדים שלישיים.
הפעלת מדריך יציאה יחיד לכל הלקוחות
תיצור אחד ריצת ספרים מחוץ ללוח שכל לקוח עוקב אחריו, ואז כוון אותו לפי שירות:
- התחילו עם רשימה אב של מערכות ומאגרי מידע שאתם עשויים לנהל: שירות דלפק, ניהול מערכות (RMM), כלי ניטור, פלטפורמות תיעוד, כספות סיסמאות, מערכות גיבוי ו-DR, דיירי ענן, כלי דוא"ל ושיתוף פעולה, כוננים משותפים, ניהול מכשירים ושירותי צד שלישי.
- עבור כל קטגוריה, יש לפרט את השלבים: ביטול או העברה של גישה, ייצוא רשומות מוסכמות, החלת מדיניות השמירה הנכונה, תזמון מחיקה או אנונימיזציה, ובדיקת החזקות משפטיות או מחלוקות פתוחות.
- הקצה בעלות ברורה כך שלכל שלב יש צוות פנימי או ספק מוגדר.
בנה את ה-runbook הזה לתוך שלך כלי ITSM או ISMS כזרימת עבודה או רשימת בדיקה מובנית, כך שיציאה מהעבודה הופכת לרצף צפוי במקום עבודה מאולתרת שתלויה במי זוכר איזו מערכת.
אוטומציה של פעולות חוזרות ונשנות וסגירה עם רישום נקי
השתמש ביכולות הפלטפורמה ובסקריפטים כדי להפחית מאמץ ידני ושגיאות:
- עניבה השבתת חשבון ופקיעת נתונים לתאריכי סיום חוזים במקומות בהם הכלים תומכים בכך.
- החלת מרכזית תוויות ומדיניות שמירה לאחסון דוא"ל, צ'אט וקבצים כך שהנתונים מתיישנים לאורך לוח הזמנים שלך ללא התערבות אישית.
- כתיבת פעולות בכמות גדולה באמצעות ממשקי API עבור משימות כגון משימות גיבוי שפג תוקפן, ניקוי דיירים או הסרת תצורה ישנה, היכן שזה יעיל ובטוח.
השלימו כל יציאה מהארון עם מדריך תמציתי רישום סיכום, לעתים קרובות כרטיס, אשר לוכד:
- מה נמחק או הומר לאנונימי, באילו מערכות ובאילו תאריכים.
- מה נשמר, למשך כמה זמן, ותחת איזה בסיס משפטי או חוזי.
- קישורים או קבצים מצורפים לדוחות, יומנים, צילומי מסך ותעודות השמדה.
- כל חריגים או החזקות, עם הפניות צולבות ללוח הזמנים של השמירה ולרישום הסיכונים שלך.
שמירה על רצף התהליכים, זרימות העבודה והרשומות יחד בפלטפורמת ISMS כמו ISMS.online נותנת לכם תשובה ברורה כאשר לקוח לשעבר שואל "מה קרה לנתונים שלנו?", והיא נותנת למבקרים דפוס חוזר התואם את הציפיות של ISO 27001 לגבי תפעול, הערכת ביצועים ושיפור. זה גם מבדיל אתכם בשקט מ-MSPs שעדיין מסתמכים על גיליונות אלקטרוניים אד-הוק וידע שבטי כאשר לקוחות עוזבים.








