ISO/IEC 27001:2022 evidence at the per-Annex-A-code level — the way ISO Lead Auditors actually walk Stage 2.
NSAuditor AI EE generates ISO/IEC 27001:2022 (October 2022; 2013 edition retired October 31, 2025) pre-audit gap reports mapped at the auditor-canonical per-Annex-A-code level. SHA-256 chain-of-custody sidecars, cover-page Scope Attestation, suppression workflow, honest OOS framing on ISMS Clauses 4-10 (entire Management System — Information Security Policy, risk treatment plan, internal audit, management review — all operator-side) — and Zero Data Exfiltration, so ISMS-scoped customers can scan inside their own boundary without sending sensitive infrastructure data to a third-party SaaS scanner.
✓ 17 Annex A controls covered⚠ 14 partial⊘ 62 explicit OOS⚡ ISMS Clauses 4-10 OOS-by-designLatest: 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
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.
Zero Data Exfiltration, rebuilt as a positive register — the claim used to be a denial; it is now an enumeration of 17 outbound paths, each named with what triggers it and how to switch it off. For an A.5.23 (cloud services) or A.8.21 (network services security) review that is the difference between an assertion and evidence. RFC 3161 trusted timestamping is now opt-in via NSAUDITOR_TSA_URL and was verified against a real timestamp authority on 2026-08-07 — opt-in, not a default, and itself one of those outbound paths. Ed25519 suppression signing is reachable and not yet proven — compliance suppress signs the approval it writes when NSAUDITOR_SIGNING_KEY names a local signing key, and its verification gate has not run against published bytes, so no surface here presents a produced signature as verified evidence. Signature records now carry algorithm and backend frozen at the moment of signing rather than re-derived later.
Matrix-neutral — all seven coverage matrices UNCHANGED and the plugin count UNCHANGED at 28 Enterprise plugins (27 of them cloud auditors), 55 overall. This ISO/IEC 27001:2022 matrix is UNCHANGED at 17 covered / 14 partial / 62 OOS. Paired CE 0.2.37 + agent-skill 0.2.35.
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.8.8 (management of technical vulnerabilities) is a control an ISO/IEC 17021-1 assessor tests on the operator’s tooling as well as their estate, and this is the register it belongs in: a gate reading the wrong tree does not produce an obviously wrong number, it produces a number that reads exactly like the right one.
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. This ISO/IEC 27001:2022 matrix was UNCHANGED at 17 covered / 14 partial / 62 OOS. Paired CE 0.2.35 + agent-skill 0.2.33.
Prior release: internal engineering identifiers stripped from the evidence pack, and a cloud that could not be scanned no longer reads CLEAN
Prior: EE 0.32.9 (2026-07-29) — an internal-provenance strip plus a false-clean closure. A compliance report is a document a customer hands their certification body assessor, 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 control of a cloud that could not be scanned carries a fail-closed evidence gap — which is exactly the state a Stage 2 assessor needs to see, because an unscannable cloud is an unevidenced control, not a conformant one.
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. Paired CE 0.2.34 + agent-skill 0.2.32.
Earlier in the 0.32.x line: cross-framework routing — the network-scan analysis agents' findings now route in all seven compliance frameworks, not just SOC 2 (ISO/IEC 27001:2022 now among them), plus a capability-claim honesty pass
Cross-framework routing — the network-scan analysis agents' findings now route in all seven compliance frameworks, not just SOC 2 — a host serving cleartext transport (no TLS where encryption is expected) or exposing SMB used to FAIL the SOC 2 report while reading perfectly CLEAN in HIPAA / NIST CSF / ISO/IEC 27001:2022 / CIS Controls v8 / PCI DSS / GDPR Art. 32 off the SAME scan. That single-framework blind spot is closed: 48 mapping rules now carry each network-scan finding (cleartext transport, SMB-alone exposure, WinRM 5985/5986, Elasticsearch transport 9300, MSRPC 135, and an aggregate open-port-count signal) to every framework that maps its control subject — adjudicated per framework (24 cells left justified-unrouted where no control applies) behind a mutation-proven over-routing guard. These signals live on the EE analysis agents that read network-scan results, not the cloud-scan / scan_cloud path.
ISO/IEC 27001:2022 now receives these findings where the control subject matches — cleartext transport → A.8.24 Use of cryptography; secure-authentication exposure → A.8.5 Secure authentication; network-exposure signals → A.8.20 Networks security. This is a ROUTING fold, not new coverage: those Annex A codes were already COVERED substrate, and this coverage matrix is UNCHANGED at 17 / 14 / 62.
Capability-claim honesty pass — a company-wide sweep withdrew six capabilities WITHDRAWN for having no shipping implementation (automated vulnerability verification, per-scan Docker isolation, a ZDE policy engine, a PostgreSQL/query-API CTEM backend, branded/custom-logo reports, and usage metering) from every advertised surface. The real cores stand: risk-scored prioritization + the operator suppression workflow; the Zero Data Exfiltration read-only-credential + hardcoded egress-redaction guarantee; unlimited JSONL scan-history retention with delta detection + webhook alerting; and compliance reports in HTML / JSON / Markdown + print-to-PDF.
Per-Annex-A-code mapping at 17 covered + 14 partial + 62 OOS = 93 — the complete Annex A universe across 4 themes (A.5 Organizational 37 + A.6 People 8 + A.7 Physical 14 + A.8 Technological 34). Auditor-canonical citation unit per ISO/IEC 17021-1 certification body assessors walking Stage 1 (documentation) / Stage 2 (implementation) / annual surveillance / 3-year recertification.
Statement of Applicability (SoA) per Clause 6.1.3.d discipline — every control carries soaApplicability field (always-applicable / risk-based-applicable / excludable-with-justification). Renderer surfaces SoA-pairing prompt near cover page — engine produces substrate for INCLUDED controls; the SoA inclusion/exclusion decisions are operator-side. Stage 1 assessors review the SoA FIRST before any technical evidence.
ISMS management-system Clauses 4-10 OOS-by-design — Context (Clause 4) + Leadership (5) + Planning (6) + Support (7) + Operation (8) + Performance Evaluation (9) + Improvement (10) entirely operator-side. Schema invariant rejects Clause-format keys. The 7 Major Nonconformity classes enumerated in renderer cover-page disclaimer (any one = auto-fail Stage 2): missing Information Security Policy / risk assessment / risk treatment plan / SoA / internal audit / management review / documented information.
11 NEW 2022 controls explicitly addressed — A.5.7 Threat intelligence · A.5.23 Cloud services · A.5.30 ICT readiness for BC · A.7.4 Physical security monitoring · A.8.9 Configuration management · A.8.10 Information deletion · A.8.11 Data masking · A.8.12 DLP · A.8.16 Monitoring activities · A.8.23 Web filtering · A.8.28 Secure coding. Distribution: 3 COVERED + 2 PARTIAL + 6 OOS with named operator-side platform pairings.
5-attribute taxonomy per Annex A control (NEW in 2022 edition) — controlType (preventive/detective/corrective) · informationSecurityProperties (C/I/A) · cybersecurityConcepts (identify/protect/detect/respond/recover — 5 categories, NOT 6 like NIST CSF 2.0) · operationalCapabilities (15 named) · securityDomains (4 named: Governance_and_ecosystem, Protection, Defence, Resilience).
2013-to-2022 transition discipline — transition deadline passed October 31, 2025; all active certificates must now be 2022 edition. Per-control iso2013Source field documents migration mapping (35 unchanged + 23 renamed + 57 merged-into-24 + 11 NEW = 93). Schema validation rejects 2013-edition Annex A codes.
No new framework; matrix-neutral — 28 plugins and all seven coverage matrices UNCHANGED. This ISO/IEC 27001:2022 coverage matrix is UNCHANGED at 17/14/62 — a matrix-neutral cross-framework routing fold (network-scan findings now reach ISO 27001 where the control subject matches, adjudicated per framework) with zero ISO coverage change here. Regression 9,280 pass / 0 fail.
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. This ISO/IEC 27001:2022 matrix is UNCHANGED at 17 covered / 14 partial / 62 OOS. 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. 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.
ISO/IEC 27001:2022 published October 25, 2022 by ISO + IEC; supersedes ISO/IEC 27001:2013 (transition deadline October 31, 2025 passed). Structure: 7 management-system Clauses (Clauses 4-10) + 93 Annex A controls across 4 themes. Most-requested next framework after SOC 2 + HIPAA + NIST CSF 2.0 + PCI DSS v4.0.1 for EU + financial services + healthcare + global enterprise operators. NSAuditor's engine is framework-agnostic — see the SOC 2 coverage matrix, HIPAA §164.312 coverage matrix, NIST CSF 2.0 coverage matrix, PCI DSS v4.0.1 coverage matrix, and CIS Critical Security Controls v8 coverage matrix for the companion frameworks.
NSAuditor AI EE generates ISO/IEC 27001:2022 per-Annex-A-code-level evidence — at the same institutional grade as SOC 2, HIPAA, NIST CSF 2.0, and PCI DSS.
It maps cloud infrastructure findings (AWS, Azure, GCP) and network scan results to specific Annex A codes (A.5.15, A.8.5, A.8.24, etc.), produces hash-chained evidence artifacts (cover-page Scope Attestation, SHA-256 chain-of-custody sidecars, and a documented suppression workflow), and ships ISO 27001 reports in machine-readable form suitable for ISO-aware GRC platform ingestion + ISO/IEC 17021-1 certification body assessor workflow.
It is not a Statement of Applicability (SoA per Clause 6.1.3.d is operator-side). It is not an ISMS management-system audit (Clauses 4-10 entirely OOS; engine produces zero substrate). It is not an internal audit per Clause 9.2 (MANDATORY operator-side; independence requirement). It is not a management review per Clause 9.3 (MANDATORY operator-side; top management). It is not a risk treatment plan (Clause 6.1.3 operator-side methodology + register). It is not a complete ISO 27001:2022 attestation (93 Annex A controls total; engine evidences 31 at MVP density).
What it IS: the per-Annex-A-code technical-evidence layer covering A.5.15-A.5.18 identity + access + cryptography substrate, A.5.23 cloud services NEW 2022 substrate, A.5.28 evidence collection (CloudTrail), A.5.33-A.5.34 records protection + PII substrate, A.5.36 compliance monitoring (Config drift), A.8.2-A.8.5 privileged access + secure auth, A.8.8 vulnerability management (CVE pipeline), A.8.9 configuration management NEW 2022 (Config recorder substrate), A.8.13 backup (AWS Backup substrate), A.8.15 logging (CloudTrail substrate), A.8.16 monitoring NEW 2022 (GuardDuty substrate), A.8.20-A.8.22 network security + segregation, A.8.24 use of cryptography (KMS substrate) — complete and assessor-ready. Compatible with operator-side ISO 27001 SoA preparation, internal audit program execution, management review cycle, and accredited certification body (BSI, DNV, BVQI, Schellman, Coalfire, A-LIGN, TÜV, SGS) Stage 1 + Stage 2 + annual surveillance workflow. Honest about what infrastructure scanning fundamentally cannot evidence (ISMS Clauses 4-10, internal audit execution, management review, risk treatment methodology) — saves you from the textbook ISO-canonical overclaim findings.
The market split: ISO-aware GRC platforms (Drata ISO 27001, Vanta ISO 27001, AuditBoard, OneTrust ISMS, Secureframe ISO 27001) automate SoA workflow + ISMS Clauses 4-10 + risk register + internal audit + management review + supplier risk management but lack deep cloud-infrastructure scanning at the per-Annex-A-code-evidence level. Legacy compliance scanners produce voluminous CVE reports but don't map findings to Annex A controls at the auditor-canonical per-code level. NSAuditor's wedge is the bridge — deep cloud + network scanning + ISO 27001:2022 per-Annex-A-code-mapped output + same Zero Data Exfiltration architecture used for SOC 2 + HIPAA + NIST CSF + PCI DSS (sensitive data never leaves customer infrastructure; air-gapped operation for operator threat models requiring controlled boundary per Clause 4.3 ISMS scope).
Why per-Annex-A-code-level mapping
ISO/IEC 27001:2022 Annex A has a 2-level hierarchy:
Theme (4 — A.5 Organizational, A.6 People, A.7 Physical, A.8 Technological) — the top-level navigational grouping; reorganized from the 2013 edition's 14 categories.
Annex A code (93 — e.g., A.5.15 Access control, A.8.5 Secure authentication, A.8.24 Use of cryptography) — the per-control granularity ISO/IEC 17021-1 certification body assessors attach evidence to during Stage 2 + surveillance.
ISO Lead Auditors walk Stage 2 + annual surveillance per-Annex-A-code against the operator's Statement of Applicability inclusions. Auditor-canonical evidence is per-Annex-A-code. Theme-level claims (e.g., "we cover A.8 Technological") don't survive institutional ISO Lead Auditor review — A.8 alone spans 34 controls; the assessor will ask which specific Annex A codes with what evidence.
NSAuditor maps at the per-Annex-A-code level. Per-control fields in data/compliance/iso-27001.json:
Field
Type
Purpose
id
string
Annex A code in canonical ISO form: A.X.Y (e.g., A.5.15, A.8.9).
theme
enum
One of A.5 Organizational / A.6 People / A.7 Physical / A.8 Technological — the parent theme group.
annexACode
string
Full Annex A code (regex-validated ^A\.[5-8]\.[0-9]{1,2}$).
controlObjective
string
ISO/IEC 27002:2022 implementation-guidance outcome statement (the auditor-citation-source-of-truth).
soaApplicability
enum
Either always-applicable, risk-based-applicable, or excludable-with-justification — per-control SoA-pairing discipline gating inclusion decision per Clause 6.1.3.d.
isoEdition
string
Always "2022" (the only active edition since transition deadline passed October 31, 2025); 2013-edition codes rejected at schema layer.
iso2013Source
string|null
2013-edition Annex A source code(s) for migration cross-reference; null for the 11 NEW 2022 controls.
attributes.controlType
enum[]
Array containing preventive, detective, and/or corrective — 5-attribute taxonomy NEW in 2022.
attributes.informationSecurityProperties
enum[]
Array of confidentiality / integrity / availability — CIA properties.
attributes.cybersecurityConcepts
enum[]
Array of identify / protect / detect / respond / recover — 5 categories (NOT 6 like NIST CSF 2.0).
attributes.operationalCapabilities
enum[]
Array of 15 named values (Governance, Asset_management, Information_protection, etc.).
attributes.securityDomains
enum[]
Array of Governance_and_ecosystem / Protection / Defence / Resilience (4 domains per ISO/IEC TS 27110).
cloudProviderAttestation
object
Per-cloud-provider ISO 27001:2022 Certificate reference: {aws, azure, gcp}. Cited names current as of 2026-Q1. Annual currency-review cadence institutionalized.
The 6 load-bearing schema enrichments (theme + annexACode + controlObjective + soaApplicability + isoEdition + iso2013Source) + the 5-attribute taxonomy + cloudProviderAttestation defend against 17 ship-blocker classes identified in pre-authoring review — the ISO/IEC 27001:2022 Statement-of-Applicability lens plus the SOC 2 evidence-sufficiency, HIPAA OCR, NIST CSF 2.0 Implementation-Tier and PCI DSS QSA perspectives, all applied before the mapping was written. A schema-additive-fields propagation test enforces these fields reach the rendered report.
Statement of Applicability discipline (Clause 6.1.3.d)
The Statement of Applicability per Clause 6.1.3.d is THE central artifact of an ISMS conformant to ISO/IEC 27001:2022. For each of the 93 Annex A controls, the operator's SoA documents:
Control reference — the Annex A code (e.g., A.5.15) + the control title from ISO/IEC 27001:2022 Annex A
Inclusion or exclusion decision — "Included" or "Excluded"
Justification — anchored to the operator's risk assessment per Clause 6.1.2, legal/regulatory/contractual requirements per Clause 4.2 + A.5.31, and ISMS scope statement per Clause 4.3
Implementation status — Planned / In progress / Implemented / Not applicable
Reference to documentation — pointer to policies / procedures / runbooks / technical configuration evidence
Stage 1 certification body assessors review the SoA FIRST — before any technical evidence. The SoA must address every Annex A control; exclusions need particularly strong justification.
How NSAuditor pairs with the SoA
NSAuditor output
SoA pairing per Clause 6.1.3.d
Covered control (e.g., A.5.15: covered)
SoA shows control as Included, implementation status = Implemented, with this report as documentation reference
Partial control (e.g., A.5.17: partial)
SoA shows control as Included, implementation status = In progress, with documented remediation plan
SoA shows control as Excluded with justification "operator uses [AWS / Azure / GCP] shared-responsibility model; [Provider] ISO 27001:2022 Certificate covers physical perimeter"
SoA discipline checklist: Completeness (all 93 controls addressed; no skips) · Justification quality (exclusions particularly scrutinized) · Internal consistency (risk register → risk treatment decisions per Clause 6.1.3 → SoA inclusions) · Edition currency (2022 codes, not 2013) · 11 NEW controls each explicitly addressed · Documentation traceability (implementation references producible on demand). If the SoA fails Stage 1, Stage 2 does NOT proceed — operator must remediate before scheduling Stage 2.
ISMS Clauses 4-10 — OOS-by-design
ISO/IEC 27001:2022 certification requires BOTH dimensions:
Annex A control implementation (93 controls — engine produces substrate per this report)
ISMS management-system Clauses 4-10 (operator-side processes — OOS-by-design for any infrastructure scanner)
This report evidences (1) only. For (2), pair with your GRC platform.
Corrective-action records + continual-improvement log
CAPA system + GRC continual-improvement tracking
The 7 Major Nonconformity classes (any one = auto-fail Stage 2)
No Information Security Policy (Clause 5.2) — operator has no board-approved policy
No risk assessment process (Clause 6.1.2) — operator has no documented methodology
No risk treatment plan (Clause 6.1.3) — operator has not produced one
No Statement of Applicability (Clause 6.1.3.d) — operator has not produced the SoA
No internal audit program (Clause 9.2) — operator has never conducted an internal audit
No management review (Clause 9.3) — operator's top management has never formally reviewed the ISMS
No documented information (Clause 7.5) — operator's policies/procedures are undocumented or unmaintained
These 7 classes account for the majority of first-time Stage 2 failures. Verify operator-side artifacts BEFORE scheduling Stage 2 audit with your accredited certification body.
Coverage matrix by theme
Source of truth is data/compliance/iso-27001.json; this matrix mirrors it. The anchor-drift defense test asserts every (source, titlePattern) pair in iso-27001.json exists in soc2.json (inheritance contract — closes the silent false-CLEAN class at the ISO 27001 mapping layer, parallel to HIPAA + NIST CSF + PCI DSS inheritance defenses).
Theme
Total
Covered
Partial
OOS
Notes
A.5 Organizational
37
5
9
23
Strong fit on identity + access + cryptography substrate. Heavy OOS on policy / governance / TPRM / IR (operator-side).
A.6 People
8
0
0
8
Entirely OOS — workforce-lifecycle dimensions. Pair with HR system + LMS + endpoint-management.
A.7 Physical
14
0
0
14
Entirely OOS — facility-tier. Cloud-hosted operators inherit from cloud-provider ISO 27001:2022 Certificate.
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 — assessor-friendly markdown + browser-viewable HTML + machine-readable JSON
Covered Annex A controls (17)
Strongest substrate match — engine evidences full implementation:
A.5 Organizational (5)
A.5.15 Access control — IAM substrate (SSH password auth, exposed admin panels, no-MFA detection)
22 of 93 Annex A controls = entirely OOS for cloud-hosted operators. Theme A.6 People (8 controls) is workforce-lifecycle; Theme A.7 Physical (14 controls) is facility-tier. For cloud-hosted operators, A.7 is inheritable from cloud-provider's ISO 27001:2022 Certificate via shared-responsibility model.
Pattern: 3 covered (cloud-service-inherited or substrate-native) + 2 partial (substrate + operator completion) + 6 OOS (process-driven or operator-side platform-required). Each NEW control must be explicitly addressed in operator's SoA — silent omission is a freshness-signal failure.
2013-to-2022 transition discipline
Transition deadline passed October 31, 2025. All active ISO 27001 certificates must now be 2022 edition. 2013-edition SoAs are stale. Schema validation in data/compliance/iso-27001.json rejects 2013-edition Annex A codes (A.9.*, A.10.*, A.11.*, A.12.*, A.13.*, A.14.*, A.15.*, A.16.*, A.17.*, A.18.* prefixes).
Migration pattern: 35 unchanged + 23 renamed + 57 merged-into-24 + 11 NEW = 93 controls in 2022 (down from 114 in 2013). Zero controls deleted entirely from 2013 — but some 2013 controls' content distributed across multiple 2022 controls (operator must re-thread justifications).
Example merges (per the iso2013Source field on each control):
A.5.14 Information transfer = merge of 2013's A.13.2.1 + A.13.2.2 + A.13.2.3 + A.6.2.2 (4 separate controls collapsed to 1)
A.5.17 Authentication information = merge of 2013's A.9.2.4 + A.9.3.1 + A.9.4.3
A.5.18 Access rights = merge of 2013's A.9.2.2 + A.9.2.5 + A.9.2.6
A.5.31 Legal/statutory/regulatory/contractual requirements = merge of 2013's A.18.1.1 + A.18.1.5
Migration pitfalls: Re-categorization not just renaming (2013's 14 categories A.5-A.18 collapsed to 4 themes A.5-A.8); 57-into-24 merges may obscure operator's prior implementation; 11 NEW controls have no 2013 source. For comprehensive 2013-to-2022 mapping, refer to ISO/IEC 27002:2022 Annex B (the official mapping) or the transition guide published by accredited certification bodies (BSI / DNV / BVQI / Schellman / Coalfire / A-LIGN).
5-attribute taxonomy (NEW in 2022 edition)
Each Annex A control in 2022 carries five attributes for assessor-style navigation:
Attribute
Values
Purpose
controlType
preventive / detective / corrective
What the control DOES with respect to security events
The renderer surfaces attribute-grouped views ("All preventive controls" / "All confidentiality-property controls") at per-Annex-A surface for assessor walkthroughs.
Pair with GRC platform — Stage 1 is operator-side documentation
Stage 2
1-3 months after Stage 1
Implementation + operating-effectiveness sampling
Engine substrate is PRIMARY evidence
Annual surveillance
Years 1 + 2
Sample of controls each year (typically 30-50%)
Engine substrate at appropriate cadence for control's operating frequency
Recertification
Year 3
Full re-audit
Engine evidence corpus across full 3-year window
Accredited certification bodies (ISO/IEC 17021-1): BSI, DNV, BVQI, Schellman, Coalfire, A-LIGN, TÜV, SGS, Lloyd's Register, NQA, Intertek, KPMG, EY. Pricing typically $15K-$50K for initial Stage 1 + Stage 2 (mid-market scope); $5K-$15K for annual surveillance. Cert body selection: prefer those with ISO 27001 specialization + your target customer-base familiarity (financial services → BSI / DNV; healthcare → Schellman / Coalfire; federal-contractor scope → A-LIGN / Schellman).
Cloud-provider ISO 27001:2022 Certificate inheritance
For cloud-hosted operators, Theme A.7 Physical (all 14 controls) is entirely inheritable from cloud-provider's ISO 27001:2022 Certificate via shared-responsibility model:
AWS ISO/IEC 27001:2022 Certificate (current as of 2026-Q1) — covers all A.7 controls for AWS-hosted resources
Microsoft Azure ISO/IEC 27001:2022 Certificate (current as of 2026-Q1) — covers all A.7 controls for Azure-hosted resources
Google Cloud Platform ISO/IEC 27001:2022 Certificate (current as of 2026-Q1) — covers all A.7 controls for GCP-hosted resources
Per-control cloudProviderAttestation field in data/compliance/iso-27001.json documents the per-cloud-provider Certificate reference. Cloud-provider Certificates are reissued on the provider's own 3-year cycle with annual surveillance — re-pull the current Certificate at every EE release cycle + every annual surveillance.
Zero Data Exfiltration — operator-controlled boundary per Clause 4.3 ISMS scope
NSAuditor AI EE inherits the same Zero Data Exfiltration architecture across all 5 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 is institutionally critical for ISO 27001:2022 because Clause 4.3 (ISMS scope) + Clause 5.2 (information security policy) require operator-controlled boundaries — a SaaS compliance tool that ingests scan data into a third-party cloud environment introduces a new TPSP per A.5.19-A.5.21 that operator's SoA must address. Zero Data Exfiltration sidesteps that TPSP expansion entirely.
Comparison vs the ISO 27001 market
Surface
NSAuditor AI EE
Drata / Vanta / Secureframe ISO 27001
AuditBoard / OneTrust ISMS
Annex A control coverage
17 covered + 14 partial = 31 substrate-evidenced
SoA workflow + checklist tracking
SoA workflow + GRC integration
Per-Annex-A-code-mapped findings
✅
Limited
Manual
Cloud infrastructure scanning depth
✅ (28 plugins across AWS / Azure / GCP / network)
Surface-level
None
Internal audit (Clause 9.2) workflow
OOS (operator-side)
✅
✅
Management review (Clause 9.3) workflow
OOS (operator-side)
✅
✅
Risk register (Clause 6.1.2)
OOS (operator-side)
✅
✅
Zero Data Exfiltration
✅
SaaS (data leaves operator env)
SaaS (data leaves operator env)
Positioning: NSAuditor + ISO-aware GRC platform = full ISO 27001:2022 coverage. NSAuditor handles the substrate-evidence dimension where it's strongest (per-Annex-A-code technical configuration + hash-chained evidence); GRC platform handles SoA + ISMS Clauses 4-10 + risk register + internal audit + management review workflow. The bundle is institutionally complete; each tool standalone leaves gaps the other fills.
ISO Lead Auditor FAQ
Does this report substitute for our Statement of Applicability?
No. The SoA per Clause 6.1.3.d is operator-side, maintained in your ISO-aware GRC platform. This report is INPUT to your SoA — for each covered/partial control, your SoA shows the control as Included with implementation status = Implemented/In progress + this report as documentation reference.
Does this report substitute for our internal audit per Clause 9.2?
No. Internal audits per Clause 9.2 are MANDATORY operator-side processes — must verify ISMS conforms to ISO 27001:2022 + the operator's own requirements + is effectively implemented and maintained. Cannot be performed by the same people who designed/implemented the ISMS (independence requirement). Absence = auto-fail Major Nonconformity.
Does this report substitute for our management review per Clause 9.3?
No. Management reviews per Clause 9.3 are MANDATORY — top management reviews the ISMS at planned intervals. Specific inputs + outputs required per the standard. Absence = auto-fail Major Nonconformity.
We're migrating from a 2013 certification. Can we use our existing SoA?
No. The 2013 edition transition deadline passed October 31, 2025. All active certificates must be 2022 edition. Use the iso2013Source field in data/compliance/iso-27001.json to map your 2013 controls to 2022 Annex A codes. Re-author your SoA against the 2022 Annex A before your next surveillance audit.
How do we address the 11 NEW 2022 controls in our SoA?
Each NEW control must be explicitly addressed (Included or Excluded with justification). 3 are substrate-evidenceable (A.5.23 cloud services, A.8.9 configuration management, A.8.16 monitoring activities — NSAuditor maps these); 2 are partial-substrate (A.8.10 information deletion, A.8.12 DLP); 6 are operator-side platform-required (A.5.7 threat intelligence, A.5.30 ICT readiness, A.7.4 physical security monitoring, A.8.11 data masking, A.8.23 web filtering, A.8.28 secure coding). See the per-control rows above for named operator-side platform pairings.
Why does the engine show 5 cybersecurity concepts and not 6 like NIST CSF 2.0?
ISO 27001:2022 retains the original 5 cybersecurity concepts (identify / protect / detect / respond / recover). NIST CSF 2.0 added Govern as the 6th category in 2024 — but ISO 27001:2022 was published in October 2022 and retains the original 5. The engine's per-control attributes.cybersecurityConcepts field reflects ISO 27001:2022 semantics; do not conflate with NIST CSF 2.0's 6 categories. A schema-level test asserts no 'govern' value leaks into the ISO 27001 cybersecurityConcepts attribute.
What's the difference between the engine's controlType and operating effectiveness?
controlType describes WHAT the control does (preventive = blocks events; detective = detects events; corrective = remediates after events). Operating effectiveness is WHETHER the control is operating correctly across the assessment window. NSAuditor evidences the CONFIGURATION substrate (i.e., the control is configured in a way that supports its type); operating effectiveness across the assessment window requires audit-log sampling + SIEM correlation that pair with engine substrate.
Our cloud provider has an ISO 27001:2022 Certificate. Can we exclude all A.7 Physical controls from our SoA?
Likely yes for cloud-hosted operators. The cloudProviderAttestation field references the cloud-provider Certificates (AWS / Azure / GCP). Your SoA shows A.7.* controls as Excluded with justification "operator uses [AWS / Azure / GCP] shared-responsibility model; [Provider]'s ISO 27001:2022 Certificate covers the physical layer." Provide the current [Provider] Certificate to your assessor at Stage 1.
What's the cadence for re-verifying cloud-provider Certificates?
Annually. Cloud-provider Certificates are reissued on the provider's own 3-year cycle with annual surveillance — re-pull the current Certificate at every EE release cycle + every annual surveillance.
What's the recommended approach for documenting evidence cadence for surveillance?
Schedule scans at cadence matching the control's operating frequency. For continuous-monitoring controls (A.8.16 Monitoring activities), monthly or weekly scans align to "continuous" semantics. For periodic-review controls (A.5.36 Compliance reviews), quarterly scans align. Operator's SoA documents the planned cadence; engine substrate evidences the executed cadence.
Does NSAuditor cover ISO/IEC 27001:2013?
No — explicitly only ISO/IEC 27001:2022. The 2013 edition transition deadline passed October 31, 2025. The version pin is enforced in data/compliance/iso-27001.jsonversion: "2022" and reflected in the rendered frameworkLabel. Schema validation rejects 2013-edition Annex A codes.