מדוע שרשראות אספקה של MSP הן כעת משטח ההתקפה הגדול ביותר שלך
ספקי שירותים מנוהלים מודרניים מתמודדים עם סיכון הולך וגדל משרשראות אספקה של טכנולוגיית מידע ותקשורת (ICT), לא רק ממרכזי הנתונים שלהם. כלים, פלטפורמות ושותפים במעלה הזרם יכולים להפוך לנקודות כשל בודדות שכאשר הן נפגעות או אינן זמינות, משפיעות על לקוחות ושירותים רבים בו זמנית. נספח A.5.21 קיים כדי לעזור לכם להבין את התלות הללו, להסכים על ציפיות אבטחה ברורות עם ספקים ולקוחות, ולטפל בסיכון שרשרת האספקה כחלק מכוון ממערכת ה-ISMS שלכם ולא כמחשבה שלאחר מעשה.
עבור ספקי שירותים מנוהלים רבים, שרשרת האספקה של כלים, פלטפורמות ושותפים שאתם תלויים בהם הפכה לאחד החלקים המסוכנים ביותר בסביבה שלכם, לצד מרכז הנתונים שלכם. רכיבים משותפים אלה מהווים בסיס להכנסות שלכם, לחוזים שלכם ולהבטחות הרגולטוריות שלכם. כאשר אחד מהם נכשל או נפגע, ההשפעה יכולה להתגלגל על פני לקוחות רבים תוך שעות, ולכן נספח A.5.21 כה חשוב להפיכת רשת התלות הזו למשהו שאתם מעצבים ומנהלים במודע.
ספקי ניהול מרחוק (MSP) מודרניים יורשים סיכון מאופיין של ריבוי משתמשים בפלטפורמות ניהול מרחוק, שירותי ענן, ספקי זהויות וכלי נישה הנמצאים בינך לבין הלקוחות שלך. פריצה אחת במעלה הזרם יכולה להעניק לתוקף גישה מועדפת לנתח גדול מבסיס הלקוחות שלך. באופן דומה, הפסקה בפלטפורמת ליבה יכולה להוריד מספר לקוחות מהאינטרנט בו זמנית, ללא קשר למידת ההצלחה של ניהול התשתית שלך.
שרשראות אספקה חזקות מתחילות בידיעה על מי אתם באמת תלויים.
המציאות החדשה של סיכון שרשרת האספקה של MSP
המציאות החדשה עבור ספקי שירותי ניהול (MSP) היא שתוקפים והפסקות תקשורת עוברים כעת דרך פלטפורמות ICT משותפות מהר יותר מאשר דרך רשתות של לקוחות בודדים. ככל שאתם משלבים כלי ניהול מרחוק, שירותי ענן, פלטפורמות זהות ומוצרי אבטחה בהצעות שלכם, כל רכיב משותף הופך לנקודת כשל פוטנציאלית. נספח A.5.21 נועד לעזור לכם לזהות מציאות זו ולבנות סביבה בקרות פרופורציונליות.
ספקי שירותי ניהול שירותים מודרניים יורשים את רוב הסיכון בשרשרת האספקה שלהם מפלטפורמות הענן, כלי ה-SaaS וקבלני המשנה שהם משלבים בשירותיהם. ככל שמרכיבים הצעות חדשות, טבעי להמשיך להוסיף פלטפורמות ייעודיות, כלי ניטור, ספקי גיבוי ושירותי אבטחה בנוסף לקבוצת יכולות ליבה.
דו"ח מצב אבטחת המידע לשנת 2025 מראה כי רוב הארגונים חוו לפחות אירוע אבטחה אחד בשנה האחרונה שמקורו בצד שלישי או ספק.
עם הזמן, צמיחה זו יוצרת שרשראות תלות צפופות ורב-שכבתיות: כלי ניטור מרחוק על גבי ענן ציבורי, פלטפורמות זהות המקושרות ללקוחות פרטיים, ספקי גיבוי המשכפלים נתונים בין אזורים וכלי אבטחה מיוחדים המשולבים באמצעות ממשקי API. תוקפים אינם צריכים למקד כל לקוח בנפרד. פגיעה בשירות אחד במעלה הזרם יכולה להעניק גישה מועדפת לסביבות מנוהלות רבות, או לאפשר לתוכנות כופר להתפשט במהירות בין לקוחות שחולקים את אותם כלים. ניתוחים של אירועי שרשרת אספקה של תוכנה מתארים בדיוק את הדפוס הזה, שבו פגיעה בספק או רכיב בשימוש נרחב יכולה להשפיע על מספר רב של ארגונים במורד הזרם בו זמנית (ניתוח תקיפה בשרשרת אספקה של תוכנה).
הפסקות פעילות מתנהגות באותו אופן. כשל בספק זהויות מרכזי או במחסנית ניהול מרחוק יכול להוציא לקוחות מרובים מהאינטרנט, לגרום לעונשים על חוזים ולמשוך תשומת לב רגולטורית גם אם התשתית שלך אינה מושפעת. הנחיות התעשייה בנוגע להערכת וניהול סיכוני אבטחת סייבר בשרשרת האספקה מדגישות לעתים קרובות כיצד שיבוש או פגיעה בשירותי ענן או זהות משותפים יכולים לגרום להפסקות פעילות בו זמנית ולהשפעה עסקית על לקוחות רבים, כמו גם השלכות חוזיות ורגולטוריות עבור ספקים המסתמכים עליהם (סקירת סיכוני אבטחת סייבר בשרשרת האספקה). נספח A.5.21 מכוון ישירות לרדיוס הפיצוץ הטכני והחוזי המשולב, ולא רק לפגיעויות מבודדות.
מדדי אבטחה בספקי ניהול אספקה (MSP) רבים לא תפסו את הקצב של השינוי הזה. צוותים עדיין עוקבים אחר אירועים היקפיים, קצב תיקונים והתראות נקודות קצה, אך יש להם מעט מאוד נראות לגבי פגיעויות תורשתיות או אירועים המונעים על ידי הספקים. ללא תמונה ברורה של תלות במעלה הזרם ופרופילי הסיכון שלהן, אתם למעשה פועלים בעיוורון במקומות שבהם כשלים נוטים ביותר לפגוע, ולכן אתם זקוקים לתצוגות שרשרת אספקה בתוך מערכת ה-ISMS שלכם ולא רק למדדי רשת.
היכן שהראות באמת מתפרקת
הנראות בדרך כלל מתפרקת בשרשרת האספקה ה"צללית": כלים, שירותים ושותפים שחמקו מחוץ לרכש הרשמי. אלה נראים לעתים קרובות כמו החלטות חד פעמיות באותו הזמן, אך הם הופכים לחלק ממפת התלות הקבועה שלכם.
רוב ספקי שירותי ה-MSP יכולים לפרט את הספקים העיקריים שלהם מהזיכרון, אך מעטים יכולים להראות תמונה מלאה של מי ועל מה הם באמת סומכים. שירותי Freemium שאומצו על ידי מהנדסים, כלי פיילוט "זמניים" שמעולם לא הסתיימו ופלטפורמות שהלקוח הסכים לתמוך בהן - כל אלה מוסיפים לשכבה נסתרת זו.
הבעיה היא שתוקפים ורגולטורים לא אכפת להם אם תלות אושרה רשמית או אומצה בשקט. אם פגיעה עוברת דרכה לסביבות המנוהלות שלכם, הלקוחות עדיין יצפו לתשובות מכם. נספח A.5.21 מתייחס לקשרים אלה כאל "בתוך ההיקף". הוא מצפה מכם להכניס אותם למפת שרשרת האספקה שלכם, לסווג אותם ולהחליט מה המשמעות של "מאובטח מספיק" עבור כל אחד מהם בהתבסס על הסיכון.
צעד ראשון ומעשי הוא למפות את רדיוס הפיצוץ של הרכיבים המשותפים הקריטיים ביותר שלכם. עבור כל כלי או פלטפורמה עיקרי, העריכו כמה לקוחות, אילו סוגי נתונים ואילו שירותים תלויים בהם. ההבנה שמערכת ניהול מרחוק אחת מהווה בסיס לחלק משמעותי מההכנסות שלכם היא לעתים קרובות הרגע שבו סיכון שרשרת האספקה מפסיק להרגיש מופשט ומתחיל לדרוש בקרות מובנות.
למה הלוח שלך צריך להיות מודאג כמו המהנדסים שלך
הדירקטוריון וההנהגה הבכירה שלכם צריכים לראות באבטחת שרשרת האספקה של טכנולוגיות מידע ותקשורת (ICT) סוגיה של ממשל, ולא רק דאגה טכנית עבור מהנדסים. לקוחות, חברות ביטוח ורגולטורים שואלים יותר ויותר כיצד מזהים, מעריכים ומבוקרים סיכוני IT של צד שלישי ומיקור חוץ, והם מצפים לתשובות קוהרנטיות החורגות מעבר לצוות האבטחה. גופי תעשייה המנטרים איומי שרשרת אספקה של תוכנה ו-ICT מציינים כי בעלי עניין חיצוניים מקדישים תשומת לב רבה יותר לאופן שבו ארגונים מנהלים סיכונים של צד שלישי, ולא רק אילו טכנולוגיות הם פורסים (איום גובר של התקפות שרשרת אספקה של תוכנה).
על פי סקר ISMS.online לשנת 2025, לקוחות מצפים יותר ויותר מספקים להתאים את עצמם למסגרות פורמליות כמו ISO 27001, ISO 27701, GDPR או SOC 2 במקום להסתמך על טענות כלליות של נהלים מומלצים.
כאשר בעלי עניין מבינים שהשירותים המנוהלים שלכם נמצאים מעל ספקים אחרים שעשויים להיות מטרות בעצמם, הם מחפשים ראיות לכך שאתם מבינים ומנהלים את הקשרים הללו. אבטחת שרשרת האספקה הופכת לנושא ברמת הדירקטוריון מכיוון שכשלים כאן עלולים לגרום להפרעה לעסקים, בדיקה רגולטורית ופגיעה בתדמית בו זמנית.
מנהיגות בדרך כלל זקוקה לאישור ש:
- כלים ושותפים קריטיים במעלה הזרם מזוהים, מוערכים סיכונים ומחויבים חוזית לציפיות אבטחה ברורות.
- הארגון מבין אילו לקוחות ושירותים יושפעו מכשלים מסוימים במעלה הזרם.
- ישנם ספרי עבודה שנבדקו עבור תקריות ספקים המכסים תגובה טכנית, תקשורת והתחייבויות חוזיות.
ללא הבטחה זו, שאלות קשות נוחתות בחדר הישיבות בזמן הגרוע ביותר האפשרי: במהלך הפסקת חשמל, פרצה או ביקורת. התייחסות לנספח A.5.21 כעמוד השדרה הפורמלי של אבטחת שרשרת האספקה של טכנולוגיית המידע והתקשורת (ICT) מעניקה למנהלים בסיס סטנדרטי שעליו הם יכולים לסמוך, במקום הסברים מאולתרים תחת לחץ.
הזמן הדגמהנספח A.5.21 וההגדרה החדשה של אבטחת שרשרת אספקה של טכנולוגיות מידע ותקשורת (ICT)
נספח A.5.21 מבקש מכם להסכים, לתעד ולתחזק ציפיות מתאימות לאבטחת מידע עם ספקי ה-ICT והלקוחות עליהם אתם תלויים. מבחינה מעשית, עליכם לדעת על מי אתם סומכים, מה אתם מצפים מהם, מה הם מצפים מכם וכיצד ציפיות אלו נבדקות לאורך זמן. עבור ספק שירותי ניהול רשתות (MSP), משמעות הדבר היא להכיר בכך שאתם נמצאים בתוך שרשראות אספקה של ICT של לקוחות רבים, כמו גם לנהל את שלכם. זה משקף את האופן שבו ISO/IEC 27001:2022 מתאר את בקרה A.5.21 בקטלוג בקרות אבטחת מידע עבור שרשראות אספקה של ICT (סקירה כללית של ISO/IEC 27001:2022).
כמעט כל הארגונים בסקר ISMS.online לשנת 2025 ציינו השגה או שמירה על אישורי אבטחה כגון ISO 27001 או SOC 2 כעדיפות עליונה.
אם נלקח ברצינות, נספח A.5.21 מעביר את אבטחת שרשרת האספקה של טכנולוגיות מידע ותקשורת מתחושת בטן לפרקטיקה מתועדת מבוססת סיכונים. הוא מתבסס על המשפחה הרחבה יותר של בקרות נספח A עבור יחסי ספקים, חוזים וניטור, ומיישם אותן באופן ספציפי על מוצרים ושירותי טכנולוגיות מידע ותקשורת. הבנת האופן שבו הוא משתלב עם A.5.19, A.5.20 ו-A.5.22 מעניקה לכם מסגרת לעשות זאת מבלי להמציא מחדש את כל מערכת ה-ISMS שלכם.
פלטפורמת ISMS משולבת כמו ISMS.online יכולה לעזור לכם לשמור את התמונה הזו במקום אחד על ידי קישור ספקים, לקוחות, שירותים, סיכונים ובקרות נספח A, כך שיהיה קל לסקור ולעדכן אותן ככל שהעסק שלכם מתפתח.
מידע זה הינו כללי ואינו מהווה ייעוץ משפטי; על ארגונים לפנות להכוונה מקצועית מתאימה לקבלת החלטות רגולטוריות.
מה שנספח A.5.21 מצפה בפועל
נספח A.5.21 מצפה מכם להתייחס לאבטחת שרשרת האספקה של טכנולוגיות מידע ותקשורת כאחריות מתמשכת ומשותפת ולא כסעיף חוזה חד פעמי. הוא מחזק את הרעיון שציפיות צריכות להיות מבוססות סיכונים, מתועדות ומתוחזקות לאורך זמן במקום להניח או לקבוע פעם אחת ולשכוח. עבור ספקי שירותי ניהול מערכות (MSPs), משמעות הדבר היא תכנון ציפיות במעלה ובמורד הזרם ובדיקה שהן ממשיכות להיות הגיוניות ככל שהשירותים והסיכונים משתנים.
נספח A.5.21 יושב לצד שלושה בקרות קשורות זה לזה:
- A.5.19, המכסה מדיניות ליחסי ספקים.
- A.5.20, המתמקד בהבטחת טיפול באבטחת מידע במסגרת הסכמי הספקים.
- A.5.22, העוסק בניטור, סקירה וניהול שינויים של שירותי ספקים.
יחד, ניתן לקרוא את הבקרות הללו בשפה יומיומית כך: זהו את שרשרת האספקה של ה-ICT שלכם, הגדירו את דרישות אבטחת המידע שאתם מצפים ממנה, הטמיעו דרישות אלו באופן שבו אתם בוחרים, חותמים איתם חוזים ומפקחים על ספקים, ושמרו על הפיקוח ככל שהשירותים משתנים. נספח A.5.21 הוא המקום שבו זה מתייחס ספציפית לשירותים ומוצרים של ICT, הן במעלה הזרם והן במורד הזרם. כותרות וקבוצות בקרות אלו עוקבות אחר המבנה שפורסם ב-ISO/IEC 27001:2022, המפרט את הבקרות של נספח A ואת תחומי המיקוד שלהן לאבטחת שרשרת האספקה של ספקים ו-ICT (סקירה כללית של ISO/IEC 27001:2022).
עבור ספק שירותי ניהול טכנולוגיות מידע (MSP), ישנה תפנית נוספת. אתם גם לקוח וגם ספק. אתם מסתמכים על שירותי ICT במעלה הזרם כדי לספק את ההיצע שלכם, ואתם ספק קריטי בשרשראות האספקה של ה-ICT של הלקוחות שלכם. נספח A.5.21 מצפה מכם לנהל את שני הצדדים באופן עקבי באופן המשקף סיכונים ומוטמע בתהליכים יומיומיים, ולא מטופל במסמכים בודדים.
הפיכת טקסט סטנדרטי למשהו שכולם יכולים להבין
סביר יותר שהצוותים שלכם יתחברו אם תתרגמו את שפת התקן לקבוצה קטנה של התחייבויות ברורות ומעשיות. התחייבויות אלו צריכות לתאר את מה שאתם עושים בפועל, במונחים שמהנדסים, מנהלי לקוחות וצוותים משפטיים מכירים, במקום לצטט את התקן.
ניתן לנסח מחדש את נספח A.5.21 כהתחייבויות כגון:
- "אנו בודקים ומסווגים את ספקי ה-IT והפלטפורמות שאנו מסתמכים עליהן ומשתמשים בהם כאשר הם עומדים בקריטריונים של אבטחה מוסכמת."
- "אנו מגדירים ומתעדים מי אחראי על אילו אמצעי אבטחה בכל שירות מנוהל שאנו מוכרים."
- "אנו עוקבים אחר ספקים ושירותים מרכזיים לאורך זמן ומגיבים במהירות ובשקיפות כאשר משהו משתנה או משתבש."
ברגע שיש לכם את התרגומים האלה, יהיה לכם הרבה יותר קל לראות היכן כבר קיימים חלקים מנספח A.5.21, כגון בדיקות קליטת ספקים, תבניות חוזים או סקירות תקופתיות. זה גם מדגיש היכן נהלים הם אד-הוק, לא מתועדים או תלויים בצוות בודד. מיפוי זה נותן לכם נקודת התחלה לעבודת התכנון המפורטת יותר במעלה ובמורד הזרם שתבוא לאחר מכן.
נספח A.5.21 מצפה שהדרישות שלכם יהיו פרופורציונליות לסיכון ולא יועתקו באופן עיוור ממערכת יחסים אחת לאחרת. ספקים ולקוחות בעלי השפעה גבוהה זקוקים בדרך כלל לבדיקת שקידה מעמיקה יותר ולהתחייבויות חזקות יותר מאשר ספקים ולקוחות בעלי השפעה נמוכה, ואותו עיקרון הופך את החוזים שלכם בהמשך הדרך לנגישים יותר להגנה בפני רגולטורים ומבקרים.
הבקרה אינה מרמזת שעליכם להטיל ציפיות אבטחה מפורטות זהות על כל ספק או לקוח. היא מצפה מכם להצדיק את הציפיות שלכם לאור הסיכון. פלטפורמת ענן קריטית המארחת נתוני לקוחות מצדיקה בדיקת נאותות מעמיקה יותר, סעיפי חוזה חזקים יותר וניטור אינטנסיבי יותר מאשר כלי בעל סיכון נמוך ולא קריטי.
אותו היגיון חל גם בהמשך. שירות מנוהל המסופק לבית חולים או למוסד פיננסי נושא בחובות ובקרה שונות מאשר שירות המסופק לעסק קטן ולא מפוקח. היישום שלכם של נספח A.5.21 הוא אמין כאשר הבדלים אלה ניכרים בהערכות הסיכונים שלכם ובאופן שבו אתם בונים הסכמים, ולא כאשר כל מערכת יחסים משתמשת בניסוח העתקה והדבקה ללא קשר להשפעה.
התאמת נספח A.5.21 למסגרות שכבר נמצאים בשימוש, כגון SOC 2, הנחיות אבטחת סייבר מוכרות או המלצות לאומיות לשרשרת אספקה, יכולה לעזור. הנחיות שרשרת אספקה של ספקי אבטחה ואנשי מקצוע המבוססות על שיטות עבודה מומלצות מעודדות אתכם למפות יעדי בקרה משותפים בתקנים כגון ISO 27001, SOC 2 ומסגרות אבטחת סייבר לאומיות, כך שצוותים לא יקיימו קבוצות דרישות מרובות וסותרות (סקירה כללית של נוהלי אבטחת שרשרת אספקה). כאן, "התאמת שכבות" פירושה פשוט קיבוץ ספקים ולקוחות למספר רמות מבוססות השפעה, במקום להתייחס לכל קשר כייחודי.
ISO 27001 בקלות
יתרון של 81% מהיום הראשון
עשינו את העבודה הקשה בשבילך, ונתנו לך התחלה של 81% מרגע הכניסה. כל שעליכם לעשות הוא להשלים את החסר.
בקרות במעלה הזרם לעומת בקרות במורד הזרם בהקשר של MSP
במערכת ניהול אספקה (MSP), המונח "upstream" (מעלה הזרם) מכסה את הספקים, הפלטפורמות וקבלני המשנה עליהם אתם מסתמכים, בעוד ש"downstream" מכסה את הלקוחות והשוכרים המסתמכים עליכם. נספח A.5.21 קל יותר ליישום כאשר מתייחסים למערכות יחסים אלה כנפרדות אך מקושרות, עם אחריות וציפיות ברורות לכל כיוון. מבנה זה הופך חששות מופשטים של שרשרת האספקה לחוזים, ספרי משחק ולוחות מחוונים שאנשים יכולים לפעול לפיהם.
מודל ברור של תהליכים במעלה/מורד הזרם הופך טקסט סטנדרטי לחוזים, ספרי עבודה ולוחות מחוונים מעשיים. ניתן להגדיר כיצד לבחור ולנטר ספקים, כיצד לחלוק את האחריות עם הלקוחות וכיצד להגיב כאשר מתרחשים אירועים בכל כיוון. ברגע שהמבנה הזה קיים על הנייר, יישוםו בכלים ובהתנהגות הופך להיות הרבה יותר פשוט.
הגדרת קשרים במעלה הזרם, במורד הזרם ובהיברידיים
המשימה הראשונה שלכם היא לתת שם ולסווג את מערכות היחסים החיצוניות שאתם תלויים בהן במקום להתייחס לכולם כאל "ספקים" או "לקוחות" גנריים. סיווג זה מעצב אילו חלקים מנספח A.5.21 רלוונטיים ביותר והיכן למקד את מאמצי התכנון שלכם. זה גם יוצר שפה משותפת בתוך הארגון שלכם כשאתם דנים בסיכון שרשרת האספקה.
התחילו ברישום גורמים חיצוניים וסיווגם לפי שני היבטים: האם הם מספקים לכם, או שאתם מספקים להם, ועד כמה הם קריטיים לשירותים שלכם? ספק ICT במעלה הזרם עשוי להיות ספק תשתית ענן, כלי ניטור מרחוק, פלטפורמת גיבוי או שותף אבטחה מומחה. גורמים במורד הזרם הם לקוחות השירות המנוהל שלכם, כולל אלה שבהם אתם פועלים כמעבדי נתונים במסגרת חוק הגנת המידע.
חלק מהיחסים הם היברידיים. מנהל שירות ניהולי עמית (MSP) בהסדר ניהול משותף מספק לך יכולות מסוימות וגם מסתמך על השירותים שלך בתמורה. לקוח שמארח דייר ענן משלו אך מבקש ממך לנהל אותו מטשטש את הגבול בין פלטפורמת הלקוח לסביבת המעלה. מערכות יחסים היברידיות אלה דורשות זהירות מיוחדת, מכיוון שקל שאחריות חשובה תוטל על שני הצדדים או על אף אחד מהם.
לאחר שתיעדו את התפקידים הללו, תוכלו להתחיל להגדיר אילו קטגוריות של בקרות חלות על אילו תפקידים. עבור קשרים במעלה הזרם, בדיקת נאותות, אינטגרציה טכנית מאובטחת, דיווח על אירועים ובקרות של מעבדי משנה הופכות למרכזיות. עבור קשרים במורד הזרם, אחריות משותפת, ציפיות אבטחה בסיסיות וחובות הלקוח בולטות יותר. הסדרים היברידיים דורשים שילוב וגבולות ברורים מאוד כדי למנוע פערים.
שימוש ברמות מבוססות סיכון כדי להביא מבנה
שכבות מבוססות סיכון הופכות רשימה ארוכה של ספקים ולקוחות למשהו שניתן לעבוד איתו. על ידי קיבוץ קשרים למספר קבוצות מבוססות השפעה, ניתן להגדיר מערכי בקרה סטנדרטיים לכל שכבה במקום לתכנן כל קשר מאפס.
לדוגמה, ניתן ליצור שלוש שכבות עבור ספקים במעלה הזרם:
- שכבה 1: פלטפורמות קריטיות עם גישה מועדפת או אירוח נתוני לקוחות.
- רמה 2: שירותי תמיכה חשובים עם גישה ישירה מוגבלת למערכות הלקוח.
- דרגה 3: כלים בעלי סיכון נמוך ללא גישה לנתונים רגישים או לסביבות ייצור.
במורד הזרם, ייתכן שתאמצו שכבות כגון "מוסדר", "זמינות גבוהה" ו"סטנדרטי", בהתבסס על רגישות הנתונים וההשפעה העסקית של הפסקות חשמל.
כל שילוב של שכבות מעלה ומטה מניע ציפיות שונות. פלטפורמת מעלה מדרגה 1 התומכת בלקוח שירותי בריאות מוסדר דורשת הבטחה עמוקה יותר ובקרות מחמירות יותר מכלי מדרגה 2 התומך בלקוח סטנדרטי. תיעוד שילובים אלה בדפוסים פשוטים - לדוגמה, "MSP-היפר-מחלק-לקוח מוסדר" לעומת "MSP-מפיץ-MSP-ארגון" - מאפשר לך לעצב מערכי בקרה סטנדרטיים במקום להתחיל מאפס עבור כל קשר חדש.
דרך תמציתית להמחיש זאת היא באמצעות מטריצה קטנה המראה כיצד תחומי האחריות משתנים לפי סוג הקשר.
| סוג הקשר | אחריות במעלה הזרם (דוגמאות) | אחריות במורד הזרם (דוגמאות) |
|---|---|---|
| MSP – פלטפורמת ענן – לקוח מוסדר | אישורים, הודעות על אירוע, פילוח, יומני גישה | אישורים, חובות הגנת מידע, תקשורת אבטחת לקוחות |
| MSP – כלי אבטחה SaaS – לקוחות מעורבים | אינטגרציה מאובטחת, עיצוב תפקידים, ניטור, סקירת ספקים | מודעות הלקוח להיקף הכלי, הסכמה במידת הצורך |
| MSP – עמית MSP (מנוהל במשותף) – לקוח | הגדרת גבולות, טיפול משותף באירועים, גישה משותפת | הלקוח מבין את חלוקת התפקידים ודרכי ההסלמה |
כפי שמוצג בטבלה, תחומי האחריות משתנים באופן משמעותי בין, נניח, תרחיש של היפר-סקיילר לבין הסדר MSP מנוהל משותף. בפועל, ניתן להתחיל במיפוי מערכות היחסים הנוכחיות שלכם לאחת מהדפוסים הללו, אישור אילו חובות נופלות היכן ולאחר מכן סטנדרטיזציה של סעיפי החוזה וספרי הריצה הפנימיים סביב דפוסים אלה.
תכנון בקרות במעלה הזרם עבור ספקים ומעבדי משנה
בקרות במעלה הזרם מגדירות כיצד אתם בוחרים, מכניסים, מנטרים ויוצאים מהספקים והפלטפורמות עליהם אתם מסתמכים. מחזור חיים פשוט וחוזר על עצמו הופך את אמון הספקים מהנחה לראיות המגובות בהערכות סיכונים, חוזים ותצורה. נספח A.5.21 מצפה שמחזור החיים יהיה פרופורציונלי לסיכון ויחול באופן עקבי על הספקים החשובים ביותר.
תכנון טוב במעלה הזרם ממיר אמון משיפוט לא פורמלי להחלטה מתועדת. משמעות הדבר היא להבין מה כל ספק עושה עבורכם, אילו סיכונים אתם יורשים, אילו בקרות הוא מפעיל ואילו עליכם לספק בעצמכם. מחזור חיים מבוסס סיכונים הופך זאת לניתן לניהול ומעניק למבקרים ביטחון שאתם לא מתייחסים לספקים כקופסה שחורה.
בניית מחזור חיים של ספק שמוכר על ידי מבקרים
מבקרים בדרך כלל מחפשים מחזור חיים ברור ומבוסס סיכונים עבור ספקים קריטיים: כיצד מעריכים ספק לפני השימוש, כיצד מטמיעים בקרות בעת אימוץן, כיצד ממשיכים בפיקוח וכיצד יוצאים מהספק בצורה בטוחה. אם תוכלו להראות את השלבים הללו ואת הראיות שמאחוריהם, קומת הניהול שלכם לפי נספח A.5.21 תיראה אמינה ושלמה. הנחיות בנוגע לסיכוני ספקים ממכונים כמו SANS מתארות מחזורי חיים מבוססי סיכון של ספקים - המכסים בחירה, קליטה, פיקוח מתמשך ויציאה - כסימן היכר של ניהול אבטחה בוגר של צד שלישי (מסמך לבן בנושא סיכוני ספקים של SANS).
דו"ח מצב אבטחת המידע לשנת 2025 מצביע על כך שרוב הארגונים כבר חיזקו את ניהול הסיכונים של צד שלישי ומתכננים להשקיע בו עוד.
מחזור חיים מעשי במעלה הזרם כולל ארבעה שלבים: בדיקת נאותות לפני התקשרות, קליטה, פיקוח עסקי כרגיל ויציאה. עבור כל שלב, יש להגדיר מה צפוי מכל רמת ספק ואילו חפצים צריכים להתקיים כדי להוכיח שפעילויות אלה התרחשו.
שלב 1: ביצוע בדיקת נאותות מבוססת סיכון
בדיקת נאותות מבוססת סיכון עוסקת באיסוף מידע מספיק כדי להבין את מצב האבטחה של הספק וכיצד הוא תואם את הצרכים שלכם. זה כולל בדרך כלל אישורים עצמאיים, הצהרות אבטחה ברמה גבוהה, סיכומי בדיקות, תפקידים בעיבוד נתונים אישיים ומידע על מעבדי משנה. הפלט צריך להיות רישום הערכה מלא המסביר מדוע הספק מקובל ברמה הנבחרת.
שלב 2: הטמעה עם בקרות טכניות וחוזיות קונקרטיות
קליטה הופכת את ההערכה לבקרות קונקרטיות. עבור פלטפורמה קריטית, זה עשוי לכלול הגדרת אימות חזק, הגבלת תפקידי ניהול, הפעלה ושילוב של רישום והסכמה על לוחות זמנים ונקודות קשר לדיווח על אירועים. רשימת תיוג קליטה פשוטה מסייעת להבטיח שלא יוחסו שלבים אלה ושמישהו אחראי בבירור לכל אחד מהם.
שלב 3: שמירה על פיקוח על עסקים כרגיל
פיקוח על "עסקים כרגיל" צריך להיות קליל אך אמיתי. עבור ספקים בעלי השפעה גבוהה, קבעו קצב ביקורת כדי לאשר שההסמכות נשמרים, התחייבויות האבטחה עדיין בתוקף ולא התרחשו שינויים משמעותיים ללא ידיעתכם. עבור רמות נמוכות יותר, ביקורות יכולות להיות מופעלות על ידי אירועים כגון שינויים בשירות, זרימת נתונים חדשה או תקריות. תיעוד של ביקורות אלו, גם אם קצרות, מראות שהפיקוח פעיל ולא משוער.
שלב 4: יציאה בטוחה ועדכון מפת שרשרת האספקה שלך
יציאה לרוב מתעלמים ממנה, אך היא חשובה ביותר. כאשר אתם מפסיקים להשתמש בספק או עוברים לפלטפורמה חדשה, צריך להיות תהליך מוגדר לביטול גישה, החזרה או מחיקה מאובטחת של נתונים ועדכון התיעוד שלכם, כך שמפת שרשרת האספקה שלכם תישאר מדויקת. רשימת תיוג קצרה ליציאה וערך רישום מעודכן מדגימים שסגרתם את הקשר בצורה מבוקרת.
מבקרים אינם מצפים לשלמות, אך הם כן מצפים לראות שמחזור חיים כזה קיים, מבוסס סיכונים ומיושמים בפועל עבור ספקים קריטיים.
אף ספק אינו מושלם, ונספח A.5.21 אינו דורש שלמות. הוא מצפה ממך לקבל החלטות מושכלות ומתועדות לגבי הסיכונים שאתה יורש והבקרות המפצות שאתה מיישם, ותוכל להסביר את ההחלטות הללו למבקרים וללקוחות.
לא כל ספק יעמוד בכל בקרות אידיאליות, ולא כל ספק צריך. מה שחשוב הוא היכולת שלך להסביר מדוע מערכת יחסים מקובלת בהתחשב בסיכון שהיא מציגה. חלוקה לרמות (tiereds) עוזרת, אבל אתה גם צריך הבהרה לגבי מתי אתה מרגיש בנוח לרשת בקרות ממסגרת האבטחה של הספק עצמו ומתי אתה מעדיף אמצעי פיצוי.
לדוגמה, אם ספק ענן גדול מחזיק בהסמכות מוכרות באופן נרחב ופועל לפי תקן אבטחה חזק, בדרך כלל סביר להסתמך עליהן עבור בקרות בסיסיות רבות, בתנאי שאתם מנהלים את התצורה שלכם בצורה מאובטחת. לעומת זאת, עבור פלטפורמה מיוחדת קטנה יותר עם פחות אבטחה פורמלית, ייתכן שתחליטו להגביל את היקפה, לדרוש התחייבויות חוזיות ספציפיות או להוסיף ניטור ובדיקות משלכם.
טיפול באירועים ראוי לתשומת לב מיוחדת. עבור פלטפורמות ליבה, צריכות להיות התחייבויות מפורשות לגבי כמה מהר תקבלו הודעה על בעיית אבטחה, איזה מידע תקבלו וכיצד תוכלו לתאם תגובות כדי להגן על הלקוחות שלכם. ציפיות אלו עדיף לכתוב בחוזים או בהסכמי שירות ולא להשאירן כהבנות בלתי פורמליות.
תיעוד שיקולי דעת אלו במרשם הסיכונים ובהצהרת הישימות שלכם מראה למבקרים כי נספח A.5.21 מיושם באופן מושכל, לא באופן אוטומטי. הצהרת הישימות שלכם היא פשוט רשימה רשמית של בקרות נספח A, שבה אתם מסבירים אילו מהן חלות, כיצד ומדוע.
שחררו את עצמכם מהר של גיליונות אלקטרוניים
הטמע, הרחב והרחיב את תאימותך, ללא כל בלגן. IO מעניק לך את החוסן והביטחון לצמוח בצורה מאובטחת.
תכנון בקרות במורד הזרם עבור לקוחות וחובותיהם
בקרות במורד הזרם מגדירות כיצד אתם חולקים את האחריות עם הלקוחות ומה אתם מצפים מהם כדי לשמור על אבטחת השירותים. עבור ספקי שירותי ניהול שירותים (MSPs), בקרות ברורות במורד הזרם מפחיתות את הסיכון להאשמה בחשיפות הנובעות משירות הלקוח ומראות לרגולטורים שקבעתם ציפיות מתאימות ומתועדות. נספח A.5.21 מחזק את הצורך להפוך את הציפיות הללו למפורשות, ניתנות לאכיפה ומגובות ראיות.
בפועל, בקרה במורד הזרם עוסקת בקביעת גבולות ולוודא שכולם מבינים אותם. אתם מגדירים מה אתם עושים כברירת מחדל, מה הלקוחות חייבים לעשות וכיצד תוכיחו ששני הצדדים עומדים באחריותם. כאשר זה נעשה היטב, שיחות על אירועים, דרישות חדשות או שירותים נוספים מתחילות מהבנה משותפת במקום מחלוקת לגבי מי היה אחראי.
תכנון מודלים של אחריות משותפת ספציפית לשירות
מודל אחריות משותפת שימושי אומר ללקוחות, בשפה פשוטה, אילו חלקי אבטחה אתם הבעלים ואילו הם הבעלים עבור שירות נתון. למשפחות שירותים שונות יש חלוקות שונות, כך שלכל אחת מהן יש מודל פשוט משלה המשקף את האופן שבו השירות מתוכנן במציאות. בהקשר זה, מודל אחריות משותפת הוא פשוט תיאור ברור של האופן שבו מחולקות חובות האבטחה בינך לבין הלקוח.
עבור כל משפחת שירותים, בנו מודל אחריות משותפת שעונה על שלוש שאלות:
- אילו תצורות וניטור אתם מספקים כברירת מחדל?
- מה הלקוח צריך לעשות כדי שזה יהיה יעיל?
- כיצד תוכיח ששני הצדדים עושים את חלקם?
לדוגמה, עבור שירות Microsoft 365 מנוהל, תחומי האחריות שלך עשויים לכלול הגדרת מדיניות גישה מותנית, הפעלת רישום וניטור התראות מפתח. תחומי האחריות של הלקוח עשויים לכלול שמירה על דיוק פרטי המשתמש, אכיפת מדיניות שימוש מקובל ותגובה מהירה להודעות אבטחה. הוכחת המודל יכולה לכלול דוחות תצורה תקופתיים ואישורי לקוח מתועדים.
מודלים אלה צריכים להיות כתובים בשפה נגישה, לשימוש חוזר בחוזים ובהצעות, ונתמכים על ידי ספרי הדרכה פנימיים המראים לצוותים שלכם כיצד לעמוד בצד שלכם בעסקה. כאשר לקוחות מבינים את המודל מלכתחילה, שיחות מאוחרות יותר על אירועי אבטחה או התחייבויות נוספות מתבססות על הבנה משותפת זו ולא על ציפיות אד-הוק.
קביעת התחייבויות הלקוח וטיפול באי עמידה בדרישות
התחייבויות הלקוח מתארות מה הלקוחות צריכים לעשות כדי להפוך את השירותים שלכם ליעילים ולשמור על הסיכון שלהם בגבולות מקובלים. נספח A.5.21 מצפה מכם להגדיר את ההתחייבויות הללו בבירור, לנטר אותן במידת האפשר ולהחליט מראש כיצד תטפלו בפערים.
בקרות במורד הזרם כוללות לעיתים קרובות התחייבויות כגון:
- תחזוקת מערכות הפעלה נתמכות.
- וידוא שהצוות יעבור הכשרה בנושא מודעות לאבטחה.
- הפעלת אימות רב-גורמי במערכות שלהם.
- הודעה מיידית על שינויים רלוונטיים בסביבתם.
התחייבויות אלו צריכות להיות מתאימות לשירות ולפרופיל הסיכון, כתובות בחוזים או בלוחות זמנים של אבטחה, ונתמכות על ידי מנגנונים פשוטים לאיסוף ראיות. זה עשוי לכלול אישורים תקופתיים, בדיקות טכניות בהן יש לכם נראות, או תוצאות מסקירות משותפות.
חשוב באותה מידה להחליט מראש כיצד תטפלו באי-ציות. ניתן לצמצם פערים מסוימים; אחרים עשויים להוביל לחריגים, עמלות נוספות או, במקרים קיצוניים, סירוב לספק שירות.
שלב 1: הגדרת אופן זיהוי אי-ציות
החליטו אילו התחייבויות ניתן לבדוק טכנית ואילו מסתמכות על אישורי לקוחות או פגישות סקירה. רשמו את הבדיקות בתהליכים או בכלים שלכם כך שאי-הציות יהיה גלוי.
שלב 2: החלטה מי יכול להעניק ולאשר חריגים
תעדו אילו תפקידים יכולים לאשר חריגים זמניים, באילו תנאים ולאיזו תקופה. כך תמנעו פשרות מיידיות שהופכות לקבועות מאוחר יותר.
שלב 3: רישום ובדיקה של הסיכון השיורי
ודאו כי חריגים ומקרים של אי-ציות נרשמים במרשם הסיכונים שלכם ונבדקים בפורומים מתאימים של ממשל. זה מראה שאתם מנהלים את הסיכון השיורי, ולא מתעלמים ממנו.
מודלים והתחייבויות ברורים במורד הזרם מושכים לקוחות בוגרים. הם מראים שאתם לוקחים את הסיכון שלהם ברצינות ושאתם מוכנים לקבוע ולקיים גבולות הגיוניים במקום להסכים להבטחות מעורפלות ובלתי ניתנות לאכיפה.
ממשל, תפקידים ומחזור חיים של בקרת שרשרת אספקה
אבטחת שרשרת האספקה מתרחבת רק כאשר מישהו אחראי עליה בבירור ושאר הארגון מבין את חלקו. נספח A.5.21 הופך בר-קיימא כאשר הוא משולב בממשל, עם תפקידים, אחריות ומקצבי סקירה מוגדרים, במקום להישאר כמשימה צדדית בלתי פורמלית עבור האבטחה. ממשל יעיל עוסק פחות ביצירת פגישות חדשות ויותר בשאילת שאלות טובות יותר באלו שכבר קיימות.
אם אבטחת שרשרת האספקה מתייחסים אליה כאל "בעיה של מישהו" ללא בהירות, היא תסיט את עצמה מהמקום. עליכם להחליט מי אחראי על הבקרה, מי מספק תשומות, מי מבצע משימות ספציפיות ובאיזו תדירות נבדקת הביצועים. ממשל טוב עוסק בהחלטות ברורות ובמשוב קבוע, לא ביותר פגישות.
ניהול שרשרת אספקה יעיל הוא שאילת שאלות טובות יותר בפגישות קיימות.
הקצאת בעלות ו-RACI ברחבי העסק
בעל שליטה שמוגדר כבעלים נותן לנספח A.5.21 משמעות ברורה, אך ההצלחה תלויה במאמץ מתואם בתחומי הרכש, התפעול, המשפט וניהול החשבונות. מודל RACI פשוט מבהיר מי עושה מה, מי חותם ומי צריך להישאר מעודכן כאשר הסיכונים של הספק או הלקוח משתנים.
נקודת התחלה מעשית היא למנות בעל בקרה יחיד עבור נספח A.5.21, לרוב ראש אבטחת המידע או CISO וירטואלי. אדם זה אחראי להבטיח שהבקרה מתוכננת ופועלת, אך אינו יכול לבצע אותה לבדו. לתחומי הרכש, המשפט, התפעול וניהול החשבונות יש תפקידים למלא.
מטריצת RACI פשוטה (אחראי, אחראי, מתייעץ, מודע) עוזרת. לדוגמה, עבור קליטת ספק Tier 1 חדש:
- הרכש אחראי על הבטחת קיומם של סעיפי אבטחה מוסכמים בחוזה.
- ראש אבטחת המידע אחראי על אישור הערכת הסיכונים והרמה של הספק.
- ייעוץ משפטי מתקיים בנוגע למונחים מורכבים, חריגים וחובות.
- ניהול התפעול וניהול החשבונות מקבלים מידע על התחייבויות המשפיעות על אופן אספקת השירותים.
כאשר התפלגות זו ברורה, עמיתים מפסיקים לראות את נספח A.5.21 כ"בעיה של איש ה-ISO" ומתחילים להבין את חלקם שלהם בהתמודדות איתה.
בחירת מקצבי ממשל שיתאימו לפעילות
ממשל גופי עובד בצורה הטובה ביותר כאשר שאלות בנוגע לשרשרת האספקה משולבות בפגישות שכבר חשובות, כגון ועדות סיכונים, סקירות הנהלה וסקירות שירות. נספח A.5.21 אינו דורש בירוקרטיה חדשה; הוא דורש ממך לשאול את השאלות הנכונות על ספקים ולקוחות בזמנים הנכונים ולתעד את התשובות.
בקרות נוטות יותר להישאר בתוקף כאשר הן מבוססות על מקצבים שהארגון כבר מכבד. עבור אבטחת שרשרת האספקה, זה עשוי להיות:
- הכללת נושאי סיכון מרכזיים של ספקים ולקוחות כנושאי סדר יום קבועים בוועדות קיימות לסקירת סיכונים או שירות.
- תזמון סקירות תקופתיות של ספקים קריטיים ולקוחות בסיכון גבוה, בהתאם למחזורי חוזים או לשינויים משמעותיים.
- סקירת אירועים וכמעט תאונות הקשורים לשרשרת האספקה בסקירות לאחר אירוע והחזרת לקחים שנלמדו לניהול הספקים והלקוחות.
הימנעו מהקמת ועדות חדשות לחלוטין אלא אם כן אתם זקוקים להן; במקום זאת, שלבו את נספח A.5.21 בפורומים מבוססים של ניהול. לדוגמה, סקירת הניהול שלכם לפי תקן ISO 27001 יכולה לכסות במפורש ביצועים מול מדדי שרשרת האספקה, כגון מספר הספקים הקריטיים ללא הערכות שוטפות, תדירות האירועים הקשורים לספקים או זמן הדיווח על אירועים.
הממשל צריך להשתרע גם על קשרים פחות גלויים, כגון קבלני משנה המשמשים לכיסוי מחוץ לשעות הפעילות או ספקי White Label המספקים שירותים תחת המותג שלך. תמונת שרשרת האספקה אינה שלמה בלעדיהם, ואירועים הקשורים לצדדים אלה עלולים להיות מזיקים באותה מידה. הבטחת כי הם נמצאים במסגרת הערכת סיכונים, בקרות חוזיות ופיקוח היא חלק מיישום אמין של נספח A.5.21.
ניהול כל דרישות התאימות, הכל במקום אחד
ISMS.online תומך ביותר מ-100 תקנים ותקנות, ומעניק לך פלטפורמה אחת לכל צרכי התאימות שלך.
שילוב A.5.19–A.5.22 עם תהליכי סיכון, ספקים ושינוי
נספחים A.5.19-A.5.22 פועלים בצורה הטובה ביותר כאשר הם שזורים בתהליכים שכבר משתמשים בהם לניהול סיכונים, ספקים, שינויים ותקריות. במקום לעמוד בנפרד כ"משימות ISO" מבודדות, יש לשקף אותן במרשם הסיכונים, בזרימת העבודה של הרכש, בניהול השינויים ובסקירות לאחר אירוע, כך שחשיבה בשרשרת האספקה תהפוך לחלק מהעבודה היומיומית. שילוב זה הוא שהופך הצהרות מדיניות להתנהגות עקבית.
שני שלישים מהארגונים בסקר מצב אבטחת המידע לשנת 2025 אמרו כי המהירות והיקף השינויים הרגולטוריים מקשים על קיום תאימות.
תכנון מדיניות ומודלים הוא הכרחי אך לא מספיק. בקרות שרשרת אספקה פועלות רק כאשר הן משולבות בטפסים, בכרטיסים ובזרימות העבודה שבהן אנשים כבר משתמשים כדי לבקש שינויים, להטמיע כלים חדשים, להעריך סיכונים ולהגיב לאירועים. נספחים A.5.19-A.5.22 יעילים ביותר כאשר הם באים לידי ביטוי באופן שבו אתם מתעדים סיכונים, מקבלים החלטות ספקים, מאשרים שינויים ולומדים מאירועים.
הטמעת חשיבה בשרשרת האספקה בתהליכי עבודה יומיומיים
הצעד הראשון הוא להפוך את סיכוני שרשרת האספקה של טכנולוגיית המידע והתקשורת לגלויים לצד סיכונים אחרים. משמעות הדבר היא יצירת ערכי סיכון מפורשים עבור שירותים וספקים קריטיים ותיאום כיצד אתם מתכננים לטפל בסיכונים אלה. לאחר שהדבר ייושם, תוכלו להוסיף נקודות ביקורת קטנות וחובה לזרימות עבודה שהצוות שלכם כבר עוקב אחריהן, כך שהחלטות לגבי ספקים ושינויים ישקפו אוטומטית את הציפיות של נספח א'.
התחילו בכך שתוודאו שמרשם הסיכונים המרכזי שלכם לוכד במפורש את סיכוני שרשרת האספקה של טכנולוגיות מידע ותקשורת (ICT). עבור כל שירות עיקרי וספק קריטי, צריכים להיות ערכי סיכון המשקפים את ההשפעה הפוטנציאלית של כשל או פגיעה שלהם, יחד עם הטיפולים שנבחרו. זה מציב את סיכוני שרשרת האספקה לצד נקודות תורפה אחרות ועוזר להנהלה להבין פשרות.
לאחר מכן, שלבו נקודות ביקורת בשרשרת האספקה בתהליכי עבודה קיימים:
- תהליכי רכש צריכים לכלול הנחיות לבדיקה האם ספק מוצע נופל תחת רמת סיכון מסוימת, האם בוצעה בדיקת נאותות והאם תבניות חוזים כוללות את סעיפי האבטחה הנדרשים.
- בקשות שינוי המכניסות או מחליפות כלים או מעבדי משנה משמעותיים צריכות להפעיל באופן אוטומטי סקירה של השפעות במעלה ובמורד התהליכים, ולא רק של תאימות טכנית.
- תהליכי תכנון שירות או קליטה עבור לקוחות חדשים צריכים לכלול צעדים ליישום מודל האחריות המשותפת המתאים ולאשר כי התחייבויות בהמשך מתועדות ומתקבלות.
לעיתים קרובות ניתן להוסיף הנחיות אלו לטפסים ולתבניות כרטיסים עם חיכוך מינימלי, בתנאי שהן חובה עבור התרחישים החשובים והתגובות מתועדות באופן מרכזי כך שהן מוזנות בחזרה לרישומי ה-ISMS שלכם.
מדידת ביצועים ולמידה מאירועים
אי אפשר לשפר את מה שלא רואים. נספח A.5.21 הופך בעל ערך רב יותר כאשר עוקבים אחר מידת התפקוד של בקרות שרשרת האספקה ומפיקים לקחים מהתקריות בחזרה לרמות, לתבניות ולספרי ההליכים שלכם. המטרה אינה להוריד כל מספר לאפס, אלא להבין היכן באמת נמצאות החשיפות הגדולות ביותר שלכם בשרשרת האספקה ולהדגים שאתם מנהלים אותן.
ברגע שהבקרות פועלות, אתם זקוקים למשוב כדי לשפר אותן. אמצעים שימושיים עשויים לכלול:
- שיעור הספקים הקריטיים עם הערכות סיכונים מעודכנות והתחייבויות אבטחה מתועדות.
- מספר וחומרת האירועים שבהם שורש הבעיה כלל קשר במעלה או במורד הזרם.
- הזמן שלוקח לקבל הודעה על תקריות רלוונטיות של הספקים ולתקשר עם הלקוחות שנפגעו.
- שיעור אי-עמידתם של הלקוחות בהתחייבויות מרכזיות בהמשך הפרויקט ותדירות הניתנים לחריגים.
כאשר מתרחשות תקריות, ניתוח גורמי שורש צריך להבחין באופן מכוון בין כשלים במעלה הזרם, בעיות פנימיות וחולשות במורד הזרם. הבחנה זו מלמדת היכן עליך להחמיר ציפיות, לשפר את הנהלים שלך או להתאים את התחייבויות הלקוח. הזנת תובנות אלו בחזרה לחלוקת ספקים, תבניות חוזים וספרי נהלים הופכת את יישום נספח A.5.21 שלך לאיטרטיבי באמת, לא סטטי.
פלטפורמת ISMS ייעודית יכולה לעזור לכם לקשר ספקים, שירותים, לקוחות, סיכונים ובקרות במקום אחד, כך שניתן יהיה לעקוב אחר שינוי או אירוע בודד על פני מערכות היחסים שהוא משפיע עליהן. גם אם אינכם מוכנים לאמץ פלטפורמה כזו באופן מיידי, תכנון התהליכים שלכם כך שניתן יהיה לאסוף את הנתונים הדרושים באופן מרכזי מאוחר יותר הוא צעד פרגמטי לקראת ISMS משולב יותר.
הזמן הדגמה עם ISMS.online עוד היום
ISMS.online יכול לעזור לכם להעביר את נספח A.5.21 מרשימות ספקים מפוזרות וסעיפי חוזה לתמונה אחת וחיה של שרשרת האספקה, הבקרות והראיות של טכנולוגיית המידע והתקשורת שלכם. על ידי החלפת גיליונות אלקטרוניים, שבילי דוא"ל ומסמכים מבודדים בסביבה מחוברת אחת, תוכלו לראות קשרים במעלה ובמורד הזרם בצורה ברורה יותר, לעקוב אחר תחומי אחריות ולענות על שאלות קשות מלקוחות ומבקרים בביטחון רב יותר.
אם אתם חושדים שמענה על שאלון מורכב של לקוחות או ביקורת ISO 27001:2022 עדיין יעורר קשיים, זהו סימן לבחון גישה מובנית יותר. ראיית קשריכם במעלה ובמורד הארגון ממופים בבירור, כאשר האחריות והסיכונים נראים לעין במבט חטוף, מעניקה לכם עמדה בטוחה יותר עבור לקוחות, מבקרים והנהלה.
כיצד לבצע פיילוט של A.5.21 בחלק אחד של שרשרת האספקה שלך
פיילוט ממוקד הוא הדרך הפשוטה ביותר לראות כיצד נראה נספח A.5.21 כאשר הוא מוטמע במלואו במערכת ניהול מידע (ISMS). במקום לנסות למדל את כל העולם בבת אחת, אתם מתמקדים בפרוסה קטנה ומייצגת של שרשרת האספקה שלכם ובודקים האם המבנה והכלים באמת מפחיתים את המאמץ וחוסר הוודאות.
פיילוט מעשי עשוי להתחיל עם פלטפורמה קריטית אחת במעלה הזרם ולקוח אחד בסיכון גבוה. ניתן לייבא את הקשרים הללו ל-ISMS.online, למפות אותם לנספחים A.5.19–A.5.22 וללכוד את האובייקטים המרכזיים: הערכת סיכונים של ספקים, מודלים של אחריות משותפת, התחייבויות לקוחות וראיות ניטור. במסגרת היקף מוגבל זה, ניתן לראות האם הפלטפורמה מפחיתה באופן משמעותי את המאמץ, מבהירה את הבעלות ומשפרת את המוכנות שלכם לשאלות מצד מבקרים ולקוחות.
על ידי שמירה על פרויקט פיילוט קטן, אתם שומרים על שליטה בהיקף ונמנעים מהצפה של צוותים שכבר עמוסים. במקביל, אתם נותנים לעצמכם דוגמאות קונקרטיות - ערך רישום סיכונים מאוכלס, מחזור חיים מתועד של ספקים, מטריצת אחריות משותפת - שתוכלו להראות לעמיתים ולהנהלה כאשר הם דנים כיצד להרחיב את הגישה.
מה להביא לשיחה מקוונת ב-ISMS
תקבלו את הערך הרב ביותר משיחה על ISMS.online אם תגיעו עם תמונה פשוטה של שרשרת האספקה הנוכחית שלכם והאתגרים שלה. מעט הכנה תקל עליכם לראות כיצד הפלטפורמה יכולה לתמוך במצב הספציפי שלכם והאם היא מתאימה לארגון שלכם.
קלטים שימושיים כוללים בדרך כלל:
- רשימה של ספקי ה-ICT החיוניים ביותר שלכם במעלה הזרם והשירותים שהם תומכים בהם.
- רשימה מצומצמת של לקוחות בעלי השפעה גבוהה, במיוחד אלו במגזרים מוסדרים.
- כל מסמך קיים המתאר תחומי אחריות משותפים, התחייבויות לקוחות או ציפיות ספקים.
- דוגמאות לאירועים אחרונים הקשורים לספקים או ללקוחות שהיו קשים לניהול.
בעזרת המידע הזה, צוות ISMS.online יוכל לבחון כיצד ייראו מערכות היחסים האמיתיות שלכם בתוך הפלטפורמה וכיצד נספחים A.5.19-A.5.22 יבואו לידי ביטוי בפועל. המטרה אינה להציע פתרון כללי, אלא להראות, באמצעות דוגמאות משלכם, כיצד ISMS מקושר יכול לפשט את נספח A.5.21 ולשפר את שרשרת האספקה שלכם.
אם אתם מזהים את הארגון שלכם בתרחישים אלה ורוצים לבחון גישה משולבת יותר, ISMS.online מוכנה לבחון יחד אתכם פיילוט ממוקד, תוך שימוש בספקים ובלקוחות האמיתיים שלכם כדי לראות האם ISMS מחובר הוא הצעד הנכון הבא עבור ה-MSP שלכם.
הזמן הדגמהשאלות נפוצות
כיצד משנה תקן ISO 27001:2022 נספח A.5.21 את האופן שבו ספק שירותי ניהול טכנולוגיות (MSP) צריך לחשוב על שרשרת האספקה שלו בתחום ה-ICT?
נספח A.5.21 מצפה מכם לנהל את שרשרת האספקה של טכנולוגיות המידע והתקשורת (ICT) כמערכת אחת מבוקרת, מפלטפורמת הענן ועד לתוצאות הלקוח, ולא כקבוצה של ספקים, כלים וחוזים מנותקים. עבור ספק שירותי ניהול ספקים (MSP), פירוש הדבר שאתם זקוקים לתצוגה חיה ובר-הגנה של האופן שבו ספקים במעלה הזרם, השירותים שלכם ולקוחות במורד הזרם קשורים זה לזה וכיצד אתם מנהלים סיכונים לאורך שרשרת זו.
מה באמת המשמעות של "שרשרת אספקה של ICT מקצה לקצה" עבור ספק שירותי ניהול טכנולוגיות מידע ותקשורת (MSP)?
מקצה לקצה פירושו שתוכלו להתחיל עם שירות יחיד ולעקוב אחר:
- איזה מוצרים ושירותי טכנולוגיית מידע ותקשורת אתה סומך עליו כדי לספק את זה.
- איך שלך פלטפורמות ותהליכים משלהם לשבת באמצע.
- איזה לקוחות או פלחי לקוחות מושפעים אם משהו נשבר.
במקום "אנו משתמשים בספק X ואנו משרתים את לקוח Y", נספח A.5.21 מניח שאתה מבין ומנהל את כל המסלול: ענן/פלטפורמות ← כלי ותהליכי MSP ← סביבות לקוחאם פלטפורמת ליבה נכשלת או נפגעת, עליכם כבר לדעת אילו שירותים ודיירים חשופים ומה תעשו בנידון.
בפועל, זה אומר שאתה יכול:
- הצבע על רישום ספקים שממפה ספקי ICT לשירותים ולקטגוריות סיכון.
- הסבר, בשפה פשוטה, מי עושה מה (אתה, הספק, הלקוח) עבור כל סוג שירות.
- הראו שתמונה זו נשארת עדכנית כאשר שירותים, ספקים או תקנות משתנים.
אם אתם יכולים להדריך רואה חשבון דרך הקומה הזו באמצעות רישומים יומיומיים במקום "חבילת ביקורת" חד פעמית, אתם מתייחסים לנספח A.5.21 כחלק מניהול העסק שלכם, וזה בדיוק מה שהוא מחפש.
כיצד נספח A.5.21 מתבסס על בקרות ספק אחרות בנספח A.5 עבור ספק שירותים מנוהלים?
נספח A.5.21 לוקח את נושאי הספקים הכלליים מ-A.5.19, A.5.20 ו-A.5.22 ומיישם אותם באופן ספציפי על ערימת ה-ICT העומדת בבסיס השירותים המנוהלים שלכם. מדובר פחות בהמצאת תהליכים חדשים ויותר בחיבור בחירת ספקים, חוזים, ניטור ושינוי לגישה קוהרנטית אחת עבור מוצרים ושירותי ICT.
כיצד משתלבות בקרות הספקים של נספח A.5 בשרשרת האספקה של ספק שירותי טכנולוגיות מידע ותקשורת (ICT) של ספק שירותי ניהול (MSP)?
ניתן לחשוב על ארבעת הפקדים כזרימה אחת:
- A.5.19 – אבטחת מידע ביחסי ספקים: החליטו היכן אבטחה חשובה בנוף הספקים שלכם וכיצד אתם שוקלים אותה בבחירות שלכם.
- A.5.20 – התייחסות לאבטחת מידע במסגרת הסכמי ספקים: הפכו את הציפיות הללו לסעיפים ברורים, תוספות ותיאורי שירות.
- A.5.21 – ניהול אבטחת מידע בשרשרת האספקה של טכנולוגיות מידע ותקשורת (ICT): יישמו את החשיבה הזו על הרשת הספציפית של פלטפורמות, כלים ואינטגרציות של טכנולוגיית מידע ותקשורת הנמצאות תחת השירותים המנוהלים שלכם.
- A.5.22 – ניטור, סקירה וניהול שינויים של שירותי ספקים: יש לבחון את הסיכונים והביצועים של הספקים ולהגיב לאירועים ושינויים.
עבור MSP, זה בדרך כלל מתורגם לשלוש יכולות גלויות:
- A רישום משותף כאשר ספקי טכנולוגיות מידע ותקשורת קשורים לשירותים, דירוגי סיכונים והתחייבויות חוזיות.
- A דפוס עקבי לאופן שבו אתם מכניסים, מנטרים ופרושים מספקי ICT, במקום לקבל החלטות חד פעמיות בדוא"ל.
- A קישור שניתן לעקוב אחריו מפעילויות אלה ועד להבטחות הפונות ללקוחות ולרישום הסיכונים הפנימי שלכם.
שימוש בפלטפורמה כמו ISMS.online מקל על חיבור הנקודות הללו מכיוון שניתן לאחסן ספקים, חוזים, סיכונים ובקרות לפי נספחים A.5.19-A.5.22 במקום אחד. זה מאפשר לך להראות למבקרים וללקוחות שאתה מנהל שרשרת אספקה של טכנולוגיית מידע ותקשורת (ICT), ולא רק ארון תיוק של הסכמים.
כיצד צריך ספק שירותי ניהול טכנולוגיות מידע ותקשורת (MSP) לתכנן מחזור חיים של ספק במעלה הזרם (upstream) העומד בנספח A.5.21 מבלי להעמיס על הצוות?
הדרך היעילה ביותר לעמוד בנספח A.5.21 במעלה הזרם היא להגדיר מחזור חיים יחיד וחוזר על עצמו של ספק, ולאחר מכן להגדיל את עומק הבדיקות לפי סיכון, ולא לפי ניחושים. הצוות שלך צריך ללמוד רק דפוס אחד, ואתה שומר בדיקת נאותות מעמיקה לספקים שיכולים באמת לפגוע בך או בלקוחות שלך.
כיצד נראה מחזור חיים מעשי ובר-חזרה של ספק ICT עבור MSP?
מחזור חיים פשוט בן ארבעה שלבים בדרך כלל מאזן בין מאמץ לביטחון:
- בחר: סווגו את הספק לפי השפעה לפני שאתם מתחייבים. פלטפורמה שמעבדת נתוני לקוחות או נמצאת באמצע ערימת הניהול מרחוק שלכם ראויה לבדיקות מעמיקות יותר מאשר חברת שירות בעלת ערך נמוך.
- על הסיפון: הפכו את הציפיות שלכם לבקרות קונקרטיות. הגדירו גישה, רישום, התראות שינויים, ערוצי תמיכה ותנאי יציאה לפני שאתם מעלים לאוויר.
- הפעל: סקור ביצועים וסיכונים בקצב סביר. עבור פלטפורמות קריטיות, קבע סקירה שנתית לפחות, בנוסף לבדיקות לאחר התראות אבטחה, אירועים או שינויים משמעותיים בשירות.
- יציאה: תכננו כיצד תסירו או תעבירו נתונים, תבטלו גישה, תחליפו תלויות ותעדכנו את התיעוד שלכם בעת עזיבת ספק או ירידת דירוגו.
אינכם זקוקים לכלי עבודה מורכבים כדי להוכיח שאתם פועלים לפי מחזור חיים זה. רישום ספקים מתוחזק, רשימות בדיקת נאותות קצרות, רשימות תיוג פשוטות להטמעה ורישומי סקירה בסיסיים כבר נותנים למבקרים איתות ברור שאתם מתייחסים לספקי ICT כחלק ממערכת ה-ISMS שלכם.
ISMS.online יכול לחזק זאת עוד יותר על ידי אחסון רישום הספקים, ראיות מחזור החיים ובקרות המקושרות של נספחים A.5.19-A.5.22 בסביבה אחת. זה עוזר לך לשמור על התהליך קל עבור הצוות שלך תוך הצגת דפוס ברור ועקבי ללקוחות, למבקרים ולשותפים.
כיצד יכול ספק שירותי ניהול רשתות (MSP) להגדיר אחריות משותפת עם לקוחות במורד הזרם כך שנספח A.5.21 יכוסה מבלי להפוך כל חוזה לרומן משפטי?
בהמשך, נספח A.5.21 מסופק כאשר הלקוחות שלך יכולים לראות, בשפה פשוטה, מה אתה מאבטח כברירת מחדל, מה עליהם לעשות בעצמם וכיצד תעבוד יחד כאשר משהו משתנה או משתבש. אינך זקוק לטקסט משפטי מותאם אישית לכל עסקה, אך אתה זקוק לקבוצה קטנה של דפוסי אחריות משותפת שהצוותים שלך מבינים ומיישמים באופן עקבי.
כיצד נראה מודל אחריות משותפת מעשי עבור שירותי MSP נפוצים?
דפוס מעשי הוא לתקנן מודלים לפי משפחת שירותים ולשמור על מבנה זהה בכל פעם. עבור כל משפחה, הגדירו ארבעה בלוקים:
- היקף השירות: מה שירות מנוהל זה מכסה ומה הוא לא.
- האחריות שלך: לדוגמה, תצורה בסיסית, רישום, גיבוי, ניטור, טיפול בפגיעויות ותיאום אירועים.
- אחריות הלקוח: לדוגמה, שמירה על תמיכה בנקודות קצה, אכיפת אימות רב-גורמי, ניהול מצטרפים/עוזבים ודיווח על שינויים משמעותיים.
- אחריות משותפת: לדוגמה, ביקורות גישה, אישור שינויים בסיכון גבוה או ניהול תקשורת אירועים.
לאחר מכן ניתן לבטא את המודלים הללו בכמה דרכים:
- קצר מטריצות אחריות בהצעות, תחומי עבודה ומסמכי קליטה.
- תוספות אבטחה: שמצורפים לחוזים מבלי לכתוב מחדש את התנאים המלאים.
- ספרי ריצה פנימיים: שבהם הצוותים שלכם משתמשים בעת קליטה, תפעול וטיפול באירועים.
כאשר לקוח זקוק לחריגה, אתם מתעדים את הסטייה הזו במפורש במקום למתוח את המודל בשקט. ברגע שדפוסים וחריגים אלה קיימים ב-ISMS שלכם ומשתקפים במרשם הסיכונים שלכם, תוכלו להראות שסיכון במורד הזרם מטופל באופן מכוון ולא באופן לא פורמלי. זה בדיוק מה שנספח A.5.21 שואף לבדוק.
ISMS.online מספק לכם מקום מרכזי לאחסון ושימוש חוזר במודלים אלה, קישורם לשירותים ולקוחות ספציפיים, ושמירה על יישור ניסוחי חוזים, ספרי הפעולות הפנימיים ורישומי הסיכונים ככל שתיק ההשקעות שלכם גדל.
כיצד יכול ספק שירותי ניהול ספקים (MSP) להפוך רשת מורכבת של ספקים, פלטפורמות ולקוחות למפת סיכונים ברורה של שרשרת אספקה של טכנולוגיות מידע ותקשורת (ICT) שעומדת בדרישות הסקירות של נספח A.5.21?
הדרך הקלה ביותר לבנות מפת סיכונים משמעותית בשרשרת האספקה היא להתחיל מהאופן שבו השירותים שלך פועלים בפועל כיום במקום להתחיל מרשימת ספקים סטטית. כאשר עוקבים אחר זרימות נתונים ונקודות בקרה משמאל לימין, הקשרים החשובים ביותר עבור נספח A.5.21 נוטים לחשוף את עצמם.
אילו צעדים מעשיים יוצרים מפת שרשרת אספקה של טכנולוגיות מידע ותקשורת (ICT) שמבקרים יכולים לעקוב אחריה?
ניתן לבנות את המפה בשלושה שלבים עצמאיים המחזקים זה את זה:
- תצוגת שירות: רשום את השירותים המנוהלים שלך (לדוגמה, Microsoft 365 מנוהל, נקודות קצה מנוהלות, גיבוי מנוהל, ענן מנוהל משותף) וציין באילו פלטפורמות, כלים ואינטגרציות במעלה הזרם כל אחד מהם תלוי.
- תצוגת קשר: עבור כל שירות, רשום:
- השמיים בְּמַעֲלֶה הַזֶרֶם ספקי ופלטפורמות טכנולוגיית מידע ותקשורת (ICT) חיוניים.
- השמיים במורד הזרם לקוחות או קבוצות לקוחות הצורכים שירות זה.
- תצוגת סיכון: עבור כל פלח ספק או לקוח בעל השפעה גבוהה, יש לרשום סיכון נפרד המציין:
- מה באופן סביר עלול להשתבש (לדוגמה, הפסקת חשמל, פרצת נתונים, שינוי רישיון).
- כיצד זה ישפיע על השירותים שלך ועל תוצאות הלקוחות.
- אילו בקרות, תנאי חוזה ונהלים תפעוליים מפחיתים את הסבירות או ההשפעה.
מנהלי שירותים רבים מוצאים תרשים פשוט מועיל, גם אם לעולם לא מציגים אותו חיצונית: ענן/פלטפורמות ← כלי ותהליכי MSP ← סביבות לקוח, עם צבעים או סמלים להצגת הסיכון היחסי. תמונה זו עוזרת לך להחליט היכן להשקיע מאמץ ומספקת למבקרים וללקוחות דרך פשוטה להבין את התלות שלך.
ב-ISMS.online ניתן לשקף מבנה זה על ידי קישור שירותים, ספקים, לקוחות וסיכונים בסביבה אחת. זה מקל מאוד על הדגמת כיצד פלטפורמה חדשה או לקוח חדש מתווספים למפה, כיצד הם מסווגים וכיצד סיכונים ואחריות קשורים מתעדכנים באופן עקבי.
אילו תיעודים יומיומיים משכנעים את מבקרי ISO 27001 ש-MSP באמת מנהל את נספח A.5.21 במקום רק לציין אותו במסמכים?
רואי חשבון בדרך כלל מתעניינים יותר בשאלה האם הרישומים היומיומיים שלכם מספרים סיפור קוהרנטי מאשר עד כמה הכלים שלכם נראים מרשימים. עבור נספח A.5.21, הם רוצים לראות שאתם מבינים מהיכן נובע סיכון שרשרת האספקה של טכנולוגיית המידע והתקשורת, מיישמים טיפול חוזר ויכולים להוכיח טיפול זה מבלי ליצור עסק שני המוקדש לניירת ביקורת.
אילו ארטיפקטים רגילים עומדים בדרך כלל בנספח A.5.21 עבור ספקי שירותי ביקורת (MSPs) מבלי לבנות "תעשיית ביקורת" מקבילה?
ברוב רשתות ה-MSP, סט קומפקטי של רשומות מספיק אם הוא שלם ומתעדכן:
- A רישום ספקים שמפרט ספקי טכנולוגיות מידע ותקשורת, מקשר אותם לשירותים, מציג את סיווג הסיכונים שלהם ומתעד את תאריכי הבדיקה האחרונים.
- קצר הערות בדיקת נאותות עבור ספקים בעלי סיכון גבוה יותר, כגון הפניות להסמכות, תשובות לשאלונים או הערכות סיכונים תמציתיות.
- חוזים או תוספות אבטחה: אשר קובעים ציפיות אבטחה, כללי דיווח על אירועים, טיפול בנתונים ותנאי מעבד משנה.
- ניטור וסקירת רישומים: , כגון פניות לביקורת שירות, פרוטוקולים של צ'ק-אין של ספקים או ביקורות לאחר אירוע המראות כיצד הגבתם.
- מודלים של אחריות משותפת: וסעיפים קשורים בחוזים עם לקוחות, בנוסף לדוגמאות אמיתיות כיצד אתם פועלים כאשר התחייבויות משני הצדדים אינן מתקיימות.
במקום לבנות "חבילות ביקורת" נפרדות, בדרך כלל יעיל יותר לוודא שהמסמכים הרגילים שלכם - רשימות תיוג להטמעה, רישומי שינויים, ספרי ריצה, סקירות אירועים ובעיות - משאירים מאחור באופן אוטומטי את הראיות שהמבקר יבקש.
אם תרכזו את האובייקטים הללו ב-ISMS.online ותקשרו אותם במפורש לבקרות ולסיכונים הרלוונטיים בנספח A, תוכלו לענות במהירות על שאלות ביקורת ושאלוני לקוחות על ידי סינון וייצוא ממקום אחד. עם הזמן, זה מפחית את הלחץ של הביקורת, מקצר את מחזורי המכירות ועוזר לצוות שלכם לקבל הכרה על ניהול שרשרת אספקה של טכנולוגיית מידע ותקשורת (ICT) המנוהלת היטב, במקום להתאמץ כל שנה כדי להרכיב מחדש את אותה קומה מאפס.
כיצד יכול MSP להשתמש ב-ISMS.online כדי להטמיע את נספח A.5.21 בעבודת שרשרת האספקה הרגילה במקום להתייחס אליו כאל פרויקט תאימות חד פעמי?
נספח A.5.21 הופך לניתן לניהול כאשר הוא משולב באופן שבו אתם רוכשים, מספקים ובודקים שירותים, ולא כאשר הוא מטופל כסטנדרט עצמאי שאפשר "לסמן". ISMS.online תומך בשינוי זה על ידי מתן סביבה אחת לחיבור ספקים, שירותים, לקוחות, סיכונים, בקרות וראיות, כך שפעולות יומיומיות ישמרו באופן טבעי על נספח A.5.21 במצב תקין.
איך זה נראה כאשר נספח A.5.21 מיושם בפועל ב-ISMS.online?
דפוס ריאלי עבור חברי פרלמנט רבים נראה כך:
- אתה שומר על רישום ספקים חי ב-ISMS.online, מסווג ספקי ICT לפי השפעה ומקשר כל אחד מהם לשירותים המנוהלים ולבקרות של נספח A.5.19–A.5.22 שהוא תומך בהן.
- אתה לוכד פעילויות בדיקת נאותות, קליטה, ניטור ויציאה כפריטי עבודה או משימות רגילות, כך שהראיות הדרושות לכם עבור נספח A.5.21 מצטברות באופן אוטומטי ככל שהצוות שלכם עובד עם ספקים.
- אתה מאחסן ומשתמש בו שוב מודלים של אחריות משותפת כתוכן מובנה, תוך מיפוי שלהם למשפחות שירותים ולקבוצות לקוחות כך ששפת החוזה, ספרי הניהול ורישומי הסיכון יישארו תואמים.
- אתה מקשר סיכונים הן לספקים במעלה הזרם והן ללקוחות במורד הזרם, כך ששינוי בחלק אחד של השרשרת מתאים באופן מיידי את השקפתך על החשיפה הכוללת של שרשרת האספקה.
דרך להתחיל בסיכון נמוך היא לבחור שירות חשוב אחד, פלטפורמה קריטית אחת במעלה הזרם ולקוח מייצג אחד, לדמות את השרשרת הזו מקצה לקצה ב-ISMS.online ולאחר מכן להריץ שינוי או אירוע אמיתי דרך המערכת. אם הצוותים שלכם והמבקר שלכם ימצאו שקל יותר לראות תלויות, להסביר התחייבויות ולאסוף ראיות מאותה דוגמה אחת, יהיה לכם טיעון פנימי חזק להרחבת אותה גישה על פני יותר משרשרת האספקה של ה-ICT שלכם.
עם הזמן, דרך עבודה זו עוזרת לעסק שלכם להיתפס לא רק כ"שומר על מערכות פועלות", אלא כמנהל שרשרת אספקה של טכנולוגיות מידע ותקשורת (ICT) הניתנת למעקב ומנוהלת היטב, שעומדת בשאלוני לקוחות ובביקורות ISO 27001 עם הרבה פחות הפרעה לעבודה היומיומית שלכם. כשאתם מוכנים להציג את הסיפור הזה ללקוח או למבקר, ISMS.online מספקת לכם את כל מה שאתם צריכים במקום אחד, במקום להשאיר אתכם להרכיב את הכל תחת לחץ.
