# Iso27001

> ISO 27001 Information Security Management System: gap analysis, risk assessment, control implementation (Annex A), ISMS documentation, certification readiness, and surveillance audit preparation

- Skill: `uitbreidenos/iso27001` (Agent Skill)
- Install (CLI): `npx skillmds@latest add uitbreidenos/iso27001`
- Raw SKILL.md: https://api.skillmd.com/api/skills/uitbreidenos/iso27001/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: UitbreidenOS (https://skillmd.com/u/uitbreidenos)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/uitbreidenos/iso27001

---


# 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):**
1. Define ISMS scope (cloud infrastructure + product + data — exclude physical premises with justification)
2. Write information security policy (1 page, signed by CEO)
3. Run first risk assessment — for cloud-native companies, focus on: cloud misconfiguration, account compromise, supply chain (third-party dependencies), ransomware, insider threat
4. 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

---