Audit Packages

The Audit Packages module is where you build the bundle an auditor (internal, external, regulator, certifier, customer) will review. An audit package is a curated assembly of governance content: a slice of controls, evidence claims, assessments, findings, exceptions, framework references, and other records, with their relationships preserved, their source snapshots captured, and a generation request that produces a stable export artifact.

Audit packages are the output side of the governance program. The rest of the modules contain the work; audit packages are how that work is packaged for someone outside the immediate team to consume.

When you would reach for this

You set up audit packages when:

An auditor requests “the package covering control X for the audit period.”
A certification body asks for the bundle that demonstrates compliance with a framework’s requirements.
A regulator requests a curated set of records as part of an investigation or routine review.
A customer’s procurement team asks for a bundle of artifacts during a vendor risk assessment.
An internal review needs a frozen point-in-time view of “what did the governance program look like for this scope on this date?”

You don’t reach for this for the underlying records themselves; those live in their own modules. Audit packages are the export bundle that references them, with provenance and snapshot fidelity.

What lives in an audit package

Three record types:

Audit package manifest is the package itself. It carries:

A title and a stable key.
A scope (which framework, which scope nodes, which period, which subject set).
The criteria the package is being assembled against (frameworks, internal review criteria).
A provenance snapshot capturing the assembly intent, the requestor, the audit cycle reference.
An owner responsible for assembly and sign-off.
A status walking through draft, assembling, ready, delivered, closed, superseded, archived.

Package item is one record referenced by the package. Each item points neutrally at a source record (a control, an evidence claim, an assessment, a finding) and captures a snapshot of that record as it was at the time of package assembly.

Generation request is a recorded request to produce the export artifact. Each request has its own status; the resulting artifact (when produced) is attached to the package.

A worked example: a transmission system operator assembles its annual regulator audit package

A transmission system operator runs an electrical grid. The grid regulator conducts annual audits of the operator’s control posture across safety, security, reliability, and market-conduct controls. The audit covers a fiscal year, draws from a defined framework, and requires a delivered package with controls, supporting evidence, the year’s assessments, any findings and their remediation status, and any exceptions in effect during the year.

Their head of regulatory affairs, Brigitte, assembles the audit package like this.

Step 1: define scope. Brigitte creates a new audit package:

Title: “Annual regulator audit — fiscal year 2026.”
Scope: the framework version the regulator is auditing against; the period (April 2025 to March 2026); the relevant scope nodes (the regulated entity boundary).
Criteria: the framework’s requirement nodes.
Owner: herself.
Status: draft.

Step 2: assemble items. Brigitte walks the criteria. For each framework requirement in scope:

Identify the implementing control.
Add the control to the package as a package item (with its snapshot at this moment).
Add the evidence claims that support the control during the audit period.
Add the assessments performed on the control in the period.
Add any findings raised on the control during the period and their current status.
Add any active exceptions affecting the control.

Each addition is a package item: a neutral reference to the source record plus a snapshot.

Step 3: review the package. Once assembly is complete, Brigitte reviews the package end to end. The package detail page shows everything included, grouped by framework requirement, with deep links back to the live source records for spot-checks.

Step 4: snapshot fidelity matters. The snapshots captured at assembly are point-in-time. If a control is later updated or an evidence claim is later superseded, the audit package still shows what the records looked like on the assembly date. This is essential for audit fidelity: the auditor reviews what existed at the time, not what exists now.

Step 5: generate the export. Brigitte requests an export generation. The system produces a packaged artifact (typically a structured archive) containing the manifest, the snapshots, and any referenced files. The package status moves to ready.

Step 6: deliver. Through the Submissions module, Brigitte creates a submission package that wraps the audit package, routes it through internal review, and sends it to the regulator. The submission picks up the audit package’s artifact as its payload.

Step 7: post-audit. After the audit completes, the package status moves to closed. Subsequent audits create new audit packages; the prior package remains visible historically.

What you’ll see in the product

Audit Packages lives under Governance → Audit Packages in the workspace.

The Audit Packages list shows every package with status, scope, criteria, owner, and the generated artifact reference (if produced).

Inside an audit package, you see:

The full scope, criteria, and provenance snapshot.
All package items grouped by source module (controls, evidence, assessments, findings, exceptions).
Each item with its snapshot and a deep link to the live source record.
Generation requests with their status and any produced artifact.
The package’s submission references (where the package was delivered).
Activity history.

Every change is captured in the workspace Audit Log.

Why snapshots, not live references

A common question: “If the package just references the live records, isn’t that simpler?”

The answer is no, because audits are point-in-time. When an auditor reviews evidence dated 17 April 2026, they need to see what the record looked like on 17 April 2026, not what it might look like six months later when someone tweaked the title or added a new version. Package items preserve snapshots so an audit conducted in October cannot be subtly invalidated by edits made in September.

This is also why audit packages don’t own the source records: they capture a moment of those records, and the source modules keep evolving independently.

Common workflows

Assembling a new audit package

Audit Packages → New audit package. Set scope (framework, period, scope nodes), criteria, owner.
Walk the criteria; add package items for each control, evidence claim, assessment, finding, and exception in scope.
Review the assembled package; spot-check items against the live source records.
Move the package to assembling complete and request a generation.

Generating the export

From the assembled package, request an export.
The system produces an artifact (structured archive).
The package status moves to ready.

Delivering through a submission

Through Submissions, create a submission package that wraps the audit package.
Route through review, send to the recipient.
The submission’s events update the package’s delivery posture.

Superseding a package

If a new package replaces a prior one (a revised submission, a follow-up audit), mark the old package superseded.
The new package may reference the old as its predecessor.
Both remain visible for historical context.

What this module does not produce on its own

Worth being explicit:

The actual export artifact (the structured archive). Generation is a separate request; the package itself is the manifest plus items.
Delivery to the recipient. That happens through Submissions.
The underlying records. Items reference and snapshot source records; the records themselves live in their owning modules.

The audit package is the curated bundle with provenance and snapshots. Everything else is upstream or downstream of it.

Frameworks - package scope and criteria reference framework versions and nodes.
Controls - the most common package item.
Evidence - evidence claims are package items.
Assessments - assessment outcomes are package items.
Findings - findings are package items.
Exceptions - active exceptions appear as package items.
Assurance - assurance engagements often produce audit packages as their export.
Submissions - audit packages are typically delivered via submission packages.