Resources · 02

Cyber exposure assessment: a prioritised checklist

Inventory what is visible, connect exposure to business assets and turn findings into a verifiable risk-reduction plan.

Updated 23 October 2026 · 4 min

Illustration · fictional scene

What this guide helps achieve

Find forgotten assets
Separate exposure from actual risk
Address credible attack paths first
Prove that a finding is closed

Quick check

Does every domain have an owner?
Do administrators use phishing-resistant MFA?
Are test services exposed?
Has restoration been tested?
Does every exception expire?

Step-by-step method

01
Define the authorised scope
List entities, domains, ranges, cloud applications and exclusions. Agree allowed techniques, timing and an emergency contact.
Deliverable: scope and rules of engagement.
02
Inventory from the outside
Correlate DNS, certificates, published services, visible technology, public repositories and official accounts. Assign every asset an owner.
Deliverable: dated inventory.
03
Review identities and access
Check MFA coverage, orphan accounts, standing privileges, recovery mechanisms and exposed secrets.
Deliverable: critical access map.
04
Connect vulnerability and context
A weakness becomes a priority when it is reachable, exploitable, linked to critical data or function and insufficiently detected.
Deliverable: risk scenarios.
05
Verify resilience and detection
Review backups, restoration, logging, alerts, dependencies and crisis procedure. An untested backup remains an assumption.
Deliverable: test evidence.
06
Manage remediation
Give each action an owner, date, expected evidence and residual risk. Revalidate externally after the fix.
Deliverable: prioritised backlog.

Worked example

Illustrative situation

A subsidiary finds an old subdomain in search results. Before scanning, it confirms ownership, hosting, purpose and whether real data may still be present.

Decision and expected evidence

The exposure record separates an approved asset, an abandoned service and an unknown third party, with an owner and closure evidence for each.

Management indicators

Indicator	What it measures	First action
Inventory coverage	Observed assets with an owner and criticality	Address ownerless assets first
Critical exposure	Sensitive services accessible from the Internet	Reduce access, segment or add strong controls
Time to remediate	Time from validated finding to closure evidence	Unblock high-impact, low-effort actions
Residual risk	Accepted exposure with an owner and expiry	Expire exceptions instead of leaving them open

Common pitfalls

Scanning without authorisation or a defined window
Ranking only by a technical score
Ignoring SaaS and historic subdomains
Closing an action without confirmation testing

Frequently asked questions

Is an exposure review a penetration test?

No. It maps and qualifies visible exposure using non-intrusive or explicitly authorised methods. Penetration testing validates selected scenarios under a separate scope.

How often should the inventory be repeated?

After major change and regularly. External assets change quickly, so frequency should follow your deployment cadence.

Why test backups?

A file or successful job does not prove integrity or the ability to restore a service within the expected time.

References: data, uses and limitations

Documentation reviewed on 2026-10-22.

References: data, uses and limitations
Source and purpose	Verified data or benchmark	How to use it	Limitation to retain
NIST · Cybersecurity Framework Structure the outcomes expected from a cybersecurity programme.	CSF 2.0 has six functions: Govern, Identify, Protect, Detect, Respond and Recover. It does not prescribe a single way to achieve outcomes.	Describe current and target profiles with evidence, gaps and owners. Connect each priority to the services it helps protect. Explore the method →	Mapping to the framework is neither certification nor proof that every control works.

security.txt and disclosure

Check that an external report reaches a team

Cyber exposure also includes the ability to receive a useful report. A security.txt file can make the contact discoverable, but its presence alone establishes neither channel availability nor case follow-through.

Check /.well-known/security.txt, HTTPS, Contact fields and exactly one Expires.
Preserve the exact host, redirects and policy link; do not extend scope to subdomains by default.
Assign a publication owner and a report handler; distinguish receipt, assessment and remediation.

Read the security.txt reference and disclosure cases →

Sources checked on 2026-10-22 · IETF · RFC 9116 · §2.5, §3, §5

CVSS, EPSS, KEV and VEX

Preserve the facts justifying remediation order

An exposure review is more useful when each vulnerability connects to an instance and decision. Keep generic scores identifiable and dated, then relate them to the exposed service.

Separate CVSS severity, EPSS probability, KEV listing and VEX applicability assertions.
Establish product, version, access paths and owner before declaring local exposure.
Record decision, interim control and verification evidence; an available patch is not a deployed fix.

Read the CVSS, EPSS, KEV and VEX reference →

Sources checked on 2026-10-22 · FIRST · CVSS 4.0 Specification · FIRST · EPSS Frequently Asked Questions · CISA · KEV official data schema · OpenVEX · Specification v0.2.0

Explore the CISA KEV catalogue

Connect an exposure to an official entry

Start with a CVE or product in the dated catalogue, then check the vendor advisory, deployed version and access path. KEV adds a known-exploitation signal; it does not replace analysis of your environment.

Keep the entry and catalogue version.
Document the product/version match and remaining uncertainty.
Separate remediation, mitigation and investigation.

Explore the catalogue and method →

CISA KEV · 2026.10.21 · Documentary review : 2026-10-22

Explore NIST CSF 2.0 outcomes

Connect exposure findings to expected outcomes

An inventory or vulnerability list describes part of the situation. CSF 2.0 also supports discussion of responsibility, protection, detection and recovery.

ID.AM: reconcile observed assets, data, services and owners.
ID.RA: describe a risk scenario and business consequences.
PR.PS: examine maintenance and actual platform state.
Document evidence and scope; do not turn a finding count into a compliance score.

Explore outcomes and evidence to examine →

NIST CSWP 29 · CSF 2.0 · 2024-02-26 · 2026-10-22

TLS certificates and open-source intelligence

CT: a discovery lead requiring qualification

Public logs help examine certificates associated with a scope. A CT result is documentary evidence, not a finding of an exploitable vulnerability.

Match each name to an authorised inventory.
Do not count duplicates across logs as separate assets.
Separate issuance, deployment, expiry and observed exposure.

Read the CT dossier and dated log list →

Google Chrome · Certificate Transparency for Site Operators · Domain Privacy · consulted 2026-10-23

Official references

References consulted: 23/10/2026. The method and worksheet propose checks to adapt to your context; they do not constitute certification.