בישראל של 2026, שבה היקף אירועי הסייבר שדווחו קפץ משמעותית ושבה גם עסקים קטנים ובינוניים נמצאים על הכוונת, BCP הוא מסמך הנהלה, תפעול, משפט וביטוח – לא רק מסמך תשתיות.
מהי תכנית המשכיות עסקית ומה ההבדל בינה לבין DRP ו־IRP
BCP הוא המסמך שמתאר איך החברה ממשיכה להפעיל או לחדש במהירות תהליכים עסקיים חיוניים במהלך שיבוש ואחריו. לפי NIST, BCP מתמקד בהמשך תהליכים עסקיים במהלך התאוששות משיבוש משמעותי. DRP, לעומת זאת, מתמקד בהעברת פעילות מערכות מידע למיקום חלופי ובהחזרת תפעול מערכתי לאחר שיבוש גדול וארוך טווח. IRP עוסק בזיהוי, בידוד, תיקון והתאוששות מאירוע סייבר – כלומר באירוע האבטחה עצמו.
במילים פשוטות:
BCP שואל איך העסק ממשיך לתפקד.
DRP שואל איך המערכות חוזרות לחיים.
IRP שואל איך עוצרים ומנהלים את האירוע.
בחברת SaaS טובה שלושת המסמכים עובדים יחד. כש־IRP מפעיל containment וחקירה, DRP צריך לאפשר Failover או Rebuild, ו־BCP צריך להגדיר אילו שירותים, לקוחות ותהליכים מקבלים קדימות עסקית, אילו הודעות יוצאות ללקוחות, ומהו סף ההסלמה להנהלה ולדירקטוריון.
איך מגדירים RTO, RPO ו־SLA בלי ליפול לשפה כללית
RTO הוא הזמן המרבי שבו שירות או רכיב יכולים להיות מושבתים לפני שהפגיעה העסקית נהיית בלתי קבילה. RPO הוא נקודת הזמן שאליה צריך להיות אפשר לשחזר נתונים לאחר האירוע, כלומר כמה איבוד נתונים העסק יכול לסבול. NIST מחדד ש־RTO ו־RPO נגזרים מ־Business Impact Analysis, לא מהעדפות ארכיטקטורה בלבד. בנוסף, RTO בדרך כלל צריך להיות קצר יותר ממגבלת השיבוש המקסימלית שהעסק מוכן לשאת.
SLA הוא ההסכמה החוזית על רמת השירות: זמינות, זמני תגובה, חלונות תחזוקה, קרדיטים, חובות דיווח ולעיתים גם דרישות DR. לכן הטעות הקלאסית היא לנסח SLA של 99.9% זמינות בלי לחבר אותו ל־RTO פנימי, ל־RPO, ל־Maintenance Windows, ולשאלה מי נותן גושפנקה עסקית לכל חריגה. אם ה־SLA ללקוח מחמיר יותר מהיכולות האמיתיות של ה־DR, החברה יוצרת לעצמה סיכון חוזי ידוע מראש.
| רכיב | מה הוא כולל בפועל | למה זה קריטי |
| BIA | דירוג שירותים, לקוחות, זרמי הכנסה, תהליכים ותלויות | בלעדיו אי אפשר להצדיק RTO/RPO או סדרי עדיפויות. |
| Service Catalog קריטי | אילו מוצרים או מודולים חייבים לחזור קודם | מונע “שיקום רוחבי” לא יעיל. |
| RTO/RPO לכל שירות | יעד זמן חזרה ויעד שחזור נתונים לכל שכבה | הופך את ה־BCP למדיד. |
| תלויות ענן וספקים | Region, DNS, IdP, CI/CD, observability, support tools | רוב כשלי ה־SaaS הם תלויי ecosystem. |
| IR Playbooks | סייבר, דליפת מידע, כשל ספק, כשל deploy, insider, outage | מקצר זמן החלטה ומקטין chaos. |
| DR Architecture | failover, restore, backup immutability, alternate processing | מחבר בין נייר למציאות. |
| Crisis Communications | לקוחות, עובדים, משקיעים, רגולטורים, תקשורת | שיבוש בלי תקשורת מגדיל נזק. |
| Governance | Incident Commander, הנהלה, legal, security, product, support | מונע צווארי בקבוק של אישור. |
| Contract Map | SLA, notice periods, security addenda, data processing | מחבר תפעול לחבות חוזית. |
| TT&E | tabletop, restore drills, failover drills, lessons learned | מסמך שלא נבחן אינו תכנית חיה. |
תלות בספק ענן אינה רק עניין טכני
חברת SaaS כמעט תמיד תלויה בענן ציבורי, אבל הסיכון האמיתי אינו רק “הספק ייפול”. הסיכון הוא ריכוז: Region יחיד, בסיס נתונים יחיד, identity provider יחיד, pipeline יחיד, מערכת ticketing יחידה, או vendor יחיד שמחזיק פונקציה קריטית ל־support או לתפעול. תקלת AWS גלובלית באוקטובר 2025 המחישה עד כמה כשל בשירות מרכזי יכול לשבש עסקים רבים בו־זמנית. במילים אחרות, shared responsibility לא פוטר את הלקוח מארכיטקטורת resilience.
לכן, ב־BCP טוב מופיעות לפחות חמש שאלות: האם יש גיבוי cross-account או cross-region; האם ניתן לבצע restore עצמאי בלי תלות מלאה בספק; האם קיימת חלופת login לאובדן IdP; האם observability נשמרת בזמן failover; והאם הלקוח הגדיר מראש מהו “degraded mode” מקובל לשירות. NIST מדגיש שה־CSF חל גם על cloud, mobile ו־AI, ושפונקציות Respond ו־Recover צריכות להיות מוכנות תמיד.
| סיכון או תרחיש | תגובה תפעולית ב־BCP/DRP/IRP | קשר חוזי ו־SLA | אינטראקציה ביטוחית אפשרית |
| כשל Region / Cloud outage | failover, degraded mode, runbook, תקשורת יזומה | השפעה על uptime, service credits, carve-outs | עשוי להשליך על Cyber, Tech E&O ולעיתים Business Interruption או Contingent BI, בכפוף לנוסח הפוליסה ולטריגר הכיסוי. |
| מתקפת סייבר / ransomware | containment, forensic, restore, privileged access reset | notice obligations, security addendum, breach clauses | Cyber Insurance רלוונטי בדרך כלל לעלויות תגובה; איכות ה־IR והגיבוי עשויה להיות משמעותית לחיתום ולתביעה. |
| אובדן נתונים | immutable backup, restore test, data integrity validation | RPO, data retention, DPA | Cyber ו־Tech E&O עשויים להיפגש, בהתאם לעילת הטענה ולנוסח הכיסוי. |
| כשל מוצר / bug קריטי | rollback, release freeze, customer workaround | SLA, warranty disclaimers, limitation of liability | Tech E&O / Professional Liability רלוונטיים לטענות על כשל שירות. |
| טעות אנוש פנימית | dual control, change management, tabletop | service commitments, audit rights | עשויה להשפיע על חבות מקצועית, crime או fidelity בתרחישים מסוימים. |
| כשל ספק צד שלישי | vendor contingency, alternate vendor, exit plan | flow-down obligations, subcontractor terms | Contingent BI, Cyber או Tech E&O עשויים להיות רלוונטיים, אך לא אוטומטית. |
| החלטת הנהלה או disclosure כושל | governance cadence, board escalation, message discipline | disclosure obligations, investor communications | D&O עשוי להיות רלוונטי אם הטענה מופנית כלפי נושאי משרה. |
חוזים, אחריות וביטוח – מה באמת צריך לבדוק
החיבור בין BCP לביטוח עובר דרך החוזים. אם הלקוח דורש Additional Insured, Waiver of Subrogation או Primary and Non-Contributory, לא די לשאול “יש סעיף כזה בפוליסה”. צריך לבדוק באיזו פוליסה, כלפי מי, ביחס לאיזו חבות, ובאילו תנאים. גם Claims Made, Retroactive Date, Territorial Limits ו־Jurisdiction משנים מהותית את איכות ההגנה הביטוחית של חברת SaaS גלובלית. Claims-made תלוי בדרך כלל במועד הגשת התביעה ובדיווח; retroactive date קובע עד כמה אחורה פעולות קודמות עשויות להיכלל; territorial/jurisdiction קובעים היכן ואיך תופעל המסגרת המשפטית.
מבחינה תפעולית, BCP טוב מסייע בארבע דרכים: הוא מצמצם סיכון בפועל; הוא מאפשר להצהיר הצהרות חיתומיות מדויקות יותר; הוא תומך בשימור ראיות ותיעוד; והוא מקל על הכנת חבילת מידע מסודרת לחתמים. מחקר על נתוני חיתום ותביעות ב־Cyber Insurance מצביע על כך שהשוק נשען במידה רבה על מידע תפעולי, פרוצדורלי וארגוני, לא רק על שאלון כללי. לכן מומלץ להכין מראש ל־underwriters: ארכיטקטורה ותלויות, טופולוגיית גיבויים, תוצאות restore tests, שיעור כיסוי MFA, נוהל IR, vendor map, היסטוריית incidents וצעדי remediation. זו איננה הבטחה לתוצאה חיתומית מסוימת, אך היא בהחלט משפרת את איכות הדיאלוג החיתומי.
טעויות נפוצות
הטעות הנפוצה ביותר היא לקרוא ל־DR runbook בשם “BCP”. טעות שנייה היא להגדיר RTO/RPO בחוזה מכירה לפני שנבדקו בפועל. טעות שלישית היא להסתמך על uptime של ספק הענן כאילו הוא שקול לרציפות העסקית של המוצר. טעות רביעית היא להשאיר את המשפטי והביטוח מחוץ לשולחן. טעות חמישית היא לעדכן את התכנית רק אחרי אירוע גדול, במקום להחזיק אותה כמסמך חי עם מחזור קבוע של מבחנים, למידה ועדכון. NIST מדגיש שסיכוני סייבר מתרחבים כל הזמן ושניהול הסיכון הוא תהליך מתמשך, וגם ב־IR ממליץ לעדכן תיעוד ונהלים במרווחים קבועים.
Checklist מעשי לחברת SaaS
- הגדירו שירותים קריטיים לפי השפעתם העסקית, לא לפי מורכבות טכנית.
- קבעו RTO ו־RPO נפרדים לכל שירות ליבה.
- מלאו BIA אמיתי עם בעלי מערכת, product, support, legal ו־finance.
- מיפו תלותי ענן, Region, DNS, IdP, email, payments ו־support.
- ודאו גיבויים ניתנים לשחזור, לא רק “קיימים”.
- בצעו restore test תקופתי עם תיעוד תוצאות.
- הגדירו Incident Commander ומחליף.
- בנו escalation matrix להנהלה, ללקוחות ולדירקטוריון.
- שלבו notify triggers לחבות חוזית, לפרטיות ולרגולציה רלוונטית.
- החזיקו customer communications templates מוכנים מראש.
- בדקו התאמה בין SLA ליכולות DR בפועל.
- סמנו לקוחות ותהליכים עם עדיפות התאוששות גבוהה.
- מיפו אילו סעיפי ביטוח לקוחות דורשים בחוזים: Additional Insured, Waiver of Subrogation, Primary/Non-Contributory.
- בדקו האם כל הפוליסות הרלוונטיות הן Claims Made ומהו ה־Retroactive Date.
- הכינו data pack לחתמים: ארכיטקטורה, controls, incidents, tests, vendor map.
- ערכו tabletop לפחות אחת לחצי שנה ותרגיל טכני לפחות פעם בשנה. זוהי מסקנה פרקטית הנשענת על דגש NIST על testing, training, exercises ו־lessons learned.
שאלות נפוצות
האם חברת SaaS קטנה באמת צריכה BCP?
כן. NIST מדגיש ש־CSF 2.0 מתאים לכל ארגון, בכל גודל ובכל רמת בשלות, וההשפעה של השבתת שירות על חברת SaaS קטנה יכולה להיות קיומית דווקא משום שאין לה עודפי משאבים.
מה קודם למה – IRP או DRP?
בדרך כלל IRP קודם כדי להבין את האירוע, לבלום התפשטות ולשמר ראיות; DRP נכנס לפי הצורך כדי לשחזר שירותים, להעביר עומס או להחזיר מערכות לפעילות תקינה. בפועל, שני המסלולים רצים לעיתים במקביל תחת incident command אחד.
איך בוחרים RTO/RPO סביר?
לא בוחרים לפי תחושת בטן. מתחילים ב־BIA: אילו לקוחות ותהליכים נפגעים, מהי עלות downtime, מה נחשב data loss נסבל, ומהם גבולות ההתחייבות החוזית. אחר כך מאמתים את היעדים בתרגול restore/failover.
האם SLA מחליף BCP?
לא. SLA הוא הבטחה חוזית לרמת שירות; BCP הוא מנגנון הניהול שמאפשר לעמוד בהבטחה או לנהל חריגה ממנה באופן מסודר.
האם BCP טוב מוזיל בהכרח ביטוח?
לא בהכרח. אין קשר אוטומטי בין קיום מסמך לבין תוצאה חיתומית או פרמיה. אבל תכנית טובה, מתורגלת ומתועדת משפרת את איכות המידע לחתמים ואת היכולת להסביר סיכון, וזה עשוי להשפיע לטובה על הדיון החיתומי.
מתי BCP הופך למסמך חי ולא לקובץ מדף?
כאשר הוא מחובר לתרגילים, ל־lessons learned, לשינויים בארכיטקטורה, להסכמי לקוח חדשים, לפוליסות המתחדשות ולמפת הספקים. NIST ממליץ במפורש על תחזוקת תכנית, exercises ועדכון תיעוד ונהלים במרווחים קבועים.
תכנית המשכיות עסקית לחברת SaaS ישראלית היא שכבת התיאום שמחברת בין business, cloud, security, product, legal, contracts ו־insurance. המסמך הנכון אינו מנסה “לכסות הכול”, אלא מגדיר בהיגיון מה קריטי, מי מחליט, כמה מהר חייבים לחזור, כמה נתונים מותר לאבד, איך מתקשרים, ואילו תלותים חייבים לפזר, לתרגל או לבטח.
בעולם שבו אירועי סייבר בישראל מחריפים ושירותי ענן מהווים גם כוח וגם נקודת ריכוז, BCP טוב הוא לא קישוט Governance – הוא מנגנון הישרדות וצמיחה.































































