The SOC 2 Journey: What We Learned

Why We Are Writing This

Most companies treat SOC 2 as a checkbox exercise and never talk about it publicly. We think that is a missed opportunity. If Intended is going to help organizations with compliance evidence for their AI governance, we should be transparent about our own compliance journey. What follows is an honest account of our SOC 2 Type II preparation.

What SOC 2 Actually Requires

SOC 2 is not a certification. It is an audit. An independent auditor examines your controls against the AICPA Trust Service Criteria and issues a report describing your system, the controls in place, and whether those controls operated effectively during the audit period. The report can include qualified opinions (the auditor found issues) or an unqualified opinion (everything checked out).

The five Trust Service Categories are Security (required), Availability, Processing Integrity, Confidentiality, and Privacy. You choose which categories to include. Most companies start with Security only and add categories over time. We included Security, Availability, and Confidentiality from the start because our customers' data classification requirements demanded it.

What Was Harder Than Expected

Writing the System Description

The system description is a narrative document that describes your system boundaries, infrastructure, software, people, processes, and data. It sounds simple. It is not.

The challenge is precision. The auditor tests controls based on the system description. If you describe a control that does not exist, or describe it differently than how it actually works, you get a finding. If you omit a control that you rely on, you have a gap in your evidence.

Writing an accurate, complete system description for Intended took three weeks and six revisions. Every statement needed to be verifiable. "We encrypt data at rest" needed to specify the algorithm (AES-256), the key management approach (AWS KMS with customer-managed keys), and the scope (all customer data in PostgreSQL and object storage).

Evidence Collection Discipline

SOC 2 is not about having controls at a point in time. It is about operating controls consistently over the audit period. This means you need evidence that controls were operating every day, not just on audit day.

For us, this meant building evidence collection into our operational workflows from day one. Every access review, every configuration change, every incident response, every vulnerability remediation needed documentation. Not after the fact, but in real time.

The hard part was changing behavior. Engineers are not naturally inclined to document every security-relevant action. We had to build tools that made documentation automatic or nearly so. Our deployment pipeline captures change approvals automatically. Our access review process generates evidence artifacts without manual intervention. Our incident response runbook includes evidence capture steps.

Access Reviews

Access reviews are deceptively complex. The concept is simple: periodically review who has access to what and confirm that access is still appropriate. In practice, access sprawls across dozens of systems, each with its own access model.

We had to inventory every system with access to customer data or production infrastructure: AWS accounts, GitHub repositories, database instances, monitoring tools, support platforms, CI/CD pipelines. For each system, we documented who has access, at what level, and why. Then we established a quarterly review cycle where managers confirm that each person's access is still appropriate.

The first review took a full week. We found three accounts with access they no longer needed (former contractors whose access had not been revoked). This was embarrassing but exactly the kind of finding that SOC 2 is designed to catch.

What Was Easier Than Expected

Technical Controls

If your infrastructure is built on modern cloud platforms, many technical controls are straightforward to implement. Encryption at rest and in transit is default behavior on most cloud services. Network segmentation is achievable with VPCs and security groups. Logging is built into every cloud service.

The technical controls that are hard in an on-premise world are table stakes in a cloud-native architecture. We spent very little time implementing technical security controls because we had made sensible infrastructure choices from the beginning.

Auditor Communication

We expected the audit process to be adversarial. It was not. Our auditors were professional, clear about their requirements, and responsive to questions. They wanted us to succeed because a clean report is easier to write than a report full of findings.

The key was preparation. Before the audit fieldwork began, we provided our auditors with the system description, a complete evidence package organized by control objective, and a mapping document linking each control to the relevant evidence. The auditors knew exactly what to look for and where to find it.

Policy Documentation

Writing security policies sounds bureaucratic, but it was actually a clarifying exercise. Formalizing our policies forced us to make explicit decisions we had been making implicitly. What is our password policy? What is our incident response timeline? What is our change management process?

Having these decisions written down eliminated ambiguity. New team members know exactly what is expected. Incident responders have a clear playbook. And the policies themselves became evidence artifacts for the audit.

What We Would Do Differently

Start Evidence Collection Earlier

We began formal evidence collection about six months before the audit. We should have started on day one. Evidence collection is not something you bolt on. It is an operational discipline. The earlier you start, the more natural it becomes.

Automate Everything

Every manual evidence collection step is a potential gap. If someone forgets to screenshot the access review, if someone does not document the incident resolution, the evidence is missing and the control appears unverified.

We automated about 80 percent of our evidence collection. We should have targeted 95 percent. Every manual step is a risk to audit readiness.

Choose Your Auditor Carefully

Not all SOC 2 auditors are created equal. Some are more experienced with technology companies. Some are more familiar with cloud-native architectures. Some are faster. Some are more thorough. We spoke with three firms before selecting our auditor, and the differences in approach, timeline, and cost were significant.

Ask for references from companies similar to yours. Ask about the auditor's experience with your infrastructure platform. Ask about their communication style and their timeline expectations.

The Ongoing Cost

SOC 2 is not a one-time effort. The audit period is continuous. Controls must operate effectively every day, not just during audit fieldwork. Evidence must be collected continuously. Access reviews must happen on schedule. Policies must be updated when processes change.

We estimate the ongoing cost of SOC 2 maintenance at approximately 10 percent of one full-time equivalent, spread across the engineering and operations team. This is not trivial, but it is manageable, and the discipline it imposes makes our operations more reliable.

Why It Matters for Our Customers

Our SOC 2 report is not just a sales enablement tool. It is proof that we take security seriously enough to submit to independent verification. When we ask customers to trust Intended with their AI governance layer, we need to demonstrate that our own house is in order.

Every enterprise customer we work with asks for our SOC 2 report. Having it ready, current, and clean accelerates procurement by weeks or months. More importantly, the discipline of SOC 2 compliance makes us a better-run company. The evidence collection, the access reviews, the policy documentation -- all of it makes our security posture genuinely stronger, not just auditably stronger.