§ SOC 2 (TSC)

Trust services criteria, with the artifacts an auditor will actually take.

SOC 2 lives or dies on evidence quality. SecHive produces the technical artifacts your service auditor needs for CC4 (control evaluation), CC7 (monitoring) and CC8 (change management) — without the post-test reconstruction.

Book a compliance demo → How the chain works

FrameworkSOC 2 (TSC)

JurisdictionAICPA

ReferenceCC4 / CC7 / CC8

ScopeService organizations · Type I & II

SecHive evidencetechnical

Auditor opinionout of scope

§ Articles → Evidence

Where SecHive evidence fits in SOC 2 (TSC).

The mapping is intentionally narrow. We list only the articles where SecHive produces a directly defensible artifact, and we name the artifact.

Article / control	What it requires	SecHive artifact
CC4.1	Evaluate the design and operating effectiveness of controls.	Per-finding evidence chain with reviewer disposition and retest.
CC7.1	Use of detection and monitoring procedures to identify changes.	Reproducible exploit chains feed detection engineering and tabletop input.
CC7.2	Monitor system components and the operation of those components for anomalies.	Negative evidence and refutation log support anomaly-vs-vulnerability triage.
CC7.3	Evaluate security events to determine response.	Severity, impact, and remediation guidance bound to each promoted finding.
CC7.4	Respond to identified security incidents.	Replay scripts allow IR teams to verify scope of an issue post-fix.
CC8.1	Authorize, design, develop or acquire, configure, document, test, approve, and implement changes.	PR-audit mode produces per-change evidence at integration time.

§ Buyer view

SecHive provides.

What you can put in front of an auditor or a security review.

For the CISO

Mappable evidence per Article 21(2) sub-clause.
Time-bounded findings with severity and impact.
Retest records that close the loop with the engineering team.

For the legal / compliance team

Redaction manifests for cross-border or supplier engagements.
Operator identity stamped on every disposition.
Cosigned attestation on report bundles.

For engineering

Deterministic replay.sh per finding.
Source references when source mode is enabled.
Negative evidence for refuted candidates.

For the auditor

Run-mode-labeled evidence rows.
sha256 binding to underlying artifacts.
Methodology spine consistent across engagements.

§ Sample evidence

A page from the matrix.

SecHive renders an evidence matrix per engagement. Below is one row, redacted.

EVIDENCE ROW — sample

# evidence-row.yaml — redacted
control:    CC7.1  # effectiveness testing
finding_id: VTX-RPL-0042
mode:       black-box
target:     redacted
target_ref: image@sha256:9c4e…  # pinned
artifact:
  path:    artifacts/replay.sh
  sha256:  7c3a…
  signed:  cosign:sechive-key
disposition:
  reviewer:  redacted-operator
  state:    confirmed
retest:
  status:    fixed @ 2026-04-18
  evidence:  artifacts/retest-receipt.json

What an auditor sees

The control id and the finding id, bound together.
A run-mode label (black-box, source-aware, etc.).
A sha256 of the underlying artifact.
A reviewer disposition with operator identity.
A retest record if the finding has been remediated.

See the full output matrix →