סיווג מאגרים לפי תיקון 13: המדריך התפעולי — לא המשפטי

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

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

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

המדריך נכתב עבור בעלי עסקים קטנים ובינוניים המנסים להבין במה הם נדרשים לעמוד, עבור ממוני אבטחת מידע (CISO) וממוני הגנת הפרטיות (DPO) המחפשים מסגרת תפעולית מובנית, ועבור ספקי שירות מנוהל (MSP) וספקי שירותי אבטחה מנוהלים (MSSP) המייעצים ללקוחותיהם בנוגע לתיקון 13 — ולעיתים מסתבכים בעצמם באותה שאלה.

מדוע המה של החוק אינו האיך

החוק כתוב בשפה משפטית. הוא דורש "בקרות המתאימות לרמת הסיכון של המאגר". מה זה אומר?

עורך דין יגיד לכם ש"זה תלוי". רגולטור יפנה אתכם לתקנות הגנת הפרטיות (אבטחת מידע), התשע"ז-2017. יועץ פרטיות יגיד לכם לערוך סקר סיכונים. אף אחד מהם לא יגיד לכם — פִּרסו EDR, MFA, אבטחת דוא"ל, גיבוי מחוץ לאתר ומדיניות הרשאות מתועדת. זה לא התפקיד שלהם, וזה לא המקצוע שלהם.

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

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

ארבע רמות הסיווג — מה הן אומרות בפועל

תקנות הגנת הפרטיות (אבטחת מידע), התשע"ז-2017, מגדירות ארבע רמות אבטחה:

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

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

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

רמת אבטחה גבוהה. מאגר עם מידע רגיש במיוחד בהיקף נרחב, או עם מספר רב מאוד של נושאי מידע. נדרש: כל בקרות הרמה הבינונית, בתוספת מבחני חדירה חיצוניים כל 18 חודשים, SOC פעיל 24/7, סקר סיכונים פורמלי, ובקרות מתועדות על ספקים. דוגמה: בית חולים, חברת ביטוח, בנק.

הבעיה: התקנות אומרות לכם מה נדרש, לא כיצד ליישם זאת. הן גם לא אומרות לכם מה לעשות כאשר ארגון קטן אינו יכול להפעיל SOC בפעילות 24/7 שדורשת הרמה הגבוהה.

מסגרת הסיווג של Fortress — שלוש שאלות לרמה מדויקת

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

שאלה ראשונה: אילו סוגי מידע יש במאגר?

תיקון 13 מגדיר 12 קטגוריות של "מידע רגיש במיוחד" שמעלות אוטומטית את רמת הסיכון, ללא קשר לגודל המאגר. הקטגוריות:

1. צנעת חייו האישיים של אדם, פרטים על אורח חייו האינטימי, נטייתו המינית
2. מידע על מצב בריאותו (לרבות מידע רפואי לפי חוק זכויות החולה)
3. מידע גנטי
4. נתוני זיהוי ביומטריים המשמשים לזיהוי או לאימות ממוחשבים
5. מוצאו האתני של אדם
6. עברו הפלילי
7. דעותיו הפוליטיות, אמונותיו הדתיות, השקפת עולמו
8. הערכות אישיות מקצועיות (לרבות הערכות של כושר אינטלקטואלי או ביצועים בעבודה)
9. נתוני שכר ופעילות פיננסית
10. נתוני מיקום ותעבורה מבעל רישיון תקשורת
11. מיקומו של אדם החושף אחת מהקטגוריות לעיל
12. מידע החוסה תחת חובת סודיות סטטוטורית

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

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

שאלה שנייה: כמה נושאי מידע יש במאגר?

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

ספי הכמות:

• עד 100,000 נושאים, במאגר המכיל אך ורק שם, כתובת ופרטי קשר — אינו נחשב מאגר מידע לפי החוק. תיקון 13 קבע פטור מפורש למאגרים "דקים".
• מעל 5,000 נושאים בשילוב מידע אישי בסיסי — הסף להעלאה לרמה הבינונית.
• מעל 100,000 נושאים עם מידע רגיש במיוחד — מקים חובה ליידע את הרשות להגנת הפרטיות בתוך 30 יום (גם אם המאגר אינו חייב ברישום).
• מעל 1,000,000 נושאים — כל סכומי העיצומים מוכפלים אוטומטית.

שאלה שלישית: מי מנהל את המאגר?

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

דוגמה מעובדת: סיווג שלושה ארגונים

ארגון א': משרד עורכי דין בן 25 איש. מפעיל CRM עם פרטי לקוחות, חשבונות ותיקים פעילים. סה"כ נושאי מידע: 8,000.

• שאלה 1 — סוגי מידע: שם, כתובת, פרטי קשר, ייתכן מידע פיננסי בסיסי. אין קטגוריות רגישות במיוחד.
• שאלה 2 — היקף: 8,000 נושאים.
• שאלה 3 — ניהול: ארגון מובנה, לא יחיד.

תוצאה: רמה בינונית (סף 5,000 נחצה).

ארגון ב': מרפאת משפחה עם 6 רופאים. מערכת ניהול מטופלים. סה"כ נושאי מידע: 3,500.

• שאלה 1 — סוגי מידע: מידע רפואי. כן, רגיש במיוחד (קטגוריה 2).
• שאלה 2 — היקף: 3,500 נושאים.
• שאלה 3 — ניהול: ארגון מובנה.

תוצאה: רמה גבוהה. העלאה אוטומטית בשל קטגוריית המידע הרפואי.

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

• שאלה 1 — סוגי מידע: שמות, פרטי קשר, תאריכי פגישות. ייתכן הערות כלליות על מצב בריאות.
• שאלה 2 — היקף: 200 נושאים.
• שאלה 3 — ניהול: יחיד.

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

שלושה ארגונים, שלוש רמות שונות. אותה מסגרת.

מיפוי בקרות — מה כל רמה באמת דורשת

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

רמת יחיד. הגנת קצה בסיסית. סיסמה חזקה ואימות רב-שלבי בשירותי ענן. גיבוי סדיר (לפחות חודשי). תיעוד בסיסי של פעילות העיבוד. אין דרישה ל-SIEM, ל-SOC או לניהול חולשות פורמלי.

רמת אבטחה בסיסית. כל האמור לעיל, בתוספת:

• מסמך הגדרות מאגר מתועד (תקנה 2)
• נוהל אבטחת מידע כתוב (תקנה 4)
• ניהול הרשאות מתועד עם בקרת גישה (תקנות 8–9)
• מנגנון תיעוד גישה לפי הרשאה (תקנה 10)
• אבטחה בסיסית של חיבורי רשת (תקנה 14)
• הדרכת עובדים ראשונית (תקנה 7)
• תיעוד אירועי אבטחת מידע (תקנה 11)

קטגוריות טכנולוגיה ריאליות ברמה הבסיסית: EPP (הגנת קצה), MFA בכל מערכות העסק, אבטחת דוא"ל בסיסית, פתרון גיבוי מנוהל, מוצר בקרות זהות פשוט. הוצאה חודשית טיפוסית: 50–150 ₪ לתחנת קצה.

רמת אבטחה בינונית. כל האמור לעיל, בתוספת:

• SIEM פעיל לאיסוף לוגים ולקורלציה ביניהם (תקנה 11)
• שמירת לוגים ל-24 חודשים (תקנות 17–18)
• תהליך ניהול חולשות מתועד (תקנה 13)
• סקירה תקופתית של מידע עודף (תקנה 2)
• ביקורת פנימית תקופתית (תקנה 16)
• הדרכת עובדים חוזרת (לא רק ראשונית)
• פיקוח על ספקי שירות חיצוניים (תקנה 15)

קטגוריות טכנולוגיה ריאליות ברמה הבינונית: כל מה שיש ברמה הבסיסית, בתוספת SIEM (שיכול להיות מנוהל), פתרון MDR בסיסי, סורק חולשות אוטומטי, ומערכת לניהול ספקים. הוצאה חודשית טיפוסית: 150–400 ₪ לתחנת קצה.

רמת אבטחה גבוהה. כל האמור לעיל, בתוספת:

• סקר סיכונים מקיף תקופתי (תקנה 5)
• מבחני חדירה חיצוניים כל 18 חודשים (תקנה 5)
• דיווח על אירועי אבטחה חמורים לרשות להגנת הפרטיות תוך 72 שעות (תקנה 11)
• ניטור SOC פעיל 24/7 (משתמע מהשילוב בין דרישות ה-SIEM לבין דרישות התגובה לאירועים)
• ביקורת חיצונית עצמאית

קטגוריות טכנולוגיה ריאליות ברמה הגבוהה: כל מה שיש ברמה הבינונית, בתוספת SOC מנוהל 24/7, MDR מלא עם תגובה אוטומטית, DLP, IRM/DRM לתוכן רגיש, מערכת לניהול אירועים (IR), ומבחני חדירה תקופתיים. הוצאה חודשית טיפוסית: 400–1,200 ₪ לתחנת קצה.

האמת התפעולית — עסקים קטנים ובינוניים לא יכולים ליישם הכול

וכעת לחלק שאף יועץ ציות לא יגיד בקול רם.

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

התשובה אינה "להפר את החוק". התשובה היא:

אפשרות 1: מיקור חוץ לשירות מנוהל. SOC-as-a-Service, MDR-as-a-Service, vCISO-as-a-Service. הדרישה הרגולטורית מתקיימת — הבקרה פעילה — אך אינכם נדרשים לבנות אותה באופן פנימי. זה המקרה הקלאסי שבו ארגון משלם תשלום חודשי במקום להעסיק חמישה אנשי אבטחה.

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

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

החוק אינו דורש מסטארט-אפ בן 10 אנשים להפעיל SOC ארגוני. הוא דורש שהבקרה הרלוונטית תהיה פעילה. האיך הוא החלטה תפעולית.

השירותים המנוהלים הזמינים

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

vCISO-as-a-Service. ממונה הגנת פרטיות (DPO) / CISO חיצוני, פעיל במשרה חלקית. מתאים לארגון המחויב למנות DPO לפי סעיף 17ב1 לתיקון 13 אך אינו זקוק ל-CISO במשרה מלאה. עלות טיפוסית: 3,000–15,000 ₪ לחודש בהתאם להיקף.

GRC-as-a-Service. הכנת המסמכים שהחוק דורש — מסמך הגדרות מאגר, נוהל אבטחת מידע, מסמכי הסכמה, נהלי טיפול בבקשות נושאי מידע. ניטור ציות תקופתי. מתאים לכל רמת סיווג. עלות טיפוסית: 2,000–10,000 ₪ לחודש.

SOC-as-a-Service. ניטור לוגים 24/7, זיהוי אירועים, תגובה ראשונית. מחליף בניית SOC פנימי. מתאים לרמה הבינונית ומעלה. עלות טיפוסית: 50–200 ₪ לתחנת קצה לחודש בהתאם להיקף.

MDR-as-a-Service. ניטור פעיל בתוספת תגובה אוטומטית בתוספת תיעוד מלא. משלב טכנולוגיה ואנליסטים. מתאים לרמה הבינונית ומעלה. עלות טיפוסית: 80–300 ₪ לתחנת קצה לחודש.

TPRM-as-a-Service. ניהול סיכוני ספקים — בדיקות תקופתיות על ספקים חיצוניים המעבדים מידע, תיעוד חוזים, ניטור אירועי אבטחה בצד הספק. מתאים לארגונים עם חמישה ספקי שירות או יותר. עלות טיפוסית: 1,500–5,000 ₪ לחודש.

חלק מהשירותים האלה מופעלים בידי אנשים בצד שלנו. חלק בידי סוכני AI (AI Agents) המטפלים בעבודה החוזרת באופן אוטומטי (מיון ראשוני של אירועים, בדיקות ציות בסיסיות, איסוף ראיות לביקורת). זהו שילוב — לא תחליף.

ה-MSP/MSSP — מי שבאמת מספק לכם את זה

רוב בעלי העסקים הקטנים והבינוניים אינם קונים את השירותים האלה ישירות מ-Fortress או מספק טכנולוגיה יחיד. הם קונים אותם מספק שירותי IT וסייבר — MSP או MSSP — המנהל את כל סביבת הטכנולוגיה שלהם.

עבור MSPs המתמודדים עם תיקון 13, האתגר הוא כפול: להבין מה הלקוח שלהם צריך, ולהיות מסוגלים לספק זאת כשירות. רוב ה-MSPs אינם מומחי סייבר — הם אנשי IT כלליים. פלטפורמות כמו Fortress (ה-Channel Enablement OS) מאפשרות ל-MSP להפעיל את חבילת השירות המלאה — vCISO, GRC, SOC, MDR, TPRM — תחת המותג שלו, בלי להעסיק צוות אבטחה פנימי.

זה המקרה הקלאסי שבו ה-MSP אינו מתחרה בפלטפורמת ה-Channel Enablement — הוא משתמש בה כדי לספק שירות עמוק יותר ללקוחותיו.

חמש טעויות סיווג נפוצות

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

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

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

3. ספירת רשומות במקום נושאי מידע. מאגר מכירות עם 100,000 רשומות המכסות מידע על 8,000 לקוחות חוזרים הוא 8,000 נושאי מידע, לא 100,000.

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

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

שאלות נפוצות

כיצד אדע אם המאגר שלי מחייב הודעה לרשות להגנת הפרטיות לפי סעיף 8א(ב)?

חובת ההודעה (להבדיל מהרישום) חלה על מאגרים עם יותר מ-100,000 נושאי מידע רגיש במיוחד, גם אם המאגר עצמו אינו חייב ברישום. אם יש לכם מאגר כזה, עליכם ליידע את הרשות להגנת הפרטיות בתוך 30 יום ממועד התקיימות התנאי.

האם ממונה אבטחת המידע וה-DPO הם אותו אדם?

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

אם אני עסק זעיר עם הכנסה של 3 מיליון ₪, האם העיצומים חלים עליי במלואם?

לא. תיקון 13 קבע תקרות מיוחדות לעסקים קטנים (הכנסה של 4–10 מיליון ₪) ולעסקים זעירים (הכנסה של עד 4 מיליון ₪). בכל מקרה, העיצום הכספי המצטבר אינו יכול לעלות על 5% מהמחזור השנתי.

מה ההבדל בין "בעל מאגר" ל"בעל שליטה במאגר"?

המונח הישן "בעל מאגר" בוטל בתיקון 13 והוחלף ב"בעל שליטה במאגר" — בהתאמה לטרמינולוגיה של ה-GDPR. בעל השליטה הוא הארגון (ולא אדם פרטי) הקובע את מטרת עיבוד המידע. לדבר משמעות הן לעניין האחריות והן לשאלה מי מחויב בחוק למנות DPO.

מה ההבדל בין רישום, הודעה ופטור?

שלוש קטגוריות נפרדות:

• חובת רישום: מאגרים המוחזקים בידי גופים ציבוריים, ומאגרים שמטרתם העיקרית היא מסחר במידע אישי עם יותר מ-10,000 נושאים.
• חובת הודעה: מאגרים עם יותר מ-100,000 נושאי מידע רגיש במיוחד שאינם חייבים ברישום.
• פטור מלא: מאגר אישי שאינו משמש למטרות עסקיות, או מאגר "דק" (שם + כתובת + פרטי קשר בלבד) עם פחות מ-100,000 נושאים.

אם אני מתחיל לעמוד בדרישות עכשיו — ב-2026 — האם אוכל לקבל הפחתות כלשהן?

כן. תיקון 13 קובע מנגנון הפחתת עיצום מצטבר של עד 70%. הגורמים העיקריים: היעדר הפרה קודמת (10%–20%), הפסקה עצמית ודיווח עצמי (30%), פעולה מתקנת (20%), ומינוי DPO כשהדבר רלוונטי (10%). קיימות גם תקרות מיוחדות לעסקים קטנים וזעירים. למסלול היזום — הגעה לציות לפני האכיפה — יש ערך כספי ממשי.

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

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

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

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

סיכום

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

מסגרת הסיווג: סוגי מידע ← היקף נושאים ← מבנה ניהול. העלאה אוטומטית בנוכחות אחת מ-12 הקטגוריות הרגישות במיוחד.

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

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

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

להמשך קריאה: ה-Channel Enablement OS · מדריך סיווג תיקון 13