Details
Trust model
The detail behind “Your evidence stays under your control”: deployment, access, evidence integrity and the limits we want you to know about up front.
Security and trust
Your security evidence can stay in your environment.
Akvera is designed so customers can retain control of security evidence and connector credentials within their own environment. The first pilots run customer-hosted.
- Customer-hosted deployment
- You run Akvera on your own host. It has no telemetry, update check or licence call to Akvera.
- Customer-controlled storage
- The database, evidence storage, backups and encryption key are yours.
- Connector credentials
- Stored encrypted in your deployment and write-only in the interface: once saved, they are never shown again.
- Your identity provider
- Users sign in through your own OIDC provider.
- No standing vendor access
- Support runs through your screen share or diagnostics you have reviewed.
Least privilege, read-only where vendors allow
Akvera integrations are designed around least-privilege, read-only access wherever vendor APIs permit it. Each integration comes with a permission manifest that lists which permission each check needs and what becomes UNKNOWN without it.
An honest boundary
Whoever administers the host can use the credentials stored on it. That is why we ask for dedicated read-only accounts, created by you.
Where the work happens
- Your systemsIdentity, source control, cloud, logging, backup, secrets. Read-only access.
- Akvera in your environmentRuns the checks, minimizes the data, hashes the evidence.
- Evidence packageResults, evidence records and raw source artifacts, with a manifest.
- Your auditorVerifies the package offline, without the product.
Evidence
Evidence that can be checked, and kept to the minimum.
Integrity
- Historical evidence
- Every verification run appends a record. Past results are not overwritten or re-evaluated.
- SHA-256 hashing
- The canonical evidence and the original source artifact are hashed, and a manifest hash covers each package.
- Evidence packages
- An exportable archive with summaries, evidence records, raw source artifacts and a manifest. A separate script verifies it offline.
- Source provenance
- Each record names the source system, scope, check version and collection time.
- Traceability
- Every result links back through the full proof chain.
Integrity-verifiable, not tamper-proof
Hashes reveal changed or partial evidence. They are not digital signatures, and we do not call the result legally tamper-proof. Whoever controls both the database and the object store could rewrite both consistently. We say this because your auditor will ask.
Minimal by design
Akvera does not collect whole datasets just because an API exposes them. A connector keeps the technical facts its checks need.
Examples of what is kept
- Status
- Timestamp
- Resource identity
- Verification result
Examples of what is not kept
- Secret values
- Backup contents
- Source code
- Unrelated logs
Evidence can still contain identifiers such as usernames, device names and repository names. During a pilot we review the field list for each integration with you.
Technical proof chain
From requirement to hash, every result is traceable.
Akvera does not ask you to trust a score. It shows how a result came about, and every link in that chain can be inspected.
The mapping covers technical evidence only. It is not an assessment of your organization.
Framework requirement
The requirement a control supports, for example an ISO/IEC 27001:2022 Annex A item.
Technical control
Akvera's own control, mapped to that requirement.
Automated check
A versioned check definition. Past results keep the definition they were produced with.
Source observation
What the source system reported, reduced to the fields the check needs.
Evidence
The result, its reasoning, collection time and expiry, kept as an append-only record.
SHA-256
A hash of the canonical evidence and of the original source artifact.