CBEST
intelligence-led penetration testing for UK financial services
CBEST is the Bank of England framework for intelligence-led penetration testing of UK financial entities, run jointly with the Prudential Regulation Authority and the Financial Conduct Authority. The framework uses bespoke threat intelligence and accredited red team providers to test the resilience of systems supporting important business services, then walks the attack path with the defenders during the replay phase. Run a defensible CBEST engagement from scope through joint debrief and closure on a single record, with the white team, control group, threat intelligence provider, and red team provider tracked as one workflow rather than a folder of PDFs.
No credit card required. Free plan available forever.
CBEST in context: the UK regulator-led framework for intelligence-led red teaming
CBEST is the Bank of England framework for intelligence-led penetration testing of UK financial entities, run jointly with the Prudential Regulation Authority and the Financial Conduct Authority. The framework was first introduced in 2014 and refreshed several times since to align with modern threat intelligence practice and operational resilience expectations. CBEST is the regulator-led testing programme: the supervisor sets the inclusion list, agrees the scope, and reviews the closure attestation. The accredited provider community, the rules of engagement, and the methodology are documented and applied consistently across firms so the results are comparable to the supervisor.
CBEST sits inside the wider UK and European resilience picture. For UK firms operating across the EU, the same testing discipline is increasingly required under the Digital Operational Resilience Act, whose threat-led penetration testing expectations point to TIBER-EU as the reference methodology. CBEST and TIBER-EU share the structural shape: a bespoke threat assessment, role separation, controlled execution, replay, and a closure attestation. The differences are jurisdictional and procedural rather than philosophical, so groups operating across both pools usually map a single workflow across the schemes rather than running two separate evidence efforts.
Who CBEST applies to and where it sits in the UK supervisory regime
CBEST applies to the population of UK financial entities the regulator considers material enough that an intelligence-led test of their important business services is a reasonable supervisory expectation. The supervisor relationship determines who leads: the PRA leads for prudentially regulated firms, the FCA leads for conduct-regulated firms, and the Bank of England Financial Market Infrastructure directorate leads for the FMI population. The cadence and depth scale with size, complexity, and systemic relevance, and the inclusion list for each cycle is set by the supervisor. Critical third parties supporting the in-scope services may be drawn into the scoping conversation and tested in coordination with the firm.
Banks, building societies, and credit institutions
PRA-regulated banks and building societies whose failure or material disruption would affect the stability of the UK financial system or important markets. CBEST coverage scales with size, the systemic relevance of the firm, and the criticality of the important business services the firm runs.
Insurers, payment systems, and FMIs
Solvency II insurers and reinsurers, recognised payment systems, and financial market infrastructures including central counterparties and central securities depositories. The Bank of England Financial Market Infrastructure directorate sets the inclusion expectations for the FMI population and works with the firm white team across the engagement.
Investment firms, asset managers, and trading venues
FCA-regulated investment firms, asset managers, and recognised investment exchanges where the disruption profile justifies intelligence-led testing. The FCA leads the supervisor relationship for these entities while CBEST methodology and the control group remain consistent with the rest of the framework.
GBEST and adjacent UK schemes
GBEST is the UK government variant that applies the same intelligence-led methodology to government and critical national infrastructure entities under Cabinet Office and NCSC sponsorship. STAR FS, operated alongside CBEST by CREST, supplies the wider provider accreditation regime that CBEST testing builds on. Many groups operating in both pools reuse a single workflow across the schemes.
The targeted threat assessment: what makes CBEST intelligence led
Every CBEST engagement begins with a targeted threat assessment produced by an accredited threat intelligence provider. The targeted threat report is bespoke to the firm and the in-scope important business services rather than a generic landscape document. It profiles the threat actors plausibly targeting UK financial services, the prevailing tradecraft, and the attack patterns the supervisor expects to see reflected in test scenarios. The report is the document that the red team builds the test plan from, and it remains part of the closure pack the supervisor may review.
- Bespoke to the firm and the in-scope important business services rather than a generic threat landscape
- Profiles the threat actors realistically targeting UK financial services, including state-aligned groups, organised crime, hacktivists, and insider threat scenarios where relevant to the service
- Describes prevailing tradecraft, common initial access vectors, persistence mechanisms, lateral movement patterns, and exfiltration techniques for the named actors
- Drives scenario design and the test plan, so each red team scenario can be traced back to a documented threat actor and a documented motivation
- Forms part of the closure pack, paired with the red team report, the replay record, and the attestation as a single body of evidence
Roles and segregation of duties: white, control, blue, red, and TI
Role separation is the structural feature that makes CBEST credible to the supervisor and the board. The framework names five roles, with explicit boundaries between who knows about the test, who runs it, who oversees it, and who defends against it. The audit of who knew what and when is part of the closure record, so the role membership is captured before launch and maintained throughout the engagement.
White team
A small group inside the firm, typically two to five people, that owns the engagement end to end. The white team commissions the providers, holds the rules of engagement, has authority to pause or escalate, and is the only group internally that knows the test is happening. White team membership and authority are documented before launch and retained in the closure pack.
Control group
The supervisors at the Bank of England, the PRA, and the FCA depending on the firm. The control group oversees the engagement, validates that the framework is being followed, and is the route of escalation if the test deviates from the rules of engagement. The control group does not run the test on the firm's behalf.
Blue team
The operational defence: the security operations centre, the incident response function, the IT operations group, and any third parties involved in detection and response for the in-scope services. The blue team is unaware that a CBEST engagement is in progress. The blue team learns about the test only at the replay phase, where the joint debrief happens.
Red team provider
The external red team commissioned by the firm and accredited under the relevant scheme. The red team builds the test plan from the targeted threat assessment, executes the controlled engagement, and produces the test report. The red team is contractually bound by the rules of engagement and reports through the white team only.
Threat intelligence provider
A separate external provider, accredited per the framework expectations, that produces the targeted threat assessment tailored to the firm. The targeted threat report informs the red team scenario design and the attack paths under test, and remains part of the closure evidence pack the supervisor may review.
Phase 1: Preparation
Preparation is the longest phase by elapsed time and the phase that most determines whether the engagement is defensible. The launch document, the procurement of accredited providers, the legal pack, and the rules of engagement all sit in preparation, and the supervisor is engaged early so expectations are baked into the plan rather than discovered later. CBEST engagements that fail review usually fail because preparation was rushed and the launch document had to be backfilled after testing began.
- Engage early with the supervisor (Bank of England, PRA, or FCA depending on the firm) to confirm timelines, the control group contact, and any firm-specific expectations
- Define the engagement scope around important business services, including the systems and third parties supporting them, the geographies, and the rationale for inclusion or exclusion
- Form the white team with explicit board mandate, authority to commission and pause the engagement, a documented contact tree, and clear segregation from the in-scope blue team
- Procure an accredited threat intelligence provider and an accredited red team provider, with credential evidence and conflict-of-interest checks captured on the engagement record
- Agree the legal pack: rules of engagement, authorisation letter, data handling commitments, indemnity, and the closure attestation template
- Hold the launch meeting with the supervisor, the white team, and the providers, and lock the scope specification before testing begins
Phase 2: Testing (targeted threat report and red team execution)
Testing is the phase most readers picture when they hear CBEST. The threat intelligence provider builds the targeted threat assessment from the firm scope and the wider UK threat picture. The red team builds the test plan from the targeted threat report, with scenarios and flags. The white team approves and the controlled red team execution runs against live production. Operator notes, evidence per flag, and timestamps are captured during execution rather than reconstructed afterwards.
- The threat intelligence provider produces a targeted threat assessment tailored to the firm, the in-scope important business services, and the threat actors realistically targeting UK financial services
- The red team builds the test plan from the targeted threat report, with attack scenarios, flags, proposed attack paths, and rules of engagement aligned to the scope
- The white team approves the test plan, the flags, and the rules of engagement, then triggers the controlled red team execution against live production
- The red team executes against live production with controlled access, prearranged escalation paths, and a live communication channel back to the white team and the control group
- Operator notes, screenshots, attack timestamps, and evidence per flag are captured during execution so the post-test record is the working record rather than a rebuilt one
Tagging every red team finding by tactic and technique sharpens the test report and the replay conversation. The MITRE ATT&CK framework page covers tagging end to end, the threat-led penetration testing workflow covers the cycle on a single engagement record, and the red teaming workflow keeps the timeline, attack paths, and operator notes structured rather than scattered across chat history.
Phase 3: Closure (replay, attestation, and lessons learned)
Closure is what separates CBEST from a standalone red team engagement. The replay phase pairs the red team and the blue team, walks the attack path together, identifies the detection and response gaps, and agrees the remediation. The closure attestation, signed by the firm, the red team provider, and the threat intelligence provider, is the formal record that a CBEST engagement was completed. The supervisor may review the attestation and the evidence pack as part of ongoing supervision.
- The red team produces the test report covering scope, methodology, attack paths, observations, and findings against the agreed flags and scenarios
- The replay phase pairs the red team and the blue team, walks the attack path together, identifies the detection and response gaps, and agrees the remediation actions in writing
- The white team consolidates the remediation plan with owners, deadlines, and retest conditions tied to the engagement record rather than to a side spreadsheet
- The firm, the red team provider, and the threat intelligence provider sign the closure attestation, which is provided to the supervisor as part of the post-engagement record
- The closure pack (targeted threat report, test plan, red team report, replay notes, remediation actions, attestation) is retained in full so the next cycle and any supervisor follow-up are addressable from a single record
For the operational side of the remediation work after the attestation, the remediation tracking workflow keeps owners, deadlines, and retest evidence linked to the engagement record so the next supervisor cycle does not turn into a second forensic exercise.
CBEST, STAR FS, and the CREST accreditation regime
CBEST is the supervisor-led programme; the provider accreditation regime that supports it is operated by CREST. STAR FS is the CREST scheme that runs alongside CBEST and accredits threat intelligence providers, red team providers, and the senior individuals who lead intelligence-led engagements. Buyers procuring CBEST testing typically check provider accreditations and individual certifications (CCSAS, CCSAM, CCT-INF, CCT-APP, CRT) against the STAR FS register. The CREST penetration testing framework page covers the wider CREST scheme landscape and the certification ladder.
CBEST vs TIBER-EU vs DORA TLPT vs GBEST and iCAST
CBEST is the UK financial services scheme. TIBER-EU is the European Central Bank framework adopted across the European Union and named as the reference methodology for TLPT under DORA. GBEST is the UK government variant operated by the Cabinet Office and the National Cyber Security Centre. iCAST is the equivalent intelligence-led scheme run by the Hong Kong Monetary Authority. The schemes share the structural ideas: a bespoke threat assessment, accredited providers, a small white team, role separation, controlled execution, replay, and a closure attestation. They differ in jurisdiction, accreditation regime, procedural detail, and the supervisor that signs off the closure pack. Groups that operate across multiple jurisdictions usually run a single underlying workflow and map artefacts to each scheme rather than building parallel evidence pipelines.
For UK firms whose operations also bring in essential service obligations beyond financial supervision, the closure pack often feeds directly into a parallel NCSC Cyber Assessment Framework cycle. CBEST findings against B4 (system security), C1 (security monitoring), and C2 (proactive security event discovery) are exactly the contributing outcomes a CAF assessor expects intelligence-led testing to evidence, so a single body of work can satisfy both the Bank of England supervisor and the CAF reviewer where the firm is in scope of both regimes.
Evidence the supervisor (and your board) actually want
CBEST programmes that struggle on review usually struggle because the artefacts are scattered across drives, secure email threads, and screenshots. Build the closure pack as the work happens, retain raw evidence alongside the structured record, and tie every artefact back to the phase, the role that produced it, and the approver who signed it off. The closure attestation reads the way the underlying record reads.
- Scope specification covering important business services, systems, third parties, geographies, threat actors in scope, and rationale for inclusion or exclusion
- Board approval, white team membership, and the contact tree with authority to escalate and pause
- Procurement records for the threat intelligence provider and the red team provider, including credential evidence and conflict-of-interest checks
- Targeted threat assessment, the red team test plan, and the rules of engagement signed by the white team
- Operator notes and per-flag evidence captured during execution, retained alongside the structured engagement record
- Red team test report, replay notes, gap analysis, and the remediation plan with owners and deadlines
- Closure attestation signed by the firm, the red team provider, and the threat intelligence provider, and retained as the post-engagement record
- Retest evidence and lessons learned feeding back into the wider operational resilience programme
Where SecPortal fits in the CBEST workflow
SecPortal is the operating layer for the CBEST engagement, not a replacement for the supervisor, the threat intelligence provider, or the red team provider. The platform handles scope, role records, findings, replay notes, attestation artefacts, and the closure pack so the work runs as a structured workflow rather than a long encrypted email thread. Compliance tracking maps the CBEST evidence pack to wider obligations under DORA, NIS2, ISO 27001, and the SWIFT Customer Security Programme for groups that have to satisfy more than one regime from the same body of work.
- Engagement management dedicated to a CBEST engagement, with phases (preparation, testing, closure) tracked as workstreams rather than as one PDF stitched together at the end
- Findings management with CVSS 3.1 scoring, MITRE ATT&CK tagging, and 300+ templates so each red team finding ties back to the scenario, the flag, and the technique it evidenced
- AI report generation that turns the test summary, findings, and remediation actions into a structured red team report and a board-ready narrative without manual rewriting
- Attack surface management to map the external footprint of the in-scope important business services before the red team builds the test plan
- Continuous monitoring with scheduled scans so the firm has a coverage record and a baseline of evidence between CBEST cycles
- Compliance tracking that maps the CBEST evidence pack to wider operational resilience expectations under PRA SS1/21, FCA SYSC, and parallel obligations under DORA where the group operates across the EU
A CBEST engagement is a multi-month effort, not a one-week test. The first cycle for a new in-scope firm typically takes between six and twelve months from launch to attestation, with preparation alone running several months. Subsequent cycles run faster because the white team, the providers, and the evidence patterns are reusable. Running the work as a managed workflow pays off most over time: prior targeted threat reports, prior red team findings, and prior remediation timelines stay linked, so each cycle becomes an iteration rather than a rebuild. For consultants delivering CBEST work to multiple firms, the security consultants workspace bundles the platform with branded client portals and AI report generation so the deliverable looks as polished as the work behind it.
For programmes that want continuous detection and trend evidence between CBEST cycles, the continuous monitoring capability and attack surface management capability produce the cadence and coverage record that intelligence-led programmes are expected to keep between formal engagements.
Key control areas
SecPortal helps you track and manage compliance across these domains.
Scope and important business services
CBEST testing is anchored to important business services rather than to a flat list of systems. The scope covers the people, processes, and technology that deliver a service the regulator considers material to the firm or to the wider sector. Capture the service definition, the systems and applications supporting it, the third parties in the path, the geographies in scope, and the rationale for inclusion or exclusion as a structured scope record. The launch document is the artefact that the regulator and the board sign off, and it should remain the authoritative scope reference for the duration of the engagement.
Threat intelligence: the targeted threat report
A CBEST engagement is intelligence led. The accredited threat intelligence provider produces a targeted threat assessment for the firm based on bespoke research, the in-scope important business services, and the threat actors realistically targeting the UK financial sector. The targeted threat report drives scenario design, the red team test plan, and the attack paths under test. Tag every red team finding back to the scenario, the threat actor profile, and the MITRE ATT&CK technique it evidenced so the test report and the attestation align without rework.
Roles: white team, control group, blue team, red team, threat intelligence provider
CBEST relies on disciplined role separation. A small white team inside the firm runs the engagement, holds the rules of engagement, and is the only group internally that knows the test is happening. The control group at the regulator oversees the test across firms. The blue team defends without prior knowledge until the replay. The accredited red team and threat intelligence providers deliver under contract through the white team. Capture membership, contact tree, legal authority, and segregation of duties on the engagement record before launch so the audit of who knew what and when is provable.
Test plan, rules of engagement, and controlled execution
The red team builds the test plan from the targeted threat report, with attack scenarios, flags, expected attack paths, and rules of engagement signed by the white team. Execution runs against live production with controlled access and prearranged escalation paths. Operator notes, screenshots, attack timestamps, and per-flag evidence are captured during execution rather than reconstructed afterwards. The white team retains the authority to pause or escalate, and the contact tree is live throughout the test window.
Replay phase and joint debrief with the defenders
The replay phase is the structural feature that distinguishes CBEST from a standalone red team test. After execution, the red team and the blue team walk the attack path together, identify detection and response gaps, and agree the remediation work in writing. Capture the replay timeline, the gap analysis, and the remediation actions on the same engagement record that holds the red team report so the closure pack reads as a single narrative rather than two competing versions.
Closure: report, remediation plan, and attestation
CBEST closes with a red team test report, a joint remediation plan with owners and deadlines, and a closure attestation that the engagement followed the framework. The attestation, the targeted threat report, the test plan, the operator notes, the replay record, and the remediation actions form the evidence pack that the regulator may review. Retain the raw artefacts inside the engagement record so the closure pack is a click rather than a forensic exercise twelve months later when the next cycle starts or when a supervisor question arrives.
Related features
Run a defensible CBEST engagement without spreadsheet sprawl
Bring scope, threat intelligence, red team execution, replay, and attestation into one workflow. Start free.
No credit card required. Free plan available forever.