שאלות נפוצות

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

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

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

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

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

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

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

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

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

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

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

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

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

חד משמעית לא. תוספי נגישות או סרגלי נגישות משפיעים רק על רכיבי ה-HTML של דפי האתר. הם לא נכנסים לתוך קובצי PDF, Word או Excel ולא מתקנים את המבנה הפנימי. הנגשת מסמכים חייבת להתבצע על הקובץ עצמו.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ברוב הארגונים יש כמה מאגרים מרכזיים:

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

הצעד הראשון הוא מיפוי מסודר של כל המאגרים ושל סוגי המידע שבהם.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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