A sample SOC 2 Type II evidence pack showing some questions an assessor typically asks, how the engine satisfies each, and the records that prove it.
SOC 2 TYPE II · EVIDENCE PACK
·TSC 2017 (2022 PoF)
·PERIOD 1 JAN - 31 MAR 2026
● 23 covered
● 6 partial
● 5 gap
● 1 org-level
ControlAudit questionHow the engine answersEvidenceStatus
CC8.1
Secure SDLC policy
Is there a documented, followed secure development lifecycle?
The operative rules document defines the fixed pipeline and gates, it applies to every change by construction.
engine-rules (version controlled),
pipeline change records
Covered
CC1.2
Governance / decision log
Are governance and material decisions recorded?
A decision register records every owner, product and operational decision with rationale.
Decision register (version controlled)
Covered
CC1.3
Roles & responsibilities
Are engineering roles and responsibilities defined?
The role map defines each pipeline function and the human role it replaces, ownership is explicit.
Role map, audit pack
Covered
CC8.1
Change authorisation
Are changes authorised before implementation?
Items are triaged and planned before development, nothing is built without an issue request and an approved plan.
Triage + plan records per item
Covered
CC8.1
Change testing
Is each change tested before deployment?
Blocking test gates and zero context reviews run on every change, including a visual check where applicable.
Test run records and conclusions per change
Covered
CC8.1
Change traceability
Is every change traceable end to end?
Each issue logged carries a change from creation to pull request, with recorded review verdicts, a merge-gate decision, and with a telemetry span per stage.
Per change audit trail with OpenTelemetry spans
Covered
CC8.1
Merge / deployment gate
Are unauthorised or failing changes prevented from reaching production?
A deterministic merge gate is a pure function of test conclusions and recorded verdicts, nothing merges over an unresolved finding or failed test.
Merge-gate decision per change
Covered
CC8.1
Independent code review
Is each change independently reviewed?
A cold peer review runs on every change with no memory of authoring it, a blocking finding rejects the change.
Recorded peer review verdicts
Covered
CC6.3
Segregation of duties
Is the author of a change separate from its reviewer?
The independent review runs on a different model session from the author, the reviewer is structurally separate.
Verdicts showing a separate reviewer
Covered
CC8.1
Secure coding standards
Are secure coding practices enforced?
A security review gate scrutinises each change against hard security rules and general vulnerabilities
Recorded security review verdicts
Covered
Showing 10 example control areas · Type II: evidence sampled throughout the period, produced continuously per change
Interpretive sub-clauses to be confirmed with your assessor