iso-27001-isms
GitHub用于规划ISO 27001信息安全管理体系(ISMS)，包括确定范围、分析上下文与风险、构建适用性声明(SoA)及制定实施路线图。强调基于风险评估推导控制措施，确保审计合规。
触发场景
安装
npx skills add mohitagw15856/pm-claude-skills --skill iso-27001-isms -g -y
SKILL.md
Frontmatter
{
"name": "iso-27001-isms",
"description": "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."
}
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):
# 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.
版本历史
- a38bc30 当前 2026-07-05 11:37
