A payment provider stops responding. Transfers remain pending. While the operations team investigates, an administrator changes a provider setting.
Who authorised the change? Which payments were affected? Did recovery restore the correct transaction states?
These questions connect operational resilience to the everyday work of running a payments platform. A team needs to restore service, understand the impact and show how it controlled the response.
The EU’s Digital Operational Resilience Act has applied since 17 January 2025. DORA establishes requirements for managing technology risk, responding to ICT incidents, testing resilience and overseeing ICT suppliers across the financial sector. ESMA’s DORA overview.
For payment businesses, the practical work starts with clear responsibilities, controlled access and evidence that remains useful when something goes wrong.
What DORA means for a payments platform
DORA applies to specified financial entities, including payment institutions and electronic money institutions, subject to the regulation’s scope and exemptions. A product’s description as a “payments platform” does not, by itself, determine its regulatory obligations. The operating entity and its activities matter. Regulation (EU) 2022/2554, Article 2.
For an in-scope operator, translating DORA into platform requirements means connecting policies to actual workflows.These are practical implementation examples. Their value comes from whether the team can produce and use the evidence during an actual disruption.
Control who can change the payment environment
Access decisions affect the potential impact of an error or a compromised account.
A support specialist may need to inspect a pending payment. A compliance officer may need to review a restriction. A finance user may need to approve a transaction. Each task calls for a defined set of permissions.
Operational area
Question the team needs to answer
Examples of supporting evidence
ICT risk management
Which systems support payments, and who can change them?
Asset inventories, access reviews, change records and recovery procedures
Incident management and reporting
What happened, what was affected and how did the team respond?
Incident timelines, impact assessments and reporting decisions
Resilience testing
Can the service recover with transaction data intact?
Test results, reconciliation records and verified corrective actions
ICT third-party risk
What happens when a technology supplier becomes unavailable?
Dependency maps, supplier assessments, contracts and exit plans
Broad access makes those responsibilities harder to separate. It can also give a routine support account the ability to affect sensitive financial operations.
Assign permissions around operational responsibilities
A useful access review starts with specific actions:
- Who can approve or reject a transaction?
- Who can change provider configuration?
- Who can create administrator accounts?
- Who can export customer or transaction data?
- Who reviews access when an employee changes role or leaves?
Finhost’s role-based access control assigns Back Office permissions through predefined Admin, Compliance, Support, Finance and Sales roles. Each administrator receives one role, with access outside that role restricted by default.
This gives teams a defined starting point for separating operational responsibilities. For example, the published role model distinguishes Compliance review and rejection permissions from Finance transaction approval.
Assess that separation against the operator’s actual approval policy. Different role permissions alone do not prove that every sensitive transaction passes through a mandatory two-person approval process.
Access reviews should also cover cloud accounts, databases, service credentials and supplier access. Back Office permissions address one part of the operating environment.
Build an incident timeline the team can trust
When payments stop moving, the team faces two connected tasks: recovering the service and understanding the disruption.
DORA requires processes for managing ICT-related incidents, classifying them and reporting major incidents. Reliable impact information supports those decisions. ESMA’s incident-management overview.
A practical investigation should establish:
- When the disruption began and when it was detected.
- Which services and transactions were affected.
- Whether an access or configuration change preceded the failure.
- What the team did to contain the issue.
- When service resumed and how recovery was checked.
The difference between “the service is back” and “the incident is resolved” can be substantial. A provider connection may recover while individual payments remain pending, incorrectly labelled or awaiting reconciliation.
Connect administrator actions to affected records
An audit trail helps investigators establish who performed an action and what it changed.
Finhost’s Full Audit Trail & Activity Logs provide searchable records of Back Office and customer activity. The documented functionality includes UTC timestamps, action results, before-and-after values for changes, and filtered CSV exports.
Those records can help answer a specific question: did an administrator change a setting before the disruption, during the response, or after recovery?
A complete incident timeline will usually draw on several sources. Application logs explain activity inside the platform. Infrastructure monitoring, provider notifications and incident records add service health, external events and response decisions.
Before relying on audit data, confirm the relevant event coverage, retention period, export permissions and availability during an outage.
Test recovery against real payment scenarios
A recovery exercise should show what happens to payments while a dependency is unavailable and after it returns.
Useful scenarios include a provider API timeout, delayed callbacks, a compromised administrator account and restoration from backup. Each exposes a different operational question.
A provider times out after receiving an instruction
The platform sends a payment instruction but receives no confirmation.
Before retrying, the team needs a way to establish whether the provider accepted the original request. An uncontrolled retry could create a duplicate payment.
A useful test checks how the platform handles an uncertain status, retrieves the provider’s records and decides whether a retry is appropriate.
A transaction callback arrives late
The customer sees a pending transfer while the provider has already processed it.
The exercise should test whether the platform can reconcile the status, update the customer-facing record and avoid triggering unnecessary manual action.
An administrator account is compromised
The team needs to revoke access, investigate previous activity and identify affected records.
Test whether revoked access stops working across relevant sessions and interfaces. Then check whether investigators can reconstruct the account’s actions.
Data is restored from backup
Successful restoration is only one part of recovery.
The team should also compare restored records with provider activity during the disruption. Payments processed after the backup was taken may need reconciliation before normal operations resume.
For every scenario, record the expected result, actual outcome, responsible owner, and corrective action. Retest the weakness after the correction has been implemented.
Make ICT supplier dependencies visible
Payments platforms depend on hosting, authentication, software, monitoring and other technology services. A disruption in one dependency can affect several customer journeys.
DORA requires in-scope financial entities to manage ICT third-party risk and maintain a register of relevant contractual arrangements. Using an external supplier does not remove the financial entity’s responsibility for its obligations. Regulation (EU) 2022/2554, Article 28.
For an operational team, a useful dependency review connects each supplier to the service it supports.
If an authentication provider becomes unavailable, can existing customers still access their accounts? If a monitoring service fails, how will the team detect another incident? If hosting is disrupted, where can responders retrieve recovery instructions and supporting records?
Establish the answers before an incident:
Dependency question | Operational decision
Which customer workflows rely on this supplier?
Define the likely service impact
Who owns the supplier relationship?
Assign an escalation contact
What evidence can the supplier provide?
Agree how investigations will be supported
What access does supplier support hold?
Define permissions and access review procedures
What happens during an extended outage?
Prepare continuity and exit arrangements
Temporary supplier access also needs an identifiable owner, a defined purpose and traceable activity. Emergency troubleshooting should still leave an understandable record.
Review one sensitive workflow from start to finish
A focused walkthrough can reveal gaps that remain hidden in a high-level security checklist.
Choose a sensitive workflow, such as a provider configuration change. Ask the team to demonstrate:
- Permission: who is allowed to make the change?
- Authorisation: what approval does the operating procedure require?
- Execution: which account performed the action?
- Evidence: what changed, and when?
- Validation: how was the result checked?
- Recovery: what happens if the change causes a disruption?
Repeat the exercise for transaction approval, administrator creation and data export.
The findings should lead to specific work: narrowing an overly broad role, removing an unused account, improving event coverage or making recovery evidence accessible during an outage.
Where Finhost supports operational resilience
Finhost’s access controls and activity logs support two everyday operational needs: limiting sensitive actions to the appropriate roles and preserving evidence of platform activity.
Together, they help teams connect responsibility with execution. Investigators can examine an action alongside the permissions held by the administrator who performed it.
DORA compliance also depends on the operator’s governance, infrastructure, incident procedures, testing programme and supplier arrangements. Platform capabilities contribute to that work; their implementation must fit the regulated business.
A practical starting point is one payment workflow. Show who can act, what the platform records, how the team handles a failure and how it verifies the outcome. Then apply the same review across the services customers rely on.
Top comments (0)