Article 16 DORA simplified ICT risk management

What the Article 16 simplified ICT risk management framework asks for

If you are a compliance lead at a small investment firm, an exempted payment institution, an exempted electronic money institution or a small occupational retirement provision institution, the first question is whether Article 16(1) of DORA applies to you. If it does, Articles 5 to 15 are disapplied for your entity, so you do not have to build the full Chapter II governance and framework structure those articles describe. That relief is narrower than it sounds. You still need a sound, documented ICT risk management framework, continuous monitoring of your ICT systems, tools that are sound and kept up to date, prompt detection and handling of incidents, identification of your key ICT third-party dependencies, and continuity plans for critical or important functions that at minimum cover backup and restoration and are tested regularly.

The detailed expectations for this lighter regime sit in Title III of Commission Delegated Regulation (EU) 2024/1774, Articles 28 to 41, which covers governance, information security policy, asset classification, physical and access controls, operations, security testing, change management, business continuity and the review report. Confirm with your competent authority which of these elements it expects you to evidence in practice, since the simplified regime does not reduce the substance of what a supervisor will ask to see.

The hardest obligation is the review required by Article 16(2). The framework must be documented, reviewed periodically and reviewed again after a major ICT-related incident, and you must be able to submit a review report to the competent authority on request. Plan this as a standing calendar item with named owners, a dated record of each review, and a way to show what changed and why. Ask whoever prepares your framework to confirm how the review report will be produced and kept current, because a report written once and never updated is the most common gap a supervisor finds.

Which entities qualify for the simplified ICT risk management framework

Article 16 gives a lighter regime to five groups of smaller financial entities, but qualification depends on the entity's own status and on how its ICT is structured. The cards below cover the five groups in Article 16(1) and the scoping questions that change how much work the simplified framework still requires.

Small and non-interconnected investment firms

Article 16(1) covers small and non-interconnected investment firms, a category that depends on the firm's size and on whether it is interconnected with other market participants. Firms that trade through central counterparties, clearing members or other market infrastructure should check whether that activity makes them interconnected. Confirm the firm's classification against the Article 16(1) text and with its competent authority before relying on the lighter regime.

Exempted payment institutions under PSD2

Payment institutions exempted under PSD2 fall within the simplified regime, but the exemption is the trigger, not the size of the payment business alone. An institution that loses or does not hold an exemption falls back to the full Chapter II requirements. Payment firms should confirm their exemption status in writing and track any change, since it determines which articles of Chapter II are disapplied.

CRD-exempted credit institutions

Institutions exempted under the Capital Requirements Directive can qualify only where the member state has not excluded them under Article 2(4). Two conditions must both hold, so an exempted institution should not assume eligibility. Check the national transposition of the exemption and record the answer, because supervisors will ask how the entity reached its position.

Exempted electronic money institutions

Exempted electronic money institutions are the fourth group named in Article 16(1). Their qualification follows the exemption granted under the applicable rules, and it should be documented alongside the entity's licence records. Where an e-money institution also provides payment services or other activities outside the exemption, map each activity to the correct regime before assuming the simplified framework applies to all of it.

Small occupational retirement provision institutions

Small institutions for occupational retirement provision are the final group in Article 16(1). Their size test and the data they hold on scheme members both matter, because a small pension vehicle still processes sensitive personal and financial data. Confirm the size criteria with the national authority and document the result, since the simplified framework does not reduce the need to protect that data.

Critical or important functions

Qualifying as a small entity does not remove the duty to identify critical or important functions. If a function that would be critical or important runs on ICT, the entity must still ensure continuity with backup, restoration and regular testing. Map each business function to the ICT systems that support it, and treat any function whose failure would materially disrupt service as in scope for the continuity controls.

Shared group and third-party platforms

Where an ICT system is hosted by a group company or a third-party platform, the entity must still identify that dependency and understand who operates each control. Shared platforms can change the work, because the entity needs contractual and evidence arrangements with the provider even when its own framework is simplified. List every shared system in the asset inventory and record which party performs backup, monitoring and access control.

How an assessor tests the simplified framework

This table sets out the steps a competent authority or independent reviewer would take to test a simplified framework under Article 16, what each step examines, the evidence it requests and the gaps reviewers most often report. Read it as a checklist to prepare the records before a request arrives, since the review is document-led and sampled.

Test step	What is tested	Evidence requested	Common findings
Confirm qualification	Whether the entity falls within an Article 16(1) category and has not been excluded from the simplified regime	Licence or authorisation status, size and interconnection analysis, national exemption decisions where relevant	Entity relies on the simplified regime without documenting why its size or interconnectedness qualifies it
Read the documented framework	Whether the framework is sound, written down, approved and covers the Article 16(1) duties	Framework document, approval record, version history, date of last periodic review	Framework exists only in informal practice or has no evidence of management approval
Check Title III coverage	Whether each area named in Title III of Delegated Regulation 2024/1774 is addressed in proportionate terms	Gap map from Title III areas to policies, procedures and owners, such as access control, operations security and change management	Areas such as physical security, data and network security or development are missing or addressed only by reference
Sample monitoring records	Whether ICT systems are continuously monitored and alerts are acted on	Alert logs, monitoring configuration, sample tickets showing triage and closure for selected dates	Monitoring is configured but alerts are not reviewed, or tickets lack owner and closure dates
Sample incident records	Whether incidents are detected, handled promptly and recorded consistently	Incident register extract, timestamps, root cause notes, links to lessons learned	Incidents recorded in email or chat with no consistent severity or timeline
Check backup and restoration tests	Whether backup and restoration are in place for critical or important functions and tested regularly	Backup job reports, restore test results with dates and scope, integrity verification output	Backups run successfully, but no restore has been tested or the test covers only a few files
Review the post-incident report	Whether the framework was reviewed after a major ICT-related incident and whether a review report is available	Review report, change log to the framework, sign-off, evidence of the report being available to the authority	No review after a major incident, or the report does not explain what changed and why

How to implement the simplified framework in order

The sequence below takes a small or exempted firm from confirming that it qualifies to a documented framework, tested continuity arrangements and a review report it can hand to its competent authority on request. Each step ends with a record that shows the work was done.

Confirm qualification in writing
Start by checking whether the entity falls within Article 16(1): a small and non-interconnected investment firm, a payment institution exempted under PSD2, a CRD-exempted institution where the member state has not excluded it, an exempted electronic money institution, or a small occupational retirement provision institution. The management body or the owner of the decision should record the analysis and the conclusion in a dated qualification memo, noting the national competent authority's position where it has one. Ask the competent authority to confirm any point that is unclear for your category. The memo is complete when it is signed and filed with the framework documents.
Document the simplified framework
Write the ICT risk management framework as one documented set covering the areas named in Title III of Delegated Regulation (EU) 2024/1774: governance, information security policy, asset classification, ICT risk management, physical security, access control, operations security, data and network security, security testing, development, change management, business continuity and the review report. Scale each section to the size and complexity of the business, and make sure someone accountable is named for each. The output is a framework document approved by the management body, with a version history.
Map ICT systems and key third-party dependencies
Build an inventory of the ICT systems, data stores and services that support the business, then identify which ones support critical or important functions and which external providers each depends on. Include self-hosted open-source components and their hosting, not only commercial SaaS. Record how each dependency is reached and what would happen if it failed. The inventory is complete when every critical dependency has an owner and an entry in the asset register that the framework refers to.
Set monitoring and incident handling
Define what is monitored, which thresholds raise an alert, who receives it and how an incident moves from detection to containment and recovery. Keep logs of the systems in the inventory and review them on a schedule the firm can actually sustain. Where open-source tooling is used, Grafana Alerting can build alert rules from queries across multiple data sources, covering metrics and logs in one place. Confirm the tool's configuration with the vendor and your environment before relying on it. The output is a monitoring standard, the alert rule list and an incident procedure with a test record showing that at least one alert reached a responsible person.
Define backup, restoration and continuity plans
For each critical or important function, set out the backup scope and frequency, the restoration procedure and the continuity arrangement for when the primary service is unavailable. Article 16(1) requires at least backup and restoration in these plans. Open-source tools such as Bareos (schedules backup, restore, verify and archive jobs with a SQL catalog) or restic (whose check command can read pack files back to confirm stored data is unmodified) can produce the technical evidence. Confirm the restore procedure against the tool documentation and your own configuration. The output is a continuity plan per function and a backup register.
Test the continuity plans regularly
Run restoration and continuity tests on a schedule set in the framework, and record what was restored, how long it took, what failed and what was changed afterwards. Testing should use the same backups and procedures described in the plan, not an idealized version of them. Keep the test records with the framework so that a supervisor can see the plans were exercised, not only written. The output is a dated test log with findings and follow-up actions assigned to named owners.
Schedule periodic and post-incident reviews
Set a review cycle for the framework and trigger an extra review after any major ICT-related incident, as Article 16(2) requires. Record each review with the changes made, the people who approved them and the evidence used. Where the firm uses an external assessor or consultant to support the review, the organization still owns the decision and the review. The output is a review log and a current review report that states the framework's status, open gaps and the owner of each gap.
Keep the review report ready for the competent authority
Article 16(2) allows the competent authority to ask for the review report, so keep it in a form that can be sent on request without reconstruction. The report should draw on the qualification memo, framework document, inventory, monitoring records, continuity tests and review log, and it should be approved by the management body. Ask your competent authority which format or sections it expects, since its supervisory practice may add detail. The output is a dated, approved review report stored where the responsible owner can retrieve it quickly.

What evidence satisfies Article 16 and how to keep it current

Entities under the simplified regime still need a documented framework, and Article 16(2) requires a review report to be available to the competent authority on request. The cards below cover the artifacts an assessor is likely to ask for and how each one stays accurate between formal reviews.

Signed framework document

This is the documented ICT risk management framework that Article 16(1) requires even under the simplified regime, covering the governance, policies and procedures set out in Title III of Delegated Regulation (EU) 2024/1774. Keep a version history with the approving body and date for each revision, and confirm that the document names the owner of each area. Between reviews, update it whenever a system, provider or process it describes changes, so the text never describes a state the organization no longer operates. Ask the auditor which signature or approval format they expect before the document is finalized.

Asset and dependency inventory

The inventory shows which ICT systems support which functions, and which third parties those systems depend on. Assessors use it to test whether the entity identifies key ICT third-party dependencies, as Article 16(1) requires, and whether continuity planning covers critical or important functions. Record the owner, location, version and provider for each entry. Refresh it on every change request, onboarding or decommissioning, and reconcile it against the actual running estate at a fixed interval.

Monitoring and alert configuration records

Article 16(1) requires continuous monitoring of ICT systems and prompt detection of incidents. Evidence here is the rule set itself: which metrics and logs are watched, the thresholds, who receives each alert and how it is acted on. Export or snapshot the configuration, keep it under version control, and log every change with a reason. When an alert rule is added or retired after an incident, record that link so the assessor can trace the lesson into the configuration.

Incident logs with handling notes

Incident records show that the entity detects and handles incidents promptly, as Article 16(1) requires. Each entry should carry the time detected, the systems affected, the classification, the actions taken, the person responsible and the closure decision. Notes should explain the root cause in plain terms so that later reviews can see what changed. Confirm with the competent authority or your own legal advisers which incidents must be reported, because the reporting duties in Chapter III apply separately from the simplified framework.

Backup and restore test records

Article 16(1) requires continuity plans that include at least backup and restoration, tested regularly. Evidence is a dated record of each restore test: the scope restored, the source snapshot, the duration, the result and any defects found. Tools such as restic can verify repository structure and read pack data back to confirm stored content is unmodified, and that output is useful supporting material when the output is saved with the test record. Retest after any change to the backup platform or the protected systems.

Periodic review report

Article 16(2) requires the framework to be reviewed periodically and after each major ICT-related incident, with a review report submitted to the competent authority on request. Keep one report per review cycle that states what was reviewed, the findings, the changes made to the framework and the approval. Treat a major incident as an automatic trigger for an out-of-cycle review, and record that trigger and its outcome in the same report. The report should cite the other artifacts above so the assessor can follow each claim to its evidence.

What meeting the simplified framework costs in money and effort

This table lists the cost components of meeting the Article 16 simplified framework, who carries each one, whether it is one-time or recurring, and what moves it up or down. No figures are given here, so use it to structure a written quote and to see where self-hosted open-source tooling can reduce licence spend.

Cost component	One-time or recurring	Who is paid or who carries the effort	Drivers and what to ask for in a quote
Internal staff time for drafting and approval	One-time, then recurring at each review	Your own staff, management body approval	Scope of the entity, number of policies to write, and the post-incident review cycle. Ask the partner which documents it drafts and which your staff must approve.
Licences or subscriptions for tooling	Recurring	Software vendors	Number of users, data volume and proprietary modules. Ask for a line-by-line list, and check whether the self-hosted open-source option covers the need, such as CISO Assistant for compliance records or Bareos and restic for backup.
Engineering time to configure monitoring and backup	One-time build, then recurring tuning	Internal platform team or an implementation partner under a fixed-scope agreement	Number of systems in the simplified scope, backup targets and alert rules. Ask for the scope, deliverables and timeline in writing before work starts.
Recurring evidence upkeep	Recurring	Your compliance and IT operations staff	Frequency of backup restore tests, log reviews and access reviews. Ask how the tooling generates and stores evidence without manual collection.
External review or testing	Recurring or periodic	Independent security testers or reviewers you engage	Scope of security testing and whether the entity is excluded from threat-led penetration testing under Article 26(1). Ask which tests are required and which are optional.
Assessor or supervisor effort	Periodic, on request	Your competent authority or its appointed assessor	Readiness of the review report and the documented framework. Ask your advisers to confirm which documents the competent authority may request under Article 16(2).

Which self-hosted open-source tools can produce the backup and monitoring evidence

Under the simplified regime, an entity still has to show that its backup and restoration plans for critical or important functions work and that its ICT systems are monitored continuously. Open-source tools can generate records for both, but none of them makes an entity compliant on its own. The evidence must come from the entity's own environment, and the entity must decide whether each tool's output is sufficient for its supervisor. Bareos (AGPL-3.0-only) is the most direct fit for the backup side. Its Director schedules and supervises backup, restore, verify and archive jobs, and it keeps a SQL catalog of backed-up files, so the job history and restore records can be exported for review. Confirm that the AGPL-3.0-only license terms work for how you distribute or modify the software, and confirm that Bareos's verify jobs and catalog retention match the restoration testing schedule your plan commits to.

restic (BSD-2-Clause) offers a second, independent check on backup data. Its restic check command verifies the structural consistency of snapshots, trees and pack files. Adding --read-data or --read-data-subset makes it read pack files back to confirm the stored data is unmodified, which is the kind of integrity evidence the plan's restoration testing can cite. The cost of full reads grows with repository size and storage egress, so decide how often full reads run and which subset is checked in between. Grafana Alerting (AGPL-3.0-only) covers monitoring. It builds alert rules from queries and expressions across multiple data sources, and it alerts on metrics and logs together from one view. Teams should record alert rules, thresholds, routing and acknowledgment history as evidence, and confirm with the platform team that these records are retained for the period the supervisor may request.

CISO Assistant (AGPL-3.0-only) helps organize that evidence against DORA. It ships DORA among more than 200 frameworks, runs audits and compliance assessments against them, and provides automatic mapping between frameworks. Treat those mappings as a starting point for your own review rather than as a finished alignment, because the mapping must be checked against the article text and the Title III requirements in Delegated Regulation (EU) 2024/1774. Confirm that the DORA content in your installed version matches the regulatory texts your supervisor uses, and assign an owner to every assessment item so that a person, not the tool, accepts each piece of evidence. An auditor or competent authority will judge whether the combined evidence meets the requirement, and an implementation partner can prepare the configuration and evidence trail without issuing any attestation.

Who does what: the entity, an implementation partner and the assessor

The financial entity remains the party responsible for its ICT risk management under Article 16. Even when the framework is lighter, the entity must hold a sound, documented framework, decide whether it qualifies for the simplified regime, and be able to show a regulator how it operates. Those decisions cannot be delegated to a vendor or consultant.

Ownership: Management assigns an accountable owner for the framework and confirms that the entity's ICT systems, incidents and third-party dependencies are covered by it.
Approval: The management body or the equivalent senior body approves the framework, the policies it contains and any material changes to them.
Qualification: The entity documents why it falls within one of the categories in Article 16(1) and rechecks that status as its activities change.
Review: The entity reviews the framework periodically and after major ICT-related incidents, as Article 16(2) requires.
Sign-off: The entity signs the review report and holds it ready for submission to the competent authority on request.

Confirm with your competent authority how it expects the review report to be structured and who inside the entity must sign it.

Where small firms usually fall short under Article 16

Firms that qualify for the simplified regime often assume lighter rules mean fewer tests and less documentation. The gaps below cluster around four things: whether the regime applies, whether the framework stays current, whether recovery has been proven, and whether monitoring leads to action. Each card names one gap and one practical way to close it.

Assuming the regime applies

Many firms adopt the simplified framework because they believe they are small, without checking each condition in Article 16(1). The categories include small and non-interconnected investment firms, exempted payment and e-money institutions, and small occupational pension providers, each with its own test. Record the qualification check in writing, with the legal basis for each criterion, and have the management body approve it. Revisit the check whenever the group structure, volumes or licences change.

Framework not reviewed after incidents

Article 16(2) requires the simplified framework to be reviewed periodically and after major ICT-related incidents, and a review report must be available to the competent authority on request. Small teams often update nothing after an outage because the response was handled informally. Set a fixed review trigger in the incident procedure, record what changed in the framework and why, and keep the dated review report ready for inspection.

Backups never tested by restoring

A backup job that reports success proves little about recovery. Firms should restore selected files and systems into a separate environment on a schedule, then compare the results with what the business needs. Tools such as restic can check repository structure and, with --read-data, read pack files back to confirm stored data is unmodified. Keep the restore log as evidence that recovery was tested, not only that backups ran.

Monitoring disconnected from incidents

Alerts that reach an inbox but never open a ticket do not satisfy the expectation that incidents are detected and handled promptly. Link each alert rule to a named owner, a severity and a documented response step, including when the event must be classified and reported. Grafana Alerting can combine metric and log queries and manage alerts from one view, which helps a small team show the path from detection to action.

Key third-party dependencies unmapped

Small firms often rely on a few cloud, hosting, software or outsourced service providers without a written list of which functions depend on them. Article 16 still requires key ICT third-party dependencies to be identified. Build a short register that maps each critical or important function to its providers, data locations and fallback options, and confirm which contracts give the firm the information it needs to act if a provider fails.

Continuity plans miss restoration timing

A continuity plan that lists backups but not how long restoration takes leaves the firm unable to say whether a critical function can recover in time. Write down the expected restoration sequence, the people who perform each step, and the time the business can tolerate. Then compare that estimate with a restore test. Where the test runs longer than planned, change the plan or the backup design before the next incident forces the question.

Questions buyers ask about the Article 16 simplified framework

Can a small firm build the simplified DORA framework in-house?

Yes, if it has the staff and time to do so, and many firms that qualify for Article 16 do the core documentation themselves. The regime is lighter than the full Chapter II framework, but it still asks for a sound, documented ICT risk management framework, continuous monitoring, incident handling, a view of key ICT third-party dependencies, and tested backup and restoration for critical or important functions. The main question is whether someone internal can map each Title III area of Delegated Regulation (EU) 2024/1774 to real systems and evidence, and keep that mapping current. A firm without that capacity usually needs outside help for the gap analysis and documentation, while the organization keeps ownership of every control and decision.

What skills and staff time does the simplified framework need?

The work needs people who know the entity's ICT estate, can read the Title III requirements, and can run backups, monitoring and access reviews. Expect the management body to approve the framework and the person who owns ICT operations to maintain it. Engineers need time to produce configuration evidence, restore tests and alert records, and a compliance lead needs time to keep policies and the review report aligned with how systems actually run. The effort depends on how many systems support critical or important functions, how documented the current estate already is, and how many third parties sit behind those functions.

What drives how long the simplified framework takes to put in place?

The timeline is driven by the size of the in-scope estate, the state of existing documentation, and how quickly backups and restore tests can be proven. Work usually runs faster where asset inventories, access lists and backup jobs already exist and are current, and slower where they must be built from scratch or where restore testing has never been done. Dependencies on third-party providers, approval cycles for policies, and the time needed to fix gaps found during review all add to the schedule. No duration is set in this guide, so ask any provider for a timeline that follows from a written scope and a stated list of assumptions.

What does a partner deliver for the simplified framework?

A partner prepares systems, controls and evidence; it does not decide compliance or issue any report. In practice, a fixed-scope engagement might include a gap analysis against Title III of Delegated Regulation (EU) 2024/1774, drafted policies for the management body to approve, configuration of backup, monitoring and alerting on the agreed platforms, documented restore tests, and an evidence pack for the review report. Ongoing support, upgrades and testing can be added as a retainer. The written scope should name each deliverable, the systems in scope, the entity's own responsibilities, and what is excluded, so that both sides know where the work ends.

Does the simplified regime remove the penetration test obligation?

Not entirely, but it removes the threat-led penetration testing requirement. Entities under Article 16(1) are excluded from threat-led penetration testing under Article 26(1), and from the duty to adopt a strategy on ICT third-party risk under Article 28(2). They still need to test their ICT systems and continuity plans regularly as part of the simplified framework, and the Title III security testing area covers this. A test scope should be agreed with the entity's competent authority expectations and its own risk profile, and any tester should be independent of the systems it examines.

What must the simplified framework review report contain?

Article 16(2) requires the simplified framework to be documented, reviewed periodically and after major ICT-related incidents, and a review report to be made available to the competent authority on request. The report should show what was reviewed, when, by whom, what changed, what gaps were found, and what remediation is planned and owned. Title III of Delegated Regulation (EU) 2024/1774 sets the detailed content, including the review report area, so confirm its exact expectations against that text. Keep the report tied to evidence such as restore records, access reviews and incident reviews so it can be defended on request.

How do I request a quote for simplified framework work?

Send a written description of the entity, its licence category, the critical or important functions in scope, the ICT systems and cloud or data center locations that support them, the existing documents you have, and the deliverables you need. DeployOpen does not publish a price list. Most engagements are fixed-scope, so a quote follows from a written scope, with scope, deliverables and timelines agreed before work starts. Ask any provider to itemize one-time work such as the gap analysis and policy drafting separately from recurring items such as support and periodic reviews, and to state what the entity must supply itself.

How DeployOpen works on this

DeployOpen helps financial entities that fall under the simplified regime prepare the systems, documentation and evidence that Article 16 expects. We plan and implement self-hosted open-source platforms inside your own infrastructure, and we prepare the evidence. Only your management body owns the framework, and only an independent auditor or competent authority reviews it.

How we scope

We confirm which Article 16(1) exemption applies and which Title III areas of Delegated Regulation (EU) 2024/1774 your entity must address.
The written scope lists the systems, business functions, backup chains and documents in scope before any work starts.
Engagements are fixed-scope, with deliverables and timelines agreed in writing, and a quote follows from that scope.

How we build

We implement and harden the open-source tools that support monitoring, alerting, backup and restoration within your own cloud or data center.
We configure backup jobs and restore tests so recovery can be shown with records, not only described in a policy.
We run security testing against the in-scope systems and record findings so remediation can be tracked to closure.

How we hand over

We prepare the documented ICT risk management framework and the review report structure that Article 16(2) requires on request.
We package configuration records, test results, alert rules and restore logs as an evidence set mapped to the Title III areas.
Your staff receive documentation and walkthroughs so the organization can operate and explain the controls without us.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after the initial handover.
We confirm with you which periodic review triggers apply, including reviews after major ICT-related incidents.
Assessment decisions and any attestation remain with your competent authority or an independent assessor, not with DeployOpen.