מנקודת מבט של הנהלה, CFO, יועץ משפטי ומנהל סיכונים, השאלה כבר איננה רק “האם תהיה פריצה”, אלא “מה יקרה להכנסות, לתזרים, להתחייבויות השירות ולמוניטין אם מערכות Mission-Critical Systems ייפלו”. ה־World Economic Forum מציין שבשנים האחרונות יותר ויותר שחקני תקיפה פועלים במובהק לשם business disruption, בעוד ש־NIST מגדיר Recover ו־Operational Resilience כחלק ישיר מניהול סיכוני הסייבר והחזרת השירותים והיכולות התפעוליות לאחר אירוע.

למה זה כבר לא רק עניין של אבטחת מידע

בפועל, אירוע סייבר חדל להיות “בעיה של ה־IT”. הוא עלול להפוך בתוך שעות לבעיה של EBITDA, של עמידה ב־SLA, של עיכוב בפרויקטים, של הפרת התחייבויות ללקוחות ושל מחלוקת חוזית עם ספקים. בנק אנגליה מגדיר important business services כשירותים שהשבתתם עלולה לפגוע בלקוחות, ביציבות הפירמה ובמערכת כולה, והדגש הרגולטורי עובר ליכולת להישאר בתוך impact tolerance גם תחת שיבוש חמור אך סביר.

המסר המרכזי לבעלי עסקים ולברוקרים

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

מהו Cyber Business Interruption

Cyber Business Interruption הוא כיסוי First-Party בפוליסת ביטוח סייבר לחברות או ביטוח סייבר לעסקים, שנועד לפצות על אובדן הכנסות בסייבר, הוצאות תפעול שוטפות והוצאות עודפות שנגרמו עקב הפרעה ממשית לפעילות העסקית לאחר אירוע סייבר או System Failure, והכול בכפוף ללשון הפוליסה, ל־schedule, ל־endorsements, לתקופת ההמתנה ולתקרות האחריות. בנוסחים שונים בשוק, business interruption loss מוגדר כהפסד הכנסה ולעיתים גם extra expense ו־forensic expenses, שנגרמים בתקופת ה־period of restoration עקב הפרעה ממשית לפעילות העסק.

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

Direct Business Interruption מול Dependent Business Interruption

הכיסוי יכול להיות ישיר – כאשר המערכות של המבוטח עצמו אינן זמינות – או עקיף, כ־Dependent Business Interruption, כאשר ההשבתה נובעת מכשל אצל צד שלישי שעליו העסק תלוי, כמו ספק SaaS, ספק IT מנוהל, ספק אירוח, פלטפורמת תשלומים או ספק ענן. Chubb מציין במפורש כי contingent או dependent business interruption מוסיף הפסדים שנגרמו עקב הפרעה במערכות של ספק טכנולוגיה חיצוני, ובנוסחי שוק אחרים מוגדר dependent business loss כהפסד הכנסה ו־extra expense שנגרמו בשל dependent security breach או dependent system failure אצל ספק קשור.

לא רק מתקפת האקר

חשוב במיוחד להבין ש־Cyber BI מודרני איננו מוגבל בהכרח רק לאירוע זדוני קלאסי. חלק מהשוק מציע הרחבות ל־system failure, ל־human or administrative error או ל־internal errors and omissions, בעוד שנוסחים אחרים מגבילים את הטריגר לאירוע זדוני מסוים, כגון מתקפת DDoS או ransomware. AIG מציין שהרחבת System Failure Cover חלה רק אם נרכשה; Lloyd’s מדגיש שקיימים הבדלים מהותיים בין פוליסות, וחלקן מציעות טריגרים מורחבים כגון system failure או administrative errors.

למה Cyber BI שונה מביטוח השבתה עסקית מסורתי

הבדל היסוד בין Business Interruption Insurance מסורתי לבין Cyber Business Interruption הוא הטריגר. הכיסוי המסורתי תחת פוליסות רכוש נבנה בדרך כלל סביב נזק פיזי מבוטח לרכוש: שריפה, סופה, נזק מים, ונדליזם וכדומה. Travelers מתאר ש־Business Income Coverage בפוליסות רכוש מתחיל כאשר נזק מכוסה מונע מהעסק לפעול, ותקופת הכיסוי נמשכת לאורך period of restoration עד שהרכוש תוקן, נבנה מחדש או הוחלף. גם IRMI מבהיר ש־direct damage הוא נזק פיזי לרכוש, וש־contingent business interruption המסורתי נוטה להיות מופעל כתוצאה מנזק פיזי לרכוש של ספקים או לקוחות מרכזיים.

לעומת זאת, Cyber BI בא לענות על מצב אחר לגמרי: העסק הושבת בגלל כשל במערכות מידע, נגישות לנתונים, פגיעה באפליקציות תפעוליות, או נפילה של ספק שירות דיגיטלי — גם כאשר אין שום נזק פיזי לבניין או למכונה. Munich Re מציג זאת באופן חד: אם מתקפת סייבר גורמת להשבתת אינטרנט, business interruption without physical damage של סוחר מקוון “לא אמורה להיות מכוסה תחת פוליסת רכוש”, ולכן נדרש טיפול ביטוחי מסוג אחר.

הטריגר שונה וגם אופן המדידה שונה

ב־BI מסורתי מוקד הדיון הוא זמני תיקון הרכוש הפיזי. ב־Cyber BI מוקד הדיון הוא שחזור, ייצוב ואימות של מערכות ונתונים: האם הגיבויים תקינים, האם הגרסאות נקיות, האם ניתן להעלות מחדש שירותים קריטיים, האם יש סביבת failover, מהו קצב החזרה של תהליכים עסקיים, והאם אובדן הנתונים מחייב Data Restoration בלבד או גם Data Recreation. NIST מדגיש שבתהליך ההתאוששות יש לוודא את שלמות הגיבויים, לשחזר מערכות ושירותים, ולאשר חזרה למצב תפעולי תקין.

מבחינת CFO ויועץ משפטי זהו סיכון הכנסות ולא רק סיכון טכנולוגי

ברגע שהמערכות מושבתות, הבעיה איננה רק טכנית. היא הופכת במהירות לשאלה של פספוס מכירות, דחיית הכנסות, הוצאות עודפות, SLA credits, תביעות אפשריות של לקוחות ותיעוד הפסד לצורך תביעה ביטוחית. Travelers מזהיר שספקי טכנולוגיה עלולים להיחשף גם לתביעות לקוחות על נזקי business loss עקב שיבושי מערכת, ו־Marsh מדגיש שסיכון סייבר מייצר במקביל השלכות First-Party ו־Third-Party.

אילו מערכות ואירועים דיגיטליים עלולים לעצור עסק

המערכות שבאמת מחזיקות את הפעילות

כמעט כל עסק מפעיל היום כמה שכבות של Mission-Critical Systems: ERP, CRM, דואר אלקטרוני, סביבת Cloud, מערכות תשלום, מערכות הזמנות (Booking Systems), פלטפורמות לוגיסטיקה, מערכות ייצור, ופלטפורמות SaaS. NIST מציין שגם מערכות ERP, MRP ו־MES הן מערכות IT מהותיות בעלות כלי התאוששות ייעודיים, וכן שבאירועי OT יש להביא בחשבון תלות של מערכות תפעוליות ביישומי IT עסקיים, כך שפגיעה ברשת ה־IT עלולה להביא לניתוק או השבתה של סביבת ה־OT והייצור. במקביל, Marsh מתאר מציאות עסקית שבה מערכות דיגיטליות, תשלומים מקוונים, מיילים, booking systems ורשומות עסקיות הפכו לחלק בלתי נפרד מהשגרה התפעולית.

Digital Dependency ושרשרת האספקה הדיגיטלית

התלות איננה רק פנימית. NIST מגדיר את Cybersecurity Supply Chain Risk Management כתהליך שיטתי לניהול חשיפה לסיכוני סייבר לאורך שרשרת האספקה, ומדגיש כי האקו־סיסטם כולל גם business partners ו־data and digital service providers. נוסף על כך, NIST ממליץ לכלול ספקים קריטיים בתוך תכנון ה־contingency, ה־incident response וה־disaster recovery. Lloyd’s מזהיר כי ריכוזיות של שירותי ענן יוצרת גם סיכון מערכתי: השבתה ממושכת של ספק ענן מוביל עלולה לייצר נזק סימולטני ללקוחות ולתלויים בו.

איך אירועים שונים הופכים להשבתה עסקית

Ransomware הוא הדוגמה הקלאסית, אך לא היחידה. CISA מזכיר שאירועי כופרה ממשיכים להשבית ארגונים, לסגור מחוזות חינוך, לנטרל תקשורת חירום ולכפות עיכובים על בתי חולים; Chubb מציג תרחישים שבהם חדירת ransomware גרמה לשיבוש תפעולי של יותר משישה חודשים ולשילוב של Data and System Recovery, Business Interruption, הוצאות תגובה ו־cyber extortion.

גם DDoS יכול לייצר System Outage מהיר מאוד: CISA מגדיר DDoS כמצב שבו תוקפים מציפים שרת ציבורי בבקשות עד שהוא הופך לאיטי או לא זמין, ו־Coalition מציין מפורשות תרחיש שבו מתקפת denial of service משביתה אתר וגורמת לאובדן הכנסה ול־extra expenses. Lloyd’s מוסיף שבכיסוי רגיל, ללא הרחבות מותאמות, הטריגר עשוי להישאר מוגבל יותר לאקטים זדוניים, בעוד שפוליסות אחרות כבר מכירות גם ב־system failure ו־administrative errors.

ולבסוף, לא כל השבתה היא “פריצה”. כשל ספק, עדכון שגוי, טעות אנוש או מתקפת supply chain עלולים להשבית אלפי ארגונים במקביל. ביולי 2024 עדכון פגום של CrowdStrike השפיע על 8.5 מיליון מכשירי Windows ברחבי העולם, ומיקרוסופט הדגישה שההשלכות הכלכליות והחברתיות הרחבות נבעו מהעובדה שהמערכות שנפגעו שירתו שירותים קריטיים רבים. CrowdStrike עצמה קבעה בניתוח השורש כי mismatch טכני בעדכון הוביל לקריסות מערכת. זהו בדיוק סוג האירוע שממחיש מדוע Cyber BI רלוונטי גם כאשר אין נזק פיזי ואין אפילו בהכרח “האקר” בצד השני של האירוע.

טבלת חשיפה, השפעה עסקית וחיתום

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

אילו נזקים כלכליים נוצרים ומה באמת מכוסה

מפת הנזק הכספי לאחר אירוע Cyber BI

כאשר מתרחש אירוע השבתת מערכות מחשוב, הנזק הכלכלי כמעט אף פעם אינו מסתכם ב”כמה שעות של חוסר זמינות”. בדרך כלל נוצרים במקביל כמה רבדים של הפסד: אובדן הכנסות בסייבר, הוצאות עודפות כדי להמשיך לעבוד, שעות נוספות, התקשרות עם ספקים חלופיים, עלויות שחזור מידע, עלויות יצירה מחדש של מידע שלא ניתן לשחזר, עיכוב בהשלמת פרויקטים, ולעיתים גם פגיעה במוניטין ובאמון הלקוחות. חלק מהפוליסות מגדירות business interruption loss כהפסד הכנסה בתוספת extra expense או forensic expenses, ואחרות מוסיפות כיסויי data recovery או digital data recovery כרכיב נפרד.

חשוב להבחין גם בין First-Party לבין Third-Party. Cyber BI מטפל בנזק הישיר לעסק המבוטח עצמו; הוא איננו מחליף כיסוי אחריות מקצועית, כיסוי privacy and network security liability או E&O כלפי לקוחות שניזוקו מההשבתה. במציאות, אירוע אחד יכול לייצר בו־זמנית גם אובדן רווח פנימי וגם תביעות או דרישות מצד לקוחות, רגולטורים או בעלי חוזה.

ההבדל בין System Damage, Data Restoration, Data Recreation, Business Interruption ו־Increased Cost of Working

System Damage מתאר את הפגיעה במערכת עצמה או בנכסים הדיגיטליים: תוכנה, חומרה, קבצים או רכיבים בלתי תפקודיים. בחלק מהשוק זה מופיע כ־digital asset damage או hardware replacement, ובחלק אחר ככיסוי נפרד לנזקי נתונים ומערכות. זה לא אותו דבר כמו אובדן הכנסות; זהו רכיב “הנזק לנכס הדיגיטלי” עצמו.

Data Restoration הוא שחזור הנתונים ממקורות קיימים – בדרך כלל מגיבויים, duplicates או assets שנשמרו בצורה אמינה. AIG מתאר כיסוי לעלויות restore electronic data from duplicates, ו־NIST מדגיש שבתהליך ההתאוששות חייבים לוודא את שלמות הגיבויים ואת נכונות נכסי השחזור לפני השימוש בהם.

Data Recreation הוא שלב יקר בהרבה: אם לא ניתן לשחזר נתונים קיימים, יש צורך לאסוף אותם מחדש, להרכיבם מחדש, להזינם ידנית או ל־recollect them from source records. AIG מדבר על עלויות “research, gather, and assemble electronic data”, ו־Marsh משתמש במונחים “recreate, restore, or recollect”. זהו הבדל קריטי ללקוח, משום ששחזור מגיבוי וסידור מחדש של נתונים אבודים הם שני עולמות כלכליים שונים.

Business Interruption הוא רכיב אובדן ההכנסה וההוצאות השוטפות שנמשכות בזמן שהעסק אינו יכול לפעול בהיקפו הרגיל. בנוסחי שוק הוא קשור ל־period of restoration ולרוב מחייב actual interruption של הפעילות העסקית.

Increased Cost of Working או Extra Expense הוא ההיפך מהפסד פסיבי: זהו כסף שהעסק מוציא באופן אקטיבי כדי לשמור על פעילות, להפחית את ירידת ההכנסות ולקצר את משך ההשבתה. AIG מגדיר זאת כהוצאות, לרבות overtime של עובדים, מעבר להוצאות התפעול הרגילות, כדי להמשיך את העסקים הרגילים ולצמצם אובדן הכנסה. Travelers מסביר ש־Extra Expense כולל הוצאות סבירות והכרחיות שנועדו להקטין את הזמן שבו העסק אינו מסוגל לפעול.

מה לא נכון להניח אוטומטית

לא נכון להניח שכל פגיעה במוניטין, כל עיכוב בפרויקט, כל קנס חוזי או כל אובדן לקוח מכוסים אוטומטית תחת Cyber Business Interruption. חלק מהנוסחים מוציאים loss of market, consequential loss, dependent business loss שאינו נרכש, או הוצאות משפטיות שאינן חלק מהכיסוי הספציפי. גם data recovery costs ו־business interruption loss עשויים להיות מסווגים כרכיבים נפרדים עם תנאים ומגבלות שונים.

מה חשוב לבדוק בפוליסת סייבר

Waiting Period, Period of Restoration ו־Sublimits

שלושת המונחים החשובים ביותר בבדיקת סעיף Cyber BI הם Waiting Period, Period of Restoration ו־Sublimits. Waiting Period הוא פרק הזמן הראשוני שבו אין כיסוי, או שבו הכיסוי מתחיל רק לאחר חלוף מספר שעות מוגדר; Coalition מדגיש שכיסוי business interruption כפוף לתקופת המתנה ייעודית, ו־Lloyd’s מציין שבשוק נראים לא פעם פרקי המתנה של שמונה עד שתים־עשרה שעות. Period of Restoration הוא החלון שבו ההפסד נמדד, ובפוליסות סייבר הוא קשור לרוב להשבת השירותים, הנתונים והיכולות התפעוליות – לא בהכרח לשיפוץ קירות או החלפת מכונות. Sublimits הם תקרות משנה, ולעיתים דווקא רכיבי cloud outage, dependent BI או data recreation כפופים לתקרות נמוכות יותר מהגבול הראשי.

עבור לקוח עסקי, זהו הבדל קריטי. אם ה־Waiting Period הוא 12 שעות, אבל רוב האירועים שלו קצרים מ־12 שעות, ייתכן שנרכש כיסוי שלא באמת פוגש את פרופיל הסיכון. אם ה־Sublimit על Dependent Business Interruption נמוך, אבל כל המכירות תלויות בענן או בפלטפורמת תשלום חיצונית, נוצר פער ביטוחי מהותי. Lloyd’s מדגיש שחלק מהפוליסות אף מחריגות dependent BI לחלוטין, אחרות קובעות sublimit, ואחרות בלבד מציעות full limit.

Dependent BI, System Failure, Cloud Service Provider, Data Recreation ו־Claims Preparation Costs

ברמת בדיקת הנוסח, ברוקר חייב לוודא במפורש אם הכיסוי כולל Dependent Business Interruption, אם קיימת הרחבה ל־System Failure, כיצד מוגדר Cloud Service Provider, האם קיימת תגובה ל־human or administrative error, האם Data Recreation מכוסה במלואה או רק Data Restoration, והאם יש כיסוי ל־Claims Preparation Costs או Loss Preparation Costs. AIG מתאר כיסוי ל־Loss Preparation Costs עבור שירותי forensic accounting לצורך ביסוס והוכחת ה־network loss או ה־network interruption costs; Beazley קובע שהפוליסה יכולה לכסות הוצאות סבירות של צד שלישי להכנת proof of loss ל־data recovery, business interruption ו־dependent business loss.

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

זווית משפטית וענפים חשופים

הזווית המשפטית והחוזית

מבחינה משפטית, אירוע Cyber BI יושב על צומת בין דיני חוזים, אחריות מקצועית, פרטיות, רגולציה וניהול סיכונים תאגידי. אם עסק מתחייב ל־SLA מול לקוחותיו – זמינות, זמני תגובה, זמני התאוששות, שלמות נתונים או שירות רציף – System Outage עלול להפוך מהר מאוד לויכוח חוזי, להענקת credits, לזכות ביטול, או אפילו לתביעת נזקים. הרגולטורים הולכים בכיוון דומה: DORA, החל מינואר 2025 עבור גופים פיננסיים באירופה, מחייב ICT risk management, ניהול סיכון צדדים שלישיים ו־key contractual provisions; NIS2 מחייב אמצעי ניהול סיכונים הכוללים incident handling, business continuity, backup management, disaster recovery, crisis management ו־supply chain security.

גם רגולטורים פיננסיים בבריטניה דורשים מהפירמות לזהות important business services, לקבוע impact tolerances, ולבצע scenario testing תחת severe but plausible disruption. המשמעות הפרקטית היא שכבר לא מספיק לשאול “האם יש firewall”, אלא צריך לשאול “כמה זמן אפשר להיות בלי המערכת הזאת לפני שנגרם נזק בלתי נסבל ללקוחות או לפעילות”.

חוזי ענן, SLA ומגבלות אחריות של ספקי IT

במישור החוזי מול ספקים, אחת הטעויות הנפוצות היא להניח ש־SLA של ספק ענן או ספק IT יממן את אובדן ההכנסות בפועל. בפועל, הדוגמאות של AWS ו־Azure מלמדות אחרת: AWS קובע ב־SLA של EC2 ש־service credits הם ה־sole and exclusive remedy בגין unavailability, וב־Customer Agreement הוא מוציא מאחריות loss of profits, revenues, goodwill ו־unavailability of services ומגביל את האחריות המצטברת לסכומים ששולמו ב־12 החודשים שקדמו לאירוע; Azure קובע שהתרופה היחידה להפרת SLA היא זו שמופיעה ב־SLA, ובהסכם המנוי מגביל אחריות לנזקים ישירים בלבד עד לגובה הסכומים ששולמו, תוך החרגה מפורשת של lost revenue, lost profits, business interruption ו־loss of business information. במילים אחרות, וכהסקה חוזית מתבקשת, ברוב המקרים הסכם הספק אינו תחליף ל־Cyber Business Interruption אלא לכל היותר שכבת פיצוי מצומצמת בהרבה.

מהצד השני, אם אתם ספק טכנולוגיה, SaaS או שירות דיגיטלי, גם הלקוחות שלכם יכולים לטעון לנזק עסקי כתוצאה מהשבתת השירות. Travelers מציין במפורש ש־software upgrades שגורמים לשיבושי מערכת בלתי צפויים עלולים לגרום lost business ללקוחות ולתביעות בגין נזקים. לכן, ללקוחות רבים נדרשים במקביל גם Cyber BI וגם שכבות אחריות כגון E&O או Network Security Liability.

ענפים חשופים במיוחד

ענפי SaaS ו־technology הם חשופים מטבעם משום שהמוצר עצמו הוא השירות הדיגיטלי. Marsh מציין כי אצל חברות טכנולוגיה מערכות, טכנולוגיה ונתונים הם רכיבים יסודיים של הפעילות, וכי יש לבצע cyber risk assessment מתוך הבנה כיצד הטכנולוגיה תומכת ב־core operations. הסיכון מתאים גם למודלים מבוססי subscription, שבהם downtime פוגע ישירות בהכנסה החוזרת.

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

eCommerce, קמעונאות ומלונאות תלויים במערכות סליקה, הזמנות, אתרי מסחר, inventory, personalization ותהליכי fulfilment. Marsh מדגיש ש־omni-channel retail, online channels ו־contactless payment systems הפכו לחלק מהותי מהסביבה הקמעונאית; Chubb מציג תרחיש של hotelier שנפגע מפריצה לרשת; ו־Coalition נותן דוגמה ישירה להשבתת ספק SaaS או אתר בעקבות תקיפת DDoS.

קליניקות, מרפאות ומוסדות בריאות חשופים לא רק משום שיש בהם מידע רגיש, אלא משום שהשבתה פוגעת גם בשירות עצמו. Marsh מגדיר business interruptions ודלף מידע כלקוחות איום מרכזי בתחום הבריאות. לוגיסטיקה, ייצור ו־OT חשופים משום שאירוע IT עלול לגרור ניתוק או shutdown של פעילות תפעולית, כפי ש־NIST מציין. שירותים מקצועיים כמו משרדי עורכי דין, ראיית חשבון, ייעוץ וסוכנויות פרסום חשופים משום שהמוצר שלהם תלוי בגישה למידע, לקבצים, לדוא"ל, לפלטפורמות עבודה וליכולת לעמוד בדדליינים של לקוחות. Chubb מציג תרחישים בענפי logistics, law firms, manufacturing ו־assisted living שממחישים בדיוק את הפגיעה העסקית הזו.

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

לכן, דיון מקצועי ב־ביטוח סייבר חייב לכלול לא רק פרטיות וכופרה, אלא גם את היכולת של הארגון לשרוד Business Interruption, לממן Data Restoration ו־Data Recreation, לשאת ב־Increased Cost of Working, ולהמשיך לפעול בתוך מגבלות רגולטוריות וחוזיות. הכיסוי הנכון נקבע רק לאחר בדיקה ספציפית של הטריגרים, ההרחבות, תקופות ההמתנה, תתי־הגבול והתלות בצדדים שלישיים.

שאלות שברוקר צריך לשאול לקוח כדי להבין חשיפת Cyber BI

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

אילו מערכות הן mission-critical לעסק, ומה השפעת downtime של כל אחת מהן?

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

מהו Recovery Time Objective האמיתי לכל מערכת, ולא מה שכתוב במדיניות?

פער בין RTO מוצהר לבין RTO תפעולי בפועל הוא בסיס קלאסי לחסר ביטוחי ולתמחור שגוי.

האם קיימים BCP, DRP ו־IRP, והאם הם נבדקים באופן קבוע?

שאלון החיתום של Chubb שואל במפורש אם קיימים Business Continuity Plan, Disaster Recovery Plan ו־Incident Response Plan, ואם הם tested regularly.

איך נראים הגיבויים של הנתונים ושל המערכות הקריטיות?

חייבים לבדוק תדירות גיבוי, recoverability, integrity, immutability, WORM, air-gap ו־MFA על הגישה לגיבויים.

האם יש failover, סביבה חלופית או alternative provider למערכות קריטיות?

זו אחת השאלות המשפיעות ביותר על severity של Cyber BI. שאלון Chubb בודק automatic failover, manual failover, offline alternative environment ו־alternative provider.

עד כמה ההכנסות תלויות בספקי צד שלישי – ענן, סליקה, SaaS, MSP או לוגיסטיקה?

NIST ו־Lloyd’s מדגישים כי צדדים שלישיים דיגיטליים הם חלק אינטגרלי משרשרת האספקה וכי ענן עלול להיות single point of failure.

האם קיימים SLA והתחייבויות חוזיות כלפי לקוחות שעלולות להיפגע בזמן outage?

זו שאלה שמחברת בין First-Party loss לבין חשיפה חוזית ו־E&O.

האם הפוליסה כוללת system failure ו־dependent business interruption, או רק malicious acts?

זו שאלה מהותית משום שהשוק איננו אחיד בנקודה הזו.

האם הלקוח ויתר בחוזים על זכות חזרה כלפי ספקים במקרה service disruption?

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

האם הארגון מסוגל להוכיח הפסד BI מבחינה חשבונאית ונתונית?

Marsh בונה שירותים ייעודיים ל־Cyber BI Quantification, ו־AIG/Beazley מתייחסים ל־loss preparation costs / proof of loss – סימן לכך שהוכחת ההפסד היא מרכיב מרכזי בניהול התביעה.

שאלות נפוצות

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

בדרך כלל, לא באופן שניתן להניח מראש. פוליסות BI מסורתיות נבנו סביב נזק פיזי לרכוש, בעוד ש־ransomware יוצר פעמים רבות השבתה בלי נזק פיזי. לכן, דווקא ביטוח סייבר עם סעיף Cyber Business Interruption הוא המסלול הרלוונטי יותר, בכפוף לנוסח הפוליסה.

האם כל Cloud Outage מכוסה?

לא. חלק מהפוליסות כוללות Dependent Business Interruption או הרחבת Cloud Service Provider, אחרות מגבילות, מסבלימות או אפילו מחריגות cloud/provider outages.

האם כל השבתת מערכות מחשוב מפעילה כיסוי?

לא. הכיסוי תלוי בטריגר שנרכש, במשך ההשבתה, ב־Waiting Period, בהגדרה של interruption ובשאלה אם מדובר ב־security breach, system failure, human error או אירוע אצל ספק תלוי.

מהו Waiting Period?

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

מהו Period of Restoration?

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

מה ההבדל בין Data Restoration ל־Data Recreation?

Data Restoration הוא שחזור נתונים מגיבויים או duplicate data; Data Recreation הוא בנייה מחדש של נתונים שלא ניתן לשחזר, באמצעות איסוף, הרכבה או הזנה מחודשת. ההבדל הזה משפיע ישירות על גודל הנזק ועל adequacy של הכיסוי.

האם שעות נוספות, עבודה ידנית וספקים חלופיים נכנסים לכיסוי?

לעיתים כן, במסגרת Extra Expense או Increased Cost of Working, אם ההוצאה נועדה להמשיך את הפעילות או להקטין את הפסד ההכנסה, ואם לשון הפוליסה מאפשרת זאת.

האם SLA של ספק ענן מספיק במקום ביטוח?

בדרך כלל לא. AWS ו־Azure מגבילים את התרופות ל־service credits או לנזקים ישירים מוגבלים, ומחריגים במפורש lost profits, lost revenue ו־business interruption. לכן, מבחינה עסקית, SLA לבדו אינו מחליף Cyber BI.

האם עסקים שאינם “חברות טכנולוגיה” צריכים Cyber BI?

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

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

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