A SOC 2 report is how many US software and service companies prove their security to customers. The audit itself is performed by an independent CPA firm, but most of the work happens before the auditor arrives: putting controls in place and making sure they leave evidence. For engineering teams, the largest part of that work is in the servers, cloud accounts and deployment pipeline. This guide covers the technical controls auditors look at and the evidence they usually ask for.
SOC 2 in two minutes
- Trust Services Criteria: the framework from the AICPA. Security is always in scope; Availability, Confidentiality, Processing Integrity and Privacy are added if relevant to your service.
- Type I tests whether controls are designed properly at one point in time.
- Type II tests whether they actually operated over a period, typically several months up to a year. Customers usually ask for Type II, so your controls must produce evidence every day, not just on audit day.
SOC 2 does not prescribe specific tools or settings. You define your controls, and the auditor tests that they meet the criteria and that you follow them.
Access control
| Control | Typical evidence |
|---|---|
| Single sign-on and MFA for cloud consoles, code hosting and admin tools | Identity provider settings, MFA enforcement report |
| Named accounts and least privilege on servers and databases | User and role listings, sudo configuration |
| Timely removal of leavers’ access | Offboarding tickets matched to account removal dates |
| Periodic access reviews | Signed-off quarterly review of who has production access |
| SSH keys or short-lived certificates, no shared root password | sshd configuration, key inventory |
Logging and monitoring
- Audit logs for administrative actions on servers (for example auditd on Linux) and in the cloud (AWS CloudTrail, Google Cloud Audit Logs, Azure Activity Log).
- Logs shipped to a central store that administrators cannot quietly edit, kept for a defined period.
- Alerts for security events and availability problems, with evidence that someone responds.
See our guide to audit logging for compliance for concrete settings.
Change management
- Infrastructure and application changes go through pull requests with review and approval, so the history is the evidence.
- Separation between who writes and who approves production changes, where team size allows.
- Emergency changes are allowed but documented and reviewed afterwards.
- Infrastructure as code (Terraform, CloudFormation, Ansible) makes this much easier to prove than changes made by hand.
Vulnerability and patch management
- Regular vulnerability scanning of servers, containers and dependencies.
- A written patching timeline by severity, and records showing you met it.
- Annual penetration test of internet-facing systems, with findings tracked to closure.
When a critical vulnerability lands, the evidence is how fast you closed it. Our PHP2Shell case study shows what fleet-wide emergency patching looks like in practice.
Encryption
- TLS for data in transit, encryption at rest for disks, databases, object storage and backups.
- Keys in a managed key service with limited access, and documented key rotation.
Backups, availability and incident response
- Automated backups with defined retention, and restore tests on a schedule with results recorded.
- Monitoring of availability and capacity if Availability is in scope.
- An incident response plan, an on-call rota, and post-incident reviews that show the plan is used.
Vendors
Auditors also check how you manage vendors that touch your systems, including hosting and managed service providers. Keep a vendor list, contracts, and their security reports or questionnaires on file.
Common reasons for exceptions
- Controls that exist on paper but leave no evidence, such as access reviews done verbally
- One forgotten server or account outside the standard setup
- Former employees whose cloud or SSH access was never removed
- Logs kept for weeks when the audit period is months
- Backups that were never restore-tested
Get help
TechProvidence engineers help teams prepare their infrastructure for SOC 2: implementing technical controls on Linux servers, AWS, Google Cloud and Azure, and keeping them running so the evidence is there when the auditor asks. We do not perform the audit itself. See our cybersecurity and risk management and managed AWS services, or contact us.
