Audit readiness
Quarterly audit, without the scramble.
The week before the audit, most teams are reconstructing evidence from tickets, screenshots, and chat threads. With Owlie, the evidence has been accruing the whole quarter — per-step execution journal, versioned state per assignment, approval provenance. So a sample pull means reading records that already exist, not reconstructing them from scratch.
Evidence as commit, not reconstruction.
Operation inspector — provisioning operations filtered by date range
The questions auditors actually ask.
- 01
“Show me every user who had access to the finance SaaS as of Q2 end, and the approval for each.”
Answer shape. The current assignments for that resource, plus every provisioning operation on it across the quarter — filtered by date range in the operation inspector — so each grant and revocation is on the record, with the originating request and its approval where one exists.
- 02
“For privileged access granted in the quarter, show the approval trail, the policy applied, and the outcome.”
Answer shape. Resources filtered to high-risk by risk level or tag, then the operations on those resources pulled for the quarter in the operation inspector. Each references its originating request where one exists, so the approval step, the applied policy (rule-based or Function-backed), and the fulfillment result are correlated through that request; policy-driven or direct grants carry the applied policy or actor on the operation itself. The approval trail and the execution journal are separate systems, joined by the request.
- 03
“What access was provisioned but never used?”
Answer shape. Sync-observed state compared to desired state, by assignment. Where the target system exposes login or activity signals, Owlie records them through sync; where it doesn't, the answer is "provisioned, with no confirmed activity" — still a defensible signal.
- 04
“What happened when the last three quarterly access reviews ran?”
Answer shape. Review campaign artifacts, exportable — showing scope, reviewers, completion rates, and any revocations that followed.
Evidence is the commit, not a project.
Every operation carries a target version. Every reconciliation attempt writes a per-step journal. Every successful apply persists observed state in the same transaction that advances the version counter. Every approval carries provenance — who, when, policy applied, outcome. You're not producing audit evidence. You're reading the log of the work the system did anyway.
Execution journal.
Execution journal
Access reviews.
Review campaign overview
Versioned state per assignment.
Assignment history
Approval provenance.
Approval provenance card
The audit week, in five actual steps.
Auditor sends the sample request: 12 users, 6 resources, privileged access for the quarter.
Compliance lead pulls the current assignments for those resources and filters the provisioning operations on them to the quarter by date range in the operation inspector. Together they show who holds access now and every grant or revocation in the window, with fulfillment status per operation.
For the high-risk sample, the execution journal for those operations is filtered to the same quarter by date range and reviewed in the operation inspector. Each row shows which operation ran, which steps executed, what the target system returned, and when each step ran.
The access-review campaigns for the quarter are exported as a bundle — scope, reviewer list, per-reviewer completion, decisions made, any revocations that followed.
What the auditor gets is pulled straight from the record — the review-campaign evidence export and the execution journal in the operation inspector — not a reconstruction. No screenshot reconstruction. No "I think that's how it went."
Audit-week stepper — 5 steps with UI snippets per step
Next quarter's audit shouldn't look like last quarter's.
Early access is open. Tell us about your attestation cycle and we'll show you Owlie running it.