ICT risk & resilience
DORA, translated into something the business can actually run.
We turn DORA Articles into governance, registers and operating routines that are easier to explain during audit, board review or regulatory scrutiny — and that the team can keep operating once the project closes.
When this matters
DORA becomes a board-level issue when auditors, the management body or regulators want clarity on ICT risk ownership, third-party concentration, incident decisions and operational resilience evidence.
Scope
What we cover.
ICT risk management framework
- Framework aligned to DORA Articles 5–16
- Roles, responsibilities and management body oversight
- Asset, dependency and criticality mapping
- Risk appetite and tolerance statements
Incident management & reporting
- Classification criteria and decision tree
- Major ICT incident reporting readiness
- Escalation routes and communications playbook
- Post-incident review and lessons-learned
Digital operational resilience testing
- Test programme design
- Scenario-based resilience exercises
- BCDR and failover testing evidence
- Resilience testing and, where relevant, TLPT readiness scoping
ICT third-party risk
- Third-party register and criticality classification
- Contractual control mapping
- Concentration and exit strategy review
- Ongoing monitoring routines
Business continuity & DR
- Business impact analysis refresh
- RTO and RPO confirmation against architecture
- Recovery runbooks and evidence
- Crisis communications planning
Regulator & board readiness
- Management body reporting pack
- Policy and control mapping to DORA
- Evidence trail for inspections
- Remediation and operating cadence
What good looks like
An ICT risk operating model the team can actually run.
- 01An ICT risk framework tied to the systems you actually run
- 02Incident classification and reporting the team has rehearsed
- 03A third-party register with concentration and exit risk visible
- 04Management body reporting the regulator can follow
Common triggers
Why teams typically bring us in.
- ICT asset and dependency map is incomplete
- Third-party register lacks criticality and exit options
- Incident classification has not been rehearsed
- BCP and DR testing evidence is weak
- Management body reporting is too technical or too vague
- Policies do not match the operating model
Related services
Adjacent work teams often pair this with.
Have a deadline pressing on you?
Tell us the gap.
Most engagements start with a short call to understand the deadline, the team and the constraints.
Bergson Limited is registered in Ireland. We are not auditors, QSAs, or legal advisers. We help technology teams produce the evidence those stakeholders need.