Why map scan findings to control frameworks at all?
If you run an automated security scanner, you get a list of findings: an outdated TLS configuration here, a missing security header there, an exposed admin endpoint somewhere else. Useful — but auditors, customers, and your own leadership rarely ask "how many findings do you have?" They ask "are you meeting NIST CSF?", "where do we stand against PCI DSS 4.0?", or "which CIS controls are at risk?"
That gap is exactly why mapping security findings to compliance frameworks matters. Findings describe technical reality. Frameworks describe expected controls. Mapping is the translation layer that lets one scan answer many questions at once, so a security engineer's output becomes something a GRC team can actually act on and evidence.
The catch: an automated external scan can only legitimately speak to a subset of any framework. Done honestly, mapping makes that boundary explicit instead of quietly inflating a pass rate. This post covers a quick orientation to three frameworks, what an external scan can and cannot evidence for each, and how to keep the mapping truthful.
A short orientation to three frameworks
NIST CSF 2.0 (functions)
NIST Cybersecurity Framework 2.0 organizes outcomes into six functions: Govern, Identify, Protect, Detect, Respond, and Recover. It is intentionally outcome-based rather than a checklist of technical settings. An external scan lives mostly inside a slice of Protect (e.g., platform hardening, secure configuration) and Identify (asset and vulnerability discovery). It says almost nothing about Govern (policy, roles, risk strategy), Respond, or Recover — those are program and process outcomes a scanner never observes.
CIS Controls v8 (IG1–IG3)
CIS Controls v8 is a prioritized set of 18 controls, broken into Safeguards and tiered by Implementation Group:
- IG1 — essential cyber hygiene, the baseline every organization should meet.
- IG2 — for organizations managing more sensitive data and complexity.
- IG3 — for those facing sophisticated, targeted threats.
CIS is concrete and technical, so more of it is externally observable than NIST CSF — but "observable from the outside" still covers only part of it. A scan can speak to pieces of Control 7 (Continuous Vulnerability Management) and externally visible configuration, but not to inventory accuracy, account management, or backup recovery.
PCI DSS 4.0 (vulnerability scanning: req 6 and 11)
PCI DSS 4.0 is prescriptive. For vulnerability work, two requirements stand out:
- Requirement 6 — develop and maintain secure systems and software, including addressing known vulnerabilities.
- Requirement 11 — regularly test security of systems and networks, including internal and external vulnerability scans (and, for external scans tied to compliance, ASV scanning by an Approved Scanning Vendor on a defined cadence).
A general automated external scan can produce strong supporting evidence for parts of Req 6 and 11, but it is not automatically an ASV scan, and it does not cover requirements like network segmentation testing, key management, or access control policy.
What an external scan CAN and CANNOT evidence
The honest framing for every framework is the same: a scan is one input, not a verdict. Here is the rough split.
An external scan CAN provide supporting evidence for:
- Known-vulnerability exposure on internet-facing assets
- Insecure transport and certificate issues
- Missing or weak security headers and obvious misconfigurations
- Some externally visible patch-level and software-version problems
An external scan CANNOT evidence:
- Governance, policy, roles, and risk strategy
- Internal access control, account, and identity management
- Backup, recovery, and incident response processes
- Physical security, key management, and most internal segmentation
The failure mode to avoid is treating "the scan didn't find a problem" as "the control passes." For a control a scan can't even observe, the only truthful state is not assessed — neither pass nor fail.
One finding, mapped across three frameworks
Mapping becomes intuitive with an example. Suppose a scan finds a web app serving over a weak, outdated TLS configuration. The same finding touches all three frameworks at once:
| Sample finding | NIST CSF 2.0 | CIS Controls v8 | PCI DSS 4.0 |
|---|---|---|---|
| Weak/outdated TLS on a public endpoint | Protect (data-in-transit protection) — at risk | Control 3 (Data Protection) safeguards for encryption in transit — at risk | Req 4 (protect data in transit) and Req 6 (known vulns) — at risk |
| Internal access-control policy | Govern / Protect (access) — not assessed | Controls 5–6 (account & access management) — not assessed | Req 7–8 (access control) — not assessed |
| Backup and recovery process | Recover — not assessed | Control 11 (Data Recovery) — not assessed | Req 12 (program/process) — not assessed |
Notice that one technical finding lands in multiple control families, and that most rows are honestly not assessed because an external scan simply can't see them. A credible posture view shows all three states: at risk, assessed with no issue, and not assessed.
Keeping the mapping honest
Good mapping is defined by what it refuses to claim. Three rules:
- Never auto-pass the unobservable. If a scan can't reach a control, mark it not assessed, distinct from a clean result.
- Separate "assessed, no issue" from "not assessed." They look similar on a dashboard but mean very different things to an auditor.
- Keep the evidence traceable. Every "at risk" mapping should trace back to the specific finding that triggered it.
This is precisely how NANOTESTING approaches it. Each scan's findings are auto-mapped across seven frameworks at once — including NIST CSF 2.0, CIS Controls v8, and PCI DSS 4.0 — and the /compliance view shows, per framework, controls at risk, controls assessed with no issue, and controls an external scan cannot assess. Those last ones are shown grey and are never counted as passing. You can view posture for the whole workspace or per target, and export auditor-ready evidence packs as PDF, CSV, or JSON for one target or several.
The point isn't to replace your GRC program — it's to give the externally observable slice of it accurate, traceable, multi-framework coverage, with the limits drawn in plain sight.
Takeaways
- Mapping turns raw findings into framework language your auditors and customers understand.
- NIST CSF 2.0 (functions), CIS v8 (IG1–3), and PCI DSS 4.0 (req 6/11) each have only a partial externally observable surface.
- A scan is supporting evidence, not a verdict — the controls it cannot reach must be marked not assessed, never auto-passed.
- Honest mapping shows three states (at risk, assessed-no-issue, not assessed) and keeps every claim traceable to a finding.
If you're building compliance evidence from scan data, start by asking the harder question for every control: can this scan actually see it? Where the answer is no, say so.