מדוע שינויים בספקים פוגעים במשחקים מקוונים

למה שינויים בספקים ממשיכים לשבור משחקים מקוונים (מנהל/ת תפעול חי / מנהל/ת טכנולוגיה ראשי הנדסי – TOFU)

שינויים בספקים לעיתים קרובות משבשים משחקים מקוונים משום ששינויים קטנים במעלה הזרם צצים כבעיות משמעותיות במשחק, אפילו כשהמערכות שלכם נראות תקינות. שחקנים רואים קיפאונות, השהיות ורכישות כושלות, אך לוחות המחוונים עדיין מדווחים על שירות תקין, כך שאתם נושאים את האשמה מבלי לראות את הסיבה האמיתית מוקדם מספיק כדי לפעול.

שינוי שאתה לא יכול לראות הוא שינוי שאתה לא יכול לשלוט בו - והשחקנים עדיין ירשו לך את האחריות.

שינויים שקטים בענן, ב-CDN ובספקים אחרים יכולים לצוץ כבעיות רועשות מאוד עבור השחקנים שלכם. שינוי קל בניתוב, הזזת אזור או עדכון SDK במעלה הזרם יכולים להופיע במשחק כקיפאונות, גומייה, רכישות כושלות או לולאות התחברות. לוחות המחוונים הפנימיים שלכם עדיין יכולים להראות "ירוק" עבור שירותי ליבה, כך שמנקודת מבטו של שחקן הבעיה פשוטה: המשחק שלכם לא עובד.

במחסנית משחקים מודרנית, התאמה בודדת יכולה להיות תלויה במופעי ענן, מסדי נתונים מנוהלים, מטמונים, CDN, אנטי-צ'יט, זהות, קול, ניתוח נתונים, פרסומות ותשלומים. רוב השכבות הללו יכולות להשתנות באופן עצמאי. מגבלת קצב מעט יותר אגרסיבית בקצה, כלל חומת אש שהוחל בצורה שגויה או מדיניות TLS חדשה יכולים להספיק כדי לדחוף את ההשהיה מעבר לטווח המקובל באזור אחד בעוד שהכל נראה בסדר במקום אחר.

מה שכואב הוא לא רק התקרית עצמה, אלא הזמן שלוקח להבין אותה. אם ערוץ התקריות שלכם מתמלא בהודעות של "שום דבר לא השתנה בצד שלנו", אך השחקנים חווים בבירור בעיות, כמעט בוודאות אתם מפספסים אותות לשינוי ספק. קבוצות רבות עדיין תלויות בבדיקות ידניות של דפי סטטוס, מיילים שיווקיים או קבוצות צ'אט כדי לגלות מה באמת קרה, דבר שאיטי וקשה להוכחה בביקורת ISO 27001.

עבור שידורים חיים, ההשפעה מיידית. ירידה במספר האירועים במקביל, עלייה חדה במספר הפניות לתמיכה, ערוצים חברתיים מתמלאים בתלונות וצוותים מופנים מעבודה מתוכננת לפענוח שינוי של מישהו אחר. עבור כותרים תחרותיים או ספורט אלקטרוני, אפילו עליות קטנות ב-Latency או אובדן חבילות מתורגמות ישירות לחוסר הוגנות נתפס, האשמות במשחקים "מזויפים" ולחץ על צוותי הקהילה.

צוותים לעיתים קרובות מתייחסים לאירועים אלה כמבודדים. מהנדסים מתקנים את התסמין - כוונון פסק זמן או הוספת ניסיון חוזר - וממשיכים הלאה, מבלי לשאול שאלה שיטתית: אילו ספקים קריטיים השתנו זמן קצר לפני בעיה זו, האם ידעתם מראש וכיצד תמנעו הפתעה דומה בפעם הבאה? ללא פרספקטיבה זו, אותו דפוס יחזור על עצמו עם פרטים שונים במקצת.

תקן ISO 27001 נספח A לבקרה 5.22 קיים בדיוק עבור סביבה מסוג זה. הוא קובע שאין לסמוך רק על כך שספקים תמיד יתנהגו באותו אופן; עליכם לנטר באופן פעיל, לסקור באופן קבוע ולנהל שינויים בשירותים שלהם, כך שאבטחת המידע ורמות השירות שלכם יישארו כפי שאתם חושבים שהן. עבור משחקים מקוונים, "רמת שירות" אינה דבר מופשט - אלא האם שחקנים יכולים להתחבר, להתחרות ולשלם ללא חיכוכים.

כאן גם חשובה מערכת ניהול אבטחת מידע (ISMS). פלטפורמת ISMS כמו ISMS.online אינה מחליפה את ערימת התצפיות שלכם או את קונסולות הענן שלכם. במקום זאת, היא עוזרת לכם ללכוד, לבנות ולנהל את הסיפור המבולגן שמאחורי האירועים הללו: על אילו ספקים אתם תלויים, מה אתם מצפים מהם, אילו שינויים התרחשו, אילו סיכונים קיבלתם ומה למדתם. זה הופך לגשר בין המציאות של הפעילות החיה לבין הציפיות של ISO 27001 A.5.22.

כיצד שינויים קטנים בספקים הופכים לאירועים גדולים

שינויים קטנים של ספקים גורמים לתקריות משמעותיות כאשר הם דוחפים אינטגרציות הדוקות ממילא מעבר למגבלותיהן באזורים, מצבים או קבוצות ספציפיות. התאמת ניתוב, הגדרת אבטחה מחמירה יותר או מטען SDK גדול יותר יכולים לדחוף את ההשהיה, שיעורי השגיאה או גדלי החבילות מעבר למה שהלוגיקה של המשחק שלך סובל, כך שהמשחק פתאום מרגיש גרוע יותר למרות שאף אחד לא שינה את הקוד שלך.

דרך טובה להתחיל היא לעבור על הפסקת חשמל או "brownout" שהתרחשה לאחרונה ולפרט כל תלות חיצונית ששיחקה תפקיד. אולי CDN העביר את המקור שלך לנקודת נוכחות חדשה, פלטפורמת ענן אילצה חבילות מקוד מחמירות יותר כברירת מחדל, או מודול אנטי-צ'יט התחיל לשלוח עומסים גדולים יותר. כל אחד מאלה יכול לדחוף אינטגרציה שברירית מעבר לקצה, במיוחד באזורים או מצבי משחק שכבר היו קרובים למגבלות הביצועים שלהם.

רוב הצוותים מגלים זאת רק לאחר מעשה. יומני רישום מראים מועדי פקיעה מוגברים או קודי שגיאה, אך לוקח שעות להבחין בהודעה על שינוי ספק בתיבת הדואר הנכנס של מישהו או בדף סטטוס. עיכוב זה מגדיל את זמן ההשבתה ומקשה על הסבר מה קרה להנהלה, לשותפים או למבקרים באופן שמקשר בבירור בין סיבה לתוצאה.

הדפוס הבסיסי זהה בכל כותרים ואולפנים. תהליכי סקירת הקוד והפריסה שלכם יכולים להיות מצוינים, אך המשחק עדיין קורס מכיוון שאתם לא עוקבים אחר שינויים בספקים באותה תחום. זיהוי דפוס זה הוא הצעד הראשון לקראת שימוש ב-A.5.22 ככלי לשיפור במקום להסתמך על ניחושים.

העלות הנסתרת באמון השחקנים ובהכנסותיהם

אירועי שינוי ספקים פוגעים ביותר מאשר זמן הפעילות; הם פוגעים בשקט באמון השחקנים, בהכנסות ובמוניטין שלכם עם שותפים. בכל פעם שאירוע, טורניר או ירידה עונתית מופרעים עקב שינויים חיצוניים, אתם מאבדים מומנטום, מגדילים את עומס התמיכה ומקשים על שכנוע השחקנים שהפעם הבאה תהיה שונה.

בעוד שמהנדסים מתמקדים בתסמינים טכניים, צוותים עסקיים וקהילתיים חווים בעיות בהחלפת ספקים כהפרעה למדדים מרכזיים. השבתות לא מתוכננות במהלך אירועים, טורנירים או ירידות עונתיות עלולות לבטל חודשים של מאמצי שיווק. לבעיות תשלום או זהות יש זנב ארוך במיוחד, מכיוון ששחקנים שנפגעו עלולים לא לסמוך על עסקאות עתידיות גם לאחר תיקונים.

השפעות אלו מחמירות אם הן חוזרות על עצמן. שחקנים מפתחים מודל מנטלי של המשחק שלכם כלא יציב או מאחור באזורים מסוימים, ללא קשר לסיבה הבסיסית. זוהי לא רק דאגה של אמינות אלא גם דאגה של אבטחה והוגנות: אם הפלטפורמה שלכם מופרעת באופן קבוע על ידי שינויים של צד שלישי, קשה יותר לטעון שיש לכם סביבה יציבה ומבוקרת היטב.

אלו הן סוגי ההשפעות שהופכות את סיכון הספקים לבעיה גלויה ברמת הדירקטוריון וברמת הרגולטור, ולא רק לבעיה הנדסית. בקרה A.5.22 מספקת לכם דרך מובנית לחבר את הנקודות בין אירועים בודדים לניטור ספקים מערכתי וניהול שינויים, כך שתוכלו להראות שלמדתם מבעיות עבר במקום לחזור עליהן.

הזמן הדגמה

מבעיית זמן פעולה לבעיית אבטחת שרשרת האספקה (ראש מחלקת אבטחה ותאימות / ראש מחלקת משפט וסיכונים – TOFU)

אירועים המונעים על ידי ספקים אינם רק בעיות בזמן תקינה; הם חושפים חולשות באבטחת שרשרת האספקה הרחבה יותר שלך. ISO 27001:2022 מקבץ בקרות סביב יחסי ספקים וסיכון שרשרת אספקה מכיוון שפרצות והפסקות אבטחה מודרניות רבות מקורן מחוץ לסביבה הישירה שלך, ו-A.5.22 עוזר לך להתייחס לשירותים חיצוניים אלה כחלק ממערכת האבטחה שלך.

כשמרחיבים את נקודת המבט משרתים לשרשרת האספקה, הפסקות מסתוריות ישנות פתאום הופכות הגיוניות.

אבטחת מידע הייתה ממוסגרת בעיקר במונחים של ההיקף והתשתית האישית שלך. בפלטפורמת משחקים מבוססת ענן, ההיקף שלך הוא נקבובי מטבעו. אתה מסתמך על רשתות, פלטפורמות ושירותים חיצוניים עבור משחקי ליבה, עיבוד נתונים, זהות ותשלומים, כך ששטח הסיכון שלך הוא למעשה שטח הסיכון של כל המערכת האקולוגית של הספקים שלך.

סעיף A.5.22 מבקש מכם להפסיק להתייחס למערכת האקולוגית הזו כרקע סטטי. במקום זאת, הוא מצפה לפיקוח מתמשך, מבוסס סיכונים. זה חורג מאיסוף אישורים ודוחות בעת הקליטה. זה כולל הבנת ביצועי הספקים לאורך זמן, כיצד הם מטפלים בחובות אבטחה והגנת נתונים וכיצד הם משנים את שירותיהם.

עבור משחקים, זה חשוב במיוחד. קחו לדוגמה מצב שבו CDN מכוון תנועה דרך תחום שיפוט חדש, ספק ענן פותח או סוגר אזורים, שירות צ'אט מוסיף מרכזי נתונים חדשים או שער תשלום משתמש במתווכים חדשים. לכל אחד מהשינויים הללו עשויות להיות השלכות על הבטחות לשמירת נתונים, התחייבויות הגבלת גיל או כללים ספציפיים למגזר כגון תקנות הימורים.

אם שינויים אלה מופיעים רק כאשר רגולטור שואל שאלות או שותף מבצע בדיקת נאותות, כבר פספסתם את כוונת A.5.22. הבקרה מעודדת אתכם לבנות השקפה משותפת בין הגורמים הביטחוניים, המשפטיים, התפעוליים והרכש לגבי אילו ספקים הם קריטיים, מה הוסכם, מה מנוטר וכיצד מטפלים בשינויים.

יחד עם זאת, הבקרה אינה מבקשת ממך להתייחס לכל ספק באותו אופן. היא מבוססת במפורש על סיכונים. כלי שיווק אזורי שניתן לכבות אינו זהה לספק זהות ששולט בגישה, או מעבד תשלומים שמטפל בזרימת כספים. זיהוי שכבות אלו והקצאת מאמצי ניטור ובדיקה בהתאם הם חלק מהתייחסות ל-A.5.22 כבקרת שרשרת אספקה ולא כבדיקת זמן פעולה כללית.

זמן פעולה הוא הכרחי אך לא מספיק

התמקדות בזמן הזמינות של הספקים בלבד אינה מספיקה, משום ששירותים יכולים להישאר "פעילים" תוך כדי ביצוע שינויים שמשנים את האבטחה, ההגינות או התאימות בדרכים שהגורמים והרגולטורים שלכם מעניינים. עליכם להבין מה משתנה מתחת למספרי הזמינות והאם שינויים אלה עדיין עומדים בהתחייבויות שלכם ובתיאבון שלכם לסיכון.

ארגוני משחקים רבים כבר עוקבים אחר זמן פעילות, זמן תגובה וספירת אירועים עבור ספקים. אלו מדדים הכרחיים, אך הם אינם מספרים את כל הסיפור. ספק יכול לעמוד ביעד זמן פעילות תוך שינוי בשקט של המקום שבו מעובדים הנתונים, למי יש גישה אליהם או כיצד הם מוגנים. מנקודת מבט של אבטחה ותאימות, שינויים אלה יכולים להיות בעלי משמעות רבה יותר מאשר הפסקת חשמל קצרה.

באופן דומה, התמקדות בזמן פעילות בלבד יכולה להוביל לנקודות עיוורות סביב הוגנות וניצול לרעה. לדוגמה, שינוי בתשתית שידוכים עשוי לשמור על שירותים זמינים אך לשנות את האופן שבו שחקנים מקובצים, עם השלכות על שלמות התחרות. עדכון נגד רמאויות עשוי להפחית תוצאות חיוביות שגויות אך גם להפחית את כיסוי הגילוי במצבים מסוימים. מדדי זמינות לבדן אינם חושפים את השינויים הללו או את השפעתם על פרופיל הסיכון שלך, לכן אתה זקוק לראייה רחבה יותר.

איומים ספציפיים למשחקים מצדדים שלישיים

שירותי צד שלישי מציגים איומים שנראים שונים עבור משחקים מאשר עבור שירותים מקוונים אחרים, במיוחד בכל הנוגע להוגנות, הונאה ובטיחות קהילתית. שינויים בספקים יכולים לשנות בשקט את האופן שבו אתם מזהים רמאים, מגנים על חשבונות, מטפלים בתשלומים או מנהלים תוכן, אפילו כאשר זמן הפעילות נראה מושלם.

פלטפורמות משחקים מתמודדות עם כמה איומים ברורים בשרשראות האספקה שלהן:

סיכון לרמאות ובוטינג כאשר אינטגרציות של אנטי-צ'יט או טלמטריה משתנות.
השתלטות על חשבון והונאת זהות כאשר זרימות אימות או שחזור תלויות בשירותים חיצוניים.
חשיפה ל-DDoS כאשר שירותי הפחתה או נתיבי רשת משתנים באופן בלתי צפוי.
סיכון להונאה ולביטול חיובים כאשר ספקים מותאמים את זרימת התשלום או את ניקוד הסיכונים.
חשיפה רגולטורית כאשר ספקי צ'אט, תוכן או ניתוח נתונים משנים את אופן הטיפול שלהם בנתוני שחקנים.

סעיף A.5.22 מספק מסגרת לטיפול באלה כחלק מתמונת סיכונים קוהרנטית. משמעות הדבר היא לשקול לא רק האם הספק "פעיל", אלא האם התנהגותו המתפתחת ממשיכה לעמוד בציפיות האבטחה, הפרטיות וההגינות שלכם עבור כל משחק ואזור. מסגור אירועים בדרך זו עוזר לצוותי משפט, סיכונים ואבטחה להתיישב על אילו שינויים בספק החשובים ביותר.

ISMS.online מעניק לך יתרון של 81% מרגע הכניסה

ISO 27001 בקלות

עשינו את העבודה הקשה בשבילך, ונתנו לך התחלה של 81% מרגע הכניסה. כל שעליכם לעשות הוא להשלים את החסר.

התחל כאן

מה באמת מבקש ממך לעשות בתקן ISO 27001 A.5.22 (קיקסטארטרים של תאימות / ראש אבטחה ותאימות – TOFU)

תקן ISO 27001:2022, נספח A לבקרה 5.22, מבקש מכם לדעת אילו ספקים באמת חשובים, לנטר אותם באופן מתוכנן ולשלוט באופן שבו שינויים בשירותיהם משפיעים על רמות האבטחה והשירות שלכם. מצופה מכם לעבור מבדיקת נאותות חד פעמית לפיקוח מתמשך מבוסס סיכונים שתוכלו להסביר ולהציג בפני רואי חשבון.

בליבתה, ניתן לבטא את תקן ISO 27001:2022 נספח A לבקרה 5.22 בשלוש התחייבויות פשוטות. ראשית, עליכם לזהות אילו שירותי ספק חשובים מספיק כך שכשלון או שינוי שלהם ישפיעו באופן מהותי על אבטחת המידע או על רמות השירות שלכם. שנית, עליכם לפקח ובודקים את השירותים הללו ואת הספקים שלהם באופן קבוע מול מה שהוסכמתם. שלישית, עליכם לנהל שינויים משמעותיים בשירותים אלו בצורה מבוקרת, כך שסיכונים חדשים יובנו וייקבלו לפני שהם משפיעים עליכם.

הטקסט הרשמי ומסמכי ההנחיות מרחיבים בנושא זה, אך המהות פשוטה. אתם שומרים על תמונה מעודכנת של ספקים קריטיים ומה הם עושים עבורכם, אתם מתכננים כיצד תנטרו ביצועים, רמת אבטחה ותאימות, אתם בודקים האם הספקים עדיין עומדים בצרכים ובתיאבון הסיכון שלכם, ואתם מעריכים, מאשרים ומתעדים שינויים משמעותיים לפני או תוך כדי שהם מתרחשים.

עבור פלטפורמת משחקים, "ספקים קריטיים" כמעט בוודאות כוללים ספקי ענן ציבורי המפעילים שרתי משחקים ושירותי back-end, ספקי CDN ראשיים, ספקי זהות וגישה מרכזיים, שותפים למניעת רמאויות ומניעת הונאות ושערי תשלום. בהתאם לארכיטקטורה שלכם, פלטפורמות צ'אט, קול, ניתוח נתונים, התאמה ותמיכת לקוחות עשויות להיכלל גם הן במסגרת התחום מכיוון שהן משפיעות על בטיחות, הוגנות או חשיפה רגולטורית.

A.5.22 אינו מחליף בקרות אחרות של ספקים. הוא פועל לצד בקרות המכסות בחירת ספקים וקליטתם, אבטחת מידע בהסכמי ספקים ושימוש בשירותי ענן. טעות נפוצה אחת היא להתייחס לבדיקת נאותות בתחילת מערכת יחסים כמספיקה, ולאחר מכן להסתמך על חוזים ואמון. עדכון 2022 של תקן ISO 27001 מדגיש כי ניטור מתמשך וניהול שינויים הם חלק ממערך הבקרות ולא תוספות אופציונליות.

מנקודת מבט של ראיות, סעיף A.5.22 עוסק ביכולת להראות, לא רק לומר, שאתם עושים את הדברים האלה. משמעות הדבר בדרך כלל היא רישום ספקים עם דירוגי סיכון וקריטיות, נהלי ניטור, רישומי סקירות, יומני שינויים וקישורים לאירועים שבהם ביצועי הספק או התנהגותו היו רלוונטיים. פלטפורמת ISMS כמו ISMS.online יכולה לעזור לרכז את כל זה במקום אחד כך שלא יהיה מפוזר על פני הודעות דוא"ל, גיליונות אלקטרוניים ותיבות דואר נכנס נפרדות.

הפיכת הטקסט לעקרונות פעולה

אתם הופכים את A.5.22 לניתן ליישום על ידי הפיכת ניסוחו לכמה עקרונות תפעול שצוותים יכולים לזכור ולפעול לפיה. עקרונות אלה צריכים להפוך פיקוח על ספקים מבוסס סיכונים לחלק טבעי מהעבודה היומיומית ולא לתרגיל תאימות נפרד.

כדי ליישם את A.5.22 בהקשר של משחקים, כדאי להגדיר קבוצה קטנה של עקרונות שניתן ליישם באופן עקבי:

אין ספק קריטי בלי בעלים.
אין פיקוח בלי מטרה ברורה.
אין שינוי משמעותי בספק ללא הערכה.
אין ביקורת ללא תוצאה מתועדת.
אין תקרית משמעותית עם ספק ללא ראיות ניתנות למעקב.

ניתן לקודד עקרונות אלה בנהלים, זרימות עבודה ולוחות מחוונים. בדרך זו, עמידה בדרישות A.5.22 הופכת לתוצר לוואי של משמעת תפעולית הגיונית ולא לתרגיל ניירת עצמאי שמופיע רק לפני ביקורות. כאשר צוותים רואים שעקרונות אלה גם מפחיתים כאוס של אירועים ומשפרים את ההסברים לשותפים, סביר יותר שהם יאמצו אותם.

כיצד נראות ראיות טובות לביקורת

ראיות טובות לפי סעיף A.5.22 מאפשרות למבקר לראות מי הספקים הקריטיים שלכם, כיצד אתם מנטרים אותם ומה עשיתם כאשר משהו השתנה או השתבש. המטרה אינה לייצר עוד ניירת, אלא להפוך את העבודה האמיתית שלכם לגלויה, ניתנת למעקב וחזרה.

בפועל, ראיות חזקות כוללות לעתים קרובות:

רישום ספקים חי עם בעלים, דירוגי סיכון ופרטי התקשרות.
תוכניות ניטור וספים המקושרים לכל רמת סיכון.
תיעוד של סקירות תקופתיות עם החלטות ופעולות מעקב.
רישומי שינויים המראים כיצד הערכת וקיבלת שינויים שיזם הספק.
רישומי אירועים המתייחסים במפורש לספקים המעורבים.

סביבת עבודה מקוונת של ISMS מסייעת בכך שהיא מספקת לכם רישום ספקים מובנה, רישומי שינויים המקושרים לאירועים ומקום לאחסון ביקורות והחלטות. זה הופך מידע מקוטע לסיפור קוהרנטי שתוכלו להפעיל שוב ושוב עבור בעלי עניין פנימיים ומבקרים בכל פעם שתצטרכו להראות כיצד אתם עומדים בתקן A.5.22. זה גם מפחית את המהומה לפני ביקורות מכיוון שהראיות נאספו כחלק מהעבודה הרגילה, ולא הופקו ברגע האחרון.

יישום A.5.22 על ספקי ענן, CDN וספקי משחקים ספציפיים (מנהל/ת תפעול חי / מנהל/ת טכנולוגיה ראשי/ת הנדסי – MOFU)

כדי ליישם את A.5.22 ביעילות, עליכם להבהיר אילו ספקי ענן, CDN וספקי משחקים מומחים חשובים ביותר, כיצד אתם מצפים מהם להתנהג ואילו סוגי שינויים צריכים לעורר סקירה מעמיקה יותר. מפת ספקים מדורגת סיכון הופכת רשימה מעורפלת של ספקים למערכת עדיפויות ממוקדת לניטור וניהול שינויים.

לאחר שתבינו מה מבקש A.5.22, השלב הבא הוא ליישם אותו בנוף הספקים הספציפי שלכם. נקודת המוצא היא מפה ברורה של מי הספקים שלכם, מה הם מספקים וכמה סיכון הם מציגים. בלעדיה, לא תוכלו לתעדף באופן משמעותי ניטור או ניהול שינויים, ותתקשו להסביר את הגישה שלכם למבקרים או לשותפים.

גישה מעשית היא לבנות מפת ספקים לפי רמות סיכון. בראש הרשימה, ממוקמים "חמצן פלטפורמה" - שירותים שכשלון או פגיעה בהם ימנעו באופן מיידי משחקנים להתחבר, לשחק או לשלם. זה בדרך כלל יכלול את פלטפורמות הענן העיקריות שלכם, ספקי CDN מרכזיים, מערכות זהות והרשאות קריטיות ושערי תשלום עיקריים. הרמה הבאה כוללת ספקים שיכולים לפגוע קשות בחוויית המשתמש או ליצור בעיות רגולטוריות, כגון כלי אנטי-צ'יט, צ'אט, קול, ניתוח ותמיכה. רמות נמוכות יותר יכולות לכלול כלים ושירותים חשובים אך קלים יותר להחלפה.

חלוקה זו מאפשרת לך להחליט היכן להשקיע לעומק. ספקים ברמה הראשונה עשויים לדרוש ניטור בזמן אמת, סקירות רשמיות רבעוניות וסעיפי הודעה קפדניים על שינויים. רמות נמוכות יותר עשויות להיות מנוטרות בצורה קלה יותר. סעיף A.5.22 תומך בגישה מבוססת סיכונים זו; הוא אינו דורש ממך להתייחס לכל ספק כקריטי, אלא רק להראות שהגישה שלך תואמת את רמת ההשפעה שיש לכל אחד מהם.

עבור כל מחלקת ספקים, עליך להגדיר מה נראה "טוב" בהקשר שלך. עבור ענן ו-CDN, זה עשוי לכלול טווחי השהייה לפי אזור, תקציבי שגיאות, מרווחי קיבולת, דפוסי חוסן וטיפול באירועים. עבור אנטי-צ'יט, זה יכול לכלול כיסוי גילוי, תהליכי סקירה, שקיפות סביב עדכונים וטיפול בתוצאות חיוביות שגויות. עבור תשלומים, ייתכן שתתמקד בשיעורי אישור, חיובים חוזרים, זמני סכסוכים ועמידה בתקנות הגנת נתונים ותקנות פיננסיות.

תרגיל זה משנה את השיחה מ"יש לנו חוזה ודף סטטוס" ל"אנחנו יודעים למה אנחנו מצפים, איך אנחנו צופים בזה ומה אנחנו עושים אם זה סוטה". זוהי בדיוק הכוונה של A.5.22 והוא עוזר לכם להסביר לעמיתים מדוע ספקים מסוימים מקבלים פיקוח מעמיק הרבה יותר מאחרים.

ויזואלי: דיאגרמת חלוקה לרמות הספקים, המציגה שירותים ברמה 1, ברמה 2 ורמות נמוכות יותר, מול השפעה ועומק סקירה.

בניית מפת ספקים לפי רמות סיכון

מודל פשוט של שכבות עוזר לכם להסביר לעמיתים ולמבקרים מדוע ספקים מסוימים מקבלים פיקוח מעמיק הרבה יותר מאחרים. זה גם מונע מכם לבזבז אנרגיה על יישום תהליכים כבדים בכלים בעלי סיכון נמוך שקל להחליף, מכיוון שהמאמץ שלכם מופנה לספקים שיכולים באמת לפגוע בחוויית השחקן או באבטחה.

טבלת השוואה קצרה יכולה להבהיר את החלוקה לרמות הזו.

נִדבָּך	השפעה על שחקנים	עומק ניטור	קצב הביקורת
1 Tier	עצירה מיידית למשחק או תשלום	מדדים והתראות בזמן אמת	רבעוני או טוב יותר
2 Tier	הידרדרות או בעיות חמורות	מדדים ובדיקות ממוקדות	פעמיים בשנה
שכבה תחתונה	מעצבן אבל ניתן להחלפה	בדיקות קלות וסקירות נקודתיות	שנתי

ניתן להתאים את התוויות והמרווחים הללו לארגון שלכם, אך שמירה על ההבחנות המובהקות תעזור לכם להצדיק היכן אתם משקיעים זמן. זה גם מקל על ההסבר לבעלי עניין פנימיים מדוע ספק ברמה הראשונה עובר יותר ביקורות ובקרות שינויים מחמירות יותר מאשר כלי בעל השפעה נמוכה.

זיהוי מתי שינוי ספק באמת חשוב

שינוי ספק באמת חשוב כאשר הוא משנה את המיקום או האופן שבו נתונים זורמים, משפיע על בקרות אבטחה או משנה את התנהגות המשחק והתשלום הליבה בדרכים שחקנים או רגולטורים היו מעוניינים בהן. ניתן להפוך את A.5.22 לפרקטי על ידי הגדרת קבוצה קצרה של "טריגרים" לשינוי עבור כל ספק קריטי שתמיד ראויים להערכה, במקום לנסות להתייחס לכל שינוי קטן כשינוי רשמי.

לא כל שינוי בספק מצדיק את אותה תגובה. חלק מיישום סעיף A.5.22 הוא להחליט אילו סוגי שינויים חייבים לעורר סקירה, בדיקה או אישור. דוגמאות לפלטפורמות משחקים כוללות:

פתיחה או סגירה של אזורים, או העברת נתונים בין אזורים.
שינוי מדיניות ניתוב, עמיתים או התנהגות anycast.
שינוי זרימות אימות או שדות נתוני מפתח של משתמשים.
עדכון ערכות SDK נגד צ'יטים או טלמטריה עם יכולות חדשות.
הוספה או שינוי של מעבדי משנה שניגשים לנתוני שחקנים.
התאמת מודלים של סיכון תשלום, טוקניזציה או מסלולי סליקה.

עבור כל ספק, ניתן לתחזק קבוצה פשוטה של "טריגרים לשינוי" הדורשים תשומת לב. כאשר טריגר מופעל - באמצעות הודעה, עדכון סטטוס או ניטור משלכם - ניתן לתעד את השינוי כתיעוד, להעריך את השפעתו, ובמידת האפשר, לבחון אותו בשלבים לפני פריסה מלאה.

כאן גם חשובים חוזים ומודלים של אחריות משותפת. אם ההסדרים שלכם אינם דורשים הודעה בזמן על שינויים מסוג זה, אתם תמיד תרדפו מאחור. התאמת ציפיות חוזיות למציאות תפעולית היא חלק מרכזי בהפיכת A.5.22 לפעיל בפועל, ו-ISMS.online יכול לעזור לכם לעקוב אחר אילו ספקים עומדים בציפיות אלו והיכן נותרו פערים בהסכמים הנוכחיים שלכם על ידי קישור חוזים, בעלים ורישומי שינויים במקום אחד.

הטמע, הרחב והרחיב את תאימותך, ללא כל בלגן. IO מעניק לך את החוסן והביטחון לצמוח בצורה מאובטחת.

הזמן את ההדגמה שלך

מסגרת ניטור: מדדי ביצועים (KPI) ולוחות מחוונים (Dashboards) למשחקים בזמן אמת (מנהל/ת תפעול חי / ראש/ת אבטחה ותאימות – MOFU)

ניטור A.5.22 עבור משחקים בזמן אמת אמור לספק לצוותי התפעול החי התרעה מוקדמת על בעיות עם ספקים, תוך מתן ראיות ברורות למבקרים לכך שאתם צופים, מבינים ומגיבים לביצועי הספקים. מסגרת פשוטה הבנויה סביב מדדים, לוחות מחוונים ופעולות מאפשרת לכם לשרת את שני הקהלים מבלי לבנות מערכות נפרדות.

עבור משחקים בזמן אמת, ניטור תחת A.5.22 צריך להיות יותר משאלונים שנתיים ופגישות מזדמנות. עליו לייצר אותות משמעותיים ובזמן שיעזרו לכם להגן על חוויית השחקן ואבטחתו. במקביל, עליו לייצר ראיות שתוכלו להציג לרואה חשבון שרוצה לדעת כיצד אתם מפקחים על ספקים וכיצד אתם מטפלים בשינויים שלהם.

דרך פשוטה לעצב את מסגרת הניטור שלך היא לחשוב בשלוש שכבות:

מדדים: – האינדיקטורים הגולמיים שאתם אוספים עבור כל ספק קריטי.
צפיות: – לוחות מחוונים ודוחות המשלבים מדדים למשהו קריא.
פעולות: – כיצד אתם מגיבים כאשר אינדיקטורים חוצים ספים או משנים מגמה.

מדדים הם האינדיקטורים הגולמיים שאתם אוספים עבור כל ספק קריטי. עבור ענן ו-CDN, זה עשוי לכלול השהייה, ריצוד, אובדן חבילות, שיעורי שגיאות, זמן פעולה ברמת האזור, אירועי DDoS וניצול קיבולת. עבור אנטי-צ'יט, ייתכן שתעקוב אחר שיעורי רמאות שזוהו, דפוסי התחמקות מחסימה ואנומליות בטלמטריה. עבור תשלומים, תנטרו שיעורי אישורים, ניסיונות הונאה, חיובים חוזרים ודחיות, תוך התמקדות במגמות ולא בקפיצות חד פעמיות.

תצוגות הן האופן שבו משלבים את המדדים הללו ללוחות מחוונים ודוחות. לוח מחוונים טוב לביצועי ספקים ושינויים עבור משחקים יראה, במבט חטוף, כיצד התנהגו מדדי QoS מרכזיים לאורך זמן, מתי הוכרזו תקריות ספקים ומתי התרחשו שינויים משמעותיים בספקים. באופן אידיאלי, הוא יציג גם אינדיקטורים קשורים המתמקדים בשחקנים כגון זמני תור, שיעורי ניתוק וקרשות תמיכה, כך שמנהלי פעולות חירום יוכלו לראות את השפעת הספקים במונחי שחקנים ולא רק כגרפים של תשתית.

פעולות הן מה שאתם עושים עם מה שאתם רואים. זה כולל ספי התראות וניתוב, נתיבי הסלמה וקצבי סקירה. סעיף A.5.22 מצפה שתוכלו להראות שאתם לא רק אוספים נתונים, אלא פועלים על פיהם כאשר ספק חורג מתאיון הסיכון שלכם. זה יכול להיות הפעלת אירוע, הפעלת סעיפים חוזיים, התאמת הגדרות משחק או בחינה מחדש של דירוג הסיכון שלכם עבור אותו ספק.

ויזואלי: דוגמה לפריסת לוח מחוונים עם אריחי ספקים, מפות השהיה אזוריות וציר זמן של שינויים המותאם לאירועים.

ISMS.online יכול לקשר את עבודת הניטור הזו למערכת הממשל שלכם על ידי כך שתאפשר לכם לרשום ספקים, לתאר את תוכניות הניטור שלכם, לקשר ללוחות מחוונים ולאחסן פרוטוקולי סקירה במערכת ISMS אחת. בדרך זו, אותם מדדים המגנים על חוויית השחקן הופכים להוכחה לכך שאתם עומדים בדרישות A.5.22, מבלי לבקש מצוותים לשמור על "תצוגת תאימות" נפרדת שמתיישרת במהירות.

עיצוב לוחות מחוונים המשמשים הן לפעילות חיה והן לביקורות

לוח בקרה נהדר של A.5.22 מאפשר לשידורים חיים להגן על חוויית השחקן בזמן אמת ומעניק למבקרים מבט חטוף על האופן שבו אתם מפקחים על ספקים. אם תתכננו תוך התחשבות בשתי הקבוצות, הכלים היומיומיים שלכם ייצרו אוטומטית את הראיות שאתם צריכים.

לוח מחוונים יעיל עבור A.5.22 בהקשר של משחקים כולל בדרך כלל:

תצוגה מקדימה של ספקים קריטיים עם סטטוס, אירועים אחרונים ומדדים מרכזיים.
פירוט מדרגות לפי ספק המציג מגמות ביצועים ותצוגות אזוריות.
פאנל המפרט שינויים אחרונים בספקים וחלונות שינוי מתוכננים.
קישורים לפרוטוקולי סקירה, הערכות סיכונים ונקודות פעולה.

עבור פעולות בשידור חי, לוח המחוונים הזה עונה על "מה פוגע בשחקנים כרגע, והיכן?". עבור צוותי תאימות וביקורת, הוא עונה על "איך אנחנו יודעים שהספק הזה עדיין נמצא בתיאבון הסיכון שלנו, ומה עשינו כשהוא לא היה?". כאשר מקשרים לוחות מחוונים להערות סקירה ולרישומי סיכונים, נמנעים מ"לוחות מחוונים תאימות" נפרדים שאף אחד לא בודק בייצור, מכיוון שלוח המחוונים התפעולי כבר נושא את קומת התאימות.

עבור ביקורות, אינכם צריכים להציג כל פרט טכני. מה שאתם צריכים הוא ראיות לכך שחשבתם על מה לנטר, שאתם בוחנים זאת באופן קבוע ושאתם מגיבים למה שזה אומר לכם. ייצוא תמונות מצב של לוחות מחוונים, בשילוב עם רשומות סקירה המאוחסנות במערכת ה-ISMS שלכם, בדרך כלל מספיק כדי להבהיר זאת ולשמור על מאמצי ההכנה ניתנים לניהול.

קישור לוחות מחוונים לסקירות וביקורות רשמיות

לוחות מחוונים עוזרים ב-A.5.22 רק אם הופכים את מה שהם מציגים להחלטות, פעולות ורישומים. אותן תצוגות שצוותי תפעול חי צופים בהן במהלך אירועים יכולות להזין ביקורות ספקים מובנות, ומאוחר יותר, ראיות ביקורת לכך שהניטור שלכם הוא יותר מתרגיל סימון תיבות.

ניתן להפוך את הקישור הזה למפורש על ידי:

תזמון סקירות ספקים תקופתיות המתחילות מנתוני לוח מחוונים אמיתיים.
רישום תוצאות הסקירה, ההחלטות והפעולות במערכת ה-ISMS שלכם.
חיבור אירועים בלוח המחוונים לרישומי שינויי ספקים וללקחים שנלמדו.

ISMS.online תומך בכך בכך שהוא מאפשר לך לקשר כל ספק קריטי לבעלים, דירוגי סיכונים, ציפיות ניטור ורישומי סקירה. בדרך זו, לוחות המחוונים שלך יישארו ממוקדים בפעילות, בעוד ש-ISMS שלך לוכד את סיפור הממשל מאחוריהם ועוזר לך להגיב בביטחון כאשר מבקרים או שותפים שואלים כיצד אתה מפקח על צדדים שלישיים קריטיים. עם הזמן, לולאת משוב זו גם משפרת את עיצוב הניטור שלך, מכיוון שדיוני סקירה מדגישים אילו מדדים ונקודות מבט מועילות באמת.

תוכנית ניהול שינויים עם ספקי ענן ו-CDN (מנהל טכנולוגיה ראשי הנדסי / מנהל תפעול חי – MOFU)

ניהול שינויים תחת סעיף A.5.22 עוסק בהתייחסות לשינויים משמעותיים בספקים כשינויים בסביבה שלכם, עם שלבים ברורים, החל מההודעה ועד ללמידה. אינכם יכולים לשלוט בתהליך הפנימי של ספק ענן או ספק CDN, אך אתם יכולים לשלוט באופן שבו אתם מתכוננים, בודקים ומנטרים את השפעת השינויים שלהם על המשחקים שלכם.

ניטור אומר לך מה קורה; ניהול שינויים מעצב את מה שצריך לקרות בהמשך. סעיף A.5.22 מדגיש כי שינויים בשירותי הספקים חייבים להיות "מבוקרים", לא רק נצפים. עבור ספקי ענן ו-CDN, זה יכול להיות מאתגר, כי אינך אחראי על התהליכים הפנימיים שלהם. מה שאתה יכול לשלוט בו הוא כיצד השינויים שלהם מתקשרים עם הסביבה שלך וכיצד הצוותים שלך מגיבים כאשר שינויים אלה מתוכננים או בלתי צפויים.

תוכנית מעשית היא ליישר קו בין הטיפול בשינויים בספקים לבין תהליכי ניהול השינויים ותגובה לאירועים הקיימים שלכם. במקום להמציא מסלול נפרד לשינויים חיצוניים, תוכלו להתייחס לשינויים משמעותיים בספקים כאל שינויים בסביבה שלכם שמקורם במקרה במקום אחר. זה מאפשר לצוותי התפעול וההנדסה שלכם לעבוד עם מושגים מוכרים ומפחית את הפיתוי "לעקוף" את התהליך.

הטמעת שינויים בספקים במחזור החיים של העסק

זה עוזר לתאר שינויים בספקים באמצעות אותה שפת מחזור חיים שבה אתם כבר משתמשים לשינויים פנימיים. קבוצה פשוטה וחוזרת על עצמה של שלבים מקלה על מהנדסים, מנהלי מוצר וצוותי תאימות לעבוד מאותו ספר פעולות ולהבין היכן A.5.22 משתלב.

שלב 1 – הודעה

סכמו כיצד תקבלו מידע על שינוי ספק, ונתבו אותו למערכת הכרטיסים או השינויים שלכם כדי שלא יאבד בתיבות הדואר הנכנס האישיות.

שלב 2 – מיון

החליטו במהירות האם השינוי רלוונטי וכמה הוא עשוי להיות מסוכן עבור משחקים, מצבי משחקים או אזורים ספציפיים, בהתבסס על חלוקת הספקים שלכם וגורמים מעוררי שינוי.

שלב 3 – הערכה ובדיקה

עבור שינויים בסיכון גבוה יותר, יש להעריך את ההשפעה הסבירה, ובמידת האפשר, להריץ בדיקות בסביבות שאינן סביבות ייצור, כגון שרד תהליכים (staging shards), אזורי בדיקה או קבוצות קנריות.

שלב 4 – אישור או קבלה

רשמו החלטה ברורה להמשיך, להגביל, לתזמן או לקבל את הסיכון, וציינו מי אישר זאת כדי שתוכלו להסביר את ההיגיון מאוחר יותר אם משהו משתבש.

שלב 5 – יישום ומעקב

עקבו אחר חלון השינויים ועקובו אחר מדדים מרכזיים, מוכנים לביטול או לצמצום השינויים אם ההתנהגות תשתפר באופן שבו שחקנים היו מבחינים בכך.

שלב 6 – סקירה ולמידה

לאחר החלון, תעדו מה קרה, מה עבד ומה תשנו בפעם הבאה, וקשרו את הלקחים הללו לרישומי הספקים ולספרי הפעולות.

עבור ספקים בסיכון גבוה, ייתכן שתרצו תקופות הודעה מוקדמות וחלונות שינויים סטנדרטיים שיוסכמו בחוזים, עם ציפיות ברורות לגבי המידע שאתם מקבלים. לדוגמה, ייתכן שתדרשו הודעה מוקדמת על מעברי אזור, מעבדי משנה חדשים או שינויים המשפיעים על בקרות ניתוב או אבטחה, כך שצעדים אלה יוכלו להתרחש לפני שהשינויים יפגעו בתעבורה חיה.

אמצעי הגנה טכניים שהופכים את הממשל למציאותי

אמצעי הגנה טכניים הופכים את ניהול שינויי הספקים לריאליסטי בכך שהם מספקים לכם דרכים בטוחות לבדיקה, חזרה למצב הקודם ולבלום את רדיוס הפיצוץ של שינויים במעלה הזרם. כאשר אפשרויות אלה קיימות, שלבי האישור שלכם הופכים לשערי סיכון אמיתיים במקום משוכות בירוקרטיות איטיות שכולם מנסים לעקוף.

כדי להפוך את זה לאפשרי בלי להאט את הצוותים שלך עד תום, דפוסים נפוצים כוללים:

הפעלת אזורים קנריים או קבוצות קטנות דרך מסלולים או סביבות חדשות לפני פריסה עולמית.
שימוש באסטרטגיות פריסה כחול/ירוק או דומות כדי שתוכלו לעבור במהירות אם ההתנהגות מתדרדרת.
תחזוקת ספרי ריצה של rollback שנבדקו ואינם תלויים בידע של אדם אחד.
שילוב הודעות על שינויי ספקים במערכות תצפית או כרטוס כך שיהיו גלויות במהלך אירועים.

אמצעי הגנה אלה משמעותם ששלבי אישור בתהליך השינוי שלכם הופכים לשערי סיכון המגובים על ידי אפשרויות אמיתיות, ולא נקודות בדיקה ללא גיבוי מעשי. הם נותנים למנהלי התהליכים והנדסה ביטחון שסיכון מבוקר אינו מביא להפחתת מהירות, והם נותנים לצוותי הציות סיפורים טובים יותר לספר למבקרים על אופן ניהול שינויי הספקים שלכם.

פלטפורמת ISMS יכולה לסייע בלכידה וחיבור של החלקים הלא טכניים של התמונה: רישומי שינויים, אישורים, הערכות וסקירות. כאשר ניתן להראות, עבור שינוי ספק נתון, מי העריך אותו, מה הוחלט וכיצד הוא התנהל, אתם בדרך הנכונה לעמוד בציפיות A.5.22. ISMS.online תומך בכך בכך שהוא מאפשר לכם לקשר רישומי שינויי ספקים לאירועים והערכות סיכונים בסביבת עבודה אחת הניתנת לביקורת, שממנה יכולים לעבוד ראשי האבטחה, התפעול הליברטי והתאימות שלכם.

ISMS.online תומך ביותר מ-100 תקנים ותקנות, ומעניק לך פלטפורמה אחת לכל צרכי התאימות שלך.

הזמן את ההדגמה שלך

אחריות משותפת, חוזים וראיות שבאמת עובדות (ראש מחלקה משפטית וסיכונים / ראש מחלקה אבטחה ותאימות – MOFU/BOFU)

דיאגרמות של אחריות משותפת עוזרות רק אם הן הופכות לניסוח חוזים קונקרטי ולבעלות פנימית ברורה. סעיף A.5.22 מצפה שתדעו מה אתם סומכים על ספקים לעשות, מה אתם שולטים בו בעצמכם וכיצד שני הצדדים יתקשרו ויראו שינויים משמעותיים. סעיף זה הוא אינפורמטיבי בלבד ואינו מהווה ייעוץ משפטי; עליכם לעבוד עם עורך דין מוסמך בעת ניסוח או תיקון חוזים.

שירותי ענן ו-CDN מתוארים לעתים קרובות באמצעות דיאגרמות של אחריות משותפת. אלו נקודות התחלה שימושיות, אך סעיף A.5.22 דורש ממך להפוך אותן לאחריות וראיות קונקרטיות. זה חשוב במיוחד כאשר הפלטפורמה שלך משתרעת על פני אזורים מרובים ומשטרי רגולציה וצוותי המשפט והסיכונים שלך צריכים להגן על ההסדרים שלך בפני רגולטורים, בעלי פלטפורמה או שותפים.

בצד החוזי, אתם רוצים שיהיו רשומות ציפיות מרכזיות מהספקים הקריטיים שלכם. דוגמאות לכך כוללות:

שינויים בספקים המחייבים הודעה מוקדמת ותקופות הודעה מוסכמות.
תמיכה בבדיקות או הרצה מקבילה במהלך שינויים גדולים, במידת האפשר.
גישה ליומנים, דוחות ומידע על אירועים הרלוונטיים לסביבה שלך.
דרישות למיקומי נתונים, מעבדי משנה ונהלי אבטחה מינימליים.

אלה צריכים להתאים להערכות הסיכונים וליכולות התפעוליות שלכם. דרישות לא מציאותיות לא עוזרות לאף אחד, אבל הצהרות מעורפלות לא נותנות לכם שום דבר לעבוד איתו כשמשהו משתבש. צוותים משפטיים ורכש יכולים לעזור לתרגם ממצאי סיכונים לניסוח בר אכיפה שיספק לכם מנופים משמעותיים כאשר ספקים נכשלים או יוצרים סיכונים חדשים.

בצד הפנימי, אתם זקוקים להקצאת אחריות ברורה. מטריצת אחריות פשוטה יכולה להגדיר מי:

אחראי על יחסי הספקים ועל דיוני החוזים.
בעל/ת אינטגרציה טכנית וניטור התנהגות בזמן אמת.
בעל הערכות והמלצות בנושא סיכוני אבטחה ופרטיות.
מאשר שינויים בסיכון גבוה וקבלת סיכונים.
מוביל תיאום אירועים כאשר הספק מעורב.

בהירות זו חיונית הן לפעילות היומיומית והן לשביעות רצון המבקרים מכך שהפיקוח על הספקים אינו נותר ליד המקרה. היא גם עוזרת למצטרפים חדשים ולבעלים מחליפים להבין למה הם נכנסים, במקום לגלות אחריות הדרגתית באמצעות אירועים.

יישור דיאגרמות של אחריות משותפת עם החלטות אמיתיות

דיאגרמות של אחריות משותפת הופכות בעלות ערך כאשר הן מנחות החלטות אמיתיות בנוגע לסיכונים, ניטור והסלמה. אם הן יישארו כתחליף להוראות, הן לא יעזרו לכם לעמוד ב-A.5.22 או להגן על השחקנים שלכם כאשר משהו נשבר בשרשרת האספקה.

ניתן להפוך אותם לשימושיים על ידי:

קישור כל תחום אחריות לבקרות, בדיקות או דוחות ספציפיים.
הסכמה איזה צוות מקבל את ההחלטה הסופית כאשר סיכון חוצה פונקציות.
רישום דוגמאות של אירועים קודמים בהם נבחנו גבולות האחריות.

כאשר קישורים אלה קיימים, רמזים משפטיים וסיכוניים יכולים להצביע על ראיות קונקרטיות לכך שאחריות משותפת מובנת ומיושמת. ISMS.online יכול לתמוך בכך על ידי צירוף מודלים של אחריות משותפת, חוזים ורישומי החלטות לכל ספק במרשם שלכם, כך שהדיאגרמות, ההתחייבויות והראיות שלכם יישארו מחוברים וקלים לאיתור כשאתם זקוקים להם.

בניית קומת ראיות A.5.22

מנקודת מבט של ISO 27001, השאלה היא לא רק האם אתם עושים את הדברים הנכונים, אלא האם אתם יכולים להראות שאתם עושים אותם. עבור A.5.22, זה בדרך כלל כרוך בקבוצה קטנה של חפצים מקושרים ומתוחזקים ולא בערימת ניירת גדולה שאף אחד לא קורא.

אלמנטים שימושיים של מאגר ראיות כוללים:

רישום ספקים עדכני עם סיווגים, בעלים ודירוגי קריטיות.
נהלי ניטור ובקרה עבור כל שכבת ספק.
רישומי ביצועי ספקים וסקירות סיכונים עם החלטות ופעולות.
רישומי שינויים שבהם בוצעו הערכות ומעקב אחר שינויים שיזמו הספק.
קישורים בין אירועי ספקים, אירועים פנימיים ושיפורים.

איסוף, קישור ושמירה של מידע זה יכולים להיות קשים אם הוא מפוזר על פני כלים וצוותים. כאן סביבת עבודה מרכזית של ISMS הופכת ליותר מארכיון תאימות. היא הופכת למקום שבו סיכון ספקים, ביצועים, שינוי וראיות מחוברים, ושבו מובילים משפטיים וסיכונים יכולים למצוא את מה שהם צריכים במהירות, אפילו תחת לחץ זמן.

ISMS.online נועד לסייע בדיוק בכך. ניתן לתחזק רישום ספקים עם בעלים ודירוגי סיכונים, לצרף תוכניות ניטור וסקירה, לאחסן רישומי שינויים ואישורים ולקשר אותם לאירועים ופעולות מתקנות. לאחר מכן, צוותי משפט וצוותי סיכונים יכולים לענות על שאלות מהרגולטורים, שותפים או בעלי פלטפורמה לגבי אופן ניהול סיכוני צד שלישי על ידי התייחסות לתצוגה מובנית אחת במקום לרדוף אחר מידע בצורה חלקה.

הזמן הדגמה עם ISMS.online עוד היום (כל הפרסונות – BOFU)

ISMS.online מספקת לארגון המשחקים שלכם דרך מעשית להפוך את ISO 27001 A.5.22 למערכת עובדת על ידי ריכוז רישומי ספקים, דירוגי סיכונים, רישומי שינויים ובדיקת ראיות במקום אחד. אתם ממשיכים להשתמש בענן, ב-CDN ובכלי הניטור הקיימים שלכם, אך מוסיפים עמוד שדרה לאבטחת מידע שמסביר מי הספקים הקריטיים שלכם, כיצד אתם מנטרים אותם ומה עשיתם כשהם השתנו.

דרך מעשית להתחיל היא להתחיל בקטן. קחו משחק חי אחד עם הכנסות גבוהות ואת קומץ הספקים הקריטיים ביותר שלו - בדרך כלל ענן, CDN, זהות ותשלומים - ודמו אותם בתוך סביבת עבודה של ISMS.online. הקצו בעלים, רשמו את הציפיות שלכם, קשרו ללוחות מחוונים קיימים והגדירו מה נחשב לשינוי משמעותי. לאחר מכן, עברו על אירוע אחרון ובדקו עד כמה הרשומות הנוכחיות שלכם מסבירות מה קרה כשאתם מסתכלים עליהן דרך עדשה זו.

פיילוט זה יחשוף במהירות היכן גיליונות אלקטרוניים ידניים ולוחות מחוונים אד-הוק עדיין מספיקים, והיכן ריכוזיות תפחית באופן ניכר את הזמן שלוקח להבין בעיה הקשורה לספק או להתכונן לביקורת. זה גם נותן למנהלים ולראשי צוותים משהו קונקרטי להגיב אליו, במקום הצעה מופשטת לשיפור ניהול הספקים.

ככל שתשכללו את הגישה שלכם, תוכלו לשלב בעלי עניין מתחומי המשפט, האבטחה, התפעול והפיננסים כדי להסכים על מה שנראה "טוב" עבור ניהול ספקים בארגון שלכם. הגדרה משותפת זו פירושה שכל זרימת עבודה או כלים חדשים תומכים בסדרי העדיפויות של כל הקבוצות המרכזיות במקום להיתפס כנטל המוטל על ידי צוות אחד. זה גם מקל על הבטחת תקציב ותמיכה, מכיוון שכל פונקציה יכולה לראות את הסיכונים והיעילות שלה משתקפים.

משם תוכלו להתרחב בהדרגה על פני כותרות ואזורים. מדדים מוקדמים - פחות אירועים מעורפלים, ניתוח מהיר יותר של גורמי שורש, שבילי ביקורת נקיים יותר ובעלות ברורה יותר על הספקים - הופכים להוכחה לכך שההשקעה שלכם משתלמת. במהלך השנה הראשונה, תוכלו לקבוע יעדים פשוטים וגלאים לעין, כגון מיפוי של כל הספקים ברמה הראשונה ובעלותם, הגדרת טריגרים לשינויים ונמצאים בשימוש והשלמת מחזור ראשון של סקירות ספקים מובנות.

התחל עם פיילוט ממוקד

התחלה עם פיילוט ממוקד על כותר אחד וקבוצה קטנה של ספקים קריטיים הופכת את A.5.22 להשגה ולא מכריעה. ניתן להוכיח ערך במהירות, לחדד את הגישה שלכם ולאחר מכן ליישם את הדפוס על שאר תיק העבודות שלכם מבלי להתחייב לשינוי משבש בבת אחת.

עבור הפיילוט שלך, ייתכן שתעשה את הדברים הבאים:

בחר משחק חי עם חשיבות ברורה להכנסות או למוניטין.
זהה את ספקי הענן, ה-CDN, הזהויות והתשלומים שלה כספקים ראשוניים מסוג ראשון.
דגמו את אלה ב-ISMS.online עם בעלים, סיכונים וציפיות ניטור.
צור מחדש אירוע שהתרחש לאחרונה כמקרה בדיקה, וקשר אותו לרישומי ספקים ושינויים.

תרגיל זה מראה היכן הממשל כבר עובד, היכן אתם מסתמכים על ידע אישי או מיילים ישנים וכמה יותר בטוחים אתם מרגישים כאשר כל הסיפור נמצא במקום אחד. זה גם נותן לכם תחושה ריאליסטית של מאמץ, מה שעוזר לכם לתכנן את השלבים הבאים.

כיצד ISMS.online תומך ב-A.5.22 עבור משחקים

ISMS.online תומך ב-A.5.22 עבור פלטפורמות משחקים על ידי מתן אבני בניין מובנות: רישומי ספקים עם בעלים ודירוגי סיכונים, מרחבים לרישום תוכניות ניטור וסקירה, יומני שינויים המקושרים לאירועים ודוחות מוכנים לביקורת שתוכלו לשתף עם בעלי עניין פנימיים וחיצוניים. אתם ממשיכים להשתמש במערך הטכני הקיים שלכם, אך אתם מקבלים שכבת ממשל שקל להסביר ולתחזק על פני משחקים, אזורים ומסגרות.

שיחת גילוי קצרה והדגמה אינן מחייבות אתכם להגירה מלאה; הן מאפשרות לכם לבדוק האם דפוס הפיילוט הזה מתאים למציאות שלכם לפני שאתם מגדילים אותו. כשתהיו מוכנים לעבור מעבר לפיילוט אחד, הדגמה תראה כיצד אבני הבניין הללו משתרעות על מספר כותרים, תוסיף בקרות פרטיות ובינה מלאכותית לצד אבטחה ותעזור לכם לשמור על התאמה בין סיכון, ביצועים וראיות של הספק.

אם אתם רוצים שהצוותים שלכם יבזבזו פחות זמן במרדף אחר מידע מספקים ויותר זמן באספקת משחקים יציבים, הוגנים ובטוחים, הזמנת הדגמה עם ISMS.online היא צעד פשוט ופשוט. זה עוזר לכם לראות כיצד ISMS מובנה יכול לתמוך בתקן ISO 27001 A.5.22 ובבקרות קשורות בכל תיק המשחקים שלכם, תוך הפיכת שינויים בספקים מהפתעות לא נעימות לאירועים מנוהלים וניתנים להסבר.

הזמן הדגמה

שאלות נפוצות

כיצד על אולפן משחקים לפרש את תקן ISO 27001 A.5.22 עבור הספקים המרכזיים שלו?

תקן ISO 27001 A.5.22 מצפה ממך ניטור, סקירה ובקרה פעילים של האופן שבו שירותי הספקים משתנים לאורך זמן, במיוחד במקרים בהם הם משפיעים על משחק חי או נתוני שחקנים. חוזה הוא רק נקודת ההתחלה; עליך להיות מסוגל להראות דרך עקבית להבנת סיכוני הספק ולפעול לפיו.

אילו ספקים נופלים באופן ישיר תחת סעיף A.5.22 בסביבת משחקים?

במערך משחקים מודרני, A.5.22 חל בדרך כלל על ספקים כגון:

תשתית ענן ואחסון
CDN וניהול תעבורה
זהות, גישה והגנה מפני רמאות
טיפול בתשלומים, הונאות והחזרי חיוב
צ'אט, קול, ניהול ושכבות חברתיות
אנליטיקה, טלמטריה ודיווחי קריסה
תמיכת לקוחות, שירותי כרטיסים וכלי קהילה

עבור כל אחד מאלה, עליך להיות מסוגל להוכיח שאתה:

לשמור על רישום ספקים נוכחי עם קריטיות, דירוג סיכון וחלוקה לדרגות.
הקצה בעלים פנימיים בעלי שם לאחריות מסחרית, תפעולית וביטחונית.
לְהַגדִיר איך ובאיזו תדירות אתה מנטר ובודק ביצועים וסיכונים (מדדי KPI/KRI, אירועים, דוחות, ביקורות).
לטפל שינויים בספקי חומרים (אזורים, ערכות SDK, מעבדי משנה, זרימות נתונים) כשינויים בסביבת הייצור שלך, לאחר הערכה ואישור.
ללכוד עדותסיכומי פגישות, עדכוני סיכונים, כרטיסים, יומני שינויים, החלטות ופעולות מעקב.

מערכת ניהול אבטחת מידע (ISMS) או מערכת ניהול משולבת (IMS) של נספח L עוזרת לכם להפוך זאת לשגרה חוזרת ולא לבלבול שנתי. ISMS.online מאפשר לכם לשמור רישומי ספקים, סיכונים, ביקורות והחלטות שינוי במקום אחד, כך שכאשר מבקר שואל "הראה לי כיצד אתה מנהל את הספק הזה", אתה מציג קומה ברורה במקום לאסוף אותה יחד מתיבות דואר נכנס וגליונות אלקטרוניים.

אם אתם עדיין מתמודדים עם פיקוח על ספקים בכלים מנותקים, זוהי נקודה מעשית לשלב את הצוות שלכם במערכת ניהול מידע (ISMS) ולהסכים מהי התוצאה הסופית של כל ספק קריטי ב-12 החודשים הקרובים.

כיצד נבחר מדדי ביצועים (KPI) ומדדי סיכון שחשובים הן לשחקנים והן לתקן ISO 27001 A.5.22?

האינדיקטורים היעילים ביותר עבור A.5.22 הם ממוקד שחקן ומבוסס סיכוןהתחילו עם מה שיכול לפגוע בחוויה או בהמשכיות, לאחר מכן חזרו למדדי ספקים שמזהירים אתכם מוקדם.

מהם מדדי KPI ו-KRI שימושיים עבור ספקי משחקים נפוצים?

עבור ספקים ברמה גבוהה יותר, ארגוני משחקים רבים עוקבים אחר מדדים כמו:

ענן ו-CDN:
זמן פעולה ושיעורי שגיאות ברמת האזור
השהייה, ריצוד ואובדן חבילות לפי אזור, ספק אינטרנט ופלטפורמה
מרווח קיבולת, אירועי ויסות וטיפולים נגד DDoS
זהות, אבטחה והגנה מפני רמאויות:
שיעורי הצלחה וכישלון בכניסה לפי גיאוגרפיה ומכשיר
זמן מאירוע חשוד ועד לחקירה או אכיפה
שיעורי חיוביים שגויות ודפוסי התחמקות חוזרים
תשלומים ומסחר:
שיעורי אישור/דחייה לפי ספק ומדינה
ניסיונות הונאה, חיובים חוזרים וזמן מחזור של מחלוקת
פניות תמיכה הקשורות לתשלום ותלונות שחקנים

אותות טכניים אלה צריכים להצטבר לתוך תוצאות השחקנים והעסקים, כגון משתמשים בו זמנית, נשירה במהלך התאמה, או המרה לחנות. עבור ISO 27001, הנקודה החשובה היא שתוכלו להראות קו ברור מ קריטיות הספק ודירוג סיכון → מדדי ביצועים/קריטיות שנבחרו → ספים והתראות → פעולות שבוצעו ונרשמו.

השוואה פשוטה יכולה לעזור לך לתכנן את קבוצת האינדיקטורים הראשונה שלך:

סוג ספק	סיכון ממוקד שחקן	דוגמה ל-KRI
ענן / CDN	השהיה, ניתוקים, הפסקות חשמל	השהייה ושיעור שגיאות לכל אזור מפתח
זהות / נגד רמאות	השבתות, איסורים לא הוגנים, ניצול לרעה	תוצאות חיוביות שגויות, זמן לאכיפה
תשלומים	רכישות כושלות, סכסוכי הונאה	שיעור דחייה ונפח חיובים חוזרים

צוותים רבים מציגים את המדדים הללו בלוח מחוונים מרכזי ולאחר מכן רושמים אותם פרצות, החלטות ומעקבים בתוך מערכת ה-ISMS שלהםכאשר משתמשים ב-ISMS.online כדי לקשר מדדים לספקים, סיכונים, בקרות ואירועים, אותו לוח מחוונים ששומר על התפעול הפעיל מעודכן הופך גם לראיה נקייה וחוזרת על עצמה לכך שניטור A.5.22 מבוסס סיכונים ומניע בפועל החלטות.

אם מדדי הספקים הנוכחיים שלכם אינם מתחברים בבירור להשפעת השחקנים ולדירוגי הסיכון, זהו סימן חזק לעצור וליישר אותם מחדש לפני סקירת ההנהלה הבאה שלכם.

כיצד נוכל לבנות לוח מחוונים של ספקים שעליו מסתמכים פעולות הפעלה בזמן אמת ומבקרים יקבלו אותו כראיה לפי A.5.22?

לוח מחוונים העומד בתקן A.5.22 צריך לעשות שתי משימות בו זמנית: לעזור לפעילות חיה לזהות בעיות במהירות, ולתת לבעלי עניין בתחום הסיכונים והביקורת ביטחון שהספקים מנוהלים באופן שיטתי. אתם מפחיתים חיכוכים כשאתם לשמור על השקפה אחת קוהרנטית במקום לוחות מחוונים נפרדים של "תפעול" ו"תאימות" שמתרחקים זה מזה.

מה שייך ללוח מחוונים של ספקים המתאים לתקן A.5.22?

עבור צוותי גיימינג ושירות חי, לוח מחוונים פרקטי כולל בדרך כלל:

A תצוגה ברמה העליונה של כל ספק ברמה הראשונה עם:
מצב נוכחי ואירועים פעילים
קבוצה ממוקדת של מדדי ביצועים (KPI/KRI) (לדוגמה, השהייה, שיעור שגיאות, הונאות, כשלים בכניסה)
דירוג סיכון כללי, תאריך סקירה אחרון וסקירה מתוכננת הבאה
תצוגות פירוט: לכל ספק, פירוט מדדים לפי:
אזור ופלטפורמה (מחשב אישי, קונסולה, נייד)
חלונות זמן סביב אירועים אחרונים או שינויים משמעותיים בספקים
השפעה על השחקנים, כגון ניתוקים, כשלים בהתאמה או זינוקים בכרטיסים
A ציר זמן של שינוי ואירוע שמסתדר:
הודעות ספקים, שינויים ב-SDK/API, ניתוב או מעבר אזורי
רישומי שינויים פנימיים, אישורים ופרטי פריסה
השפעה נצפית על משחקיות, התנהגות בחנות ותורי תמיכה

עבור ISO 27001 A.5.22, כל משבצת ספק צריכה לשמש כנקודת כניסה אל רישומי ISMSחוזים, הערכות סיכונים, סקירות ביצועים, אירועים ויומני שינויים. ISMS.online תומך בדפוס זה בכך שהוא מאפשר לך לקשר ספקים, סיכונים, בקרות ורשומות בתוך מערכת ניהול אבטחת מידע אחת. כאשר מבקר שואל "כיצד אתה מנטר וסוקר את הספק הזה?", אתה יכול להציג תחילה את לוח המחוונים, ואז לעבור ישר להחלטות המתועדות שעומדות מאחוריו.

אם התצוגה הנוכחית שלכם לגבי ספקים מפוזרת על פני כלי NOC, גיליונות אלקטרוניים ושרשורי דוא"ל, עיצוב לוח מחוונים משותף שאליו מתחבר מערכת ה-ISMS שלכם היא אחת הדרכים המהירות ביותר להעלות את האמון הן בצוותי התפעול החי והן בצוותי אבטחת מידע.

כיצד נוכל לשלב שינויים שיזמו הספקים בתהליך השינוי שלנו מבלי להאט את הגרסאות עד כדי זחילה?

שינויים ביוזמת הספק מגיעים לעתים קרובות כעדכוני סטטוס, ניוזלטרים או הערות שחרור וקל לטפל בהם באופן לא רשמי. תקן ISO 27001 A.5.22 מצפה מהם. שינויים בספקי חומרים יטופל באמצעות תהליכי ניהול השינויים והערכת הסיכונים הרגילים שלך, אך אין זה אומר בניית זרימת עבודה שנייה וכבדה יותר רק עבור ספקים.

כיצד נראה דפוס בקרת שינויים ריאליסטי של ספק?

רוב ארגוני הגיימינג וה-SaaS מצליחים עם דפוס כזה:

לכוון עדכונים במקומות בהם צוותים כבר עובדים:

הזינו הודעות ספקים, Webhooks או אימיילים למערכת הכרטיסים או ניהול השינויים הקיימת שלכם, כך שיופיעו באותו תור כמו שינויים פנימיים.

תיוג לפי ספק וסיכון:

תייגו כל פריט עם ספק, סוג שירות, סביבה ורמת סיכון כך ששינויים בעלי סיכון גבוה יותר יהיו גלויים בבירור וניתן יהיה לבחון אותם תחילה.

החל את מחזור החיים הסטנדרטי שלך:

בצע שינויי ספקים באמצעות אותם שלבים מרכזיים כמו שינויים פנימיים:

מיון השפעה ראשוני (האם זה משפיע על ייצור, אזורים, מיקומי נתונים או הסכמי רמת שירות?)
הערכת סיכונים או בדיקות במידת הצורך
אישור על ידי רשות השינוי המתאימה
פריסה מבוקרת וניטור ממוקד
סקירה קצרה לאחר היישום, המתעדת מה הלך טוב ומה לא
השתמשו באמצעי הגנה טכניים כדי להישאר מהירים ובטוחים:

שלבו אזורים קנריים, קבוצות שחקנים קטנות, דגלי תכונה ותוכניות החזרה למצב אחר מתורגלות כדי שקבוצות יוכלו לנוע במהירות ועדיין לשמור על שליטה.

מנקודת מבט של ציות לתקנות, הדרישה המרכזית היא ש שינויים משמעותיים בספקים משאירים עקבות ברוריםרישום כרטיס או שינוי, הערכת השפעה, אישורים, הערות ניטור וכל עדכון לסיכונים. אם תחברו את הרשומות הללו במערכת ניהול משולבת של ISMS או במערכת ניהול משולבת של נספח L, כגון ISMS.online, תוכלו להדגים שבקרת שינויים בספקים היא שיטתית ולא אד-הוק, בעוד שמהנדסים ועובדים ממשיכים לעבוד בתוך כלים מוכרים.

אם אתם מתייחסים כיום לשינויים בספקים כאל "מידע בלבד", זה הזמן להחליט אילו סוגי שינויים תמיד צריכים להפעיל רישום רשמי במערכת ה-ISMS שלכם, כך שמהירות השחרור ורמת הביקורת יישארו תואמים.

כיצד עלינו ליישר קו בין חוזים ותחומי אחריות משותפים כך ש-A.5.22 יעבוד באופן יומיומי בעסקי משחקים?

עבור ספקים גדולים כגון ענן, CDN, זהות ותשלומים, חוזים ומודלים של אחריות משותפת הם המנופים העיקריים שלכם. תקן ISO 27001 A.5.22 מצפה מכם להשתמש במנופים אלה באופן מכוון ולתמוך בהם באמצעות בעלות פנימית ברורה, ולא רק בתיאורי שירות ברמה גבוהה.

מה צריכים לכסות חוזים, ומה חייב להיות לצוותים שלכם?

עבור ספקים קריטיים או בעלי סיכון גבוה, בדרך כלל כדאי לוודא שהחוזים כוללים:

הודעות שינוי:

תקופות הודעה וערוצי תקשורת עבור שינויים באזורים, מיקומי נתונים, מעבדי משנה, ממשקי API/SDK או התנהגות שירות ליבה.

תמיכה סביב פעילויות בסיכון גבוה:

שיתוף פעולה בבדיקות, החזרה למצב אחר ותקשורת במהלך הגירות, אירועים גדולים בשידור חי או הקלות אבטחה.

גישה למידע:

יומנים, דוחות ואנשי קשר בעלי שם הנחוצים לך כדי לחקור בעיות ביצועים או אירועי אבטחה פוטנציאליים.

תקני אבטחה והמשכיות מינימליים:

ציפיות להצפנה, חלונות דיווח על אירועים, אישורים, אחסון נתונים, התחייבויות להמשכיות עסקית ודרישות קבלני משנה בהתאם למערכת ה-ISMS שלכם.

באופן פנימי, אתה צריך לפחות תמציתי מטריצת אחריות שקובע:

למי שייך כל ספק מבחינה מסחרית ותפעולית.
מי מנטר את ביצועי השירות, האבטחה והתאימות, ובאמצעות אילו לוחות מחוונים או דוחות.
מי מורשה לקבל, להפחית או להימנע מסיכון הקשור לספקים, וכיצד החלטות אלו נרשמות ונבדקות מחדש.

כאשר אתם שומרים יחד חוזים, רשימות אחריות, הערכות סיכונים ותוצרי סקירות במערכת ה-ISMS או במערכת הניהול המשולבת שלכם, קל הרבה יותר להראות שפיקוח על הספקים הוא יעיל מכוון, עקבי וניתן להרחבה בין אזורים ותאריםISMS.online נועד לאחסן ולקשר את הממצאים הללו במקום אחד, כך שמבקרים, שותפים ובעלי עניין פנימיים יוכלו לראות שמודל האחריות המשותפת שלכם מיושם ולא משתמע.

אם אחריות הספקים עדיין ממוקמת בעיקר בכותרות ובדפי שקופיות, הקדשת זמן לתיעודן במערכת ה-ISMS שלכם היא אחד הצעדים בעלי המינוף הגבוה ביותר שתוכלו לנקוט לפני הגרסה או הביקורת הגדולות הבאות שלכם.

כיצד מערכת ניהול מידע (ISMS) כמו ISMS.online יכולה להפוך את ISO 27001 A.5.22 להרגלים יומיומיים במקום פרויקט ביקורת שנתי?

לארגונים רבים יש מדיניות ספקים שנראית משכנעת במדריך, אך היא מופשטת מדי מכדי שניתן יהיה לעקוב אחריה תחת לחץ מהעולם האמיתי, הן בתחומי התפעול, ההנדסה, הרכש והמשפט. מערכת ניהול אבטחת מידע הופכת את A.5.22 למוחשי על ידי הפיכת ציפיות ל... שגרות פשוטות ונראות לעין שמתאימות לאופן שבו הצוותים שלכם כבר עובדים.

כיצד נראה יישום מעשי של A.5.22 בתוך ISMS או IMS?

בתוך מערכת ניהול משולבת מודרנית מסוג ISMS או נספח L, בדרך כלל היית:

בנה רישום ספקי מגורים

רשום את תפקידו של כל ספק, את הנתונים שעובדו, את רמת הקריטיות שלו, דירוג הסיכון והבקרות הממופות שלו, ולאחר מכן עדכן אותו ככל שהשירותים מתפתחים.

קישור ספקים ל סיכונים, אירועים ורישומי שינויים

כך שתוכלו לעקוב אחר נתיב שלם, החל מבעיה או תלונה במשחקיות, דרך תקרית עם הספק, ועד לפעולות מתקנות והחלטות סיכון מעודכנות.

הגדרה ותזמון סקירות ביצועי ספקים וסיכונים

עם סדר יום ברור, מדדים מוסכמים ומשתתפים בעלי שם, צירוף פרוטוקולים, החלטות ומעקב אחר פעולות כראיות.

מסמך טריגרים לשינוי וזרימות עבודה

כך ששינויים מונעי-ספקים נכנסים באופן עקבי לאותם תהליכי שינוי ואירועים שהצוותים שלכם כבר סומכים עליהם לעבודה פנימית.

שימוש חוזר במבנים על פני סטנדרטים שונים מערכת ניהול משולבת

אם אתם עובדים גם עם ISO 9001, ISO 22301 או תקני נספח L אחרים, התאמו את ההקשר, המנהיגות, התכנון, התפעול והשיפור כך שניהול הספקים ירגיש כמו מערכת קוהרנטית אחת ולא כמו תוספת אבטחה.

דרך מעשית להתחיל היא למדל שירות חשוב אחד - לדוגמה, הענן הראשי או ערימת התשלומים שלך - וקומץ ספקים מרכזיים בתוך ISMS.online, ולאחר מכן להציג מחדש אירוע חי או שינוי מורכב אחרון דרך מודל זה. תרגיל זה בדרך כלל חושף פערים בבעלות, רשומות חסרות והחלטות לא עקביות באופן שבו ההנהלה יכולה לפעול לפיו. משם ניתן להרחיב את הדפוס על פני ספקים, אזורים ומוצרים נוספים, באמצעות אבני דרך גלויות - כל הספקים ברמה הראשונה רשומים, בדיקת קצב חי, מעקב אחר שינויים במקום - כדי להראות שהארגון שלך... הידוק בקרת הספקים, חיזוק החוסן והבשלת מערכת ה-ISMS שלה.

אם אתם רוצים שהסטודיו או הפלטפורמה שלכם יוכרו ככאלו שמתייחסים לסיכון הספק כחלק מחוויית השחקן ומהמשכיות העסקית ולא רק לפרטי רכש, הטמעת A.5.22 בכלים ושגרות יומיומיות באמצעות פלטפורמה כמו ISMS.online היא דרך אמינה להדגים מנהיגות בביקורות, מכרזים ושיחות עם שותפים כאחד.

ISO 27001 A.5.22 – ניטור שינויים בענן, CDN וספקים המשפיעים על פלטפורמות משחקים