CIS Critical Security Controls v8 evidence at the per-Safeguard level — with the Implementation Group cumulative discipline auditors and cyber-insurance underwriters actually consume.
NSAuditor AI EE generates CIS Controls v8 (Center for Internet Security, May 2021; v8.1 errata June 2024) pre-audit gap reports mapped at the per-Safeguard level — the atomic, attestable unit. SHA-256 chain-of-custody sidecars, cover-page Scope Attestation, suppression workflow, honest IG-cumulative framing (engine substrate is a SUBSET of each Implementation Group; the remainder is operator-side process/endpoint artifacts), no-certification-body attestation discipline — and Zero Data Exfiltration, so you can scan inside your own boundary without sending infrastructure data to a third-party SaaS scanner.
✓ 17 Safeguards covered⚠ 23 partial⊘ 113 explicit OOS⚡ IG-cumulative disciplineLatest: EE 0.35.0 (2026-08-12) — the approval surface: suppression approvals get a CLI — compliance suppress | review | renew | keygen — and NSAUDITOR_SIGNING_KEY becomes a setting that changes the artifact. Ed25519 suppression signing is reachable and not yet proven: its verification gate has not run against published bytes
Earlier in the same lane: EE 0.33.1 (2026-08-07) — auditor-verifiable proof, now stated in all seven framework reports. All seven auditor-shaped reports now say the same thing about evidence integrity: RFC 3161 trusted timestamping is opt-in via NSAUDITOR_TSA_URL, pointed at a Time-Stamp Authority you choose, and every compliance artifact then carries a .tsr sidecar your auditor verifies offline with stock openssl — against that third party, with none of our software in the path. Opt-in with no default, ever, so an air-gapped environment simply leaves it unset. Verified end to end on 2026-08-07 against a real public Time-Stamp Authority through the published binaries. The agent skill and the Community Edition README answer the same way, so every surface a reader can reach agrees. It builds directly on EE 0.33.0 (2026-08-07), the wiring release: eleven compliance options that nothing shipped could populate now receive values from a real entry point, Zero Data Exfiltration is stated as a positive register of 17 enumerated outbound paths, and signature records carry algorithm and backend frozen at signing time. EE 0.33.0 requires CE ≥ 0.2.37 — the new entry points live in Community Edition. RFC 3161 trusted timestamping is now opt-in via NSAUDITOR_TSA_URL (verified against a real timestamp authority on 2026-08-07; opt-in, not a default); Ed25519 suppression signing is reachable and not yet proven — its verification gate has not run against published bytes. Matrix-neutral — all seven coverage matrices UNCHANGED and the plugin count UNCHANGED at 28 Enterprise plugins (27 of them cloud auditors), 55 overall; the CIS Controls v8 matrix is UNCHANGED at 17 covered / 23 partial / 113 OOS = 153 Safeguards, IG denominators included. Paired CE 0.2.37 + agent-skill 0.2.35. Prior: EE 0.32.11 (2026-08-05) — the dependency-advisory release gate had been auditing the maintainer’s development tree while calling it the production closure. It now packs the tarball, installs it the way a customer does, and audits THAT, and it refuses to report clean until it has proved an advisory database actually answered. The gap it was hiding: the development tree carries 25 advisories, 8 of them HIGH; the closure a customer installs carries 6, none HIGH — across 26 advisory packages the two lists share five and zero high-severity ones, so every one of those eight highs was development-only. That is Safeguard 7.x territory read back onto our own supply chain, and it is the register an underwriter reviewing an IG1 attestation should expect a vendor to hold itself to. That release was matrix-neutral — still 28 Enterprise plugins, 27 of them cloud auditors (55 overall), and seven frameworks; the CIS Controls v8 matrix was UNCHANGED at 17 covered / 23 partial / 113 OOS = 153 Safeguards. The SOC 2 matrix is now enumerated in full at 10 / 4 / 37 = 51 — enumeration completeness, not a coverage change. Paired CE 0.2.35 + agent-skill 0.2.33. Full detail below.
CURRENT · EE 0.35.0 · 2026-08-12Suppression approvals get a CLI (matrix-neutral)EE 0.35.0 + CE 0.2.40 + agent-skill 0.2.38
The approval surface — every accepted risk now has a name, a date and an expiry, and a command line to manage them
EE 0.35.0 is the current release — the approval surface. Suppression approvals get a CLI (compliance suppress | review | renew | keygen) and NSAUDITOR_SIGNING_KEY becomes a setting that changes the artifact: suppress signs the approval it writes when the variable names a local Ed25519 key — a capability that is reachable and not yet proven — its verification gate has not run against published bytes, so no surface here presents a produced signature as verified evidence. Severity ranks how bad a vulnerability would be if exploited; it never tells you whether anyone is exploiting it. EE 0.34.0 answers that at scan time. Every finding carrying a CVE is joined by CVE ID against the CISA Known Exploited Vulnerabilities catalog and FIRST EPSS exploitation-probability scores, and lands in one of three bands — KNOWN_EXPLOITED, ELEVATED or BASELINE. The queue is ordered exploit-first, so a KEV-listed MEDIUM outranks an unexploited CRITICAL, and the evidence travels with the finding: the KEV flag, the EPSS score with its percentile, the CVE ids that matched and the publication date of the catalog they were matched against — so an assessor can see why a finding was ranked where it was. Both catalogs are free, public and operator-supplied, and the join runs entirely on your machine: point the Pro tier at the KEV and EPSS files you already trust, and no CVE, host or finding leaves your network to obtain the ranking. riskScore is untouched — exploitPriority is a new axis beside it. It builds on EE 0.33.1, which stated auditor-verifiable proof in every framework report. All seven auditor-shaped reports say the same thing about evidence integrity: RFC 3161 trusted timestamping is opt-in via NSAUDITOR_TSA_URL, pointed at a Time-Stamp Authority you choose, and every compliance artifact then carries a .tsr sidecar your auditor verifies offline with stock openssl — against that third party, with none of our software in the path. Opt-in with no default, ever, so an air-gapped environment simply leaves it unset. Verified end to end on 2026-08-07 against a real public Time-Stamp Authority through the published binaries. The entry points these releases rely on live in Community Edition, so EE 0.35.0 requires CE ≥ 0.2.40.
Prior: EE 0.32.11 (2026-08-05) — the release gate that is supposed to tell us what a customer actually installs had been auditing the maintainer’s development tree and calling it the production closure. It now packs the tarball, installs it the way a customer does, and audits THAT — and it refuses to report clean until it has proved an advisory database actually answered.
Why the difference is not a rounding error — the development tree carries 25 advisories, 8 of them HIGH; the closure a customer installs carries 6, none HIGH. Across 26 advisory packages the two lists share five — and zero high-severity ones. Every one of those eight highs was development-only. A gate reading the wrong tree does not produce an obviously wrong number, it produces a number that reads exactly like the right one — the same false-clean shape this page already describes for unscannable clouds, one layer further out.
Also in this release — the SOC 2 matrix is now enumerated in full at 10 covered / 4 partial / 37 out of scope = 51, the complete AICPA TSC 2017 universe. That is enumeration completeness, not a coverage change: no control changed status and no routing changed. The Type I vs Type II documentation now says, mechanism by mechanism, which parts are reachable from a shipped entry point and which are not.
Verified on the published bytes, not the source tree — after a global install of the published tarballs, 28 of 28 Enterprise plugins active, and a three-cloud scan produced a 76-file evidence pack per cloud.
That release was matrix-neutral — still 28 Enterprise plugins, 27 of them cloud auditors (55 overall), seven frameworks, and the other six coverage matrices unchanged. The CIS Controls v8 matrix is UNCHANGED at 17 covered / 23 partial / 113 OOS = 153 Safeguards, and the IG denominators are unchanged (IG1 23-of-56 / IG2-cumulative 38-of-130 / IG3-cumulative 40-of-153). Paired CE 0.2.35 + agent-skill 0.2.33.
Prior: EE 0.32.9 (2026-07-29) — an internal-provenance strip plus a false-clean closure. A self-attestation pack is a document you hand an underwriter or a peer reviewer, and ours carried internal engineering identifiers — roadmap ids, internal release stamps, the name of an internal audit review — in finding titles, on the attestation cover page and in the chain-of-custody record. Measured on a rebuilt three-cloud evidence pack: 686 unexplained internal-marker occurrences → 0 across 105 files, with a positive control in the same run (3,572 benign matches still detected) so the zero is a measurement rather than an absence of looking.
The false-clean closure — when a cloud plugin could not start (optional SDK absent, credentials unusable) it refused to report, and that refusal evaporated one layer up: the compliance report came out byte-identical to one where the scanner ran and found nothing. Ten controls read PASS — no violation, no warning. The dangerous shape is ordinary: AWS and GCP scan for real, Azure’s SDK is absent, and the combined pack reads as a clean three-cloud audit. Now every in-scope Safeguard of a cloud that could not be scanned carries a fail-closed evidence gap — which matters most here, because an IG1 attestation an underwriter relies on must not silently count an unscanned cloud as implemented.
Also in that release — an archived scan re-processed by the new build WARNS instead of failing clean; four report surfaces that contradicted each other on trusted timestamping — which was still on the roadmap at that release, and became opt-in via NSAUDITOR_TSA_URL in EE 0.33.0 — now say the same verifiable thing; and a new instrument, a pack scanner that FAILS CLOSED when its own positive control is empty. The paired Community Edition fixes --out <dir>, which wrote to the PARENT directory when the directory name contained a dot; the MCP scan_cloud summary now handles both spellings of the evidence-gap prefix; and validate no longer misreports where plugins came from.
Two upgrade notes still apply — (1) the evidence-gap finding TITLE changed at 0.32.9, so suppression rules matching the older text stop matching; the direction is safe (findings resurface rather than hide) but it is SILENT, so re-check your suppression set. (2) Re-scan rather than re-process scans captured before 0.32.9 — the engine now warns.
That release was matrix-neutral too — 28 Enterprise plugins, 27 of them cloud auditors, seven frameworks, and all seven coverage matrices unchanged, IG denominators included. Paired CE 0.2.34 + agent-skill 0.2.32.
Before that: EE 0.32.8 (2026-07-28) — capability-claim honesty pass, part 2 — the air-gapped-delivery class. 27 advertised claims across the three published packages were checked against the code and withdrawn: an arm64 image (the build forces linux/amd64), offline-installable tarballs, monthly NVD feed bundles, an air-gapped install script, and a feed import CLI command with no implementation. Five of the 27 were not documentation but rendered runtime strings — the [COVERAGE GAP] rationale that prints verbatim into the assessor-facing evidence pack was telling the reader to import a feed with a command that does not exist. Nothing was withdrawn by deletion: the air-gap story was rewritten to what the code supports — a linux/amd64 delivery image or npm host install, fully offline ES256 license verification with no phone-home, and offline CVE matching under NSAUDITOR_OFFLINE_ONLY=1 — and ends with an explicit “deliberately not claimed” list, held by two mutation-proven guards. Matrix-neutral — no detection, routing or coverage change; still 28 EE plugins and all seven coverage matrices byte-identical to 0.32.7. The CIS Controls v8 matrix is UNCHANGED at 17 covered / 23 partial / 113 OOS = 153 Safeguards. The paired Community Edition also fixes --out, which silently wrote to the parent directory when the output directory was version-named. Regression 9,280 pass / 0 fail. Paired CE 0.2.33 + agent-skill 0.2.31. The Vanta · Drata · Secureframe GRC connectors ship as before (opt-in, outbound, single-workspace, early-access). And before that: EE 0.32.7 (2026-07-21) — cross-framework routing, so network-scan findings reach every framework that maps their control subject; matrix-neutral.
Per-Safeguard mapping at 17 covered + 23 partial + 113 OOS = 153 across 18 Controls — the atomic, attestable unit (coverage claimed at the SAFEGUARD level, never the Control level; Control-level roll-up is derived, never asserted as PASS). Engine substrate-evidences IG1 23-of-56 / IG2-cumulative 38-of-130 / IG3-cumulative 40-of-153; the remaining Safeguards are operator-side process/endpoint artifacts paired with your CSAT / CIS-CAT Pro self-attestation.
Implementation Group cumulative discipline — IG1 = 56 Safeguards (the cyber-insurance baseline; ~50-70% of mid-market policies require IG1 attestation), IG2 cumulative = 130 (IG1 + 74 IG2-only), IG3 cumulative = 153 (IG2 + 23 IG3-only). Smallest-IG-membership tagging per Safeguard; cumulative roll-up is the renderer's job. NEVER report IG2 as 74-of-74 in isolation — the IG1 base MUST be intact before any IG2/IG3 claim is valid.
No-certification-body attestation discipline — CIS Controls has no formal certification body (unlike ISO 27001's ISO/IEC 17021-1 bodies or PCI's QSAs). Engine output is INPUT to your CSAT / CIS-CAT Pro self-attestation OR a SOC 2 auditor cross-validating CIS scope OR CIS-SecureSuite peer review — NEVER "CIS certified."
CIS-Hardened-Image detection is LIVE — substantial substrate-evidence credit on Safeguards 4.1 + 4.2 + 4.6 for operators running CIS-Hardened-Images is detected, not just eligible: plugin 1210 (AWS) + Azure/GCP image-inventory producers feed the detector, and the renderer flips the credit from eligible → observed (with a per-cloud inspected-vs-hardened fraction + point-in-time caveat) when a Hardened-Image is found. Conservative — a Marketplace owner/alias alone never grants credit; a CIS-specific signal is required. Per-Safeguard shared-responsibility-model boundary (operator / cloud-provider / shared) unchanged.
5 Security Functions (NOT 6 — no Govern) + 6 Asset Types + MS-ISAC / EI-ISAC / H-ISAC sector baselines + v7.1-to-v8 cross-reference per the v71Source field on every covered/partial Safeguard.
28 plugins (including plugin 1210 aws-ec2-instance-auditor — the AWS Hardened-Image producer); CIS v8 matrix 17/23/113 (Safeguard 8.10 Retain Audit Logs partial via the RDS CloudWatch Logs retention posture; Safeguard 9.5 Implement DMARC partial via the SES DMARC posture; IG1 23-of-56 cyber-insurance baseline unchanged, IG2-cum 38, IG3-cum 40); SOC 2 + HIPAA + NIST CSF + PCI DSS + ISO 27001 + GDPR Art. 32 matrices UNCHANGED.
CIS Controls v8 published May 2021 by the Center for Internet Security (v8.1 errata June 2024). Structure: 18 Controls decomposed into 153 Safeguards across 3 cumulative Implementation Groups (IG1 / IG2 / IG3). The most-requested next framework after SOC 2 + HIPAA + NIST CSF 2.0 + PCI DSS v4.0.1 + ISO 27001:2022 for SMB + mid-market + state/local-government + critical-infrastructure operators — and the baseline most cyber-insurance underwriters key IG1 attestation to. NSAuditor's engine is framework-agnostic — see the SOC 2, HIPAA §164.312, NIST CSF 2.0, PCI DSS v4.0.1, and ISO/IEC 27001:2022 coverage matrices for the companion frameworks.
NSAuditor AI EE generates CIS Controls v8 per-Safeguard-level evidence — at the same institutional grade as SOC 2, HIPAA, NIST CSF 2.0, PCI DSS, and ISO 27001.
It maps cloud infrastructure findings (AWS, Azure, GCP) and network scan results to specific Safeguards (3.3, 5.4, 8.2, 11.4, etc.), produces hash-chained evidence artifacts (cover-page Scope Attestation, SHA-256 chain-of-custody sidecars, and a documented suppression workflow), and ships CIS reports in machine-readable form suitable for CIS-aware GRC platform ingestion + CSAT / CIS-CAT Pro self-attestation workflow.
It is not a CIS certification (CIS has no certification body — engine output is INPUT to self-attestation). It is not an IG attestation (the IG1 base requires operator-side process/endpoint artifacts beyond infrastructure scanning). It is not a Security Awareness Training program (Control 14 — operator-side LMS). It is not an Incident Response program (Control 17 — operator-side). It is not a Penetration Testing engagement (Control 18 — operator-side). It is not a complete CIS Controls v8 attestation (153 Safeguards total; engine evidences 38 at conservative-MVP density).
What it IS: the per-Safeguard technical-evidence layer covering Control 1-2 inventory substrate, Control 3 Data Protection (access control lists + encryption-in-transit + encryption-at-rest), Control 4 Secure Configuration (firewall + Config recorder + Hardened-Image credit), Control 5-6 Account + Access Management (IAM inventory + shadow-admin + MFA), Control 7 Continuous Vulnerability Management (Inspector2 substrate), Control 8 Audit Log Management (CloudTrail substrate), Control 11 Data Recovery (AWS Backup Logically Air-Gapped Vault), Control 12-13 Network Infrastructure + Monitoring (Security Group + VPC + GuardDuty), and Control 16 Application Software Security (CI/CD guardrails + WAF) — complete and self-attestation-ready. Honest about what infrastructure scanning fundamentally cannot evidence (security-awareness training, endpoint EDR, incident-response execution, penetration testing) — saves you from the textbook CIS-canonical overclaim.
The market split: CIS-aware GRC platforms (Drata CIS Controls, Vanta CIS Controls, AuditBoard CIS) automate the self-attestation workflow + continuous evidence collection but lack deep cloud-infrastructure scanning at the per-Safeguard-evidence level. Legacy compliance scanners produce voluminous CVE reports but don't map findings to Safeguards at the IG-cumulative level. NSAuditor's wedge is the bridge — deep cloud + network scanning + CIS v8 per-Safeguard-mapped output + same Zero Data Exfiltration architecture used for the five companion frameworks.
Why per-Safeguard-level mapping
CIS Controls v8 has a 2-level hierarchy:
Control (18 — e.g., Control 3 Data Protection, Control 5 Account Management) — the top-level grouping.
Safeguard (153 — e.g., 3.3 Configure Data Access Control Lists, 5.4 Restrict Administrator Privileges, 11.4 Establish an Isolated Instance of Recovery Data) — the atomic, attestable unit each Implementation Group is defined over.
Self-attestation (CSAT / CIS-CAT Pro), SOC 2 auditor CIS cross-validation, and cyber-insurance underwriters all consume coverage at the SAFEGUARD level. Claiming "Control 4 covered" when only 3 of Control 4's 12 Safeguards are evidenced is auditor-detectable overclaim — Control-level roll-up is derived (e.g., "Control 4: 3 of 12 Safeguards evidenced"), never asserted as PASS.
NSAuditor maps at the per-Safeguard level. Per-Safeguard fields in data/compliance/cis-v8.json:
Field
Type
Purpose
safeguardId
string
Safeguard ID in canonical CIS form: N.M (e.g., 3.3, 11.4); N = Control 1-18.
controlNumber / controlTitle
int / string
Parent Control (1-18) + title (e.g., 3 / "Data Protection").
implementationGroup
enum
Smallest-IG-membership: IG1 / IG2 / IG3 — the FIRST IG that includes this Safeguard. Drives the IG-cumulative coverage summary.
securityFunction
enum
One of identify / protect / detect / respond / recover — 5 Functions (NOT 6 like NIST CSF 2.0; no Govern).
assetType
enum
One of devices / software / data / users / network / applications — the 6 CIS v8 asset types.
The 11 load-bearing schema enrichments defend against the 16 ship-blocker classes identified in pre-authoring review — the CIS Controls v8 Implementation-Group lens plus the five companion-framework perspectives (SOC 2, HIPAA, NIST CSF 2.0, PCI DSS v4.0.1, ISO/IEC 27001:2022), all applied before the mapping was written. That review pass found 0 ship-blockers. Every titlePattern inherits from soc2.json's grep-verified set; where no pattern matches a Safeguard, it is marked OOS (no fabricated patterns).
Implementation Group cumulative discipline
The Implementation Groups are cumulative — this is THE central institutional mechanism of CIS Controls v8, the lens cyber-insurance underwriters + CIS-CAT self-attestation + CIS-SecureSuite peer reviewers all consume IG claims through:
Cumulative means: claiming "we're IG2" = ALL 56 IG1 Safeguards AND ALL 74 IG2-only = 130 total (NEVER 74-of-74 in isolation). Claiming "we're IG3" = ALL 130 IG2-cumulative AND ALL 23 IG3-only = 153 total. The IG1 base MUST be intact before any IG2/IG3 claim is valid — operators who skip IG1 Safeguards while pursuing IG2/IG3 depth are NOT IG2/IG3 compliant (cyber-insurance underwriters reject the claim + re-classify as incomplete IG1, potentially declining or limiting coverage).
SMB, limited IT/security expertise; untargeted-attack threat model
IG2 — Foundational Cyber Hygiene (cumulative)
130
38 (29%)
Mid-market, dedicated security team, regulatory exposure; targeted-attack threat model
IG3 — Organizational Cyber Hygiene (cumulative)
153
40 (26%)
Large org, critical infrastructure, mature program; nation-state APT threat model
The engine substrate covers a SUBSET of each IG. The remaining Safeguards are operator-side process/endpoint artifacts (security-awareness LMS training, endpoint EDR, incident-response program, third-party-risk management) that pair with your CSAT / CIS-CAT Pro self-attestation. This report is INPUT to that attestation — for each covered/partial Safeguard, your self-attestation cites this report as documentation evidence; for the operator-side remainder, your self-attestation cites your LMS / EDR / IR / TPRM platform evidence.
No-certification-body attestation discipline
CIS Controls v8 has no formal certification body (unlike ISO 27001's ISO/IEC 17021-1 accredited bodies or PCI's QSAs). This report is INPUT to one of 3 operator-side validation paths — never a "CIS certification":
Validation path
What it is
When to use
1. Self-attestation
CSAT (CIS Controls Self Assessment Tool — lighter-weight) or CIS-CAT Pro Assessor (benchmark-automated, more rigorous)
Most operators; cyber-insurance renewal; customer security questionnaires
2. SOC 2 auditor cross-validation
SOC 2 Type II auditor folds CIS Controls scope into the SOC 2 evidence package (CC6/CC7/CC8 substrate)
Operators already pursuing SOC 2 — most common path
3. CIS-SecureSuite peer review
Informal community validation from comparable-organization members
CIS-SecureSuite members seeking community baseline
Never represent this report as "CIS certified" or "CIS Controls certification" — there is no such certification. Represent it as "substrate evidence supporting CIS Controls v8 IG[N] self-attestation." Overclaiming certification is the textbook CIS-canonical misrepresentation.
Coverage matrix by Control
Source of truth is data/compliance/cis-v8.json; this matrix mirrors it. The anchor-drift defense test asserts every (source, titlePattern) pair in cis-v8.json exists in soc2.json (inheritance contract — closes the silent false-CLEAN class at the CIS mapping layer, parallel to the HIPAA + NIST CSF + PCI DSS + ISO 27001 inheritance defenses).
Control
Safeguards
Covered
Partial
OOS
1 Inventory Enterprise Assets
5
0
1
4
2 Inventory Software Assets
7
1
1
5
3 Data Protection
14
3
4
7
4 Secure Configuration
12
1
5
6
5 Account Management
6
2
1
3
6 Access Control Management
8
2
0
6
7 Continuous Vulnerability Mgmt
7
2
0
5
8 Audit Log Management
12
1
4
7
9 Email & Web Browser Protections
7
0
1
6
10 Malware Defenses
7
0
0
7
11 Data Recovery
5
3
2
0
12 Network Infrastructure Mgmt
8
1
1
6
13 Network Monitoring & Defense
11
1
2
8
14 Security Awareness Training
9
0
0
9
15 Service Provider Management
7
0
0
7
16 Application Software Security
14
0
1
13
17 Incident Response Management
9
0
0
9
18 Penetration Testing
5
0
0
5
TOTAL
153
17
23
113
Conservative-MVP density: substrate-evidenceable Safeguards concentrate in Controls 1-8 + 11-13 + 16 (cloud-API-enumerable). Controls 10 + 14 + 15 + 17 + 18 are entirely operator-side (endpoint / LMS / IR / TPRM / pentest). Safeguard 9.5 (Implement DMARC) is partial off the SES DMARC posture (policy strength + SPF/DKIM alignment).
Hepta-framework: SOC 2 + HIPAA + NIST CSF + PCI DSS + ISO 27001 + CIS v8 + GDPR Art. 32 in one scan
The engine is framework-agnostic — single scan, seven compliance reports, zero duplicate scanning effort (GDPR is Article 32 infrastructure substrate — security of processing — not GDPR compliance):
Implementation Group Coverage Summary — IG1 / IG2-cumulative / IG3-cumulative engine-substrate table with cyber-insurance-baseline framing (the central CIS cover-page section)
Attestation-discipline disclaimer — explicit "no certification body; INPUT to CSAT / CIS-CAT Pro" prompt
Trusted timestamping (RFC 3161) is opt-in as of EE 0.33.0 — set NSAUDITOR_TSA_URL to a Time-Stamp Authority you choose and each artifact gets a .tsr sidecar your auditor verifies offline with openssl ts -verify. Opt-in with no default, ever: a baked-in default would be third-party egress nobody asked for. Verified against a real authority on 2026-08-07 — Status Granted, Verification: OK, and a one-byte change to the artifact flips it to FAILED.
Markdown + HTML + JSON outputs — self-attestation-friendly markdown + browser-viewable HTML + machine-readable JSON
Covered Safeguards (17)
Strongest substrate match — engine evidences the implemented control state:
2.2 Ensure Authorized Software is Currently Supported IG1 — EOL / deprecated-runtime / CVE detection
3.3 Configure Data Access Control Lists IG1 — public-bucket / public-blob / allUsers detection
3.10 Encrypt Sensitive Data in Transit IG2 — TLS policy + RDS SSL + SecureTransport + HSTS
3.11 Encrypt Sensitive Data at Rest IG2 — default-encryption + RDS/SQS/SNS at-rest encryption
4.4 Implement and Manage a Firewall on Servers IG1 — Security Group / firewall public-ingress detection
5.1 Establish and Maintain an Inventory of Accounts IG1 — IAM / RBAC principal enumeration
Live detection (AMI-ID / image-publisher = center-for-internet-security-inc / image-project = cis-public / container-label org.cis.benchmark.profile) is LIVE — plugin 1210 (AWS) + the Azure/GCP image-inventory producers feed the detector, and the renderer flips cisHardenedImageCredit from eligible → observed (with a per-cloud inspected-vs-hardened fraction + point-in-time / configuration-drift caveat) when a CIS-Hardened-Image is found. Conservative — a cloud Marketplace owner/alias alone never grants credit; a CIS-specific signal is required.
Sector baselines — MS-ISAC / EI-ISAC / H-ISAC
The Cloud Companion Guide v8 cross-references sector-specific baseline requirements; each Safeguard carries sectorBaselineApplicability:
CIS Controls v8 uses 5 Security Functions — Identify / Protect / Detect / Respond / Recover. NOT 6 like NIST CSF 2.0: NIST added Govern as a 6th Function in 2024, but CIS Controls v8 (published May 2021) retains the original 5-function model. The engine's per-Safeguard securityFunction field strictly rejects govern; a schema-level test asserts no Govern value leaks into the CIS securityFunction attribute (defending against cross-framework drift from the NIST CSF engine).
Each Safeguard also applies to one of 6 Asset Types — Devices / Software / Data / Users / Network / Applications. Engine substrate is strongest for Devices / Software / Data / Network (cloud-API-enumerable); weakest for Users (partial — IAM principals only) and operator-process Safeguards (OOS).
v7.1-to-v8 transition discipline
CIS v7.1 had 20 Controls + 171 Sub-Controls; v8 consolidated to 18 Controls + 153 Safeguards ("Sub-Controls" renamed to "Safeguards"). Each covered/partial Safeguard carries a v71Source field for migration cross-reference.
Migration pitfalls:
Control numbering changed (20 → 18) — Controls 19 (Incident Response) + 20 (Penetration Tests) folded into v8 Controls 17 + 18; v7.1 Control 19/20 IDs are stale and rejected at the schema layer.
Some Sub-Controls merged; terminology renamed Sub-Control → Safeguard.
5 brand-new Safeguards added in v8 (no v7.1 source).
~20 Sub-Controls changed IG assignment across versions — re-verify your IG scoping.
For the comprehensive v7.1-to-v8 mapping table, refer to CIS's published CIS Controls v7.1 to v8 Mapping document.
Cyber-insurance IG1 baseline
~50-70% of mid-market cyber-insurance policies require IG1 attestation as a coverage prerequisite (as of 2024+). IG1 is the "essential cyber hygiene" baseline. The engine evidences 23 of the 56 IG1 Safeguards via infrastructure scanning; the remaining 33 are operator-side (unique-passwords / IdP policy, endpoint encryption / MDM, security-awareness LMS, access-granting/revoking process, IR designation).
IG1 gaps are commercial-impact findings — potential coverage-invalidation, not just compliance findings. Verify the full IG1 base (engine substrate + operator-side process artifacts) is intact BEFORE submitting a cyber-insurance attestation. Underwriters commonly ask: "Show me your IG1 attestation" (must be 100% 56/56 for most policies); "How many IG1 Safeguards are in-progress vs covered?" (in-progress count as gaps for coverage-prerequisite purposes); "What's your remediation timeline for IG1 gaps?" (90-day or 180-day plan with named owner expected).
Zero Data Exfiltration — operator-controlled boundary
NSAuditor AI EE inherits the same Zero Data Exfiltration architecture across all 6 supported frameworks:
Local-only scanning — no scan data leaves the operator's environment; no SaaS dependency
Local-only AI — Claude API integration is OPTIONAL (operator-configured); air-gapped fallback for federal-contractor + classified-data scope
Operator-controlled signing — suppression approval and scope attestation operator-side
This architecture matters for CIS Controls v8 because Control 3 Data Protection + Control 15 Service Provider Management scrutinize where sensitive data flows — a SaaS compliance tool that ingests scan data into a third-party cloud environment introduces a new service provider per Control 15 that the operator must inventory, classify, assess, and monitor (Safeguards 15.1-15.6). Zero Data Exfiltration sidesteps that service-provider expansion entirely.
Positioning: NSAuditor + CIS-aware GRC platform (or CIS-CAT Pro) = full CIS Controls v8 coverage. NSAuditor handles the cloud-infrastructure substrate-evidence dimension where it's strongest (per-Safeguard technical configuration across AWS / Azure / GCP + hash-chained evidence + IG-cumulative framing); the GRC platform / CIS-CAT handles host-level benchmark assessment + the self-attestation workflow + the operator-side process Safeguards (awareness training, IR, TPRM). The bundle is institutionally complete; each tool standalone leaves gaps the other fills.
CIS Controls auditor FAQ
Is this report a CIS certification?
No. CIS Controls v8 has no formal certification body. This report is INPUT to one of 3 operator-side validation paths: (1) self-attestation via CSAT or CIS-CAT Pro Assessor; (2) a SOC 2 Type II auditor cross-validating CIS scope; (3) CIS-SecureSuite peer review. Represent it as "substrate evidence supporting CIS Controls v8 IG[N] self-attestation."
Does NSAuditor map at the Control or per-Safeguard level?
Per-Safeguard — the atomic, attestable unit. 18 Controls decompose into 153 Safeguards; coverage is claimed at the SAFEGUARD level (3.3, 5.4, 11.4). Control-level roll-up is derived ("Control 4: 3 of 12 Safeguards evidenced"), never asserted as PASS.
What does "IG2 cumulative = 130" mean?
The Implementation Groups are cumulative. Claiming IG2 means ALL 56 IG1 Safeguards AND ALL 74 IG2-only = 130 total — never 74-of-74 in isolation. The IG1 base must be intact before any IG2/IG3 claim. Operators who skip IG1 while pursuing IG2/IG3 depth are NOT IG2/IG3 compliant — cyber-insurance underwriters re-classify them as incomplete IG1.
Why does CIS v8 have 5 Security Functions and not 6 like NIST CSF 2.0?
CIS Controls v8 (published May 2021) retains the original 5 Functions (Identify / Protect / Detect / Respond / Recover). NIST CSF 2.0 added Govern as a 6th Function in 2024 — but that's NIST CSF, not CIS. The engine's securityFunction field rejects govern; a schema-level test asserts no Govern value leaks into the CIS attribute.
We run CIS-Hardened-Images. Do we earn substrate-evidence credit?
Yes — for Safeguards 4.1, 4.2 (partial), and 4.6. Operators running CIS-Hardened-Images from AWS / Azure / GCP Marketplace or Docker Hub earn substantial substrate-evidence credit. The cisHardenedImageCredit field surfaces this. Live detection across AWS / Azure / GCP is LIVE (plugin 1210 + Azure/GCP image-inventory producers) — the renderer flips the credit from eligible → observed when a Hardened-Image is detected, with a point-in-time caveat. A Marketplace owner/alias alone never grants credit.
How does IG1 coverage affect our cyber-insurance?
~50-70% of mid-market cyber-insurance policies require IG1 attestation as a coverage prerequisite (2024+). The engine evidences 23 of 56 IG1 Safeguards; the remaining 33 are operator-side. IG1 gaps are commercial-impact findings — potential coverage-invalidation. Verify the full IG1 base is intact before submitting a cyber-insurance attestation.
We're on CIS v7.1. How do we migrate to v8?
v7.1 had 20 Controls + 171 Sub-Controls; v8 has 18 Controls + 153 Safeguards. Each covered/partial Safeguard carries a v71Source field. Pitfalls: Controls 19/20 are v7.1-stale (rejected at schema layer); some Sub-Controls merged; 5 brand-new Safeguards in v8; ~20 changed IG assignment. Refer to CIS's published "CIS Controls v7.1 to v8 Mapping" document.
Can NSAuditor evidence Control 14 (Security Awareness Training), Control 17 (Incident Response), or Control 18 (Penetration Testing)?
No — these are entirely operator-side and OOS-by-design for any infrastructure scanner. Control 14 = LMS (KnowBe4 / Proofpoint / SANS); Control 17 = IR program (pair with SOAR — TheHive / Cortex XSOAR / Splunk SOAR); Control 18 = independent pentest engagement. The engine enumerates these as OOS with named operator-side platform pairings so your self-attestation knows exactly what to attach.
What's the difference between the engine substrate and a full IG attestation?
The engine substrate-evidences the cloud-infrastructure-observable Safeguards within each IG (IG1 23/56, IG2-cumulative 38/130, IG3-cumulative 40/153). A full IG attestation also requires the operator-side process/endpoint Safeguards (training, EDR, IR, TPRM) that infrastructure scanning fundamentally cannot observe. Pair the engine substrate with your CSAT / CIS-CAT Pro self-attestation for the complete IG picture.