Auditor-ready evidence: new export formats in Wardengate

Preparing for a privileged-access audit should not require a week of bespoke SQL. Historically it has, because the evidence lives in five places — the IdP, the ticketing system, the bastion, the screen recorder, and the SIEM — and the auditor's questions cross all five. The February release narrows that gap by making Wardengate a defensible primary source for the answers auditors keep asking.

What shipped

Three capabilities, designed together. None of them are glamorous. All of them are the kind of thing you only appreciate once you have been in a room with an external auditor who is asking for 'a list of every privileged session against the cardholder environment in Q3, with named identity, approval ticket, and duration.'

• A queryable session ledger. Every brokered session is now a first-class row in the ledger, with identity, target, approval reference, policy version, start and end timestamps, and evidence pointers. The ledger is queryable through the admin UI and exportable as JSON-L or Parquet.
• Structured evidence exports. A canned export for SOC 2 CC6 controls, one for ISO 27001 A.9, and one for PCI requirement 8. Each is a directory of artifacts and a manifest, ready to hand to an auditor or a GRC platform.
• Signed manifests. Every export includes a signed manifest describing the artifacts inside, their hashes, the policy version in force at the time, and the Wardengate build that produced them. Auditors can verify the chain of custody without trusting the filesystem it was copied through.

Why this shape

We spent the last two quarters with five customers' audit teams. The feedback converged on three points. First: auditors do not want a dashboard; they want evidence they can file. Second: they want the evidence keyed to a control, not to a product feature. Third: they will ask you to prove the evidence was not tampered with between the gateway and their inbox, and 'trust us' is not an answer anyone accepts anymore.

An auditor at a Fortune 500 bank put it plainly in one of those sessions: 'I do not care how pretty your console is. I care whether I can point at one file and say, this is what happened, and I can prove the file did not change.' The signed manifest is the direct response to that sentence.

Using the ledger

The ledger is the primary surface for day-to-day review. A security engineer reviewing last night's privileged activity runs one query instead of five. The underlying schema is deliberately narrow — the columns that every audit asks for, nothing more.

-- Sessions against the prod database tier, last 7 days, with approval context
SELECT s.identity, s.target, s.approval_ref, s.started_at, s.ended_at,
       s.policy_version, e.manifest_sha256
FROM   wardengate.sessions s
JOIN   wardengate.evidence  e USING (session_id)
WHERE  s.target_tag = 'tier:prod-db'
  AND  s.started_at > now() - interval '7 days'
ORDER  BY s.started_at DESC;

Exporting for a control

The structured exports are the second surface. Instead of exporting raw sessions and then writing the narrative in a spreadsheet, you run an export keyed to a control family and Wardengate assembles the narrative. The CC6.1 export, for example, bundles every privileged session against in-scope systems, the policy version in effect for each, the approval record, and a summary page describing the controls themselves and how evidence maps to each.

Upgrade path

The ledger is available on all supported releases from 2026.02 onward. The structured exports require 2026.02 or later on the control plane. There is no schema migration for existing session history — past sessions are back-filled into the ledger on first use, which takes a few minutes for most estates and up to an hour for the largest.

What is next

We are working on two follow-ups for the 2026.04 release: a HIPAA-oriented export profile, and an evidence relay that pushes manifests directly into GRC platforms without an intermediate copy. Both are in private preview. If you want to join, talk to your account team or file the usual request.