If you build or run a SaaS product, sooner or later a customer's security team will ask for your SOC 2 report. The work usually lands on engineering. Here is what SOC 2 controls are and what they mean for the systems you build.
For a longer walkthrough with examples and a checklist, see this guide to SOC 2 controls expl
ained.
What are SOC 2 controls?
SOC 2 controls are the policies, processes, and technical safeguards that protect customer data. An auditor tests them against the AICPA's Trust Services Criteria:
| Criterion | What it covers |
|---|---|
| Security | Protection against unauthorized access (required in every report) |
| Availability | Systems are up and usable as committed |
| Processing Integrity | Data is processed accurately, completely, and on time |
| Confidentiality | Sensitive data is identified and restricted |
| Privacy | Personal information is collected, used, retained, and disposed of properly |
There is no universal control list. You pick controls based on your systems, risks, and customer commitments, and the auditor tests whether they work.
What this looks like in engineering terms
Security
- MFA enforced on production and cloud consoles
- Role-based access with regular access reviews
- Vulnerability scanning and patching
- Centralized logging and alerting
- A documented incident response process
Availability
- Uptime and capacity monitoring
- Automated backups, with restores that you actually test
- A disaster recovery plan that has been exercised, not just written
Processing Integrity
- Input validation and error handling
- Automated tests in CI
- Alerts when jobs or pipelines fail
Confidentiality
- Encryption at rest and in transit
- Secrets management instead of credentials in repos
- Data classification and secure disposal
Privacy
- A clear map of what personal data you collect, where it lives, and how long you keep it
- Retention and deletion that match your privacy policy
Change management is a control too
Auditors often sample your change process. If production changes go through pull requests with review and approval, and your CI/CD keeps a record, that history is evidence. Tickets, PR approvals, and deployment logs can all serve as proof.
Mistakes that cause audit pain
- Policies without implementation. A written policy doesn't prove a control operates.
- Collecting evidence at the last minute. Screenshot sprints right before the audit are painful and error-prone.
- Skipping access reviews. Offboarded people and role changes leave stale permissions behind.
- Ignoring vendors. Your cloud providers and SaaS tools are part of your risk surface.
- Treating SOC 2 as a one-time project. Controls have to run across the whole audit period.
- Protecting production but forgetting backups and dev environments that contain real data.
A quick prep checklist
Start with these areas and write down the control and the evidence for each:
- [ ] Access control and MFA
- [ ] Security monitoring and logging
- [ ] Risk assessment
- [ ] Incident response
- [ ] Change management
- [ ] Vendor management
- [ ] Security awareness training
- [ ] Backup and disaster recovery
- [ ] Data protection and encryption
- [ ] Periodic policy review
This SOC 2 control checklist maps each area to example evidence. Treat it as a starting point, not a replacement for a risk-based assessment of your own environment.
SOC 2 and ISO 27001
Many teams end up doing both. They overlap in areas like access control, incident management, and monitoring, but they aren't one-to-one equivalents. SOC 2 is built on the Trust Services Criteria, while ISO 27001 defines requirements for an Information Security Management System. Mapping overlapping controls lets you reuse evidence instead of doing the work twice.
Make it continuous
The easiest audits are the ones where evidence is collected automatically as part of normal operations. Assign owners, monitor controls, track gaps, and remediate quickly. A compliance automation platform can help centralize control tracking, evidence collection, and audit prep so it doesn't live in spreadsheets.
Wrapping up
SOC 2 isn't just paperwork. Much of it is engineering hygiene you may already be doing: access control, monitoring, change review, backups, and encryption. The key is to document it, collect evidence continuously, and keep it running all year.
What's the hardest SOC 2 control your team has had to implement? Let me know in the comments.
Top comments (0)