Admin Guides / Access review campaigns
The evidence pack
What the evidence pack holds, when Warde produces it, and how it answers an auditor's questions about a campaign.
When a campaign completes, Warde attaches an evidence pack to the campaign record: a JSON file that reports the campaign as it was launched, every decision, and every removal with its confirmation. It is the record an auditor tests.
When it is produced
- Automatically, when the campaign completes, which is when every removal is confirmed. The generator is recorded as the system.
- On demand, with Generate evidence pack on the campaign, in any state after generating, including Active and Closing. The person who asked is recorded.
The pack is prepared in the background, and only one run happens at a time. Each new pack is a new attachment, named evidence-pack-YYYY-MM-DD-HH-MM-SS.json; earlier ones stay. A campaign of more than 5,000 lines is split into parts, ...-part-001.json and onwards, each a complete document with a page block. Attaching a pack is written to the audit history.
What it holds
| Section | What is in it |
|---|---|
generated_at, generated_by | When the pack was made, and by whom |
campaign | Name, state, planned start, due date, completed at, and the line, decision, revocation and reconciliation counts |
trigger | Whether the campaign was launched by schedule or by an administrator, and who |
definition | The definition as it stood at launch: name, subject, reviewer strategy, scope condition, the scope it resolved to, whether it reviewed only holders behind, and the justification rules |
left_out | For entitlement campaigns, access left out because it comes with a bundle or role the person holds, or because the engine gives it by its own rules |
lines | One per review line: the person, account, entitlement, collection, how it was granted and when, the engine's reason, the risk rating, the reviewer, the decision, the justification, who decided and when |
lines[].role | For bundle lines: the version held, the version current, the change shown to the reviewer, and when the person was brought up to date |
lines[].revocation | For removals: whether it could be removed, when the removal was confirmed, the operation's state, how it completed, the engine that ran it and the engine's own reference |
given_back | Access a reviewer removed that the engine later gave back, with who gave it back and when, as the engine reported it. Each such removal's line says so too. |
Why the pack can be trusted
- Frozen at launch. The definition, scope and reviewers are snapshotted when the campaign starts. Editing the definition afterwards changes nothing in the pack.
- Rows that survive renames. Every line keeps its own copy of the person, account, entitlement and how it was granted, so a later rename or deletion does not rewrite the evidence.
- Closed loop. A removal is reported with the engine's reference and the time it was confirmed, or the closing of the ServiceNow task that carried it out. A campaign cannot complete until every removal is confirmed.
- Append-only history. Every decision is also in Warde's audit history, which nobody can edit or delete, kept for seven years by default.
Questions an auditor asks
| Question | Where the pack answers it |
|---|---|
| Was the list complete? | definition gives the scope condition and the scope it resolved to at launch; lines is every item in it, and left_out says what was excluded and why |
| Did the right people review? | Each line names its reviewer, and definition gives the strategy |
| Were decisions justified? | Each line has the decision, its reason, who decided and when |
| Was removed access actually removed? | Each removal has its confirmation time and the engine's reference, and given_back lists any the engine later restored |
| Was anything changed after the fact? | The definition snapshot, and the audit history behind every decision |