אחסון אתרים לארגונים: איך בוחרים, מה דורשים ב-SLA ומה כותבים בחוזה

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

מה ארגון קונה כשהוא קונה אחסון אתרים?

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

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

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

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

שיתופי, VPS, מנוהל או ענן: השוואה כנה

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

אחסון שיתופי

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

שרת וירטואלי (VPS)

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

אחסון מנוהל

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

ענן ציבורי

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

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

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

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

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

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

אחסון אתרים בישראל או בחו"ל: מתי מיקום המידע חשוב?

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

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

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

מה אומרת המדיניות הממשלתית

הנחיה 4.2 של רשות התקשוב הממשלתי, "מדיניות מימוש חזון מחשוב הענן במשרדי הממשלה", בגרסה 3.0 שבתוקף מ-1.11.2021, קובעת תפיסה של Cloud First: מערכת חדשה מתוכננת כברירת מחדל לענן. לפי ההנחיה, במכרז נימבוס זכו AWS ו-Google, והן מקימות אזור בישראל שמאפשר למשרדי הממשלה וליחידות הסמך שירותי ענן על פלטפורמה שממוקמת בישראל וכפופה לחוקיה. ההנחיה מונה במפורש את "כפיפות לדיני מדינה זרה" כסיכון של מידע ממשלתי בענן מחוץ לישראל, ומתארת ועדת ענן, בשיתוף הרשות להגנת הפרטיות ומערך הסייבר הלאומי, שאישרה בתקופת הביניים העלאת מערכות לענן.

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

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

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

בגילוי הדעת של הרשות להגנת הפרטיות לפרשנות תקנה 2(4) יש הבהרה שחשובה לכל מי שמאחסן בחו"ל: גילוי הדעת לא חל כשההעברה נעשית במסגרת התקשרות עם מחזיק שמקום מושבו מחוץ לישראל. במקרה כזה נדרשת עמידה מלאה של המחזיק בחוק הגנת הפרטיות ובתקנותיו, והחובות בהתקשרות עם מחזיק מופיעות בתקנה 15 לתקנות הגנת הפרטיות (אבטחת מידע), התשע"ז-2017. ספק אחסון שמחזיק את מאגר הפניות שלכם עשוי להיחשב מחזיק כזה.

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

מי אחראי על מה: הספק, הענן ואתם

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

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

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

SLA: מה זה הסכם רמת שירות ומה באמת נמדד?

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

זמינות

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

זמן תגובה וזמן פתרון

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

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

שעות תמיכה

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

מה מבטיחה ספקית הענן, ומה לא

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

גיבויים, RPO ו-RTO: כמה מידע מותר לאבד?

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

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

גיבוי שלא שוחזר אף פעם הוא השערה. מה שמבדיל גיבוי אמיתי:

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

רשימת סעיפים לדוגמה ל-SLA של אחסון אתרים

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

שכבות האבטחה: WAF, DDoS, CDN, עדכונים וניטור

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

• חומת אש לאפליקציות (WAF): מסננת בקשות זדוניות לפני שהן מגיעות לאתר, כמו ניסיונות הזרקה וסריקות אוטומטיות. היא יכולה לשבת אצל ספק האחסון או בשירות שעומד לפני האתר.
• הגנה מפני DDoS: מתקפה שמציפה את האתר בתעבורה כדי להפיל אותו. נכון לאוקטובר 2026, Cloudflare מציינת בתיעוד שלה הגנת DDoS לא מוגבלת בשכבות 3 עד 7 בכל התוכניות, כולל התוכנית החינמית. ספקים אחרים מציעים הגנות דומות בתנאים שונים, ושווה לבדוק מה כלול אצל הספק שלכם.
• CDN: מגיש עותקים של הדפים הציבוריים משרתים קרובים לגולש, מוריד עומס מהשרת ומקצר זמני טעינה. הוא עוזר גם לשרידות, כי חלק מהאתר ממשיך להיות מוגש גם כשהשרת מתקשה.
• חסימת גישה ישירה לשרת: אם יש שכבת הגנה לפני האתר, השרת עצמו מקבל תעבורה רק ממנה. אחרת תוקף פשוט עוקף אותה.
• HTTPS בכל מקום, עם חידוש אוטומטי של התעודה והתראה לפני שפג תוקפה.
• עדכונים בשגרה: מערכת ההפעלה, שרת האינטרנט, מערכת ניהול התוכן והתוספים, לפי לוח זמנים כתוב.
• גישה לניהול: משתמש אישי לכל אדם, אימות דו-שלבי, והרשאות מינימליות. בלי משתמש "admin" משותף.
• לוגים וניטור: רישום של כניסות ושינויים, ושמירה שלהם מחוץ לשרת לתקופה מוגדרת, כדי שאפשר יהיה להבין מה קרה אחרי אירוע.

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

איך יודעים שהאתר נפל לפני שהלקוחות יודעים?

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

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

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

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

של מי הדומיין, ה-DNS והחשבונות?

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

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

מעבר אחסון בלי השבתה

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

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

מה כותבים בחוזה עם ספק האחסון

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

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

מה שכדאי שיופיע בחוזה, מעבר לנספח ה-SLA:

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

מה עושים עכשיו

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

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