Skip to content
toevan
Sign inBook an audit pilot
Open menuClose menu
Book an audit pilot

Control map · Trust Services Criteria (2017)

SOC 2

Book an audit pilotSee a sample report

8 of 15 SOC 2 controls code can evidence, with v1.4.0, plus 1 supporting

Code evidence for access, boundary and confidential-data criteria today; change approvals with process evidence in v1.4.0.

  • Live7
  • Coming in v1.4.01
  • Supporting1
  • Planned7
  • Your organisation45
  1. 7 with code evidence todayPartial evidence, checked on every pull request.
  2. 1 more in v1.4.0Process evidence from merges, approvals and rule changes.
  3. 45 stay with your organisationListed in full below, so nothing is implied.

A 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.

Today the SOC 2 blueprint gives code evidence for seven criteria on every pull request. From v1.4.0, every merged pull request is sealed as a change record with its approvals, checks and signatures: evidence for CC8.1. The full map is below, including the 45 criteria that stay with your organisation.

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.

Live7

Code evidence today, sealed on every pull request. Always partial: the control also asks for things outside code. Code evidence today: rules in the SOC 2 blueprint check part of this on every pull request.

  • CC6.1

    Access limit design

    CC6 Access protection

  • CC6.3

    Role permission changes

    CC6 Access protection

  • CC6.6

    Outside threat defense

    CC6 Access protection

  • CC6.7

    Data movement limits

    CC6 Access protection

  • CC7.2

    Anomaly watching

    CC7 Security operations

  • C1.1

    Confidential data marking

    C1 Confidential data

  • C1.2

    Confidential data disposal

    C1 Confidential data

Coming in v1.4.01

Process evidence: merged pull requests, approvals, required checks, branch protection, rulesets and bypasses, sealed per change.

  • CC8.1

    Change approvals

    CC8 Change handling

    Process evidence: every merged pull request 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.

Supporting1

Toevan records related evidence, today or in v1.4.0, but the duty is organisational, so it never counts as covered.

  • CC7.4

    Incident response steps

    CC7 Security operations

    Supporting evidence today: a rule records evidence related to this duty. The duty itself is an operational process.

Planned7

Can be evidenced from code or GitHub. The rule or mapping is not built yet.

  • CC6.2

    User credential issuing

    CC6 Access protection

  • CC7.1

    Weakness drift watching

    CC7 Security operations

  • A1.2

    Backup safeguards

    A1 Capacity and backup

  • PI1.2

    Complete accurate inputs

    PI1 Processing accuracy

  • PI1.3

    Processing loss errors

    PI1 Processing accuracy

  • P4.2

    Personal data retention

    P4 Use and keeping

  • P4.3

    Personal data disposal

    P4 Use and keeping

Your organisation45

Policy, people, physical security, contracts, regulatory procedure, operations or external audit. Your organisation evidences these.

Show all 45 controls

CC1 Leadership conduct

  • CC1.1Conduct commitmentorganisational policy
  • CC1.2Board oversightorganisational policy
  • CC1.3Reporting linesorganisational policy
  • CC1.4Capable staff hiringpeople and HR
  • CC1.5Duty answerabilitypeople and HR

CC2 Information sharing

  • CC2.1Good control informationorganisational policy
  • CC2.2Staff duty briefingsorganisational policy
  • CC2.3Outside party talksorganisational policy

CC3 Risk review

  • CC3.1Risk goalsorganisational policy
  • CC3.2Risk weighingorganisational policy
  • CC3.3Fraud risk revieworganisational policy
  • CC3.4Change impact revieworganisational policy

CC4 Control monitoring

  • CC4.1Ongoing control reviewsan operational process
  • CC4.2Weakness reportingan operational process

CC5 Control selection

  • CC5.1Risk cutting controlsorganisational policy
  • CC5.2Technology control choicesorganisational policy
  • CC5.3Rolled out policiesorganisational policy

CC6 Access protection

  • CC6.4Physical entry limitsphysical security
  • CC6.5Asset data disposalphysical security
  • CC6.8Unwanted software blockingan operational process

CC7 Security operations

  • CC7.3Event judgingan operational process
  • CC7.5Incident recovery learningan operational process

CC9 Vendor risk

  • CC9.1Disruption risk reductionorganisational policy
  • CC9.2Vendor risk managementcontracts and vendors

A1 Capacity and backup

  • A1.1Capacity watchingan operational process
  • A1.3Recovery testingan operational process

PI1 Processing accuracy

  • PI1.1Defined processing goalsan operational process
  • PI1.4Output delivery reviewan operational process
  • PI1.5Stored item integrityan operational process

P1 Notice duties

  • P1.1Privacy noticeorganisational policy

P2 Choice duties

  • P2.1Consent choicesorganisational policy

P3 Collection duties

  • P3.1Lawful collectionorganisational policy
  • P3.2Explicit sensitive consentorganisational policy

P4 Use and keeping

  • P4.1Stated purpose limitsorganisational policy

P5 Individual requests

  • P5.1Access request answersan operational process
  • P5.2Correction handlingan operational process

P6 Sharing duties

  • P6.1Consent before sharingorganisational policy
  • P6.2Sharing recordsorganisational policy
  • P6.3Unauthorized sharing recordsorganisational policy
  • P6.4Vendor privacy commitmentscontracts and vendors
  • P6.5Vendor incident reportingcontracts and vendors
  • P6.6Breach noticesregulatory procedure
  • P6.7Sharing accountingan operational process

P7 Data quality

  • P7.1Accurate personal dataan operational process

P8 Complaint handling

  • P8.1Complaint handlingan operational process

Using it in an audit

  1. Take the population from the change records (from v1.4.0)

    Every merge into a protected branch and every direct push 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 for v1.4.1.

  2. 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.

  3. Test a sample

    For each sampled record, check its results, then verify its signature and its place in the chain offline.

    toevan audit verify --path evidence-clone --pub-key toevan.pub

How each fact was obtained

Every fact in a record and a report carries one of six labels, so your auditor knows how far to rely on it.

Recomputed
Toevan computed it from the code or git history itself.
Re-perform it from the same inputs and get the same result.
Reported + sealed
GitHub reported it; Toevan captured it at the event and signed it.
Rely on it as far as you rely on GitHub. Any later change is detectable.
Declared + sealed
The organisation declared it, such as a change to what is checked; Toevan signed the declaration and its history.
See who declared what, when, and every later change.
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.
Treat it as Toevan’s statement, and ask the organisation for the approval behind it.
Consumed
Taken from another system’s signed record, such as build provenance, and linked by commit or digest. Planned.
Check the original record independently.
Not captured
No reliable source was available. Toevan does not infer it.
Obtain it from the organisation by other means.

See it in a report

The sample change evidence report shows the evidence as your auditor receives it, with every fact labelled.

Open the sample report

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.

Book an audit pilotSee a sample report