iso-27001-internal-audit

ISO 27001 Internal Audit

Run a structured internal audit against ISO 27001:2022. This skill walks you through scoping, control assessment, evidence collection, and findings generation — following the same workflow a certified auditor uses.

Security Model

• No scripts executed — this skill is markdown-only procedural guidance
• No secrets required — works with public reference data
• IP-clean — all control descriptions are original writing referencing NIST SP 800-53 (public domain). ISO 27001:2022 controls are referenced by section ID only (e.g., "A.5.15"), never by copyrighted title or description
• Evidence stays local — all evidence collection commands output to local filesystem

When to Use

Activate this skill when:

1. Preparing for a surveillance or certification audit — run 4-6 weeks before the external audit
2. Performing quarterly internal audit — ISO 27001 requires at least annual internal audits; quarterly is best practice
3. Post-incident review — assess whether controls failed and what corrective actions are needed
4. New framework adoption — map existing controls to ISO 27001 requirements
5. Onboarding a new compliance tool — validate that automated checks cover the right controls

Do NOT use for:

• Generating the ISO 27001 Statement of Applicability (SoA) from scratch — use iso-27001-evidence-collection for evidence gathering first
• SOC 2-only audits — use soc2-readiness instead
• Reading or interpreting a specific contract clause — use legal agreement skills

Core Concepts

Control Domains (ISO 27001:2022 Annex A)

ISO 27001:2022 has 93 Annex A controls across 4 domains, plus ISMS clauses 4-10 (30 sub-clauses). This skill covers 48 priority Annex A controls (of 93 total) — the most critical per domain for cloud-native startups. Remaining controls are lower-tier or typically N/A for cloud-native organizations.

| Domain | Controls | Focus | |--------|----------|-------| | A.5 Organizational | 37 | Policies, roles, incident management, supplier relations | | A.6 People | 8 | Screening, training, termination, confidentiality | | A.7 Physical | 14 | Facility security, equipment, media — mostly N/A for cloud startups | | A.8 Technological | 34 | Access control, crypto, logging, SDLC, network security | | Clauses 4-10 | 30 | ISMS management system (context, leadership, planning, support, operation, performance, improvement) |

Decision Tree: Startup Scoping

Is the organization cloud-native (no owned data centers)?
├── YES → Mark A.7.1-A.7.9, A.7.11-A.7.13 as "satisfied by cloud provider SOC 2"
│         Focus evidence on: laptops, home offices, mobile devices
├── NO  → Full A.7 assessment required
│
Does the organization develop software?
├── YES → A.8.25-A.8.34 (SDLC controls) are in scope
├── NO  → A.8.25-A.8.34 can be scoped out with justification
│
Does the organization handle PII?
├── YES → A.5.34 (privacy) is critical, cross-reference with GDPR/CCPA
├── NO  → A.5.34 is checkbox tier

Control Tiering

Not all 93 controls fail equally. Prioritize by audit failure frequency:

| Tier | Count | Treatment | |------|-------|-----------| | Critical | ~30 | Full assessment: evidence, interviews, observation | | Relevant | ~30 | Standard check: evidence review, spot-check | | Checkbox | ~33 | Verify policy exists or cloud provider covers it |

For detailed per-control guidance, load rules/<domain>.md.

Step-by-Step Workflow

Step 1: Scope and Context

1. Identify the ISMS scope — What systems, processes, locations, and people are in scope?
2. Gather the Statement of Applicability (SoA) — Which of the 93 Annex A controls apply?
3. Review previous audit findings — What was flagged last time? Are corrective actions closed?
4. Check data freshness — If using a monitoring dashboard or automated testing system, verify data is < 7 days old

# If Internal ISO Audit MCP server is available:
list_controls()                                    # Get all controls with tier classifications
get_control_guidance(control_id="Clause 9.2")      # Check specific ISMS clause requirements

# If reading local files:
# Check compliance/status/last_refresh.yaml for staleness

Step 2: ISMS Clause Assessment (Clauses 4-10)

Most startups fail here — they treat ISMS as documentation, not a functioning management system.

1. Clause 5 (Leadership) — Is there a signed security policy? Who is the ISMS owner? Is there evidence of management review?
2. Clause 6 (Planning) — Is there a risk assessment? Is it current (< 12 months)? Does it reference the SoA?
3. Clause 7 (Support) — Is there a competence matrix? Are training records current?
4. Clause 8 (Operation) — Is the risk treatment plan being executed?
5. Clause 9 (Performance) — Are there metrics? Has an internal audit been done? Is there a management review record?
6. Clause 10 (Improvement) — Are nonconformities tracked? Are corrective actions implemented?

Auditor hint: Auditors look for a CONNECTED chain — risk assessment → SoA → risk treatment plan → evidence of implementation → monitoring → management review → improvement. Any break in the chain is a nonconformity.

Step 3: Annex A Control Assessment

Work through controls by domain, prioritizing Critical tier:

1. For each Critical control:
2. Check: Is there a documented policy/procedure?
3. Check: Is there evidence of implementation?
4. Check: Is there evidence of monitoring/review?
5. Record finding: Conformity / Minor nonconformity / Major nonconformity / Observation

1. For each Relevant control:
2. Check: Is there evidence of implementation?
3. Spot-check one or two items
4. Record finding

1. For each Checkbox control:
2. Verify policy exists or cloud provider SOC 2 covers it
3. Record as conforming or note exception

# If Internal ISO Audit MCP server is available:
list_controls(domain="organizational")                      # List all controls in a domain with tiers
get_control_guidance(control_id="A.5.15")                   # Full guidance: auditor hints, pitfalls, evidence
search_guidance(query="access review", domain="organizational")  # Find related controls by keyword
get_nist_mapping(control_id="A.5.15")                       # Cross-reference to NIST SP 800-53

Step 4: Evidence Collection

For each finding, collect supporting evidence:

1. API exports (preferred) — timestamped JSON/CSV from source systems
2. Screenshots (when API unavailable) — must include visible system clock
3. Interview notes — summarize who said what, when
4. Document review — note document name, version, date reviewed

Evidence naming convention: {control_id}_{evidence_type}_{date}.{ext} Example: A.5.15_user-access-list_2026-02-28.json

For detailed collection commands, load rules/ files or use the iso-27001-evidence-collection skill.

Step 5: Generate Findings

For each nonconformity:

## Finding: [Short title]

- **Control**: A.x.x
- **NIST Reference**: [NIST control ID]
- **Severity**: Major / Minor / Observation
- **Description**: [What was found]
- **Evidence**: [What evidence supports the finding]
- **Root Cause**: [Why the control failed]
- **Corrective Action**: [Specific remediation steps]
- **Due Date**: [Agreed timeline]
- **Owner**: [Person responsible]

Severity definitions:

• Major nonconformity: Control is missing or completely ineffective. Audit failure risk.
• Minor nonconformity: Control exists but has gaps. Must fix before next surveillance audit.
• Observation: Potential improvement. Not required but recommended.

Step 6: Audit Report

Generate a structured audit report:

1. Executive summary — overall ISMS maturity, key findings, recommendation
2. Scope — what was audited, what was excluded
3. Methodology — controls assessed, evidence reviewed, people interviewed
4. Findings