Noxen and ISO 27001:2022

ISO 27001 is the most rigorous of the three frameworks Noxen maps to — it certifies an information security management system, not a set of controls in isolation. The 2022 revision restructured Annex A from 114 controls into 93, grouped under four themes. Noxen produces direct technical evidence for a cluster of Technological controls, primarily around vulnerability management and configuration. It does not certify your organisation against ISO 27001 — only an accredited certification body can do that. What you get is audit-ready evidence for the technical Annex A controls that surveillance and recertification audits will sample.

What ISO 27001:2022 is

ISO/IEC 27001:2022 is the international standard for information security management systems (ISMS). The standard body (clauses 4 to 10) is the management-system spine — context, leadership, planning, support, operation, performance evaluation, improvement. Annex A is the catalogue of reference controls organisations can select from for their Statement of Applicability. The 2022 revision reduced the 2013 Annex A from 114 controls to 93 and reorganised them into four themes:

5 — Organisational (37 controls): policies, roles, threat intel, supplier relationships.
6 — People (8 controls): screening, terms of employment, awareness, disciplinary process.
7 — Physical (14 controls): perimeters, entry, equipment, cabling, secure disposal.
8 — Technological (34 controls): user endpoints, privileged access, authentication, cryptography, malware, vulnerability management, logging, monitoring, change management.

Noxen contributes to a subset of the Technological theme (8.x). The Organisational, People, and Physical themes are entirely outside Noxen's reach, as is the ISMS management-system requirement set (clauses 4 to 10).

How Noxen maps to ISO 27001:2022

Annex A controls are deliberately written at a level that allows organisations to demonstrate compliance through a range of evidence types. For 8.8 ("Management of Technical Vulnerabilities"), an auditor wants to see that you identify, assess, and remediate technical vulnerabilities in a timely manner. A nightly Noxen scan with a daily-refreshed CVE feed and dated findings produces a strong evidentiary chain for the first two parts of that — identification and assessment. The remediation step (patching, mitigating, accepting risk) still lives in your ticketing system, but Noxen tags each finding with the date it first appeared and the date it disappeared, which is exactly the timeline data the auditor wants.

The mapping is conservative: where a control has a policy-or-process side that Noxen can't observe, the CSV labels the coverage as partial.

Controls Noxen produces evidence for

Annex A control	Coverage	What Noxen contributes
8.8 — Management of Technical Vulnerabilities	Full (technical evidence)	The headline control. Daily CVE matching against installed packages, severity bucketing, dated first-seen and last-seen records, remediation hints. The full evidentiary chain auditors expect for this control.
8.9 — Configuration Management	Partial	`sshd_config` audit, TLS configuration audit, HTTP security headers, exposed admin surface flags. Demonstrates that secure baselines are observed; baseline definition itself remains a documentation artefact.
8.16 — Monitoring Activities	Partial	Scheduled nightly scans across the fleet produce a continuous monitoring record. Diff-from-yesterday delta highlights anomalous change. Not a substitute for SIEM-level monitoring; complements it.
8.21 — Security of Network Services	Partial	Port-scan deltas, TLS audit on every TLS-capable port, exposed admin surface detection. Covers the technical-attribute side; service-level agreements and contracts stay with you.
8.22 — Segregation of Networks	Adjacent	Noxen does not enforce segmentation, but per-host inventory across distinct subnets in the host catalog produces evidence that segmentation boundaries are inventoried. Treat as supporting, not primary.
8.32 — Change Management	Partial	Diff-from-yesterday output is a record of change to the fleet's security posture — new packages, new open ports, new findings appearing after deployments. Change-approval workflow remains in your ticketing system.

Note: this list reflects the controls Noxen currently has explicit mapping rules for. Adjacent controls in the Technological theme (such as 8.5 secure authentication or 8.7 protection against malware) are not covered by Noxen and the CSV will not assert coverage for them. If your Statement of Applicability includes those, you will source evidence from your IAM and EDR stacks instead.

Controls Noxen does NOT cover

ISO 27001 is fundamentally a management-system standard. Most of Annex A and all of clauses 4–10 are outside Noxen's remit. Be explicit about this in your evidence binder.

Clauses 4–10 (the ISMS itself). Context, leadership, planning, risk treatment, internal audit, management review, continual improvement. The whole management-system spine.
5.x — Organisational controls. Policies, roles and responsibilities, segregation of duties, threat intelligence, supplier relationships, incident management lifecycle, legal and contractual requirements.
6.x — People controls. Screening, terms of employment, awareness, training, disciplinary process, NDAs.
7.x — Physical controls. Perimeters, entry controls, secure rooms, equipment siting, cabling, secure disposal, clear desk.
8.1 / 8.2 / 8.3 / 8.4 — User endpoint, privileged access, information access restriction, source code access. Identity and access management territory.
8.5 — Secure authentication. MFA, password policy enforcement.
8.7 — Protection against malware. EDR / AV.
8.10 / 8.11 / 8.12 — Data deletion, masking, leakage prevention. DLP territory.
8.13 / 8.14 — Backup, redundancy. Backup verification, DR testing.
8.15 — Logging. Centralised log collection; Noxen logs its own activity but doesn't collect host syslogs.
8.24 / 8.25 / 8.26 / 8.27 / 8.28 — Cryptography, SDLC, security requirements, secure architecture, secure coding.
8.29 / 8.30 / 8.31 — Security testing in development, outsourced development, separation of environments.
8.33 / 8.34 — Test information, audit testing.

How to export evidence

The MSP / Team tier exposes an ISO 27001 selector in the Compliance CSV export. Per-host or fleet-wide. The output is a flat CSV with these columns:

scan_date — ISO 8601 timestamp.
host — display name from the host catalog.
finding_id — CVE ID or probe identifier.
severity — critical / high / medium / low / info.
iso_theme — 5 / 6 / 7 / 8 (always 8 from Noxen).
iso_control — Annex A reference (e.g. 8.8).
coverage — full / partial / adjacent.
summary — one-line description.

ISO 27001 certification runs on a three-year cycle: initial certification audit, two annual surveillance audits, then a recertification audit. Across that cycle the certification body samples evidence from across the period — so the right cadence is monthly export, retained for the full three-year window. NoxenAgent scans nightly; the underlying record is continuous. The export is just a materialised slice with the Annex A mapping applied.

When this is enough — and when it isn't

Noxen's ISO 27001 mapping is enough as the technical-vulnerability-management evidence layer for an organisation that has the rest of its ISMS in order. If you have a maintained Statement of Applicability, documented policies, internal audit records, and management review minutes — and you are pursuing or maintaining certification — Noxen handing your certification body clean, dated, mapped CSVs for 8.8 / 8.9 / 8.16 saves you the work of stitching that evidence together from apt output and screenshots.

It is not a substitute for an ISMS. You cannot get certified on the strength of a scanner. If your organisation is pre-ISMS, the work is policy, risk treatment, internal audit, and management review — none of which Noxen produces. Once those pieces are in place, the technical-control evidence Noxen generates is one of the cleaner things in the binder.

See the MSP tier → · All compliance mappings · Continuous scanning vs patching