IT Compliance for Financial Services: What FCA-Regulated Firms Should Expect From IT Support

This blog is intended to provide general information and guidance. Cobweb is not a legal adviser, and the content should not be taken as legal advice.

When the regulator asks how your firm would keep serving clients through an IT failure, the answer sits with your systems, your suppliers and the people who support them. That makes IT support part of your compliance position, whether it is run in-house or outsourced.

The useful starting point is knowing which rules apply to your firm and what evidence your IT arrangements should provide. There is no single FCA technology checklist for every regulated business. A small financial advice firm, a payment institution and a bank have different permissions, risk profiles and obligations. However, the underlying expectation is consistent: manage technology risk carefully, understand critical dependencies and be able to demonstrate that controls work in practice.

This guide explains where regulation and day-to-day IT meet, including the operational incident and third party reporting rules due to take effect on 18th March 2027. It also gives you practical questions to use when reviewing an internal IT team or managed service provider.

1. Which rules shape IT in a financial services firm?

Several overlapping requirements can influence how a UK financial services firm manages technology. The FCA Handbook’s systems and controls expectations are a core starting point. Depending on the firm’s type and permissions, these may be reinforced by the FCA’s operational resilience framework and its expectations for outsourcing and third party risk. UK GDPR adds risk-based security duties for personal data. Firms with EU operations or contractual links may also need to consider the EU’s Digital Operational Resilience Act, known as DORA.

The first compliance task is therefore one of scope. Confirm which legal entities, permissions, services and locations are covered, then connect those requirements to the technology that supports them. Avoid assuming that a control used by a large bank is automatically proportionate for a smaller adviser, or that being outside a specific operational resilience rule removes the need for sound continuity planning.

Across these frameworks, the practical themes are similar: identify important services, control access to data, oversee suppliers, prepare for disruption, keep reliable records and retain evidence. Your IT support should make those activities visible rather than leaving them hidden in technical systems or informal conversations.

2. Does FCA operational resilience apply to your firm?

The FCA’s formal operational resilience rules apply to specified categories of firm, including banks, building societies, insurers, payment and e-money institutions and enhanced scope SM&CR firms. Many smaller regulated firms are not within the full regime, so each business should check its classification and permissions rather than rely on a general description.

For firms in scope, operational resilience is organised around important business services. A firm identifies the services whose disruption could cause intolerable harm to consumers or market integrity, sets an impact tolerance for each service, and maps the people, processes, technology, facilities and third parties needed to deliver it. It must then test whether it can remain within those tolerances during severe but plausible disruption. In-scope firms have been expected to operate consistently within their impact tolerances since 31th March 2025.

This changes the conversation with IT support. ‘Are the servers available?’ is not enough. The stronger question is: ‘Can clients still receive the important service within the agreed tolerance if identity, connectivity, Microsoft 365, a line-of-business application or a key supplier fails?’ The test should produce decisions, actions and retained evidence, not simply a green status report.

Firms outside the formal regime still need appropriate systems, controls and business continuity arrangements. The same approach remains useful at a proportionate scale: identify the services that matter most, map what they depend on, decide how long disruption is acceptable and test recovery against that expectation.

3. What changes with incident and third party reporting in 2027?

The FCA’s final rules on operational incident and third party reporting take effect on 18th March 2027. For firms in scope, reportable operational incidents will need to be assessed against specified thresholds. Relevant firms will also need to maintain, and in some cases submit, structured information about material third party arrangements.

The scope is not identical across the incident-reporting and third party elements, so firms should review the final policy statement against their own permissions and legal entities. The preparation period should be used to agree ownership across compliance, operations, risk, procurement and IT.

For IT support, the practical requirement is a dependable chain from detection to regulatory decision-making. Monitoring and service desk records should identify when an incident started, which services and customers are affected, whether data or availability has been compromised, what containment has occurred and who has been notified. Clear severity criteria and escalation routes are essential, because a technically significant event can become a compliance event when impact or duration crosses a threshold.

Third party reporting also raises the standard of supplier information. Records should show the service provided, legal entity, data involved, hosting or delivery locations, subcontracting where relevant, business owner, criticality, contract dates and exit arrangements. If this information sits across spreadsheets, contracts and individual inboxes, producing an accurate register will be unnecessarily difficult.

4. Who is accountable when IT is outsourced?

Outsourcing IT does not outsource regulatory accountability. The regulated firm remains responsible for the service and must have enough information, expertise and control to oversee the provider. This applies to a fully managed IT service and to individual cloud platforms or specialist applications.

A well-drawn IT support agreement should define service levels, support hours, security responsibilities, incident notification, access to information for audit and regulatory purposes, data locations, approved subcontractors, continuity measures and exit support. Responsibilities should be explicit. For example, if the provider monitors backups but the firm owns the recovery objective, the agreement and review process should say who approves the objective, who runs restore tests and who closes failed actions.

Cloud services must be included in the same oversight. Microsoft 365, Azure, hosted client portals, customer relationship management systems and financial planning or payment platforms are third party dependencies. They belong in supplier records, risk assessments and service maps even when they are widely used or bought through another provider.

5. How should client data, access and records be controlled?

The UK GDPR security principle is risk-based. Technical and organisational measures should reflect the sensitivity and volume of data, the harm that could result from misuse or loss, and the threats facing the firm. Financial records, identity documents, bank details and special category data justify strong preventative and detective controls.

In practice, this usually means multi-factor authentication (MFA) for user and administrator access, role-based permissions, separate administrator accounts, managed and encrypted devices, timely security updates and a controlled joiner, mover and leaver process. Access reviews should confirm not only who has an account, but whether their current role still justifies access to each system and data set.

Record keeping also needs deliberate configuration. Emails, client files and, where applicable, recorded communications should be retained for the required period, retrievable during a complaint or regulatory review and protected against inappropriate alteration or deletion. Microsoft 365 retention policies, labels and eDiscovery capabilities should reflect the firm’s approved retention schedule. A default mailbox setting is not a records-management policy.

Cyber Essentials can provide a recognised baseline for controls such as secure configuration, access control, malware protection, firewalls and security update management. Certification does not by itself prove FCA compliance, but it can support due diligence requests from clients, professional networks, cyber insurers and supply-chain partners.

Related reading: Cyber security guide for finance 2026 and Cyber Essentials services.

6. What about DORA and EU business?

DORA has applied across the EU since 17 January 2025. It is not UK law, but UK-headquartered businesses can still be affected through an EU branch, subsidiary or group entity, or through contracts to supply ICT services to EU financial entities.

Where DORA applies, firms face detailed requirements for ICT risk management, incident management and reporting, digital operational resilience testing and third party risk. Contracts with technology suppliers may need specific provisions covering service descriptions, locations, security, assistance during incidents, audit and access rights, continuity, termination and exit.

A UK firm should therefore ask a targeted scope question rather than assume DORA is irrelevant or universally applicable. Compliance, legal and procurement teams should identify affected entities and contracts, then ensure IT support can supply the operational evidence those obligations require.

For a deeper explanation, see Cobweb’s DORA compliance guide.

7. What evidence should your IT support give you?

Good IT support resolves day-to-day issues. Compliance-ready IT support also produces evidence that leaders can understand, challenge and retain. Reports should be tied to risk and service outcomes, not filled with technical activity that cannot be linked to a control.

A useful monthly or quarterly pack may include device and patch compliance, endpoint protection status, MFA coverage, privileged access changes, joiner and leaver completion, backup success, restore-test results, significant incidents, recurring service issues, supplier risks and overdue actions. Exceptions should have an owner and due date.

Recovery evidence deserves particular attention. Recovery time objectives (RTO) and recovery point objectives (RPO) should be agreed for priority systems and aligned with business impact tolerances where applicable. Restore tests should confirm that data can be recovered and the service can be made usable, not merely that a backup job completed. Results, lessons and remedial actions should be kept on file.

Finally, the firm needs a named service owner, a clear escalation route and a regular review meeting. Minutes should record material risks, decisions, accepted exceptions and actions. This gives senior management and compliance teams a defensible view of whether IT arrangements remain suitable as the firm, its suppliers and regulatory expectations change.

Financial services IT compliance review checklist

The next step: connect compliance requirements to IT evidence

IT compliance for the finance industry is not achieved by purchasing a particular tool or passing every technology decision to a provider. It depends on knowing which obligations apply, translating them into proportionate controls and keeping evidence that those controls work.

An effective review should leave you with a clear service map, accountable owners, current supplier information, tested recovery arrangements and reporting that supports regulatory decisions. If your IT team or provider cannot show those things, that is the right place to begin.