Skip to main content
ClaudeWave
Skill1.2k repo starsupdated yesterday

iso-27001-isms

Scope an ISO 27001 ISMS and build the Statement of Applicability across Annex A controls. Use when asked to implement ISO 27001, scope an ISMS, build a Statement of Applicability (SoA), or prepare for ISO 27001 certification. Produces an ISMS plan — scope & context, risk-treatment approach, an Annex A control applicability table (the SoA), and a prioritised implementation roadmap.

Install in Claude Code
Copy
git clone --depth 1 https://github.com/mohitagw15856/pm-claude-skills /tmp/iso-27001-isms && cp -r /tmp/iso-27001-isms/plugins/pm-compliance/skills/iso-27001-isms ~/.claude/skills/iso-27001-isms
Then start a new Claude Code session; the skill loads automatically.

SKILL.md

# ISO 27001 ISMS Skill

ISO 27001 certifies a *system* (the ISMS), not a checklist — auditors check that you scoped it, assessed
risk, and can justify which Annex A controls you applied or excluded (the Statement of Applicability).
This skill builds that backbone: scope, risk treatment, and a defensible SoA, so certification is a
documented management system rather than a scramble.

## Required Inputs

Ask for these only if they aren't already provided:

- **ISMS scope** — the products, locations, and information assets in scope (and what's deliberately out).
- **Context & interested parties** — the business, its regulatory/customer security obligations, and key risks.
- **Risk approach** — how you identify, assess, and treat information-security risk (the SoA flows from the risk assessment, not the other way round).
- **Current controls** — what's already implemented across the Annex A domains.

## Output Format

### ISO 27001 ISMS: [organisation]

**1. Scope statement** — the boundary of the ISMS: assets, locations, exclusions and why.

**2. Context & risk** — interested parties and their requirements; the risk assessment method and risk acceptance criteria.

**3. Statement of Applicability (SoA)** — the heart of it: each Annex A control, applicable or not, status, and justification:

| Annex A control | Applicable? | Status | Justification |
|---|---|---|---|
| A.5 Access control policy | Yes | met | Required for customer data |
| A.8 Teleworking | No | n/a | No remote-access to in-scope systems — excluded with rationale |

(Excluding a control is fine — *excluding it without a justification* is an audit finding.)

**4. Risk treatment plan** — the top risks, the treatment (mitigate/accept/transfer/avoid), and the controls that address each.

**5. Implementation roadmap** — prioritised: mandatory clauses 4–10 (management system) first, then the highest-risk Annex A gaps, with owners and dates.

## Programmatic Helper

`scripts/soa_coverage.py` (stdlib only) scores SoA coverage and flags controls excluded without a
justification (the classic finding):

```bash
# soa.json: [{"control":"A.5.1","applicable":true,"status":"met|partial|gap","justification":"..."}, ...]
python3 scripts/soa_coverage.py soa.json
python3 scripts/soa_coverage.py soa.json --json
```

## Quality Checks

- [ ] The ISMS scope is explicit, including deliberate exclusions
- [ ] The SoA covers every Annex A control with an applicable/excluded decision
- [ ] Every excluded control carries a justification (the most common audit finding)
- [ ] The SoA traces to the risk assessment — controls exist to treat identified risks, not for show
- [ ] Mandatory management-system clauses (4–10) are addressed, not just the Annex A controls

## Anti-Patterns

- [ ] Do not exclude a control without a written justification — silent exclusions are audit findings
- [ ] Do not build the SoA before the risk assessment — applicability is *derived* from risk, not guessed
- [ ] Do not treat Annex A as the whole standard — clauses 4–10 (the management system) are mandatory and where many fail
- [ ] Do not mark controls "implemented" without evidence of operation — certification audits sample evidence
- [ ] Do not present this as certification — only an accredited body certifies; this prepares the ISMS

## Based On

ISO/IEC 27001 (ISMS clauses 4–10) and Annex A control set + the Statement of Applicability requirement.
ai-ethics-reviewSkill

Conduct a structured ethical review of an AI or ML feature, model, or product. Use when preparing to deploy an AI system, assessing algorithmic risk, auditing a model for bias, or producing a responsible AI impact assessment. Produces a structured ethics review covering fairness, transparency, privacy, safety, accountability, and societal impact with a risk tier score, pre-deployment checklist, and prioritised mitigations.

ai-product-canvasSkill

Structure AI and ML product decisions with the rigour of any product decision. Use when building AI-powered features, evaluating LLM integrations, designing AI products, or assessing AI readiness. Produces a complete AI product canvas covering problem definition, model approach, data requirements, evaluation framework, UX design, responsible AI checklist, and launch monitoring plan.

design-handoff-briefSkill

Transform feature briefs into structured design briefs that give designers the context they need before opening Figma. Use when asked to write a design brief, create a design handoff, brief a designer on a new feature, or translate a PRD into design requirements. Produces a brief with user goal, emotional context, success criteria, constraints, edge cases, and out-of-scope boundaries.

experiment-designerSkill

Design statistically rigorous A/B tests and interpret experiment results. Use when asked to design an experiment, run an A/B test, calculate sample size, interpret test results, or assess whether an experiment was successful. Produces a complete experiment design with hypothesis, sample size, run time, success criteria, and risk flags — or a results interpretation with ship/iterate/kill recommendation.

multi-source-signal-synthesiserSkill

Synthesises user signals from multiple research sources into a unified, weighted insight brief. Use when you have data from interviews, support tickets, NPS verbatims, app reviews, or sales calls and need to reconcile contradictions, surface the underlying need behind requests, or answer 'what are users really telling us'. Produces ranked insights with confidence ratings, source weighting rationale, divergent signal analysis by user segment, and a research gap identification section.

data-analysis-standardSkill

Structure a product data analysis, metric deep-dive, funnel analysis, or cohort study. Use when asked to analyse product metrics, investigate a drop in conversion, explain a data change to stakeholders, or find the root cause of a metric movement. Produces a structured analysis with question, root cause, confidence level, and recommended action.

product-health-analysisSkill

Interpret product metrics against goals and surface actionable signals. Use when asked to analyse product health, review key metrics, investigate a performance issue, produce a health report, or assess product-market fit signals. Produces a structured health report with RAG status, trend analysis, root cause hypotheses, and prioritised actions.

retention-analysisSkill

Structure a retention analysis, churn investigation, or engagement deep-dive for any product team. Use when asked to analyse user retention, investigate churn, measure DAU/MAU, or build a retention improvement plan. Produces a retention snapshot with root cause hypotheses, aha-moment correlation, and prioritised interventions.