| name | iso27001 |
| description | ISO 27001 Information Security Management System: gap analysis, risk assessment, control implementation (Annex A), ISMS documentation, certification readiness, and surveillance audit preparation |
ISO 27001 Skill
When to activate
- Planning or preparing for ISO 27001 certification
- Running a gap analysis against ISO 27001:2022 controls
- Conducting an ISMS risk assessment (required by Clause 6)
- Selecting and implementing Annex A controls (93 controls across 4 domains)
- Preparing the Statement of Applicability (SoA)
- Preparing for a certification audit or surveillance audit
When NOT to use
- SOC 2 compliance — different framework, use the soc2-compliance skill
- GDPR compliance — use the gdpr-expert skill (ISO 27001 + GDPR overlap but are separate)
- ISO 13485 (medical devices) or ISO 42001 (AI management) — different standards
- Quick security hardening without a management system — just fix the security issues directly
Instructions
Gap analysis
Run an ISO 27001:2022 gap analysis for [organisation].
Organisation: [describe — size, industry, locations]
Certification goal: [initial certification / re-certification / surveillance]
Current security maturity: [none / basic / intermediate / advanced]
Scope of ISMS: [what systems, locations, processes are in scope]
ISO 27001:2022 structure:
- Clauses 4-10: Management system requirements (mandatory — cannot exclude)
- Annex A: 93 information security controls across 4 themes (can exclude with justification)
MANDATORY CLAUSES GAP CHECK:
Clause 4 — Context:
□ Internal and external issues identified and documented
□ Interested parties (stakeholders) and their requirements documented
□ ISMS scope defined and documented
□ Information security policy drafted, approved, communicated
Clause 5 — Leadership:
□ Top management commitment documented (not just delegated to IT)
□ Roles and responsibilities for ISMS assigned in writing
□ Information security policy signed by top management
Clause 6 — Planning:
□ Information security risk assessment process defined and documented
□ Risk criteria (acceptable risk threshold) defined
□ Risk assessment conducted covering all assets in scope
□ Risk treatment plan produced for unacceptable risks
□ Information security objectives set and measurable
□ Statement of Applicability (SoA) — all 93 Annex A controls addressed
Clause 7 — Support:
□ Resources for ISMS allocated
□ Security awareness and training programme in place, records kept
□ Documented information (policies, procedures) managed and controlled
□ Communication process for internal/external security communications
Clause 8 — Operation:
□ Risk assessment run at least annually (or when significant changes occur)
□ Risk treatment implemented per the treatment plan
□ All operational controls from Annex A implemented (or excluded with justification in SoA)
Clause 9 — Performance Evaluation:
□ Security monitoring and measurement defined
□ Internal ISMS audit programme established and conducted at least annually
□ Management review of ISMS at least annually — minutes documented
Clause 10 — Improvement:
□ Nonconformities identified, root-cause analysed, corrective actions taken and documented
□ Continual improvement process active
ANNEX A DOMAIN GAP CHECK (4 themes, 93 controls):
Theme 5 — Organisational Controls (37 controls):
□ Information security policies (5.1)
□ Information security roles and responsibilities (5.2)
□ Segregation of duties (5.3)
□ Management responsibilities (5.4)
□ Information security in project management (5.8)
□ Supplier relationships and ICT supply chain (5.19-5.22)
□ Incident management (5.24-5.28)
□ Business continuity and ICT readiness (5.29-5.30)
□ Intellectual property and privacy (5.32-5.34)
Theme 6 — People Controls (8 controls):
□ Screening / background checks (6.1)
□ Terms and conditions of employment including security (6.2)
□ Security awareness and training (6.3)
□ Disciplinary process for security breaches (6.4)
□ Remote working security (6.7)
Theme 7 — Physical Controls (14 controls):
□ Physical security perimeter (7.1)
□ Physical entry controls (7.2)
□ Clear desk and clear screen (7.7)
□ Equipment maintenance and secure disposal (7.9, 7.14)
Theme 8 — Technological Controls (34 controls):
□ User endpoint device security (8.1)
□ Privileged access rights management (8.2)
□ Information access restriction (8.3)
□ Access to source code (8.4)
□ Secure authentication (8.5)
□ Capacity management (8.6)
□ Malware protection (8.7)
□ Technical vulnerability management (8.8)
□ Configuration management (8.9)
□ Data leakage prevention (8.12)
□ Backup (8.13)
□ Redundancy / availability (8.14)
□ Logging (8.15-8.16)
□ Network security and segmentation (8.20-8.22)
□ Encryption (8.24)
□ Secure development (8.25-8.31)
□ Security testing (8.29)
Rate each: ✅ Implemented / 🟡 Partial / 🔴 Not implemented / N/A (excluded — justify in SoA)
Output: prioritised gap register with effort estimates.
Risk assessment
Conduct an ISO 27001 information security risk assessment.
Assets in scope: [information assets, systems, processes — or describe the ISMS scope]
Risk methodology: [asset-based (classic) / scenario-based]
Risk criteria: [define acceptable risk threshold — e.g. score < 6 on a 5×5 matrix]
Asset-based risk assessment process:
STEP 1 — Asset inventory:
For each information asset:
- Asset name and type (data / system / process / physical)
- Asset owner
- Confidentiality classification (Public / Internal / Confidential / Secret)
- Dependencies (what systems/people access this asset)
STEP 2 — Threat identification:
Common threats per asset type:
- Data: unauthorised access, data breach, ransomware, accidental loss
- Systems: malware, DDoS, unauthorised admin access, misconfiguration
- Personnel: phishing, insider threat, social engineering, accidental disclosure
- Physical: theft, fire, flooding, equipment failure
STEP 3 — Vulnerability identification:
What weaknesses could allow the threat to exploit the asset?
- No MFA (vulnerability) → account compromise (threat)
- Unpatched systems → malware exploitation
- No access review → privilege creep
- No backup → ransomware impact
STEP 4 — Risk scoring:
Likelihood (1-5): how likely is the threat to occur given current vulnerabilities?
Impact (1-5): what would be the consequence (confidentiality, integrity, availability)?
Risk score = Likelihood × Impact (range 1-25)
Risk acceptance threshold: [e.g. score ≤ 6 = acceptable, > 6 = requires treatment]
STEP 5 — Risk treatment options:
- Modify: implement controls to reduce likelihood or impact
- Retain: accept the risk (only for acceptable risks with documented justification)
- Avoid: cease the activity that creates the risk
- Transfer: insurance, outsourcing with contractual security obligations
Risk register format:
| Asset | Threat | Vulnerability | L | I | Score | Treatment | Control(s) | Residual Score | Owner |
|---|---|---|---|---|---|---|---|---|---|
Generate the risk assessment for my ISMS scope.
Statement of Applicability
Build the Statement of Applicability (SoA) for [organisation].
Context: The SoA is a mandatory document (ISO 27001 Clause 6.1.3) listing all 93 Annex A controls with:
- Whether each control is applicable (included or excluded)
- Justification for inclusion or exclusion
- Implementation status (implemented / planned / not applicable)
- Reference to evidence of implementation
SoA format:
| Control | Title | Applicable? | Justification | Status | Evidence Reference |
|---|---|---|---|---|---|
| 5.1 | Policies for information security | YES | Required for ISMS foundation | Implemented | IS-POL-001 |
| 5.8 | Information security in project management | YES | All development projects in scope | Partial | Project template v2 |
| 6.7 | Remote working | YES | 90% remote workforce | Implemented | Remote work policy |
| 7.1 | Physical security perimeters | NO | Cloud-only infrastructure; no office premises in scope | N/A | Scope definition §3.2 |
Common valid exclusions with justification:
- Physical controls (7.x): "organisation operates fully in cloud with no physical premises in scope"
- Development controls (8.25-8.31): "organisation does not develop software; all systems are COTS"
- Supplier-specific controls: if no third-party suppliers in scope
Rules for exclusions:
- Only exclude if the risk assessment shows no relevant risk
- Cannot exclude a control just because it's hard to implement
- Auditors scrutinise exclusions — be prepared to justify each one
Generate the SoA for my organisation with appropriate inclusions, exclusions, and status.
Example
User: We're a 40-person cloud-native B2B SaaS. No physical offices, all remote, AWS infrastructure, third-party code. We want ISO 27001. How long will it take and what do we do first?
Claude's roadmap:
For a 40-person cloud-native SaaS, ISO 27001 certification typically takes 9-14 months. Here's the realistic breakdown:
Phase 1 — Foundation (Months 1-3):
- Define ISMS scope (cloud infrastructure + product + data — exclude physical premises with justification)
- Write information security policy (1 page, signed by CEO)
- Run first risk assessment — for cloud-native companies, focus on: cloud misconfiguration, account compromise, supply chain (third-party dependencies), ransomware, insider threat
- Produce risk treatment plan
Phase 2 — Control implementation (Months 3-7):
The 10 controls that need the most work in typical SaaS companies:
- 8.2: Privileged access — MFA everywhere, no shared admin accounts
- 8.8: Vulnerability management — scheduled scans, patch SLA defined
- 5.24-5.28: Incident management — documented process, tested at least once
- 8.15-8.16: Logging and monitoring — CloudTrail, security alerts configured
- 8.25: Secure development — code review, SAST in CI pipeline
- 5.19-5.22: Supplier security — security questionnaire for critical vendors (AWS, Stripe, etc.)
Phase 3 — Internal audit + management review (Month 8-9):
Run your first internal audit against the mandatory clauses and key controls. Fix nonconformities. Management review documented with meeting minutes.
Phase 4 — Certification audit (Month 10-14):
Stage 1 audit (documentation review, ~2 days): auditor reviews your ISMS documentation remotely
Stage 2 audit (implementation check, ~3-5 days): auditor tests whether controls actually work
Realistic cost:
- Certification body audit: £8K-£20K for a 40-person company (BSI, Bureau Veritas, TÜV, etc.)
- Consultant (optional but recommended for first certification): £15K-£40K
- Tooling (optional): Sprinto, Tugboat Logic, or ISMS.online (~£500-£2K/month)
- Internal time: CISO/IT lead approximately 30% time for 6 months