本文へ移動
cccskills
無料GitHub で公開

soc2-evidence-collector

Build-an-X for SOC 2 Type II evidence collection and auditor-facing packaging - 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. Cross-framework evidence packaging (control-evidence matrix, timestamped bundles, chain-of-custody notes per NIST SP 800-72 - also for ISO 27001 / HIPAA / PCI DSS / GDPR / FedRAMP) lives in references/evidence-packaging.md. Use when the team is preparing for SOC 2 Type II audit and needs continuous evidence collection, or when any audit engagement requires auditor-ready evidence packages built from automated test output.

日本語の概要は準備中です。原文の説明を表示しています。

testland/qaスター 13(GitHub 13 + cccskills 0)
連携ツールSlackAWS

実行スコア 未検証

インストール方法を見る

含まれるファイル(5)

  • SKILL.md10.0 KB
  • .tessl-plugin/plugin.json994 B
  • references/evidence-packaging.md15.0 KB
  • references/evidence-source-map.md1.8 KB
  • references/grc-delivery-and-ci-automation.md2.1 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

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 - Package evidence for the auditor

Raw collected evidence (Steps 2 - 6) still needs assembling into the deliverable an auditor or GRC platform receives: the control-evidence matrix, bounded log excerpts, chain-of-custody notes (SHA-256 hashed, per NIST SP 800-72), and a deterministic archive. The full cross-framework packaging workflow - it also handles ISO 27001, HIPAA, PCI DSS, GDPR, and FedRAMP control IDs - is in references/evidence-packaging.md; GRC-platform delivery and CI automation of the whole run is in references/grc-delivery-and-ci-automation.md.

Step 8 - 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. ✅ Package the evidence for delivery (Step 7)
  7. ✅ 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 8)

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)
  • Cross-framework evidence packaging (carries the NIST SP 800-72 chain-of-custody + ISACA citations): references/evidence-packaging.md
  • GRC-platform delivery + CI automation (carries the PCI DSS retention citation): references/grc-delivery-and-ci-automation.md
  • 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

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

コメント

ログインなしで書き込めます。使ってみた感想、質問、動かなかった環境などを気軽にどうぞ。

まだコメントはありません。最初のコメントを書いてみませんか。

送信するとすぐに公開されます。メールアドレスや電話番号などの個人情報は書かないでください。URL は 2 つまでです。

0 / 1000 文字

このフォームは reCAPTCHA で保護されており、Google のプライバシーポリシーと利用規約が適用されます。

同じリポジトリのスキル

Builds a CI gate that fails the build on **new** WCAG / a11y violations introduced by a PR while grandfathering pre-existing violations on a per-rule / per-page baseline. Aggregates verdicts from axe-core / pa11y / Lighthouse a11y / WAVE / IBM Equal Access scans. Use when a project has accumulated a11y debt and a strict "zero violations" gate would block every PR - the ratchet pattern lets the team ship while preventing regressions.

日本語の概要は準備中です。原文の説明を表示しています。

testland/qa132026年10月20日 更新

Workflow skill that builds an A/B-test validity checklist from an experiment proposal, walking the canonical design-correctness gates - pre-registered OEC/power/guardrails, randomization unit + SRM check, assignment integrity, telemetry, peeking discipline, novelty/primacy, post-experiment SRM re-check - into a per-experiment checklist + sign-off form. Use when launching, auditing, or governing an experiment. For pitfall mechanics (guardrails, peeking) see experiment-results-interpreter's references; to read an already-valid result use experiment-results-interpreter; for per-SDK harness tests use experiment-sdk-testing - this gates DESIGN, not SDK code.

日本語の概要は準備中です。原文の説明を表示しています。

testland/qa132026年10月20日 更新

The single install-flow skill: the reference contract for the PWA install flow (installability gate fields, `beforeinstallprompt` handshake, per-platform paths - Android WebAPK / iOS Share menu / Firefox no-op - and the `display-mode` post-install signal, in references/install-flow-reference.md) plus the build-an-X workflow that emits the Add-to-Home-Screen suite. Walks the four-stage timeline, emitting one test per gate cell per [web.dev/articles/install-criteria][install-criteria], the deferred-prompt → `prompt()` → `userChoice` chain per [web.dev/articles/customize-install][customize-install], the iOS Safari manual-metadata branch (`apple-touch-icon`) per [web.dev/learn/pwa/installation][learn-pwa], and the post-install `(display-mode: standalone)` MQ assertion. Output: a Playwright spec with per-stage cells plus a coverage matrix. Use when a PWA's manifest, icons, or install handler change, when install conversion drops at an unknown stage, or when triaging a flaky install assertion.

日本語の概要は準備中です。原文の説明を表示しています。

testland/qa132026年10月20日 更新

Build-an-X workflow that uses an LLM to map existing tests to spec sections - given a spec doc + the test suite, the LLM identifies which tests cover which sections, surfaces uncovered sections (gap), and recommends specific tests to add. Output is a coverage matrix per spec ID. Scope is mapping tests that already exist and naming the gaps, not authoring tests for new acceptance criteria. Use when a spec doc and a test suite both exist but nobody can say which requirements are actually covered - before a release sign-off, an audit, or a decision about where to spend the next round of test effort.

日本語の概要は準備中です。原文の説明を表示しています。

testland/qa132026年10月20日 更新

Generates tests from natural-language specs (acceptance criteria, user stories, requirements) using an LLM, with confidence scoring per test case (LLM self-assessment plus heuristics: assertion quality, naming, completeness), batching uncertain cases for human review, and integration with the team's existing test framework. Use when the user asks to generate unit tests from acceptance criteria, convert user stories to test cases, automate test creation from requirements, or augment a spec-driven test suite with AI-generated stubs that are then curated before merge.

日本語の概要は準備中です。原文の説明を表示しています。

testland/qa132026年10月20日 更新

Configures Allure Report (test-runner adapter install, `allure-results` directory wiring, `categories.json` for failure classification, `history-trend.json` retention via the copy-history-between-runs pattern), runs the Allure CLI to convert `allure-results` to a static HTML site, and uploads the report as a CI artifact. Use when the team needs richer test reporting than JUnit XML - step-level attachments, per-test history, retry tracking, and severity / epic / feature labeling across framework-agnostic adapters (pytest, Jest, JUnit, TestNG, NUnit, Mocha). As a rich static HTML report generator, it is the open-source alternative to the sunset ExtentReports (JVM/.NET per-test HTML narrative); for hosted cross-run flakiness analytics rather than a static per-run report use currents-integration.

日本語の概要は準備中です。原文の説明を表示しています。

testland/qa132026年10月20日 更新

testland のスキルをすべて見る

このスキルの問題を報告する