DORA Readiness and Compliance Audit
From January 2025 the financial sector must comply with DORA - Digital Operational Resilience Act. Check organization readiness, identify gaps and implement requirements before supervisory controls.
Describe your scope — your account manager will reply within 24 hours.
- Free quote
What is a DORA compliance audit?
A DORA (Digital Operational Resilience Act) compliance audit is a comprehensive assessment of a financial organization's readiness to meet EU regulation requirements for digital operational resilience. nFlo evaluates ICT risk management, incident response processes, resilience testing, and third-party provider risk management.
Contact your account manager
Discuss DORA Readiness and Compliance Audit with your dedicated account manager.
DORA is not just IT - it's risk management transformation
From gap analysis to full compliance
Readiness Assessment
Evaluation against DORA's 5 pillars
Gap Analysis
Identifying gaps in each area
Roadmap
Prioritized implementation plan
€2 Million Fine - Inadequate ICT Risk Management
A European bank received a fine from supervisors for inadequate IT vendor risk management. An outage at one cloud provider caused 8-hour downtime of transaction systems. The bank had no exit strategy or resilience tests for critical vendors.
Without DORA compliance:
- Fines set under national law — in Poland, up to PLN 20,869,500 or 10% of total annual revenue (Art. 18zm of the Act on Financial Market Supervision)
- No control over third-party ICT provider risk
- Chaotic incident reporting to supervisors
- Inadequate digital resilience testing
Comprehensive Path to DORA Compliance
We guide you through all 5 DORA pillars - from ICT risk management to threat-led penetration testing. Not just audit, but implementation and documentation preparation for supervisors.
What you get:
- Compliance assessment against DORA’s 5 pillars (Readiness Assessment)
- Gap analysis with action prioritization
- ICT risk management framework compliant with DORA Art. 6
- Critical ICT third-party provider register
- Incident reporting procedures (Art. 17-23)
- Digital resilience testing program (Art. 24-25)
- TLPT (Threat-Led Penetration Testing) preparation
- Documentation for supervisory audits
Who Is It For?
This service is for you if you are:
- A bank, credit institution or credit union
- An insurance or reinsurance company
- An investment firm or investment fund
- A payment institution or e-money institution
- A crypto-asset service provider
5 DORA Pillars
1. ICT Risk Management (Art. 5-16)
ICT risk management framework:
- ICT asset identification and classification
- System and service risk assessment
- ICT risk management policies and procedures
- Protection and prevention mechanisms
- Detection, response, recovery capabilities
- Learning and evolving (continuous improvement)
2. ICT-related Incident Management (Art. 17-23)
Incident management system:
- Incident classification (major vs. other)
- Detection and response procedures
- Incident reporting to supervisors (FCA/ESMA/EBA)
- Threat information sharing
- Root cause analysis and remediation actions
3. Digital Operational Resilience Testing (Art. 24-27)
Resilience testing program:
- Vulnerability assessments and scans
- Open source analysis
- Network security assessments
- Gap analysis
- Penetration testing
- TLPT - Threat-Led Penetration Testing (for large institutions)
4. ICT Third-Party Risk Management (Art. 28-44)
ICT vendor management:
- ICT third-party provider register
- Critical or important ICT services identification
- Pre-contract due diligence
- Contractual requirements (exit strategy, audit rights)
- Continuous vendor monitoring
- Exit plans and contingency measures
5. Information Sharing (Art. 45)
Threat information sharing:
- Participation in information sharing arrangements
- Cyber threat intelligence
- Cooperation with other financial entities
Implementation Timeline
Phase 1: Gap Analysis (4-6 weeks)
- DORA compliance assessment
- Gap identification in 5 pillars
- Roadmap with priorities
Phase 2: Quick Wins (2-3 months)
- Incident reporting procedures
- Critical ICT provider register
- Basic testing program
Phase 3: Implementation (6-12 months)
- ICT risk management framework
- Third-party risk management program
- Advanced resilience testing
- TLPT preparation (if applicable)
Phase 4: Continuous Compliance
- Monitoring and reviews
- Documentation updates
- Reports for management and supervisors
Key DORA Requirements
ICT Risk Management Framework
| Requirement | Description |
|---|---|
| Governance | Board responsibility for ICT risk |
| Risk Assessment | Regular ICT risk assessments |
| Protection | Technical and organizational measures |
| Detection | Anomaly and incident detection |
| Response | Incident response procedures |
| Recovery | Business continuity and disaster recovery |
| Communication | Internal and external communication |
Third-Party Risk Requirements
| Requirement | Description |
|---|---|
| Register | Complete third-party provider register |
| Classification | Critical/important function identification |
| Due Diligence | Pre-contract assessment |
| Contracts | Mandatory contractual clauses |
| Monitoring | Ongoing performance monitoring |
| Exit Strategy | Termination and transition plans |
How does DORA affect ICT third-party access to critical systems?
An ICT provider with administrative access to a bank’s or insurer’s system does not take over responsibility - the financial entity remains fully responsible for its DORA obligations at all times (Article 28(1)(a)). Article 9(4)(c) limits logical access to legitimate and approved functions, and Article 21 of Commission Delegated Regulation (EU) 2024/1774 requires, among others, assigning privileged access on a need-to-use or ad-hoc basis, limiting shared accounts, strong authentication for remote access and, where feasible and appropriate, automated solutions for privileged access management (PAM). In practice, PAM translates this into:
- Task-bound access - the provider receives permissions to a specific system for an approved work window, after which access expires.
- Credentials in a vault, not with the provider - passwords and keys of technical accounts are known to the gateway and can be changed once the work is done.
- Recorded sessions available for audit - every action is attributed to the named account of a specific person on the provider’s side.
- Strong authentication at the gateway - MFA before every remote session, regardless of the target system.
We will design and deploy this for your ICT providers as part of our PAM Implementation service.
PAM supports the technical side of the requirements - it does not replace the register of contractual arrangements, provider assessment, the ICT risk management framework or audit.
Related Glossary Terms
Learn more about key concepts related to this service:
How we work
Our proven service delivery process.
Scoping
Define scope - which entities and systems
Assessment
Compliance assessment against DORA's 5 pillars
Gap Analysis
Detailed gap identification
Implementation
Required mechanism implementation
Documentation
Documentation for supervisors (FCA/EBA)
Benefits for your business
What you gain by choosing this service.
Avoid Fines
Regulatory compliance before supervisor control
Operational Resilience
Better resilience to ICT incidents
Vendor Management
Third-party ICT risk control
Faster Response
Efficient incident reporting to supervisors
Related Articles
Expand your knowledge with our resources.
Third-party vendor access to critical systems: how do you control it under DORA?
The integrator of your core system, the firm that maintains your databases, the infrastructure service provider — each of them logs into systems your institution is accountable for, not theirs. We show how to turn DORA and Delegated Regulation 2024/1774 into concrete decisions about the account, the session and the evidence for audit.
Read more →DORA and penetration testing: a testing programme in which TLPT is the summit, not the starting point
A firm asking "do we have to run TLPT?" is usually asking about the top of the pyramid before it has checked the base. DORA requires a testing programme from almost every financial entity, and TLPT only from those an authority designates. We separate the two levels and give the provision behind every claim.
Read more →IT security audit under NIS2: what will you prove compliance with?
A supervisory authority may demand evidence that your cybersecurity policy is actually being implemented — the directive says so explicitly. Preparation therefore starts with a register of evidence, not with a vulnerability scanner. We break that register down into ten areas and show which artefact closes each one.
Read more →Frequently Asked Questions
Common questions about DORA Readiness and Compliance Audit.
Who does DORA apply to?
All EU financial sector entities: banks, insurers, investment firms, payment institutions, funds, crypto providers. DORA is effective from January 17, 2025.
How much does DORA implementation cost?
Gap analysis: €12,000-24,000. Full implementation for medium bank: €70,000-190,000. For small payment institution: €35,000-70,000. Depends on organization size and current maturity level.
What are the penalties for DORA non-compliance?
DORA itself does not set fine amounts for financial entities — Member States lay down the penalties (Article 50(3)). In Poland, the KNF (Polish Financial Supervision Authority) may fine a financial entity up to PLN 20,869,500 or 10% of its total annual revenue (for insurance and reinsurance undertakings, 10% of gross written premiums), or up to twice the benefit gained or loss avoided through the breach (Art. 18zm of the Act on Financial Market Supervision). The periodic penalty payment of up to 1% of average daily worldwide turnover (Article 35) applies to critical ICT third-party service providers, not to financial entities themselves.
Does DORA replace NIS2?
No - it complements. Financial sector must comply with DORA (more specific for ICT) and may be subject to NIS2. DORA takes precedence in cybersecurity for finance.
What is TLPT in DORA context?
Threat-Led Penetration Testing - advanced penetration test simulating realistic APT attack. Required for large institutions (banks, exchanges) every 3 years. Must be conducted by certified testers.