Article 15: Further harmonisation of ICT risk management tools, methods, processes and policies

Article 15 requires you to track and implement the harmonised ICT risk management tools, methods, processes, and policies that will be defined in Regulatory Technical Standards (RTS) issued by the ESAs, coordinated via the Joint Committee and consulted with ENISA. Operationally, you need a repeatable “RTS intake-to-control” process, clear ownership, and provable evidence that your ICT risk framework stays aligned as those RTS evolve. (Regulation (EU) 2022/2554, Article 15)

Key takeaways:

• Treat Article 15 as an implementation-readiness requirement: build the machinery to adopt RTS quickly and consistently. (Regulation (EU) 2022/2554, Article 15)
• Create traceability from RTS obligations to controls, owners, and evidence artifacts in a single register your supervisors can navigate. (Regulation (EU) 2022/2554, Article 15)
• Run recurring readiness drills and close gaps with tracked corrective actions and validation evidence, not slide decks. (Regulation (EU) 2022/2554, Article 15)

“Article 15: further harmonisation of ICT risk management tools, methods, processes and policies requirement” is easy to misread as a purely supervisory or standard-setting provision that does not change day-to-day operations. For a Compliance Officer, CCO, or GRC lead, the practical impact is real: Article 15 signals that DORA’s ICT risk management expectations will be harmonised via ESA-developed RTS, and supervisors will expect your program to ingest those standards and convert them into operating controls, testing, and evidence. (Regulation (EU) 2022/2554, Article 15)

So your job is not to guess future RTS text. Your job is to build an internal capability that (1) monitors and intakes RTS updates, (2) maps each requirement to your policy/control stack, (3) assigns accountable owners across ICT risk, security operations, and third-party management, and (4) preserves audit-grade proof that the controls operate and that gaps are remediated. (Regulation (EU) 2022/2554, Article 15)

This page gives you requirement-level implementation guidance you can execute quickly: who must act, how to set up the workflow, what evidence to retain, and the exam questions you should pre-answer.

Regulatory text

Excerpt (operator-relevant): “The ESAs shall, through the Joint Committee, in consultation with the European Union Agency on Cybersecurity (ENISA), develop common draft regulatory technical standards …” (Regulation (EU) 2022/2554, Article 15)

Plain-English interpretation

Article 15 is the “standardisation pipeline” behind DORA’s ICT risk management expectations. It says the European Supervisory Authorities (ESAs), acting together, will draft RTS to harmonise ICT risk management tools, methods, processes, and policies. (Regulation (EU) 2022/2554, Article 15)

What the operator must do

Even though Article 15 describes what ESAs will produce, regulated entities still need to operationalise it by:

• Staying current on RTS outputs that define harmonised expectations for ICT risk management. (Regulation (EU) 2022/2554, Article 15)
• Converting RTS requirements into internal controls (policies, standards, procedures, technical configurations, and monitoring) with named accountable owners. (Regulation (EU) 2022/2554, Article 15)
• Proving execution through artifacts: testing results, incident workflow evidence, remediation closure, and third-party control validation. (Regulation (EU) 2022/2554, Article 15)

If you do not build this intake-and-mapping capability, you risk being “compliant on paper” with DORA-aligned policies while missing the harmonised specifics supervisors will examine.

Who it applies to

Entity scope

Applies to DORA in-scope regulated entities that must align their ICT risk management approach with DORA and the related RTS that harmonise expectations across the EU. (Regulation (EU) 2022/2554)

Operational context (where this shows up in real life)

You will feel Article 15 pressure in:

• ICT risk management framework governance: policy hierarchy, control library, risk taxonomy, and KRIs/metrics.
• Security operations: vulnerability management, logging/monitoring, secure configuration, identity controls, incident handling.
• Change management: implementing updated standards across multiple tech stacks.
• Third-party risk management: requiring service providers to meet your harmonised control expectations and providing evidence.

A practical rule: if a supervisor can ask “show me how you implemented the harmonised DORA RTS requirement,” then Article 15 is operationally in-scope for that domain.

What you actually need to do (step-by-step)

Step 1: Stand up an “RTS intake” workflow (owner, triggers, routing)

Outcome: No RTS update can land without being assessed, assigned, implemented, and evidenced.

1. Name an accountable process owner (often: GRC lead or ICT risk head) and a deputy.
2. Define intake triggers: ESA/competent authority publication, legal bulletins, industry association alerts, internal audit findings tied to RTS gaps.
3. Define routing and approval: legal/compliance interpretation → ICT risk/control mapping → engineering implementation plan → validation/testing → closure sign-off.
4. Create response SLAs internally (your choice; treat as a governance commitment) for triage, implementation plan issuance, and closure verification.

Daydream fit (earned): most teams fail on the “routing + evidence” piece. Daydream can act as the system-of-record for requirement-to-control mapping, owner assignment, and evidence requests, so RTS adoption is trackable end-to-end.

Step 2: Build a single “DORA RTS mapping register” (traceability backbone)

Outcome: A supervisor can pick any RTS obligation and you can show control coverage and proof.

Create one register with these columns:

• RTS / Article reference (store as text fields; do not rely on memory)
• Requirement statement (verbatim excerpt where possible)
• Internal policy/standard references
• Control(s) and control owner(s)
• Systems/services in scope
• Evidence artifacts required (what, where stored, retention owner)
• Test method and test cadence (your internal governance decision)
• Known gaps, risk acceptance status, remediation plan, target closure date (if applicable)

This register is also your “handoff object” between compliance interpretation and engineering execution. Without it, you will answer audits through ad hoc emails and tribal knowledge.

Step 3: Translate “tools, methods, processes and policies” into control domains you can test

Outcome: Harmonisation becomes measurable.

Use a practical decomposition:

• Tools: GRC platform, ticketing, SIEM, EDR, IAM tooling, vulnerability scanners, configuration management, vendor management portals.
• Methods: risk assessment methodology, scoring, threat modeling approach, control testing approach, assurance methods for third parties.
• Processes: change management, incident management, vulnerability remediation, access reviews, backup/restore testing, vendor onboarding/offboarding.
• Policies/standards: ICT risk policy, security policy, third-party security standard, logging standard, encryption standard, secure SDLC standard.

For each domain, write “control intent” statements that are testable (example: “Privileged access is reviewed and re-approved by the control owner; evidence is retained”). Keep them aligned to your existing frameworks (ISO 27001 Annex A, NIST CSF/800-53, COBIT). Article 15 does not replace those; it tightens harmonisation expectations. (Regulation (EU) 2022/2554, Article 15)

Step 4: Assign accountability across functions (and document it)

Outcome: No “shared ownership” gaps.

Minimum roles to identify:

• ICT risk management owner (framework)
• CISO/security operations owner (technical control operation)
• Third-party risk owner (service provider oversight)
• IT service owner(s) (system-level control implementation)
• Compliance/legal owner (interpretation and supervisory response)

Capture this in RACI form for the RTS intake workflow and store it with version control.

Step 5: Evidence the controls operate (not just that they exist)

Outcome: You can pass a supervisory review with artifacts, not narratives.

Evidence should match the lifecycle:

• Design evidence: approved policies/standards; architecture decisions; control descriptions.
• Operational evidence: tickets, logs, reports, access review outputs, monitoring alerts, incident runbooks used in practice.
• Testing evidence: internal control testing results, issue logs, remediation verification.
• Remediation evidence: corrective action plans (CAPs), closure notes, retesting output, sign-offs by accountable owners.

One common hangup: teams collect screenshots with no context. Require each artifact to include system name, time period, control owner, and a short statement of what the artifact proves.

Step 6: Run readiness drills (tabletop + evidence pull)

Outcome: You can answer a supervisor quickly without scrambling.

Run a drill where you:

• Select several RTS-mapped controls
• Pull evidence from source systems
• Validate completeness (time period coverage, approvals, scope)
• Record gaps and open CAPs
• Re-test a sample after remediation

This is where teams find the real problem: evidence exists, but nobody can retrieve it reliably or tie it back to the requirement.

Required evidence and artifacts to retain

Maintain an “exam pack” organized by requirement mapping:

• RTS intake procedure and change log (who reviewed what, when, and what changed)
• Mapping register (requirement → controls → owners → evidence)
• Policy/standard documents and version history
• Control operation evidence ¹
• Control testing plan and results
• Issues register and CAP tracker, including closure validation evidence
• Third-party oversight artifacts where relevant (due diligence results, contract security clauses summary, SOC reports review notes, remediation follow-ups)

Store artifacts in a controlled repository with access control and retention rules that match your broader compliance retention practices.

Common exam/audit questions and hangups

Expect questions like:

• “Show me how you monitor and implement new/updated RTS requirements.” (Regulation (EU) 2022/2554, Article 15)
• “Who is accountable for translating RTS text into technical control changes?”
• “Prove this control operated over the period, not just that the policy exists.”
• “Show open gaps, remediation plans, and how you validated closure.”
• “How do third parties that support critical processes meet these control expectations?”

Hangups that slow responses:

• Evidence spread across SIEM, ticketing, cloud consoles, and shared drives.
• Control owners named in policy but not engaged operationally.
• “One-time compliance project” thinking, instead of a repeatable RTS intake function.

Frequent implementation mistakes and how to avoid them

1. Mistake: Treating Article 15 as “supervisors’ problem.”
   Fix: Treat it as a requirement to maintain readiness for harmonised standards adoption, with a defined workflow and accountable owner. (Regulation (EU) 2022/2554, Article 15)

2. Mistake: Mapping requirements to policies only.
   Fix: Map to controls and evidence. A policy without operational proof fails under supervision.

3. Mistake: Shared inbox governance.
   Fix: Use a ticketed workflow with explicit sign-offs (compliance interpretation, technical implementation, validation).

4. Mistake: No closure discipline for CAPs.
   Fix: Require closure evidence plus independent validation (control testing or second-line review).

5. Mistake: Third-party controls left out of harmonisation mapping.
   Fix: Tag controls that rely on third parties and define what assurance you require (reports, attestations, testing rights, incident notice evidence).

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so do not build your plan around specific precedents.

Risk still concentrates in three places:

• Supervisory credibility risk: inability to demonstrate a controlled process for adopting harmonised RTS expectations. (Regulation (EU) 2022/2554, Article 15)
• Operational resilience risk: inconsistent control implementation across business units and systems because standards updates do not propagate.
• Third-party concentration risk: service providers become the weak link when harmonised expectations are not contractually or operationally enforced.

Practical execution plan (30/60/90-day)

A numeric day-by-day plan would imply a universal timeline; use phases tied to your internal governance calendar and change capacity.

Phase 1: Immediate (set the mechanism)

• Appoint the RTS intake owner and define RACI across compliance, ICT risk, security, IT, and third-party management.
• Draft and approve the RTS intake procedure (triage, interpretation, mapping, implementation, validation, closure).
• Stand up the initial mapping register structure and populate it with your current DORA-related control library references.

Phase 2: Near-term (make it real with evidence)

• Select a representative subset of ICT risk domains (identity, vulnerability management, incident management, third-party onboarding) and complete end-to-end mapping to evidence.
• Run the first readiness drill: evidence pull, gap logging, CAP issuance, and closure criteria definition.
• Implement a supervisory-response workflow: how you respond to regulator questions, who approves, how evidence is packaged.

Phase 3: Ongoing (institutionalize)

• Make RTS intake part of routine governance (risk committee agenda item, change advisory board linkage).
• Schedule recurring control operation checks and second-line testing aligned to your risk profile.
• Keep the mapping register current, and require each control owner to refresh evidence pointers and test results.

Daydream can reduce operational friction here by centralizing the mapping register, workflow approvals, evidence requests, and readiness drill outputs so audit response is a retrieval exercise, not a fire drill.

Frequently Asked Questions

Does Article 15 impose direct obligations on my firm, or only on the ESAs?

The text describes ESA development of RTS, but your practical obligation is to be able to adopt and evidence the harmonised expectations once they apply under DORA. Build an RTS intake-to-control process now so adoption is controlled and provable. (Regulation (EU) 2022/2554, Article 15)

What should I show an examiner if RTS details are still evolving?

Show governance and execution capability: intake workflow, mapping register format, accountable owners, and a drill that proves you can collect evidence and close gaps. That demonstrates readiness to implement harmonised standards without delay. (Regulation (EU) 2022/2554, Article 15)

How do I map “tools, methods, processes and policies” to controls?

Break them into domains (tooling, methodology, processes, policy stack), then map each requirement to a specific control statement, a control owner, and an evidence artifact. If you cannot name evidence, the mapping is incomplete.

What’s the minimum evidence set that tends to satisfy supervisors?

For each mapped control: design artifact (policy/standard), operational proof (system output or ticket record), and a testing/validation record plus remediation closure evidence for any failures. Package it by requirement in an exam pack.

How does this affect third-party risk management?

Harmonised ICT risk expectations often depend on third parties that operate or support your systems. Tag controls that rely on third parties, define assurance requirements, and retain evidence of your follow-up on gaps.

Where does Daydream fit without creating another layer of bureaucracy?

Use Daydream as the system-of-record for requirement mapping, ownership, evidence requests, and readiness drills. That replaces ad hoc spreadsheets and email approvals with a traceable workflow tied to supervisory-ready artifacts.

Footnotes

1. Regulation (EU) 2022/2554, Article 15