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, implementing mechanism, and evidence hook, then projected per framework instead of rebuilt per framework. Controls MAP to shipped implementations by name (authorization-matrix-designer, rls-policy-auditor, audit-log-architect, incident-response-runbook, and the rest of the Phase 3/4 packs) — this skill documents and maps, never rebuilds. 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

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 concrete implementing mechanism (named shipped skill or system artifact), its evidence hook for compliance-evidence-collector, and an honest implementation status. The batch premise (D9): most technical controls already exist in the shipped Phase 3/4 packs — this skill MAPS them into compliance shape and exposes what is genuinely 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. Shipped control artifacts to map, not rebuild: 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 Phase 1.5 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 (e.g. OWASP D8: encryption-in-transit/at-rest design 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 existing controls from shipped artifacts. Walk the inputs above and list what already operates: mechanism, where it lives, who runs it. Map-don't-rebuild is the rule — a control that exists gets a pointer, never a re-specification.
3. Normalize into the seven domains using 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 (named skill/system artifact — evidence it exists), 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: <named shipped skill / system artifact / process — or MISSING>
    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 by name to shipped artifacts — nothing that exists was re-specified from scratch.
• 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 (e.g. D8 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 Phase 3/4 skills already implement most technical controls; re-specifying them here creates a second source of truth that rots. Point, don't paraphrase.
• 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 — 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.