Frameworks
ISO/IEC 27001:2022: technical evidence
Many measures in Annex A of ISO/IEC 27001:2022 can be partly observed technically. Akvera maps its technical controls to selected requirements and provides evidence from the source systems. This page shows which ones, and what Akvera does not do.
What technical evidence does for ISO 27001
ISO/IEC 27001 asks for an information security management system. Whether a technical measure really holds up day to day shows in the systems: in the identity provider, in backup, in logging. Technical evidence supports the assessment of such measures. It replaces neither the management system nor your auditor’s decision.
Which requirements Akvera supports technically
The mapping is an illustrative technical mapping of selected Annex A requirements. Confirm its applicability against your licensed standard and your Statement of Applicability. Depending on edition, licensing and permissions, individual checks return UNKNOWN. The limits for each integration are on the supported checks page.
| Requirement | Examples of technical checks | Source system |
|---|---|---|
| A.5.17 Authentication information | Multi-factor authentication for privileged accounts, legacy authentication blocked | Microsoft Entra ID |
| A.5.18 Access rights | Detection of dormant but enabled accounts | Microsoft Entra ID |
| A.8.2 Privileged access rights | Restricted privileged roles, time-bound assignments | Microsoft Entra ID |
| A.5.23 Cloud services | Expected resources covered by Azure Policy evidence | Microsoft Azure |
| A.8.9 Configuration management | Compliance with assigned Azure policies | Microsoft Azure |
| A.8.13 Information backup | Expected backup jobs exist, with current successful runs | Veeam Backup & Replication, Proxmox Backup Server |
| A.8.15 Logging | Active log inputs, sources sending events, retention | Graylog |
| A.8.16 Monitoring activities | Monitoring agents enrolled and reporting, detection rules enabled | Wazuh |
| A.8.25 Secure development | Expected repositories and projects are observed | GitLab, GitHub |
| A.8.32 Change management | Protected branches, required approvals, successful pipeline before merge | GitLab, GitHub |
| A.8.28 Secure coding | Secret scanning and push protection | GitHub |
| A.8.24 Cryptography | Expected secret engines mounted (metadata only, no secrets read) | HashiCorp Vault |
How to use the evidence in an audit
- Declare the expected inventory: which endpoints, log sources, repositories or backup groups must be covered.
- Connect your systems read-only, with accounts you create.
- Run the checks and resolve UNKNOWN results, for example by granting a missing permission.
- Export an evidence package and hand it to your auditor, who can verify it offline.
What Akvera does not do for ISO 27001
- Akvera does not certify and does not make an organization ISO 27001 compliant.
- It does not replace risk assessment, the Statement of Applicability, policies, internal audits or management review.
- It covers only technical aspects of the mapped requirements, and only where a connected system provides the data.
- Whether the evidence is sufficient for your audit is decided by your auditor.
See which evidence can be collected in your environment.
Tell us which systems you use and which technical evidence your audit asks for.