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.
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-ismsSKILL.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.Design a 360-degree feedback survey or write a structured 360 feedback report. Use when asked to build a 360 feedback process, write 360 feedback for a colleague, design a feedback survey, or produce a feedback report. Produces either a complete survey instrument with rating scales and open-ended questions, or a structured narrative feedback report with themes, strengths, and development areas.
Decode a 401k or workplace retirement plan — the real cost of its funds, the match's fine print, vesting math, and the plan features worth using or avoiding. Use when someone asks 'is my 401k any good', 'decode my 401k plan', 'which funds should I look at', or 'what fees am I paying'. Produces a fee decode in dollars-over-time, match and vesting math, a fund-lineup triage by cost, and the questions for HR or the plan administrator.
Design statistically rigorous A/B tests for product features, UI changes, onboarding flows, and pricing experiments. Use when asked to set up an experiment, design an A/B test, calculate sample size, or interpret test results. Produces a complete test plan with hypothesis, variant definitions, sample size, duration estimate, guardrail metrics, and a results interpretation guide.
Analyse a finished A/B test and write the readout — the result, whether it's statistically and practically significant, what it means, and the ship/no-ship call. Use when asked to analyse experiment results, write an A/B test readout, interpret test data, or decide whether to ship a variant. Produces a clear verdict with the lift and confidence, segment cuts, the risks (peeking, novelty, sample), and a recommendation. Distinct from planning a test — this reads results.
Generate a WCAG 2.2 accessibility audit checklist and remediation suggestions for any UI or design. Use when asked to audit for accessibility, check WCAG compliance, review a design for a11y issues, or create an accessibility remediation plan. Produces a prioritised checklist with pass/fail assessments and specific fixes.
Plan a trip that actually works with a disability or access need — confirm real accessibility (not just 'accessible' labels), book the assistance in advance, plan for equipment and medication, and build in the contingencies for when access breaks down. Use when someone says 'plan an accessible trip', 'travelling with a wheelchair/disability', 'book assistance for my flight', or 'will this hotel actually work for me'. Produces an access-verified itinerary, an assistance-booking checklist, an equipment/medication plan, and contingency scripts. Verify specifics with providers.
Request a reasonable accommodation at work or in education — frame it around the barrier and the adjustment (not your diagnosis), cite the right process, and navigate the back-and-forth constructively. Use when someone says 'I need a workplace accommodation', 'request reasonable adjustments', 'ADA/Equality Act accommodation', or 'how do I ask for accommodations for my disability/condition'. Produces the request letter, a barriers-and-adjustments map, disclosure guidance, and a plan for the interactive process. Not legal advice — routes to the formal process and to advocacy where needed.
Build a structured account plan for any key customer or target account. Use when asked to create an account plan, key account strategy, strategic account review, or territory plan. Produces a complete account plan with relationship map, growth opportunities, risks, and 90-day action plan.