DORA applies to over 22,000 financial entities in the EU — but most guidance is written for systemic banks with 500-person compliance teams. If you're a small NBFI, payment institution, or investment firm with a lean team, you need a different approach.
The good news: DORA Article 4 explicitly allows proportionate implementation. The regulation recognizes that a 20-person payment institution and a global systemically important bank face fundamentally different risk landscapes. The requirements are the same in principle, but how deeply you implement them should reflect your size, complexity, and risk profile.
Here's what that actually means in practice — a full checklist organized by the five DORA pillars, with clear guidance on what's required, what's recommended, and what small entities can realistically simplify or skip.
Understanding Proportionality Under DORA
Article 4 of DORA establishes the proportionality principle: financial entities shall implement the requirements of DORA "taking into account their size and overall risk profile, and the nature, scale and complexity of their services, activities and operations." This isn't a vague aspiration — it's a legally embedded principle that your national competent authority (NCA) must respect when assessing your compliance.
More concretely, Article 16 defines a simplified ICT risk management framework for entities that qualify. This simplified framework applies to:
Small and non-interconnected investment firms
Payment institutions exempted under PSD2 (Directive 2015/2366)
Institutions exempted under the Electronic Money Directive
Small institutions for occupational retirement provision (IORPs)
Even if you don't formally qualify for the Article 16 simplified framework, the Article 4 proportionality principle still applies. A small NBFI with five ICT vendors and two critical systems is not expected to implement the same depth of controls as a bank with 500 third-party providers and complex interconnected infrastructure.
But — and this is critical — proportionality does not mean exemption. You still need to address every pillar. You still need documentation. You still need to be able to demonstrate compliance to your NCA. What changes is the depth, complexity, and formality of your implementation. The checklist below reflects this reality.
The Checklist: All 5 DORA Pillars
Each item below is marked with a priority level for small and medium financial entities:
Pillar 1: ICT Risk Management
Articles 5–16
ICT risk management framework documented
A written framework that defines how you identify, protect against, detect, respond to, and recover from ICT risks. For small entities, this can be a single document of 15–25 pages. It does not need to be a 200-page enterprise policy suite.
Roles and responsibilities assigned
Someone must own ICT risk management. For small entities, this can be the CISO combined with another role (e.g., CTO, Head of IT). You also need a designated backup. Document who is responsible for what — a simple RACI matrix will suffice.
ICT asset inventory maintained
A complete inventory of all ICT assets, including hardware, software, network components, and data. For small entities, an Excel spreadsheet with clear categorization is perfectly adequate. No GRC platform needed.
Risk assessments performed annually
At minimum, conduct a formal ICT risk assessment once per year and after any significant change to your ICT environment. Document the methodology, findings, and treatment decisions. A risk register in Excel with likelihood/impact scoring works well.
BIA completed for critical functions
A Business Impact Analysis identifying which business functions are critical or important, what ICT systems support them, and what the recovery time and recovery point objectives are. This is the foundation for everything else in DORA.
ICT security policies in place
At minimum, you need documented policies covering: ICT risk management, information security, incident management, and ICT third-party management. For small entities, these can be concise, practical documents. Focus on what your team actually follows, not what looks impressive on paper.
Patch management process documented
A defined process for identifying, testing, and applying security patches. Include timelines for critical vs. non-critical patches. Most NCAs will expect this even if it's a one-page procedure.
Access control policy implemented
Documented access control principles (least privilege, need-to-know) with defined processes for granting, reviewing, and revoking access. Include privileged access management. This is non-negotiable regardless of size.
Data classification scheme applied
Classify data by sensitivity (e.g., public, internal, confidential, restricted) and ensure handling rules exist for each level. For small entities, a three- or four-tier scheme is sufficient.
Awareness training conducted annually
All staff, including management, must receive ICT security awareness training at least annually. For small entities, this can be a structured internal session — you don't need to buy an expensive e-learning platform. Document attendance and topics covered.
Pillar 2: ICT-Related Incident Reporting
Articles 17–23
Incident classification criteria defined
You must classify incidents using all 7 criteria defined in the regulatory technical standards: affected clients, data losses, critical function impact, transactions affected, duration, geographical spread, and economic impact. These are not optional — all seven must be assessed for each incident.
Classification process documented
A clear, repeatable process for how incidents are classified — ideally a decision tree or calculator that any team member can use under pressure. You need to determine within hours whether an incident is "major" and reportable, so the process must be fast and unambiguous.
Reporting timelines established
Major incidents require three reports: initial notification within 4 hours of classification, intermediate report within 72 hours, and a final report within 1 month. Build these deadlines into your incident response workflow and assign clear ownership for each report.
Incident log maintained
All ICT-related incidents must be recorded and maintained in a log — not just major ones. This is your evidence of ongoing monitoring and serves as input for trend analysis. An Excel-based log with consistent fields (date, description, classification, impact, resolution, lessons learned) is compliant.
Communication templates prepared
Pre-draft notification templates for your NCA, for management, and for affected clients. When a major incident happens, you have 4 hours — you don't want to be drafting from scratch under pressure.
Root cause analysis process defined
A documented approach for conducting post-incident root cause analysis. The final incident report requires this, so define the process before you need it. For small entities, a structured template (5 Whys or fishbone diagram) is sufficient.
Pillar 3: Digital Operational Resilience Testing
Articles 24–27
Annual testing program defined
You need a documented program for testing ICT systems and tools at least annually. The scope should cover all critical systems. For small entities, the testing program can be straightforward: define what you'll test, when, and how.
Vulnerability assessments performed
Regular vulnerability scanning of your ICT infrastructure. Automated scanning tools can cover this affordably. Document findings, prioritize remediation, and track closure.
Network security testing conducted
Periodic testing of network defenses, firewall configurations, and segmentation. Can be combined with vulnerability assessments for efficiency.
TLPT (Threat-Led Penetration Testing)
Small entities are generally exempt from TLPT unless specifically designated by their NCA. TLPT is required only for entities identified as significant under Article 26(8). If your NCA hasn't designated you, this is not required — but standard penetration testing is still a good practice.
Pillar 4: ICT Third-Party Risk Management
Articles 28–44
Register of Information maintained and submission-ready
The DORA Register of Information covering all ICT third-party arrangements. This must follow the official EBA template structure (15 tabs) and be ready for submission to your NCA. This is one of the most demanding requirements — start early and keep it updated continuously.
Vendor risk assessment methodology defined
A documented methodology for assessing ICT third-party risk, including criteria for due diligence before engagement and ongoing monitoring. For small entities, a structured Excel scorecard with consistent criteria is compliant and practical.
Critical/important ICT providers identified
Identify which of your ICT third-party providers support critical or important functions. This classification drives the level of due diligence, contractual requirements, and monitoring intensity required for each provider.
Contractual clauses include DORA Article 30 requirements
Contracts with ICT third-party providers must include specific clauses covering: service level descriptions, data processing locations, audit rights, incident notification obligations, exit provisions, and cooperation with authorities. Review all existing contracts and amend where necessary.
Exit strategies documented for critical providers
For every critical or important ICT third-party provider, you need a documented exit strategy. This includes transition plans, data portability provisions, and alternative provider identification. This doesn't need to be a 50-page document — but it must be credible and actionable.
Concentration risk assessed
Evaluate whether you have excessive dependency on a single ICT third-party provider or a small number of providers. Consider what happens if a key provider fails. Document the assessment even if you conclude the concentration risk is acceptable given your size.
Sub-outsourcing chain mapped
Understand and document the sub-outsourcing arrangements of your critical ICT providers. Who do they rely on? Where is data processed downstream? This information feeds into both the Register of Information and your risk assessments.
Pillar 5: Information Sharing
Article 45
Participate in information sharing arrangements
DORA Article 45 encourages — but does not mandate — financial entities to participate in voluntary information sharing arrangements related to cyber threat intelligence. For small entities, this might mean joining a sector-specific ISAC (Information Sharing and Analysis Center), subscribing to threat intelligence feeds from your NCA or industry association, or simply establishing informal information sharing with peer organizations. While not required, this is increasingly seen as a hallmark of mature security programs.
What Small Entities Can Skip (or Simplify)
Proportionality works both ways. While you must address all five pillars, there are several areas where small entities can legitimately take a lighter approach:
TLPT Testing
Threat-Led Penetration Testing is required only for entities designated by their NCA under Article 26(8). Small entities are generally not designated. Standard vulnerability assessments and basic penetration testing satisfy the Article 24–25 requirements for most smaller organizations. Save the budget for controls that matter more at your scale.
Dedicated CISO Role
DORA does not require a dedicated Chief Information Security Officer. The regulation requires that ICT risk management responsibilities be clearly assigned, but the role can be combined with other functions. A CTO who also handles security, or a Head of IT who owns the ICT risk framework, is compliant as long as responsibilities are documented and there's adequate competence.
Enterprise GRC Platforms
You do not need a six-figure GRC platform to be DORA compliant. Well-structured Excel workbooks, properly maintained, are fully compliant. What matters is the content, consistency, and currency of your documentation — not whether it lives in ServiceNow or a spreadsheet. Many small entities will find that purpose-built Excel tools are more practical and maintainable than enterprise software.
Independent Internal Audit for ICT
DORA requires that the ICT risk management framework be audited, but small entities are not expected to have a full independent internal audit function dedicated to ICT. External auditors can fulfill this role. Many small entities already use external audit firms for other regulatory requirements — extend the scope to cover ICT risk management.
Real-Time Threat Intelligence Feeds
While large institutions invest in real-time threat intelligence platforms and dedicated SOC teams, small entities can satisfy the intent of DORA through periodic review of publicly available threat intelligence, NCA advisories, and vendor security bulletins. A monthly review cadence, documented and acted upon, demonstrates adequate awareness.
A Realistic Timeline
If you're starting now (or restarting after an initial attempt), here's a realistic six-month roadmap for a small financial entity with a lean team:
Months 1–2: Gap Analysis + Policy Drafting
Conduct a gap analysis against the checklist above. Identify what you already have (you may be further along than you think) and what's missing. Draft or update your core policies: ICT risk management framework, information security policy, incident management procedure, and third-party management policy. Start building your ICT asset inventory and Register of Information in parallel.
Months 3–4: Implement Tools + Processes
Deploy practical tools: an incident classifier for quick major/non-major determinations, complete the ICT Register of Information, set up vendor risk assessment scorecards, and finalize your BIA. Run your first formal risk assessment. Ensure contractual clauses are reviewed and amendment plans are in place for non-compliant contracts.
Months 5–6: Test, Refine, Prepare for Audit
Conduct vulnerability assessments and testing. Run a tabletop exercise for your incident response process. Validate your Register of Information for completeness and consistency. Conduct awareness training. Compile your compliance evidence into a structured folder that an auditor or NCA inspector can navigate easily.
Ongoing: Maintain and Improve
DORA compliance is not a one-time project. Maintain the Register of Information as contracts change. Log all ICT incidents consistently. Reassess vendor risk when contracts renew or providers change. Update risk assessments annually or after significant changes. Keep training current. The key is building sustainable processes, not just documents.
The regulation is the same for everyone. The implementation shouldn't be.
Focus on substance over process, practical tools over frameworks, and compliance that your team can actually maintain. A small entity with a clear, well-maintained set of Excel-based tools and concise policies is in a far better position than a large institution with an expensive GRC platform that nobody keeps updated.
Proportionality is your advantage. Use it deliberately, document your reasoning, and build a compliance program that serves your organization — not one designed for a bank 100 times your size.