Building Your ICT Risk Management Framework

Bottom Line

A DORA-compliant ICT risk management framework is not a policy document — it is an operating system for managing digital risk. Auditors will test whether it is lived, not just written. Board minutes, training logs, tested DR results, and current asset inventories are the evidence that counts.

What Auditors Will Actually Look For

• Board approval of the IRMF — with minutes showing genuine engagement, not a rubber-stamp resolution.
• A written ICT risk appetite statement, calibrated to your business model.
• A current ICT asset inventory that maps assets to critical functions and third-party dependencies.
• Risk assessments conducted at least annually and after material changes — with documented residual risk decisions.
• RTOs and RPOs for every critical system — and evidence of DR tests that actually met those targets.
• Backup restoration tests, not just backup creation confirmation.
• Post-incident review reports with control improvements tracked to completion.

Common Mistakes

• Framework policy approved once and never reviewed — DORA requires annual review and post-incident updates.
• Asset inventory completed for compliance and never maintained — new systems added without registration.
• RTOs set aspirationally rather than based on tested recovery times — auditors ask for DR test results.
• Risk acceptance decisions undocumented — leaving no audit trail for why certain residual risks were tolerated.

Governance and Board Accountability (Art. 5)

The management body owns ICT risk under DORA. "IT manages it" is not an acceptable governance model.

• The board must formally approve the IRMF and review it at least annually.
• Board members are expected to maintain sufficient ICT risk knowledge — training records are an audit artefact.
• Allocate clear ownership: CISO, CRO, and CIO with documented responsibilities and escalation paths.
• Define board-level ICT risk appetite and communicate it to the business.
• Produce a board-level ICT risk report at least quarterly: key risk indicators, incidents, and testing outcomes.

ICT Risk Strategy (Art. 6)

The framework must be anchored to a documented strategy aligned with the business.

• Define ICT risk appetite: what level of disruption is acceptable, to which systems, and for how long?
• Map ICT risks to business objectives — a payment firm and an asset manager have very different risk profiles.
• The IRMF policy must cover all six pillars: identification, protection, detection, response, recovery, and learning.
• Review the strategy after any major incident, significant organisational change, or material technology shift.

ICT Asset Identification and Classification (Art. 8)

You cannot manage risks you have not identified. Asset mapping is foundational — and it must be kept current.

• Maintain a comprehensive ICT asset inventory: hardware, software, network components, data assets, and third-party services.
• Classify assets by their role in supporting critical or important functions.
• Map dependencies: which systems depend on which, and which external providers underpin each asset.
• Identify single points of failure and concentration risks.
• Integrate asset discovery into your change management process — new systems must be registered before go-live.

Protection Controls (Art. 9)

Controls must be proportionate to asset criticality. Auditors look for specificity — not generic policies.

• Access control: least-privilege principles, MFA for privileged accounts, and regular access reviews with evidence.
• Patch management: defined SLAs by severity; critical patches applied within 24–72 hours.
• Network segmentation: critical systems separated from general corporate networks.
• Encryption for data at rest and in transit for critical and confidential assets.
• Security requirements flowed down to ICT third-party providers in contracts.

Detection Capabilities (Art. 10)

Detection is not just deploying a SIEM — it is confirming that the right threats would actually be detected.

• Deploy a SIEM or equivalent monitoring capability with use cases covering your critical systems.
• Define alert thresholds and escalation paths for different severity levels.
• 24/7 monitoring for systems supporting critical functions — in-house or via a managed SOC.
• Test detection capabilities as part of the annual testing programme — not just assumed to work.

Response and Recovery (Art. 11)

BCP and DRP documents that have never been tested are audit findings waiting to happen.

• Document BCP and DRP covering all critical functions.
• Define RTOs and RPOs for each critical system — based on actual capability, not aspiration.
• Test BCPs and DRPs at least annually; full failover tests are better than tabletops alone.
• Maintain crisis communication procedures for internal and external stakeholders.

Backup and Continuous Improvement (Arts. 12–13)

Backups and learning loops close the framework cycle.

• Define backup frequency proportionate to RPO; critical systems may require near-real-time replication.
• Store backups in physically and logically isolated environments, protected from ransomware.
• Test restoration procedures regularly — backup creation without restoration testing provides false assurance.
• Conduct post-incident reviews after every major incident; track control improvements to completion.
• Feed testing findings (pen tests, TLPT, DR tests) into the annual risk assessment update.

3-Step Action Checklist

• 1. This week: Confirm the IRMF has board approval documented in minutes and was reviewed within the last 12 months. If not, schedule a board agenda item — this is your single highest-priority governance action.
• 2. This month: Pull your ICT asset inventory and spot-check 10 systems added in the last 6 months. If any are missing, your asset management process is broken. Fix the process, not just the register.
• 3. This quarter: Schedule a live DR test for at least one critical system against its documented RTO. Document the outcome — whether it succeeded or failed. That test result is the first thing an auditor will request.