Are the PRA and FCA operational resilience rules binding, and what did the 31 March 2025 deadline mean?

Yes. The requirements sit in the FCA Handbook (SYSC 15A) and the PRA Rulebook and came into force on 31 March 2022, with PRA SS1/21 and FCA PS21/3 setting out the expectations behind them. The 31 March 2025 deadline was the date by which firms in scope had to have performed mapping and testing so that they could remain within impact tolerances for each important business service, and to have made the necessary investments. It is not a one-off exercise: firms are expected to keep their mapping and testing under review, at least annually or after a material change, and to remediate vulnerabilities in time.

Can Ostorlab run our CBEST assessment?

No. CBEST is a regulator-led assessment, run with CREST-accredited threat intelligence and penetration testing providers against the systems and services that underpin your important business services, and the regulators decide which firms take part. Ostorlab supports the regular testing of your app and APIs, helps you go into a CBEST with known issues already fixed, and retests afterwards.

Do the UK rules mention mobile apps?

Not by name. The operational resilience rules are about services, not channels: where mobile banking delivers an important business service, the app and its APIs are in scope of mapping, testing and remediation. The payment rules are more direct. Strong customer authentication applies to online account access, electronic payment transactions and other remote actions that carry a risk of payment fraud, wherever the customer performs them.

What changed for incident reporting in 2026?

On 18 March 2026 the FCA published PS26/2, its final rules and guidance on operational incident and third party reporting, developed with the PRA and the Bank of England. They introduce a single definition of an operational incident, reporting thresholds, a standardised reporting process with standard or enhanced reports, and new duties to notify material third party arrangements and keep a register. The rules apply from 18 March 2027. Separately, regulation 99 of the Payment Services Regulations 2017 already requires payment service providers to notify the FCA of major operational or security incidents without undue delay.

Does Ostorlab cover the outsourcing and third-party rules?

Partly. SS2/21 covers governance, contracts, audit rights, data security and exit plans, much of which is not a technical test. Where its expectations reach the app and its APIs, such as data-in-transit and data-at-rest controls, vulnerable components and the security testing results you can demand from a provider, Ostorlab produces evidence you can keep.

Does Ostorlab make our app meet the PRA and FCA requirements?

No tool does that on its own. The rules cover governance, impact tolerances, scenario testing, incident reporting, recovery and third-party management, and much of that sits outside the app. Ostorlab helps you test the controls in your app and its APIs, and gives you evidence for each result.

Can our data stay in the region?

Yes. On the Enterprise plan you can choose European Union data residency, or run scans on-premises. Ostorlab is SOC 2 Type II audited, and the details are in the Trust Center.

What do you need to run a scan?

At a minimum, you can search for your application on the App Store or Google Play and run a free, fast scan on ostorlab.co with no login required. Or provide the mobile artifact (APK, AAB or IPA). For deeper coverage of authenticated flows, add test credentials before running a full scan.

PRA and FCA operational resilience: test your mobile banking app before and after every release.

The PRA and FCA operational resilience rules require firms to be able to remain within impact tolerances for their important business services in severe but plausible disruptions, and to identify and remediate vulnerabilities in time. CBEST adds threat intelligence-led assessments for the firms the regulators select. The payment rules require strong customer authentication on online account access, payments and other remote actions. Ostorlab tests your app and the APIs behind it, behind login, on every release.

Assesses the mobile app and the APIs it calls, on the build your customers download
Tests strong customer authentication, one-time codes, dynamic linking and session handling with your test accounts
Lists the SDKs and native libraries in each release and maps them to known vulnerabilities
Proves each finding with a replayable exploit or request and response evidence

Scan your own app Book a demo

Free scan of your app from the App Store or Google Play. No login required.

Who it applies to: Banks, building societies, PRA-designated investment firms, insurers, enhanced scope SM&CR firms, and payment and e-money firms
Key date: Operational resilience rules in force since 31 March 2022; the deadline to be able to remain within impact tolerances was 31 March 2025
Focus: Impact tolerances, scenario testing, vulnerability remediation, threat-led assessment and strong customer authentication
Main reference: FCA Handbook SYSC 15A and PRA SS1/21, with FCA PS21/3

Key dates

The PRA and FCA texts behind your mobile channel

The operational resilience rules sit in the FCA Handbook and the PRA Rulebook, with CBEST and the payment rules alongside them. The dates below are for the texts cited on this page.

29 March 2021
Final operational resilience rules
The FCA publishes PS21/3 and the PRA publishes SS1/21, with rules and expectations on important business services, impact tolerances, mapping and scenario testing.
31 March 2022
Rules come into force
FCA SYSC 15A and the PRA operational resilience parts apply. Firms must have identified their important business services, set impact tolerances and started mapping and testing.
31 March 2025
Impact tolerance deadline
By this date, firms must have performed mapping and testing so that they can remain within impact tolerances for each important business service, and made the investments to operate within them.
12 November 2024
Critical third parties
The PRA, Bank of England and FCA publish final rules for critical third parties (PRA PS16/24, FCA PS24/16). The regime takes effect on 1 January 2025.
20 October 2025
Cyber response and recovery practices
The Bank, PRA and FCA publish effective practices observed across systemic firms on cyber response and recovery. The publication introduces no new requirements.
18 March 2026
Incident reporting rules
The FCA publishes PS26/2 on operational incident and third party reporting, with a single definition of an operational incident and reporting thresholds. The rules apply from 18 March 2027.
15 May 2026
Frontier AI statement
The Bank of England, FCA and HM Treasury tell firms to triage, prioritise and remediate vulnerabilities faster and at scale, including in third-party and open-source software.
13 July 2026
First CTP designations
HM Treasury designates four global cloud and technology providers as critical third parties: Amazon Web Services EMEA SARL, Google Cloud EMEA Limited, Microsoft Ireland Operations Limited and Oracle Corporation UK Limited.

What the PRA and FCA ask

The PRA and FCA rules, applied to your mobile app

For each rule: what the text says, what it means for a mobile banking app, how Ostorlab helps, and what stays with your team.

FCA Handbook SYSC 15A.2; PRA SS1/21, March 2022
Identify important business services and set impact tolerances
What the text says
Under FCA SYSC 15A and the PRA operational resilience parts, a firm must identify its important business services and set an impact tolerance for each one, the maximum tolerable disruption. It must ensure it can remain within each impact tolerance in the event of a severe but plausible disruption, and review its assessments at least once a year or after a material change. PRA SS1/21 sets out the expectations behind the rules.
Source:FCA Handbook SYSC 15A.2; PRA SS1/21, March 2022
What it means for your mobile app
Mobile banking is almost always an important business service, and the app is the main way customers reach it. If the app or its APIs fail or are breached, the firm has to be able to stay within the tolerance it set.
How Ostorlab helps
Ostorlab tests the app and its APIs on every release, so weaknesses that would disrupt the service are found before customers see them. Findings are rated and tracked to closure.
What stays with you
Identifying the services and setting the tolerances, and the response and recovery arrangements behind them.
FCA Handbook SYSC 15A.4.1; PRA SS1/21, 4.2 and 4.15
Map the resources and remediate vulnerabilities in time
What the text says
Firms must identify and document the people, processes, technology, facilities and information needed to deliver each important business service, in enough detail to identify vulnerabilities and remedy them. The PRA expects the speed of remediation to be commensurate with the potential impact of a disruption, and expects firms to develop and implement remediation plans where a service would not be able to remain within its impact tolerance.
Source:FCA Handbook SYSC 15A.4.1; PRA SS1/21, 4.2 and 4.15
What it means for your mobile app
The app binary, its SDKs and the APIs behind it are technology resources in that map. A vulnerability in any of them is a vulnerability in the service.
How Ostorlab helps
Mobile SAST analyses the binary including embedded SDKs, SCA maps components to known vulnerabilities, and the AI-agent pentest tests the running app and its APIs. Findings become tickets in the platform or in Jira and ServiceNow, and are retested after the fix.
What stays with you
Deciding remediation deadlines, resourcing the fixes and tracking them to closure.
FCA Handbook SYSC 15A.5 and 15A.6; PRA SS1/21, Chapter 6
Run scenario testing and learn from it
What the text says
Firms must develop and keep up to date a testing plan and carry out scenario testing of severe but plausible disruptions, including unavailability of third-party services, loss or reduced provision of technology, and corruption or deletion of critical data. Testing may be paper based, simulations or live systems, but should not pose a material risk of creating a disruption. After testing or a disruption, firms must conduct a lessons learned exercise and make the improvements identified. Records are kept for at least six years.
Source:FCA Handbook SYSC 15A.5 and 15A.6; PRA SS1/21, Chapter 6
What it means for your mobile app
Scenario tests exercise the whole service, not the app alone. The app and API findings from those tests are only useful if the underlying weaknesses are fixed and can be proven fixed.
How Ostorlab helps
Ostorlab does not run scenario testing or exercises. It tests the app and API controls that your scenarios depend on, before and after the exercise, so the technical items in your lessons learned have evidence.
What stays with you
Designing and running the scenarios, business continuity and recovery plans, and the lessons learned exercises.
CBEST Implementation Guide, 2024 edition, Bank of England
Prepare for CBEST threat intelligence-led assessments
What the text says
CBEST is the regulators' threat intelligence-led assessment framework, used since 2014 for firms and financial market infrastructures selected by the PRA, the Bank of England and the FCA. A CBEST mimics the actions of real attackers against the systems and services that underpin important business services, runs in four phases from initiation to a regulator-supervised remediation plan, and is delivered by CREST-accredited threat intelligence and penetration testing providers. The 2024 edition of the CBEST Implementation Guide adds guidance on remediation documentation and on third parties to important business services.
Source:CBEST Implementation Guide, 2024 edition, Bank of England
What it means for your mobile app
CBEST is regulator-led and scoped around your important business services. It is not a replacement for the regular testing of your app and APIs between assessments.
How Ostorlab helps
Ostorlab does not run CBEST. It helps you go into a CBEST with known app and API issues fixed, and retests the app and API items of your remediation plan afterwards.
What stays with you
Scoping and running CBEST, choosing accredited providers, and the remediation plan the regulator supervises.
PRA SS2/21, November 2024 version, Chapters 7 and 8
Manage outsourcing and third-party risk
What the text says
Under PRA SS2/21, firms remain responsible for outsourced services, including material outsourcing. The PRA expects robust controls for data in transit, in memory and at rest, including encryption and key management, identity and access management, access and activity logging, and incident detection and response. For material outsourcing, written agreements must give access and audit rights that cover the results of security penetration testing carried out on the provider's applications, data and systems. The statement also covers business continuity and exit plans.
Source:PRA SS2/21, November 2024 version, Chapters 7 and 8
What it means for your mobile app
Your app bundles third-party SDKs that talk to their own backends, and your APIs may run on cloud services. Their security is part of your outsourcing and third-party risk view.
How Ostorlab helps
Ostorlab lists the SDKs and native libraries in each release with their versions, maps them to known vulnerabilities, and shows what the app and its SDKs exchange with backends over the network.
What stays with you
Due diligence, contracts, audit rights, exit plans and cloud configuration.
FCA, Critical Third Parties: Strengthening UK Financial Services; PRA PS16/24 and FCA PS24/16
Know the critical third parties behind your services
What the text says
The critical third parties regime, in force since 1 January 2025, allows HM Treasury to designate third parties whose failure or disruption could threaten the stability of, or confidence in, the UK financial system, and allows the regulators to oversee the services those parties provide. The first designations, covering four global cloud and technology providers, came into force on 13 July 2026. The regime complements rather than replaces firms' own responsibilities: firms and their boards remain accountable for managing third-party risk and remaining operationally resilient.
Source:FCA, Critical Third Parties: Strengthening UK Financial Services; PRA PS16/24 and FCA PS24/16
What it means for your mobile app
If your app or backend runs on a designated provider, you still own the risk. The regime gives the regulators another lever; it does not transfer your obligations.
How Ostorlab helps
Ostorlab tests the controls in your app and its APIs wherever they run, so the evidence you hold does not depend on a provider's own assurances.
What stays with you
Contractual arrangements with providers, and your own outsourcing and resilience obligations.
Payment Services Regulations 2017, regulation 100; FCA, Strong Customer Authentication
Apply strong customer authentication to the app and its payments
What the text says
Under regulation 100 of the Payment Services Regulations 2017, a payment service provider must apply strong customer authentication where a customer accesses their payment account online, initiates an electronic payment transaction, or carries out any action through a remote channel that may imply a risk of payment fraud or other abuses. Remote payments must use authentication that dynamically links the transaction to a specific amount and a specific payee. Providers must also maintain adequate security measures to protect the confidentiality and integrity of personalised security credentials. The FCA expects authentication solutions that work for all groups of consumers, including customers who do not use a mobile phone.
Source:Payment Services Regulations 2017, regulation 100; FCA, Strong Customer Authentication
What it means for your mobile app
Login, payments and sensitive account changes in the app all sit inside SCA. The controls have to be enforced by the backend, not just presented by the app.
How Ostorlab helps
Ostorlab completes SMS, email or TOTP one-time codes with your test accounts and tests SCA enforcement, dynamic linking and step-up flows, including how attackers try to manipulate them, together with the API calls behind them.
What stays with you
Choosing authentication methods and exemptions, transaction monitoring, and the accessibility of the methods you offer.
Payment Services Regulations 2017, regulations 98 and 99; FCA PS26/2, 18 March 2026
Manage operational and security risks, and report incidents
What the text says
Regulation 98 of the Payment Services Regulations 2017 requires each payment service provider to maintain a framework with appropriate mitigation measures and controls for the operational and security risks of its payment services, including effective incident management and the detection and classification of major operational and security incidents, with an updated assessment provided to the FCA at least annually. Regulation 99 requires notification to the FCA without undue delay of a major operational or security incident, and informing payment service users where their financial interests are affected. From 18 March 2027, the FCA's PS26/2 rules create a single FCA, PRA and Bank of England regime for operational incident reporting, with one definition of an operational incident, reporting thresholds and standard or enhanced reports.
Source:Payment Services Regulations 2017, regulations 98 and 99; FCA PS26/2, 18 March 2026
What it means for your mobile app
Incidents that start in the app or an API are operational and security incidents. The evidence you keep during testing is what lets you classify and report them quickly.
How Ostorlab helps
Ostorlab does not report incidents to regulators. It keeps per-finding evidence, severity and retest history that your incident and reporting teams can use.
What stays with you
Incident management, classification, notification to the FCA and communication with customers.
UK GDPR, Article 32; ICO, A guide to data security
Protect personal data and test your security measures
What the text says
Article 32 of the UK GDPR requires controllers and processors to implement technical and organisational measures appropriate to the risk, including encryption or pseudonymisation, the ability to ensure ongoing confidentiality, integrity, availability and resilience, and a process for regularly testing, assessing and evaluating the effectiveness of those measures. The ICO's guidance says this testing can be done through techniques such as vulnerability scanning and penetration testing, and that firms should document the results and act on the recommendations, or have a valid reason not to.
Source:UK GDPR, Article 32; ICO, A guide to data security
What it means for your mobile app
The app is where customer data is collected, displayed and stored on a device the bank does not control. The measures protecting it need regular, documented testing.
How Ostorlab helps
Ostorlab looks for session tokens and personal data in local storage, caches, logs and screenshots, checks transport protections, and finds API keys and credentials in the app package, with file system evidence of what was written, where and when.
What stays with you
The risk assessment, the measures themselves, data protection impact assessments and breach notification.
Bank of England, FCA and HM Treasury joint statement on frontier AI models and cyber resilience, 15 May 2026
Watch for and patch vulnerabilities faster
What the text says
In a joint statement on 15 May 2026, the Bank of England, the FCA and HM Treasury said frontier AI models can rapidly identify and enable exploitation of a potentially large number of vulnerabilities across firms' technology estates, and that firms should be able to triage, prioritise, risk assess and remediate vulnerabilities more quickly, more frequently and at scale, including through automation where appropriate. The statement also points to the risks from third parties, supply chains and open-source software, and to the effective practices on cyber response and recovery published by the Bank, PRA and FCA in October 2025.
Source:Bank of England, FCA and HM Treasury joint statement on frontier AI models and cyber resilience, 15 May 2026
What it means for your mobile app
An app release can be vulnerable the day after it ships. Vulnerability discovery and patching have to run on a cadence the release pipeline can keep up with.
How Ostorlab helps
Ostorlab runs scans from your CI/CD pipeline on every build and monitors store releases without manual triggers, so new findings surface on the release they affect, and fixes can be retested the moment they ship.
What stays with you
Patching decisions, change management and the operational risk of remediating at scale.

Summary of public PRA, FCA, Bank of England, ICO and legislation texts, checked on 27 September 2026. This page is not legal advice.

Mapping

PRA and FCA rules, control by control

The controls the PRA and FCA texts point to, how Ostorlab tests them in your app and its APIs, and the evidence you can keep.

PRA and FCA rules, control by control
Control	How Ostorlab helps	Evidence you keep
Important business services and impact tolerancesSYSC 15A.2; SS1/21	AI-agent pentest of the app and its APIs, behind login, on the build you ship. Details	A working exploit you can replay for each AI-agent finding, and a coverage heatmap
Mapping, vulnerabilities and remediation deadlinesSYSC 15A.4; SS1/21 4.15	Findings rated critical to low, tracked as tickets and retested after the fix. Details	Ticket history and retest result for each finding
Scenario testing readinessSYSC 15A.5	Tests the app and API controls your scenarios depend on, before and after the exercise. Details	Scan results per build, with reproduction steps
CBEST preparation and remediationCBEST Implementation Guide 2024	Retests the app and API items of a CBEST remediation plan. Details	Retest results for the remediation items you scope
Third-party and open-source componentsSS2/21 Chapter 7; frontier AI statement	Fingerprints statically compiled libraries and maps them to known vulnerabilities, release to release. Details	Mapped vulnerabilities with upgrade or replace recommendations, and closure tracked across releases
Outsourced service security testingSS2/21 8.4	Tests the app and the APIs it calls wherever they are hosted, with request and response evidence. Details	Request and response evidence for each API finding
Strong customer authentication and dynamic linkingPSRs 2017 reg 100	Logs in with one-time codes and tests SCA enforcement, dynamic linking and step-up flows. Details	Findings on login, payment and step-up flows, with reproduction steps
Personalised security credentialsPSRs 2017 reg 100(3); SCA technical standards	Finds API keys, tokens and credentials in the app package and validates whether they work. Details	Validated secrets, with the permissions and services they expose
Data protection on the device and in transitUK GDPR Article 32; ICO guidance	Looks for tokens and personal data in storage, caches, logs and screenshots, and checks transport protections. Details	File system evidence showing what was written, where and when
Incident evidence and reportingPSRs 2017 reg 99; FCA PS26/2	Keeps per-finding evidence, severity and retest history that supports incident classification.	Finding evidence, severity ratings and retest history

Ostorlab tests controls in the app and its APIs. Scenario testing, CBEST, SOC monitoring, incident response and reporting, business continuity and recovery, governance and physical security stay with your teams.

Action plan

PRA and FCA controls to test in your mobile app

A practical list for security, resilience and technology risk teams, based on the operational resilience rules, the outsourcing rules and the payment and data rules.

Important business services
Check whether the mobile app and its APIs sit on an important business service, and that their testing is in scope of your impact tolerance work.
Remediation deadlines
Rate findings, set deadlines by severity, and keep retest evidence that proves each fix landed.
Before and after release
Run automated SAST, DAST and SCA on every build, and scan each store release, not only the version you tested last quarter.
Components and SBOM
Keep a versioned list of the SDKs and native libraries in each release, and check it against known vulnerabilities.
Strong customer authentication
Verify that login, payments and sensitive changes require SCA on the server, that remote payments dynamically link amount and payee, and that fallback methods are tracked.
Secrets in the app
Check the app package for API keys, tokens and credentials, and rotate any that work.
Data on the device
Look for tokens and personal data in storage, caches, logs and screenshots, and test the transport protections.
CBEST and incident readiness
Go into CBEST with known app and API issues fixed, and keep scan evidence ready for incident classification and reporting.

A suggested list, not an FCA or PRA template. This is not legal advice.

Platform

The capabilities behind this page

Each one has its own page with the details.

Trusted by banks and fintechs, including

4.8/5 on Gartner Peer Insights SOC 2 Type II audited

Sources

The official texts this page is based on, checked on 27 September 2026.

SS1/21 Operational resilience: Impact tolerances for important business servicesPRA, March 2022 version, published 11 March 2022 and effective from 31 March 2022. First published 29 March 2021 with PS6/21. Impact tolerances, mapping, scenario testing and remediation, with 31 March 2025 as the deadline for firms to be able to remain within their impact tolerances
PS21/3 Building operational resilienceFCA, published 29 March 2021, rules and guidance in force from 31 March 2022. Sets out the operational resilience requirements that sit in the FCA Handbook, including the 31 March 2025 deadline
FCA Handbook SYSC 15A Operational resilienceFCA, last updated 5 April 2024. Important business services, impact tolerances, mapping, scenario testing, lessons learned, records kept for at least six years, and annual review
CBEST Implementation GuideBank of England, 2024 edition. The threat intelligence-led assessment framework used since 2014 by the Bank, PRA and FCA, with CREST-accredited threat intelligence and penetration testing providers, four assessment phases and a supervised remediation plan
SS2/21 Outsourcing and third party risk managementPRA, November 2024 version, published 15 November 2024 and effective from 31 December 2024. Chapters 7 (data security), 8 (access, audit and information rights) and 10 (business continuity and exit plans). A March 2026 update, following PS7/26, applies from 18 March 2027
Critical Third Parties: Strengthening UK Financial ServicesFCA, with the PRA and the Bank of England. Final rules published 12 November 2024 (PRA PS16/24, FCA PS24/16), regime in force from 1 January 2025. First designations came into force on 13 July 2026 for Amazon Web Services EMEA SARL, Google Cloud EMEA Limited, Microsoft Ireland Operations Limited and Oracle Corporation UK Limited
The Payment Services Regulations 2017UK Statutory Instrument 2017 No. 752, regulations 98 to 100. Management of operational and security risks, incident reporting and strong customer authentication, with the related technical standards as onshored
A guide to data securityICO guidance on the UK GDPR security principle and Article 32, including the requirement for a process of regularly testing, assessing and evaluating the effectiveness of security measures, and vulnerability scanning and penetration testing as techniques

FAQ

Frequently asked questions

Straight answers on coverage, setup, and how results reach your team.

Can't find your answer? Book a demo or contact us.

Yes. The requirements sit in the FCA Handbook (SYSC 15A) and the PRA Rulebook and came into force on 31 March 2022, with PRA SS1/21 and FCA PS21/3 setting out the expectations behind them. The 31 March 2025 deadline was the date by which firms in scope had to have performed mapping and testing so that they could remain within impact tolerances for each important business service, and to have made the necessary investments. It is not a one-off exercise: firms are expected to keep their mapping and testing under review, at least annually or after a material change, and to remediate vulnerabilities in time.
Not by name. The operational resilience rules are about services, not channels: where mobile banking delivers an important business service, the app and its APIs are in scope of mapping, testing and remediation. The payment rules are more direct. Strong customer authentication applies to online account access, electronic payment transactions and other remote actions that carry a risk of payment fraud, wherever the customer performs them.
On 18 March 2026 the FCA published PS26/2, its final rules and guidance on operational incident and third party reporting, developed with the PRA and the Bank of England. They introduce a single definition of an operational incident, reporting thresholds, a standardised reporting process with standard or enhanced reports, and new duties to notify material third party arrangements and keep a register. The rules apply from 18 March 2027. Separately, regulation 99 of the Payment Services Regulations 2017 already requires payment service providers to notify the FCA of major operational or security incidents without undue delay.

Assess your mobile banking app the way the PRA and FCA describe it

Start with a free scan of your app from the store, or book a demo to run logged-in tests of your app and APIs with our team.

Scan your own app Book a demo

PRA and FCA operational resilience: test your mobile banking app before and after every release.

The PRA and FCA texts behind your mobile channel

Final operational resilience rules

Rules come into force

Impact tolerance deadline

Critical third parties

Cyber response and recovery practices

Incident reporting rules

Frontier AI statement

First CTP designations

The PRA and FCA rules, applied to your mobile app

Identify important business services and set impact tolerances

What the text says

What it means for your mobile app

How Ostorlab helps

What stays with you

Map the resources and remediate vulnerabilities in time

What the text says

What it means for your mobile app

How Ostorlab helps

What stays with you

Run scenario testing and learn from it

What the text says

What it means for your mobile app

How Ostorlab helps

What stays with you

Prepare for CBEST threat intelligence-led assessments

What the text says

What it means for your mobile app

How Ostorlab helps

What stays with you

Manage outsourcing and third-party risk

What the text says

What it means for your mobile app

How Ostorlab helps

What stays with you

Know the critical third parties behind your services

What the text says

What it means for your mobile app

How Ostorlab helps

What stays with you

Apply strong customer authentication to the app and its payments

What the text says

What it means for your mobile app

How Ostorlab helps

What stays with you

Manage operational and security risks, and report incidents

What the text says

What it means for your mobile app

How Ostorlab helps

What stays with you

Protect personal data and test your security measures

What the text says

What it means for your mobile app

How Ostorlab helps

What stays with you

Watch for and patch vulnerabilities faster

What the text says

What it means for your mobile app

How Ostorlab helps

What stays with you

PRA and FCA rules, control by control

PRA and FCA controls to test in your mobile app

Important business services

Remediation deadlines

Before and after release

Components and SBOM

Strong customer authentication

Secrets in the app

Data on the device

CBEST and incident readiness

The capabilities behind this page

Sources

Frequently asked questions

01Are the PRA and FCA operational resilience rules binding, and what did the 31 March 2025 deadline mean?

02Can Ostorlab run our CBEST assessment?

03Do the UK rules mention mobile apps?

04What changed for incident reporting in 2026?

05Does Ostorlab cover the outsourcing and third-party rules?

06Does Ostorlab make our app meet the PRA and FCA requirements?