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.
What we cover
Scope of work
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.
- An ICT risk framework tied to the systems you actually run
- Incident classification and reporting the team has rehearsed
- A third-party register with concentration and exit risk visible
- Management body reporting the regulator can follow
Common red flags
Patterns we see most often.
- 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
Next step
Talk to Bergson about this work
Most engagements start with a short call to understand the deadline, the team and the constraints.