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

Four 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, active, generating, generated, approved, archived, retired.

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.

Export template is the reusable export configuration. It lets administrators choose which approved fields are included, the output format, redaction behavior, grouping intent, and lineage notes for a specific export context such as a legal register, SoA, or audit package. The selectable fields come from enabled Novantra modules; users do not select raw database columns or internal system fields.

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. While the generation runs the package is generating; when it finishes, the system has produced a packaged artifact (a structured archive) containing the manifest, the snapshots, any referenced files, and available ledger evidence for the export. The package is then generated.

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 and the package is signed off, its status moves to approved, and older packages are eventually archived or retired. 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).

The Templates tab shows tenant-owned export templates. A template records the approved field selection, output format, redaction expectations, grouping notes, and lineage expectations. A generation request may use a template so the exported package follows the same auditor-ready structure every time.

The Export fields tab shows the fields made exportable by enabled governance modules. These are safe, product-level descriptors with labels and sensitivity metadata. They are not implementation details and they do not reveal storage keys, internal route names, or private system logic.

Enabled source modules can publish export fields for their own records. For example, Sources can publish source-version fields, Frameworks can publish framework and coverage fields, Regulatory Register can publish profile, triage, review, and export-request fields, and Compliance Posture can publish model, signal, projection, and recalculation fields. Audit Packages also publishes its own package, item, generation, and template fields so export templates can include package metadata without exposing internal storage details.

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.
Export integrity details, including package and manifest hashes and, where available, the current audit-ledger checkpoint, signing state, and anchor state.
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.

Ledger evidence in exports

Generated exports include deterministic hashes for the package payload and manifest. When audit-ledger checkpoint evidence exists, the export also includes a ledger evidence file with sanitized checkpoint, signature, and anchor references. This helps an auditor correlate the package with the audit chain without exposing raw secrets, storage paths, or internal database structure.

If ledger signing or anchoring is not configured, the export remains valid as a hashed package export and the stronger ledger state is simply absent or marked not configured.

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.
With the package active and assembly complete, request a generation.

Generating the export

Create or select an export template for the review context.
From the assembled package, request an export generation.
The generation records the template choice, source snapshots, redaction intent, lineage intent, and artifact notes.
The system produces an artifact when the generation provider runs.
The package status moves to generated.

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.

Replacing a package

If a new package replaces a prior one (a revised submission, a follow-up audit), archive or retire the old package.
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.