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.

DomainControlsFocusA.5 Organizational37Policies, roles, incident management, supplier relationsA.6 People8Screening, training, termination, confidentialityA.7 Physical14Facility security, equipment, media — mostly N/A for cloud startupsA.8 Technological34Access control, crypto, logging, SDLC, network securityClauses 4-1030ISMS management system (context, leadership, planning, support, operation, performance, improvement)

Decision Tree: Startup Scoping#

text

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:

TierCountTreatmentCritical~30Full assessment: evidence, interviews, observationRelevant~30Standard check: evidence review, spot-checkCheckbox~33Verify 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

text

# 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:
   • Check: Is there a documented policy/procedure?
   • Check: Is there evidence of implementation?
   • Check: Is there evidence of monitoring/review?
   • Record finding: Conformity / Minor nonconformity / Major nonconformity / Observation
2. For each Relevant control:
   • Check: Is there evidence of implementation?
   • Spot-check one or two items
   • Record finding
3. For each Checkbox control:
   • Verify policy exists or cloud provider SOC 2 covers it
   • Record as conforming or note exception

text

# 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:

markdown

## 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 — grouped by domain, with severity and corrective actions
5. Positive observations — what's working well (auditors do note these)
6. Conclusion — readiness for external audit, recommended timeline

Quick Reference: Top 10 Controls That Fail Most Often#

#ControlCommon FailureFix1A.5.15No periodic access reviewSchedule quarterly reviews, export user lists2A.8.8No vulnerability scanningDeploy Dependabot/Snyk, schedule infra scans3A.5.24Incident response plan untestedRun tabletop exercise, document results4A.8.5MFA not enforced everywhereEnable MFA on all production + admin accounts5A.5.30No business continuity testRun DR failover test, document RTO/RPO results6A.8.15Audit logs not centralizedShip logs to SIEM/CloudWatch/Stackdriver7A.8.9No baseline configurationDocument server/container base images8A.6.1Background checks incompleteVerify all employees have completed screening9A.8.32No change management processRequire PR reviews, document deployment process10A.5.9Asset inventory incompleteExport from cloud provider + endpoint management

DO / DON'T#

DO#

• Collect evidence via API exports with ISO 8601 timestamps — always preferred over screenshots
• Test controls, don't just review documentation — auditors check implementation, not just policies
• Interview people at different levels — manager says one thing, engineer may say another
• Document positive findings — shows the audit is balanced and thorough
• Keep the SoA aligned with actual controls — gaps between SoA and implementation are major findings
• Use screencapture -x ~/evidence/{filename}.png on macOS when screenshots are necessary

DON'T#

• Screenshot portals without visible system clock — auditors will reject undated evidence
• Accept "we have a policy" without checking implementation — "show me" > "tell me"
• Audit your own work — independence requirement (Clause 9.2) means auditors can't audit their own area
• Treat checkbox controls as zero-effort — even N/A controls need justification in the SoA
• Skip ISMS clauses to focus only on Annex A — most first-time failures are in clauses 4-10

Troubleshooting#

ProblemSolutionData is stale (> 7 days old)Refresh from monitoring dashboard or re-export from source systemsCan't determine which controls applyStart with the SoA; if no SoA exists, use the decision tree aboveToo many findings to address before auditPrioritize: fix all Major nonconformities first, then Critical-tier MinorsEvidence timestamps don't match audit periodRe-collect evidence within the audit window (typically 12 months)Cloud provider controls not documentedRequest SOC 2 Type II report from provider; map their controls to your SoAInternal audit has never been doneThis IS the first internal audit — document that in the report and plan for regular cadence

Rules#

For detailed per-control guidance, load the appropriate rules file:

FileCoveragerules/access-control.mdA.5.15-A.5.18, A.8.2-A.8.5 — identity, authentication, authorizationrules/incident-response.mdA.5.24-A.5.29, A.6.8 — incident lifecyclerules/encryption.mdA.8.24, A.8.10-A.8.12 — cryptographic controlsrules/change-management.mdA.8.25-A.8.34, A.8.9, A.8.32 — SDLC and configurationrules/logging-monitoring.mdA.8.15-A.8.17 — audit trails and monitoringrules/business-continuity.mdA.5.30, A.8.13-A.8.14 — backup, DR, BCPrules/people-controls.mdA.6.1-A.6.8 — HR security lifecyclerules/supplier-management.mdA.5.19-A.5.23 — third-party riskrules/isms-management.mdClauses 4-10 — management system operation

Attribution#

Audit procedures and control guidance developed with Internal ISO Audit (Hazel Castro, ISO 27001 Lead Auditor, 14+ years, 100+ audits).

Runtime Detection#

This skill operates in three modes, detected automatically:

1. Internal ISO Audit MCP server available (best) — Live control guidance lookup with auditor hints, NIST cross-references, and full-text search
   • Detected by: internalisoaudit MCP server configured in client
   • Tools: get_control_guidance, list_controls, get_nist_mapping, search_guidance
   • Server: internalisoaudit.com/api/mcp
2. Local compliance data available (good) — Reads compliance/ directory directly
   • Detected by: compliance/status/last_refresh.yaml exists
   • Benefits: Historical test data, evidence status, control mappings
3. Reference only (baseline) — Uses embedded rules/ files, no live data
   • Always available
   • Benefits: Procedural guidance, control descriptions, evidence checklists
   • Limitation: No organization-specific status data

Connectors#

For Internal ISO Audit MCP server setup, see CONNECTORS.md.