Wdrożenie polityk i procedur DORA

DORA art. 2 enumeruje 21 kategorii podmiotów finansowych objętych: 1) Credit institutions (banki — instytucje kredytowe per Polish ustawa Prawo bankowe). 2) Payment institutions (instytucje płatnicze per PSD2 — ustawa o usługach płatniczych). 3) Account information service providers (AISP, payment initiation service providers — PISP). 4) Electronic money institutions (instytucje pieniądza elektronicznego). 5) Investment firms (firmy inwestycyjne per MiFID II). 6) Crypto-asset service providers (CASP per MiCA — Markets in Crypto-Assets Regulation). 7) Issuers of asset-referenced tokens (ART issuers). 8) Central securities depositories (CSDs — KDPW w Polsce). 9) Central counterparties (CCPs — KDPW_CCP w Polsce). 10) Trading venues (regulated markets — GPW, MTF, OTF). 11) Trade repositories. 12) Managers of alternative investment funds (AIFMs). 13) Management companies (UCITS management companies). 14) Data reporting service providers (ARMs, APAs, CTPs). 15) Insurance and reinsurance undertakings. 16) Insurance intermediaries, reinsurance intermediaries, ancillary insurance intermediaries. 17) Institutions for occupational retirement provision (IORPs — funds emerytalne). 18) Credit rating agencies. 19) Administrators of critical benchmarks. 20) Crowdfunding service providers. 21) Securitisation repositories. Proportionality (art. 4): smaller entities (microenterprises per Article 2(3) — < 10 employees i < 2 mln EUR balance sheet) mogą applicar simplified ICT risk management framework. Smaller payment institutions, small AIFs, smaller insurance intermediaries — reduced scope per detailed criteria. Important: DORA covers EU entities + non-EU entities providing services to EU customers (extra-territorial scope dla some provisions). For Polish entities: KNF jest competent authority enforcement. ICT third-party service providers serving covered entities — also impacted (must comply with contractual requirements per art. 30, may be designated CTPP per art. 31). Verification: jeśli unsure czy DORA applies — consult Polish Financial Supervision Authority (KNF) guidance lub legal counsel familiar with EU financial regulation.

DORA apply since 17 January 2025 — deadline już minął. Status w 2026: enforcement begun, KNF actively examining compliance during regular supervisory activities. Penalty exposure existing dla non-compliant entities — do 10 mln EUR lub 1% global turnover. Reality dla organizations behind schedule: nie ma legal mechanism dla extending deadline indywidualnie, ale KNF supervisory approach acknowledges varying maturity — focus jest na demonstrable progress (formal commitment, documented roadmap, evidence of remediation activities) rather than perfect compliance from day one. Recommended approach if not compliant: 1) Immediate Gap Assessment — comprehensive review current state przeciwko DORA requirements (4-6 tygodni). 2) Formal Remediation Roadmap — Board-approved plan z timelines per article, demonstrating commitment. 3) Engage KNF proactively — informal communication z supervisory team o organization’s plan, request supportive supervisory approach. 4) Prioritized implementation — address highest-risk gaps first (incident management, third-party register, business continuity), defer lower-priority items. 5) Document everything — every meeting, every decision, every interim policy — demonstrate due diligence. 6) Communicate honestly w board reports + supervisory communications — hiding non-compliance worsens enforcement risk. Realistic catch-up timeline: 6-12 miesięcy dla mid-size entity z dedicated team + external support, longer for complex organizations. Reality check: many EU financial entities są behind on DORA implementation — KNF + other competent authorities understand this. Active demonstrable progress + good faith engagement typically secures supportive supervisory approach. Punishment dla willful non-compliance lub willful misrepresentation — significantly worse than for honest delayed implementation.

DORA contains 64 articles ale w praktyce kluczowe są: 1) Art. 5 (Governance) — Management body accountability dla ICT risk, board training requirement, three lines of defence model. Cornerstone — without proper governance, rest of DORA is theatre. 2) Art. 6 (ICT Risk Management Framework) — comprehensive framework z all components (identification, protection, detection, response, recovery, learning). 3) Art. 9 (Information Security Policy) — top-level policy across cały ICT environment. 4) Art. 11 (Business Continuity Policy) + Art. 12 (Business Continuity Plans) — documented BCP z BIA-derived RTO/RPO, tested annually. 5) Art. 17 (ICT-related Incident Management) — formal incident management procedure. 6) Art. 19 (Reporting Major ICT-related Incidents) — reporting do KNF per ITS templates, timelines 4h initial / 72h intermediate / 1 month final. 7) Art. 24 (Digital Operational Resilience Testing Programme) — comprehensive testing programme. 8) Art. 25 (Testing of ICT Tools and Systems) — vulnerability assessments + penetration testing + end-to-end + scenario-based. 9) Art. 26-27 (Threat-Led Penetration Testing) — dla designated entities (typically systemic banks, CCPs, large insurance). 10) Art. 28 (Third-Party ICT Risk Management) — comprehensive third-party management, Register of Information requirement. 11) Art. 30 (Contractual Arrangements) — mandatory clauses w contracts per RTS. 12) Art. 31 (Critical ICT Third-Party Providers) — designation framework, oversight implications. Less obvious but important: Art. 8 (ICT Asset Management) — comprehensive inventory ICT assets supporting critical functions, often overlooked but foundational. Art. 13 (Learning and Evolving) — formal learning from incidents fed back into framework, often handled informally but DORA requires formal process. Art. 23 (Voluntary Notification of Cyber Threats) — encouraged but not mandatory, demonstrates good faith engagement. Implementation tip: jeśli starting from scratch, focus na art. 5 (governance) + art. 6 (framework) + art. 17 (incident management) + art. 28 (third-party) first — these są foundational. Add other articles iteratively jako programme matures.

Integration kluczowa dla efficiency — nie creating separate compliance programmes dla każdego standardu. Approach: 1) Single Information Security Management System (ISMS) — based na ISO 27001:2023 as foundation (most comprehensive, widely-adopted, third-party verified through certification). 2) Mapping matrix — each control documented z mapping to all applicable standards. Example: „Access Control Policy” maps to ISO 27001 Annex A.5.15-A.5.18, A.8.3 + NIS2 art. 21 ust. 2 lit. i + DORA art. 9 (Information Security Policy) + KNF Rekomendacja D Pkt 8 (Access Control). One policy document satisfies all four — no duplication. 3) Augmentation approach — start z ISO 27001 implementation (typically 60-75% covers DORA technical requirements), add specific gaps: a) DORA-specific additions: Incident classification methodology per RTS (DORA-specific format), Major incident reporting templates per ITS (specific KNF/DORA submission format), TLPT methodology (designated entities only), Register of Information (DORA-specific format z mandatory fields). b) NIS2-specific additions: CSIRT NASK reporting templates (NIS2-specific), supply chain security per art. 21 lit. e (NIS2-specific scope). c) KNF Rekomendacja D specific: Bank-specific control interpretations (e.g. branch office security, ATM security — narrowly Rekomendacja D focused). 4) Unified governance — single Risk Committee covering all frameworks, single Information Security Steering Committee, single Internal Audit covering all. Eliminates 3-4 separate governance structures. 5) Unified internal audit — single annual audit plan covers all frameworks (typically ~30% effort reduction vs separate audits per framework). 6) Unified incident management — one Incident Response Team handles wszystkie incidents, with appropriate reporting to different authorities based na incident type (CSIRT NASK dla NIS2, KNF dla DORA, supervisory authority dla Rekomendacja D, internal stakeholders dla ISO 27001). 7) Documented mapping artifact — formal cross-reference document showing one organizational control = multiple framework requirements. Maintained as living document. Realne savings: typowo 50-65% effort reduction vs separate compliance programmes per framework. One certification audit (ISO 27001) + targeted DORA / NIS2 supervisory reviews vs multiple separate audits.

TLPT (Threat-Led Penetration Testing) per DORA art. 26-27 — najbardziej zaawansowany element testing programme. Designation criteria: not every financial entity must do TLPT — only designated entities. Designation by national competent authority (KNF dla Polish entities) based on systemic importance criteria per art. 26(8) i associated RTS: 1) Size (total assets, balance sheet, transaction volumes). 2) Significance dla financial sector functioning (market share, interconnectedness, substitutability). 3) Cross-border activity. 4) Designation by EU level frameworks (G-SIBs — Global Systemically Important Banks, D-SIBs — Domestic Systemically Important Banks, systemic CCPs per EMIR, systemically important insurance per Solvency II). Polish entities likely designated: top 5-7 banks (PKO BP, Pekao S.A., Santander Bank Polska, mBank, ING Bank Śląski, BNP Paribas Bank Polska, Millennium Bank — most are D-SIBs), KDPW + KDPW_CCP (systemic CCP), GPW Tower, largest insurance companies (PZU, Warta, Allianz Polska — based na systemic criteria), possibly large credit institutions for international entities. Smaller institutions — NOT subject do TLPT but still must do regular penetration testing per art. 25. Frequency: every 3 years minimum (per art. 26(1)). May be more frequent based na supervisor’s risk assessment. Methodology: TIBER-EU framework (TIBER stands for „Threat Intelligence-Based Ethical Red Teaming”, European Central Bank 2018) — extensively documented, mandatory follow for DORA TLPT. Phases: 1) Preparation (Scoping) — 4-8 tygodni: scope definition w cooperation z TIBER Cyber Team (TCT) — independent body coordinating tests, identify critical functions for testing, establish testing rules (no production disruption mandatory, escalation procedures dla detected harmful activity). 2) Threat Intelligence — 4-6 tygodni: Threat Intelligence Provider (TIP — external, separate od Red Team) collects intelligence on specific threat actors likely targeting entity (based on sector, geography, prior incidents), develops realistic attack scenarios. 3) Red Team Testing — 12-16 tygodni active testing: Red Team Provider (RTP — separate od TIP, dedicated red team operator) executes scenarios — phishing, lateral movement, persistence, exfiltration simulation. Blue Team observes (may or may not be aware of test, depending na configuration). 4) Closure — 4-6 tygodni: findings documented, regulator briefing, lessons learned, remediation plan. Total duration: 6-9 miesięcy per cycle. Cost: 1-5 mln zł per cycle (RTP + TIP + TCT + organization’s effort). Output: formal report dla regulator + remediation plan.

Register of Information (RoI) per DORA art. 28(3) — mandatory inventory of all contractual arrangements z ICT third-party service providers. KNF requires submission annually (zgodnie z ITS on Register submission templates). Required fields per provider per ITS on Register of Information (Commission Implementing Regulation): 1) Provider identification — legal entity name, LEI (Legal Entity Identifier), Tax ID, Country of incorporation, Address, Contact person. 2) Service details — Description of services provided, Date of contract commencement, Contract end date (lub indefinite), Renewal terms. 3) Criticality assessment — Service criticality (supporting critical lub important functions yes/no), Functions supported, Substitutability assessment (czy alternative provider easily available — important dla concentration risk i exit strategy planning). 4) Sub-outsourcing — Sub-outsourcing arrangements detail (provider’s own sub-contractors), Sub-outsourcing locations, Sub-outsourcing categories. 5) Geographic information — Country of service delivery, Country of data processing, Country of data storage. 6) Risk assessment — Pre-contract risk assessment date i outcome, Ongoing risk assessment frequency i last review date. 7) Contractual elements — Confirmation that contract contains DORA mandatory clauses (per art. 30 + RTS), Exit strategy reference, SLA targets (key indicators), Audit rights confirmed (financial entity has right to audit provider). 8) Performance monitoring — KPIs monitored, Frequency of monitoring, Last KPI review. 9) Incident-related — Number of incidents involving provider w current reporting period, Description of major incidents. Submission process: structured XBRL format per ITS specifications submitted do KNF (Polish entities) annually za poprzedni rok. Public visibility: aggregated data may be published by ESAs dla market-wide insights into ICT third-party concentration. Realne wyzwania budowy RoI: 1) Inventory completeness — typowo banki mają 200-500+ ICT providers (cloud, software vendors, integrators, consultants, hosting providers, SaaS subscriptions). Mid-market financial entities 50-150 providers. Initial inventory often missing many providers — discovery process intensive. 2) Criticality assessment — challenging dla services indirectly supporting critical functions (e.g. email provider supports communications, communications support customer onboarding, customer onboarding is critical — czy email provider is critical? Generally yes, transitively). 3) Contract review — many existing contracts pre-date DORA i don’t contain mandatory clauses — renegotiation required (typically 12-18 miesięcy effort dla major providers). 4) Sub-outsourcing visibility — providers often don’t disclose all sub-contractors voluntarily — need to push for transparency via contract amendments. Recommendation: dedicated tool dla RoI management (Archer Third-Party Risk, ServiceNow Vendor Risk Management, OneTrust Third-Party Risk, MetricStream Third-Party Risk) — manual spreadsheet management is feasible for small portfolios (< 50 providers) but inefficient at scale.

Bezpośrednio: cloud providers nie są „financial entities” per DORA art. 2, więc nie podlegają DORA jako primary subject. Jednak: indirectly substantially impacted: 1) ICT third-party service providers serving financial entities (most large cloud providers serve significant number financial customers). Through contractual relationships, must support customers’ DORA compliance: mandatory clauses per RTS on Contractual Arrangements (Reg. 2024/2956) — including audit rights for customer’s regulators, sub-outsourcing controls, exit strategies, security obligations, regulatory cooperation requirements. 2) Critical ICT Third-Party Provider (CTPP) designation per DORA art. 31 — Lead Overseer (Joint Committee of ESAs) designates CTPPs subject do direct oversight. AWS, Microsoft Azure, Google Cloud Platform są highly likely candidates dla CTPP designation given systemic importance w financial sector. Designated CTPPs subject do: oversight framework with Lead Overseer assessment (similar to bank supervision), oversight fees (Lead Overseer charges CTPPs), compliance with specific requirements (information sharing with financial customers, support customers’ compliance, allow regulatory inspections). Decision on CTPP designation typowo Q4 2025 — Q2 2026 — Lead Overseer publishing first designations. 3) Contractual compliance — major cloud providers offering DORA-compliant contractual frameworks: AWS Financial Services Industry (FSI) Addendum (DORA-specific contractual provisions), Microsoft Azure DORA support framework (Online Services Terms updated, DPA updates, sector-specific provisions), Google Cloud DORA compliance documentation. Customers must accept these (typically through standard online click-through agreements lub negotiated Master Service Agreements). 4) Audit support — cloud providers offering audit support packages dla financial customers (third-party audit reports, certification artifacts SOC 2 / ISO 27001 / ISMAP, customer-driven audit capability w defined parameters). 5) Practical implications dla financial entities using cloud: implementation often requires contract amendments (existing pre-DORA contracts likely missing some mandatory clauses), risk assessment per provider must consider DORA-specific risks (concentration risk, exit difficulty, geographic data sovereignty, sub-outsourcing chains within cloud providers). Recommendation dla financial entities: 1) Inventory cloud usage (often distributed across departments — Marketing using AWS, IT using Azure, R&D using GCP — central inventory often missing). 2) Review contractual coverage — work z legal team i provider account team for DORA-compliant addendums where needed. 3) Document exit strategy per cloud service — even if difficult (lock-in), need realistic plan. 4) Subscribe do provider DORA communications (AWS / Microsoft / Google publish ongoing DORA compliance updates). 5) Engage internal stakeholders early — cloud architects, security team, procurement, legal — multi-disciplinary effort.

Bezpośrednio: NIE — DORA nie wymaga formal ISO 27001 certification. Praktycznie: extensively beneficial: 1) DORA art. 9 (Information Security Policy) wymaga top-level Information Security Policy adresując confidentiality, integrity, availability — ISO 27001 ISMS dokładnie to dostarcza (ISMS = Information Security Management System). 2) DORA RTS on ICT Risk Management Framework (Reg. 2024/1774) explicit references ISO standards jako acceptable methodology — ISO 27001 controls (Annex A) largely satisfy DORA technical requirements. Implementing ISO 27001 is effectively shortcut do DORA art. 9 + significant portions of art. 6 (Risk Management Framework). 3) Audit efficiency — single ISO 27001 certification audit (annual surveillance, 3-year recertification) jest evidence dla many DORA controls. Without ISO 27001, financial entity musi prove DORA compliance ad-hoc dla every supervisor review — significantly more effort. 4) Third-party assurance — DORA art. 30 (contractual arrangements) requires customer audit rights of providers. ISO 27001 certification jest accepted by most customers in lieu of customer-specific audit — saves provider time + customer effort. Without ISO 27001, providers face many individual customer audits. 5) Insurance + customer trust — cyber insurance underwriters favor ISO 27001 certified entities (lower premium, higher coverage), enterprise customers strongly prefer ISO 27001 certified providers (procurement filtering criterion). 6) Reality check w polskim rynku — większość banks, large insurance companies, payment institutions, asset managers serving institutional clients posiadają ISO 27001. Bez ISO 27001 — competitive disadvantage versus peers. Recommendation dla DORA-affected entities: 1) Jeśli już ISO 27001 — leverage existing ISMS jako foundation dla DORA implementation. Mapping ISO Annex controls do DORA articles, fill gaps (DORA-specific additions). Typowo 2-3 miesiące additional effort vs starting from scratch (saved 6-12 miesięcy). 2) Jeśli nie ma ISO 27001 — strongly recommend pursuing certification w parallel z DORA implementation (12-18 miesięcy combined timeline). Synergies typowo 40-50% effort savings vs sequential implementation. 3) ISO 22301 (Business Continuity Management) — also strongly recommended dla DORA art. 11-12 BCM compliance. 4) ISO 27005 (Risk Management Methodology) — useful reference dla DORA art. 6 risk methodology. ISO standards are not mandatory but pragmatically nearly universal w mature DORA implementations.

Exit strategy is mandatory part DORA framework per art. 28(8): „financial entities shall put in place exit strategies for ICT third-party service providers supporting critical or important functions”. Reason: avoid lock-in scenarios where provider failure (bankruptcy, geopolitical disruption, regulatory action, service degradation) leaves financial entity unable do continue critical functions. Required components of exit strategy per art. 28(8) i RTS: 1) Identification of risk scenarios triggering exit — provider failure, regulatory action against provider, security breach affecting provider, geopolitical change (sanctions on provider’s country, data residency concerns), unsatisfactory performance, end of contract. 2) Alternative providers identified — minimum one viable alternative documented (preferably 2-3). Assessment of alternative provider’s capability, capacity, timeline for migration, cost implications. 3) Data portability — how is data extracted from current provider? Format (data formats — proprietary lub standard, schema compatibility), volume (typowo many TB dla mature usage), bandwidth (extraction timeline given practical limits), encryption (data extracted with encryption keys preserved), legal authority (data ownership clear in contract). 4) Service portability — how are processes migrated? Configuration extraction, custom integrations rebuild, training new provider operations, customer experience continuity. 5) Timeline — exit feasibility within specified timeframe (typically 6-12 miesięcy dla complex cloud services, faster dla commodity SaaS). 6) Cost estimate — full TCO of exit migration, including dual-running phase (using both providers temporarily). 7) Trigger criteria — specific events triggering exit execution (clearly defined, not vague „if provider fails”). 8) Testing — periodic testing of exit feasibility (annually at minimum, ideally with partial migration test — moving small workload to alternative provider). Common challenges: 1) Cloud provider lock-in — moving 100s of services from AWS do GCP může trvat 2-3 years even with best preparation. 2) Custom integrations — proprietary integrations w provider-specific APIs may require complete rebuild. 3) Data egress cost — large data migration z cloud may cost hundreds of thousands USD in egress fees. 4) Vendor cooperation — provider transitioning out may be uncooperative (extending pain dla customer). Contract should specify obligations during exit period (data return formats, transition assistance, knowledge transfer, professional services availability). Mitigation strategies: 1) Multi-cloud architecture — avoid single-cloud lock-in by designing critical workloads with multi-cloud capability from the start (Kubernetes-based deployments portable across clouds, Terraform multi-cloud configurations, vendor-agnostic application designs). 2) Data portability by design — use open standards (PostgreSQL vs vendor-specific DBs, S3-API-compatible storage with multiple provider options, OpenAPI for API designs). 3) Documented runbooks dla migration scenarios — not just plans but tested procedures. 4) Reserved capacity z alternative providers (RFPs for backup providers, even if not currently using). 5) Stronger contract terms — extended notice periods (12+ miesięcy), professional services included for transition, data portability guarantees. Realne: perfect exit strategy is challenging dla cloud — but documented good-faith exit strategy with continuous improvement satisfies DORA requirement.

Cost depends significantly na size, complexity, starting maturity, sector. Realistic price ranges dla polskiego rynku 2026: 1) Small payment institution / small fintech / small asset manager (revenue < 50 mln zł, < 50 employees, simplified DORA per art. 4 proportionality) — Setup: 150-400 tys. zł (gap assessment + documentation suite + initial implementation), Ongoing: 80-200 tys. zł/year (compliance maintenance, annual testing, KNF reporting). 2) Mid-size insurance company / mid-size bank (revenue 100-500 mln zł, full DORA scope) — Setup: 500 tys. - 2 mln zł, Ongoing: 200-600 tys. zł/year. 3) Large bank / systemic insurance (revenue 1-10 mld zł, full DORA + likely TLPT designated) — Setup: 2-10 mln zł, Ongoing: 500 tys. - 3 mln zł/year (including TLPT every 3 years dodatkowo 1-5 mln zł). 4) Systemic infrastructure entities (KDPW, GPW, designated CCPs) — Setup: 5-30 mln zł, Ongoing: 1-5 mln zł/year. 5) Critical Third-Party Provider (CTPP) designated cloud / software provider — Setup: 2-15 mln zł (significant compliance investment), Ongoing: 500 tys. - 5 mln zł/year + Lead Overseer fees (per DORA art. 41-44 — fees TBD by ESAs annually). Specific cost components: 1) Gap Assessment + Roadmap: 50-300 tys. zł (4-6 tygodni). 2) Documentation suite development: 200-800 tys. zł (40-70 documents). 3) Tooling — GRC platform: 100-500 tys. zł/year subscriptions (Archer, ServiceNow GRC, MetricStream, OneTrust GRC, custom) + implementation services 100-500 tys. zł one-time. 4) Training program — Board training (10-30 tys. zł), specialized training (20-100 tys. zł). 5) Vendor contract renegotiation (third-party clauses) — typically 100-500 tys. zł external legal + internal effort. 6) Testing programme — annually: vulnerability assessment + penetration test + scenario testing + BCP test typowo 200-800 tys. zł/year. 7) Internal Audit DORA scope — typowo 50-200 tys. zł/year additional internal audit effort. 8) Ongoing operations — DORA compliance specialist (1-3 FTE for mid-size, 5-15 FTE for large) typowo 200 tys. - 2 mln zł/year. 9) Major incidents handling — variable, dependent na incident severity (typowo 50-500 tys. zł per major incident dla investigation, reporting, remediation, customer notifications). 10) TLPT (designated entities only) — 1-5 mln zł per 3-year cycle. ROI considerations: 1) Avoided penalties — DORA penalties up to 10 mln EUR lub 1% turnover. 2) Avoided operational losses — mature ICT risk management reduces losses 70%+ per studies. 3) Insurance premium reduction — 20-40% dla DORA-compliant entities. 4) Competitive advantage — DORA compliance increasingly expected by customers, partners, regulators. 5) Operational efficiency — formal procedures often improve operations beyond compliance. Free initial consultation available — 1-hour discovery call + Gap Assessment scoping estimate — no cost, no commitment.