Compliance Control Foundation

---
name: compliance-control-foundation
description: Author the framework-agnostic common control set that ISO 27001, ISO 42001, and SOC 2 work all consumes — one catalog across access control, cryptography, change management, logging/monitoring, incident response, vendor management, and risk assessment, each control written ONCE with objective, owner, verified operating mechanism or gap, and evidence hook, then projected per framework instead of rebuilt per framework. Shipped skills identify design and review routes; they do not prove that an organization operates a control. Map verified running systems and processes by name. Use when starting a compliance program, asked for a common/baseline control set, or when multiple frameworks threaten parallel control lists. Do NOT use for one framework's management system (the iso-*/soc2-* projections), control→criteria references (multi-framework-crosswalk), or gap assessment (compliance-gap-auditor).
---

# Compliance Control Foundation

**Reading key:** ISO is the International Organization for Standardization;
SOC 2 is an American Institute of Certified Public Accountants (AICPA)
attestation framework, and CPA means certified public accountant; TSC means
the SOC 2 Trust Services Criteria. AI means artificial intelligence; SDLC
means software development lifecycle; RLS means row-level security; RMF means
risk management framework. NIS2 is the European Union's second Network and
Information Security Directive; US and EU mean United States and European
Union. OWASP is the Open Worldwide Application Security Project.

## Purpose

Produce the single framework-agnostic control catalog that the framework
projections (`iso-27001-isms-architect`, `iso-42001-aims-architect`,
`soc2-trust-criteria-mapper`) consume, so the same access-control, crypto,
change-management, logging, incident-response, vendor-management, and
risk-assessment controls are written once and satisfy every framework via
`multi-framework-crosswalk` — never three parallel control lists. Each
control states its objective, owner, the verified operating mechanism
(system or process), its evidence hook for
`compliance-evidence-collector`, and an honest implementation status. The
shipped technical-control skills provide design and review routes, not
evidence that technical controls operate in this organization. This skill
maps verified systems and processes into compliance shape and exposes what
is missing; it does not re-derive or re-implement them.

## Use When

- Use when: starting a compliance/certification program and the common
  control baseline does not exist yet.
- Use when: asked for a "common control set", "control framework",
  "security control baseline", or to unify controls across ISO 27001,
  ISO 42001, and/or SOC 2.
- Use when: framework work is producing duplicate per-framework control
  lists that drift from each other.
- Do NOT use when: building one framework's management system or scoping —
  `iso-27001-isms-architect`, `iso-42001-aims-architect`,
  `soc2-trust-criteria-mapper` (they consume this catalog).
- Do NOT use when: attaching framework clause/criteria references to
  controls — `multi-framework-crosswalk`; or assessing where the org
  stands — `compliance-gap-auditor`.
- Do NOT use when: implementing or fixing a control (route to the owning
  skill, e.g. `appsec-implementer`, `secrets-identity-hardener`).

## Inputs to Inspect

1. Candidate control artifacts to inspect, not assume implemented: the authorization matrix
   (`authorization-matrix-designer`), RLS audit + negative tests
   (`rls-policy-auditor`, `multi-tenant-security-tester`), tenant-isolation
   review (`tenant-isolation-reviewer`), secret/credential posture
   (`secrets-identity-hardener`), migration review practice
   (`secure-migration-reviewer`), audit-log taxonomy/schema
   (`audit-log-architect`), incident machinery
   (`incident-response-runbook`), supply-chain review
   (`supply-chain-security-reviewer`), threat models (`threat-modeler`,
   `ai-threat-modeler`), secure-dev review practice
   (`security-pr-reviewer`, `static-analysis-reviewer`).
2. AI-governance artifacts for the AI-facing controls: the shipped
   AI-governance pack (`ai-sdlc-operating-model`, `agent-authorization-matrix`,
   `agent-memory-governance`, `agent-governance-audit`) and
   `ai-governance-risk-reviewer` outputs.
3. Which framework(s) the org is targeting and any existing policy or
   control documents (to reconcile, not duplicate — conflicts go to
   `source-of-truth-reconciler`).
4. Known control residue from the reconciliation doc (the repository's **D8**
   audit, the [OWASP Top 10:2025 coverage
   map](../../../docs/reconciliation/step-0-reconciliation-v4.md): encryption
   and app-config hardening are partial) — the catalog must carry these as
   honest status, not silence.

## Workflow

1. **Confirm scope and consumers.** Which frameworks will project from this
   catalog, and who owns it. No target framework or owner named → Stop
   Conditions.
2. **Inventory verified operating controls.** Walk the candidate routes
   above and inspect actual running systems, maintained processes and dated
   evidence. List what operates, where it lives and who runs it. A shipped
   skill alone is a design route, not an implemented mechanism. Map a verified
   control by pointer rather than re-specifying it.
3. **Normalize into the seven domains** using
   [references/common-control-set.md](references/common-control-set.md):
   access control, cryptography, change management, logging & monitoring,
   incident response, vendor management, risk assessment. Add AI-specific
   controls (AI SDLC governance, agent authority, AI risk review) as an
   eighth domain when ISO 42001 / AI RMF is in scope.
4. **Write each control once.** Per control: stable ID, objective (what
   risk it treats), description, named owner, implementing mechanism
   (verified system/process artifact, or MISSING), evidence hook
   (what proves it operates — feeds `compliance-evidence-collector`), and
   status: implemented / partial / missing, with the residue named.
5. **Keep it framework-neutral.** No clause or criteria citations in the
   catalog — framework references are `multi-framework-crosswalk` rows so
   a framework edition change never rewrites the catalog.
6. **Mark gaps honestly.** Controls with no mechanism are `missing`, not
   aspirational prose; partial coverage names what's absent (e.g.
   encryption design review beyond key custody). Remediation ordering is
   `compliance-gap-auditor`'s job — record status here, don't prioritize.
7. **Hand off.** Catalog → projections (selection), crosswalk (references),
   evidence collector (hooks), gap auditor (baseline). Propose as a new
   versioned document; treat any existing catalog as controlled — changes
   as a reviewable diff.

## Output Format

```
COMMON CONTROL SET — <org/system> v<n> (owner: <named human>)
Consumers: <iso-27001-isms-architect | iso-42001-aims-architect | soc2-trust-criteria-mapper | ...>
Domains: access control | cryptography | change mgmt | logging & monitoring |
         incident response | vendor mgmt | risk assessment [| AI governance]
Per control:
  [CC-<domain>-<nn>] <name>
    Objective: <risk treated>
    Owner: <named human/role>
    Mechanism: <verified running system / maintained process — or MISSING>
    Design/review route: <named skill, if useful; not proof of operation>
    Evidence hook: <what proves operation> (→ compliance-evidence-collector)
    Status: implemented | partial (<residue>) | missing
Known residue carried: <e.g. crypto design review, app-config hardening>
Framework references: none here — see multi-framework-crosswalk
```

## Validation Checklist

- [ ] Every control has a stable ID, objective, named owner, mechanism (or
      explicit MISSING), evidence hook, and honest status.
- [ ] Existing implementations are mapped to verified operating systems or
      maintained processes; a shipped skill alone never earns implemented status.
- [ ] All seven domains covered (plus AI governance when 42001/RMF in
      scope); domain gaps stated, not skipped.
- [ ] Zero framework clause/criteria citations inside the catalog.
- [ ] Known residue (the repository's **D8** audit: OWASP Top 10:2025
      crypto/app-config partials) appears as partial/missing status, not silence.
- [ ] Catalog is versioned with an owner; changes proposed as diffs.

## Compliance Precision Rules

- SOC 2 is an AICPA **attestation** (a CPA's examination); ISO 27001/42001
  are **certifiable** management-system standards. Never write
  "SOC 2 certified" anywhere in the catalog or its consumers.
- Do not cite ISO Annex A control counts or IDs here at all — 27001 counts
  are secondary-sourced and 42001 counts conflict across sources; framework
  references live in the crosswalk with their verification flags.
- The ~60–80% cross-framework overlap figure is an industry estimate, not a
  standard-derived number — cite it only as such.
- Market rationale (SOC 2 for US procurement, 27001 via NIS2 pull, 42001 in
  EU public procurement) is positioning, not a standards claim — keep it
  out of control text.

## Gotchas

- Parallel-list drift is the failure this skill exists to prevent: the
  moment a projection writes its own control text instead of selecting
  from this catalog, the frameworks fork and evidence duplicates.
- Control theater: a policy sentence with no mechanism is not a control.
  Mechanism must name something that exists and runs — or status is
  `missing`.
- Vocabulary capture: writing the catalog in one framework's idiom (e.g.
  TSC phrasing) makes the other projections awkward — keep control
  language plain and operational.
- The rebuild temptation: the shipped technical-control skills can guide
  design and review, while verified operating controls are mapped by pointer.
  Neither route justifies rewriting another control's implementation here.
- Owners must be humans/roles, not team abstractions — auditors ask "who",
  and so does `compliance-gap-auditor`.

## Stop Conditions

- No target framework(s) and no catalog owner can be named — stop; an
  ownerless control set is unauditable by design.
- Shipped artifacts contradict each other (e.g. two authorization sources
  disagree) — route to `source-of-truth-reconciler` before cataloging.
- Asked to implement or change a control, not document it — hand to the
  owning skill (`appsec-implementer`, `secrets-identity-hardener`, ...) and
  stop.
- Asked to assert the org is "compliant" or "audit-ready" from this catalog
  alone — that is `compliance-gap-auditor`'s parameterized assessment, and
  even it never issues an audit opinion.
- An existing controlled catalog would be overwritten — propose a diff for
  named-human approval instead (`human-approval-boundary`).

## Supporting Files

- [references/common-control-set.md](references/common-control-set.md) —
  the seven-domain control scaffold with per-domain starter controls and
  the shipped-skill mechanism map.
- `evals/evals.json` — trigger + behavior cases.
- `evals/trigger-evals.json` — discrimination within the compliance cluster
  (foundation vs projections vs crosswalk vs gap audit vs evidence) and
  against `threat-modeler` and `authorization-matrix-designer`.