בנקאות ענן-נייטיב ב-2026 נמצאת בשלב הביקורת של DORA. תקנה (EU) 2022/2554 ⧉ בתוקף מאז 17 בינואר 2025. משטר הסיווג של ספק צד-שלישי קריטי (CTPP) תחת סעיפים 28-44 נפתח לאורך 2025-2026, כש-AWS, Microsoft (Azure), Google (GCP) ו-Salesforce בתוך פרימטר הסיווג או בקרבתו. רשויות הפיקוח האירופיות (EBA, EIOPA, ESMA) פרסמו את ה-RTS וה-ITS הסופיים על מרשם המידע ⧉ במהלך 2024. צוות פיקוח הבנקאות של ECB מנהל תכניות מפורשות בנושא היערכות לשיבוש בענן ובדיקות חדירה מונעות-איום בסדרי העדיפויות הפיקוחיים 2026-28 ⧉. השאלה המוסדית אינה אם להתאים את אסטרטגיית הענן ל-DORA — זה סגור — אלא אם יסודות הנדסת הפלטפורמה של המוסד מייצרים ראיות בקצב צנרת הפריסה במקום בקובצי PDF שנאספים בשבוע שלפני הבחינה.
תקציר מנהלים / עיקרי הדברים
- חוסן הענן תחת DORA באכיפה פעילה מאז 17 בינואר 2025. סעיפים 6, 8, 18, 26 ו-28-44 כולם בתוקף. ממצאי פיקוח מגל הבחינות הראשון הגיעו ברבעון הרביעי של 2025. מסגור ה"היערכות" מאחר בשני מחזורים.
- משטר הסיווג של CTPP נפתח. AWS, Microsoft, Google, Salesforce — בתוך הפרימטר או בקרבתו. הסיווג מעניק לרשויות הפיקוח זכויות פיקוח ישיר, ובכלל זה בקשות מידע, ביקורות באתר והמלצות פיקוחיות.
- הנדסת הפלטפורמה היא התוצר. מסלולים סלולים על Kubernetes (EKS / AKS / GKE / OpenShift), פורטל מפתחים בסגנון Backstage, GitOps (ArgoCD או Flux), Open Policy Agent ברמת ה-admission ו-OpenTelemetry מקצה לקצה. חמישה יסודות ייעודיים; כל דבר חסר הוא ממצא.
- ענן ריבוני הוא הנדסה, לא מיתוג. AWS European Sovereign Cloud, Microsoft EU Data Boundary, Bleu (Capgemini + Orange + Microsoft), Thales / S3NS, Oracle EU Sovereign Cloud — כל אחת נוגעת בממד ספציפי של Schrems II + סעיף 28 של DORA; אף אחת אינה תשובת מפתח-במפתח.
- נדרשות ראיות יציאה שנבדקו. סעיפים 81 ו-113-117 של EBA/GL/2019/02. תרגיל-שולחן רבעוני אינו מספק; המפקחים מצפים לבדיקת יציאה שנתית מקצה-לקצה לכל פונקציה קריטית או חשובה.
- RTO / RPO ממלאי ה-CIF. Tier 1: 2h / 15min. Tier 2: 4h / 1h. Tier 3: 24h / 4h. נגזרים מניתוח השפעה עסקית, לא מקיבולת צוות הפלטפורמה.
מדוע חוסן הענן תחת DORA נמצא בשלב הביקורת #
שלוש סיבות מדוע מסגור ה"היערכות" שגוי ב-2026.
ראשית, ציר הזמן. DORA פורסמה בדצמבר 2022. תקופת היישום בת 24 החודשים הסתיימה ב-17 בינואר 2025. ה-RTS וה-ITS הסופיים של רשויות הפיקוח — לרבות ה-ITS על מרשם המידע המשמש לסיווג CTPP — פורסמו לאורך 2024. גל הבחינות הפיקוחי הראשון התרחש לאורך 2025; ממצאים על שלמות מסגרת ניהול סיכוני ICT לפי סעיף 6 ועל התאמת מרשם סעיף 8 הגיעו ברבעון הרביעי של 2025 בכמה מוסדות בדרג ראשון.
שנית, משטר הסיווג של CTPP. סעיף 31 קובע את הקריטריונים לסיווג כספק צד-שלישי קריטי: השפעה מערכתית במקרה של כשל, קריטיות השירותים המסופקים, היקף ומורכבות השירותים, יכולת הסבה. רשויות הפיקוח מנהלות את המרשם ומפרסמות החלטות סיווג. AWS, Microsoft (Azure), Google (GCP) ו-Salesforce נמצאות בתוך פרימטר הסיווג או בקרבתו, בהתאם לנתח השוק שלהן בשירותים פיננסיים לפי מדינת חברה. הסיווג מעניק למפקח הראשי (אחת מרשויות הפיקוח, המוקצית לכל ספק) סמכות פיקוח ישיר: בקשות מידע לפי סעיף 37, ביקורות באתר לפי סעיף 38, המלצות לפי סעיף 35 ומשטר הגילוי הציבורי לפי סעיף 41. הבנקים המפוקחים על אותם CTPPs כפופים לציפיות פיקוחיות מקבילות באשר לאופן ניהול אותה תלות מסווגת.
שלישית, סדרי העדיפויות הפיקוחיים של ECB ל-2026-28. מסמך סדרי העדיפויות נוקב בשתי תכניות מפורשות שמשפיעות ישירות על בנקאות ענן-נייטיב: היערכות לשיבוש מהותי בשירות הענן (תרחישים פיקוחיים מודלים בוחנים את יכולת המוסד לספוג השבתה מתמשכת של CTPP מסווג) ו-TLPT בהתאמה ל-TIBER-EU (כל תרגיל TIBER-EU מקיף את הפונקציות הקריטיות והחשובות של המוסד, שכוללות כעת שירותים המתארחים בענן ציבורי). גל הבחינות של 2026 יפיק ממצאים בשתי הזירות.
המסגור ל-2026 אינו "DORA בדרך"; הוא "ממצאי בחינות DORA מגיעים לתיבת הדואר של המוסד שלכם, והחלטות הנדסת הפלטפורמה שקיבלתם במהלך 2024-2025 הן מה שהמפקח בוחן בממצאים האלה."
ארכיטקטורת המדד ל-2026 #
| שכבת מדד | איך נראית "מוכנות" | מדד המוכנות | אופן הכישלון |
|---|---|---|---|
| בשלות הפלטפורמה | יותר מ-80% מעומסי העבודה על פלטפורמת Kubernetes של מסלול סלול (EKS / AKS / GKE / OpenShift) עם admission של policy-as-code, פריסת GitOps ובדיקות DR אוטומטיות | אחוז ה-CIFs על פלטפורמת המסלול הסלול; ספירת פריסות צל; זמן ממוצע להעלאת שירות חדש לפלטפורמה | פלטפורמות צל עם בקרות לא עקביות; CIFs הרצים על תשתית לא סלולה, השקופים להתאמת מרשם סעיף 8 |
| שלמות מרשם סעיף 8 | מרשם המידע מתואם אוטומטית לצריכת ה-API של צד שלישי בפלטפורמה + cloud-bill-of-materials; סיווג הקריטיות עקבי עם מלאי ה-CIF של המוסד | אחוז רשומות המרשם המותאמות לטלמטרית הפלטפורמה; ספירת רשומות יתומות; בדיקת שלמות פרימטר ה-CTPP | רשויות הפיקוח מזהות תלות ב-CTPP מסווג שהמוסד לא חשף לפי סעיף 8; ממצא נקודתי והשלכת פרימטר CTPP |
| ריכוז בענן | פונקציות קריטיות ממופות לספקי ענן וגם לאזורי תת-ענן וגם לשירותים וגם להערכת הסבה; חשיפה מתואמת בין CIFs מכומתת | ציון ריכוז לכל CIF; חשיפה מתואמת בין CIFs החולקים אזור CTPP מסווג | השבתה אחת של AWS us-east-1 IAM מפילה ארבעה CIFs שהמוסד חשב שמומנו בנפרד |
| יכולת יציאה שנבדקה | בדיקת ביצוע יציאה שנתית מקצה-לקצה לכל CIF התלוי ב-CTPP מסווג; RTO / RPO מתועדים עומדים ביעדים הנגזרים מ-BIA; מסלול ניידות נתונים נבדק | שיעור הצלחת הבדיקה לכל CIF; זמן ממוצע לביצוע יציאה מול יעד RTO; השהיית מסלול ניידות הנתונים | תכנית יציאה הקיימת רק כקובץ PDF; תרגיל-שולחן אומר RTO של 4h, בדיקה בפועל מראה 48h בניסיון הראשון |
| תצפיתיות + דיווח אירוע | תיעודי OpenTelemetry מקצה לקצה בין השירותים; עוזר סיווג אוטומטי של 4 שעות לפי סעיף 18 משולב בפלטפורמת ניהול האירועים | אחוז התעבורה של CIF המכוסה בתיעודי OTel; זמן ממוצע מזיהוי אירוע עד החלטת סיווג לפי סעיף 18 | אירוע מהותי מסווג מחוץ לחלון 4 השעות כי קביעת הקריטיות דרשה ישיבת טריאז'; ממצא לפי סעיף 18 |
| שילוב TLPT | היקף ה-TLPT נגזר ממלאי ה-CIF ומתרענן ברציפות; הממצאים מוזרמים בחזרה ל-policy-as-code של הפלטפורמה; ממצאים סגורים מפיקים חבילות ראיות מוכנות לפיקוח | שיעור סגירת ממצאי TLPT; זמן מחזור מממצא לעדכון מדיניות | TLPT מגלה פגיעות שצוות הנדסת הפלטפורמה של המוסד לא יכול לתקן בפחות משני מחזורי שחרור |
אותות עכשוויים למעקב #
| אות | המשמעות לבנקים | מקור |
|---|---|---|
| DORA באכיפה פעילה מאז 17 בינואר 2025 | ממצאים פיקוחיים מהגל הראשון הגיעו ברבעון הרביעי של 2025; ממצאי הגל השני צפויים לאורך המחצית השנייה של 2026 | EUR-Lex ⧉ |
| סיווג CTPP נפתח לאורך 2025-2026 | AWS, Microsoft, Google, Salesforce בתוך הפרימטר או בקרבתו; הסיווג מעניק לרשויות הפיקוח זכויות פיקוח ישיר | EBA ⧉ |
| סדרי העדיפויות הפיקוחיים של ECB ל-2026-28 נוקבים במפורש בשיבוש בענן | תרחישים פיקוחיים מודלים בוחנים את היכולת לספוג השבתה מתמשכת של CTPP מסווג | פיקוח הבנקאות של ECB ⧉ |
| TIBER-EU מותאם לסעיף 26 של DORA | היקף ה-TLPT מכסה פונקציות קריטיות / חשובות, לרבות שירותים המתארחים בענן | TIBER-EU של ECB ⧉ |
| קווי המנחה למיקור-חוץ של EBA (EBA/GL/2019/02) משתלבים עם סעיף 28 של DORA | נוכחות מהותית (סעיף 64), הערכת הסבה (סעיף 81), אסטרטגיית יציאה (סעיפים 113-117) — הסעיפים שהמפקחים בוחנים בפועל | EBA ⧉ |
| טיוטת EU Cloud Services Scheme (EUCS) מתקדמת | תכנית הסמכה עתידית לענן ריבוני תחת חוק הסייבר האירופי; טיוטה שפרסמה ENISA | ENISA EUCS ⧉ |
הנדסת פלטפורמה: חמשת היסודות הייעודיים #
בשלות ענן-נייטיב ב-2026 מצטמצמת לחמישה יסודות הנדסיים שמשתלבים זה בזה ומפיקים ראיות פיקוחיות בקצב צנרת הפריסה. חסרון של אחד מהם הוא ממצא שמחכה לקרות.
1. מסלולים סלולים מבוססי Kubernetes #
כל CIF רץ על פלטפורמת Kubernetes מנוהלת — EKS, AKS, GKE או OpenShift על CTPP מסווג, או חלופה מנוהלת על ידי ספק. צוות הפלטפורמה מפעיל דפוס אשכול זהב יחיד עם סטייה מבוקרת: צמתים מתמונת בסיס מתועדת; בידוד namespace-לכל-צוות; פרופיל pod-security-standards-restricted; מדיניות רשת; הזרקת service-mesh (Istio או Linkerd) לאימות ולתצפיתיות בין-שירותים. שירותים חדשים מצטרפים למסלול הסלול דרך תהליך הצטרפות מתבנת שמייצר את רשומת מרשם סעיף 8 כתוצר של פריסה.
2. פורטל מפתחים בסגנון Backstage #
פורטל מפתחים מרכזי — Backstage ⧉ של Spotify בקוד פתוח הוא יישום הייחוס, לצד חלופות ארגוניות מגוונות — מספק את מערכת הרישום עבור מה רץ והיכן. הקטלוג מציג כל שירות, בעלים, תלות, סיווג קריטיות, runbook ומשמרת on-call. הפורטל משתלב עם מרשם סעיף 8: כל רשומת קטלוג ממופה לרשומת מרשם; רשומות ללא הפניה למרשם גורמות לכישלון CI; רשומות מרשם ללא נוכחות בקטלוג מעוררות התראות מקדימות-מפקחים.
3. פריסת GitOps באמצעות ArgoCD או Flux #
פריסת ייצור עוברת דרך בקר GitOps — ArgoCD או Flux הם תקן הייצור ב-2026 — שמיישב מצב הצהרתי מנוהל-Git לאשכול הרץ. kubectl apply ידני מושבת; המסלול היחיד לייצור הוא pull request שמוזג. מאגר ה-Git הוא שובל יומן הביקורת; מפקחים השואלים "הראו לי את התצורה של שירות X בתאריך Y" מקבלים תגית Git, לא צילום מסך.
4. Open Policy Agent ברמת ה-admission #
Open Policy Agent (OPA) יושב בשרשרת ה-admission של האשכול ואוכף את מדיניות הפלטפורמה: עמידה בפרופיל pod-security, מקור התמונה, מגבלות משאבים, נוכחות מדיניות רשת, שכפול מתאים לתיר הקריטיות, מיקום בתת-אזור תחת אילוצי ענן ריבוני. המדיניויות מנוהלות ב-Git ומנוהלות-שינויים לצד תצורות השירותים. פריסות שנדחו מפיקות נימוקים הניתנים לסקירה שמזינים את חבילת הראיות לניהול השינוי.
5. OpenTelemetry מקצה לקצה #
כל שירות פולט תיעודי OpenTelemetry, מטריקות ויומנים. צוות הפלטפורמה מפעיל צינור תצפיתיות מרכזי — בדרך כלל Tempo או Jaeger לתיעודים, Prometheus למטריקות, Loki או OpenSearch ליומנים — שמשטיח בריאות CIF מקצה לקצה, מיפוי תלויות וקלטים לסיווג אירועים. חלון הסיווג בן 4 השעות של סעיף 18 מתחיל עם הזיהוי; צינור ה-OTel מקצר את המסלול מזיהוי לסיווג להפיכתו לחיפוש בר-שאילתה, לא ישיבת טריאז'.
ענן ריבוני כהנדסה, לא כמיתוג #
אסטרטגיית ענן ריבוני ב-2026 חייבת להשיב על ארבע שאלות ספציפיות של Schrems II + DORA + מיקור-חוץ של EBA:
- היכן הנתונים מעובדים ומאוחסנים? מיקום במדינת חברה באיחוד האירופי; תת-אזור לזרימות בקריטיות גבוהה; התחייבויות מקום נתונים בכתב.
- למי יש גישה משפטית לנתונים? הפעלה על ידי עובדים מקומיים בלבד; בקשות גישה של ממשלות זרות כפופות להליך בית משפט מקומי; תגובה לבקשות גישה חוקיות שנבדקה.
- מהו פרופיל ההסבה? הערכת הסבה לפי סעיף 81 של EBA/GL/2019/02; ביצוע יציאה שנבדק; ספק חלופי מזוהה וחתום בחוזה (או מתועד מדוע אינו ישים).
- מהו מודל הריבונות הטכני? מפתחות בשליטת הלקוח; הפרדה קריפטוגרפית; מישור ניהול ריבוני; שרשרת אספקה ניתנת לביקורת.
חלופות הספקים של 2026 שמתייחסות לשאלות אלה:
- AWS European Sovereign Cloud (הוכרזה ב-2023, GA צפויה במחצית השנייה של 2026): אזור פיזי המופעל על ידי חברת בת של AWS תושבת האיחוד האירופי; הפעלה ותמיכה תושבות איחוד אירופי; מפתחות בשליטת הלקוח באמצעות דפוס KMS-XKS. בהמתנה ליישור תוכן חוזי של סעיף 28 של DORA ב-2026.
- Microsoft EU Data Boundary (GA 2024) + Bleu (Capgemini + Orange + Microsoft, צרפת בלבד): Data Boundary שומרת נתוני לקוחות באיחוד האירופי באזורי האיחוד; Bleu הוא הענן הריבוני הצרפתי בהתאמה ל-SecNumCloud שמריץ את ה-stack של Microsoft Azure תחת שליטה תפעולית צרפתית.
- שותפויות הריבונות של Google Cloud: Thales / S3NS בצרפת (מקבילה ל-Bleu); T-Systems בגרמניה.
- Oracle EU Sovereign Cloud (GA 2023): דפוס דו-אזורי (Frankfurt + Madrid) עם הפעלה תושבת איחוד אירופי; תואם Schrems II באופן נקי.
- ספקים בהתאמה ל-Gaia-X (OVHcloud, Scaleway, Stackit, Aruba Cloud, IONOS): ספקים אירופיים מולדים עם תיוג Gaia-X; היקף ואקוסיסטם קטנים מאלו של ההיפר-סקיילרים אך ללא חשיפה ל-Foreign Intelligence Surveillance Act.
ההכרעה האסטרטגית כמעט אף פעם אינה בינארית. בנקים בדרג ראשון בדרך כלל מפעילים תצורת היפר-סקיילר-עם-Data-Boundary לרוב עומסי העבודה, חלופת ענן ריבוני לזרימות רגישות מסווגות (למשל מערכות ניהול תיקי AML / סנקציות המטפלות בנתונים אישיים של תושבי האיחוד), ומסלול הסבה-מתחזק שנבדק שנתית תחת סעיף 28 של DORA.
ביצוע יציאה שנבדק #
סעיפים 113-117 של EBA/GL/2019/02 ⧉ הם הוראות אסטרטגיית היציאה. הטקסט מפורש לגבי הנדרש: "מוסדות ומוסדות תשלום צריכים להבטיח שהם יכולים לצאת מהסדרי מיקור-חוץ ללא הפרעה בלתי מוצדקת לפעילותם העסקית… אסטרטגיות היציאה צריכות להיות מתועדות ומבדוקות כחלק מהסקירות התקופתיות של הסדרי מיקור-החוץ."
הציפייה הפיקוחית ב-2026 היא בדיקת ביצוע יציאה שנתית מקצה-לקצה לכל CIF התלוי ב-CTPP מסווג. תרגילי-שולחן וסקירת מסמכים אינם מספיקים. הבדיקה חייבת להפיק:
- מדידת זמן-לשחזור: זמן בפועל מהכרזת היציאה ועד שחזור עומס העבודה אצל הספק החלופי, מול יעד ה-RTO הנגזר מ-BIA.
- ראיות לניידות נתונים: ייצוא נתונים שנבדק מהראשי, מאומת מול מסלול הייבוא של ספק היעד, עם ראיות התאמה.
- שקילות פונקציונלית: עומס עבודה שנבדק רץ אצל הספק החלופי עם SLOs שווי-ערך.
- ראיות עלות: עלות ביצוע יציאה מתועדת מול הנחת עלות-השחזור בתכנון מצבי החירום של המוסד.
הניסיון הראשון לבדיקת יציאה מקצה-לקצה של CIF מגלה בדרך כלל פער של פי 5-10 בין ה-RTO המתועד ל-RTO בפועל. סגירת הפער הזה היא עבודה הנדסית שאורכת חודשים. בנקים שמגלים זאת במהלך ביקורת פיקוחית, ולא במחזור הבדיקה השנתי שלהם, ניצבים בפני מחזור ממצאים ברבעון השלישי שניתן היה להימנע ממנו.
יעדי RTO / RPO ממלאי ה-CIF #
כל פונקציה קריטית או חשובה ממופה לסיווג תיר הנגזר מניתוח ההשפעה העסקית של המוסד. התיר מניע את יעדי ה-RTO וה-RPO שצוות הנדסת הפלטפורמה מתחייב לספק.
| תיר | דוגמאות | RTO | RPO |
|---|---|---|---|
| Tier 1 (קריטי משימתית) | קישוריות RTGS (CHAPS / T2 / Fedwire), הרשאת תשלום קמעונאי, אימות לקוחות לערוצים דיגיטליים | 2 שעות | 15 דקות |
| Tier 2 (קריטי) | סינון AML / סנקציות, צינורות זיהוי הונאה, הרשאת ATM, עיבוד תשלומים אצוותי | 4 שעות | שעה |
| Tier 3 (חשוב) | דיווח והגשה רגולטורית, מאגרי ידע פונים-ללקוח, פלטפורמות שיתוף פעולה פנימיות | 24 שעות | 4 שעות |
| Tier 4 (לא-קריטי) | מערכות HR פנימיות, כלי שיווק, דיווח שאינו פונה-ללקוח | 72 שעות | 24 שעות |
המספרים האלה ממחישים — ה-BIA של המוסד מפיק שלו. תוצר הנדסת הפלטפורמה הוא יכולת שנבדקה ברגרסיה לעמוד ביעדים הנגזרים מ-BIA, מוכחת באמצעות בדיקות DR אוטומטיות לכל שירות ומאומתת באמצעות בדיקת ביצוע היציאה השנתית עבור CIFs התלויים ב-CTPP.
מה המשמעות לפי סוג הבנק #
בנקים חשובים מערכתית גלובלית #
הבעיה הקשה היא קנה מידה לרוחב קווי העסק: אלפי שירותים, מאות CIFs, חשיפות מרובות ל-CTPPs מסווגים על פני מוצרים, תחומי שיפוט ופרופילי חוסן. ההשקעה היא ביכולת הנדסת הפלטפורמה המרכזית — מסלולים סלולים של Kubernetes, פורטל Backstage, GitOps, OPA, OTel — שמפיקה את התאמת מרשם סעיף 8, מפת ריכוז ה-CTPP ויכולת ביצוע היציאה לכל CIF, ללא בנייה ייחודית לקו עסקי.
בנקים אוניברסליים ובינוניים #
ההשקעה בהנדסת פלטפורמה מוצדקת בדרג הזה אך ההיקף מוגבל: בחרו את שניים-שלושה ה-CIFs בעלי הקריטיות הגבוהה ביותר, בנו סביבם את דפוס המסלול הסלול, וקבלו שמערכת המורשת ממשיכה תחת הבקרות הקיימות בטווח הבינוני. המיצוב הפיקוחי חשוב יותר מרוחב הפלטפורמה — יכולת להוכיח שלמות מרשם סעיף 8 של DORA ויציאה שנבדקה עבור שלושת ה-CIFs המובילים מכסה את עיקרי דאגות המפקח.
בנקים אזוריים וקטנים #
בחירת ספק במקום בנייה פנימית. בחרו ספק פלטפורמת בנקאות שהארכיטקטורה שלו ב-Kubernetes-native מתועדת, ששילוב מרשם סעיף 8 בו מובנה ושהתחייבויות התוכן החוזי שלו לפי סעיף 28 של DORA ברורות. יכולת ההנדסה הפנימית סובבת תצורה, ניטור ותגובה לאירועים — לא בניית פלטפורמה.
פינטקים, PSPs וספקי SaaS המשרתים בנקים #
שאלת המוצר עבור ספקים שמוכרים לבנקים אירופיים ב-2026 היא האם הפלטפורמה מפיקה את רשומות מרשם סעיף 8 ואת התוכן החוזי לפי סעיף 28 של DORA שתפקיד הציות של הבנק זקוק להם. ספקים עם פלטים מובנים זוכים בעסקאות ארגוניות; ספקים עם תבניות PDF מפסידים למתחרים עם JSON מובנה.
מסקנה #
חוסן הענן תחת DORA נמצא בשלב הביקורת. החלטות הנדסת הפלטפורמה שהתקבלו במהלך 2024-2025 הן מה שמחזור הפיקוח של 2026 בוחן. המוסדות שייראו אמינים בעיני ECB ו-EBA ב-2026-2028 הם אלה שמפעילים מסלולים סלולים של Kubernetes עם פורטלים בסגנון Backstage ופריסת GitOps תחת admission של Open Policy Agent עם OpenTelemetry מקצה לקצה — מפיקים ראיות למרשם סעיף 8 כתוצר של פריסה וראיות ביצוע יציאה שנבדקו כמחזור שנתי, לא כתגובה לבקשה פיקוחית.
המוסדות שלא ביצעו את אותן השקעות יגלו אם צוות הציות בקו השני שלהם יכול לספוג את הסבב הראשון של ממצאי הפיקוח לפני שמגיע הסבב השני.
מדדו את הפלטפורמה כמו שמודדים כל תכנית תפעולית: כיסוי מסלול סלול, שיעור התאמת מרשם, ציון ריכוז CTPP, זמן יציאה שנבדק מול יעד RTO, זמן ממוצע לסיווג לפי סעיף 18, שיעור סגירת TLPT. ראיות בקצב הצנרת; חבילות תיעוד רק כשהמפקח מבקש אחת.
שאלות נפוצות #
האם חוסן הענן תחת DORA עדיין בשלב ההיערכות ב-2026?
לא. DORA באכיפה פעילה מאז 17 בינואר 2025. משטר הסיווג של CTPP תחת סעיפים 28-44 נפתח לאורך 2025-2026. ממצאי בחינות של ECB על ניהול סיכוני ICT לפי סעיף 6 ועל שלמות מרשם סעיף 8 הגיעו בכמה מוסדות בדרג ראשון ברבעון הרביעי של 2025. השאלה הפיקוחית של 2026 היא ראיות בחינה ספציפיות למוסד, לא היערכות רגולטורית.
אילו ספקי ענן מסווגים כ-CTPPs?
רשויות הפיקוח מפרסמות החלטות סיווג באתריהן. המוסדות שבתוך הפרימטר או בקרבתו ב-2026 כוללים את AWS, Microsoft (Azure), Google (GCP), Salesforce ומספר מצומצם של אחרים, בהתאם לנתח השוק בשירותים פיננסיים לפי מדינת חברה. הבנקים המפוקחים על אותם ספקים ניצבים בפני ציפיות פיקוחיות מקבילות באשר לאופן ניהול אותה תלות.
האם ענן ריבוני מבטל את הצורך בתוכן החוזי לפי סעיף 28 של DORA?
לא. ענן ריבוני מתייחס לממד של Schrems II + מקום נתונים; התוכן החוזי לפי סעיף 28 של DORA הוא חובה נפרדת שחלה ללא קשר למקום שבו הנתונים נמצאים. החוזה של ספק הענן הריבוני עדיין חייב לכסות נגישות נתונים, אבטחה, מקום, זכויות ביקורת, אסטרטגיות יציאה והמשכיות לפי סעיף 28.
מהו התוצר ההנדסי שמדגים את חוסן הענן תחת DORA?
חמישה יסודות הנדסת פלטפורמה משתלבים: מסלולים סלולים של Kubernetes (אשכול מנוהל עם סטייה בשליטת מדיניות), פורטל מפתחים בסגנון Backstage (קטלוג שמתואם למרשם סעיף 8), פריסת GitOps (ArgoCD או Flux), Open Policy Agent ברמת ה-admission, OpenTelemetry מקצה לקצה. ראיות בקצב הצנרת ולא ברגע הבחינה.
באיזו תדירות יש לבדוק ביצוע יציאה?
בדיקת ביצוע יציאה שנתית מקצה-לקצה לכל CIF התלוי ב-CTPP מסווג. תרגילי-שולחן וסקירת מסמכים אינם מספיקים. הבדיקה חייבת להפיק זמן-לשחזור, ראיות לניידות נתונים, שקילות פונקציונלית וראיות עלות — מדודים מול יעדי ה-RTO וה-RPO הנגזרים מ-BIA.
הפניות #
- האיחוד האירופי, (2022). תקנה (EU) 2022/2554 — חוק החוסן התפעולי הדיגיטלי (DORA) ⧉.
- רשות הבנקאות האירופית, (2019). EBA/GL/2019/02 — קווי המנחה להסדרי מיקור-חוץ ⧉.
- רשות הבנקאות האירופית, (2026). חוק החוסן התפעולי הדיגיטלי ⧉.
- רשויות הפיקוח האירופיות, (2024). דוח סופי על ה-ITS למרשם המידע תחת DORA ⧉.
- פיקוח הבנקאות של ECB, (2025). סדרי עדיפויות פיקוחיים 2026-28 ⧉.
- הבנק המרכזי האירופי, (2024). מסגרת TIBER-EU ⧉.
- ENISA, (2024). תכנית הסייבר של האיחוד האירופי לשירותי ענן (EUCS) ⧉.
- Spotify, (2020-2024). פורטל המפתחים Backstage ⧉.
- Cloud Native Computing Foundation, (2018). Open Policy Agent (OPA) ⧉.
- Cloud Native Computing Foundation, (2019). OpenTelemetry ⧉.
נסקר לאחרונה .
נסקר לאחרונה .