iso27001-test-patterns

Overview

Per isms.online/iso-27001/annex-a (community reference; canonical standard text at iso.org/standard/27001 - paywalled; cite by stable ID "ISO/IEC 27001:2022"):

ISO/IEC 27001:2022 restructured Annex A from 114 controls (2013 edition) to 93 controls across four themes, adding 11 new controls for cloud, threat intelligence, secure coding, and monitoring:

The full 93-control enumeration is in references/annex-a-control-index.md. All control IDs, names, and counts are sourced from isms.online/iso-27001/annex-a/ (fetched 2026-06-04).

This is a pure-reference skill - it defines the test-pattern catalog by control. Tests use the team's existing framework; this skill is the per-control test recipe. A.5, A.6, and A.7 controls are largely verified by document review and site inspection; automated tests exist only where a control has a runtime behavior, and those patterns are catalogued in references/technical-control-test-patterns.md.

When to use

• Preparing for ISO 27001:2022 Stage 1 (documentation) or Stage 2 (implementation evidence) certification audit.
• Scoping a Statement of Applicability (SoA) - deciding which of the 93 Annex A controls apply and what tests demonstrate their operation.
• Gap assessment: identifying which technical controls have no test coverage.
• New feature touches identity, access, cryptography, or secure development - confirming the relevant A.8.x controls are still covered.

How to use

1. List in-scope controls from your SoA and the full index in references/annex-a-control-index.md.
2. Find the testable ones in the summary table below - the A.8.x (plus two A.5/A.6) controls with a runtime behavior a test can assert.
3. Pull the pattern: read the one fully worked control (A.8.5) below to see the shape, then copy the matching per-control code from references/technical-control-test-patterns.md.
4. Adapt the assertion to your stack - the API names (kms.describe_key, siem.get_alerts, scm.list_merged_prs) are placeholders for the real ones.
5. Wire it into a scheduled run on a production-equivalent environment, so each pass emits a timestamped record that becomes Stage 2 evidence (hand off to compliance-evidence-generator).
6. Record not-applicable controls in the SoA with all four required fields (see the SoA section).

Testable controls (summary)

Each row maps a control to what its test asserts; the full multi-assertion code is in references/technical-control-test-patterns.md.

Worked example: proving A.8.5 Secure Authentication end to end

Control (A.8.5): access is granted only after authentication that includes a second factor. Per isms.online/iso-27001/annex-a (fetched 2026-06-04) this is a technological control with runtime behavior, so a Stage 2 auditor wants evidence the enforcement actually holds - not just a policy stating it should. The test proves the control from both sides and emits the pass record that becomes that evidence.

1. Arrange a user whose account has MFA enabled.
2. Assert the negative path - a password-only login issues no session.
3. Assert the positive path - password plus a valid OTP issues a session.
4. Emit evidence - the passing run writes a record keyed to the control ID.

import pyotp

def test_a_8_5_second_factor_is_enforced(client, seed_user):
    """A.8.5: authentication must require a second factor before issuing a session."""
    user = seed_user(email="alice@example.com", password="C0rrect-Horse", mfa_enabled=True)

    # Negative path: password alone must not issue a session token.
    no_factor = client.post("/auth/login", json={
        "email": user.email,
        "password": "C0rrect-Horse",
    })
    assert no_factor.status_code in (401, 403)
    assert "session_token" not in no_factor.json()

    # Positive path: password plus a valid OTP issues a session.
    otp = pyotp.TOTP(user.mfa_secret).now()
    with_factor = client.post("/auth/login", json={
        "email": user.email,
        "password": "C0rrect-Horse",
        "otp": otp,
    })
    assert with_factor.status_code == 200
    assert "session_token" in with_factor.json()

    # Evidence: the pass record feeds the Stage 2 bundle, keyed to the control.
    record_control_evidence(control="A.8.5",
                            test="test_a_8_5_second_factor_is_enforced",
                            outcome="PASS")

Run this on a production-equivalent environment on a schedule (not only in CI against dev data), so the evidence demonstrates the control operating over the audit's observation period. The record_control_evidence call is the seam into compliance-evidence-generator, which assembles the control-evidence matrix and chain-of-custody notes.

Evidence patterns for certification audits

Per isms.online/iso-27001/ (fetched 2026-06-04), certification follows two stages:

Stage 1 audit: Documentation review. Auditor reads the ISMS, policies, risk assessment, and Statement of Applicability. Evidence needed: policy documents, risk register, SoA with justifications.

Stage 2 audit: Implementation verification. Auditor samples control operation. Evidence needed: test pass-history, access-review records, audit logs, deployment pipeline outputs, training records.

Evidence storage requirements: append-only, immutable (object-store versioning or equivalent), with collector-run metadata so auditors can verify continuity.

Statement of Applicability (SoA)

Per isms.online/iso-27001/statement-of-applicability (fetched 2026-06-04):

The SoA is a mandatory document under ISO/IEC 27001:2022 clause 6.1.3. It must list all 93 Annex A controls and for each declare:

• Implementation status (implemented / not implemented)
• Justification for inclusion or exclusion
• Brief description of how the control is implemented, with policy reference

A control marked "not applicable" must include:

1. Which specific control (ID + name, not "general")
2. Reason the control does not apply to the organization
3. Approver (CISO / DPO / compliance officer)
4. Re-review date

The not-applicable verdict logic refuses to accept scope exclusions without all four required fields.

Key compliance gaps tests should catch

Anti-patterns

Limitations

• This skill is a test-pattern catalog, not legal advice and not a substitute for a qualified ISO 27001 lead auditor.
• The standard text (ISO/IEC 27001:2022) is paywalled at iso.org; this skill sources control IDs, names, and counts from isms.online/iso-27001/annex-a/ (fetched 2026-06-04).
• Controls A.5, A.6, and A.7 are largely verified by document review and site inspection; automated test patterns are only listed where a runtime behavior exists.
• ISO/IEC 27001:2022 clause numbering differs from the 2013 edition; verify the edition in scope for any active engagement.
• Test templates use the team's existing frameworks; actual API names (e.g., kms.describe_key, siem.get_alerts) must be adapted to the target stack.

References

• isms.online/iso-27001/annex-a - community Annex A reference (control IDs, names, count; source for this skill; fetched 2026-06-04)
• isms.online/iso-27001/statement-of-applicability - SoA requirements (fetched 2026-06-04)
• isms.online/iso-27001/ - ISMS requirements (clauses 4-10) and certification stages (fetched 2026-06-04)
• iso.org/standard/27001 - canonical ISO/IEC 27001:2022 standard text (paywalled; cite by stable ID "ISO/IEC 27001:2022")
• Full 93-control Annex A enumeration (carries the isms.online Annex A citation): references/annex-a-control-index.md
• Exhaustive per-control test code (carries the isms.online Annex A citation): references/technical-control-test-patterns.md
• soc2-evidence-collector - sister: SOC 2 Type II evidence collection (AICPA TSC)
• gdpr-test-patterns - sister: GDPR per-Article test catalog
• audit-trail-test-author - companion: audit log emission tests (feeds A.8.15 evidence)