Testland
Browse all skills & agents

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.

Install with skills.sh (any agent)

npx skills add testland/qa --skill soc2-evidence-collector
View source

soc2-evidence-collector

Overview

Scope decision - which Trust Services Criteria (TSC) this collector must cover:

CategoryTSC sectionsRequired?
Common CriteriaCC1 - CC9 (35 sub-criteria)Always required
AvailabilityA1Optional (recommended for SaaS uptime claims)
ConfidentialityC1Optional (typical for B2B SaaS)
Processing IntegrityPI1Optional (common for transaction-processing SaaS)
PrivacyP1 - P9Optional (common when handling PII at scale)

Type II is assessed over a 3 - 12 month observation period, so every in-scope control needs continuous evidence available for auditor sampling, not a point-in-time snapshot.

This is a build-an-X workflow - the per-criterion evidence collection script, not a standalone tool. Pair with Vanta / Drata / Secureframe (commercial GRC platforms) for evidence storage + auditor-facing dashboards.

When to use

  • Pre-audit: Type II observation period started; need continuous evidence.
  • Pre-pre-audit: identifying which controls + evidence are testable vs require manual attestation.
  • Post-finding remediation: a previous audit flagged an evidence gap.
  • Adopting a GRC platform (Vanta/Drata/Secureframe) and need evidence-feed configuration.

Step 1 - Identify in-scope criteria

Most SaaS engagements include CC + Availability + Confidentiality. Privacy criteria add when GDPR/CCPA also in scope. Processing Integrity adds for fintech / data-processing SaaS. The full per-criterion scope-decision table is in references/evidence-source-map.md.

Step 2 - Auto-collect evidence per criterion

Map each control to one or more automatable evidence sources; the full control-to-evidence-source table is in references/evidence-source-map.md.

okta_client, aws_iam, github_org, and slack in the examples are injected client interfaces - thin wrappers you provide over the vendor SDKs (okta-sdk-python, boto3, PyGithub, slack_sdk), not pip-importable modules.

Example collector script:

# evidence/cc6_1_logical_access.py
import okta_client, datetime, json

def collect_cc6_1_evidence(start_date, end_date):
    """Per CC6.1: collect user-access audit events for the period."""
    events = okta_client.get_audit_events(
        type='user.session.start',
        start_date=start_date,
        end_date=end_date,
    )
    evidence = {
        'control_id': 'CC6.1',
        'period_start': start_date.isoformat(),
        'period_end': end_date.isoformat(),
        'evidence_type': 'user_access_logs',
        'sample_size': len(events),
        'events': events[:100],   # auditor sample
        'collected_at': datetime.datetime.utcnow().isoformat(),
        'collector': 'soc2-evidence-collector v1.0',
    }
    with open(f'evidence/cc6_1_{start_date.date()}_{end_date.date()}.json', 'w') as f:
        json.dump(evidence, f, indent=2)

Step 3 - Per-control test patterns

Beyond raw evidence collection, write tests that verify the control operates correctly:

def test_cc6_3_offboarded_user_has_no_active_sessions():
    """CC6.3: deprovisioned users must lose all access immediately."""
    user = User.objects.get(email='alice@example.com')
    deprovision(user)

    # Verify across all systems:
    assert not okta_client.user_has_active_sessions(user)
    assert not aws_iam.user_exists(user.aws_username)
    assert not github_org.is_member(user)
    assert not slack.is_member(user)
    # Audit log records the deprovisioning event:
    assert AuditLog.objects.filter(
        actor='hr-system',
        action='deprovision',
        subject=user.email,
    ).exists()

These tests run in CI; their pass/fail history is itself evidence for the auditor.

Step 4 - GRC platform alignment

Default: Vanta - the broadest native-integration coverage (AWS / Okta / GitHub / GSuite / etc.) means the auto-collected evidence (Step 2) only needs to fill gaps the integrations don't cover. Use the alternatives when Vanta doesn't fit:

PlatformUse when
Vanta (default)Standard SaaS stack with mainstream identity / cloud / source-control providers
DrataMulti-framework engagement (SOC 2 + ISO 27001 + HIPAA) where Drata's templates lead
SecureframeBudget-constrained engagement where Vanta's pricing is prohibitive

Across all three, evidence ingest format is platform-specific but the auto-collected JSON (Step 2) feeds the platform's manual-upload UI when no native integration exists for your tooling.

Step 5 - Observation period sampling

Type II auditors typically request:

  • Population list (all instances of a control event during the period - e.g., all PRs merged, all access-grants)
  • Sample (auditor selects 25 - 40 random instances)
  • Per-sample evidence (the specific logs, tickets, approvals)

Your evidence collector should support both:

  • Population queries (SELECT * FROM audit_log WHERE date BETWEEN ...)
  • Per-instance evidence retrieval (full context for one event)

Step 6 - Continuous-monitoring controls

Some controls are continuous (e.g., CC7.1 threat detection) - the evidence is an alert-history feed, not point-in-time samples.

Pattern: daily collector cron job that:

  1. Queries the source system for the previous day's events
  2. Stores in append-only evidence storage (S3 with versioning, immutable)
  3. Records collector-run metadata (when, what, how many records)

Continuity gaps in collector runs are themselves audit findings - make collector failures alert-worthy.

Step 7 - End-to-end recipe

For each in-scope criterion:

  1. ✅ Map criterion to evidence source(s)
  2. ✅ Implement automated collector (Step 2)
  3. ✅ Write per-control test (Step 3)
  4. ✅ Wire evidence into GRC platform (Step 4)
  5. ✅ Verify continuous-collection has no gaps (Step 6)
  6. ✅ Run a mock auditor query (request a sample; verify response is complete + timely)

Worked example

The observation period opens and CC6.3 (access deprovisioning) is in scope. The collector exports offboarding tickets daily; the per-control test test_cc6_3_offboarded_user_has_no_active_sessions runs in CI. A mock auditor sample pulls one departed employee: the ticket and the Okta session-revoke event line up, but the test fails because the ex-employee is still an org member in github_org. GitHub was never wired into the deprovisioning job. The team adds it, the test goes green, and the passing run plus the daily offboarding export becomes the CC6.3 evidence the auditor samples.

Anti-patterns

Anti-patternWhy it failsFix
Manual evidence collection onlyDoesn't scale across observation period; misses sampling intervalsAutomated collector (Step 2)
Trust the auditor will only sample what we expectAudit fails on unexpected sample requestContinuous full-population collection (Step 6)
Evidence stored in mutable storageTampering risk; audit invalidatedAppend-only / immutable storage (Step 6)
Test pass-history not preservedLoses control-effectiveness evidencePersist test results for the period
Skip mock-audit dry runsFirst real audit reveals gapsMock-audit before observation period (Step 7)

Limitations

  • This is a build-an-X workflow. Tests use the team's existing test framework + cloud APIs.
  • SOC 2 has many criteria; this skill is a starting framework, not a complete control library.
  • Trust Services Criteria evolve (current TSP 2017, revised 2022); pin version per audit engagement.
  • GRC platforms are commercial; OSS alternatives (e.g., comply-soc2 / Drata-compatible scripts) exist but are less polished.
  • This skill doesn't replace a SOC 2 readiness consultant.

References

  • aicpa.org/topic/audit-assurance/audit-and-assurance-greaterthan-suitable-trust-services-criteria - AICPA Trust Services Criteria (paywalled; free abstract)
  • vanta.com/solutions/soc-2 - Vanta SOC 2 product
  • drata.com/grc-central/soc-2 - Drata SOC 2 reference
  • secureframe.com/hub/soc-2 - Secureframe SOC 2 hub
  • gdpr-test-patterns, hipaa-test-patterns, audit-trail-test-author - sister test-pattern catalogs

SOC 2 evidence source map

View source (opens in new window)

SOC 2 evidence source map

In-scope criteria decision

Most SaaS engagements include CC + Availability + Confidentiality. Privacy criteria add when GDPR/CCPA also in scope. Processing Integrity adds for fintech / data-processing SaaS.

Criterion categoryTypical scope decision
CC1 Control EnvironmentAlways
CC2 Communication & InformationAlways
CC3 Risk AssessmentAlways
CC4 MonitoringAlways
CC5 Control ActivitiesAlways
CC6 Logical & Physical AccessAlways
CC7 System OperationsAlways
CC8 Change ManagementAlways
CC9 Risk MitigationAlways
A1 AvailabilityIf uptime SLA committed
C1 ConfidentialityTypical for B2B SaaS
PI1 Processing IntegrityIf data-processing accuracy matters
P1 - P9 PrivacyIf handling PII at scale

Control to evidence source

Map each control to one or more automatable evidence sources:

ControlEvidence sourceCollector pattern
CC6.1 Logical accessIDP audit logs (Okta/Auth0/Keycloak)Daily export of user-access events
CC6.2 Access provisioningOnboarding workflow logsPer-hire ticket + access-grant audit
CC6.3 Access deprovisioningOffboarding workflow logsPer-departure ticket + access-revoke audit
CC7.1 Threat detectionSIEM (Datadog, Splunk) alert logsContinuous alert-history feed
CC7.2 System monitoringAPM (Datadog, New Relic) uptime dataDaily uptime report
CC8.1 Change managementGit PR history + CI deploy logsPer-PR audit (reviewer attribution)
A1.1 Availability monitoringSLO dashboardsMonthly availability report
C1.1 Encryption at restCloud KMS audit logsQuarterly attestation
C1.2 Encryption in transitTLS config auditQuarterly attestation

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.

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.

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.