DORA implementation: ICT compliance

We prepare financial institutions and their suppliers to meet the requirements of the DORA regulation. We check and assess gaps, implement key policies and processes (ICT risk, incidents, resilience testing, business continuity, suppliers) and organise infrastructure: 24/7 monitoring, backups, HA and a complete set of documents for audit.

DORA Regulation: how compliance is implemented

From gap assessment to audit readiness!

We start with a concise gap assessment aligned with DORA requirements, evaluating maturity in the areas of ICT risk, incident management, business continuity (BCM/DRP), resilience testing, and supplier management. The results are turned into a clear roadmap with priorities, owners and metrics.

Next, policies and procedures are implemented and the technical layer is organised: 24/7 monitoring and alerts, backups with restoration tests, HA/geo-redundancy, registers (risks, incidents, changes), runbooks and playbooks. We prepare DORA report templates (4h/24h/72h/1 month), required provisions in SLAs/supplier contracts and an exit plan.

Audit

We identify DORA gaps and risks in ICT infrastructure and processes.

Design

We create policies, procedures, registers and an implementation roadmap with KPIs.

Plan implementation

We implement processes and tools (risk, incidents, BCM/DRP, 24/7 monitoring, backups, HA) and compile evidence for audit.

Incident simulations

We practise scenarios, test resilience (tabletop/TLPT) and consolidate the reporting required by DORA.

Where to start with DORA implementation?

DORA audit (gap assessment)

A comprehensive review of processes and ICT with a gap map, priorities and a clear roadmap

A DORA audit (gap assessment) is a structured review of your processes and infrastructure against the five pillars of DORA. We work with documents and configurations, speak with the team, review architecture, logs, RTO/RPO and alert thresholds.

Areas covered include risk and incidents, business continuity (BCM/DRP), 24/7 monitoring, backup/HA, identity and access management (IAM), vulnerabilities/patching, registers, and collaboration with suppliers.

The result is a gap map with impact assessment, division into quick wins and projects, and a roadmap with owners and KPIs, plus a list of missing policies/procedures/registers (evidence pack). This way you know what to do first and why.

DORA policies, procedures and registers

Ready-made, customised templates: ICT risk, incidents, BCM/DRP, resilience testing, registers and evidence pack.

  • Policies and standards: ICT risk, incident, business continuity (BCM/DRP), resilience testing, supplier security and contract management
  • Operational procedures (SOP + runbooks): incident detection/triage/classification, 4h/24h/72h/1 month reporting, CAB/changes, restoration tests, patch management, crisis communication.
  • Registers required by DORA: risks, incidents, assets, changes, access (IAM), vulnerabilities, suppliers/contracts, acceptance exceptions.
  • Annexes and forms: RACI matrix, materiality criteria, KPIs/KRIs, report templates (KNF/ESAs), audit checklists, SLA clauses (RTO/RPO, exit plan, audit rights).
  • Formats and integration: Word/Google Docs, Confluence, Jira/Service Desk; versioning in Git and clear mapping to existing tools.

The result: a coherent, practical set of documents and artefacts that the team actually works with—not just paperwork for the audit.

Technical implementation for DORA

24/7 monitoring and alerts, backups with restoration tests, HA/hardening, central logs/SIEM and operational runbooks

Technical implementation for DORA means translating regulatory requirements into specific controls within your infrastructure, making it manageable, measurable and auditable.

  • 24/7 monitoring and alerts: metrics, logs and synthetic tests, Critical/High/Warning/Info thresholds, on-call escalations and response playbooks.
  • Backups with restoration tests: 3-2-1 rule, encryption, immutable copies (WORM), cyclical restore drills aligned with defined RTO/RPO.
  • HA / DR: clustering and automatic failover, segmentation, emergency runbooks and regular failover tests.
  • Hardening and access: baseline (e.g. CIS), MFA/PAM, secret rotation, patching windows, and vulnerability scanning with remediation.
  • Centralised logs / SIEM: log ingestion, detection correlations, retention aligned with policy and reports for audit purposes.
  • Operational runbooks: step-by-step guides for incidents and changes, linked to event classification and 4h/24h/72h/1 month report templates.

Incidents and reporting (national supervisory authorities, ESAs)

4h/24h/72h/1 month process, materiality thresholds, forms and automations—along with predefined message templates.

  1. What do we report?
    Events meeting materiality thresholds (impact on clients/services, downtime duration, data loss, spread, supply chain).
  2. How is the decision made?
    Criteria matrix + report/no-report checklist, decision owner and acceptance trail.
  3. How is reporting performed?
    Predefined forms and channels to the relevant supervisory authority, reference number, incident register.
  4. What is automated?
    A draft submission is created from SIEM/monitoring in ITSM (fields, timestamps, impact metrics), versioned in Confluence/Git.
  5. How is communication handled?
    Message templates for clients/partners, Q&A for PR, integration with status page and crisis communication plan.
  6. How do we close?
    Final report with RCA, corrective actions, runbook and KPI/KRI updates.

ICT supplier management and exit plan

Due diligence, DORA clauses in SLAs, ongoing risk monitoring and a practical exit plan

What is done:

  • Due diligence (before launch): rapid supplier assessment, DORA/NIS2 compliance checklist, verification of certificates, sub-supplier chain and data flows.
  • Supervision (during cooperation): KPIs/KRIs, incident thresholds and escalation paths, supplier risk register, cyclical reviews and an up-to-date evidence pack.
  • SLA clauses (essentials): RTO/RPO and availability, audit rights, notification of sub-supplier changes, data location/portability, incident reporting principles.
  • Exit plan (without downtime): export formats and data ownership, cutover/rollback scenario, schedule and access termination + acceptance criteria.

The result is full control of supply-chain risk and predictable service provider changes—without chaos and with a complete set of audit evidence.

DORA regulation: why choose us?

Processes, infrastructure and an evidence pack that will pass an audit and withstand an incident

We support financial institutions and their suppliers in the practical implementation of DORA. Procedural and technical layers are combined: 24/7 monitoring, backups with restoration tests, HA/DR and strict runbooks. We organise registers, map requirements to RTS/ITS, automate reporting (4h/24h/72h/1 month) and prepare a complete evidence pack. We deliver solutions across private and public cloud environments, collaborating closely with security teams and software houses.

Evidence pack ready for audit

24/7 monitoring

Backups with restoration tests

Reporting to supervisory authorities

HA/DR and hardening

SLA & suppliers

FAQ

In what ways is your DORA implementation more than "just documentation"? What do you actually deliver?

We do not just produce policies; we implement working processes and controls.

What we deliver specifically:

  • Gap assessment: gap map, priorities, roadmap and KPIs/KRIs.
  • Set of policies/procedures + registers (risk, incidents, BCM/DRP, testing, suppliers) fine-tuned to your organisation.
  • Configured technical controls: 24/7 monitoring and alerts, backups with tests, HA/DR, centralised logs/SIEM, IAM and hardening.
  • Incidents and reporting: 4h/24h/72h/1 month workflow, forms and message templates.
  • Suppliers: due diligence, DORA clauses for SLAs, exit plan.
  • Evidence pack + runbooks and short training sessions for the team.

What is the first step of cooperation and what data do you need to get started?

A short kick-off call (30–45 min) + NDA. We define the scope, process owners and read-only access. We send a checklist and export formats.

What we need to get started (minimum):

  • List of critical systems/services + owners and RTO/RPO.
  • Architecture diagram (on-prem/cloud/containers) and main integrations.
  • Current policies/procedures (incidents, BCM/DRP, backup, patching), if available.
  • Monitoring/logs: sample alerts, SLO/SLA, tools in use (ITSM/SIEM).
  • Backup/DR: schedule, most recent restoration tests.
  • Suppliers: list + key SLAs/agreements, incidents from the last 12 months.

"DORA: from when?" — what are the key dates and milestones (including RTS/ITS)?

Key DORA dates (summary):

  1. 16 Jan 2023 — the regulation enters into force (preparation period).
  2. 17 Jan 2024 — ESAs publish the first package of final RTS/ITS drafts.
  3. 17 July 2024 — second package: 4 RTS, 1 ITS and 2 guidelines; submitted to the Commission for adoption.
  4. 23 Oct 2024: the Commission adopts RTS/ITS on incident/cyber threat reporting (4h/24h/72h/1 month).
  5. 17 Jan 2025: DORA applies (no transition period); including the obligation to maintain an ICT contract register.
  6. 28 Apr 2025 (PL): deadline for submitting the ICT contract register to national supervisory authority (one-off national milestone).

Can you integrate DORA processes with our tools (Jira/ServiceNow, SIEM, monitoring, ITSM)?

Yes. We integrate DORA processes with your stack without replacing any tools, or recommend changes for the future.

What we do in practice:

  • Jira / ServiceNow (ITSM): Incident/Problem/Change ticket types, DORA-specific fields, SLA/KPIs, automatic on-call escalations, report templates and RCA checklists.
  • SIEM & logs (e.g. Splunk, Elastic, Sentinel, QRadar): rule mapping for DORA severity levels, webhooks for ITSM, contextual evidence (event ID, evidence, timeline) and auto-creation of submission drafts.
  • Monitoring/APM (Prometheus+Alertmanager, Grafana): Critical/High/Warning/Info thresholds, service tagging, alert routing, dashboard snapshots for the evidence pack.
  • CMDB/service catalogue: criticality, owners, RTO/RPO, links (ERP/PIM/WMS), supplier dependencies—for materiality reporting.
  • Runbooks and knowledge base (Confluence/Knowledge Base): “Execute runbook” commands, communication checklists (KNF/ESAs, clients, PR), and change versioning
  • SSO/RBAC & audit: OIDC/SAML, least privilege roles and permissions, full change trail and policy-compliant retention.
  • Integration standards: OpenTelemetry, syslog, API/webhooks; we connect with your existing environment.

What does the DORA audit (gap assessment) look like and what does it cover?

Audit process (in brief):

  1. Kick-off + NDA → scope, owners, read-only access.
  2. Document review & interviews → policies, procedures, registers.
  3. Configuration review → monitoring, backup/DR, logs/SIEM, IAM, patching.
  4. Maturity assessment & scoring → gaps, impact/risk, quick wins.
  5. Report & roadmap → priorities, owners, KPIs/KRIs.

Scope in line with DORA:

  • ICT risk, incidents and reporting (4h/24h/72h/1 month).
  • Resilience testing (BCM/DRP, restore drills, coordinated tabletop/TLPT).
  • ICT supplier management (due diligence, SLA, audit rights, exit strategy).
  • Evidence / registers (risks, incidents, changes, access, contracts, assets).
  • Technical layer: 24/7 monitoring and alerts, backups (3-2-1/WORM), HA/DR, IAM/MFA, logs/SIEM, vulnerabilities/patching.

Do you support on-prem, private cloud and public cloud environments (AWS/Azure/GCP)?

Yes, absolutely.

  • Private cloud: ours and the client’s (VMware/Proxmox/K8s)—design, hardening, HA/DR, monitoring, backup/restore drills.
  • Public cloud (AWS/Azure/GCP): landing zone, IAM/MFA, S3/Blob/WORM, observability, DORA reporting automations.
  • On-prem: remote only (architecture, configurations, audits, runbooks)—no physical work in the DC.

What can we do for you?

Let's talk. Send a message!