# Change evidence for regulated Vault estates

Nojam helps you evidence change management for Vault: who changed what, who approved it, on which plan, and that the record wasn't edited afterwards. It doesn't make you compliant on its own, and this page says where it stops.

## What Nojam records for every change

- The commit, the pull request and the plan, with its SHA-256.
- The policy bundle that judged the plan, and its result.
- Each approval: who, when, and how they signed in, including the channel and the second factor.
- The ServiceNow change or incident, where a target requires one, as ServiceNow confirmed it at each approval.
- The runner that ran the job, and the signed audit anchor that covers it.
- Every break-glass hold, with its stated reason and its extra approvers.

## A log you can prove wasn't changed

Every audit event is chained to the one before it by SHA-256, so editing, deleting or reordering one breaks the chain at that point.

Someone with database access could rebuild the chain, so Nojam signs its head every 10 minutes and writes it to a write-once bucket with S3 object lock. Events also stream as they happen to your own store: Splunk, syslog over TLS, S3 with object lock, PostgreSQL, a file or a webhook. A rewritten history no longer matches the signed anchors or your copy.

The audit page shows both checks, and `nojam audit verify` checks an exported copy offline, without trusting Nojam.

## How it lines up with common change controls

Your auditor decides what counts as evidence. This is what Nojam gives them to test against.

| Control | What Nojam provides |
| --- | --- |
| SOC 2, CC8.1: changes are authorised, tested and approved | A plan on every pull request, policy checks on every plan, approval by someone who is not the author, and an apply of exactly the approved plan |
| ISO/IEC 27001:2022, Annex A 8.32: change management | The same chain from commit to apply, plus change records from ServiceNow and promotion in a fixed order from dev to production |
| PCI DSS 4.0, requirement 6.5: changes to system components are managed | The approved plan hash, the approver and the result of each change, in one export per job |
| DORA: ICT change management | Recorded approvals, break-glass with a reason, and a tamper-evident log streamed to your own store |

## Exports that point back to the record

Every job, the overview and the activity feed export as JSON, NDJSON, PDF or PNG. Each export names who made it, when, and the audit chain head at that moment, so a printed copy can be tied back to the record.

The break-glass page exports on its own for a change board: why it was held, what it destroys, the reason, the record and the approvals.

## What Nojam doesn't cover

- The log is tamper-evident, not tamper-proof. Someone with database access can still change rows; what Nojam guarantees is that the change shows.
- It records changes made through Nojam. A change made by hand in the Vault UI or CLI doesn't pass through it, so keep Vault's own audit device on.
- It doesn't review who has access to Vault or read secrets. Those controls stay with Vault and your identity provider.
- Rollback re-applies the last known-good configuration. It is compensation, not a database transaction, and it can't bring back deleted KV data.

## Show your auditor a real change

In a pilot, one job export covers a full change from commit to apply. Bring it to your next audit conversation.

[Request a pilot](https://nojam.io/pilot.md) [Join early access](https://nojam.io/early-access.md)

---

Canonical page: https://nojam.io/compliance/  
Site map for AI agents: https://nojam.io/llms.txt