DORA and SYSC Compliance: An IT Checklist for UK Financial Services Firms

When a critical system fails, having policies and procedures in place is only part of the picture.

Could your organisation quickly establish which important business services are affected? Could your IT team identify the systems and third parties those services depend on? And could you show when your resilience and security controls were last tested?

For financial services firms, these are important operational questions.

Firms within scope of the FCA’s operational resilience rules need to identify their important business services, establish impact tolerances and be able to remain within those tolerances during disruption. The FCA’s transition period for achieving this ended on 31 March 2025.

Alongside UK requirements, organisations with relevant EU operations or relationships may also need to consider the Digital Operational Resilience Act (DORA). It introduces requirements around ICT risk, technology incidents, resilience testing and third-party dependencies.

For organisations reviewing DORA compliance, financial services requirements need to be translated into practical technology controls. This checklist provides a starting point for assessing whether the technology, testing, processes and evidence behind your operational resilience are working as intended.

Important: The requirements applying to a financial services organisation depend on its activities, regulatory permissions and structure. This article provides practical IT guidance and isn’t a substitute for legal or regulatory advice.

Does DORA Apply to UK Financial Services Firms?

DORA applies to a broad range of financial entities operating within the EU and has applied since 17 January 2025. Its requirements cover ICT risk management, technology-related incidents, digital operational resilience testing and third-party technology risk.

For UK financial services firms, DORA compliance becomes particularly relevant where an organisation has activities or relationships within the EU.

This may include:

• UK financial groups with regulated subsidiaries or branches in the EU;
• firms providing regulated financial services through EU entities;
• UK technology or ICT providers supporting EU financial organisations and encountering DORA requirements through those customer relationships; and
• financial groups operating across UK and EU regulatory environments.

These organisations may need to consider DORA alongside UK operational resilience requirements rather than treating one framework as a replacement for the other.

A firm operating solely within the UK isn’t automatically subject to DORA simply because it is FCA regulated. UK activities may instead fall under domestic requirements, including the FCA’s operational resilience framework and relevant SYSC provisions.

This makes DORA compliance financial services planning particularly important for organisations operating across UK and EU regulatory environments. There is common ground around technology risk, testing, incidents and third-party dependencies, but satisfying one framework doesn’t automatically satisfy the other.

The practical starting point is to establish which requirements apply and map them against existing controls.

For UK-regulated firms, understanding what FCA operational resilience means in practice can help identify where documented controls need to be supported by more effective testing and evidence.

What Does SYSC Require?

Within the UK, the FCA’s Senior Management Arrangements, Systems and Controls sourcebook, commonly known as SYSC, sets requirements around how regulated firms organise and control their operations.

SYSC 15A covers operational resilience for firms within its scope.

The FCA’s rules apply to organisations including banks, building societies, PRA-designated investment firms, insurers, Recognised Investment Exchanges, enhanced-scope SMCR firms and certain payments and electronic money institutions.

Relevant requirements include:

• identifying important business services;
• setting impact tolerances;
• understanding the resources needed to deliver those services;
• testing against severe but plausible disruption;
• identifying and addressing vulnerabilities;
• maintaining response and recovery arrangements; and
• evidencing the firm’s approach.

For IT teams, this means understanding how applications, cloud platforms, connectivity, endpoints, identity services, data and external suppliers support the firm’s important business services.

If one component fails, the organisation needs to understand the effect on the service it supports.

Where Do DORA and FCA Operational Resilience Overlap?

DORA and the UK’s operational resilience framework differ in scope and detailed requirements, but they raise many of the same technology questions:

• How are ICT and operational risks managed?
• How will services continue or recover following disruption?
• How are technology incidents detected and escalated?
• Have resilience and security controls been tested?
• How are third-party dependencies managed?
• Can the organisation demonstrate that its controls work?

For organisations dealing with both frameworks, mapping these requirements against existing technology controls can reduce unnecessary duplication.

A backup and recovery process, for example, may support several requirements. But firms also need to know whether it has been tested, whether recovery is quick enough for the service concerned and whether the result can be evidenced.

DORA and SYSC IT Compliance Checklist

1. Map Important Business Services and Technology Dependencies

Start by connecting important business services with the technology required to deliver them.

This could include:

• business applications;
• cloud infrastructure;
• networks and connectivity;
• endpoints;
• business and client data;
• authentication and identity platforms; and
• third-party technology providers.

The objective is to understand the dependency chain.

If an application becomes unavailable, which service is affected? If an identity platform fails, what else becomes inaccessible? If a technology provider suffers an outage, which operations are disrupted?

The FCA’s observations on operational resilience reinforce the importance of understanding these dependencies when assessing important business services and impact tolerances.

Evidence to retain: dependency maps, system inventories, architecture documentation, ownership information and review records.

2. Maintain an ICT Risk Management Framework

Effective DORA compliance financial services controls depend on technology risks being understood and managed before they develop into incidents.

An ICT risk review might consider:

• unsupported systems;
• unpatched vulnerabilities;
• insecure configurations;
• inappropriate access;
• single points of failure;
• backup and recovery weaknesses;
• cloud dependencies; and
• gaps in security monitoring.

Risks should have clear owners, agreed actions and a way of tracking remediation.

Technology resilience also depends on the organisation’s wider security posture. Reviewing cyber security within a financial services environment alongside operational risk can help uncover weaknesses affecting systems, data and services.

Where a formal information security framework is appropriate, ISO 27001 provides a structured approach to identifying risk, applying controls and continually improving information security management.

Evidence to retain: risk registers, vulnerability reports, patching records, assessments and remediation plans.

3. Establish Clear Incident Management and Escalation

When an incident occurs, everyone involved should understand what happens next.

Document:

• how incidents are detected and classified;
• who needs to be notified;
• when compliance or senior management becomes involved;
• how external suppliers are engaged;
• who makes key decisions; and
• where actions are recorded.

IT may identify and resolve a technical failure, but compliance and operations teams also need enough information to assess its impact on customers, important business services and any regulatory obligations.

DORA and UK frameworks have different incident requirements, so applicable reporting obligations should be established separately rather than assumed to be covered by the IT incident process.

Evidence to retain: incident logs, escalation procedures, communications, root-cause analyses and post-incident reviews.

4. Test Business Continuity and Disaster Recovery

A recovery plan only becomes meaningful when it is tested.

Realistic scenarios could include:

• ransomware;
• failure of a critical application;
• cloud platform disruption;
• loss of connectivity;
• compromise of a privileged account; or
• failure of an important technology supplier.

For firms within scope of FCA operational resilience requirements, the key question is whether the technology supporting an important business service can recover quickly enough for that service to remain within its impact tolerance.

A successful test isn’t simply one where a backup restores. Firms should understand how long recovery took, what failed and what needs improvement.

Evidence to retain: recovery plans, test results, recovery times, identified weaknesses and remediation records.

5. Manage Third-Party ICT Risk

Financial services environments increasingly depend on cloud platforms, SaaS applications and outsourced technology services.

Third-party oversight is an important part of DORA compliance financial services organisations need to consider where the regulation applies.

Firms should know:

• what each provider supplies;
• which services depend on them;
• where relevant data is held;
• what security and resilience controls exist;
• how incidents are communicated;
• which significant subcontractors are involved; and
• how a service could be transitioned if required.

Concentration risk matters too. Several different systems may ultimately depend on the same cloud, identity or connectivity provider.

Evidence to retain: supplier assessments, contracts, service reviews, security information, risk assessments and exit plans.

6. Test Operational Resilience and Security

Testing helps move the organisation from believing a control works to having evidence of how it performs.

Depending on risk and applicable requirements, testing could include:

• vulnerability assessments;
• penetration testing;
• backup restoration;
• disaster recovery exercises;
• phishing simulations;
• incident-response exercises; and
• wider resilience scenarios.

The important part is what happens after the test. Findings should be assessed, prioritised and addressed rather than added to a report and forgotten.

Several common penetration testing mistakes, including ineffective remediation, can reduce the value of security testing.

Evidence to retain: testing scopes, reports, remediation records and retest results.

7. Define Responsibilities and Train Staff

DORA and SYSC compliance cannot sit with IT alone.

IT, compliance, operations, senior management and external suppliers may all have roles during an operational incident.

Those responsibilities should be established before something goes wrong.

Employees also need to understand how to report suspicious activity or technology problems, while those with specific resilience responsibilities need to know how incidents should be escalated.

Evidence to retain: responsibility matrices, training records, escalation procedures and participation in resilience exercises.

8. Maintain Audit Trails and Compliance Evidence

Evidence should show not only that a control exists, but how it operates.

Firms should be able to establish:

• which controls are in place;
• who owns them;
• when they were reviewed or tested;
• what weaknesses were found;
• what action followed; and
• whether remediation was verified.

For example, stating that vulnerability management takes place is less useful than demonstrating when scanning occurred, what was identified and whether critical findings were resolved.

The FCA has highlighted the importance of firms being able to evidence their operational resilience approach through their self-assessment.

Evidence collection should therefore form part of everyday technology management.

Common IT Compliance Gaps Firms Discover Too Late

Weaknesses often become visible when something breaks or evidence is requested.

Common examples include:

• backups exist but full recovery hasn’t recently been tested;
• important services are identified but technology dependencies aren’t fully mapped;
• suppliers were reviewed at onboarding but not subsequently reassessed;
• penetration tests take place but remediation isn’t consistently followed through;
• IT and compliance escalation processes aren’t connected;
• resilience exercises aren’t properly documented; and
• technology documentation no longer represents the live environment.

The issue is often the gap between having a control, knowing it works and being able to prove it works.

DORA compliance and FCA operational resilience should therefore be treated as ongoing operational disciplines rather than periodic paperwork exercises.

What Should Your IT Provider Be Able to Evidence?

Outsourcing technology doesn’t outsource regulatory accountability.

An IT provider can, however, contribute to the controls and evidence underpinning a firm’s resilience.

For financial services organisations using managed IT services, this could include:

• infrastructure monitoring;
• patch and vulnerability management;
• backup and recovery testing;
• security monitoring;
• incident escalation;
• technology documentation;
• security testing; and
• service and audit reporting.

The regulated organisation remains responsible for its governance and regulatory decisions, while the MSP supports the technology and provides evidence relating to the controls it operates.

The value of an IT provider is not just in maintaining systems, but in being able to provide clear evidence of the controls it manages, from patching and vulnerability management to backups, recovery testing and incident support. This becomes particularly important in regulated environments, where technology needs to support day-to-day operations while remaining secure, resilient and auditable.

When assessing a provider, firms can also look for independent indicators of security capability. Akita is ISO 27001 certified, a Cyber Essentials Plus Assessor and CREST-accredited.

Turning DORA and SYSC Requirements Into Practical IT Controls

DORA, SYSC and FCA operational resilience differ in jurisdiction, scope and detail, but they raise similar practical questions.

Do you understand what your important services depend on? Do you know what happens if critical technology fails? Have recovery arrangements been tested? Can you evidence the results?

A useful starting point is to:

1. Map technology dependencies.
2. Assess the risks.
3. Test controls under realistic conditions.
4. Remediate weaknesses.
5. Document the results.
6. Review arrangements as technology and risks evolve.

Taking this approach makes DORA compliance financial services planning more practical while supporting wider operational resilience. Instead of becoming a periodic documentation exercise, resilience becomes part of ongoing technology management.

If you’re reviewing whether your technology environment supports your resilience and compliance requirements, speak to Akita’s financial services team about your DORA and SYSC IT requirements.