Audit Packages

An audit package is a named, versioned group of policies representing one compliance framework — the EU AI Act, ISO/IEC 42001, or a framework of your own. Attaching a package to a project attaches every policy it contains, so a team applies a whole framework in one step instead of picking policies individually.

Packages sit in the Authoring stage: they group the policies that assessments then run against. See the Overview for how Authoring fits with Assessment, Testing and Runtime Governance.

Policies are referenced, not copied. A package points at policies by identifier. The same policy can belong to several packages and still attaches only once to a project — which is what lets one piece of evidence answer to more than one framework.

Table of Contents

How a package is put together 

Audit Package  "EU AI Act"
├── policy reference   com.example.euaiact.riskmanagement
├── policy reference   com.example.euaiact.datagovernance   (pinned to v1.0)
└── policy reference   com.example.privacy

A package carries no controls or questions of its own. Everything a team answers comes from the policies it references — see Policy Configuration for how those are built.

Package fields

Field Type Required Description
identifier string Yes Unique identifier, e.g. com.example.pkg.euaiact
name string Yes Display name shown when someone picks a package
framework string Yes The compliance framework this package represents, e.g. EU AI Act
version string Yes Version string. Compared numerically when resolving the latest
description string No What the package covers
policies PolicyRef[] Yes The policies to attach. At least one is required
isSystemLevel boolean No When true, the package is available to every organisation. Restricted — see Uploading a package. Default false

framework is free-form on purpose. One framework can have several packages — for example a high-risk variant and a minimal variant — each a separate package sharing the same framework value.

Policy references

Each entry in policies points at a policy by identifier, and may pin a version.

Field Type Required Description
identifier string Yes The policy’s identifier
version string No Pins an exact version. When omitted, the latest non-archived version is resolved at the moment the package is attached

Pin a version when the framework requires a specific wording, and leave it out when you want projects to pick up policy updates automatically. An unpinned reference is resolved fresh each time a package is attached, so two projects created a month apart can receive different policy versions from the same package.

Duplicate identifiers are rejected rather than quietly merged — listing the same policy twice is treated as an authoring mistake.

Uploading a package

Packages are authored as JSON and uploaded; there is no form for building one field by field.

Where: the System Audit Packages tab of the System Admin dashboard. Paste your JSON and upload. Packages already ingested are listed below the input.

Who can upload:

Package scope Permission needed
Your organisation (isSystemLevel absent or false) Permission to manage policies in that organisation
Every organisation (isSystemLevel: true) Platform administrator

The upload accepts three shapes, so you can paste a single package or a batch:

{
  "auditPackages": [
    {
      "identifier": "com.example.pkg.euaiact",
      "name": "EU AI Act — High Risk",
      "framework": "EU AI Act",
      "version": "1.0",
      "description": "Policies required for high-risk systems under the EU AI Act.",
      "policies": [
        { "identifier": "com.example.euaiact.riskmanagement" },
        { "identifier": "com.example.euaiact.datagovernance", "version": "1.0" },
        { "identifier": "com.example.privacy" }
      ]
    }
  ]
}

A bare package object, or a plain array of package objects, is also accepted.

What happens when a package is attached

When a package is attached to a project, the platform resolves it and attaches its policies:

  1. The latest non-archived version of the package is resolved from its identifier.
  2. For each policy reference, the policy is resolved — the pinned version if given, otherwise the latest non-archived one.
  3. Each policy is attached to the project, along with its control bundles.
  4. The project records which packages were attached, with their name, framework and version.

Deduplication is by policy identifier, not identifier + version. If a policy is already on the project — attached individually, or by another package — it is not attached a second time. A project can never end up with two versions of the same policy from this path.

Missing references are skipped, not fatal. If a package has been archived, or one of its policy references no longer resolves, the platform logs a warning and carries on rather than failing project creation. The rest of the package still attaches.

This means a package can attach partially if a policy it references was archived after the package was uploaded. Re-upload the package after archiving a policy that any package points at.

Versioning and re-uploading

identifier + version together identify a package within its scope.

  • Re-uploading the same identifier and version updates that package in place. Ingestion is idempotent, so running the same upload twice is safe.
  • Changing version creates a new package version. The previous version remains.
  • Attaching always resolves the latest non-archived version, compared numerically. Projects that already have the package keep what they were given; the new version applies to future attachments.

Versions are compared numerically rather than as text, so 1.10 sorts above 1.9.

Recommending a package during screening

A package does not have to be chosen by hand. Screening can recommend one, so a project created through the wizard arrives with the right framework already suggested and the team only has to confirm it.

A recommendation targets a package by its identifier — not its name or framework — so keep identifiers stable once a package is in use.

Under the hood the rule uses the RECOMMEND_AUDIT_PACKAGE action type, whose target field is targetAuditPackageIdentifier. Rules Configuration documents rule authoring against ADD_POLICY_AND_ANSWER; talk to Asenion before building on this one so the behaviour is confirmed for your tenant. Bring the package identifier you want recommended and the screening answers that should trigger it.

Validation errors

The whole upload is rejected if anything fails, so a package can never be stored pointing at policies that do not exist.

Message Cause
identifier is required / name is required / framework is required / version is required A required field is missing or blank
policies must contain at least one policy reference The policies array is empty
duplicate policy reference "..." The same policy identifier appears more than once
referenced policy "..." does not exist (or is archived) No non-archived policy with that identifier

A pinned reference must match that exact identifier and version; an unpinned one only needs some non-archived version to exist.

Quick reference

Aspect Detail
What it is A named, versioned group of policy references representing one framework
Authoring JSON upload — System Admin dashboard → System Audit Packages
Scope Organisation by default; platform-wide with isSystemLevel: true
Policies Referenced by identifier, optionally version-pinned
Re-upload Same identifier + version updates in place
Attach Fans out to every referenced policy, deduplicated by identifier
Missing refs Logged and skipped; project creation still succeeds
Recommended by screening Targeted by package identifier; set up with Asenion