Many security teams report tens of thousands of open findings each month and still cannot answer the question the board actually asks: which of these could an attacker use to reach something we care about, and how quickly do we close those? Exposure management is the shift from counting vulnerabilities to reducing exploitable paths, across software flaws, misconfigurations, exposed identities and internet-facing assets. This model uses NHI Mgmt Group's five levels, Ad hoc to Optimised, to score an exposure management programme across six dimensions, from scoping to mobilisation, and gives a realistic route from periodic scanning to continuous validation. It is for vulnerability management leads, CISOs and security architects. The discipline itself, including the five CTEM stages, is covered in the Exposure Management and CTEM Guide; this page is the scoring tool.
Key takeaways
- The five levels are Ad hoc, Developing, Defined, Managed and Optimised, scored separately across scoping, discovery, prioritisation, validation, mobilisation and measurement.
- Prioritisation is the hinge. Moving from severity scores alone to exploitation evidence (CISA KEV, EPSS) and business context is what takes most programmes from Level 2 to Level 3.
- Validation separates Level 4. Exposures are proven reachable and exploitable, by attack path analysis or safe testing, before they consume remediation effort.
- Mobilisation is usually the ceiling. If findings cannot reach an accountable owner with an agreed deadline, better discovery only produces a longer backlog.
- Identity exposures count. Over-privileged service accounts, stale keys and exposed tokens are exposures in the same queue as software flaws, not a separate programme.
The five levels
| Level | Name | What it looks like |
|---|---|---|
| 1 | Ad hoc | Scans run occasionally on known networks, often before audits. Findings are exported to spreadsheets and prioritised by CVSS base score alone. No consistent asset inventory, no remediation deadlines, and cloud, SaaS and identity exposures are out of scope. |
| 2 | Developing | Authenticated scanning runs on a schedule for servers and endpoints. A vulnerability or patch policy sets deadlines by severity. Cloud configuration checks exist but are reported separately. Backlogs grow because everything rated critical or high is treated the same. |
| 3 | Defined | The programme has a written scope that includes external attack surface, cloud, SaaS and identity. Prioritisation uses exploitation evidence (KEV listing, EPSS) and asset criticality, not just CVSS. Every in-scope asset has an owner, findings flow to ticketing, and exceptions are risk-accepted by a named senior owner. |
| 4 | Managed | Exposures are correlated across tools into one view and validated: attack path analysis shows which findings lead to critical assets, and safe testing or breach and attack simulation confirms exploitability and control effectiveness. Metrics on exploitable exposure and time to close are reported monthly to leadership. |
| 5 | Optimised | Exposure assessment is continuous and scoped by business service. Common exposure classes are prevented at build time through guardrails and secure baselines. Validation runs automatically after changes, results feed threat modelling and architecture decisions, and the programme is re-scored at least twice a year. |
Capability dimensions
The six dimensions follow the CTEM cycle (scoping, discovery, prioritisation, validation, mobilisation) plus measurement. Score each separately and take the lowest as the honest programme level. A capability that covers only part of the estate scores no higher than Level 2.
| Dimension | Level 1 Ad hoc | Level 3 Defined | Level 5 Optimised |
|---|---|---|---|
| Scoping | Whatever the scanner can reach | Written scope covering on-premises, cloud, SaaS, external surface and identities, tied to business services | Scope set per business service and reviewed when services, mergers or suppliers change |
| Discovery | Unauthenticated network scans, irregular | Authenticated scans, cloud posture checks, external surface discovery and identity posture data on a set schedule | Continuous discovery from agents, cloud APIs and provisioning pipelines; new assets assessed at creation |
| Prioritisation | CVSS base score only | CVSS plus KEV listing, EPSS probability, asset criticality and internet exposure; a documented decision method such as SSVC | Risk-based ranking that includes attack path position, compensating controls and business impact, recalculated daily |
| Validation | None; findings assumed real | Manual confirmation for critical findings; annual penetration testing | Continuous attack path analysis and automated safe testing after changes; control effectiveness verified |
| Mobilisation | Findings emailed to IT | Owner on every asset, tickets with deadlines, senior risk acceptance for exceptions with expiry dates | Fixes routed into engineering backlogs automatically; recurring classes fixed at source in templates and baselines |
| Measurement | Count of open vulnerabilities | Time to remediate by priority, KEV backlog, exception count | Exploitable-path count to critical assets, trend of validated exposure, cost of exposure reduction per business service |
Prioritisation inputs at Level 3 and above
- CISA Known Exploited Vulnerabilities (KEV): a catalogue of vulnerabilities with evidence of exploitation in the wild. Under BOD 22-01, US federal civilian agencies must remediate KEV entries within two weeks for CVEs assigned in 2021 or later and six months for older CVEs, unless CISA sets a shorter date. Many private organisations adopt the two-week figure as a benchmark. See the CISA KEV Catalogue Guide.
- EPSS: FIRST's Exploit Prediction Scoring System estimates the probability, from 0 to 1, that a published CVE will be exploited in the wild in the next 30 days, with scores published daily. See the EPSS Guide.
- SSVC: CISA's Stakeholder-Specific Vulnerability Categorization uses decision points (exploitation status, technical impact, automatable, mission prevalence and public well-being impact) to reach one of four decisions: Track, Track*, Attend or Act.
- Business context: asset criticality, data classification and internet reachability from your inventory and attack surface tooling.
Where identity fits
Attack paths rarely end at a vulnerable server; they run through credentials. A Level 3 programme brings identity posture into scope: service accounts with domain admin rights, cloud roles with wildcard permissions, long-lived access keys, secrets in code and unused privileged accounts. At Level 4, attack path analysis combines software flaws and identity relationships, so a medium-severity flaw on a host where a privileged service account logs on outranks a critical flaw on an isolated test box. See the Identity Attack Paths Guide and the ISPM Guide.
Self-assessment questions
Answer yes only if the practice is documented, covers the whole in-scope estate and has run for at least two quarters.
- Scoping: Is there a written exposure management scope that includes cloud, SaaS, the external attack surface and identities, and is it mapped to business services?
- Discovery: Are servers and endpoints scanned with credentials on a schedule, and are cloud accounts assessed for misconfiguration at least daily?
- Discovery: Can you list every internet-facing asset and its owner today?
- Prioritisation: Does your ranking use KEV listing and EPSS or an equivalent exploitation signal, as well as asset criticality?
- Prioritisation: Is the decision method written down, so two analysts rank the same finding the same way?
- Validation: Are critical findings confirmed as reachable before remediation is demanded, and do you test whether existing controls block exploitation?
- Validation: Do you analyse attack paths to your most critical assets, including identity relationships?
- Mobilisation: Does every finding reach an accountable owner with a deadline, and do risk acceptances expire?
- Mobilisation: Are recurring exposure classes fixed in templates, images or baselines, not one asset at a time?
- Measurement: Do you report time to remediate KEV-listed vulnerabilities and the count of validated exploitable paths to leadership monthly?
Scoring: mostly "no" is Level 1. Yes to discovery and a severity policy only is Level 2. Yes to every scoping, prioritisation and mobilisation question is Level 3. Add validation and monthly outcome reporting for Level 4. Level 5 needs prevention at build time and automated validation after change.
Moving up a level
Level 1 to Level 2
- Build or adopt an asset inventory and agree owners for server and endpoint estates. The Asset Inventory Maturity Model sets the bar.
- Switch to authenticated scanning on a fixed schedule and fix scan coverage gaps first.
- Publish a patch and vulnerability policy with deadlines by priority. NIST SP 800-40 Rev. 4 frames patching as preventive maintenance and is a good basis.
Level 2 to Level 3
- Extend scope to cloud posture, external attack surface and identity posture, and record it in writing.
- Add KEV and EPSS to prioritisation, and adopt a documented decision method such as SSVC.
- Track KEV-listed findings separately with a two-week target (benchmarked on BOD 22-01) and report the backlog.
- Introduce formal risk acceptance: the NCSC's vulnerability management guidance treats a decision not to update as a senior-level risk decision, so require a named owner and an expiry date.
Level 3 to Level 4
- Correlate findings across scanners, cloud, surface and identity tools into one exposure record per asset.
- Add attack path analysis for critical assets, starting with the directory and cloud control planes.
- Introduce safe, continuous validation through breach and attack simulation or targeted testing, and agree with stakeholders what validated results trigger remediation. See the Breach and Attack Simulation (BAS) Guide.
- Report validated exploitable exposure, not raw counts, to leadership.
Level 4 to Level 5
- Push the top recurring exposure classes into build-time guardrails: hardened images, policy as code and pipeline checks.
- Trigger validation automatically after significant change (new internet-facing service, new privileged role).
- Feed results into threat modelling, architecture review and supplier decisions, and re-score twice a year.
Small organisations: Level 3 is a sensible ceiling. A managed scanning service, KEV-first patching and an owner list in a spreadsheet deliver most of the value. Large organisations: fund mobilisation (owners, workflows, engineering time) before more discovery tooling.
Metrics by level
| Metric | Introduced at | Why it matters |
|---|---|---|
| Scan coverage of in-scope assets | Level 2 | Unscanned assets are unknown exposure |
| Median time to remediate KEV-listed findings | Level 3 | Directly tracks exploited-in-the-wild risk |
| Findings without an owner | Level 3 | Shows whether mobilisation works |
| Expired or overdue risk acceptances | Level 3 | Exceptions that quietly became permanent |
| Validated exploitable paths to critical assets | Level 4 | The outcome measure the board can follow |
| Recurring exposure classes fixed at source | Level 5 | Prevention instead of repeated clean-up |
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | ID.RA-01, ID.RA-05, ID.RA-06 | Vulnerabilities identified and validated; risk used to prioritise; responses tracked |
| NIST CSF 2.0 | ID.IM-02 | Improvements from security tests and exercises |
| NIST SP 800-53 Rev. 5 | RA-3, RA-5, RA-7, CA-7, CA-8 | Risk assessment, vulnerability scanning, risk response, continuous monitoring, penetration testing |
| CISA | BOD 22-01 and KEV catalogue | Exploitation-based prioritisation and deadlines |
Common failure patterns
- Tool before scope. Buying an exposure platform without a written scope and owner model produces a prettier backlog.
- Everything is critical. Ranking by CVSS alone sends teams after thousands of findings that are not being exploited.
- Validation without consequence. Attack path results that do not change remediation priority waste the effort.
- Permanent exceptions. Risk acceptances with no expiry date accumulate into the real exposure.
- Identity left out. Over-privileged service accounts and stale keys sit in a different team's queue and never appear in exposure reporting.
Practitioner checklist
- Write the exposure management scope, including cloud, SaaS, external surface and identity.
- Score each of the six dimensions and record the lowest as the programme level.
- Add KEV and EPSS to prioritisation and document the decision method.
- Track KEV-listed findings against a two-week target and report the backlog monthly.
- Give every in-scope asset an owner and every exception an expiry date.
- Pilot attack path analysis for one critical asset group, including identity relationships.
- Introduce safe validation and agree which results trigger remediation.
- Re-score the model every six months and publish the trend.
Standards and references
- CISA: BOD 22-01, Reducing the Significant Risk of Known Exploited Vulnerabilities
- CISA: Stakeholder-Specific Vulnerability Categorization (SSVC)
- FIRST: Exploit Prediction Scoring System (EPSS)
- NIST: SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning
- NCSC: Vulnerability management
- Gartner: How to Manage Cybersecurity Threats, Not Episodes (CTEM)
- NIST: Cybersecurity Framework 2.0
Related NHI Mgmt Group resources: Exposure Management and CTEM Guide · Attack Surface Management Maturity Model · Risk-Based Vulnerability Management Guide · Exposure Management Buyer's Guide · CIS Control 7 Continuous Vulnerability Management Guide