Compliance Mapping
cv4pve-diag tags many of its diagnostic checks with the normative controls they satisfy. A failed check on two-factor authentication, for example, is also a documented gap against ISO 27001 A.5.17, NIS2 Art. 21(j), DORA Art. 9 and PCI DSS 8.4.2 — the report doubles as evidence for auditors.
The diagnostic logic is unchanged: same checks, same severity, same descriptions. Compliance is an additional mapping layer attached to the findings.
Pick a framework with --compliance and the report keeps only the findings that relate to it, each
with the controls it concerns. An example report with --compliance=Nis2:
| Gravity | ControlId | Code | Id | Description | Context | SubContext |
|---|---|---|---|---|---|---|
| Critical | Art.21(j) | CC0004 | access/users/root@pam | root@pam has no TFA configured — full access protected only by password | Cluster | Access |
| Critical | Art.21(i) | CG0006 | nodes/pve02/lxc/101 | Privileged container has AppArmor disabled — no kernel confinement, root inside has unrestricted host access | Lxc | Security |
| Critical | Art.21(c) | CG0002 | nodes/pve02/qemu/203 | Disk 'scsi0' disabled for backup | Qemu | Backup |
| Warning | Art.21(e) | WN0013 | nodes/pve01 | Node requires reboot: running kernel '6.8.12-20-pve' but newer kernel '6.8.12-43-pve' is installed | Node | Reboot |
| Warning | Art.21(e) | WG0037 | nodes/pve01/qemu/1010 | CPU type 'kvm64' is missing security flags: +spec-ctrl, +ssbd, +pcid, +md-clear — add to cpu flags to mitigate Spectre/Meltdown/MDS | Qemu | CPU |
| Warning | Art.21(c) | WG0017 | nodes/pve02/qemu/999 | vzdump backup not configured | Qemu | Backup |
| Warning | Art.21(e) | WG0002 | nodes/pve01/qemu/1013 | OS 'Microsoft Windows 8.x/2012/2012r2' not maintained from vendor! | Qemu | OSNotMaintained |
| Info | Art.21(c) | IC0002 | cluster | No HA resources configured — VMs will not automatically restart on node failure | Cluster | HA |
| Ok | Art.21(c) | WC0001 | cluster/backup | 3 backup job(s) configured at cluster level | Cluster | Backup |
| Ok | Art.21(e) | WC0003 | cluster | Cluster firewall is enabled | Cluster | Firewall |
| Ok | Art.21(c) | WG0017 | nodes/pve01/qemu/100 | Guest is covered by at least one enabled backup job | Qemu | Backup |
| Ok | Art.21(c) | WG0017 | nodes/pve01/qemu/101 | Guest is covered by at least one enabled backup job | Qemu | Backup |
Ok rows come from --full, or IncludeOkResult: true in the settings file.How findings are produced
Section titled “How findings are produced”- Checks without a compliance mapping are reported as before (e.g. performance thresholds, hardware health, configuration hygiene).
- Checks with a compliance mapping include the list of normative controls (standard + control id + title) on every result they produce.
- When the top-level
IncludeOkResultflag is enabled in Settings, every check also emits anOkresult on success — useful for full audit reports where you need to prove that controls were verified, not only that they were violated.
Single-node setups and compliance
Section titled “Single-node setups and compliance”A single-node Proxmox VE host is, by design, not compliant with the resilience and business-continuity controls that most standards require (ISO 27001 A.5.30, NIS2 Art. 21(c), DORA Art. 11, …). With only one node:
- There is no HA failover — if the host goes down, every guest goes down with it.
- There is no replication target between nodes.
- There is no live migration for planned maintenance.
For this reason cv4pve-diag reports the related findings on single-node setups, even though they may look noisy on a lab or dev host:
| Code | When it fires on a single node |
|---|---|
IC0017 |
Always — the cluster has a single node, HA / quorum / replication are ineffective |
IC0002 |
Only when the node is part of a corosync cluster (a one-node cluster): no HA resources configured |
IC0003 |
Only when the node is part of a corosync cluster: no replication jobs configured |
IG0015 |
Only when some HA resources exist: a running guest is not managed by HA |
CG0005 |
Only when an HA guest has disks on non-shared storage and no enabled replication job |
A standalone host that was never joined to a cluster (pvecm not configured) gets IC0017 only: the HA and replication checks need a cluster configuration to read.
This is intentional: on a production single-node deployment those findings ARE the audit evidence that the resilience controls are not in place. The remediation is to add a second node, not to silence the check.
If you run cv4pve-diag on a lab or dev single-node setup and the noise bothers you, the right tool is the ignore rules: add the codes you do not want to see in ignored-issues.json and the next runs will hide them (or keep them, marked as ignored, with --ignored-issues-show). See ignore rules.
Cross-node checks (
CN0002,WN0005–WN0009,WN0015,WN0045,WN0047,WC0011,WC0012,CC0002) are different: they compare each node against its peers. On a single-node setup there is nothing to compare to, so these checks are skipped entirely (no KO and no OK emitted) — they would have no compliance value.
CLI usage: the --compliance flag
Section titled “CLI usage: the --compliance flag”When you pass --compliance=<standard> on the execute command, two things happen:
- The output is filtered: only findings that have at least one mapping for the selected standard are kept — plus
WG0042,CU0001andWC0020, which are always kept because they say what the analysis could not verify. - A
ControlIdcolumn (Control Idin Excel) is added to the report, listing the control identifiers of that standard for each finding (comma-separated when more than one). In Excel the summary also shows aCompliance:row with the selected standard.
Accepted values: the --compliance column of Frameworks.
Values are matched case-insensitively. Without the flag nothing is filtered and there is no ControlId column.
The output format follows the --output-file extension (see Reading the report), so an auditor-ready report needs no --output:
cv4pve-diag --host=pve.local --api-token=user@realm!token=uuid \ --compliance=Soc2 --output-file=soc2-evidence.xlsx executeExamples
Section titled “Examples”# All findings mapped to ISO 27001, with their control ids in the reportcv4pve-diag --host=pve.local --api-token=user@realm!token=uuid \ --compliance=Iso27001 execute
# Same, exported to Excel — the header table shows "Compliance: Nis2"cv4pve-diag --host=pve.local --api-token=user@realm!token=uuid \ --compliance=Nis2 --output=Excel execute
# Combine with --output and --output-file to produce an HTML auditor reportcv4pve-diag --host=pve.local --api-token=user@realm!token=uuid \ --compliance=PciDss --output=Html --output-file=pcidss-report.html execute
# Combine with IncludeOkResult in the settings file to also show passing controlscv4pve-diag --host=pve.local --api-token=user@realm!token=uuid \ --settings-file=audit-settings.json --compliance=Dora executeFrameworks
Section titled “Frameworks”One page per framework, with the controls and the checks that give evidence for them.
| Framework | --compliance |
Standard |
|---|---|---|
| ISO/IEC 27001 | Iso27001 |
ISO/IEC 27001:2022 |
| NIS2 | Nis2 |
NIS2 (EU Directive 2022/2555) |
| NIS2 Implementing Regulation | Nis2Ir |
NIS2 Implementing Regulation (EU) 2024/2690 — cloud, data centre, managed service providers and other digital providers |
| ACN NIS2 (Italy) | Acn |
ACN — NIS2 basic security measures (Italy, Determinazione ACN n. 379907/2025) |
| DORA | Dora |
DORA (EU Regulation 2022/2554) |
| PCI DSS | PciDss |
PCI DSS v4.0 |
| GDPR | Gdpr |
GDPR (EU Regulation 2016/679) |
| AgID (Italy) | AgId |
AgID — Misure minime ICT (Italian PA) |
| ENS (Spain) | Ens |
ENS — Esquema Nacional de Seguridad (Spanish PA, RD 311/2022) |
| BSI IT-Grundschutz | BsiGrundschutz |
BSI IT-Grundschutz — Kompendium Edition 2023 (Germany) |
| BSI C5 | C5 |
C5 — BSI Cloud Computing Compliance Criteria Catalogue (Germany, C5:2020) |
| ISO 22301 | Iso22301 |
ISO 22301:2019 — Business continuity management systems |
| SOC 2 | Soc2 |
SOC 2 — AICPA Trust Services Criteria (2017 + 2022) |
| NIST SP 800-53 | Nist80053 |
NIST SP 800-53 rev.5 — Moderate baseline subset |
| ISO/IEC 27017 | Iso27017 |
ISO/IEC 27017:2015 |
| ISO/IEC 27018 | Iso27018 |
ISO/IEC 27018:2019 — PII in public clouds |
| CIS Controls | Cis |
CIS Controls v8 |
| NIST CSF | NistCsf |
NIST CSF 2.0 |
Coverage by area
Section titled “Coverage by area”The mapping is concentrated where compliance frameworks actually demand verifiable controls. The full check list per area is in Diagnostic Checks; the table below shows where compliance tags are attached.
| Area | Examples of mapped checks |
|---|---|
| Access / Identity | root@pam TFA, admin TFA (direct and via group), ACL scoping, account expiration, API tokens, external realm TFA, privilege separation |
| Backup | Job presence, retention, schedule, recent backups, disk inclusion, backup storage availability, recent task failures |
| Resilience / HA | HA resource state, replication configuration and errors, single-node topology, NIC bond redundancy, HA on shared storage |
| Firewall | Cluster firewall on/off, default policy, node firewall, overly permissive rules, audit logging, VM/CT firewall, IP filter |
| Cryptography | Certificates expired, expiring soon, default or self-signed |
| Data integrity | Disk cache mode (cache=unsafe, writeback without backup) |
| Patch / Vulnerability | PVE EOL, subscription, important updates, reboot required, version/kernel/package consistency, OS not maintained, CPU security flags, CVE |
| Logging / Monitoring | Cluster log errors, task failure rate, services not running, NTP offset, storage availability, metric server, user notification |
| Container isolation | Privileged containers, AppArmor, raw lxc config |
Disclaimer & limits
Section titled “Disclaimer & limits”The compliance mapping in cv4pve-diag is automated and technical only — it reads the cluster state and tags findings against the verifiable subset of each standard. Procedural, organisational and physical controls are out of scope and require manual review.
The report does not constitute formal certification. Use it as a continuous self-assessment input alongside your audit programme, never as the sole evidence of conformity.
Specifically:
- Scope is technical. Policies, training, supplier management, business continuity testing, physical security, incident response procedures and similar organisational requirements are not assessed here.
- Coverage is partial. A standard may include dozens or hundreds of controls; this tool maps only the ones that can be verified from the Proxmox VE API state. For example: ISO 27001 has 93 Annex A controls; only the technical subset relevant to a virtualisation cluster is mapped. NIS2 Art. 21(2) defines ten measures; only the technically verifiable ones produce findings.
- A passing check does not equal compliance with the control. It only confirms that the specific automated rule passed. Full conformity usually requires manual evidence (policies, procedures, evidence of operation) that this tool cannot validate.
- Coverage is not symmetrical across standards. PCI DSS requirements that involve cardholder-data flows, GDPR requirements on lawful processing bases, DORA testing/reporting obligations and HIPAA-like requirements on PHI are not enforceable from PVE state alone.
- Controls evolve. Standard revisions (ISO 27001 minor updates, NIS2 secondary acts, PCI DSS minor versions, …) may shift control numbering or scope. Re-check the catalog when a new release of
cv4pve-diagis published. - Mapping is best-effort and informative. The association between an automated check and a normative control reflects the project maintainers’ interpretation; an auditor may disagree on specific mappings. Treat findings as inputs to a conversation, not as authoritative pronouncements.
In short: a clean cv4pve-diag --compliance=… report means the cluster passes the technical controls this tool can verify for that standard. It is a strong signal, but it is not — and cannot be — a substitute for a formal audit.