iso27001-test-patterns
Reference catalog of ISO/IEC 27001:2022 Annex A test patterns: testable technical controls with code-level assertions for access control (A.8.2-A.8.5), logging and monitoring (A.8.15-A.8.16), cryptography (A.8.24), and secure development (A.8.25-A.8.31), plus evidence patterns for Stage 1 and Stage 2 certification audits and Statement of Applicability scoping. The full 93-control Annex A index (four themes: organizational A.5, people A.6, physical A.7, technological A.8) and the exhaustive per-control test code live in references/. Use when authoring ISMS test coverage for an ISO 27001:2022 certification engagement or gap assessment.
Install with skills.sh (any agent)
npx skills add testland/qa --skill iso27001-test-patternsiso27001-test-patterns
Overview
Per isms.online/iso-27001/annex-a (opens in new window) (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:
| Theme | Controls | Count |
|---|---|---|
| A.5 Organizational | A.5.1 - A.5.37 | 37 |
| A.6 People | A.6.1 - A.6.8 | 8 |
| A.7 Physical | A.7.1 - A.7.14 | 14 |
| A.8 Technological | A.8.1 - A.8.34 | 34 |
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
How to use
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.
| Control | Test asserts | Code |
|---|---|---|
| A.8.2 Privileged Access Rights | Admin identities are separate from user identities; access reviewed within 90 days | reference |
| A.8.3 Information Access Restriction | Access enforced per data classification; role change revokes prior grants | reference |
| A.8.4 Access to Source Code | Only the dev group holds write access | reference |
| A.8.5 Secure Authentication | MFA required (no session without a second factor); weak passwords rejected | Worked example below |
| A.8.15 Logging | Auth events logged with required fields; audit log is append-only | reference |
| A.8.16 Monitoring Activities (NEW) | Sustained failures raise an alert; privileged actions appear in the monitoring stream | reference |
| A.8.17 Clock Synchronization | Log timestamps stay within NTP drift tolerance | reference |
| A.8.24 Use of Cryptography | Approved at-rest algorithm; TLS floor enforced; key rotation on schedule | reference |
| A.8.25 - A.8.31 Secure development | Security-test gate on release; env credential isolation; SAST on every PR | reference |
| A.5.3 Segregation of Duties | A change author is not its sole approver | reference |
| A.5.34 / A.6.8 PII + incident reporting | PII not leaked in API responses; reported events create a trackable ticket | reference |
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 (opens in new window) (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.
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/ (opens in new window) (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.
| Control cluster | Evidence type | Collector pattern |
|---|---|---|
| A.5.15, A.8.2, A.8.3 | IDP audit logs (access grants, reviews) | Daily export from IDP |
| A.8.5 | MFA enforcement logs | Per-login event stream |
| A.8.15, A.8.16 | SIEM event history | Continuous alert feed (append-only) |
| A.8.24 | KMS key configuration + rotation history | Quarterly attestation export |
| A.8.25 - A.8.31 | CI pipeline pass-history (SAST, security tests) | Per-PR run history |
| A.5.18, A.6.5 | Provisioning/deprovisioning tickets | ITSM export per hire/departure |
| A.6.3 | Training completion records | LMS export |
| A.5.26, A.5.27 | Incident post-mortem records | Incident management system export |
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 (opens in new window) (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:
A control marked "not applicable" must include:
The not-applicable verdict logic refuses to accept scope exclusions without all four required fields.
Key compliance gaps tests should catch
| Gap | Detection |
|---|---|
| MFA bypassed on legacy endpoints | A.8.5 per-endpoint test |
| Audit logs deletable via API | A.8.15 append-only assertion |
| Dev pipeline merges without SAST | A.8.28 PR check audit |
| Prod and dev share a database credential | A.8.31 credential isolation test |
| Access rights not reviewed within 90 days | A.8.2 review-recency assertion |
| Same engineer authors and approves a change | A.5.3 PR approval test |
| Log timestamps drift from NTP by more than 1 s | A.8.17 clock-sync test |
Anti-patterns
| Anti-pattern | Why it fails | Fix |
|---|---|---|
| SoA excludes a control with no justification | Stage 1 audit rejects SoA; certification blocked | Document reason + approver + re-review date per clause 6.1.3 |
| Tests run only in CI against dev data | Auditor cannot verify production control operation | Run periodic evidence-collection in production equivalents |
| Audit log evidence stored in mutable storage | Auditor disputes log integrity | Append-only immutable storage (object-store versioning or equivalent) |
| Map one SAST scan to all A.8.25-A.8.31 controls | Each control needs its own dedicated assertion | Per-control test (A.8.29 gates pipeline; A.8.31 tests env isolation separately) |
| Skip clock-sync test (A.8.17) | Log correlation fails during incident forensics | NTP-drift assertion (A.8.17 pattern) |
Limitations
References
Annex A control index (ISO/IEC 27001:2022)
View source (opens in new window)Annex A control index (ISO/IEC 27001:2022)
Deep reference for iso27001-test-patterns SKILL.md. The full 93-control enumeration across the four Annex A themes. Consult when scoping a Statement of Applicability or checking which theme a control belongs to; the SKILL.md keeps only the four-theme summary and the testable-control shortlist.
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. All control IDs, names, and counts below are sourced from isms.online/iso-27001/annex-a (opens in new window) (fetched 2026-06-04); the canonical standard text is paywalled at iso.org and is cited by stable ID "ISO/IEC 27001:2022".
A.5 Organizational controls (37 controls)
Most A.5 controls are verified by document review, policy attestation, or access-control test. The exceptions with automated test patterns are A.5.3 (segregation of duties) and A.5.34 (PII protection) - both in technical-control-test-patterns.md (opens in new window).
| ID | Control name |
|---|---|
| A.5.1 | Policies for Information Security |
| A.5.2 | Information Security Roles and Responsibilities |
| A.5.3 | Segregation of Duties |
| A.5.4 | Management Responsibilities |
| A.5.5 | Contact With Authorities |
| A.5.6 | Contact With Special Interest Groups |
| A.5.7 | Threat Intelligence (NEW 2022) |
| A.5.8 | Information Security in Project Management |
| A.5.9 | Inventory of Information and Other Associated Assets |
| A.5.10 | Acceptable Use of Information and Other Associated Assets |
| A.5.11 | Return of Assets |
| A.5.12 | Classification of Information |
| A.5.13 | Labelling of Information |
| A.5.14 | Information Transfer |
| A.5.15 | Access Control |
| A.5.16 | Identity Management |
| A.5.17 | Authentication Information |
| A.5.18 | Access Rights |
| A.5.19 | Information Security in Supplier Relationships |
| A.5.20 | Addressing Information Security Within Supplier Agreements |
| A.5.21 | Managing Information Security in the ICT Supply Chain |
| A.5.22 | Monitoring, Review and Change Management of Supplier Services |
| A.5.23 | Information Security for Use of Cloud Services (NEW 2022) |
| A.5.24 | Information Security Incident Management Planning and Preparation |
| A.5.25 | Assessment and Decision on Information Security Events |
| A.5.26 | Response to Information Security Incidents |
| A.5.27 | Learning From Information Security Incidents |
| A.5.28 | Collection of Evidence |
| A.5.29 | Information Security During Disruption |
| A.5.30 | ICT Readiness for Business Continuity (NEW 2022) |
| A.5.31 | Legal, Statutory, Regulatory and Contractual Requirements |
| A.5.32 | Intellectual Property Rights |
| A.5.33 | Protection of Records |
| A.5.34 | Privacy and Protection of PII |
| A.5.35 | Independent Review of Information Security |
| A.5.36 | Compliance With Policies, Rules and Standards for Information Security |
| A.5.37 | Documented Operating Procedures |
A.6 People controls (8 controls)
A.6 controls are verified by HR records, contract review, training completion records, and offboarding audits. A.6.8 (Information Security Event Reporting) has an automated test pattern - see technical-control-test-patterns.md (opens in new window).
| ID | Control name |
|---|---|
| A.6.1 | Screening |
| A.6.2 | Terms and Conditions of Employment |
| A.6.3 | Information Security Awareness, Education and Training |
| A.6.4 | Disciplinary Process |
| A.6.5 | Responsibilities After Termination or Change of Employment |
| A.6.6 | Confidentiality or Non-Disclosure Agreements |
| A.6.7 | Remote Working |
| A.6.8 | Information Security Event Reporting |
A.7 Physical controls (14 controls)
A.7 controls are verified by site inspection, physical access-log review, and equipment maintenance records. No automated code-level test patterns exist for A.7; evidence is operational.
| ID | Control name |
|---|---|
| A.7.1 | Physical Security Perimeters |
| A.7.2 | Physical Entry |
| A.7.3 | Securing Offices, Rooms and Facilities |
| A.7.4 | Physical Security Monitoring (NEW 2022) |
| A.7.5 | Protecting Against Physical and Environmental Threats |
| A.7.6 | Working In Secure Areas |
| A.7.7 | Clear Desk and Clear Screen |
| A.7.8 | Equipment Siting and Protection |
| A.7.9 | Security of Assets Off-Premises |
| A.7.10 | Storage Media |
| A.7.11 | Supporting Utilities |
| A.7.12 | Cabling Security |
| A.7.13 | Equipment Maintenance |
| A.7.14 | Secure Disposal or Re-Use of Equipment |
A.8 Technological controls (34 controls)
NEW = added in the 2022 revision. The A.8.x controls verifiable through automated tests have code patterns in technical-control-test-patterns.md (opens in new window).
A.8.1 User Endpoint Devices / A.8.2 Privileged Access Rights / A.8.3 Information Access Restriction / A.8.4 Access to Source Code / A.8.5 Secure Authentication / A.8.6 Capacity Management / A.8.7 Protection Against Malware / A.8.8 Management of Technical Vulnerabilities / A.8.9 Configuration Management (NEW) / A.8.10 Information Deletion (NEW) / A.8.11 Data Masking (NEW) / A.8.12 Data Leakage Prevention (NEW) / A.8.13 Information Backup / A.8.14 Redundancy of Information Processing Facilities / A.8.15 Logging / A.8.16 Monitoring Activities (NEW) / A.8.17 Clock Synchronization / A.8.18 Use of Privileged Utility Programs / A.8.19 Installation of Software on Operational Systems / A.8.20 Networks Security / A.8.21 Security of Network Services / A.8.22 Segregation of Networks / A.8.23 Web Filtering (NEW) / A.8.24 Use of Cryptography / A.8.25 Secure Development Life Cycle / A.8.26 Application Security Requirements / A.8.27 Secure System Architecture and Engineering Principles / A.8.28 Secure Coding (NEW) / A.8.29 Security Testing in Development and Acceptance / A.8.30 Outsourced Development / A.8.31 Separation of Development, Test and Production Environments / A.8.32 Change Management / A.8.33 Test Information / A.8.34 Protection of Information Systems During Audit Testing
Source
Technical-control test patterns (ISO/IEC 27001:2022 Annex A)
View source (opens in new window)Technical-control test patterns (ISO/IEC 27001:2022 Annex A)
Deep reference for iso27001-test-patterns SKILL.md. The complete per-control test-pattern catalog for the A.8.x (plus two A.5/A.6) controls verifiable through automated tests. Consult when authoring the actual test for a control; the SKILL.md keeps the summary table and one fully worked example (A.8.5).
All control IDs and names are sourced from isms.online/iso-27001/annex-a (opens in new window) (fetched 2026-06-04). Test templates use the team's existing frameworks; the API names (e.g. kms.describe_key, siem.get_alerts) must be adapted to the target stack. A.5, A.6, and A.7 controls are otherwise verified through document review and site inspection; automated tests exist only where the control has a runtime behavior.
A.8.2 - Privileged Access Rights
Privileged accounts must be separately provisioned, minimally scoped, and reviewed.
def test_privileged_accounts_are_separate_identities():
"""A.8.2: privileged access uses dedicated accounts, not shared admin."""
admin_accounts = iam.list_accounts(role='admin')
regular_accounts = iam.list_accounts(role='user')
# No account should appear in both sets:
overlap = set(admin_accounts) & set(regular_accounts)
assert overlap == set(), f"Shared admin/user identities: {overlap}"
def test_privileged_access_reviewed_within_period():
"""A.8.2: quarterly access review must be on record."""
last_review = AccessReview.objects.filter(scope='privileged').order_by('-completed_at').first()
assert last_review is not None
assert (timezone.now() - last_review.completed_at).days <= 90A.8.3 - Information Access Restriction
def test_user_cannot_access_data_outside_their_classification():
"""A.8.3: access restriction enforced per data classification."""
user = User.objects.get(clearance='internal')
response = client_for(user).get('/data/confidential/records')
assert response.status_code == 403
def test_role_change_revokes_prior_access_immediately():
"""A.8.3 + A.5.18: reclassification of role removes prior grants."""
user = grant_role(user, 'analyst')
revoke_role(user, 'analyst')
response = client_for(user).get('/reports/analyst-only')
assert response.status_code == 403A.8.4 - Access to Source Code
def test_only_developers_have_write_access_to_source():
"""A.8.4: source code write permissions restricted to dev group."""
non_dev_users = User.objects.exclude(groups__name='developers')
for user in non_dev_users[:10]: # sample
assert not scm.has_write_access(user, repo='main-app'), \
f"{user.email} has unexpected write access"A.8.5 - Secure Authentication
The end-to-end narrated version of this control is the Worked example in SKILL.md; the terse catalog form is below.
def test_mfa_enforced_for_all_users():
"""A.8.5: MFA required; login without second factor must fail."""
response = client.post('/auth/login', json={
'email': 'alice@example.com',
'password': 'correct-password',
# no OTP supplied
})
# Must not issue session token without second factor:
assert response.status_code in [401, 403]
assert 'session_token' not in response.json()
def test_password_complexity_policy_enforced():
"""A.8.5: weak passwords rejected at registration."""
response = client.post('/auth/register', json={
'email': 'bob@example.com',
'password': 'password123', # weak
})
assert response.status_code == 400
assert 'password' in response.json().get('errors', {})A.8.15 - Logging
def test_authentication_events_produce_audit_records():
"""A.8.15: login success and failure must be logged."""
with capture_audit_log() as logs:
client.post('/auth/login', json={'email': 'alice@example.com', 'password': 'wrong'})
events = [e for e in logs if e['event_type'] == 'auth.login.failure']
assert len(events) >= 1
record = events[0]
# Required fields per A.8.15:
assert 'timestamp' in record
assert 'user_identifier' in record
assert 'source_ip' in record
assert 'outcome' in record
def test_audit_log_is_append_only():
"""A.8.15: log records must not be deletable via application API."""
log_id = AuditLog.objects.last().id
response = client.delete(f'/audit-logs/{log_id}')
# No DELETE endpoint should exist; log must survive:
assert response.status_code in [404, 405]
assert AuditLog.objects.filter(id=log_id).exists()A.8.16 - Monitoring Activities (new in 2022)
def test_anomaly_detection_alert_fires_on_excessive_failures():
"""A.8.16: sustained login failures must trigger a monitoring alert."""
for _ in range(20):
client.post('/auth/login', json={'email': 'alice@example.com', 'password': 'wrong'})
# SIEM / monitoring platform must have received the alert:
alerts = siem.get_alerts(rule='excessive_login_failures', within_minutes=5)
assert len(alerts) >= 1
def test_privileged_action_monitored_in_realtime():
"""A.8.16: privileged admin operations must appear in monitoring stream."""
with monitor_events() as stream:
admin_client.post('/admin/users/bulk-export')
assert any(e['category'] == 'privileged_operation' for e in stream.events)A.8.17 - Clock Synchronization
def test_audit_log_timestamps_within_ntp_tolerance():
"""A.8.17: log timestamps must be within NTP drift tolerance (typically 1 s)."""
ntp_time = get_ntp_time()
for record in AuditLog.objects.order_by('-created_at')[:50]:
drift = abs((record.created_at - ntp_time).total_seconds())
assert drift < 1.0, f"Log timestamp drift {drift}s exceeds 1 s NTP tolerance"A.8.24 - Use of Cryptography
def test_data_at_rest_encrypted_with_approved_algorithm():
"""A.8.24: storage encryption must use AES-256 or equivalent."""
config = kms.describe_key(key_id='data-encryption-key')
assert config['KeySpec'] in ['AES_256', 'SYMMETRIC_DEFAULT']
assert config['KeyState'] == 'Enabled'
def test_tls_minimum_version_enforced():
"""A.8.24: TLS 1.2 is the minimum acceptable; TLS 1.0/1.1 must be rejected."""
for old_version in ['TLSv1', 'TLSv1.1']:
connection = attempt_tls_connection(host='api.example.com', version=old_version)
assert connection.failed, f"TLS {old_version} should be rejected but was accepted"
def test_encryption_key_rotation_on_schedule():
"""A.8.24: key rotation must occur within policy window (e.g., 365 days)."""
key_meta = kms.get_key_rotation_status('data-encryption-key')
assert key_meta['KeyRotationEnabled'] is True
last_rotation = key_meta['LastRotatedDate']
days_since = (datetime.utcnow() - last_rotation).days
assert days_since <= 365, f"Key last rotated {days_since} days ago; exceeds 365-day policy"A.8.25 - A.8.31 Secure development controls
The secure-development cluster covers: Secure Development Life Cycle (A.8.25), Application Security Requirements (A.8.26), Secure System Architecture (A.8.27), Secure Coding (A.8.28, new in 2022), Security Testing in Development and Acceptance (A.8.29), Outsourced Development (A.8.30), and Separation of Environments (A.8.31).
def test_security_testing_required_before_production_deployment():
"""A.8.29: release pipeline must gate on security test pass."""
pipeline = ci.get_last_pipeline(branch='main')
stages = [s['name'] for s in pipeline['stages']]
assert 'security-scan' in stages, "Security scan stage missing from pipeline"
security_stage = next(s for s in pipeline['stages'] if s['name'] == 'security-scan')
assert security_stage['status'] == 'passed'
def test_production_and_dev_environments_share_no_credentials():
"""A.8.31: dev/test must not use production secrets."""
prod_db_url = secrets.get('DATABASE_URL', env='production')
dev_db_url = secrets.get('DATABASE_URL', env='development')
assert prod_db_url != dev_db_url, "Production and development share a database credential"
def test_sast_scan_in_pr_pipeline():
"""A.8.28: static analysis for secure coding must run on every PR."""
last_prs = scm.list_merged_prs(count=20)
for pr in last_prs:
checks = scm.get_check_runs(pr['head_sha'])
sast_checks = [c for c in checks if 'sast' in c['name'].lower() or 'semgrep' in c['name'].lower()]
assert len(sast_checks) > 0, f"PR #{pr['number']} merged without SAST check"
assert all(c['conclusion'] == 'success' for c in sast_checks), \
f"PR #{pr['number']} merged with SAST failures"A.5.3 - Segregation of Duties
A.5.3 is organizational but has a testable runtime assertion:
def test_same_user_cannot_approve_their_own_change():
"""A.5.3: the author of a change must not be its sole approver."""
prs = scm.list_merged_prs(count=50)
for pr in prs:
author = pr['author']
approvers = [r['user'] for r in pr['reviews'] if r['state'] == 'APPROVED']
# Author approval alone must not satisfy the merge gate:
non_author_approvals = [a for a in approvers if a != author]
assert len(non_author_approvals) >= 1, \
f"PR #{pr['number']} approved only by its author ({author})"A.5.34 / A.6.8 - PII protection and incident reporting
def test_pii_fields_not_exposed_in_api_responses():
"""A.5.34: PII must not leak via standard API responses."""
response = client.get('/api/users')
users = response.json()['results']
for user in users:
assert 'password' not in user
assert 'ssn' not in user
assert 'tax_id' not in user
def test_security_event_report_creates_ticket():
"""A.6.8: employee-reported security events must generate a trackable record."""
response = employee_client.post('/security/report-event', json={
'description': 'Suspicious email with attachment',
'severity': 'medium',
})
assert response.status_code == 201
ticket_id = response.json()['ticket_id']
assert IncidentTicket.objects.filter(id=ticket_id).exists()Source
Related skills
audit-trail-test-author
Build-an-X for audit-log tests across compliance frameworks - required-events catalog (auth events / privilege change / data access / admin action / config change / export / impersonation); structured-log-format assertions per OWASP A09:2021; tamper-evident chain (hash-chain + signed-batch patterns) for HIPAA §164.312(b) + PCI Req 10 + SOC 2 CC7.3; immutability + retention per framework; query-replay tests for forensic reconstruction. Use when authoring audit log tests for any compliance framework (HIPAA / PCI / SOC 2 / GDPR / etc.).
ccpa-test-patterns
Reference catalog of CCPA + CPRA-aligned test patterns - do-not-sell-or-share opt-out via Global Privacy Control (GPC) signal; data-disclosure category tests per Cal. Civ. Code §1798.110; sensitive personal information (SPI) handling per CPRA §1798.121; deletion-request workflows per §1798.105; CPRA's right to correct (§1798.106) + limit-use (§1798.121). Use when authoring CCPA/CPRA-readiness tests for any product processing California consumer data.
compliance-coverage-scoring
Scores existing tests and evidence against a named compliance framework's criteria list (GDPR, CCPA/CPRA, SOC 2 Trust Services Criteria, HIPAA Security Rule, PCI DSS, ISO/IEC 27001), marking every criterion met, partial, not met, or not applicable with a stated evidence requirement per state, and recording each scope exclusion with its criterion reference, reason, named approver, and re-review date. Produces a readiness self-assessment only: not certification, not an audit opinion, not legal advice. Use when a framework version has been named and an evidence set already exists, and someone needs a per-criterion readiness score before an observation period opens, before a qualified assessor arrives, or in response to a regulator inquiry.
compliance-evidence-generator
Build-an-X workflow that produces auditor-facing evidence packages from automated test results: maps control IDs to test outcomes across any compliance framework (SOC 2, ISO 27001, HIPAA, PCI DSS, GDPR, FedRAMP); generates the control-evidence matrix, timestamped evidence bundles (screenshots, log excerpts, CI exports), and chain-of-custody notes per NIST SP 800-72. Distinct from soc2-evidence-collector (SOC2-only raw log harvest) and from read-only coverage gap analysis that produces no artifacts. Use when an audit engagement requires auditor-ready evidence packages built from existing automated test output.
gdpr-test-patterns
Reference catalog of GDPR-aligned test patterns - data-subject-rights workflows (Art. 15 access, Art. 16 rectification, Art. 17 erasure / "right to be forgotten", Art. 18 restriction, Art. 20 portability, Art. 21 objection); consent recording + revocation per Art. 7; data-residency assertions per Art. 44 - 50 international transfers; breach-notification timing tests per Art. 33 (72 hours); data-minimization assertions in fixtures per Art. 5(1)(c). Use when authoring GDPR-readiness tests for any product processing EU personal data.
hipaa-test-patterns
Reference catalog of HIPAA Security Rule-aligned test patterns - administrative safeguards (45 CFR §164.308: workforce training, access management, contingency planning), physical safeguards (§164.310: facility access, workstation security, device disposal), technical safeguards (§164.312: access control, audit logs, integrity, transmission security); PHI handling assertions in fixtures; minimum-necessary tests per §164.502(b); BAA-scope boundary verification. Use when authoring HIPAA-readiness tests for any product handling Protected Health Information.
pci-dss-control-test-author
Build-an-X for PCI DSS v4.0 scope verification - cardholder data environment (CDE) boundary tests, segmentation tests (PCI Req 1), prohibited-data-storage assertions per Req 3 (no full track data, no CVV/CAV2/CVC2/CID, no PIN/PIN block post-authorization), key-management tests per Req 3.6, encryption-of-transmissions per Req 4. Use when authoring PCI DSS scope-reduction + control tests for any system handling payment-card data.
soc2-evidence-collector
Build-an-X for SOC 2 Type II evidence collection - per-Trust-Services-Criterion test artifacts (Common Criteria CC1.1 - CC9.2; plus Availability A1, Confidentiality C1, Processing Integrity PI1, Privacy P1 - P9 if in scope); auto-collection from CI logs + audit trails + access logs + change-management records; alignment with Vanta / Drata / Secureframe evidence shapes; observation-period sampling. Use when the team is preparing for SOC 2 Type II audit and needs continuous evidence collection automation.