Safeguard
Compliance•

SOC 2 for DevOps leads: turning pipelines into evidence

A SOC 2 report is written by a CPA about your controls. DevOps leads supply the evidence: change records, access reviews, logs. Here is how to prepare.

Safeguard Security Team
4 min read

A SOC 2 report is an examination by a CPA of a service organization's controls relevant to security, availability, processing integrity, confidentiality or privacy. DevOps leads supply much of the evidence: change records, access reviews, monitoring and incident logs. The best preparation is making your tools record this by default.

What is a SOC 2 report?

The AICPA describes SOC as a suite of services that CPAs provide for system level controls of a service organization. Its SOC 2 guide is titled as a report on controls relevant to security, availability, processing integrity, confidentiality or privacy. The report is issued by a licensed CPA firm, and the AICPA sets the professional standards for these engagements. You choose which of the five categories are in scope, and security is the usual starting point.

Be careful about shortcuts. In 2026 the AICPA published pieces warning that promises of fast and easy SOC reports threaten the credibility of the reports and that quick turn engagements carry risks, and it said it is looking at allegations about a compliance vendor's business practices. The practical advice: confirm that your auditor is a licensed CPA firm that is enrolled in peer review, and be suspicious of any promise of a report in days.

What do auditors need from DevOps?

The auditor tests whether controls you describe actually operate. For infrastructure and delivery, that usually means evidence in a few families. Change management: pull requests with approval, tests, deployment records. Access: who has production access, how it is granted and removed, how often it is reviewed. Monitoring and incident response: alerts, tickets and post incident reviews. Backup and recovery: schedules and test results, if availability is in scope. Vulnerability management: scan results and fix timelines.

Which of these apply, and how many samples the auditor takes, is an auditor decision, so ask them. Do not assume a number.

How do you make evidence cheap?

Prefer controls that leave records without effort. Branch protection that requires review leaves a record on every merge. Infrastructure as code leaves a diff for every change. Single sign on with group based access leaves a log of grants. Ticket links in commit messages tie changes to approvals. A control that depends on someone remembering to take a screenshot will fail in month eleven.

Constructed example: a team requires review in policy, but the repository allows admins to push to main. During sampling, the auditor finds three direct pushes for urgent fixes with no review. The fix is not a stricter policy. It is a protected branch rule with a documented break glass path that creates a ticket automatically, so urgent changes still leave a trail.

What about a point in time versus a period?

Reports can be written about a point in time or about a period. Ask your auditor which they propose and what dates apply. If a period is covered, you must operate the control throughout, so changes to tooling in the middle need documentation. Our companion articles on report types cover timing in more depth.

What should DevOps own versus security?

DevOps owns the systems of record and the exports. Security owns the control descriptions and exceptions. Compliance or finance owns the auditor relationship. Agree on that split before kickoff, and name one person who answers the auditor's data requests within a day or two.

How to apply this

  1. Ask the auditor for the list of evidence requests early and map each to a system.
  2. Turn on branch protection, required reviews and deployment logging on every in scope repository.
  3. Move access to groups in your identity provider and schedule quarterly reviews with recorded sign off.
  4. Make sure alerts create tickets, and that incident reviews are stored in one place.
  5. Test a restore, if availability is in scope, and keep the result.
  6. Do a dry run: pull ninety days of evidence yourself and note what was hard.
  7. Confirm the auditor is a licensed CPA firm.

Quick check

Who issues a SOC 2 report?

A licensed CPA firm. The AICPA sets the professional standards. Tools can help collect evidence, but the examination is the CPA's.

Which trust categories must be included?

The report can cover security, availability, processing integrity, confidentiality and privacy. The service organization chooses which are in scope, with its auditor.

Sources

Last reviewed: 18 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.