Governance, risk and compliance pack reference

Every skill in the Governance, risk and compliance pack — what it makes, when to use it, what it needs, its quality bar, and what it hands off to.

Governance, risk and compliance drafts for compliance leads, DPOs and risk owners: a risk register with a checked heat map, a GDPR data protection impact assessment, a SOC 2 control-to-evidence map, and answers to a customer security questionnaire drawn from your own evidence, each prepared for a qualified person to review.

Skills

dpia

Draft a data protection impact assessment (DPIA) for one processing activity in the structure GDPR Article 35(7) requires — a systematic description of the processing and its purposes, necessity and proportionality, risks to the rights and freedoms of individuals, and the measures to address them — with a data inventory (categories, special category data, data subjects, sources, recipients, transfers outside the EEA, retention), the lawful basis per purpose, a likelihood × severity risk table scored for harm to people, residual risk, a view on prior consultation, and the open questions for the DPO.

Tier heavy · v0.1.0 · SKILL.md · skill page

Use it when the user needs a DPIA or PIA, is launching something that processes personal data in a new or risky way, or asks "do we need a DPIA", "write the DPIA for…", "privacy impact assessment".

A good result:

• The four Article 35(7) parts are all present, in order: description and purposes, necessity and proportionality, risks to individuals, measures.
• Risks are harms to people, scored for likelihood and severity to them. No company-impact rows.
• Every purpose has its own lawful basis, and special category data has an Article 9(2) condition or an open question saying it lacks one.
• Transfers outside the EEA name the destination and the mechanism, or are marked [to confirm].
• Every unknown is visible: [to confirm] in the body and a numbered DPO question, never a guess written as fact.
• Residual risk counts only agreed measures, and the prior consultation view follows from it.
• Article numbers cited are ones the regulation actually contains for that point; when unsure, describe the requirement without a number.

Hands off to: threat-model when the processing runs on a new system whose security design hasn't been assessed; risk-register when the DPIA leaves residual risks the business has accepted.

Not for:

• Security threats against a system design: use threat-model, and feed its findings into the measures section here
• Threats to an AI agent's tools and prompts: use agent-threat-model
• Rules for staff using AI tools: use ai-usage-policy
• Business risks to the company, scored for the company: use risk-register
• Mapping controls to SOC 2 audit evidence: use soc2-evidence-map

risk-register

Build or update an enterprise or project risk register — each risk written as cause, event and consequence, scored for likelihood and impact on a defined scale, inherent and residual ratings, a named owner, a treatment (avoid, reduce, transfer, accept), controls, a due date and a review trigger — with a heat map, the top risks that need a decision, and a stdlib script that validates the register CSV and flags overdue reviews.

Tier standard · v0.1.2 · SKILL.md · skill page

Use it when the user wants a risk register, a risk log, a RAID log's risk section, a heat map, or says "what are our top risks", "update the risk register", "score these risks".

Needs: Python 3 for its scripts (standard library only).

A good result:

• Every risk has a cause, an event and a consequence, each a sentence. No one-word risks.
• The scale is written down in the output, with what each number means.
• Inherent and residual are both scored, and residual counts only controls in place today.
• Every open risk has a named owner (a person or a role a person holds) and a next review date.
• Every treatment has an action and a date, except accept, which names who accepted it.
• The script passes with zero errors before the register is shown, and its heat map is pasted, not redrawn by hand.
• The decision list is short: five or fewer, each naming the decision and the decider.

Hands off to: decision-log when the committee has decided on the top risks.

Not for:

• Security threats against a specific system design, by STRIDE: use threat-model
• Threats specific to an AI agent's tools, prompts and data: use agent-threat-model
• Risks to individuals from processing personal data: use dpia, which scores harm to people, not to the company
• Mapping controls to SOC 2 criteria and audit evidence: use soc2-evidence-map
• Recording a decision once it has been made: use decision-log
• Setting quality targets such as availability or latency: use nfr-spec

security-questionnaire-response

Answer a customer's security questionnaire from your own evidence: each question gets a direct answer (Yes, No, Partial or Not applicable), a short narrative, and the document and section it rests on. Questions the evidence doesn't cover are marked as needing input instead of being answered, and conflicts between sources, stale evidence and answers that would commit you to future work are flagged for the security owner.

Tier standard · v0.1.0 · SKILL.md · skill page

Use it when the user has a vendor security questionnaire, a SIG or CAIQ, a due-diligence spreadsheet or the security section of an RFP to fill in, or says "answer this security questionnaire", "fill in this vendor assessment".

A good result:

• Every Yes, No and Partial cites a document and a place in it.
• Nothing is claimed that the evidence does not show: no certification, test, number or control is invented or upgraded.
• Gaps are visible. Needs-input and flagged questions are counted and listed first.
• Conflicts are shown, not resolved.
• The customer's IDs, order and wording of questions are preserved.

Not for:

• Mapping your controls to SOC 2 criteria and the evidence an auditor wants. Use soc2-evidence-map.
• Assessing a processing activity's risk to individuals under GDPR. Use dpia.
• Finding the threats in a system design. Use threat-model.
• Listing and scoring business risks. Use risk-register.

soc2-evidence-map

Map an organisation's controls to the SOC 2 Trust Services Criteria in scope (Security always, plus Availability, Confidentiality, Processing Integrity or Privacy if chosen), and for each control list the evidence an auditor will ask for, the system it lives in, the owner, how often it is produced, and the gaps — distinguishing Type I (designed and in place at a date) from Type II (operating over a period, sampled from a full population) — as a table and a CSV the team can work from.

Tier standard · v0.1.0 · SKILL.md · skill page

Use it when the user is preparing for a SOC 2 audit or readiness assessment, says "SOC 2 evidence", "map our controls to the TSC", "what will the auditor ask for", "SOC 2 gap analysis".

A good result:

• Every criterion in scope has a control or is listed as a gap. The coverage table shows it.
• Every control is written as who, what, how often, with what record. No adjectives in place of a mechanism.
• Evidence is specific to the report type: Type I names design evidence; Type II names the population, its source system, and the per-sample record.
• Criteria IDs appear only where reference.md gives them; anything else is described in words.
• System, owner and frequency are filled for every row, or the blank is itself a gap.
• Status is honest: a control with no record, or one that started mid-period, is not in place.
• Proposed controls are marked proposed, never presented as existing.

Hands off to: risk-register when the company has no risk assessment, which the risk assessment criteria expect.

Not for:

• Finding security threats in a system design: use threat-model
• Scoring business risks for a risk committee: use risk-register; SOC 2's risk assessment criteria expect one, and this map can point to it
• A GDPR assessment of one processing activity: use dpia
• Writing the security or reliability targets for a service: use nfr-spec
• A policy for staff use of AI tools: use ai-usage-policy

Loops

comply

Take a change that carries risk (a launch, a new vendor, a new use of personal data) to a risk position its owner has signed: a risk register scored inherent and residual, a DPIA when personal data is processed, the evidence behind every control the ratings rely on, a script that checks the register, and a sign-off only the named owner can give.

Cap: 3 returns before BLOCKED. LOOP.md

Included from core

Installed with this pack. Details: Core pack reference.

• brief-intake: Turn raw mess — a Slack thread, meeting transcript, Jira ticket, half-written Notion page, email chain, or paragraph of free-form context — into a structured brief that the downstream skill (adr-generator, design-doc, runbook-generator, exec-summary, slide-outliner) can consume without further intake.
• context-graph: Map the decisions behind a codebase from its ADRs, RFCs and design records — each record's status and date, what supersedes or amends what, which records cite which, the files and folders each decision governs, and with git the commits that implemented it and the commits that changed each decision's code since it was made, and who made them — then answer "why is it like this?" from the record and check the record is still true. Finds supersessions only one side records, current decisions pointing at code that is gone, code that has drifted from its decision, two current decisions governing the same path, and references to records that don't exist.
• council-review: Convene a council of distinct senior-engineer personas (Architect, Security, Operator/SRE, Pragmatist, User-Advocate, plus optional bench seats) to deliberate a decision, design, or code change — each takes an independent stance, the genuine disagreements are surfaced as named cruxes, and a Chair issues a reconciled verdict that records dissents and states what would change the decision. The "Claude Council."
• doc-critique: Review an existing document — ADR, design doc, runbook, exec summary, tech-comparison matrix, deck outline, decision log — and produce a structured critique against the same quality bars the skilldrop generators enforce. Categorizes findings by severity (blocker / major / minor / nit), points to the exact section/line, and suggests a concrete fix for each.
• output-hygiene: Review agent-written text before it ships and strip the machine artifacts it carries — invisible Unicode, non-breaking spaces, homoglyphs, harness-added provenance trailers, trailing chat closers — then flag the prose tells a script cannot catch, each quoted with a rewrite.

Edit this page on GitHub · View source