The NCSC disruptive attack guidance reads, at first glance, like a plan. It is closer to a set of questions, and the hardest of them are about your own estate: what do you own that is reachable from the internet, who controls it, and could you still list it if every internal system were dark? Most organisations handed the guidance start at the response stage. The gap that bites is earlier than that.
What the NCSC disruptive attack guidance actually covers
The NCSC’s response and recovery guidance for highly disruptive incidents, published on 28 July 2026, deals with the category of attack that stops an organisation operating normally: critical systems or services disrupted, disabled or damaged, with recovery measured in weeks or months rather than hours. That timescale is the point of the document. An incident you can absorb in an afternoon does not need it.
Three stages, three different owners
The guidance is structured in three parts: preparation before anything happens, response during the incident, and longer-term recovery afterwards. In practice these three parts belong to different people. Preparation sits with whoever owns asset records, backups and supplier contracts, which is usually IT and procurement rather than security. Response belongs to whoever can make decisions at speed, including the decision to take a service offline. Recovery drifts back towards the business, because it is about rebuilding in a sensible order and deciding what not to rebuild at all.
Read it with that split in mind, because the preparation work is the only part you can do calmly, and it is the part most frequently skipped.
It is written for organisations without an incident response team
The guidance is aimed squarely at organisations that have no dedicated incident response function: a few IT staff, a managed service provider, perhaps a retained responder they have never called. That shapes how it is written. It assumes you will be buying capability under pressure, and it assumes you can answer basic factual questions about your own environment when the responder asks.
What the guidance deliberately is not: a technical runbook. It will not tell you how to rebuild a domain controller or which forensic image to take first. It sets the sequence and the decisions. The facts it needs as input are yours to supply.
The question the guidance keeps asking that most organisations cannot answer
Preparation assumes a usable asset picture, and specifically an answer to the question of what belongs to you and is reachable from the internet. Internal asset registers answer a different question. They record what the IT team provisioned, licensed and monitors. They are reliable about laptops and servers in a known subnet, and quietly unreliable about everything else.
The usual omissions are mundane. A marketing microsite built by an agency on a hosting account the agency owns. A legacy VPN endpoint left routable after the replacement went in. A test environment on a cloud account opened with a departmental card. A subdomain delegated to a supplier’s platform for a product that was retired in 2022. An acquired company’s infrastructure, still running, still carrying your brand on the certificate.
None of these is exotic. They are the ordinary sediment of an organisation that has existed for a few years and moved quickly. Several were never recorded because nobody involved thought of them as IT at all; someone was buying a campaign, not a server.
During a disruptive incident, unknown internet-facing systems are a double liability. They are a plausible entry route, which matters for the investigation. They are also unmanaged estate you cannot patch, isolate or account for while you are rebuilding, which matters for the recovery. A responder asking “is anything else of yours exposed?”wants a list, not a shrug.
Building an external footprint record that survives the incident
The technique matters more than the tool here. Start from a seed domain and expand outwards: certificate transparency logs for hostnames that were issued a certificate, DNS records for what resolves and where, domain registration data for the names registered alongside the one you remembered. Repeat on what you find. The seed-to-inventory process is unglamorous and it works from the outside, the way an attacker does.
That last detail is the one with real incident value. An asset inventory that exists only inside the systems you have just lost is no inventory at all. If your CMDB is encrypted and your SharePoint is offline, a record you can regenerate from public data is worth more than a dashboard you cannot reach. Keep a current copy out of band: a printed or offline export, held by someone who will be in the room on day one.
Candidates are not assets
Discovery produces candidates. A hostname in a certificate log may belong to a supplier, a former subsidiary, a shared platform serving forty other customers, or to someone who registered a lookalike name. Treating candidates as confirmed assets during an incident burns response hours chasing things you do not own and cannot change.
Ownership confirmation is the actual work: who is the registrar, who controls the DNS zone, whose hosting account pays for it, which named person in the business depends on it. It is tedious. It is also far cheaper done in advance than at hour nineteen of an incident, when the person who knows is unreachable and the agency that built it has been dissolved.
Keep the record thin enough to maintain. Owner, hosting provider, registrar, DNS controller, business purpose and internal dependency earn their place because each one answers a question someone will ask under pressure. Our longer breakdown of the fields worth recording for an internet-facing inventory goes further on what to leave out.
The exposure that matters most while you are mid-recovery
Mass rebuilds are a dangling DNS factory. Cloud resources get torn down and recreated at speed, storage buckets and app services and CDN endpoints come back with new names, and the CNAME records pointing at the old ones stay exactly where they were. Take promo.example.co.uk, left as a CNAME to a decommissioned cloud storage endpoint. An attacker registers that resource name in their own account, the name resolves to their content, and they are now serving pages on your domain. The fix is removal of the DNS record. Nothing is done to a server, because there is no server.
Subdomain takeover risk so peaks in the weeks after recovery, not before the attack. That is counterintuitive enough that it almost never appears on a recovery checklist. If you want the mechanics, the dangling DNS problem is worth reading before you plan a rebuild, not after.
Three other things accumulate during recovery:
- Emergency access routes. A temporary RDP or SSH exposure to get an engineer working. A management interface opened to let a supplier in. These are rarely recorded and almost never removed on the date someone promised.
- Stand-in services. A holding site on an unfamiliar host, a temporary mail relay, a webform on a platform nobody vetted.
- Certificates for short-lived hostnames, issued in a hurry and logged publicly forever. The emergency naming convention you invent at 2am becomes a map of your recovery for anyone reading the logs.
Most of this has no CVE attached to it. An open admin panel with no authentication is not a vulnerability in any catalogue; it is a configuration. A CVE-only view of external risk understates it, which is one reason vulnerability counts make a poor recovery metric.
Triage under pressure: likely affected against definitely affected
Passive external observation tells you what a service presents to the world: a banner, a response header, a fingerprint, a TLS certificate. From that you can infer a version, and from the version you can infer exposure to a known flaw. It is an inference, not a confirmed fact. The system has not been tested; the banner may be stale, the vendor may have backported the fix, the device may be a load balancer answering for something else entirely.
Active vulnerability scanning or an authenticated check closes that gap by proving the condition exists. That distinction changes your decision. “Likely affected”justifies investigating and perhaps restricting access. “Definitely affected”justifies taking an internet-facing remote access appliance offline in the middle of a recovery, which is a decision someone will question afterwards. The difference between likely and definitely is the difference between a defensible call and a guess.
Write the evidence standard down in advance: which category of finding warrants which action, and who signs it off. That removes an argument you do not want to be having at 3am with a tired supplier on a conference bridge.
On sequencing: use passive observation first, because it is fast, needs no change window and does not add load to systems already struggling. Then spend your constrained scanning capacity on the handful of candidates that would actually change a decision. When everything looks urgent, order by reachability from the internet, then whether authentication stands in front of it, then business dependency, then severity. Severity last is deliberate. A critical flaw on something nobody can reach is not your problem this week.
Turning the preparation stage into a standing routine
Preparation is not a document you produce once. The external surface changes without anyone deciding it should: a developer deploys a new service, a DNS record is added for a launch, a certificate expires. Against a surface that moves like that, a quarterly assessment is a snapshot of a river. Change detection is what catches new exposure the day it appears, and it is also what lets you spot the emergency access routes from a rebuild as diffs against a baseline you took before the incident. Without that baseline, you find them months later by accident.
Alert fatigue is the failure mode that undoes continuous monitoring. Decide in advance which changes page a human: a new administrative interface with no authentication in front of it, a DNS record newly resolving to a third-party provider, a certificate issued for a hostname nobody recognises. Everything else groups by asset owner and lands in a weekly review. That is a prioritisation decision, not a tooling one, and no product will make it for you.
Then rehearse the external half. Most recovery exercises stop at the firewall. Ask the awkward questions instead: who holds the registrar credentials, who can edit the DNS zone if the person who normally does it is on leave, who can revoke a certificate at two in the morning, and what happens if your DNS is managed by the agency that also lost its systems. Our external readiness checklist for NCSC patch waves covers the same muscle in a smaller, more frequent form.
External attack surface management sits alongside the other controls, not in place of them. Cyber Essentials and the forthcoming Cyber Security and Resilience Bill handle the compliance floor. Vulnerability management provides proof. The NCSC’s guidance on mitigating malware and ransomware attacks, which the NCSC pointed organisations back towards in May 2025 after the incidents affecting UK retailers, covers the controls that reduce the chance of needing any of this. External discovery covers the assets nobody recorded.
What external discovery does not do
It does not exploit anything. Passive discovery reads public data: certificate logs, DNS, registration records, the responses a service offers to any visitor. Nor does looking make you a target. Attackers enumerate your domains whether or not you ever do; choosing not to look simply means they have a better map than you.
It will not tell you with certainty whether a system is patched. It tells you what is exposed and what is probably running there. And it replaces nothing in the NCSC’s guidance: not the incident response plan, not offline backups, not the hard recovery decisions about what comes back first. It improves the quality of the input those decisions rely on, which is a smaller claim and a more honest one. A tool that promises more than that is worse than useless, because it gives false confidence.
What good looks like is modest: a current external inventory you could reproduce from outside, a named owner against every entry, and a short list of exposures you have already decided how to handle.
The Short Version
- The NCSC disruptive attack guidance covers preparation, response and recovery for attacks that stop you operating normally, with recovery measured in weeks or months. It is not a technical runbook and it assumes you can describe your own estate.
- Internal registers routinely miss marketing microsites, legacy VPN endpoints, test environments, supplier-hosted subdomains and acquired infrastructure.
- Build the external record so it can be rebuilt from outside, from a seed domain plus certificate transparency logs, DNS and registration data, and keep a copy out of band.
- Discovery gives candidates. Ownership confirmation turns them into assets, and it is far cheaper before an incident.
- Subdomain takeover risk peaks after a mass rebuild, not before the attack. Audit DNS records against live resources once the rebuild settles.
- Agree in advance which evidence standard justifies which action, so “likely affected”and “definitely affected”are not argued over mid-incident.
- Decide now which changes wake someone up. Everything else goes to a weekly review grouped by owner.
Frequently Asked Questions
What does the NCSC define as a highly disruptive cyber attack?
The NCSC’s response and recovery guidance, published on 28 July 2026, describes it as an attack that disrupts, disables or damages critical systems or services so that the organisation cannot operate normally. The defining feature is duration: recovery is expected to take weeks or months. Incidents you can contain and resolve within normal working patterns sit outside that category.
What does the NCSC disruptive attack guidance say about preparation?
Preparation is the first of its three stages and covers the work that only makes sense before an incident: knowing your assets and dependencies, having backups you can actually restore, arranging specialist support in advance, and agreeing who decides what. The guidance does not prescribe tooling. It does assume you can answer factual questions about your estate, including which systems are reachable from the internet and who owns them.
How do I work out which internet-facing assets I own before an incident?
Start with your registered domains, then expand outwards using certificate transparency logs, DNS records and domain registration data, and repeat the process on whatever new names appear. Treat the result as a candidate list and confirm ownership for each entry through the registrar, DNS controller, hosting account and a named business owner. Our guide to finding forgotten internet-facing assets walks through doing this with free tooling.
Why do dangling DNS records appear during recovery, and how do I close them?
Rebuilds tear down and recreate cloud resources quickly, while the CNAME records pointing at the old storage buckets, app services and CDN endpoints are left behind. If an attacker can claim the original resource name in their own account, the record now points at their content on your domain. The fix is to remove or correct the DNS record; there is no server to patch. Schedule a DNS-against-resources audit as a recovery task, not an afterthought.
Does external attack surface discovery count as hacking or make us more likely to be attacked?
Passive discovery reads information that is already public: certificate logs, DNS, registration data and the responses services give any visitor. It does not exploit anything. Active vulnerability testing is a different matter and should only be run against systems you own or have written permission to test. Looking does not attract attention either; enumeration of your domains happens regardless, so the only question is whether you have the same picture.