Compliance pack

Compliance pack

A compliance pack is pre-baked Policy targeting one regulation.

Operator ticks "EU AI Act" or "OWASP LLM Top 10" → procurement-defensible deployment, no Rego required.

Each pack is curated by Compliance, externally legal-reviewed, certified once, inherited by every customer that applies it.

⚠ Independent of the core. Policy works without packs — operators can hand-author every rule. Packs are accelerators: they save time and ship procurement-defensible bundles. They're not a separate kind of Policy, just a curated authoring shortcut.

At a glance

Takes	a regulation choice (--pack eu-ai-act)
Expands into	a curated set of authoring conveniences (functions, categories, concerns, Rego templates) merged into the Policy
Maintained by	Compliance team + external legal review per pack version
Composes via	cascade merger (strictest-wins) when multiple packs apply to one Sandbox

What it is, concretely

Packs sit between the operator and Rego. Instead of hand-writing rules to satisfy GDPR's data residency clause, you tick "GDPR baseline" and the pack expands into the same rules you'd otherwise write — but maintained by us, reviewed by external counsel, version-pinned.

Packs compose: apply EU AI Act + GDPR + OWASP LLM Top 10 to the same Sandbox-spec → cascade merger combines them strictest-wins. The audit's because-trail records which pack contributed each rule.

Shipped or planned:

Pack	What it covers	Status
EU AI Act	Articles 9–17 high-risk obligations: audit signing, human oversight, accuracy documentation, bias monitoring	Q3 2026
OWASP LLM Top 10	LLM01–LLM10 (with explicit non-coverage of LLM03 / LLM09)	Q3 2026
GDPR baseline	EU residency, right-to-erasure, DPA Article 28	planned
PCI-DSS scope	Payment-data tooling constraints	planned
HIPAA	PHI-mode detect_pii, access_control_strict	planned
NIS2 / DORA	EU regulated-industry obligations	planned

What it's made of

Compliance pack (e.g. eu-ai-act@v1)
├── pack metadata:        id, version, applies_when, provenance_tag
├── required_concerns:    [gdpr_required, audit_required, human_oversight_required, ...]
├── required_categories:  [eu_residents, customer_pii, ...]
├── required_pipeline_steps:
│     • detect_pii: { enabled: true, on_detection: block }
│     • audit_signing: { enabled: true }
│     • require_human_approval: { for_capabilities: [destructive_action] }
│     • ...
├── forbidden_capabilities: [undocumented_automated_decision, ...]
├── rego_templates:       [block_egress_outside_eu, ...]
└── documentation:        DPIA template, transparency disclosure, etc.

The pack also (often) ships with a paired probe library — applying the pack auto-enrolls the agent in matching pre-deployment evaluation probes.

Lifecycle

[author]      Compliance team writes pack content
              External legal review of regulatory mapping
              External technical review by Engineering
              → pack published as <name>@<version>
   │
   ▼
[apply]       tappass policy apply --pack <name> [--level org|project|agent]
              → pack expands into authoring sub-objects
              → merges via cascade (strictest-wins)
   │
   ▼
[compile]     Same as Policy lifecycle from this point on
              (cascade merge → keyring derivation → sync delivery → layer apply)
   │
   ▼
[provenance]  Every rule introduced by the pack is tagged
              via_compliance_pack: <name>@<version>
              → because-trail surfaces this in audit
   │
   ▼
[update]      Regulation evolves → new pack version
              Operators pin to specific version; explicit bump required to migrate
              Pack versions are immutable; @v2 is a new pack, not an edit

Engines that operate on compliance packs

Engine	What it does	Status
Pack expander	Expands a --pack <name> reference into authoring sub-objects	concept (within authoring resolver extensions)
Cascade merger	Composes pack output with org/project/agent policies	concept (cascade-merge-engine)
Pack registry	Per-version pack storage	concept
Coverage report renderer	Per-regulation coverage summary in dashboard	concept
Probe library binder	Couples pack to its probe suite for evaluation	concept

Quick-starts (the packs themselves are quick-starts)

Pack	Coverage	Status
EU AI Act	Articles 9–17 high-risk obligations: audit signing, human oversight, accuracy documentation, bias monitoring	concept (Q3 2026)
OWASP LLM Top 10	LLM01–LLM10 (where TapPass enforces); explicit non-coverage of LLM03/LLM09 with rationale	concept (Q3 2026)
GDPR baseline	EU residency, right-to-erasure, DPA Article 28, ROPA	planned (Q1 2027)
PCI-DSS scope	Payment-data tooling constraints; financial_write thresholds	planned
HIPAA	PHI-mode detect_pii; access_control_strict; allowed-domain matching	planned
NIS2 / DORA	EU regulated-industry obligations: incident reporting, business continuity, audit retention	planned

Packs compose. Apply EU AI Act + GDPR + OWASP LLM to one sandbox-spec → cascade merger combines them strictest-wins. The because-trail records which pack contributed each rule.

Surfaces

Persona	Surface	What you do
Operator (terminal)	tappass policy apply --pack <name>	apply at any cascade level
Operator (terminal)	tappass policy show --pack <name>	inspect pack contents and coverage report
Operator (visual)	Onboarding wizard, step 3	tick boxes for applicable packs
Operator (visual)	Dashboard policy editor	see active packs + version + last update
Compliance team	YAML files in pack repo	author + version + review

Related concepts

• applies to → Policy (packs expand into authoring sub-objects, then compile normally)
• composes via → Cascade (multiple packs merge strictest-wins)
• pairs with → Probe library (applying pack auto-enrolls in matching probes)
• enriches → authoring sub-objects (Function, Category, Concern, Capability — packs extend these)

Authoritative docs

Topic	File
Vision	governed-agents-architecture.md §4.5
Pack template (worked example)	eu-ai-act-bundle
Authoring substrate the pack builds on	intent-to-policy.md

Status snapshot

Pack	Status
EU AI Act v1	concept (Q3 2026)
OWASP LLM Top 10 v2026	concept (Q3 2026)
GDPR / PCI-DSS / HIPAA / NIS2 / DORA	planned (Q1 2027 demand-driven)
Pack expander engine	concept (extends existing authoring resolver)
External legal review for v1 packs	gating dependency before public claim

Common confusions

• Pack ≠ Policy. A pack is a bundle of authoring objects; it expands into a Policy. The same pack applied at different cascade levels (org floor vs. project floor) produces different effective policies after merging.
• Pack ≠ probe library. Packs are policies (what to enforce); probe libraries are tests (what to check pre-deployment). They're paired — applying a pack enrolls in its probes — but they're separate artifacts.
• Versioning is conservative. Packs are immutable per version. New regulation interpretation → @v2. Operators pin to a specific version; auto-rolling forward is opt-in only. This is what makes external certification of the pack inheritable to every deployment using that version.

Why this concept matters strategically

Without compliance packs, every customer assembles their compliance posture from scratch. Procurement-defensibility scales linearly with how many customers do that work.

With packs, the same bundle is reused across every customer — which makes it economically possible to certify the bundle once by external counsel, with that certification inherited by every deployment. That's the procurement-defensibility play that competes with Giskard's "EU AI Act compliance pack" claim.