ISO 27001 Evidence Collection

Systematically collect audit evidence for ISO 27001:2022 and SOC 2. This skill provides API-first evidence collection commands, organizes evidence by control, and validates completeness before auditor review.

Security Model

• - No scripts executed — this skill is markdown-only procedural guidance
• No secrets required — works with reference checklists; CLI commands use existing local credentials
• Evidence stays local — all outputs go to the local filesystem
• IP-clean — references NIST SP 800-53 (public domain); ISO controls cited by section ID only

When to Use

Activate this skill when:

1. 1. Preparing evidence package for external audit — 2-4 weeks before auditor arrives
2. Quarterly evidence refresh — update evidence that has aged beyond the audit window
3. After remediation — collect evidence proving a finding has been fixed
4. New system onboarding — establish baseline evidence for a newly in-scope system
5. Evidence gap analysis — identify what's missing before the audit

Do NOT use for:

• - Running the internal audit itself — use INLINECODE0
• SOC 2-only readiness assessment — use INLINECODE1
• Interpreting audit findings — use the internal audit skill

Core Concepts

Evidence Hierarchy (Best to Worst)

Evidence Freshness Requirements

Evidence Naming Convention

CODEBLOCK0

Examples:

• - INLINECODE4
• INLINECODE5
• INLINECODE6

Step-by-Step Workflow

Step 1: Identify Evidence Gaps

Determine what evidence is missing or stale.

CODEBLOCK1

Step 2: Prioritize Collection

Order evidence collection by:

1. 1. Missing evidence for Critical-tier controls — audit blockers
2. Stale evidence past renewal date — auditor will reject
3. Evidence for Relevant-tier controls — expected but not blocking
4. Checkbox-tier evidence — policies and attestations

Step 3: Collect by Platform

Run evidence collection commands grouped by platform to minimize context-switching.

GitHub Evidence

GCP Evidence

Azure Evidence

Google Workspace Evidence

macOS Endpoint Evidence

Step 4: Validate Evidence Package

Check completeness before submitting to auditor:

1. 1. Completeness: Do you have evidence for every applicable control in the SoA?
2. Freshness: Is every piece of evidence within the required age?
3. Format: Are API exports in JSON/CSV with timestamps? Screenshots have system clock visible?
4. Naming: Files follow the naming convention?
5. Coverage: Critical-tier controls have at least 2 forms of evidence?

CODEBLOCK7

Step 5: Generate Evidence Index

Create an index file listing all evidence, mapped to controls:

CODEBLOCK8

DO / DON'T

DO

• - Use API exports with ISO 8601 timestamps over screenshots whenever possible
• Collect evidence from the SOURCE system (IdP, not a secondary report)
• Include metadata: collection date, system version, user who collected
• Store evidence in version-controlled directory with clear naming
• Collect evidence for the AUDIT PERIOD (usually past 12 months), not just current state
• Use screencapture -x ~/evidence/{filename}.png for screenshots (captures without shadow/border)

DON'T

• - Take screenshots without visible system clock (menu bar on macOS, taskbar on Windows)
• Collect evidence from sandbox/staging instead of production
• Manually edit evidence after collection (auditors may verify against source)
• Wait until the week before the audit to collect everything
• Assume stale evidence is acceptable — check freshness requirements above
• Mix evidence from different audit periods in the same file

Troubleshooting

Rules

For detailed evidence collection guidance by topic:

Attribution

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

Runtime Detection

1. 1. Compliance MCP server available (best) — Automated gap detection, evidence freshness tracking
2. Local compliance data available (good) — Reads evidence status from INLINECODE20
3. Reference only (baseline) — Uses embedded checklists and command reference