STAR-FS and DORA TLPT: Threat-Led Testing for Firms in Both Regimes

ByOfficer

A UK banking group with an EU financial entity identified by its competent authority for DORA threat-led penetration testing may be subject to STAR-FS in the UK and DORA TLPT in the EU at the same time. The Bank of England, the Prudential Regulation Authority and the Financial Conduct Authority maintain STAR-FS, the Simulated Targeted Attack and Response framework for the finance sector, published in its current form in March 2024 and operated alongside CREST. Since 17 January 2025, DORA (Regulation (EU) 2022/2554) has required certain EU financial entities to run threat-led penetration testing under Article 26. The two frameworks share a red-team lineage and look interchangeable on a slide. Treat one test as evidence for the other, though, and the gap surfaces during a supervisory conversation instead of before it.

STAR-FS is a firm-led framework. A firm or financial market infrastructure can initiate and run the assessment itself, using accredited threat intelligence and penetration testing providers, and can have the result recognised as a supervisory assessment where the regulator is notified and given the chance to input to scope. DORA threat-led penetration testing works from the other direction: the competent authority identifies which entities must test, and it validates the scope before execution. For a group caught by both, the practical question is how to run two obligations from one testing capability without assuming that a pass on one side clears the other.

Related reading: DORA TLPT: What Designated Entities Must Prepare

The calendar and cadence that drive both regimes

STAR-FS runs as a phased assessment with published indicative timings, and the timing of the next test is a matter for the firm and its supervisor, not a single statutory deadline like a reporting return. DORA, by contrast, fixes a minimum cadence in law. The dates below are the ones worth pinning to a wall before either programme starts.

  • STAR-FS current guidance suite: published March 2024 by the Bank of England, the PRA and the FCA with CREST.
  • STAR-FS assessment length: the four phases together run across roughly 18 to 24 weeks, based on the indicative phase timings in the Implementation Guide.
  • DORA application date: 17 January 2025, under Article 64 of Regulation (EU) 2022/2554.
  • DORA TLPT frequency: at least every three years for identified entities, adjustable up or down by the competent authority on a risk basis, under Article 26(1).
  • TLPT technical standard: Commission Delegated Regulation (EU) 2025/1190 of 13 February 2025, published in the Official Journal on 18 June 2025 and in force twenty days later.
  • Active red team phase under the TLPT standard: at least 12 weeks, under Article 11(5) of that Delegated Regulation.

What STAR-FS is, and what it borrows from CBEST

STAR-FS promotes an intelligence-led penetration testing approach that mimics the actions of cyber threat actors intent on compromising an organisation’s Important Business Services and the technology and people that support them. The framework was designed to replicate the rigour of CBEST, the Bank of England’s intelligence-led testing scheme that has been in use for systemically important institutions since 2014, and to extend that discipline to a wider set of firms that are not systemic. The design difference is who holds the reins. CBEST is regulator-led for the largest institutions. STAR-FS lets a firm manage the test itself while still producing formal reports that can be used as regulatory evidence of technical cyber resilience.

That firm-led design is the point most teams misread. STAR-FS sits in the supervisory toolkit as a framework that firms and FMIs are encouraged to use as part of their testing and assurance strategy, with no mandatory filing date attached. A firm can self-initiate a STAR-FS assessment for its own cyber programme. The guidance is explicit that a self-initiated test can be recognised as a supervisory assessment only where the regulator is notified, is given the opportunity to input to the scope, and receives the remediation plan at the end. Skip the notification and the input, and the firm has run a useful internal exercise with no supervisory standing.

The regulator, for STAR-FS purposes, means the Bank of England, the PRA and the FCA. The scheme is operated with CREST, which accredits the providers and certifies the individuals who lead each phase. That accreditation layer is what lets a firm run the test itself without the regulator losing confidence in the result.

Who sits in the control group and who runs the attack

A STAR-FS assessment begins with the firm establishing a control group. This is a small number of senior people, usually one for each system in scope, positioned at the top of the security incident escalation chain. They know the test is happening. Almost nobody else in the firm does, because the assessment is meant to test defences as they behave on a normal day, which means the blue team and the wider security operations centre are kept unaware. The control group typically draws on roles such as the COO, CIO, CTO and CISO alongside relevant subject matter experts, and the firm may ask its members to sign non-disclosure agreements. A Senior Accountable Executive signs off the scope and carries accountability for the assessment.

The testing itself is delivered by two CREST-accredited suppliers: a Threat Intelligence Service Provider and a Penetration Testing Service Provider. The individuals leading the work hold CREST certifications such as the Certified Threat Intelligence Manager, the Certified Simulated Attack Manager and the Certified Simulated Attack Specialist. The register of approved providers sits on the CREST website. One integrity safeguard is easy to miss and worth stating to any team scoping its first assessment: the providers are obliged to report to CREST if they suspect the process has been manipulated to produce a more favourable result, whether by scoping out vulnerable systems, tipping off system owners, or pressuring a provider to soften findings.

Where a critical third party operates a system that underpins an in-scope service, that provider may need to join the control group so the assessment can reach the system safely. The control group members run the test; they sit outside its scope and are never targets of it.

The four phases and what the regulator receives

STAR-FS runs through four phases, each with its own deliverables. The firm leads the assessment, but where regulatory involvement has been agreed the regulator may input to scope, receives relevant immediate notifications and the Regulator Summary, and may request full STAR-FS reports as part of its continuous assessment.

Initiation, roughly four to six weeks

Planning, scoping and procurement. The control group is established, the firm drafts its STAR-FS Scope Specification and a Project Initiation Document, and it procures the accredited providers. The assessment cannot move past procurement until the firm has legal contracts in place with the providers, including the STAR-FS standard contractual clauses.

Threat Intelligence, roughly six to eight weeks

The Threat Intelligence Service Provider takes direction from the firm, gathers intelligence, and produces a Threat Intelligence Report and a Targeting Report. There must be a minimum of two scenarios, and the scenarios must cover all the Important Business Services identified in scoping, proportionate to their number. This phase ends with a formal handover to the penetration testing team. The intelligence is deliberately a grey-box approach: the testers work from real information about the firm, in contrast to a black-box test that starts from nothing.

Penetration Testing, roughly four to six weeks

The Penetration Testing Service Provider turns the scenarios into a Penetration Test Plan and a PT Risk Management Plan, executes the test against live production systems, and produces the Penetration Test Report. An optional detection and response assessment and SOC accreditation can be added here to test how well the firm spotted and reacted to the attack.

Closure, roughly four weeks

The firm builds a Remediation Plan and completes the STAR-FS Regulator Summary. That summary is the artifact the supervisor actually receives, and it is submitted through the firm’s supervisory team. It pulls together executive summaries of the scoping document, the threat intelligence report and the penetration test report, plus the remediation plan. Tracking of remediation against that plan then becomes a supervisory matter.

Scope is built on Important Business Services, not the network boundary

The single most common scoping error in STAR-FS is treating the scope as the boundary of the network the testers may operate within. The scope means something narrower: the critical systems the testers should aim to reach, each of which underpins a defined Important Business Service. An Important Business Service, in line with the UK operational resilience policy the STAR-FS guidance points to (PS6/21 on impact tolerances for important business services), is a service provided by a firm or FMI to another person which, if disrupted, could pose a risk to the stability of the UK financial system, the firm’s safety and soundness, an appropriate degree of protection for policyholders, or the orderly functioning of markets, or could cause intolerable harm to clients.

From those services, the control group identifies the critical systems that support them, then defines compromise actions for each system. Compromise actions map to the three information assurance objectives, confidentiality, integrity and availability, and become the flags the testers try to capture. If the firm needs to restrict where the testers may operate, that restriction is raised separately during penetration test planning, not baked into the scope. Confusing the two produces a test that either overreaches or quietly excludes the systems that matter most.

This is where the UK framework and the EU regime start to pull apart. STAR-FS anchors scope to Important Business Services. DORA anchors scope to critical or important functions, a related but distinct concept defined in the Regulation. The two often overlap in a real firm, but they are drawn from different rulebooks, and a scope validated for one is not automatically the right scope for the other.

Where STAR-FS meets DORA TLPT

DORA Article 26 requires financial entities identified by their competent authority, other than microenterprises and entities on the simplified ICT risk-management framework, to carry out advanced testing by means of threat-led penetration testing at least every three years. Each test must cover several or all of the entity’s critical or important functions and be performed on live production systems. The firm assesses which functions to include, but the competent authority validates that scope before the test proceeds. This is the structural break from STAR-FS: the firm does not finalise its own DORA scope.

The tester rules under DORA are prescriptive. Article 26(8) requires that where a financial entity uses internal testers, it must contract external testers for every third test. The TLPT technical standard, Commission Delegated Regulation (EU) 2025/1190, tightens this further: threat intelligence must always come from an external provider, and significant credit institutions must always use external testers. That standard also sets a binding floor for the active red team testing phase of at least 12 weeks, which removes the ambiguity that firms sometimes read into a purely framework-based test. For the broader design of the DORA regime and how it scales, our guide to DORA resilience testing for smaller firms walks through the proportionality routes for entities below the TLPT threshold.

Reporting also diverges. Under DORA Article 26(6), at the end of the test and once reports and remediation plans are agreed, the entity and, where relevant, the external testers provide the designated TLPT authority with a summary of findings, the remediation plans, and documentation evidencing that the test met the requirements. Article 26(7) then has the authority issue an attestation confirming the test was performed correctly, which supports mutual recognition of threat-led tests between EU competent authorities. STAR-FS has its own reporting endpoint in the Regulator Summary, but there is no equivalent cross-border attestation reaching into the EU regime. The table below sets the two side by side.

Dimension STAR-FS (UK) DORA TLPT (EU)
Legal status Framework in the supervisory toolkit; firm-led and encouraged, not a standalone statutory testing mandate Statutory obligation under Article 26 of Regulation (EU) 2022/2554, with binding standard CDR (EU) 2025/1190
Who sets scope Firm drafts and its Senior Accountable Executive signs off; regulator may input where notified Firm assesses functions, but the competent authority validates the scope before execution
Frequency No fixed cadence in the framework; firm and supervisor driven At least every three years, adjustable by the competent authority
Scope anchor Important Business Services Critical or important functions
Testers CREST-accredited TI and PT providers; CREST-certified leads Testers meeting Article 27; external threat intelligence always; external testers every third test; significant credit institutions always external
Lineage Modelled on CBEST (2014) Built on the TIBER-EU approach
Minimum red team phase Not fixed in the framework At least 12 weeks (CDR (EU) 2025/1190, Article 11(5))
Regulator output STAR-FS Regulator Summary via the supervisory team Summary of findings, remediation plan and documentation to the TLPT authority; attestation for mutual recognition

What a STAR-FS pass does not do for your DORA obligation

A completed STAR-FS assessment is evidence of technical cyber resilience to the UK regulator. It does not discharge the DORA Article 26 obligation. The mutual recognition built into DORA runs between EU competent authorities through the Article 26(7) attestation. A UK supervisory framework sits outside that mechanism, so a STAR-FS Regulator Summary is not a DORA attestation and cannot be presented as one. The reverse also holds: a DORA test scoped to critical or important functions and validated by an EU competent authority is not a STAR-FS assessment recognised by the Bank of England, the PRA or the FCA.

The overlap is operational, and that is where the value sits. Both regimes use intelligence-led, grey-box red teaming against live production systems. Both keep the blue team unaware. Both separate a threat intelligence stage from an execution stage and both end in a remediation plan. A group can therefore run one testing capability, one panel of accredited providers, and one internal control discipline across both. What it cannot do is bank the compliance credit twice. Two supervisors, two scopes, two reporting endpoints.

There is a terminology trap here as well. In the UK, a dual-regulated firm means a firm regulated by both the PRA and the FCA, such as a bank or a large investment firm. That is a different idea from being caught by both the UK and EU testing regimes. A firm can be dual-regulated in the UK sense and have no DORA exposure at all, and an EU entity subject to DORA TLPT is not thereby a UK dual-regulated firm. When a group maps its testing obligations, it should confirm which legal perimeter each entity actually sits in before it assumes an overlap.

Running both without paying for the same test twice

The practical work is a mapping exercise done before either test is scoped. Start by laying the firm’s Important Business Services next to its DORA critical or important functions and marking where the underlying systems are the same. Those shared systems are the natural core of a combined testing programme. Where the two lists diverge, each divergence is a candidate for a regime-specific add-on rather than a reason to run two entirely separate engagements.

Provider selection is the next lever. STAR-FS accreditation does not by itself establish compliance with DORA Article 27 and Article 7(1) of Commission Delegated Regulation (EU) 2025/1190. Before contracting, the control team must assess the proposed providers and give the test managers evidence of compliance; it must not proceed where the TLPT authority considers the proposed threat intelligence provider or external testers non-compliant. The external-tester rotation rule is imposed by DORA Article 26(8), rather than by the Delegated Regulation. Cadence planning follows: the DORA three-year floor is the harder constraint, so a group can anchor its combined calendar to the DORA cycle and slot STAR-FS activity around it, provided the UK supervisor is content with the timing.

Two elements stay separate. The scope validation step under DORA belongs to the competent authority, so a group cannot self-certify its DORA scope the way a purely firm-led STAR-FS test allows. And the reporting artifacts stay separate: the STAR-FS Regulator Summary goes to the UK supervisory team, while the DORA summary of findings, remediation plan and documentation go to the designated TLPT authority. Teams that also run the surrounding DORA obligations should keep this testing work aligned with their DORA ICT incident reporting and their DORA register of information, since the third parties inside a TLPT scope are the same ones tracked there.

Frequently Asked Questions

Is a STAR-FS assessment mandatory for UK financial firms?

The framework is firm-led and encouraged rather than a mandatory return with a filing deadline. Firms and FMIs can self-initiate it, and a self-initiated test gains supervisory standing where the regulator is notified, inputs to scope, and receives the remediation plan. For the largest, systemically important institutions, the Bank of England runs the related CBEST scheme on a regulator-led basis instead.

Does completing STAR-FS satisfy the DORA Article 26 requirement?

No. The two are separate legal regimes. DORA mutual recognition operates between EU competent authorities through the Article 26(7) attestation, and a UK supervisory framework sits outside that mechanism. A STAR-FS Regulator Summary is not a DORA attestation, and a DORA test is not a STAR-FS assessment recognised by the UK authorities.

Can we use the same testers for STAR-FS and DORA TLPT?

Possibly, but STAR-FS accreditation alone does not establish DORA compliance. The proposed providers must satisfy DORA Article 27 and Article 7(1) of Commission Delegated Regulation (EU) 2025/1190, and the control team must give the test managers evidence of compliance before contracting. Under DORA Article 26(8), external testers are required for every third test, and significant credit institutions must always use external testers. A provider panel can serve both regimes only where that compliance assessment is completed and documented.

How often do we have to run each test?

STAR-FS sets no fixed cadence in the framework; timing is driven by the firm and its supervisor. DORA requires TLPT at least every three years for identified entities, and the competent authority can require a higher or lower frequency based on the entity’s risk profile.

What does each regulator actually receive?

Under STAR-FS, the supervisory team receives the STAR-FS Regulator Summary, which consolidates the scoping, threat intelligence and penetration test summaries with the remediation plan. Under DORA Article 26(6), the designated TLPT authority receives a summary of findings, the remediation plans, and documentation evidencing the test met the requirements, followed by an Article 26(7) attestation.

Are ICT third-party providers inside the scope of these tests?

They can be. In STAR-FS, a critical third party operating an in-scope system may need to join the control group so the system can be reached safely. Under DORA Article 26(3), ICT third-party providers can be brought into scope while the financial entity retains full responsibility for compliance, and Article 26(4) allows pooled testing where several entities share a provider.

What is the difference between Important Business Services and critical or important functions?

Important Business Services is a UK operational resilience concept tied to the impact of disruption on financial stability, safety and soundness, policyholders, market functioning or clients. Critical or important functions is the DORA concept that anchors TLPT scope. They frequently overlap in a real firm, but they come from different rulebooks, so a scope validated for one is not automatically correct for the other.

Related Articles

Key Takeaways

  • STAR-FS is the Bank of England, PRA and FCA framework operated with CREST, current guidance dated March 2024, modelled on CBEST and extended to a broader set of firms. Firm-led and self-initiable, it operates without a fixed filing deadline.
  • The assessment runs through four phases, Initiation, Threat Intelligence, Penetration Testing and Closure, across roughly 18 to 24 weeks, ending in a Regulator Summary submitted through the supervisory team.
  • Scope is built on the Important Business Services and their supporting critical systems that the testers must reach, a narrower target than the whole network estate.
  • DORA Article 26 mandates threat-led penetration testing at least every three years for identified entities, on live production systems, with scope validated by the competent authority.
  • The DORA standard, Commission Delegated Regulation (EU) 2025/1190, sets a minimum 12-week active red team phase, requires external threat intelligence, and requires significant credit institutions to use external testers.
  • STAR-FS and DORA TLPT do not cross-recognise. A UK assessment does not discharge the DORA obligation, and a DORA test is not a UK supervisory assessment.
  • The shared red-team lineage means a group can run one testing capability and one provider panel across both regimes, but it cannot claim the compliance credit twice.

Sources and References

  • Bank of England, PRA and FCA with CREST, STAR-FS UK Implementation Guide (March 2024): bankofengland.co.uk
  • Bank of England, STAR-FS Penetration Test Report Specification (March 2024): bankofengland.co.uk
  • Regulation (EU) 2022/2554 (DORA), Chapter IV, Articles 24 to 27 and Article 64: eur-lex.europa.eu
  • Commission Delegated Regulation (EU) 2025/1190 of 13 February 2025 (TLPT regulatory technical standard): eur-lex.europa.eu

Treating STAR-FS and DORA TLPT as two obligations from one capability

A cross-border group needs one testing capability to satisfy both rulebooks: one team, one provider panel, one internal control discipline. The compliance outputs, by contrast, stay separate. Map Important Business Services against critical or important functions first, confirm the DORA tester conditions before assuming a single panel covers both, anchor the calendar to the harder three-year DORA floor, and keep the two reporting endpoints distinct. The frameworks were built from the same idea of realistic, intelligence-led attack simulation, which is exactly why they can share so much operationally and still stand apart in law.

Last updated: July 2026

Disclaimer: The information on RegReportingDesk.com is for educational and informational purposes only. It does not constitute legal, regulatory, tax, or compliance advice. Always consult your compliance officer, legal counsel, or the relevant supervisory authority for guidance specific to your institution.

Similar Posts