A red team engagement starts long before the operators touch anything. It starts with reconnaissance, and the first week of that reconnaissance is usually spent building a picture of your organisation that you should already have. The NCSC adversary simulation guidance published alongside the Cyber Adversary Simulation (CyAS) scheme sets out what an assured engagement looks like, but it does not do the preparation for you. That part is yours, and the quality of it decides whether you buy a genuine test of your detection capability or an expensive rediscovery of your own shadow IT.

This is a readiness guide, written from the attacker reconnaissance side. What you need accurate on day one, what to scope, and what to keep watching in the eleven months after the report lands.

What the NCSC adversary simulation guidance actually says, and what it leaves to you

The NCSC's material on adversary simulation covers three things: introductory guidance explaining what threat-led adversary simulation is and when it is appropriate, the CyAS Standard that sets the technical and delivery bar, and a Working Practices Document placing obligations on assured member companies. Details of assurance schemes change, so check the NCSC website for the current version before you write any of it into a procurement document.

The important point for buyers is what the guidance assumes about you.

The guidance is aimed at organisations with defences worth testing

Adversary simulation measures whether your people, processes and detection tooling notice and respond to a capable attacker pursuing a specific objective. If you have no SOC, no logging on your identity provider, and a patch backlog measured in quarters, the exercise will simply confirm what you already suspect, at a day rate. Spend that budget on the basics first. This is the maturity test nobody applies honestly enough.

Three things the NCSC does not supply

Defining your critical business functions is your job. So is producing accurate asset data. So is owning remediation afterwards, which is where most of the value either lands or evaporates. An assured provider brings tradecraft, threat intelligence capability and a controlled delivery process. It does not bring an inventory of your internet-facing estate, and it certainly does not know which of your business processes would genuinely hurt if it stopped for a day.

Where CyAS sits alongside CBEST, TIBER-EU and CHECK

Financial services firms regulated by the Bank of England will already know CBEST, and TIBER-EU applies the same threat-led model across Europe. CHECK and CREST remain the right framework for conventional penetration testing of a defined system or application. These are not competing options, they are different instruments. A CHECK test tells you whether a system is vulnerable. A threat-led simulation tells you whether your organisation notices someone exploiting it.

Adversary simulation versus penetration testing: choosing the right engagement

The distinction matters because procurement teams frequently buy the wrong one.

A penetration test is breadth-first. Defined scope, defined window, an inventory of vulnerabilities ranked by severity, and usually a friendly relationship with the defenders. An adversary simulation is goal-oriented. The operators emulate the tradecraft of a threat actor plausibly interested in your sector, working towards a named objective such as reaching the payment run, the patient record system or the operational technology network, while actively avoiding detection.

Only one of those exercises your SOC. That is the honest reason to buy a simulation: you want to know whether an alert fires, whether a human acts on it, and how long containment takes.

Simulations cost more, run longer (typically weeks rather than days), and carry more operational risk. If your detection coverage is untested and you suspect the answer is poor, purple teaming is usually better value this year. You run known techniques collaboratively with the defenders watching, fix the gaps in real time, and save the covert exercise for when you expect to pass. Adversarial exposure validation tooling can fill the gap between formal engagements on the more repeatable techniques.

Threat intelligence: the input that decides whether the simulation is realistic

Threat-led means led by intelligence about you, not by a threat actor name pulled from a sector report. A targeting report should describe what an attacker researching your organisation this month would actually find and use.

What makes a targeting report specific

Current evidence, tied to your domains and your people. Leaked credentials and stealer log entries referencing your corporate email domains and SSO portals. Ransomware leak site activity affecting your sector and your suppliers. Hacker and ransomware Telegram channel chatter naming your brand, your managed service provider or a recently acquired subsidiary. Open source detail on named executives that supports a plausible pretext.

Automated feeds miss a great deal of this. Dark web and Telegram monitoring that includes human analyst review picks up the conversation that never becomes a structured indicator: someone offering access to an organisation described by sector and turnover rather than by name, or a broker advertising a VPN appliance at an address range that happens to be yours. Our guide to triaging leaked credentials found on the dark web covers how to work out which of those exposures are live risk rather than historic noise.

Sector and geography shape the emulation

A UK water utility should expect emulation of actors interested in operational technology and remote engineering access. A building society should expect fraud-motivated intrusion aimed at payment systems and customer data, plus the regulatory overlay that comes with it. A legal firm should expect credential theft, mailbox access and data extortion, with partners and their personal accounts as the initial target. If your provider's proposed scenario would read identically for all three, ask for a better one.

Getting your external attack surface accurate before the red team arrives

Here is the mistake that costs the most money: scoping from an internal CMDB rather than from an external discovery sweep.

Internal inventories record what you deployed deliberately. Attackers enter through what you deployed and forgot. A decommissioned marketing subdomain still resolving to a live host. A development environment running on a cloud account opened by an agency you no longer use. Infrastructure inherited in an acquisition that never made it into your asset register because the integration project was descoped.

Take a realistic example. An organisation hands over 240 in-scope IP addresses and 18 domains. External discovery then finds a legacy subdomain pointing at an unpatched file transfer appliance, plus a staging environment on a cloud account opened years ago by a former marketing agency. Both are outside the signed scope until the rules of engagement are amended, which means either a contract variation mid-engagement or a red team politely stepping around your most likely entry point.

The discovery work to do first

• Full subdomain and DNS mapping, including wildcard records, dangling CNAMEs and anything pointing at cloud storage you no longer own.
• Cloud and third-party hosted assets, including SaaS tenants and anything on a departmental credit card.
• Lookalike and typosquatted domains registered against your brand.
• Geographically distributed infrastructure, particularly assets from acquisitions or overseas offices.

Continuous external asset discovery and mapping from the attacker perspective is what makes this list trustworthy, because it sees what can actually be reached from the internet rather than what someone recorded in a spreadsheet in 2022.

Deduplicate known vulnerabilities before you pay for them again

If a finding is already on a ticket with an owner and a date, say so in the scoping document. You are not buying a vulnerability list. Being billed for CVEs your own scanning found last month is avoidable waste.

Supplier boundaries and executive exposure

Initial access in real incidents increasingly arrives through a supplier or managed service, yet most simulation scopes stop at your own perimeter for contractual reasons. Decide deliberately: is the supply chain path emulated with written third-party authorisation, simulated through an assumed-breach starting point, or excluded entirely? Record the decision so the board understands what the exercise did not test. The supplier blind spots exposed by the Glasgow Council incident are a useful reference point for that conversation.

Executive exposure deserves the same treatment, and it is usually reviewed only after the report lands. Too late. Run your own open source reconnaissance on leadership profiles, personal email reuse, home addresses in company filings and social media detail first. Fix the trivially exploitable items yourself, then pay the red team to test the hard ones. Our note on who to cover in VIP monitoring and the mistakes that leave executives exposed sets out where to start.

Scoping, rules of engagement and the authorisation trail

Objectives should be written in business language, not technical language. "Reach domain admin"is a weak objective. "Initiate a change to bank details on the supplier payment run"or "access the SCADA network from the corporate domain"tells the board something meaningful.

The authorisation trail needs to name:

• The white cell: the small group who know the exercise is running and can confirm activity is authorised.
• The control group: who must not know, and how you will handle it if a defender escalates to law enforcement or a regulator in good faith.
• Stop conditions: agreed triggers to pause, who can call them, and the out-of-hours contact route.
• Evidence handling: what happens to sensitive data the team recovers, how it is stored, and when it is destroyed.
• Third-party permissions: written authorisation from hosting providers and managed service partners before work starts, not during.

Legal sign-off on the authorisation letter is not administrative theatre. It is the document that protects the operators and you.

Turning findings into change

Measure timing, not vulnerability counts

The headline output should be detection and escalation timing per attack phase: time to first alert, time to human triage, time to escalation, time to containment, recorded against reconnaissance, initial access, lateral movement and actions on objectives.

Consider a typical pattern. Reconnaissance runs for eleven days unnoticed. Initial access using a valid credential harvested from a stealer log triggers nothing. The first SOC ticket appears at lateral movement on day nineteen. The finding there is not a missing tool. The finding is that impossible-travel alerts had been tuned out months earlier because of false positives. That is a process failure, and no amount of new licensing fixes it.

Route findings properly

Separate one-off fixes from control failures that will recur. A single unpatched appliance is a ticket. A patching process that misses anything not in the CMDB is a control failure, and it will produce the same finding next year unless the process changes. Push both into Jira or ServiceNow with named owners rather than leaving them in a PDF.

Between engagements

An annual exercise gives you a point-in-time result against a footprint that changes weekly. New subdomains appear. Credentials get published. Lookalike domains get registered ahead of a campaign. Ongoing OSINT and dark web monitoring, combined with continuous external asset monitoring, is what keeps next year's scope accurate and stops the same finding coming back.

Set a weekly "what changed"cadence for the security team and a quarterly summary for the board in plain business terms. Both ISO 27001 Annex A controls on technical vulnerability management and supplier relationships, and cyber insurance renewal questionnaires, increasingly ask for evidence of testing and of remediation follow-through. A single report with no re-test evidence answers neither.

Frequently Asked Questions

What is the NCSC Cyber Adversary Simulation (CyAS) scheme?

CyAS is the NCSC's assurance scheme for threat-led adversary simulation, supported by a CyAS Standard and a Working Practices Document that set obligations on assured member companies. It gives buyers a consistent quality bar for goal-oriented red team engagements. Scheme details evolve, so confirm the current documentation on the NCSC website before you reference it in procurement.

How does adversary simulation differ from penetration testing?

Penetration testing enumerates vulnerabilities across a defined scope within a short window. Adversary simulation emulates a specific threat actor pursuing a named business objective over weeks, covertly, to test whether your people and detection tooling respond. One produces a findings list, the other produces detection and response timings.

Does my organisation need to be CyAS assured to run a red team exercise?

No. Assurance applies to providers, not to buying organisations. You may choose an assured provider for confidence in delivery quality, or because a regulator or a framework such as CBEST expects it, but an unassured engagement is not prohibited.

What should we have in place before commissioning an adversary simulation?

An externally verified asset inventory rather than a CMDB extract, a current view of leaked credentials tied to your domains, a supplier map with written authorisation where the supply chain is in scope, a reviewed picture of executive open source exposure, and functioning logging and detection worth testing. Without those, the first week of the engagement goes on rediscovering your own estate.

How often should adversary simulation be repeated, and what happens in between?

Annually is common for regulated organisations, or after significant change such as an acquisition or a major platform migration. Between exercises, run continuous external monitoring for new exposures, newly published credentials and freshly registered lookalike domains, and re-test remediated findings so you can evidence improvement to regulators, insurers and auditors.

The NCSC adversary simulation guidance raises the standard for how these engagements are delivered. What it cannot do is make your inputs accurate. If you want the operators spending their time on tradecraft rather than on mapping an estate you should already know, start with continuous external attack surface visibility and bring that picture to the scoping call.