Technical evidence directly from source systems

What technical evidence is

Technical evidence is an observation taken from the system where a control is actually implemented: whether multi-factor authentication is enforced for privileged accounts, whether backup jobs complete successfully, or whether log sources are actively sending events.

The observation becomes meaningful through its origin. The source system, the time of collection and the check that evaluated it must be traceable.

Why screenshots and exports often fall short

These methods exist for good reasons, and auditors work with what they are given. As proof of technical controls, however, they have weaknesses:

• They show a single point in time and go stale shortly after capture.
• They are hard for someone else to reproduce.
• They often prove only that someone took a screenshot, not that the control keeps working.
• They have to be produced by hand again in every audit cycle.

How Akvera creates evidence

Akvera connects read-only to your existing systems, evaluates defined technical controls and keeps the evidence. Every result can be traced step by step:

1. A framework requirement, for example an Annex A item of ISO/IEC 27001:2022.
2. The technical control mapped to that requirement.
3. An automated check, written as a versioned definition. Past results keep the definition they were produced with.
4. An observation from the source system, reduced to the fields the check needs.
5. Evidence with result, reasoning, collection time and expiry, kept as an append-only record.
6. A SHA-256 hash of the evidence and of the original source artifact.

An example

Illustrative example: the control “The main branch is protected” is checked against GitLab. A protected main branch is expected, enabled branch protection is observed, and the result is PASS. Timestamp, source, check revision and hash are stored.

If the protection were not active, the result would be FAIL. If Akvera could not read it because of a missing permission, the result would be UNKNOWN.

Three results: PASS, FAIL and UNKNOWN

Missing evidence does not become PASS, and partial coverage does not become complete coverage.

• PASS: sufficient, current evidence supports the control.
• FAIL: a current, valid observation violates the control.
• UNKNOWN: Akvera does not have sufficient evidence for a defensible statement, for example because of a missing permission, an unsupported edition or missing expected inventory. Akvera names the cause and the next step.

What can be automated

• Technical controls in connected systems whose state can be read through an interface: identity, cloud, source control, logging and monitoring, backup and secrets management.
• Repeated checks instead of one-off point-in-time captures.
• Tracing every result back to its source.

What Akvera does not replace

• Policies, processes and organizational measures. Akvera evidences technical controls, not how people act.
• Systems that are not connected, and data a system does not expose.
• Your auditor’s assessment and any legal interpretation. Akvera does not issue certifications and does not make an organization ISO 27001 or NIS2 compliant.

Evidence packages for auditors

An evidence package is an exportable archive with summaries, evidence records, raw source artifacts and a manifest. A separate script verifies it offline, without the product.

The hashes make changed or incomplete evidence detectable. They are not digital signatures, which is why we speak of verifiable integrity rather than tamper-proofing.

Which systems connect

Nine integrations are available for pilots: Microsoft Entra ID, Microsoft Azure, GitLab, GitHub, Veeam Backup & Replication, Proxmox Backup Server, Graylog, Wazuh and HashiCorp Vault. Depth and scope of checks differ by integration. The details are on the supported checks page.