Your team opens a pull request. Someone reviews it, the check suite runs, and main refuses a direct push. That is criterion CC8.1 operating, today, with nobody calling it a control. Then the auditor asks for the population of changes in the observation window, and somebody loses a weekend rebuilding it out of git log.
Part 1 covered what a SOC 2 report is and what it is not. This part covers what surprises engineers: most of the controls in that report describe work your team already does. The first examination hurts anyway, and it hurts for reasons that have little to do with your engineering.
A practice is what your team does. A control is what your team does, written down
A practice is a habit. A control is a practice that has a description, an owner, a frequency, and a trail somebody outside your team can read months later.
Five gaps sit between the two, and they are the same five every time.
- Informal. The practice is real and undescribed. An auditor cannot test a description that does not exist.
- Inconsistent. It holds for eleven of twelve sampled changes, and the twelfth becomes an exception in your report.
- Unowned. It lapsed in July, and nobody noticed until the evidence request arrived.
- Unevidenced. This is the expensive one. A period that has already passed cannot be reconstructed, and that is what pushes an examination window back by a quarter.
- Unmanaged exceptions. The 2 a.m. deploy that skipped review has no record explaining why it skipped review.
Four of those close with a page of writing. The fifth closes only by setting retention long enough before the window opens, which is why Part 1 spent its length there.
The Trust Services Criteria say what has to be true. They name no vendor and no product. The AICPA's own document, TSP Section 100, settles how much latitude you have in paragraph .04:
Use of the trust services criteria does not require an assessment of whether each point of focus is addressed.
Points of focus are the AICPA's suggested characteristics of each criterion, and the paragraph above that one calls them guidance that "may assist management when designing, implementing, and operating controls." They are not a checklist you have to answer line by line.
So when a vendor tells you that SOC 2 requires their platform, they are selling you something. You choose the control. Your service auditor judges whether your choice meets the criterion.
Carry one caveat through everything below. The AICPA publishes no mapping from an engineering practice to a criterion, because management selects the controls and the auditor evaluates them. A pull request review supports CC8.1. Nothing in CC8.1 requires a pull request review, and anyone who tells you it does has invented a requirement on the AICPA's behalf.
The eight-minute version
The same material, with the criteria on screen and the five gaps drawn out:
Your Engineering Team May Already Have These SOC 2 Controls. Eight minutes, covering the same ground as the sections below.
Change management, and four verbs in one artifact
CC8.1 reads: "The entity authorizes, designs, develops or acquires, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures to meet its objectives."
A merged pull request carries four of those verbs in a single artifact: the linked issue authorizes, the diff and the description document, the check suite tests, and the review approves. GitHub keeps all four with timestamps you did not write yourself, which is what makes them worth anything to a stranger.
The gap is rarely the review itself. It is the branch that still allows a force push, the repository nobody added to the protected set, and the emergency fix that shipped at two in the morning with checks skipped.
Think of it as a building permit. Nobody objects to you renovating your own kitchen, and the permit exists so that someone qualified signed off and a record survives of what changed. Your renovation is fine either way; the inspector needs the paperwork to say so.
Pull the change population before anyone asks you for it. One command gives you every change merged inside a window, who wrote it, and who approved it:
gh pr list --state merged --search "merged:2026-01-01..2026-03-31" \
--limit 500 \
--json number,title,mergedAt,author,reviews \
--jq '.[] | [.number, .mergedAt, .author.login,
([.reviews[] | select(.state=="APPROVED") | .author.login] | join(","))] | @tsv'
Run it against the repository you are about to describe as in scope. Rows that come back with an empty approvals column are your exception population, and finding them in month two costs you a conversation. Finding them in month eleven costs you an exception in the report.
Branch protection is the other half, and almost nobody exports it:
gh api "repos/OWNER/REPO/branches/main/protection" \
--jq '{reviews: .required_pull_request_reviews.required_approving_review_count,
checks: .required_status_checks.contexts,
force_push: .allow_force_pushes.enabled,
admins: .enforce_admins.enabled}'
On a private repository under a free plan that endpoint answers 403, because GitHub sells branch protection there as a paid feature. Save its output on a schedule. A settings page you screenshot the week the auditor arrives proves the setting existed that week and says nothing about January.
Access is three questions, and the third one fails audits
Who can get in is CC6.1, which asks that "the entity implements logical access security software, infrastructure, and architectures over protected information assets to protect them from security events to meet the entity's objectives." Multi-factor authentication is the control most teams already run here.
What they reach once inside is CC6.3, which covers authorizing, modifying and removing access "based on roles, responsibilities, or the system design and changes, giving consideration to the concepts of least privilege and segregation of duties, to meet the entity's objectives." Most teams' cloud roles follow least privilege on the resources somebody set up deliberately.
How people arrive and leave is CC6.2, and this is the sentence worth reading twice: "Prior to issuing system credentials and granting system access, the entity registers and authorizes new internal and external users whose access is administered by the entity. For those users whose access is administered by the entity, user system credentials are removed when user access is no longer authorized."
Handing out keys is easy to remember. Getting them back is what the audit tests. Offboarding runs through whoever noticed, the shared dashboard login outlives three leavers, and the quarterly access review happens once and then stops. An auditor tests CC6.2 by taking a name off your leavers list and asking you to show the account is gone.
So produce the list on a schedule instead of on demand. The Azure half of that is one command:
az role assignment list --all --include-inherited \
--query "[?principalType=='User'].{user:principalName, role:roleDefinitionName, scope:scope}" \
-o tsv > access-review-$(date +%F).tsv
Join it against your current employee roster, write the reviewer's name into the file, and commit it. The file date is the evidence. Four dated files across a year say something that a folder of portal screenshots taken in one afternoon cannot.
A log nobody reads meets the first word of CC7.2 and none of the rest
CC7.2 asks that "the entity monitors system components and the operation of those components for anomalies that are indicative of malicious acts, natural disasters, and errors affecting the entity's ability to meet its objectives; anomalies are analyzed to determine whether they represent security events."
Logging is the monitoring half. Alerting is the analysis half. Both live in one sentence of the criterion, so shipping logs into a bucket nobody has ever queried satisfies the opening clause and stops there.
Incidents split across two criteria that teams tend to collapse into one. CC7.3 covers the decision: "The entity evaluates security events to determine whether they could or have resulted in a failure of the entity to meet its objectives (security incidents) and, if so, takes actions to prevent or address such failures." CC7.4 covers what happens next: "The entity responds to identified security incidents by executing a defined incident-response program to understand, contain, remediate, and communicate security incidents, as appropriate."
Your on-call ticket, its timeline and its postmortem are the evidence for both. The word carrying the weight in CC7.4 is defined. A team that handles incidents well without a written program has the practice and not the control, and the fix is to write down the program you are already following.
Vendors, and the trap hiding in one letter
CC9.2 is one line: "The entity assesses and manages risks associated with vendors and business partners."
Moving your database to a managed service transfers the controls and leaves the responsibility with you. A yearly read of that provider's own SOC 2 report, written down with the date you read it and what you concluded, satisfies most of this. Part 1 argued that the model API in your product belongs on the same list.
Backups are the trap. A1.2 covers "software, data backup processes, and recovery infrastructure" among the things an entity implements and monitors. A1.3 is a single sentence: "The entity tests recovery plan procedures supporting system recovery to meet its objectives."
Read the prefix. A is Availability, and Availability is a category you choose. Paragraph .07 of TSP 100 sets out why that matters: the common criteria "are suitable for evaluating the effectiveness of controls to achieve an entity's system objectives related to security; no additional control activity criteria are needed," and each of the other four categories layers its own control activity criteria on top of them. Security is the common criteria and nothing further, and every category carries the common criteria, so Security is in your examination whatever else you scoped.
Scope Security alone and restore testing falls outside your report. That surprises most engineers I say it to. Most companies scope Availability anyway, and you should test restores whichever way you scoped, because a backup nobody has restored is a spare key nobody has tried in the lock.
The page that closes four gaps
Pick one practice this week and write its page. Here is the whole format:
# Change management (supports CC8.1)
Control: Every change to production code reaches main through a pull request
carrying at least one approving review from someone other than the author and a
passing check suite. Direct pushes to main are blocked at the branch level.
Owner: Head of Engineering
Frequency: Every change
Evidence: GitHub pull request history, retained for the life of the repository.
Branch protection exported quarterly to
compliance/evidence/branch-protection-YYYY-QN.json.
Exceptions: An emergency change may bypass review with the approval of the Head
of Engineering, recorded in the incident ticket within 24 hours and logged in
compliance/exceptions.md.
Title, owner, frequency, evidence location, exception path. Write that page and you close three of the five gaps outright, and you make the fourth, inconsistency, visible enough to fix. Evidence is the gap no page will close for you, because retention has to be running before the period starts.
What each area already gives you
| Criterion |
What it covers |
The practice that commonly supports it |
| CC6.1 |
Who can get in |
Multi-factor authentication |
| CC6.2 |
Arrivals and departures |
Onboarding, credential removal |
| CC6.3 |
What they reach inside |
Role-based access, least privilege |
| CC7.2 |
Monitoring for anomalies |
Logging, plus alerting on those logs |
| CC7.3 |
Deciding an event is an incident |
On-call triage |
| CC7.4 |
Responding under a defined program |
Incident timeline, postmortem |
| CC8.1 |
Authorizing and documenting change |
Merged pull request with review |
| CC9.2 |
Vendor risk |
Yearly read of the vendor's own SOC 2 |
| A1.2, A1.3 |
Backup and restore testing |
Restore drills, if you scoped Availability |
Every criterion above is quoted from the 2017 Trust Services Criteria with revised points of focus, 2022, which is the current edition. That revision changed the points of focus and left the criteria themselves alone, so check any of these against the source before you write them into a control description.
Where the work sits
The engineering is usually done before the audit starts. You are missing a description, a name against it, a schedule, and a trail that outlives the period, and each of those costs an hour of writing rather than a quarter of building. Teams that treat the first examination as a security project spend the quarter regardless, because they go looking for controls to adopt when they should be describing the controls they run.
Start with the practice you would defend to a stranger without preparing first. Write that one down the way it already works, and you will have your first control by the end of the afternoon.