Overview
Draft periodic ICT risk reports for the management body as required by the EU Digital Operational Resilience Act (DORA), Article 5. The skill produces structured, decision-ready board packs covering ICT risk posture, incident summaries, resilience testing results, third-party risk status, compliance progress, budget allocation, and actionable recommendations.
DORA Art. 5 places explicit personal accountability on the management body for defining, approving, and overseeing the ICT risk management framework. Generic board packs are insufficient – the management body needs evidence-based reporting that demonstrates oversight and supports the accountability trail required by Art. 5(2). This skill ensures every report meets those obligations.
What It Covers
- ICT risk posture – threat landscape, risk register highlights, KRIs, risk appetite adherence per Art. 6(8)(a)
- ICT incidents – severity breakdown, major incidents reported to the competent authority (Art. 19), MTTD/MTTR, financial impact
- Resilience testing – vulnerability assessments, penetration tests, TLPT results (Art. 26), remediation progress
- Third-party risk (Art. 5(7)) – provider register, material changes, concentration risk, exit strategy readiness
- Compliance status – DORA gap assessment, RTS/ITS implementation, supervisory interactions, upcoming deadlines
- ICT budget and resources – budget utilization, resilience investment, management body training (Art. 5(4))
- Recommendations – decisions required, budget requests, risk tolerance adjustments, priority actions
Example Conversation
You: We need to prepare the Q1 2026 ICT risk report for our management body. We are a mid-size payment institution regulated by the Central Bank of Ireland.
Agent: I’ll guide you through the full board report workflow. Let me start by confirming the reporting context.
- Is the quarterly reporting frequency already approved by your management body?
- Were there any outstanding action items from the Q4 2025 report?
- Does the simplified ICT risk management framework under Art. 16 apply to your entity?
- What is the date of the next management body meeting so we can target the report accordingly?
You: Yes, quarterly reporting was approved last year. We have 4 open action items from Q4. Art. 16 does not apply – we have over 200 employees. The board meets on April 15th.
Agent: Good. Let me now work through each section. Starting with the ICT risk posture – please provide or upload the following:
- Current risk register extract (top risks by residual score)
- Any new risks identified in Q1 (new systems, products, or infrastructure changes)
- KRI dashboard or metrics report for Q1
- Any breaches of the risk tolerance levels set by the management body
You: I’ve uploaded our risk register and KRI dashboard. We onboarded a new cloud-based fraud detection system in February, and one KRI (mean time to patch critical vulnerabilities) breached the amber threshold in March.
Agent: I see the risk register shows 47 active risks, with 5 rated critical. Two risks have a deteriorating trend since Q4: “third-party cloud concentration” moved from medium to high, and “legacy payment gateway vulnerabilities” remains critical with overdue remediation. The new fraud detection system introduces a new risk entry I’ll flag for the board.
For the KRI breach – the mean-time-to-patch exceeded 15 days against your 10-day threshold. I’ll present this with a trend chart and root cause summary. Let me move on to the incident section. How many ICT incidents were recorded in Q1, and were any classified as major under Art. 18?
You: 23 incidents total. One was classified as major – a payment processing outage on February 12th that lasted 4 hours and affected 12,000 transactions. We reported it to the Central Bank of Ireland within the 4-hour window.
Agent: I’ll document that in the major incidents table with the reference number, timeline, and current status. For the executive summary dashboard, I’m marking the Incidents domain as Amber given the major incident. Let me compile the remaining sections – resilience testing, third-party risk, compliance, and budget. What testing was conducted in Q1?
You: We completed a penetration test of the payment processing platform in January and a scenario-based business continuity test in March. TLPT is scheduled for Q3 – we are in scope as a significant payment institution.
Agent: After completing all sections, I’ll run the
dora_board_report_checkerto validate completeness before we finalize. Let me draft the full report now with the executive summary dashboard, all seven reporting sections, recommendations, and the action items register.
Sample Output Excerpt
Below is a representative excerpt from a generated board report showing the executive summary dashboard, a risk posture section, and the third-party risk section that fulfills Art. 5(7) requirements.
Executive Summary Dashboard
| Domain | Status | Trend | Key Metric | Prior Period |
|---|---|---|---|---|
| ICT Risk Posture | Amber | Stable | 5 critical risks, 1 KRI breach | Amber |
| ICT Incidents | Amber | Deteriorating | 1 major incident reported (Art. 19) | Green |
| Resilience Testing | Green | Improving | 92% critical findings remediated | Amber |
| Third-Party Risk | Amber | Deteriorating | 14 providers supporting critical functions; concentration risk increased | Green |
| Compliance | Green | Improving | 84% DORA requirements implemented | Green |
| ICT Budget | Green | Stable | 88% budget utilization | Green |
Top Items Requiring Management Body Attention:
- Decision required – Accept residual risk for legacy payment gateway (Risk-017) or approve EUR 340,000 remediation budget
- Awareness – Major payment processing incident on 12 Feb 2026; root cause remediation 70% complete, target April 30
- Decision required – Approve revised ICT third-party concentration risk tolerance following new cloud fraud detection onboarding
1. ICT Risk Posture Summary (excerpt)
1.2 Risk Register Highlights
| Rank | Risk ID | Risk Description | Residual Risk | Trend | Owner |
|---|---|---|---|---|---|
| 1 | RISK-017 | Legacy payment gateway unpatched vulnerabilities | Critical | Stable | Head of Infrastructure |
| 2 | RISK-031 | Cloud provider concentration (AWS) | High | Deteriorating | CISO |
| 3 | RISK-008 | Insider threat — privileged access management gaps | High | Stable | Head of Security Operations |
| 4 | RISK-042 | New fraud detection system integration risk | Medium | New | Head of Payments |
| 5 | RISK-019 | Ransomware exposure via email vector | High | Improving | CISO |
New risks identified: 1 (RISK-042, fraud detection system integration) Risks closed: 2 (RISK-029 legacy API decommissioned, RISK-036 MFA rollout completed) Risks with deteriorating trend: 1 (RISK-031 cloud concentration)
1.6 Key Risk Indicators
| KRI | Current Value | Threshold | Status | Trend |
|---|---|---|---|---|
| Mean time to patch critical vulnerabilities | 17 days | 10 days | Red | Deteriorating |
| High-privilege accounts without MFA | 0% | < 5% | Green | Stable |
| Critical systems with overdue risk assessments | 2 | 0 | Amber | Stable |
| Third-party provider SLA breaches | 3 | < 2 | Amber | Deteriorating |
4. ICT Third-Party Risk Status (Art. 5(7)) (excerpt)
4.1 Provider Register Summary (Art. 5(7)(a))
| Category | Count |
|---|---|
| Total ICT third-party providers | 67 |
| Providers supporting critical or important functions | 14 |
| New providers onboarded this period | 2 |
| Providers terminated this period | 1 |
4.2 Material Changes (Art. 5(7)(b))
| Change | Provider | Impact on Critical Functions | Risk Assessment | Status |
|---|---|---|---|---|
| New contract — fraud detection platform | FraudGuard Ltd | Payment processing (critical) | Medium | Approved |
| Sub-outsourcing change — data centre migration | CloudCore Inc | Core banking platform (critical) | High | Under review |
| Contract renewal with scope expansion | PayNet Services | Card processing (critical) | Low | Approved |
4.3 Concentration Risk Assessment (Art. 5(7)(c))
The entity relies on AWS for 78% of its ICT infrastructure, supporting 9 of 14 critical functions. The onboarding of FraudGuard Ltd (hosted on AWS) increased this concentration. A single AWS region failure could impact payment processing, fraud detection, and customer data services simultaneously. Recommendation: the management body should review and approve the revised concentration risk tolerance, or direct a multi-cloud feasibility study.
Extension Tools
dora_board_report_checker
Validates that a management body ICT risk report covers all DORA Art. 5 required reporting topics before submission to the board. The tool reads a JSON-structured board report and checks for completeness across nine mandatory sections:
| Section | What It Checks | Severity if Missing |
|---|---|---|
| Entity profile | Entity type (Art. 2(1)), reporting period, competent authority | ERROR |
| Executive summary | One-page dashboard with RAG status for each domain | ERROR |
| ICT risk posture | Threat landscape, risk register, risk appetite adherence, KRIs (min 3 sub-fields) | ERROR / WARNING |
| ICT incidents | Severity breakdown, major incidents (Art. 19), root causes, MTTD/MTTR, financial impact (min 3 sub-fields) | ERROR / WARNING |
| Resilience testing | Tests conducted, findings, TLPT results, remediation progress (min 3 sub-fields) | ERROR / WARNING |
| Third-party risk (Art. 5(7)) | Provider register (Art. 5(7)(a)), material changes (Art. 5(7)(b)), concentration risk (Art. 5(7)(c)), exit strategy readiness (Art. 28(8)) | ERROR / WARNING per sub-field |
| Compliance status | Gap assessment, remediation roadmap, RTS/ITS implementation, audit findings (min 3 sub-fields) | ERROR / WARNING |
| ICT budget | Budget utilization, resilience investment, resources, training (Art. 5(4)) | ERROR / WARNING |
| Recommendations | Decisions required, budget requests, risk tolerance adjustments, priority actions | ERROR / WARNING |
| Action items | Prior period status and new items with owners and target dates | WARNING |
Missing mandatory sections are reported as ERRORs that must be resolved. Sections present but with fewer than 3 populated sub-fields are flagged as WARNINGs indicating insufficient depth. The tool also specifically validates Art. 5(7) sub-requirements for third-party reporting, since these are mandatory reporting elements, not optional inclusions.
Run after drafting the report to verify completeness before the management body meeting.
Getting Started
Activate the Management Body ICT Risk Report (DORA) skill and have the following information ready:
- Entity profile – entity type under DORA Art. 2(1), competent authority, reporting period
- Risk register – current risk register extract with residual risk scores and trends
- KRI dashboard – key risk indicator values with thresholds for the reporting period
- Incident log – ICT incidents for the period, including any major incidents reported to the competent authority
- Testing results – vulnerability assessments, penetration test reports, and TLPT results if applicable
- Third-party register – ICT third-party provider register (Art. 28(3)), including any material changes during the period
- Compliance tracker – DORA gap assessment status, RTS/ITS implementation progress
- Budget data – ICT risk management budget allocated vs. spent, training records
- Prior report – previous board report with action items for status tracking
The agent guides you through a 10-step workflow: gather context, compile risk posture, summarize incidents, report testing results, report third-party risk (Art. 5(7)), report compliance status, report budget, draft recommendations, validate with dora_board_report_checker, and produce the final board report with executive summary dashboard.
This skill draws on data from other DORA skills – if you have already used dora-ict-risk-framework, dora-incident-classification, dora-resilience-testing, dora-third-party-policy, or dora-information-register, load those outputs to pre-populate the corresponding report sections.