skilldrop-cli 0.16.3__py3-none-any.whl

skilldrop_cli/data/packs/grc/skills/dpia/reference.md

@@ -0,0 +1,118 @@
+# dpia reference
+
+This summarises the parts of the EU GDPR (Regulation (EU) 2016/679) and the EDPB-endorsed
+guidance a DPIA draft relies on. The UK GDPR keeps the same structure for these articles.
+Check the supervisory authority's own guidance and DPIA list for the country concerned; this
+file is a drafting aid, not legal advice.
+
+## What a DPIA must contain: Article 35(7)
+
+The assessment contains at least:
+
+| Part | What the regulation asks for | Where it goes in the template |
+|---|---|---|
+| (a) | A systematic description of the envisaged processing operations and the purposes of the processing, including, where applicable, the legitimate interest pursued by the controller | §2 Description of the processing |
+| (b) | An assessment of the necessity and proportionality of the processing operations in relation to the purposes | §3 Necessity and proportionality |
+| (c) | An assessment of the risks to the rights and freedoms of data subjects | §4 Risks to individuals |
+| (d) | The measures envisaged to address the risks, including safeguards, security measures and mechanisms to ensure the protection of personal data and to demonstrate compliance, taking into account the rights and legitimate interests of data subjects and other persons concerned | §5 Measures and residual risk |
+
+Other parts of Article 35 that shape the draft:
+
+- **Art. 35(1):** a DPIA is required where processing, in particular using new technologies, is likely to result in a high risk to the rights and freedoms of natural persons. It is done before the processing starts. One assessment may cover a set of similar processing operations with similar high risks.
+- **Art. 35(2):** the controller seeks the advice of the data protection officer, where one is designated.
+- **Art. 35(3):** a DPIA is required in particular for (a) a systematic and extensive evaluation of personal aspects based on automated processing, including profiling, on which decisions are based that produce legal effects or similarly significantly affect the person; (b) processing on a large scale of special categories of data (Art. 9(1)) or of personal data relating to criminal convictions and offences (Art. 10); (c) systematic monitoring of a publicly accessible area on a large scale.
+- **Art. 35(4):** each supervisory authority publishes a list of processing that requires a DPIA. Check it.
+- **Art. 35(9):** where appropriate, the controller seeks the views of data subjects or their representatives (for employees: a works council or union) on the intended processing.
+- **Art. 35(11):** the controller reviews the assessment, at least when the risk represented by the processing changes.
+
+## Screening: the nine criteria
+
+The Article 29 Working Party guidelines on DPIA (WP248 rev.01), endorsed by the EDPB, list
+nine criteria. Processing that meets two or more will in most cases need a DPIA; one can be
+enough.
+
+1. Evaluation or scoring, including profiling and predicting
+2. Automated decision-making with legal or similarly significant effect
+3. Systematic monitoring
+4. Sensitive data or data of a highly personal nature
+5. Data processed on a large scale
+6. Matching or combining datasets
+7. Data concerning vulnerable data subjects (including employees, children, patients)
+8. Innovative use or applying new technological or organisational solutions
+9. Processing that prevents data subjects from exercising a right or using a service or a contract
+
+## Lawful basis: Article 6(1)
+
+Each purpose needs one of:
+
+| Point | Basis | Watch for |
+|---|---|---|
+| (a) | Consent | Must be freely given, specific, informed and unambiguous, and as easy to withdraw as to give. EDPB guidance on consent says employees can rarely give it freely to their employer. |
+| (b) | Contract | Only processing that is necessary to perform a contract with the person, or to take steps they asked for before entering one. |
+| (c) | Legal obligation | Name the law that imposes the obligation. |
+| (d) | Vital interests | Protecting someone's life; rarely the right basis for routine processing. |
+| (e) | Public task | Public authorities and tasks in the public interest set out in law. |
+| (f) | Legitimate interests | Needs a documented balancing test: the interest, why the processing is necessary for it, and why it doesn't override the person's interests and rights. Not available to public authorities performing their tasks. |
+
+Employment processing may also be subject to national rules adopted under **Article 88**.
+
+## Special category and criminal offence data
+
+**Article 9(1)** special categories: racial or ethnic origin, political opinions, religious or
+philosophical beliefs, trade union membership, genetic data, biometric data processed to
+uniquely identify a person, data concerning health, and data concerning a person's sex life
+or sexual orientation.
+
+Processing them needs an Article 6 basis **and** an Article 9(2) condition, for example
+explicit consent (9(2)(a)) or obligations in employment, social security and social
+protection law (9(2)(b)), many of which depend on member state law. Name the condition, or
+raise an open question for the DPO.
+
+**Article 10:** personal data about criminal convictions and offences may be processed only
+under official authority or where authorised by law. Flag it separately.
+
+Watch for inferred special category data: sickness absence is health data; location near a
+place of worship or a clinic can reveal more than intended.
+
+## Transfers outside the EEA: Chapter V
+
+For each recipient outside the EEA, record the country and the mechanism:
+
+- **Adequacy decision** (Art. 45): the European Commission has decided the country gives adequate protection. For the US, the EU-US Data Privacy Framework adequacy decision (July 2023) covers only organisations certified under it; check the recipient's certification and the decision's current status.
+- **Appropriate safeguards** (Art. 46): most often the Commission's standard contractual clauses, or binding corporate rules within a group. Supplement them with a transfer impact assessment where the destination's laws may undermine them.
+- **Derogations** (Art. 49): narrow, for occasional transfers; not a basis for routine, systematic transfers.
+
+Remote access from outside the EEA (a support team viewing data) counts as a transfer.
+
+## Scoring risks to individuals
+
+Score for the person, not the controller. Harms to consider (Recital 75 lists examples):
+discrimination, identity theft or fraud, financial loss, damage to reputation, loss of
+confidentiality, significant economic or social disadvantage, being deprived of rights and
+freedoms, losing control over their personal data, and physical harm.
+
+| | Severity: minimal | Severity: significant | Severity: severe |
+|---|---|---|---|
+| **Likelihood: probable** | medium | high | high |
+| **Likelihood: possible** | low | medium | high |
+| **Likelihood: remote** | low | low | medium |
+
+- **Remote:** needs several things to go wrong, or has not happened in comparable processing.
+- **Possible:** could happen with the current design in the normal course of things.
+- **Probable:** expected to happen to some people, given the design.
+- **Minimal:** inconvenience, quickly overcome.
+- **Significant:** real consequences the person can overcome with some difficulty: lost income, distress, an unfair decision that is later reversed.
+- **Severe:** consequences that are serious or hard to reverse: loss of a job, discrimination, financial hardship, harm to health or safety.
+
+Use the organisation's own scale when it has one.
+
+## Prior consultation: Article 36
+
+- **Art. 36(1):** the controller consults the supervisory authority before processing where the DPIA indicates the processing would result in a high risk in the absence of measures taken by the controller to mitigate the risk. In practice: a residual risk that stays high after the measures.
+- **Art. 36(2):** the authority gives written advice within eight weeks of the request, extendable by six weeks for complex processing.
+- **Art. 36(3)** lists what to send, including the DPIA itself and the DPO's contact details.
+
+## Roles
+
+- The **controller** is responsible for the DPIA. A **processor** assists the controller with it under the Article 28 contract.
+- The **DPO** advises and monitors performance of the DPIA; the DPO does not own the decision. Record the DPO's advice and, if the controller departs from it, why.

skilldrop_cli/data/packs/grc/skills/dpia/templates/dpia.md

@@ -0,0 +1,103 @@
+# DPIA: <processing activity>
+
+> Draft prepared for review by the DPO / privacy counsel. It is not legal advice; the
+> controller decides. Items marked `[to confirm: …]` are unverified and repeated in §7.
+
+| | |
+|---|---|
+| Controller | <legal entity> |
+| Processing activity | <one activity, one line> |
+| Business owner | <name, role> |
+| DPO | <name> |
+| Version / date | 0.1 draft / YYYY-MM-DD |
+| Status | Draft for DPO advice |
+
+## 1. Screening: is a DPIA required?
+
+| Criterion | Applies? | Why |
+|---|---|---|
+| Art. 35(3)(a) systematic, extensive automated evaluation with significant effects | yes / no | |
+| Art. 35(3)(b) large-scale special category or criminal offence data | yes / no | |
+| Art. 35(3)(c) large-scale monitoring of a publicly accessible area | yes / no | |
+| Evaluation or scoring | yes / no | |
+| Automated decision-making with legal or similar effect | yes / no | |
+| Systematic monitoring | yes / no | |
+| Sensitive or highly personal data | yes / no | |
+| Large scale | yes / no | |
+| Matching or combining datasets | yes / no | |
+| Vulnerable data subjects | yes / no | |
+| Innovative technology or new organisational solution | yes / no | |
+| Prevents people exercising a right or using a service | yes / no | |
+
+**Conclusion:** <DPIA required / recommended / not required>, because <criteria met>.
+Supervisory authority's DPIA list checked: <yes, item … / [to confirm]>.
+
+## 2. Description of the processing (Art. 35(7)(a))
+
+**What happens, in order:** <collection → use → sharing → storage → deletion, one line each>
+
+**Purposes:**
+
+| # | Purpose | Lawful basis (Art. 6(1)) | Art. 9(2) condition, if special category | Notes |
+|---|---|---|---|---|
+| P1 | | | | |
+
+Legitimate interest pursued (where (f) is used): <the interest, stated plainly>
+
+**Data inventory:**
+
+| Data category | Special category / criminal? | Data subjects | Source | Recipients and processors | Location / transfer outside EEA and mechanism | Retention |
+|---|---|---|---|---|---|---|
+| | | | | | | |
+
+**Scale:** <number of people, volume, frequency, geography>
+
+**Systems and vendors:** <system, vendor, role (processor / controller), contract in place?>
+
+## 3. Necessity and proportionality (Art. 35(7)(b))
+
+| Question | Answer |
+|---|---|
+| Is each purpose necessary, and does the processing achieve it? | |
+| Could less data, less detail or a less intrusive method achieve it? | |
+| Is each retention period justified? | |
+| How are people told (Arts. 13/14)? Where is the notice? | |
+| How do people exercise access, objection, rectification and erasure? | |
+| Is any decision made about a person without meaningful human review (Art. 22)? | |
+| Are processors bound by an Art. 28 contract? | |
+| Were data subjects or their representatives consulted (Art. 35(9))? | |
+
+## 4. Risks to individuals (Art. 35(7)(c))
+
+| # | Risk to the person (harm, who, how it arises) | Likelihood | Severity | Inherent risk |
+|---|---|---|---|---|
+| R1 | | remote / possible / probable | minimal / significant / severe | low / medium / high |
+
+## 5. Measures and residual risk (Art. 35(7)(d))
+
+| Risk | Measure | Owner | In place / agreed / proposed | Residual likelihood | Residual severity | Residual risk |
+|---|---|---|---|---|---|---|
+| R1 | | | | | | |
+
+Only measures that are in place or agreed lower the residual risk.
+
+## 6. Prior consultation (Art. 36)
+
+<Residual risks still high: none / R… . View: prior consultation looks needed / does not
+look needed, because …. For the DPO to confirm.>
+
+## 7. Open questions for the DPO and the business
+
+| # | Question | Who can answer | Blocks |
+|---|---|---|---|
+| Q1 | | | §… |
+
+## 8. DPO advice and sign-off
+
+| | |
+|---|---|
+| DPO advice | |
+| Advice followed? If not, why | |
+| Residual risks accepted by | |
+| Decision (proceed / proceed with measures / do not proceed / consult authority) | |
+| Next review date or trigger | |

skilldrop_cli/data/packs/grc/skills/risk-register/SKILL.md

@@ -0,0 +1,139 @@
+---
+name: risk-register
+description: 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. Use 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".
+---
+
+# risk-register
+
+You turn a list of worries into a register someone can manage: every risk has a cause, an
+uncertain event and a consequence, a score on a scale written down next to it, an owner
+who is a person, and a treatment with a date. The output is a CSV the user keeps, a short
+summary with a heat map, and the few risks that need a decision this month. You prepare
+material for a qualified risk owner or committee to review; it is not audit or legal advice.
+
+## How to respond
+
+1. **Ask once for what is missing, in one message.** Take what is already given. Ask for
+   at most two things, and offer defaults so the user can reply "go":
+   - **Scope and objective:** whose risks (a project, a business unit, the company) and
+     the objective they threaten. A risk is only a risk *to something*.
+   - **The existing register,** if updating: the CSV or a paste. *Default: start a new one.*
+   - **Scale:** *default 5×5* (below). Use the organisation's own scale when they have one,
+     and write its definitions into the output.
+
+   Named owners, dates and control details come from the user. Never invent a person.
+
+2. **Write each risk as cause → event → consequence.** One sentence each.
+   ✅ *Cause:* "Depot laptops run an unsupported OS build" → *Event:* "Ransomware encrypts
+   the depot file share" → *Consequence:* "Dispatch runs on paper for days."
+   ❌ "Cyber risk." ❌ "Lack of resources." (a cause with no event) ❌ "Project delayed."
+   (a consequence with no cause). Split a risk that has two independent events. Merge two
+   rows that share the same event.
+
+3. **Define the scale before scoring anything.** Default 5×5, likelihood over the review
+   horizon (default 12 months), impact on the stated objective:
+
+   | Score | Likelihood | Impact |
+   |---|---|---|
+   | 1 | Rare: under 5% | Minimal: absorbed in normal operations |
+   | 2 | Unlikely: 5–20% | Minor: small cost or delay, no external notice |
+   | 3 | Possible: 20–50% | Moderate: a milestone or budget line is missed |
+   | 4 | Likely: 50–80% | Major: an objective is missed, customers or a regulator notice |
+   | 5 | Almost certain: over 80% | Severe: the objective fails, or harm to people |
+
+   Score = likelihood × impact. Bands: **low 1–4, medium 5–9, high 10–16, critical 20–25.**
+   Put money or time thresholds on the impact row when the user gives them ("Major: over
+   £250k or a month's delay"). Full definitions are in [`reference.md`](reference.md).
+
+4. **Score inherent, then residual.** Inherent is the risk with no controls operating;
+   residual is with the controls that exist *today*. Planned controls lower the target, not
+   the residual. Residual can never be higher than inherent. If residual equals inherent
+   under `reduce`, the listed controls do nothing, so say so.
+
+5. **Pick one treatment per risk and give it a date.**
+   - **avoid:** stop the activity that creates the risk.
+   - **reduce:** add or strengthen controls; list them and the due date.
+   - **transfer:** insurance, contract terms, outsourcing. The consequence moves; the
+     accountability does not.
+   - **accept:** a deliberate decision, recorded with who accepted it. A high or critical
+     residual risk accepted by its own owner needs sign-off from someone above them.
+
+   Every open risk gets a `next_review` date and a `review_trigger`: the event that reopens
+   it early ("vendor misses an SLA two months running"), not "quarterly".
+
+6. **Write the register** in the columns of
+   [`templates/risk-register.csv`](templates/risk-register.csv). Controls go in one cell,
+   separated by semicolons. Status is `open` or `closed`; close a risk, don't delete it.
+
+7. **Check it with the script.** It validates required fields, score range, real owners,
+   treatment values, dates, residual not above inherent, and overdue reviews and actions,
+   then prints the inherent and residual heat maps and the top risks.
+
+   ```bash
+   # Claude Code
+   python3 "${CLAUDE_SKILL_DIR}/scripts/check_register.py" risk-register.csv --as-of 2026-10-01 --top 5 --out register-check.txt
+   # Other IDEs (from the skill folder)
+   python3 scripts/check_register.py risk-register.csv --as-of 2026-10-01 --top 5 --out register-check.txt
+   ```
+
+   `--scale N` changes the scale (3 to 10). Exit code 0 means valid, 1 means errors in the
+   register, 2 means the file could not be read. Fix every error and rerun before
+   presenting. Report warnings to the user; don't silently fix scores to make them go away.
+
+8. **Present the summary** above the register:
+   - the scale and bands, in one line;
+   - the residual heat map from the script, pasted as printed;
+   - **Decisions needed:** at most five risks, each with the decision and who makes it
+     ("Accept R-006 flood risk at residual 8, or fund racking: Operations Director");
+   - **Overdue:** reviews and actions past their date, with owners;
+   - what changed since the last version, when updating.
+
+**Non-interactive runs** (subagent, CI, headless): a missing scale or horizon becomes the
+default above, tagged `[assumption]` at the top. A missing scope, or no risks to work from,
+emits `BLOCKED: need the scope and objective, and the risks or the source to draw them from`.
+A missing owner is written as an error to resolve, never filled with a guessed name.
+
+## Useful references in this skill
+
+- [`reference.md`](reference.md): scale definitions, cause-event-consequence patterns, treatment rules, review triggers, and the CSV columns
+- [`templates/risk-register.csv`](templates/risk-register.csv): the register header and one annotated row
+- [`scripts/check_register.py`](scripts/check_register.py): the validator and heat map (stdlib, Python 3.9+)
+- [`examples/northwind-register.md`](examples/northwind-register.md): worked example, with the script's real output
+- [`examples/northwind-register.csv`](examples/northwind-register.csv): the example register
+
+## Quality bar
+
+- **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.
+
+## When to use this skill
+
+- ✅ Starting a risk register for a project, a programme, a business unit or the company
+- ✅ Updating scores, owners and dates before a risk committee or steering group
+- ✅ Turning a workshop's sticky notes into scored, owned risks
+- ✅ Checking an existing register CSV for gaps and overdue reviews
+
+## When NOT to use this skill
+
+- ❌ 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`
+
+## Anti-patterns to avoid
+
+- ❌ **The one-word risk.** "Cyber", "people", "budget". Nobody can own, score or treat a category.
+- ❌ **Owner "IT" or "TBD".** A department doesn't answer for a risk; the script rejects these.
+- ❌ **Residual scored on planned controls.** The register then shows a risk as handled months before anything changes.
+- ❌ **Likelihood without a horizon.** "Likely" over a week and over five years are different risks.
+- ❌ **"Review quarterly" as the trigger.** Name the event that should reopen the risk early.
+- ❌ **Everything amber.** If most risks score 9 to 12, the scale definitions aren't being used. Score against the table.
+- ❌ **Deleting closed risks.** Close them with a date and keep them; the history is what an auditor reads.
+- ❌ **Redrawing the heat map by hand.** Paste the script's counts so the picture matches the CSV.

skilldrop_cli/data/packs/grc/skills/risk-register/evals/eval_queries.json

@@ -0,0 +1,34 @@
+[
+  {
+    "query": "Build a risk register for our office move programme",
+    "should_trigger": true
+  },
+  {
+    "query": "Here's our risk log CSV, check it for missing owners and overdue reviews",
+    "should_trigger": true
+  },
+  {
+    "query": "Score these eight risks for likelihood and impact and give me a heat map for the board",
+    "should_trigger": true
+  },
+  {
+    "query": "What are our top risks this quarter and which need a decision from the exec team?",
+    "should_trigger": true
+  },
+  {
+    "query": "Run a STRIDE threat model on our payments API design",
+    "should_trigger": false
+  },
+  {
+    "query": "Do a DPIA for our new employee monitoring tool",
+    "should_trigger": false
+  },
+  {
+    "query": "Map our controls to SOC 2 criteria and list the evidence the auditor will ask for",
+    "should_trigger": false
+  },
+  {
+    "query": "Log the decision we made to accept the flood risk at the riverside depot",
+    "should_trigger": false
+  }
+]

skilldrop_cli/data/packs/grc/skills/risk-register/evals/evals.json

@@ -0,0 +1,19 @@
+{
+  "skill_name": "risk-register",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Build a risk register for Acme Retail's ERP migration programme for the steering group next week. Risks from the kickoff: data migration errors in product master data (owner: Data Lead, Jo Park), the systems integrator's key architect rolling off in January (owner: Programme Director, Lee Grant), cutover clashing with Black Friday trading, and finance users not trained in time (owner: Finance Systems Manager, Ravi Mehta). We use a 5x5 scale. Today is 2026-10-01.",
+      "assertions": [
+        "Every risk is written as a cause, an uncertain event and a consequence, not a one-word category",
+        "The likelihood and impact scale is defined in the output, with what each number means and the review horizon",
+        "Each risk has both an inherent and a residual score, and residual is never higher than inherent",
+        "Each risk has one treatment from avoid, reduce, transfer or accept, with an action and a due date, or a named acceptor for accept",
+        "The cutover risk, which has no owner in the prompt, is flagged as needing an owner rather than given an invented person's name",
+        "Each open risk has a next review date and a review trigger that names an event, not just 'quarterly'",
+        "The summary includes a heat map and at most five risks needing a decision, each naming the decision",
+        "It does not invent controls, people or dates that are not in the prompt; any it proposes are marked as proposals or assumptions"
+      ]
+    }
+  ]
+}

skilldrop_cli/data/packs/grc/skills/risk-register/examples/northwind-register.csv

@@ -0,0 +1,9 @@
+id,title,cause,event,consequence,owner,inherent_likelihood,inherent_impact,residual_likelihood,residual_impact,treatment,controls,due_date,next_review,review_trigger,status
+R-001,Single warehouse management system vendor,The WMS is a single-tenant install supported by one vendor with no exit plan,The vendor ends support or fails,Picking and dispatch stop at all three depots until a replacement is live,Head of Operations (Priya Shah),3,5,2,5,reduce,Escrow agreement for source code; quarterly vendor financial check; exit plan drafted,2026-12-15,2026-11-01,Vendor misses an SLA two months running or announces a sale,open
+R-002,Driver shortage in peak season,Regional driver pool shrank 12% this year and agency rates rose,Not enough drivers are available for November to December peak,Missed delivery windows and contract penalties from two retail customers,Fleet Manager (Tom Okafor),4,4,3,4,reduce,Peak contracts with two agencies signed; overtime pre-approved; route consolidation,2026-10-20,2026-10-15,Agency confirms fewer than 80% of booked drivers,open
+R-003,Ransomware on depot laptops,Depot laptops run an unsupported OS build and staff share a local admin account,Ransomware encrypts depot laptops and the file share,Depot dispatch runs on paper for days and customer data may be exposed,IT Security Lead (Mei Lin),4,5,2,4,reduce,EDR on all endpoints; shared admin account removed; offline backups tested monthly,2026-09-30,2026-10-10,Any EDR detection on a depot device or a failed backup restore,open
+R-004,Fuel price spike,Fuel is 31% of operating cost and contracts have no fuel surcharge clause,Diesel price rises more than 20% within a quarter,Margin on fixed-price contracts falls below zero,Finance Director (Ana Ruiz),3,4,3,3,transfer,Fuel surcharge clause added at each renewal; six-month hedge on 40% of volume,2027-03-31,2026-12-01,Diesel index up 10% in a month,open
+R-005,Loss of ISO 9001 certificate,Two depots have open non-conformities from the last surveillance audit,The certification body suspends the certificate at the next audit,Three tenders that require ISO 9001 are lost,Quality Manager (Ben Hart),2,4,1,4,reduce,Corrective action plan; internal audit at both depots before the surveillance visit,2026-11-30,2026-09-15,Internal audit raises a major non-conformity,open
+R-006,Flooding at the riverside depot,The riverside depot sits in a flood zone and stock is stored at floor level,The depot floods,Stock is lost and that depot is closed for weeks,Head of Operations (Priya Shah),2,4,2,4,accept,Flood insurance in place; stock raised on pallets above 30 cm,,2027-01-15,Environment Agency flood warning for the site,open
+R-007,Key-person dependency in route planning,One analyst maintains the route optimisation scripts,The analyst leaves or is off for an extended period,Routes are planned by hand and fuel use rises,Fleet Manager (Tom Okafor),3,3,1,3,reduce,Second analyst trained; scripts moved to version control with a runbook,2026-08-31,2027-02-01,Either analyst resigns,closed
+R-008,Customer data in shared spreadsheets,Customer delivery addresses are exported to spreadsheets for ad hoc planning,A spreadsheet is emailed to the wrong person or left on a shared drive,A personal data breach that may need reporting to the regulator,Data Protection Lead (Sam Doyle),3,3,3,3,reduce,,2026-12-31,2026-10-30,A misdirected email or a breach report,open

skilldrop_cli/data/packs/grc/skills/risk-register/examples/northwind-register.md

@@ -0,0 +1,127 @@
+# Worked example: Northwind Logistics operations risk register
+
+## Input given to the skill
+
+> We're Northwind Logistics, three depots. I need a risk register for the operations
+> committee on 1 October. Here's what came out of the workshop: the WMS vendor (one vendor,
+> no exit plan), not enough drivers for peak, ransomware on the depot laptops (old OS, shared
+> admin login), fuel prices, our ISO 9001 surveillance audit with two open non-conformities,
+> the riverside depot flooding, route planning depending on one analyst (we've fixed that,
+> a second analyst is trained), and customer addresses floating around in spreadsheets.
+> Owners: Priya Shah (Head of Ops) for WMS and flooding, Tom Okafor (Fleet) for drivers and
+> routing, Mei Lin (IT Security) for ransomware, Ana Ruiz (Finance Director) for fuel, Ben
+> Hart (Quality) for ISO, Sam Doyle (Data Protection Lead) for the spreadsheets. 5x5 is fine.
+> [followed by the controls and dates for each risk]
+
+The scope (operations, 12-month horizon), the scale (default 5×5) and every owner, control
+and date came from the user. The skill wrote each risk as cause, event and consequence, and
+scored inherent and residual.
+
+## The register
+
+[`northwind-register.csv`](northwind-register.csv), eight rows. One row as written:
+
+| Field | Value |
+|---|---|
+| id | R-003 |
+| title | Ransomware on depot laptops |
+| cause | Depot laptops run an unsupported OS build and staff share a local admin account |
+| event | Ransomware encrypts depot laptops and the file share |
+| consequence | Depot dispatch runs on paper for days and customer data may be exposed |
+| owner | IT Security Lead (Mei Lin) |
+| inherent | likelihood 4 × impact 5 = 20 (critical) |
+| residual | likelihood 2 × impact 4 = 8 (medium) |
+| treatment | reduce |
+| controls | EDR on all endpoints; shared admin account removed; offline backups tested monthly |
+| due_date / next_review | 2026-09-30 / 2026-10-10 |
+| review_trigger | Any EDR detection on a depot device or a failed backup restore |
+
+## Script check
+
+Command:
+
+```bash
+python3 scripts/check_register.py examples/northwind-register.csv --as-of 2026-10-01 --top 5
+```
+
+Real output (exit code 0):
+
+```text
+Risk register check
+  file:   examples/northwind-register.csv
+  as of:  2026-10-01
+  scale:  1-5 likelihood x 1-5 impact
+  bands:  low 1-4, medium 5-9, high 10-16, critical 20-25
+  rows:   8 read, 8 valid, 7 open
+
+Errors (0)
+  none
+
+Warnings (2)
+  - line 9 [R-008]: treatment is reduce but no controls are listed
+  - line 9 [R-008]: treatment is reduce but residual equals inherent (9); the controls change nothing
+
+Overdue (2)
+  - line 4 [R-003]: treatment action overdue by 1 day(s) (due_date 2026-09-30), owner IT Security Lead (Mei Lin)
+  - line 6 [R-005]: review overdue by 16 day(s) (next_review 2026-09-15), owner Quality Manager (Ben Hart)
+
+Inherent heat map, open risks (rows = likelihood, columns = impact)
+  L\I |   1   2   3   4   5
+  -------------------------
+    5 |   .   .   .   .   .
+    4 |   .   .   .   1   1
+    3 |   .   .   1   1   1
+    2 |   .   .   .   2   .
+    1 |   .   .   .   .   .
+  low 0, medium 3, high 3, critical 1
+
+Residual heat map, open risks (rows = likelihood, columns = impact)
+  L\I |   1   2   3   4   5
+  -------------------------
+    5 |   .   .   .   .   .
+    4 |   .   .   .   .   .
+    3 |   .   .   2   1   .
+    2 |   .   .   .   2   1
+    1 |   .   .   .   1   .
+  low 1, medium 4, high 2, critical 0
+
+Top 5 open risks by residual score
+  R-002  residual 12 (high), inherent 16  Driver shortage in peak season  [reduce, owner Fleet Manager (Tom Okafor)]
+  R-001  residual 10 (high), inherent 15  Single warehouse management system vendor  [reduce, owner Head of Operations (Priya Shah)]
+  R-004  residual 9 (medium), inherent 12  Fuel price spike  [transfer, owner Finance Director (Ana Ruiz)]
+  R-008  residual 9 (medium), inherent 9  Customer data in shared spreadsheets  [reduce, owner Data Protection Lead (Sam Doyle)]
+  R-003  residual 8 (medium), inherent 20  Ransomware on depot laptops  [reduce, owner IT Security Lead (Mei Lin)]
+
+Result: PASS
+```
+
+## Summary handed to the committee
+
+**Scale:** 5×5, likelihood over 12 months, impact on operations objectives. Low 1–4,
+medium 5–9, high 10–16, critical 20–25.
+
+**Residual heat map:** as printed by the script above. No critical residual risks; two high.
+
+**Decisions needed (3).** Deciders are roles the user did not name; confirm them before the meeting.
+
+1. **R-002 Driver shortage, residual 12 (high).** Approve a third agency contract or accept
+   the penalty exposure on the two retail contracts for peak. *Decider: Operations Director.*
+2. **R-001 WMS vendor, residual 10 (high).** Approve budget to test the exit plan with a
+   second vendor before year end, or accept single-vendor exposure for another year.
+   *Decider: CFO.*
+3. **R-008 Customer data in spreadsheets, residual 9.** No controls are listed and the
+   residual equals the inherent score, so nothing is reducing it yet. Agree a control
+   (for example, planning inside the WMS with exports switched off) and a date.
+   *Decider: Sam Doyle with the Head of Operations.*
+
+**Overdue (2):**
+
+- R-003 ransomware actions were due 30 September, one day ago. Mei Lin to confirm whether
+  the shared admin account removal is complete.
+- R-005 ISO 9001 review was due 15 September. Ben Hart to rescore before the surveillance visit.
+
+**Not raised:** R-006 flooding is accepted at residual 8 (medium) by its owner, which is
+within her authority; R-007 is closed and stays in the register as history.
+
+*This register prepares material for the operations committee and the risk owners to review.
+It is not audit or legal advice.*

skilldrop_cli/data/packs/grc/skills/risk-register/manifest.json

@@ -0,0 +1,43 @@
+{
+  "name": "risk-register",
+  "version": "0.1.0",
+  "description": "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. Use 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\".",
+  "entrypoint": "SKILL.md",
+  "deps": {
+    "npm": [],
+    "pip": []
+  },
+  "env": {
+    "required": [],
+    "optional": []
+  },
+  "related": [
+    "agent-threat-model",
+    "decision-log",
+    "dpia",
+    "nfr-spec",
+    "soc2-evidence-map",
+    "threat-model"
+  ],
+  "handoff": [
+    {
+      "to": "decision-log",
+      "when": "the committee has decided on the top risks",
+      "purpose": "Record each accept, fund or avoid decision with who made it and why.",
+      "fallback": "If decision-log is absent, add the decision, the decider and the date to the risk's controls cell and the summary."
+    }
+  ],
+  "tags": [
+    "risk",
+    "risk-register",
+    "grc",
+    "heat-map",
+    "governance",
+    "compliance"
+  ],
+  "permissions": {"network": [], "commands": [], "files": "named-paths"},
+  "model": {
+    "tier": "standard",
+    "rationale": "Structured writing against a fixed format and scale, with a script doing the checks and counts. Scoring needs some judgment but is bounded by the written scale."
+  }
+}