Control map · Trust Services Criteria (2017)
SOC 2
Code evidence for access, boundary and confidential-data criteria on every pull request, and process evidence for change approvals from every merge.
Code evidence
6criteria checked on every pull requestLive (process)
1from merges, approvals, rule changes, and deployments and releases recorded by GitHubPlanned
8can be evidenced from code or GitHub; not built yetOrganisation-level criteria
Policies, people, vendors, physical security and the like, listed below.Managed by your organisation’s workflowsA SOC 2 Type II report tests whether controls operated throughout a period. Change approvals are usually where engineering teams spend the most audit time, assembling tickets and screenshots for a sample of changes.
The SOC 2 blueprint gives code evidence for the access, boundary and confidential-data criteria on every pull request. Every pull request merged into the default branch is sealed as a change record with its approvals, checks and signatures: evidence for CC8.1. The full map is below, with the organisation-level criteria listed after it.
Toevan gives evidence for controls; it never certifies them or claims a framework is covered. Whether the evidence is sufficient is your auditor’s judgement. Controls are shown by id with Toevan’s own short names; the official titles and requirement text belong to the framework’s publisher.
Code evidence6
Sealed on every pull request. Always partial: the control also asks for things outside code. Rules in the SOC 2 blueprint check part of each on every pull request.
CC6.1Access limit designCC6 Access protectionCC6.3Role permission changesCC6 Access protectionCC6.6Outside threat defenseCC6 Access protectionCC6.7Data movement limitsCC6 Access protectionC1.1Confidential data markingC1 Confidential dataC1.2Confidential data disposalC1 Confidential data
Live (process)1
Merged pull requests, approvals, required checks, branch protection, rulesets and bypasses, and deployments and releases recorded by GitHub, each sealed.
CC8.1Change approvalsCC8 Change handlingProcess evidence: every pull request merged into the default branch is sealed as a change record with its approvals on the final commit, the required checks at merge, who merged it, its signatures and the code verdicts it carried.
Change record rec_5b81d4e
example dataPlanned8
Can be evidenced from code or GitHub. No rule checks these yet; each is planned, and none counts as evidence today.
CC6.2User credential issuingCC6 Access protectionCC7.1Weakness drift watchingCC7 Security operationsCC7.2Anomaly watchingCC7 Security operationsA1.2Backup safeguardsA1 Capacity and backupPI1.2Complete accurate inputsPI1 Processing accuracyPI1.3Processing loss errorsPI1 Processing accuracyP4.2Personal data retentionP4 Use and keepingP4.3Personal data disposalP4 Use and keeping
Organisation-level criteria
Organisation-level controls (policies, people, vendors, physical security and the like) stay with your organisation’s own process; Toevan does not cover them.
Show the list
CC1 Leadership conduct
CC2 Information sharing
CC3 Risk review
CC4 Control monitoring
CC5 Control selection
CC6 Access protection
CC7 Security operations
CC9 Vendor risk
A1 Capacity and backup
PI1 Processing accuracy
P1 Notice duties
P2 Choice duties
P3 Collection duties
P4 Use and keeping
P5 Individual requests
P6 Sharing duties
P7 Data quality
P8 Complaint handling
Using it in an audit
- Take the population from the change records
Every pull request merged into the default branch and every push to a protected branch that no merged pull request explains, in the period, captured from GitHub as it happened, is a sealed record you can export for sampling. You can re-perform the default branch’s population from git history; designated production branches are planned.
- Read the code evidence for the period
Each pull request carries sealed code results against the blueprint’s rules, pinned to the commit and the rule-set version in force.
- Test a sample
For each sampled record, check its results, then verify it offline against the published key with openssl and the shell: get the evidence, confirm the key, check the record. To replay the whole chain, Toevan provides the toevan command on request; it is not yet public.
- Recomputed
- Toevan computed it from the code or git history itself.
- Reported + sealed
- GitHub reported it; Toevan captured it at the event and signed it.
- Declared + sealed
- The organisation declared it, such as a change to what is checked; Toevan signed the declaration and its history.
- Toevan record, not sealed
- Held in Toevan’s database but not sealed in the ledger, such as a waiver today. Nothing protects it by a signature.
- Consumed
- Taken from GitHub’s deployment and release records and linked by commit or digest.
- Not captured
- No reliable source was available. Toevan does not infer it.
Recomputed listed from git history and matched to the sealed records
Test the mapping on a real audit.
Bring one repository and an upcoming audit. We’ll set up the blueprint and walk your auditor through verification.
- One repository, one framework
- Evidence from the first pull request
- Verifiable without a Toevan account