Skip to content

DORA and operational resilience

The Digital Operational Resilience Act (DORA) applies from 17 January 2025 to financial entities within its scope. It requires the financial institution to manage ICT risk across its own systems and ICT third-party services. Finsaku can provide controls and operational evidence, but it does not replace the institution's governance, incident reporting, resilience programme, or third-party register.

What DORA requires

From the financial institution

The organisation must:

  • make its management body accountable for ICT risk and maintain an ICT risk-management framework;
  • identify business functions, information assets, ICT systems, dependencies, risks, and control owners;
  • protect systems and data, detect anomalous activity, respond to incidents, recover service, and learn from disruption;
  • classify ICT-related incidents and report major incidents through the prescribed process and timelines;
  • operate a risk-based digital operational resilience testing programme and remediate findings;
  • manage ICT third-party risk, maintain the register of information, and govern contracts, concentration risk, contingency, and exit;
  • preserve evidence that controls, tests, decisions, incidents, and remediation are operating as intended.

From the software and service

DORA requires the financial institution to use ICT systems and services that are reliable, appropriately protected, monitored, recoverable, testable, and traceable. The institution must understand how each service supports critical or important functions and obtain the contractual and technical information needed for oversight.

For Finsaku, assess the application controls together with the specific deployment: hosting architecture, monitoring, backups, restoration, vulnerability management, incident contacts, service commitments, subprocessors, data locations, and exit assistance. Do not infer those deployment-level properties from a tenant screen. An ICT provider's regulatory status must be confirmed from current official and contractual evidence.

Traceability matrix

The classification describes product coverage:

  • Out of the box — Finsaku provides the application control without custom development. The customer must still configure and operate it correctly.
  • Customer action required — Finsaku provides supporting controls or evidence, but the customer must complete the governance, operational, contractual, testing, or deployment-level work.
Important requirement DORA reference Coverage How the requirement is addressed
Management-body accountability and ICT governance Articles 5 and 6 Customer action required Finsaku identifies tenant configuration, users, permission groups, products, integrations, and supported changes. The customer must assign management accountability, approve the ICT risk framework, define risk appetite and roles, fund controls, maintain policies, and oversee remediation.
Suitable, reliable, and resilient ICT systems Article 7 Customer action required Finsaku provides the application used to configure and run lending workflows. The customer must assess the specific deployment's suitability, reliability, capacity, resilience, lifecycle, maintenance, support, and alignment with the criticality of the functions it supports.
ICT-supported functions, assets, and dependency identification Article 8 Customer action required Product configuration, workflows, integrations, external calculators, templates, and provider references help identify Finsaku dependencies. The customer must maintain the authoritative business-function, information-asset, ICT-asset, dependency, criticality, and ownership inventory, including infrastructure and services not represented in the tenant.
Application access control and segregation Article 9 Out of the box OAuth/OIDC sign-in, user status, granular permissions, affiliations, tenant scope, separate sensitive permissions, and controlled impersonation restrict Finsaku access. The customer must define roles, review cumulative access, govern privileged identities and the identity provider, block leavers, and test permitted and prohibited operations.
Traceability of user and configuration activity Articles 9 and 10 Out of the box The Finsaku audit trail records supported actors, events, times, references, and stored value changes. Event-action execution history adds workflow execution evidence. The customer must set evidence-retention rules, restrict history access, correlate Finsaku activity with infrastructure and provider logs, and preserve evidence during an investigation.
Protection, prevention, and infrastructure security Article 9 Customer action required Finsaku contributes tenant scoping, authorisation, controlled configuration, and integration boundaries. The customer must obtain and assess deployment evidence for network and platform security, encryption, secure configuration, patching, vulnerability management, endpoint controls, capacity, and physical or cloud safeguards.
Detection of anomalous activity Article 10 Customer action required Audit history, failed event actions, integration results, current record state, and service logs can contribute signals and investigation evidence. The customer must operate monitoring, alerting, baselines, triage, escalation, correlation, coverage testing, and ownership across the complete ICT estate.
ICT incident response and recovery Articles 11 and 13 Customer action required Finsaku record state, history, execution results, provider references, and reconciliation checks help establish impact and verify restored processing. The customer must maintain response and recovery plans, roles, communications, containment, workarounds, root-cause analysis, corrective actions, and lessons learned.
Backup, restoration, and recovery objectives Article 12 Customer action required Finsaku application data and workflow checks can be used to validate business results after restoration. The customer must obtain the deployment's backup scope, isolation, retention, restoration design, recovery objectives, test results, exceptions, and contractual commitments, then reconcile restored business data.
ICT incident classification and regulatory reporting Articles 17–23 Customer action required Finsaku supplies timestamps, affected records, users, workflow failures, and provider references that can support a timeline. The customer must determine whether an event is an ICT-related or major incident, apply the regulatory criteria, maintain the incident record, meet reporting timelines, and coordinate communications. A Failed event action is not itself a DORA classification.
Digital operational resilience testing Articles 24 and 25 Customer action required Finsaku supports controlled tests of critical lending and servicing flows, permissions, provider failures, duplicate prevention, reconciliation, and restored operation. The customer must define the risk-based programme, scope environments and dependencies, preserve results, assign remediation, retest findings, and include the other test types required by DORA.
Threat-led penetration testing Articles 26 and 27 Customer action required Finsaku service and architecture information can help define the assessed boundary. Where TLPT applies, the customer must coordinate the authority-led scope, approved testers, production safeguards, provider participation, evidence, remediation, and attestation. Tenant users cannot satisfy TLPT by testing application screens.
ICT third-party risk strategy and register of information Article 28 Customer action required The Finsaku integration inventory identifies configured providers, status, connection settings, and dependent workflows. The customer must maintain the DORA register of information, map services to functions, assess criticality and concentration, record processing locations and subcontracting, conduct due diligence, and keep the register current.
Key contractual provisions for ICT services Article 30 Customer action required Finsaku configuration shows which external services are enabled; applicable Finsaku service documents describe the contracted platform service. The customer must ensure agreements cover scope, locations, data access and return, security, service levels, assistance, incident notice, audit and inspection, testing, subcontracting, termination, and exit as applicable.
Third-party continuity and exit Articles 28 and 30 Customer action required Finsaku exports, configuration records, provider references, and reconciliation checks can support a controlled transition. The customer must define feasible contingency and exit plans, ownership, triggers, alternative arrangements, data migration and deletion, transition support, testing, and acceptance criteria.
Evidence and regulatory access Articles 6, 28, and 30 Customer action required Finsaku audit, configuration, query, export, and execution views supply product evidence subject to permission. The customer must preserve the complete evidence set, relate it to controls and assessed periods, govern disclosures, and obtain deployment, provider, contract, test, and incident evidence held outside the platform.

The matrix is a control map, not a statement that a Finsaku deployment or customer is DORA compliant. Use the official DORA text, applicable regulatory technical standards, supervisory guidance, current contracts, and qualified advice for the entity being assessed.