Your website is only the starting point
A business’s external attack surface includes its publicly accessible websites, portals and other services. After a website migration, old campaign addresses or test portals may still exist. An inventory shows which services are needed and who decides whether to keep them.
Domains and digital certificates belong in the inventory too. The UK’s NCSC recommends keeping records current and checking them against multiple information sources. For a business with only a few services, a regularly maintained list can be sufficient. [1]
Discovery does not establish a vulnerability
A discovered subdomain is initially something to clarify. The address might identify a necessary service, a redirect or an old reference. A security assessment needs consistent attribution, observation dates and specific technical evidence. The number of discovered addresses tells you little about which action is needed.
Keep separate fields for observations and decisions. “Address found in a public source” describes the evidence. “Supplier confirms the service belongs to our account” records attribution. “Business owner to decide whether to retire it” sets the next step. None of these statements, by itself, proves an exploitable vulnerability.
A record somebody can act on
Our suggestion for a small organisation is a short working register. Start with known services and add discoveries that need clarification. One person within the business coordinates the work; answers may come from your agency, IT support provider or service supplier.
For each entry, record at least the details below. Where an answer is missing, assign the question and a due date. “Unknown” is more useful than a guess that later gets treated as an established fact.
- System: exact address, associated service and business purpose.
- Owner: the person in the business who decides on its use and changes.
- Provider: supplier, customer account reference and responsible contact; no passwords.
- Evidence: source, date and what was actually observed or confirmed.
- Next step: retain, clarify or approve retirement, with a due date.
- Completion: who checked the change and where the confirmation is recorded.
Cancelling a contract does not tidy up DNS
DNS is the address directory that links names to their intended technical destinations. When changing providers, ask explicitly which records belong to the old service. Cancelling the contract does not answer that technical question.
Microsoft documents a specific Azure risk: when DNS still points to a removed resource, a subdomain takeover may become possible under certain conditions. Review the DNS mapping and destination together; an old reference alone does not confirm a takeover. [3]
What an external view can tell you
An external security assessment can organise observable services and configuration concerns into a useful picture. Existing public information and direct, low-impact DNS, TLS or HTTP requests should be distinguished in both the engagement and its findings. “External” does not automatically mean “entirely passive”.
The described Level 1 scope provides a documented starting point without signing into applications. Whether user roles are correctly separated or access works as intended after sign-in requires a separately agreed assessment with suitable test accounts.
The NCSC likewise distinguishes the external view of internet-accessible resources from an examination of internal risks. What can be observed from outside determines which questions that view can answer. [2]
Close the task and revisit the record
For the next review, we suggest three manageable tasks: resolve unclear ownership, put unused services forward for a decision and track agreed changes. Revisit the register after changing agencies, launching campaigns and finishing projects too.
When retiring assets, the NCSC recommends considering dependencies beforehand, checking the outcome and retaining evidence. Ask for confirmation that the technical work is complete, then update the entry. [4]
Related reading
Sources & further reading
Published:
Primary sources checked on 29.09.2026.
Sources and limitations are identified in the article.
