SOC 2 for software teams
What a SOC 2 report is, why customers ask for one and which engineering controls auditors look at, from access reviews to change management.
What SOC 2 is
SOC 2 examination against the AICPA Trust Services Criteria
SOC 2 is not a law. It is a report. An independent CPA firm examines a service company's controls against the AICPA Trust Services Criteria and writes a report that the company shares with customers, usually under NDA.
There are two types. A Type I report says whether the controls are designed well at one point in time. A Type II report says whether they actually worked over a period, often 3 to 12 months. Enterprise buyers usually ask for Type II.
The criteria have five categories: Security (always included, also called the common criteria), Availability, Processing Integrity, Confidentiality and Privacy. You choose which of the other four to include. There is no pass or fail score. The report holds the auditor's opinion and any exceptions found.
Who it applies to
B2B software and service companies
Any company that stores or processes customer data, most often SaaS. The push usually comes from a customer's security review or procurement team.
The whole company, not only the code
Controls cover people (onboarding, background checks, training), process (change management, incident response) and systems (access, logging, backups).
Your vendors, through their reports
Subservice providers such as your cloud host are usually carved out of your report. You show you reviewed their own SOC 2 reports instead.
No law requires SOC 2. It is driven by contracts and customer demand. It is also not a certificate: a SOC 2 report is an attestation for a period, and customers will ask for a new one each year.
Key requirements, and what they mean for the build
Each row links the official text. Read the source for the exact wording before you rely on it.
Control environment
Leadership oversight, a code of conduct, clear roles and checks on the people who join.
Named owners for systems, and onboarding that grants access only after the checks are done.
Source: AICPA: 2017 Trust Services Criteria (revised points of focus, 2022)
Communication and risk assessment
Share security duties with staff and customers, and assess risks to your objectives, including the risk of fraud.
A risk register for the product, and a security page or trust center customers can read.
Source: AICPA: 2017 Trust Services Criteria (revised points of focus, 2022)
Monitoring and control activities
Check that controls keep working and fix what does not.
Automated evidence where possible: scripts or tools that check settings daily instead of screenshots once a year.
Source: AICPA: 2017 Trust Services Criteria (revised points of focus, 2022)
Logical and physical access
Restrict access to what each person needs, authenticate users, and remove access promptly when people leave.
SSO with MFA, least-privilege roles, regular access reviews, and offboarding that removes production access on the last day.
Source: AICPA: 2017 Trust Services Criteria (revised points of focus, 2022)
System operations
Detect vulnerabilities and unusual activity, and respond to incidents.
Dependency and infrastructure scanning, central logs with alerts, an on-call rota and written post-incident reviews.
Source: AICPA: 2017 Trust Services Criteria (revised points of focus, 2022)
Change management
Changes to systems are authorised, tested and approved before they reach production.
Protected main branch, required code review, CI tests on every change and a deploy log that ties each release to its approval.
Source: AICPA: 2017 Trust Services Criteria (revised points of focus, 2022)
Risk mitigation and vendors
Plan for business disruption and manage the risk from vendors and partners.
A vendor list with each vendor's data access and SOC report, plus a continuity plan that has been tested.
Source: AICPA: 2017 Trust Services Criteria (revised points of focus, 2022)
Availability (optional)
Capacity planning, backups and recovery that meet the commitments made to customers.
Backups with tested restores, recovery targets you have actually measured, and capacity alerts.
Source: AICPA: 2017 Trust Services Criteria (revised points of focus, 2022)
Confidentiality and Privacy (optional)
Identify confidential and personal information, protect it, and dispose of it when it is no longer needed.
Data classification, retention jobs that actually delete, and customer data deletion on request.
Source: AICPA: 2017 Trust Services Criteria (revised points of focus, 2022)
Engineering controls for SOC 2
How the rules change the way the software is designed.
- 01
Evidence from the pipeline
Pull requests, reviews, CI runs and deploys are already records. Keep them, and the change management evidence collects itself.
- 02
SSO and MFA everywhere
One identity provider for staff, MFA enforced, and no shared accounts on production systems.
- 03
Infrastructure as code
Environments defined in code and reviewed like any other change, with production kept separate from development.
- 04
No production data in development
Test with synthetic or masked data, so access to customer data stays a small, reviewed group.
- 05
Central logging and alerts
Application, access and infrastructure logs in one place, kept for a set period, with alerts that reach a person.
- 06
Vulnerability management
Scanning of dependencies and cloud configuration, with fix targets by severity and a regular penetration test.
- 07
Customer-facing controls
Audit trails, SSO for customer users, role-based access and data export and deletion. Security questionnaires ask for all of these.
- 08
Access reviews
A regular review of who can reach production and customer data, with removals recorded.
What to watch
The criteria in use are the 2017 Trust Services Criteria with points of focus revised in 2022. Check the AICPA page for any newer version before an audit.
Checked against the official sources on 2026-10-25.
9 OceanLab product builds cite SOC 2
Counted from our published case studies: a build counts when SOC 2 is in the list of rules it was built for.
Migdalor - SOC 2 and ISO 27001 Audit Readiness Tracker for Startups
Designed and built a clickable audit readiness tracker for startups preparing for SOC 2 and ISO/IEC 27001: one control library mapped to both frameworks, automated tests against cloud, identity, code, HR and device systems, and an inbox that chases the evidence nobody can automate.
Kleidi - SaaS Admin Console with Consented Support Access and a Full Audit Trail
Designed and built a clickable internal admin console for an Athens SaaS company that sells housekeeping software to EU hotels: find any tenant and see everything about it on one page, enter a customer's workspace only with their consent, work GDPR data requests on the clock, and give staff elevated rights only for a limited window with someone else's approval.
Umurinzi - Cloud Security Posture and Control Mapping Dashboard
Designed and built a clickable cloud security posture dashboard for a Kigali healthtech on AWS and Google Cloud: one findings queue checked against the CIS Benchmarks, identity risks and internet exposure in one view, every check mapped to ISO 27001 and SOC 2 controls, and a residency check for Rwandan patient data.
Riegel - Institutional MPC Custody Platform with Quorum Approvals and Client Policies
Designed and built a clickable client console for a German crypto custodian's MPC custody platform: institutions see their vaults and holdings, follow every transaction from request to final confirmation, approve with a security key against a quorum per approver group, and test their own first-match withdrawal policy before it goes live.
CryptoTax - FIFO Tax & PnL Reporting Engine for Retail Crypto Investors
Built a tax and portfolio reporting platform that ingests transactions from 30+ exchanges and wallets, computes FIFO cost-basis, and generates IRS Form 8949 + Schedule C in one click - shipped from clickable AI prototype to production in 10 weeks.
Shadoof - Feature Flag and Progressive Delivery Service for a Marketplace's Engineering Teams
Designed and built a clickable feature flag console for the engineering teams of a Cairo online marketplace: targeting rules and sticky percentage rollouts per environment, change requests with a second approver for Production, kill switches for incidents and a full change history for every flag.
Every build that cites SOC 2
- Building Pylon - Insurance operations console
- CryptoTax - Crypto tax reporting
- Kleidi - SaaS admin dashboard
- Migdalor - Audit readiness tracker
- Riegel - Institutional MPC custody
- Shadoof - Feature flags service
- Tekmė - Workflow automation builder
- Umurinzi - Security posture dashboard
- Zarpe - Employee onboarding
Check your product
Other frameworks and industries
Build with SOC 2 in mind from day one
Project build
We design and build the system as one project. It starts with a clickable prototype your team tries before any production code is written. Pay per milestone (outcome-based) or hourly at $30-50/hr, depending on role and seniority.
Embedded engineers
Our engineers join your team on a flexible monthly retainer. Part-time is fine and it runs month to month, with hours that overlap the US, UK and Europe, the Middle East, and Australia and Asia. Outcome-based or $30-50/hr.
SOC 2 questions
Should we get SOC 2 Type I or Type II first?
Many companies start with Type I because it is faster, then move to Type II once the controls have run for a period. If a key customer asks for Type II, plan the observation period from the start.
What is the difference between SOC 2 and ISO 27001?
SOC 2 is an attestation report from a CPA firm, common with US buyers. ISO/IEC 27001 is a certification of an information security management system, common in Europe and Asia. The controls overlap a lot, so one programme can serve both.
Does SOC 2 change how we build the product?
Partly. Most controls are about how the company runs: access, change management, monitoring and vendors. But customers' security reviews also check product features such as SSO, audit logs, role-based access and data deletion, so those are worth building early.
Can a compliance automation tool do SOC 2 for us?
It can collect evidence and track controls, which saves a lot of time. It cannot run the controls for you. Someone still has to review access, approve changes and respond to incidents, and an independent auditor still has to examine them.
