SOC 2 Compliance for Developers: A Complete Guide

Your company just closed an enterprise deal, and now the security team needs engineering to help prepare for a SOC 2 audit. You open the SOC 2 documentation and find 200 pages written for compliance officers, not for the people who actually build and ship the software. The controls they describe (access management, encryption, logging, change management) are things you already work on every day. But nobody has translated the audit requirements into terms that map to your codebase, your CI/CD pipeline, and your pull request workflow.

This guide does that translation. You will learn what the five Trust Service Criteria actually mean for your code and how to build audit evidence collection into your existing development workflow. Tools like Sourcegraph can accelerate this process by enabling rapid codebase-wide queries in place of manual searches.

What Is SOC 2 Compliance?

SOC 2 (System and Organization Controls 2) is an auditing framework from the American Institute of Certified Public Accountants (AICPA). It evaluates whether a service organization handles sensitive customer data securely across the AICPA's five Trust Services Criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy.

Here is what makes SOC 2 different from frameworks like PCI DSS or HIPAA: SOC 2 does not prescribe specific security controls. It lets each organization define its own internal controls, then verifies whether those controls actually work. For developers, this is both freedom and responsibility. The access control system you design, the logging pipeline you build, the data encryption scheme you implement: these become the organization's controls that auditors evaluate. Your software development decisions directly shape the audit scope.

There are two report types. Type I evaluates whether your controls are properly designed at a single point in time. Think of it as a snapshot. Type II evaluates whether those controls operated effectively over a sustained period, typically 3 to 12 months. Type II is what enterprise customers actually care about, because it proves your controls work consistently under real conditions.

Many enterprise buyers require or strongly prefer Type II. If your startup is pursuing SOC 2 for the first time, many teams start with Type I to validate that appropriate controls exist, then transition to Type II within 12 months.

The developer-specific implication: Type II means you cannot "cram" for an audit. Your controls need to work every day for months, which means building compliance into your development workflow rather than bolting it on before audit season. This is where the compliance process starts to look like security best practices, not bureaucratic overhead.

Why Developers Need to Understand SOC 2

SOC 2 compliance used to live in a separate compliance department. Three shifts in how service organizations operate have changed that.

Engineering teams now own the controls that auditors test. When an auditor asks, "How do you ensure only authorized users can manage customer data in production?", the answer is not a policy document. It is your IAM configuration, your database access policies, and the authorization middleware in your application code.

The security team writes the policy. You implement the actual control. If your role-based access control implementation has a bug that grants excessive permissions, the policy becomes irrelevant. The auditor tests the service organization's controls, not the document.

Evidence collection depends on code-level visibility. Auditors ask questions like "show me everywhere PII is processed in your application" or "demonstrate that all code changes go through peer review." Answering these questions requires you to search across repositories, review git history, and prove your CI pipeline enforces required checks.

With Sourcegraph Code Search, you can run a query like repo:* file:\.go$ PII|personalData|ssn|email and locate every instance of PII handling across hundreds of services in seconds. Without that kind of codebase-wide visibility, the same audit response requires days of manual searching across multiple repositories.

Developer tooling decisions affect compliance posture. The CI/CD pipeline you configure, the secrets management system you choose, the network security infrastructure you deploy: all of these produce evidence in a SOC 2 audit.

A CI pipeline that enforces branch protection, requires code reviews for approval, and runs SAST scans on every pull request is not just good practice. It is a functioning SOC 2 control that generates its own audit trail. Understanding what auditors look for helps you build these security processes correctly from the start, instead of retrofitting them six months before an audit.

The 5 Trust Service Criteria Explained for Engineers

The five Trust Services Criteria (TSC) form the backbone of every SOC 2 audit. Security is mandatory. The other four are optional but commonly included, especially for SaaS companies serving enterprise customers. Here is what each one means for the code you write and systems you maintain.

Security (Common Criteria, Required)

Security is the only mandatory criterion, also called the Common Criteria. It covers protecting systems against unauthorized access and sensitive data from exposure.

What auditors look for: Firewalls and network segmentation, authentication and authorization systems, data encryption at rest and in transit, vulnerability management, intrusion detection systems, malware detection, and security event monitoring.

What this means for your code: Your application's auth layer, RBAC implementation, API authorization checks, and secrets management practices all become audit evidence. Auditors want to see that access controls are enforced consistently across services, not just documented in a wiki. They also want evidence from vulnerability scans showing issues are tracked and remediated within defined SLAs. If your security team claims "all critical vulnerabilities are patched within 72 hours," an auditor will ask for proof: ticket histories, deployment logs, and code diffs showing the fix.

Availability

Availability covers whether your system meets its stated service level agreements (SLAs).

What auditors look for: Monitoring and alerting systems, incident response procedures, disaster recovery plans, backup and recovery testing, capacity planning, and business continuity architecture.

What this means for your code: Your health check endpoints, circuit breakers, retry logic, and failover configurations are all compliance evidence. If your SLA promises 99.9% uptime, auditors check whether your architecture can actually deliver that and whether you have monitoring data showing you met it during the observation period.

Processing Integrity

Processing Integrity ensures data accuracy: that processing is complete, valid, accurate, and timely.

What auditors look for: Input validation, error handling, data processing monitoring, quality assurance, control testing, and reconciliation processes.

What this means for your code: Your validation logic, idempotency guarantees, data transformation tests, and pipeline monitoring are in scope. If a webhook handler drops events silently or your ETL pipeline truncates records without logging an error, that is a processing integrity gap an auditor can flag.

Confidentiality

Confidentiality protects information designated as confidential: trade secrets, intellectual property, and non-public financial data.

What auditors look for: Data classification schemes, encryption of confidential data, access restrictions to prevent unauthorized disclosure, secure data disposal, and confidentiality agreements.

What this means for your code: How you tag data sensitivity levels, apply encryption, handle retention and deletion, and prevent logging of confidential data in plaintext.

That last one trips up many teams. Structured logs that include full request bodies can expose API keys or sensitive financial data, a common audit finding.

Privacy

Privacy covers personal information of data subjects: its collection, use, retention, disclosure, and disposal.

What auditors look for: Consent mechanisms, data minimization, PII access controls, retention policies, and processes for handling data breaches.

What this means for your code: Your consent collection flows, data anonymization logic, PII field encryption, user data export and deletion endpoints (think GDPR right-to-erasure), and audit trails of who accessed personal data.

With Code Search, you can run structural queries to find every file that handles PII fields like email, ssn, phone_number, or address across your entire codebase, giving auditors a definitive map of where sensitive information flows through your systems.

SOC 2 Compliance Checklist for Development Teams

This checklist maps each control area to specific developer actions and the evidence you will need to produce during an audit. Unlike generic compliance checklists written for security teams, this one focuses on implementing controls that engineering needs to build and maintain.

The shortcut most teams miss: Instead of compiling evidence manually before each audit process, build evidence collection into your existing workflow. Structured logging that captures authentication events, CI pipelines that enforce review requirements and log their enforcement, and codebase-wide search queries all generate audit evidence automatically.

This continuous approach is more effective than point-in-time scrambles. Nutanix demonstrates this model: they used codebase-wide search to find and fix every instance of the Log4j vulnerability across their large codebase during their own compliance work.

Essential Tools for SOC 2 Developer Compliance

No single tool covers all SOC 2 requirements. Effective compliance stacks combine tools across several key areas, and the right combination depends on your stack, team size, and which Trust Services Criteria you are pursuing.

Secrets Management and Access Control

Storing secrets in environment variables or .env files committed to version control is one of the most common audit findings that many service providers encounter. Use a dedicated secrets manager: HashiCorp Vault, AWS Secrets Manager, or Google Cloud Secret Manager. Pair this with infrastructure-as-code (Terraform, Pulumi) so access policies are version-controlled and auditable.

A practical check you can run today: Search your codebase for hardcoded secrets using Code Search. A query like repo:* (API_KEY|SECRET_KEY|password\s*=\s*["']) will surface files where secrets may be committed across all repositories.

Code Insights can then track this pattern over time, showing your team and auditors a dashboard of "hardcoded secrets detected" trending toward zero.

Vulnerability Scanning

Dependency scanning (Snyk, Dependabot, Trivy) catches known CVEs in your supply chain. SAST tools (Semgrep, CodeQL) find security issues in your own code. DAST tools (StackHawk, Burp Suite) test running applications. Running all three in your CI pipeline means every pull request gets a security check before merge.

The remediation bottleneck nobody talks about: Scanning finds vulnerabilities. Fixing them across 50 or 200 repositories is the real work.

When a scan identifies a deprecated cryptographic function used across dozens of services, Batch Changes automates the fix: define the search-and-replace pattern once, and it opens tracked pull requests across every affected repository. This approach scales compliance remediation beyond individual Jira tickets filed for each repository.

Logging and Monitoring

Centralized logging (Datadog, Splunk, the ELK stack) with structured JSON output gives auditors searchable evidence of security events. Configure alerts for authentication failures, permission changes, and data access anomalies. Retain logs for the duration your controls specify, commonly 12 months for SOC 2 Type II.

What to log for SOC 2 specifically: Authentication events (login success/failure, MFA challenges), authorization decisions (access granted/denied), data access events (who read what PII and when), configuration changes (infrastructure and application), and deployment events. If your logs do not capture these categories, you have a gap that an auditor will find.

Compliance Platforms

Dedicated compliance platforms (Vanta, Drata, Secureframe) automate evidence collection from cloud providers, identity systems, and vendor management tools. They maintain a continuous record of control status and generate auditor-ready reports. These platforms handle infrastructure-level evidence well, but they cannot see inside your code. That is where code intelligence tools like Sourcegraph provide the application-level evidence that compliance platforms miss: which services handle PII, whether deprecated functions have been removed, and whether security patterns are consistently implemented across your codebase.

How to Prepare for a SOC 2 Audit as a Developer

The audit process follows a predictable pattern. Here is what it looks like from the engineering side, with concrete actions at each stage.

Months 1-2: Scope and Document. Work with your security team to conduct risk assessments and define which systems are in scope for the audit. Document the controls you have already built: authentication systems, encryption implementations, logging pipelines, and deployment processes.

The gap most teams hit here is that internal controls exist informally but are not documented or consistently enforced. A thorough gap analysis at this stage reveals what needs work, and a codebase-wide search is essential for closing those gaps. With Sourcegraph, you can run queries like repo:* lang:python import.*cryptography or repo:* func.*Authenticate to inventory your existing security implementations.

Compare what your policy documents claim against what your code actually does. Discrepancies found now are fixable. Discrepancies found by an auditor become official findings.

Months 3-4: Remediate Gaps. Fix the gaps identified during scoping. Common remediation work includes adding structured logging where it is missing, enforcing optional branch protection rules, implementing MFA for production database access, scheduling security awareness training for the team, and integrating SAST scanning into CI pipelines.

When gaps span many repositories (a deprecated TLS configuration used in 30 services, for example), Batch Changes coordinates the fix across your entire codebase with a single declarative file, opening tracked PRs for each affected repository instead of filing individual tickets.

Months 5-6: Evidence Collection and Pre-Audit. Compile evidence that your controls work: pull request review records showing approvals, deployment logs with timestamps, vulnerability scan results over the observation period, access review records, and incident response documentation.

Run a pre-audit readiness review with your compliance team. If your logging and CI pipelines have been running correctly, most of this evidence already exists. The work is querying and exporting it, not creating it from scratch.

Ongoing: Maintain Controls. SOC 2 Type II requires ongoing monitoring and continuous compliance, not point-in-time readiness. Code Insights dashboards enable this by tracking key metrics over time.

Set up tracking queries for metrics like "percentage of repositories with security scanning enabled," "number of hardcoded secrets detected," or "services still using deprecated TLS versions." These dashboards give your team a real-time view of security posture between audits and serve as evidence of continuous monitoring for user entities and future auditors alike.

SOC 2 vs. ISO 27001: What Developers Should Know

Both SOC 2 and ISO 27001 address information security, but they differ in structure and market expectations in ways that affect your engineering work.

The practical difference for developers: SOC 2 gives you freedom to define controls that match your existing architecture. If your access control system uses a custom RBAC implementation, you describe that as your control, and the auditor tests whether it works. ISO 27001 defines 93 controls in Annex A, and you select which ones apply through a risk-based Statement of Applicability. You can exclude controls with documented justification, but the framework is more prescriptive than SOC 2's open-ended approach.

SOC 2 compliance is increasingly expected for US SaaS, so many growing companies start there, then add ISO 27001 for regulatory compliance when expanding into European markets. The engineering work overlaps significantly. Access controls, encryption, logging, vulnerability management, and incident response are foundational to both. Building your systems with SOC 2 security practices in mind also covers substantial ground toward ISO 27001.

Conclusion

SOC 2 compliance is engineering work. The controls auditors evaluate (access management, encryption, logging, vulnerability remediation) are the same systems you build and maintain as a developer. The teams that achieve compliance smoothly are not the ones that scramble to compile evidence six weeks before the auditor arrives. They are the ones who built evidence collection into their daily workflow from the start, gaining an improved security posture and a competitive advantage in the process.

Start with the checklist in this guide and focus on the Security criterion first, since it is required and covers the broadest ground. From there, build out controls for whichever additional criteria your customers require. The earlier you invest in codebase-wide visibility and automated evidence collection, the less painful every subsequent audit becomes.

If your team needs to find security patterns across hundreds of repositories, coordinate vulnerability fixes at scale, or track compliance metrics over time, explore how Sourcegraph's code intelligence platform fits into your compliance workflow. Sourcegraph itself holds a SOC 2 Type II attestation, so the tool handling your source code meets the same security bar you are working toward.

‍