What SOC 2 controls fall on engineering?

The controls that land squarely on engineering teams are: branch protection and required code reviews before merging, CI/CD gates enforcing tests and security scans, secrets management to prevent credentials in code, vulnerability scanning of dependencies and containers, access controls on production systems, change management records for deployments, and incident response runbooks. Most of these map to CC6, CC7, and CC8 in the Trust Services Criteria.

Does SOC 2 require code review?

Yes. CC8.1 requires that changes to production systems are authorized and tested before deployment. In practice, auditors look for branch protection rules that require at least one approving review before merging to main, and a CI/CD pipeline that runs tests on every pull request. A screenshot of your GitHub branch protection settings and a sample pull request with an approval is standard evidence.

What does SOC 2 require for secrets management?

SOC 2 CC6.1 requires logical access controls on sensitive data including credentials and API keys. For engineering teams, this means secrets must not be hardcoded in source code, must be stored in a secrets manager (AWS Secrets Manager, HashiCorp Vault, or equivalent), and must be rotated on a defined schedule. Auditors will often ask to see the secrets management tooling and review whether any secrets have been committed to the codebase.

Do developers need to complete security training for SOC 2?

Yes. CC1.4 requires that personnel are trained on security policies relevant to their roles. For developers, this typically means annual security awareness training that covers topics like phishing, secure coding practices, and the acceptable use policy. Completion records must be maintained as evidence. Most compliance platforms integrate with training tools to track completion automatically.

What does SOC 2 require for CI/CD pipelines?

SOC 2 CC8.1 (change management) requires evidence that code changes are reviewed, tested, and approved before reaching production. For CI/CD pipelines, this means: automated tests run on every merge, security scans (SAST, dependency scanning) run in the pipeline, deployments to production require a passing build, and production deploys are logged with who deployed what and when. Auditors will ask for a sample deployment record.

SOC 2 for engineering teams

If you are an engineer reading this, you probably did not volunteer for SOC 2. Someone in finance or sales told you the company needs it to close enterprise deals, and now you have a Notion doc of controls landing in your sprint. The good news is that most of what SOC 2 asks engineers to do is what you should be doing anyway. The bad news is that auditors care about the paper trail, not just the practice.

SOC 2 engineering checklist: 5 controls your team owns

Here is what actually matters for engineering teams, control by control.

Why engineers should care beyond compliance

The SOC 2 controls that target engineering are not arbitrary. They are codified versions of what mature engineering organizations already do: review code before it ships, protect production from accidents, patch vulnerabilities on a clock, and write down what happens when things go wrong.

Treating SOC 2 as a forcing function rather than a tax usually produces a better engineering org. The controls force conversations about access scope, deployment safety, and on-call hygiene that teams often defer.

Change management (CC8.1)

This is the control that maps directly to your GitHub setup. The auditor wants to see that code does not reach production without review and approval, and that the process is enforced by the system, not by trust.

What the auditor will check:

Branch protection on default branches (main, master, production)
Required pull request reviews from at least one other engineer
Required status checks (CI must pass before merge)
No direct pushes to protected branches (including by admins)
Signed commits or commit verification (a nice-to-have, increasingly common)
Deployment approvals for production releases (manual approval gate or recorded auto-deploy)

What auditors actually pull from GitHub: a sample of five to ten merged PRs from the audit period. They will check that each has a reviewer who is not the author, that CI passed, and that the merge corresponds to a production deployment.

Common gap

Common gaps:

Admins bypassing branch protection (turn this off explicitly)
Self-approval through dummy accounts
"Emergency" hotfix processes with no record
Force pushes to protected branches

If your CD pipeline auto-deploys main to production, that is fine, but you need to be able to show the deployment log and tie each deploy to a reviewed commit.

Access management (CC6.1)

Engineering access is the highest-risk access in the company. Auditors know this. They will scrutinize who has production access, how they got it, and whether they still need it.

What the auditor will check:

MFA enforced on every system that touches production (cloud console, CI/CD, code host, secrets manager)
Least privilege for IAM roles (no wildcard admin policies for engineers)
Service account hygiene (named owner, rotation policy, no shared credentials)
SSH key inventory and rotation
Production database access logged and reviewed

Service accounts are where most teams fail. A service account named "ci-deploy" with full admin in AWS, owned by no one, with credentials that have not rotated in two years, will become a finding. Give every service account a named human owner, document its purpose, and rotate credentials on a schedule.

For engineer access specifically, run quarterly access reviews. The on-call rotation changes, people move teams, contractors leave. The auditor will ask why a backend engineer who moved to data still has prod SSH access.

Vulnerability management (CC7.1)

The auditor wants to see that you find, prioritize, and fix vulnerabilities on a documented clock.

What works:

Dependabot or Snyk scanning every repo on every PR
A patching SLA written down and followed (critical within 7 days, high within 30, medium within 90)
A vulnerability dashboard with the open count and age
An annual penetration test by a licensed third party

What does not work:

"We patch when we have time"
A scanner that runs but produces tickets nobody owns
Critical vulnerabilities open for 90 days because they were "not exploitable"

If you decide a vulnerability is not exploitable in your environment, that decision needs a written justification and a manager sign-off. Otherwise it looks like you ignored it.

Incident response (CC7.2)

Incident response is mostly a documentation exercise, which engineers tend to skip. Do not skip it.

You need:

A written incident response runbook with roles, escalation paths, and severity definitions
An incident tracking system (Jira, Linear, dedicated incident tool) with severity, timeline, root cause, and resolution
Postmortems for severity 1 and 2 incidents, written within a defined window (usually two weeks)
Quarterly tabletop exercises or simulated incidents
Evidence the security team was notified within the SLA for security incidents

The auditor will ask for the full incident list from the audit period. Zero incidents is a finding because nobody has zero incidents. If you legitimately had no severity 1 or 2 incidents, you still had minor ones. Document them.

What evidence auditors pull from GitHub

Specifically, expect requests for:

Branch protection settings exported as JSON or screenshotted with timestamps
Pull request samples with reviewer, status checks, and merge commit visible
Repository member list with role assignments
Deploy keys and webhook inventory
Audit log excerpts for sensitive actions (force pushes, branch protection changes, admin permission grants)
Two-factor authentication status for every member of the org

You can pull all of this through the GitHub API, storing the diff so you can show change over time, not just a single snapshot. A fractional CISO sets that up and keeps it running so your engineers do not have to.

Where to go from here

If your engineering org is the bottleneck on SOC 2, getting the GitHub evidence layer under control (branch protection monitoring, PR sampling, access reviews) is the highest-leverage fix, and it is exactly the work a fractional CISO takes off your engineers. For a deeper view of how SOC 2 lands across a SaaS stack, see our SOC 2 for SaaS guide.

Want a security leader to run this?

Xorabyte is a fractional CISO for startups who can review your cloud for the gaps found first, so a blocked deal or an audit stops being your problem to carry alone. Book a call and you will leave with a clear path, not a sales pitch.