Article 13 DORA learning and evolving: requirements

What DORA Article 13 requires a financial entity to learn and keep up to date

DORA Article 13 requires a financial entity to build a working habit of learning from threats, vulnerabilities, incidents and tests, and to feed that learning back into how it manages ICT risk. In practice this means seven duties: gathering threat and vulnerability information, running post-incident reviews after major ICT-related incidents, feeding lessons from tests and incidents into the ICT risk assessment, reporting to the management body at least yearly, delivering compulsory security awareness and resilience training, and monitoring technology developments. If you are the compliance lead or CISO who must show this is met, your evidence has to prove that each duty runs on a schedule and produces outcomes, not just that a policy exists.

The risk behind Article 13 is repetition. An entity that closes an incident ticket without asking why it happened will meet the same failure again, and a control set that was right three years ago may be blind to a current attack pattern. The hard part is that lessons usually stay in tickets, chat threads and post-mortem documents that nobody links to the risk register, and training is often recorded as a course launch rather than as completion by each person. Confirm with your own records whether a named owner can trace one post-incident action to a changed control, a changed risk score and a board report.

Start with the training record and the review trail, because these are the easiest to test. Check whether every employee and senior manager has a completion record for the ICT security awareness and resilience modules, whether third-party staff are included where your contracts and Article 30 arrangements call for it, and whether the board receives a yearly report from senior ICT staff that cites concrete lessons. Ask your team to pick one major incident from the past year and show the review, the risk assessment update and the reporting line that followed. Any gap you find there is a cheaper problem to fix now than during a competent authority inquiry.

Which teams, incidents, staff and providers Article 13 reaches

Article 13 does not apply the same way to every part of an organization. Who is covered, which events trigger a review, who sits in training and whether providers join it each change the amount of work. The cards below name the scoping decision in each case and what it changes for your program.

Entities that carry the monitoring duty

Article 13(7) requires entities other than microenterprises to monitor relevant technological developments continuously and keep up to date with current ICT risk management processes. A microenterprise financial entity is outside that sentence, but it still runs the other learning duties that apply to its size and profile. Confirm your entity's classification before you assign the monitoring role, because the classification decides whether the duty is yours to staff and evidence. Record the decision and the reason in your framework documentation so an assessor can trace it.

Major incidents that disrupt core activities

Article 13(2) triggers a post-incident review only after a major ICT-related incident disrupts core activities. Minor incidents still feed the risk assessment, but they do not require the formal review. Your team must define, in writing, how it measures disruption to core activities and who makes the major classification. Without that definition, reviews happen inconsistently and an assessor will ask why some incidents were reviewed and others were not. Link the threshold to the incident classification your reporting process already uses.

Teams in the post-incident review

A post-incident review under Article 13(2) checks promptness of response, the quality and speed of forensic analysis, escalation and communication. Those questions reach beyond the security operations team into incident commanders, forensic staff, communications owners and the business units that lost service. Assign each review a named owner and list the teams whose actions it will assess. If a team is missing from the review, its gaps will not reach the lessons log, and the same failure can repeat in the next incident.

Staff and senior management in mandatory training

Article 13(6) makes ICT security awareness programmes and digital operational resilience training compulsory for all employees and senior management. The scope is the whole workforce and the management body, not only the technology function. Your training record should show which people completed which module, when, and against which version of the content. Board members and senior managers often need a separate track that covers decisions on ICT risk and incident escalation, so plan that content early.

Module completion as training evidence

Your learning platform must show that each person completed the mandatory modules, not only that the course was published. Moodle's activity completion can mark an activity complete when a learner views it, receives a grade from it, or ticks it manually, depending on the conditions you set. Choose the condition deliberately. Viewing a page proves little, while a graded assessment shows understanding. Confirm the completion rules with your platform team before you rely on them as Article 13 evidence.

Third-party providers in training where appropriate

Article 13(6) includes ICT third-party service providers in the training where appropriate, by reference to Article 30(2)(i). Decide which providers have staff who touch your systems, such as managed security operators, outsourced hosting administrators or implementation partners, and whether their contracts require them to take your modules or an equivalent course. The decision depends on the provider's access and role, so document the reasoning for each provider. Your contracts should name the training obligation and the evidence you will receive.

How lessons from incidents and tests reach the risk assessment

Article 13 asks for more than collecting information. Under Article 13(1), capabilities and staff must gather intelligence on vulnerabilities, cyber threats and ICT-related incidents, and analyse their likely impact on digital operational resilience. Gathering is the easy half. The reviewer will look for a documented decision trail showing what was learned, who assessed it, and which risk register entry, control or test scope changed as a result. A threat feed that nobody reads, or a lessons log that never touches the risk assessment, meets the wording of gathering but not the purpose of the Article.

After a major ICT-related incident disrupts core activities, Article 13(2) requires a post-incident review. The review must test whether procedures were followed and whether actions worked, and it covers promptness of response, quality and speed of forensic analysis, escalation, and communication. For each of these, the file should show timestamps, the decision owner and the evidence relied on. Case management tools such as DFIR-IRIS can keep the incident timeline, evidence hashes and tasks in one record, which makes it easier to show a reviewer the sequence. Confirm with your competent authority how it expects changes to be communicated on request, since the Article ties that obligation to requests from the authority rather than to a fixed schedule.

Article 13(3) expects lessons from threat-led testing and real incidents to feed into the ICT risk assessment continuously, not only when the annual review falls due. Reviewers will look for dated entries that link a finding to a changed risk score, a new control or a re-scoped test. The yearly report from senior ICT staff to the management body under Article 13(5) should then point to those decisions, with the options considered, the choice made and the owner. A report that describes incidents without showing what the board approved, deferred or rejected will read as status reporting, not governance.

How an assessor tests Article 13 learning and evolving

This table compares each Article 13 duty with the test approach an assessor is likely to take, the evidence requested and the finding that appears most often. Supervisors apply their own methods, so confirm expectations with your competent authority before relying on any single approach.

Duty	Likely test approach	Evidence requested	Common finding
Threat and vulnerability intelligence (Art. 13(1))	Ask how threat and vulnerability information is gathered, then pick several recent feeds or advisories and trace each to an analysis of likely impact	Intelligence sources list, analysis records, dated impact assessments, named owners	Feeds are subscribed but no documented analysis of impact on the entity's own services
Post-incident review after major incidents (Art. 13(2))	Sample major incidents and check the review covers response promptness, forensic quality, escalation and communication	Review reports, timelines, action logs, sign-off records	Reviews exist but do not address the Article 13(2) questions or stop before actions are closed
Feeding lessons into the ICT risk assessment (Art. 13(3))	Trace a lesson from a test or incident to a changed control and a updated risk assessment entry	Risk register versions, change tickets linked to incidents or test findings, dated updates	Lessons are recorded in incident tools but the risk assessment is not updated
Yearly reporting to the management body (Art. 13(5))	Check board or management body minutes for an annual ICT report from senior ICT staff and questions raised	Board minutes, annual report, action tracker showing management follow-up	Report is delivered but minutes show no discussion or decisions
Security awareness and resilience training (Art. 13(6))	Check completion records against the employee and senior management population, including content covering current threats	Training curriculum, completion reports by role, dates, assessment results	Completion rates are tracked for staff but not for senior management or updated content
Monitoring technology developments (Art. 13(7))	Ask how new technology and ICT risk practices are monitored, then check that changes were reviewed and acted on	Monitoring log or watch list, review minutes, decisions on adoption or deferral	Monitoring is informal with no record of what was reviewed or why changes were deferred

Evidence that passes for post-incident reviews, threat intelligence and training

Article 13 is assessed through records, not intentions. The cards below describe the artifacts an assessor will ask to see, what each must show, and how the owner keeps it current between audits. Each card names a review cadence so the evidence stays dated and traceable.

Dated post-incident review reports

For each major ICT-related incident that disrupted core activities, keep a written review that records the timeline, root cause, whether procedures were followed, and how promptness of response, forensic quality and speed, escalation and communication performed. Each review ends with dated actions and named owners. Assessors check that actions were completed and that changes can be communicated to the competent authority on request. Owner: the head of ICT operations. Review each report within a fixed period after closure and reconcile open actions monthly.

Lessons-to-controls register

A single register links every lesson from an incident or threat-led test to the action taken and to the specific ICT risk assessment entry it changed. Without this link, an assessor cannot see that lessons were fed continuously into risk assessment as Article 13 requires. Record the lesson source, the affected asset or function, the changed risk rating, and the date the change was approved. Owner: the ICT risk control function. Reconcile the register against risk assessment versions at each scheduled review.

Threat and vulnerability intake records

Show how information on vulnerabilities, cyber threats and incidents enters the organization, who triages it, and what the analysis concluded about likely impact on digital operational resilience. Intake sources can include vendor advisories, sector sharing groups and internal detections. Keep the triage decision, the analyst, and the impact conclusion together so the record stands alone. Owner: the security operations lead. Review open intake items weekly and sample closed items each quarter for quality.

Management body reporting packs

Senior ICT staff must report to the management body at least yearly on ICT risk, incidents, test results and the resilience strategy. Keep the slide or report pack, the minutes showing that members discussed it, and the decisions or resources approved. Minutes that record attendance and questions carry more weight than a pack with no discussion trail. Owner: the chief information security officer or head of ICT. Prepare the pack before each scheduled board or management body meeting and file the minutes within the governance calendar.

Training completion records

Article 13 makes security awareness and digital operational resilience training compulsory for all employees and senior management, and ICT third-party providers are included where appropriate. Keep a learning-platform export showing module completion per person, with dates, versions of the course content, and follow-up for anyone overdue. Platforms such as Moodle record activity completion through configured conditions, so confirm which condition marks a module complete. Owner: the HR or learning lead with the security team. Run completion reports monthly and escalate overdue staff to their line manager.

Technology watch log

Article 13 requires entities other than microenterprises to monitor relevant technological developments continuously and keep up to date with current ICT risk management processes. A watch log lists sources monitored, items reviewed, the assessment of relevance to the ICT estate, and the resulting decision such as no action, a backlog item or a policy update. Assessors look for a steady pattern of entries rather than a single annual summary. Owner: the enterprise architect or security architect. Add entries as items arrive and hold a short monthly review of unresolved decisions.

Sequence to build the learning cycle

This sequence turns the Article 13 duties into a working cycle: intelligence feeds post-incident reviews, reviews and test findings update the risk assessment, and the resulting records support the yearly report to the management body and the training record. Each step closes with an artifact an assessor can inspect.

Assign owners and inputs for threat intelligence
Name the people who collect vulnerability, threat and ICT incident information, and define the sources they watch, such as vendor advisories, internal alerts, incident records and information sharing channels. Assign an analyst role to assess the likely impact of each item on digital operational resilience, as Article 13(1) asks. Done means a written intelligence procedure with named owners, an input list, and a sample intake log showing items triaged and their impact noted. The intake platform is the tool choice, not the requirement; MISP or OpenCTI can hold this record if they fit the team, and the reader should confirm their own fit before committing.
Set the post-incident review template
Build one review template that covers each check in Article 13(2): whether procedures were followed, whether actions were effective, promptness of response, quality and speed of forensic analysis, and escalation and communication. Require the template to be completed after every major ICT-related incident that disrupts core activities. Done means an approved template and a completed sample review, labelled as illustrative if it is a training case, that records findings, root causes and proposed changes. DFIR-IRIS can hold the case timeline and evidence, so the review draws from a single audit trail rather than memory.
Link review actions to the risk register
Convert each finding from post-incident reviews and threat-led or basic testing into a tracked action with an owner, a priority and a link to the affected risk entry. Update the ICT risk assessment so lessons feed it continuously, as Article 13(3) requires. Done means a register extract showing each action, its risk link, its status and its closure evidence, plus records showing which risk ratings changed after a review. Ask the reader to confirm internally how the risk register and the action tracker are kept in sync, since an assessor will test that link directly.
Build the yearly management body report
Have senior ICT staff compile the year's incident reviews, test results, intelligence trends, open actions and strategy progress into one report for the management body. Article 13(4) and (5) require monitoring of how the resilience strategy is implemented and reporting at least yearly. Done means a dated report, a record of the management body meeting where it was received and discussed, and minutes showing decisions or instructions. The report should show what changed as a result of the year's learning, not only what happened.
Launch and track mandatory training modules
Publish security awareness and digital operational resilience training as compulsory modules for all employees and senior management, and include ICT third-party providers where Article 30(2)(i) applies. Use a learning platform such as Moodle to assign modules and record completion. Done means a module catalogue, an assignment list covering every role, and a completion report per person. Moodle's activity completion can mark a module complete on viewing, on grading or on manual tick, so confirm which condition the organization will rely on before the record is presented as evidence.
Run a recurring technology watch
Assign a named owner to monitor relevant technology developments and the latest ICT risk management practices on a recurring schedule, as Article 13(7) requires for entities other than microenterprises. Record each item reviewed, its relevance to the estate, and any decision to adopt, defer or reject it, then feed accepted changes into the risk register and the policy set. Done means a watch log with dated entries and linked decisions. Ask the reader to confirm the review cadence their governance body expects, since the Regulation does not fix one in the text supplied here.

Self-hosted open-source tools that carry the learning evidence

Article 13 asks for threat information, post-incident lessons, yearly reporting and compulsory training to be recorded and reused. The four tools below each hold one part of that trail inside your own infrastructure. None of them makes an entity compliant on its own; they produce records that your processes, owners and assessors then rely on.

DFIR-IRIS for post-incident reviews

DFIR-IRIS is licensed under LGPL-3.0-or-later. It keeps each case as one record of assets, indicators, tasks and evidence, with a full audit trail, and builds a consolidated investigation timeline. For Article 13(2), that timeline is the raw material for a post-incident review that checks promptness of response, forensic speed, escalation and communication. Evidence is logged with SHA-256 verification and chain of custody, and reports are generated from case data. Confirm how your SIEM and EDR alerts reach the tool, who owns case closure, and whether the review template matches what your competent authority may request.

MISP for shared threat indicators

MISP is licensed under AGPL-3.0-only. It correlates indicators by exact match and by advanced patterns such as fuzzy hashes and CIDR overlaps, and it records sightings so you can show which indicators actually appeared in your environment. Events synchronize between MISP instances under granular distribution and sharing groups, and exports run through its REST API to STIX 1 and 2, CSV and Suricata, Snort and Zeek rule formats. This supports the Article 13(1) duty to gather threat information and feed lessons into the ICT risk assessment. Confirm your sharing rules, handling of personal data in indicators, and which exports your detection tools consume.

OpenCTI for structured threat intelligence

OpenCTI is licensed under Apache-2.0. It organizes threat intelligence as STIX-based entities, relationships and containers, and ingests data through connectors and TAXII, RSS, CSV and JSON feeds or manual file upload. Its value under Article 13 is the link between threat actors, campaigns and your own assessed exposure, which lets the ICT risk assessment show how new threats changed priorities. It also shares knowledge through native feeds and exports. Confirm which feeds your sources license for redistribution, who reviews analyst output, and how entries are retained for supervisory review.

Moodle for training completion records

Moodle is licensed under GPL-3.0-or-later. Its activity completion feature marks an activity complete for each learner when they view it, when they receive a grade, or when they tick it manually, depending on the conditions set for that activity. Article 13(6) makes ICT security awareness and resilience training compulsory for all staff and senior management, so the completion record is the evidence that each person in scope finished the module. Confirm that completion conditions match your policy (view alone is weaker than a graded assessment), how you handle staff who leave, and whether ICT third-party providers need access where Article 30(2)(i) applies.

What meeting Article 13 costs in money and effort

This table breaks the cost of Article 13 learning activities into components, showing who is paid, whether each cost is one-time or recurring, what pushes it up and how to keep it down. No fee figures are given, so use it to structure your questions for a written quote. The main takeaway is that most of the recurring cost comes from staff time and the number of incidents, not from software licenses.

Cost component	Who is paid or who spends time	One-time or recurring	What drives it up and how to keep it down
Tooling or licenses	Software vendor or internal platform team	Both: setup one-time, subscriptions recurring	Number of tools in use. Self-hosted open-source options such as MISP, OpenCTI and DFIR-IRIS can remove license spend, but hosting and maintenance remain.
Engineering time for review and ticketing	Internal engineers, or an implementation partner on a fixed-scope build	Mostly one-time build, recurring upkeep	Number of incidents and integrations with alert sources. Keep case templates standard and connect fewer, well-defined sources.
Staff time for training content and tracking	Security awareness lead, HR or learning team, managers	Recurring, usually each training cycle	Number of employees, senior management and relevant third-party staff in scope. Reuse modules and track completion in a learning system such as Moodle.
Management time for the yearly report	Senior ICT staff preparing, management body reviewing	Recurring, once a year at minimum	Volume of lessons learned and metrics to summarize. Keep a running log of findings so the report draws on existing records.
External review of the learning process	Independent reviewer or consultant, if you choose to use one	Usually one-time per review cycle, optional	Scope of the review and how mature the process is. Ask for a fixed-scope proposal that names the documents reviewed.
Auditor sampling	Independent auditor or competent authority inquiry	Recurring with each assessment	Number of samples requested. Keep evidence indexed by date, incident and training cohort so sampling takes less time.

Who owns the learning cycle, who can help, and what the auditor checks

The financial entity owns the learning cycle. Article 13 places the duty on the entity and its management body, so the reviews, the conclusions drawn from them and the decisions that follow must come from people inside the organization who are accountable for ICT risk. An outside party can run tooling or draft material, but it cannot take those decisions on the entity's behalf.

Post-incident reviews: Senior ICT staff decide whether the response to a major ICT-related incident was prompt, whether forensic analysis was of adequate quality and speed, and whether escalation and communication worked. They record the findings and the changes they will make.
Risk assessment updates: The team decides how lessons from incidents and threat-led testing change the ICT risk assessment and the resilience strategy.
Management body reporting: Senior ICT staff prepare the at least yearly report to the management body and own its content, including its account of the monitoring of strategy implementation.
Training decisions: The organization decides which awareness and resilience modules apply to which roles, how often they run, and who is excused from which content.
Technology watch: Named owners track relevant technological developments and decide which ones change the risk management processes.

Confirm that each of these duties has a named owner, a deadline and a record of sign-off before an external party is engaged.

Questions buyers ask about Article 13 before hiring help

How much effort does the Article 13 learning cycle take to run?

The effort depends mostly on how many major ICT-related incidents and significant tests your entity produces, how many systems sit in scope, and how mature your threat intelligence intake already is. Article 13 requires information gathering on vulnerabilities, cyber threats and incidents, post-incident reviews after major incidents, feeding lessons into the ICT risk assessment, yearly reporting to the management body, and tracking technology developments. Recurring work includes reviewing feeds, running reviews, updating the risk assessment and preparing the annual report. Ask any consultant to split the effort into one-time setup (process design, templates, tooling) and recurring tasks (monitoring, reviews, reporting), and to state the assumptions behind each estimate in writing.

Can a small financial entity run the Article 13 learning process in-house?

Often yes, provided the process is proportionate and someone owns it. Article 4 scales DORA's requirements to size and risk profile, and small entities generally have fewer incidents, fewer systems and simpler reporting lines. The minimum practical set is a documented intake of vulnerability and threat information, a short post-incident review template, a risk assessment update trigger, an annual report to the management body and a training schedule. Where the entity lacks staff with security analysis skills, outsourcing the monitoring or the review facilitation is a common choice. Ask whether the entity's own staff can operate the process after handover, not only whether the setup is delivered.

How long does it take to get the first post-incident review and training records in place?

The duration depends on scope, the number of systems and people covered, and whether tooling must be deployed or only documented. Training records need a learning platform, a course catalogue and a way to show completion, while post-incident review needs a template, a case record and an approval path. Neither has a duration in the supplied facts, so ask any provider for a written timeline that lists each milestone, the client responsibilities that gate it (for example, access to systems, staff availability and sign-off dates) and what happens if a dependency slips. A fixed-scope written agreement is the right place to fix these dates.

What does the work need from our staff and management?

It needs named owners and time from several roles. Security and IT staff must supply vulnerability and incident data and join post-incident reviews. Senior ICT staff must prepare the yearly report to the management body, which Article 13 requires at least yearly. Human resources or learning owners must schedule the compulsory awareness and resilience modules for all employees and senior management, and the management body must receive and challenge the report. Ask a provider to map each step to a named role in your organization before work starts, so that gaps in ownership show up during scoping rather than at the first review.

Can an outside consultant take over the management body's responsibility for Article 13?

No. The management body keeps ultimate responsibility for ICT risk under DORA, including approving and reviewing the framework and receiving the yearly report. An implementation partner can prepare the process, the templates, the tooling and the evidence, and can facilitate reviews, but it cannot make the decisions that belong to your board or accept residual risk on its behalf. Independent assessors do not certify DORA compliance either, because DORA sets no certification scheme. Write the division of roles into the engagement so that each decision and each piece of evidence has a named owner inside your organization.

What should we ask a consultant for before signing an Article 13 engagement?

Ask for a written scope listing the Article 13 activities covered, the deliverables for each (for example, a threat intake procedure, a post-incident review template, a training catalogue and an annual report template), and the systems and teams in scope. Request the responsibility split in a table, a written timeline with dependencies, the client effort assumed, and the handover plan for operating the process after delivery. Also ask which parts are one-time and which recurring, what a change in scope costs, which open-source tools are proposed and how they will be hosted in your environment, and what the provider will not do, including any statement that it issues audit reports or certificates.

Which open-source tools support Article 13 evidence, and do they meet the requirement on their own?

Tools can produce evidence for parts of Article 13, but none satisfies the article alone. MISP correlates indicators and shares events between instances with sharing groups. OpenCTI organizes threat intelligence as STIX-based entities and ingests feeds through connectors and TAXII. DFIR-IRIS keeps each case with a full audit trail and builds an investigation timeline that can support a post-incident review. Moodle's activity completion can record that staff viewed or passed training modules. Each tool needs a documented process around it, with a named owner and a retained record. Confirm licensing and any capability you depend on directly with the project documentation before you rely on it.

How DeployOpen scopes and prepares the Article 13 evidence trail

DeployOpen works on the Article 13 evidence trail as a fixed-scope implementation engagement inside the client's own infrastructure. We prepare the systems that collect threat and vulnerability information, the post-incident review records, the lessons-learned flow into risk assessment, the yearly management body reporting and the training records. The organization owns its controls and its conclusions, and an independent auditor or competent authority assesses them.

How we scope

Agree in writing which threat and vulnerability sources, incident records and test outputs fall within the Article 13 engagement.
Confirm which business functions, ICT systems and teams generate the lessons that must reach the ICT risk assessment.
Define the yearly management body report contents, owners, reviewers and the review cycle before work starts.

How we build

Deploy and configure threat intelligence platforms in the client's environment, with ingestion, sharing groups and retention set to the client's policy.
Set up a case management record for major incidents so post-incident reviews keep timelines, actions and evidence in one place.
Configure the training platform with compulsory awareness and resilience modules, completion tracking and reporting for staff and senior management.

How we hand over

Document each workflow, its owner, its inputs and the records it produces, so an assessor can trace a lesson from source to decision.
Provide a sample evidence pack showing threat intelligence records, review minutes, risk register updates and training completion exports.
Walk the client's compliance and ICT teams through the runbooks, and list what the organization must still approve or sign off.

How we support

Offer ongoing support, upgrades and continuous testing through a retainer, if the client wants the platforms maintained after handover.
Review platform changes and new technology developments against the client's monitoring obligation on a scheduled basis.
Confirm with the client's counsel, auditor or competent authority which evidence format and retention period they expect before finalizing exports.

Article 13 Learning and evolving