מאת עידן צברי · יועץ אבטחת מידע והגנת פרטיות · מומחה תיקון 13
מאת: עידן צברי, יועץ בכיר לאבטחת מידע והגנת פרטיות · עודכן אוגוסט 2026
מה זה RTO?
RTO, Recovery Time Objective הוא יעד זמן ההתאוששות: כמה זמן מותר למערכת או לתהליך עסקי להיות מושבת מרגע האירוע ועד לחזרה לפעילות. אם ה-RTO של מערכת ההזמנות שלכם הוא ארבע שעות, המשמעות היא שהארגון החליט שהוא שורד ארבע שעות בלי הזמנות, ומעבר לכך מתחיל נזק בלתי מתקבל. ה-RTO הוא שמכתיב את סוג הפתרון: גיבוי לענן, אתר DR חם, או שרת חלופי במדף.
מה זה RPO?
RPO, Recovery Point Objective הוא יעד נקודת ההתאוששות: כמה מידע מותר לאבד, במונחי זמן. אם ה-RPO הוא שעה, המשמעות היא שבמקרה הגרוע תחזרו לתמונת מצב של לפני שעה, וכל מה שנוצר מאז אבד. ה-RPO הוא שמכתיב את תדירות הגיבוי: גיבוי לילי אחד ליום פירושו RPO של עד 24 שעות, בין אם התכוונתם לכך ובין אם לא.
מה ההבדל בין RTO ל-RPO?
ההבדל פשוט: RTO מודד זמן השבתה, RPO מודד אובדן מידע. אפשר לחזור לפעילות מהר מאוד (RTO קצר) ועדיין לאבד יום שלם של נתונים (RPO ארוך), ולהפך. שניהם נדרשים, והם עולים כסף בנפרד.
| RTO | RPO | |
|---|---|---|
| מה נמדד | זמן חזרה לפעילות | כמות מידע שאבד |
| השאלה העסקית | כמה זמן נשרוד מושבתים? | כמה מידע נוכל לאבד? |
| מה זה מכתיב | ארכיטקטורת התאוששות (DR, שרידות, ענן) | תדירות ושיטת הגיבוי |
| דוגמה | 4 שעות עד חזרה למסחר | עד שעה של הזמנות שאבדו |
| מי מחליט | ההנהלה, לא מחלקת ה-IT | |
איך קובעים RTO ו-RPO בפועל?
לא לכל המערכות אותו יעד, וזו הטעות הנפוצה. התהליך הנכון הוא ניתוח השפעה עסקית (BIA) קצר:
- מיפוי תהליכים קריטיים, מה באמת עוצר את העסק: ייצור? גבייה? שירות לקוחות?
- כימות הנזק לשעה, הפסד הכנסה, קנסות SLA, נזק תדמיתי, עצירת שרשרת אספקה
- קביעת יעד לכל מערכת, מערכת הליבה תקבל RTO/RPO אגרסיביים; ארכיון ישן יכול לחכות
- בדיקת פער מול המצב הקיים, מה ה-RTO/RPO שאתם באמת מקבלים היום, לא מה שכתוב בהצעה
- תמחור הפער, כמה עולה לקצר RTO מ-24 שעות ל-4, וכמה שווה לכם
למה זה נכשל ברגע האמת?
ברוב הארגונים שנתקלתי בהם, הפער אינו בטכנולוגיה אלא בהנחות שלא נבדקו. גיבויים קיימים, אבל איש לא ניסה לשחזר מהם. יש “תוכנית DR”, אבל היא לא תורגלה. הספקים מוגדרים בחוזה, אבל לא יודעים מה תפקידם בשעת אירוע. והמסמכים הקריטיים, מפת הרשת וסיסמאות המערכת, שמורים במערכת שגם היא מושבתת.
- מתי בפעם האחרונה בוצע שחזור מלא בפועל, ולא רק “בדיקת גיבוי הצליחה”?
- האם קיים עותק גיבוי מבודד מהרשת (offline/immutable) שכופרה לא יכולה להצפין?
- האם ההסכם עם ספק ה-IT או הענן כולל SLA מדיד לחזרה לשגרה?
- האם התיעוד הקריטי נגיש גם כשהמערכות למטה?
הקשר לתיקון 13 ולרגולציה
אירוע השבתה שכרוך גם בפגיעה במידע אישי הופך מיידית לאירוע רגולטורי: חלה חובת דיווח מיידית לרשות להגנת הפרטיות מרגע שנודע על האירוע. הקנס הראשון בישראל לפי תיקון 13, 256,000 ₪, ניתן בדיוק על איחור בדיווח, לא על הפריצה עצמה. משמעות מעשית: תוכנית ההתאוששות שלכם חייבת לכלול לא רק “איך מחזירים מערכות” אלא גם “מי מדווח, למי ותוך כמה זמן”. כל התשובות על תיקון 13 כאן. לארגון שאין לו מענה פנימי לשאלה הזו, הפתרון המקובל הוא ממונה הגנת פרטיות במיקור חוץ. מי שרוצה לבנות את התמונה כולה מסודר, מהסקר ועד תוכנית העבודה, מתחיל בייעוץ אבטחת מידע.
יעדים מקובלים לפי סוג מערכת
אין מספר נכון אחד, אבל יש טווחים שחוזרים בארגונים בינוניים בישראל. הטבלה הזו היא נקודת פתיחה לדיון עם ההנהלה, לא תקן:
| סוג מערכת | RTO טיפוסי | RPO טיפוסי |
|---|---|---|
| מערכת ליבה תפעולית (ERP, מערכת הזמנות) | 4 עד 8 שעות | 15 דקות עד שעה |
| דואר אלקטרוני ושיתוף קבצים | 4 עד 24 שעות | עד שעה |
| אתר אינטרנט שיווקי | 24 עד 48 שעות | 24 שעות |
| מערכות שכר ומשאבי אנוש | 24 עד 72 שעות | 24 שעות |
| ארכיון ומידע היסטורי | שבוע | 24 שעות |
שימו לב שככל שה-RPO מתקצר, העלות עולה בצורה לא ליניארית. ההפרש בין גיבוי יומי לגיבוי כל רבע שעה הוא לרוב ההפרש בין ארכיטקטורה פשוטה לבין שכפול מתמשך בין אתרים.
איך מחשבים את עלות ההשבתה
הדרך היחידה להצדיק השקעה בקיצור RTO היא להעמיד מולה מספר. החישוב הבסיסי הוא פשוט: מחזור שנתי חלקי מספר שעות הפעילות בשנה נותן עלות שעת השבתה ישירה. לזה מוסיפים את מה שלא נכנס למחזור: קנסות חוזיים מול לקוחות, שעות עבודה שמושקעות בשחזור במקום בפעילות, ונזק מוניטיני שקשה לכמת אבל אפשר להעריך בטווח.
כשמנהל כספים רואה שעת השבתה במונחי שקלים, הדיון על RTO מפסיק להיות דיון טכני. זה בדיוק המקום שבו סקר סיכוני אבטחת מידע מספק את הנתונים, כי הוא ממפה אילו תהליכים עסקיים תלויים באילו מערכות.
RTO, RPO, MTD ו-BIA: איך המונחים מתחברים
ארבעת המונחים נשמעים דומים ומבלבלים גם אנשי מקצוע. הסדר ההגיוני הוא זה: ניתוח השפעה עסקית, BIA, הוא התהליך שבו מזהים אילו תהליכים קריטיים ומה קורה כשהם נעצרים. מתוכו נגזר MTD, משך ההשבתה המקסימלי שהעסק יכול לספוג לפני נזק בלתי הפיך. RTO הוא היעד שנקבע כדי להישאר בתוך ה-MTD, ו-RPO הוא כמה מידע מותר לאבד בדרך.
ארגון שקובע RTO בלי BIA בעצם מנחש. לרוב הוא מגלה את הטעות ביום שבו הוא צריך את היעד באמת.
אתר אחד מול שני אתרים: איך מחליטים
השאלה חוזרת בכל דיון על התאוששות מאסון. דאטה סנטר יחיד עם גיבוי מחוץ לאתר מספיק כשה-RTO נמדד בשעות ארוכות והתקציב מוגבל. שני אתרים פעילים או אתר משני בענן נדרשים כשה-RTO קצר משעות בודדות או כשיש דרישה חוזית או רגולטורית לרציפות.
הטעות הנפוצה היא לבחור ארכיטקטורה לפני שקובעים יעד. קודם מחליטים כמה זמן מותר להיות מושבתים, אחר כך בונים את הפתרון שעומד בזה. ארגונים שנדרשים גם לעמידה ברמות אבטחה לפי תקנות אבטחת מידע או בISO 27001 ימצאו שהדרישה לרציפות תפעולית כבר מופיעה שם.
שאלות נפוצות
מה זה RTO ומה זה RPO בפשטות?
RTO הוא כמה זמן מותר לעסק להיות מושבת עד שהוא חוזר לפעול. RPO הוא כמה מידע מותר לו לאבד, נמדד בזמן. RTO של 4 שעות ו-RPO של שעה פירושם: חוזרים לפעילות תוך 4 שעות לכל היותר, ומאבדים לכל היותר שעה של נתונים.
מי אמור לקבוע את היעדים, ה-IT או ההנהלה?
ההנהלה. RTO ו-RPO הם החלטות עסקיות על סיבולת לנזק, ומחלקת ה-IT מתרגמת אותן לארכיטקטורה ולתקציב. כשה-IT קובע אותם לבד, התוצאה היא בדרך כלל או הגנת יתר יקרה או פער מסוכן שההנהלה לא מודעת לו.
מה RTO ו-RPO סבירים לחברה בינונית?
אין מספר אחיד, הוא נגזר מהנזק לשעה. מערכת ליבה בייצור או במסחר מצדיקה לרוב RTO של שעות בודדות ו-RPO של דקות עד שעה; מערכות משניות יכולות להסתפק ביממה. הדרך היחידה לדעת היא לכמת את הנזק לשעה לכל תהליך.
מה ההבדל בין RTO ל-MTD?
MTD הוא משך ההשבתה המקסימלי שהעסק שורד לפני נזק בלתי הפיך. RTO הוא היעד שהארגון מציב לעצמו כדי להישאר בתוך ה-MTD, ולכן הוא תמיד קצר ממנו.
כמה עולה לקצר RTO?
העלות לא עולה בקצב קבוע. מעבר מ-48 שעות ל-24 שעות הוא לרוב שינוי נוהל. מעבר מ-8 שעות לשעה אחת דורש ארכיטקטורה אחרת, לרוב אתר משני ושכפול מתמשך. לכן כדאי לקבוע את היעד מתוך צורך עסקי מוכח ולא מתוך שאיפה.
מי אחראי על עמידה ב-RTO וב-RPO?
ההנהלה קובעת את היעד כי הוא החלטה עסקית. ה-IT או הספק אחראים לממש אותו. מי שמוודא שהיעד מוגדר, מתועד ונבדק בתרגול הוא לרוב מנהל אבטחת המידע, פנימי או במיקור חוץ.
גיבוי לענן פותר את הבעיה?
לא בהכרח. גיבוי מבטיח שהמידע קיים; הוא לא מבטיח כמה זמן ייקח לשחזר אותו ולהחזיר את המערכות לאוויר. שחזור של טרהבייטים מהענן עלול לקחת ימים, כלומר RPO מצוין לצד RTO גרוע. חייבים למדוד את שניהם בנפרד, ולתרגל שחזור בפועל.
קשור: סקר סיכוני אבטחת מידע · CISO כשירות · 5 כללי זהב להישרדות מתקפת כופרה
רלוונטי להעמקה: ייעוץ אבטחת מידע · סקר סיכוני אבטחת מידע
יודעים מה ה-RTO וה-RPO שלכם באמת?
שיחת הערכה עם יועץ בכיר, נבדוק את הפער בין מה שהובטח לכם למה שתקבלו ברגע האמת.
לתיאום שיחת הערכהעידן צברי — יועץ אבטחת מידע והגנת פרטיות
מייסד SEC-IT, עם מעל 15 שנות ניסיון. משלב רקע משפטי (תואר במשפטים) עם ניסיון IT מבצעי ומומחיות סייבר (CISM, CISO), ומתמחה ביישום תיקון 13 והגנת פרטיות לעסקים קטנים ובינוניים. עוד על עידן ←
