Introduction to SOC 2

SOC 2 (System and Organization Controls 2) is a widely recognized auditing standard developed by the AICPA (American Institute of Certified Public Accountants). It evaluates a service organization’s controls related to the security, availability, processing integrity, confidentiality, and privacy of customer data.

This framework is especially critical for technology and cloud companies. It provides independent assurance to customers that the organization maintains effective internal controls to protect sensitive information and systems.

SOC 2 Change Management Requirements

A core SOC 2 requirement (aligned with Trust Services Criteria such as CC8.1) states that the entity must:
Authorize, design, develop or acquire, configure, document, test, approve, and implement changes to infrastructure, data, software, and procedures to meet its objectives.

This directly applies to code deployments and infrastructure modifications. The goal is to prevent unauthorized, untested, or risky changes that could compromise security, availability, processing integrity, or other key principles

Many organizations, including those I have worked with, require technology vendors to maintain SOC 2 compliance. As a result, it has become a critical certification for B2B SaaS and cloud service providers.

How AI Challenges Traditional Controls Generative AI is transforming software development by writing code, generating tests, and authoring documentation. While this boosts productivity, it reduces direct human involvement in the creation process.

However, AI agents cannot be held accountable for changes. Responsibility and ownership must remain with a human. This reality puts new pressure on the “approve” step in the SOC 2 change management process.

Reviewing code, tests, and documentation has always been important. With AI-generated content, thorough human approval becomes essential.

Shifting Responsibilities and Real-World Impact Traditionally, the primary responsibility for deployed code rested with the author. In AI-assisted workflows, that burden shifts more heavily to the reviewer. Every change must have a clear human owner—AI cannot fulfill this role for compliance or accountability purposes. In my experience as VP of Software Engineering, review time for AI-written code increased by approximately 50% compared with human-authored code. While this sounds negative at first, the overall time from starting work to deployment was still faster thanks to AI’s rapid generation capabilities.

Why AI Code Reviews Take Longer AI-assisted reviews require more effort for several reasons:
- Repetitive mistakes: AI tends to repeat the same class of mistake across multiple changes, unlike human authors who typically learn from feedback. - Weaker explanations: AI rarely explains why it made a particular design decision. Human-authored code usually arrives with context: a comment, a commit message, or a conversation. When it does not, the reviewer can ask the author for additional information. AI-generated code often does not come with that context, which means the reviewer must reconstruct the reasoning themselves before they can evaluate whether the approach is sound.
- Limited adaptability: when a reviewer asks for a modification, AI doesn't always interpret the intent behind the request;, it fulfills the literal instruction and sometimes introduces new issues in the process. Reviewers who invest in stronger prompting skills can narrow this gap considerably, but it remains a real source of friction early in the learning curve.

These are not reasons to avoid AI-assisted development. They are reasons to staff and train review processes accordingly. These factors make human oversight more demanding, but they do not eliminate the net productivity gains of AI.

Best Practices for Compliant AI-Assisted Development

To maintain SOC 2 compliance while leveraging AI, organizations should adopt the following practices:
1.Mandatory Human Ownership: Every production change must be owned and approved by a human. AI output should be clearly labeled in pull requests and commit messages.
2.Tiered Review Process:
- Use AI for an initial review pass to catch obvious issues, run static analysis, or suggest fixes first.
- Follow with human review (consider requiring two human reviewers for high-risk or security-sensitive changes).
This layered approach prevents reviewers from getting distracted by minor problems.
3.Enhanced Documentation and Traceability: Document AI tool usage, models involved, and key prompts where relevant. Maintain clear audit trails linking tickets, PRs, tests, and approvals.
4.Reviewer Training — Invest in upskilling engineers on AI-specific pitfalls and advanced prompting techniques to reduce review friction over time.
5.Risk-Based Controls — Apply stricter review requirements to critical paths, security-related code, or infrastructure changes.

Conclusion

AI does not eliminate SOC 2 requirements; it amplifies the importance of robust human approval and accountability in change management. By embracing structured review processes, clear ownership policies, and AI as a supportive (not replacement) tool, organizations can capture significant productivity gains while upholding the controls their customers and auditors expect.

The key principle remains unchanged: A human must own every change. I see a key role of Engineering leadership is to ensure the organization treats the “approve” step with renewed rigor.