SOC 2 and Internal App Development: What Your Auditor Is Going to Ask That Your Team Can’t Answer Yet

SOC 2 audits have a way of surfacing things organizations assumed were handled.

An enterprise can have mature security policies, a well-run IT organization, and a track record of clean audits — and still walk into a SOC 2 review and encounter questions about its internal application development process that nobody prepared for. Not because the organization is negligent, but because the questions have changed.

The shift in how auditors approach internally built applications has been gradual, but it’s become more pronounced as AI-assisted development has accelerated how fast organizations build internal tools. Auditors are asking more detailed questions about development pipelines, change management practices, and the governance of applications that handle customer or sensitive business data — and they’re asking them with an understanding that the speed of development has outpaced the governance frameworks many organizations have in place.

If your organization is preparing for a SOC 2 Type I or Type II audit, or is maintaining SOC 2 compliance through annual reviews, the questions in this article are ones your team should be able to answer before the auditor asks them. Most teams currently can’t — not because they don’t care, but because the internal app development process hasn’t been treated as a SOC 2 scope item with the same rigor as other controls.

What SOC 2 actually covers in your development process

SOC 2 is built around the Trust Services Criteria. For most organizations pursuing SOC 2, the relevant criteria that touch internal app development are concentrated in the Change Management and Logical Access categories, with additional requirements under Risk Assessment and Monitoring depending on the organization’s environment.

The Change Management criteria require that changes to systems that are in scope for SOC 2 go through a defined, documented process — one that includes authorization, testing, and review before changes are deployed to production. The criteria don’t specify exactly what that process has to look like. They require evidence that one exists, that it is followed consistently, and that exceptions are documented and reviewed.

The Logical Access criteria require that access to in-scope systems is granted based on documented business need, reviewed periodically, and revoked promptly when no longer necessary. For internally built applications, this means the access controls need to be documented, the provisioning process needs to be controlled, and access reviews need to be demonstrable.

The Risk Assessment criteria require that the organization has identified the risks associated with its systems and has implemented controls to address those risks. For internally built applications, this means there needs to be evidence that someone evaluated the risks of the application before it went into production — not after the audit began.

These requirements apply to any application that is in scope for the SOC 2 audit. The scope determination is itself a point of vulnerability for many organizations: applications that handle customer data, process sensitive business information, or connect to systems that are in scope can be in scope themselves, whether or not the development team thought of them that way when they built them.

The questions auditors are asking now

The following questions reflect what SOC 2 auditors are increasingly focusing on when they examine internal application development practices. They are not hypothetical. They are the questions that surface during audit fieldwork and generate findings when teams can’t answer them.

“Can you walk me through your change management process for this application?”

This is the first question, and it’s the one that most exposes gaps in informal development processes. The auditor wants to understand what happens between “someone decides to make a change” and “the change is live in production.” They’re looking for evidence of a defined process, not a description of what the team generally tries to do.

The answer they’re looking for includes: a change request or ticket that documents what was changed and why, a review step involving someone other than the developer who made the change, a testing step with documented outcomes, and an approval step before deployment to production. The evidence they want is the records that show this process was actually followed — not the policy document that says it should be.

For applications built with AI assistance, this question surfaces a specific gap: if the development team used AI coding tools to build or modify the application, does the change management record reflect the actual development process, or does it reflect a retrospective reconstruction of what the team remembers doing?

“Who approved this application for production deployment, and where is that approval documented?”

This question looks for a specific artifact: a documented deployment authorization. Not an email thread that can be interpreted as approval, not a Slack message from a manager saying “looks good,” but a formal record that identifies who had the authority to approve production deployment and confirms that they did.

Many development teams have informal approval processes that work well in practice but don’t produce the documented artifact the auditor is looking for. When development moved slower, the absence of formal deployment authorization documentation was a common finding but a manageable one. When development is moving fast with AI assistance, the volume of deployments makes the gap larger and the finding more significant.

“How do you ensure that code meets your security requirements before it reaches production?”

This question is about the security review step in the development pipeline. The auditor wants to understand what controls exist between code being written and code being deployed, specifically around security.

The answer can include automated security scanning, manual code review with defined security criteria, penetration testing, or a combination. What it can’t be is “we review the code before we deploy it” without specifics about what the review covers and what happens when it finds something. The auditor will ask follow-up questions about the most recent findings from security review and how they were addressed. If the answer is “we haven’t had any findings,” that’s usually a signal that the review process isn’t thorough enough, not that the code is perfect.

For AI-assisted development, this question has added relevance because AI coding tools introduce specific vulnerability classes that a generic code review may not be calibrated to catch. The auditor may not ask about AI tools specifically, but if your security review process was designed before AI-assisted development was part of your workflow, it may not be adequate for what your team is building now.

“Can you show me the access control configuration for this application and explain how it was set up?”

Access control documentation for internally built applications is one of the most consistently weak areas in SOC 2 audits. The application may have the right access controls in place — the auditor can verify that by reviewing the configuration. What’s usually missing is documentation showing how those controls were designed, what the intended access model is, and who reviewed and approved the configuration.

The auditor is also looking for evidence of access reviews: periodic confirmation that the people who have access to the application still need that access, and that access levels are still appropriate. For applications built and deployed quickly, this review process often doesn’t get established until an audit forces the question.

“What is the process for handling vulnerabilities or security findings in internally built applications?”

This question looks for a vulnerability management process that applies to internally built applications, not just to commercial software and infrastructure. The auditor wants to see that the organization has a defined process for tracking, prioritizing, and remediating security findings in its own code — and evidence that the process is being followed.

For organizations that have adopted AI coding tools, this question also implicitly covers what happens when a security scan identifies a vulnerability in AI-generated code. Is that tracked the same way as a vulnerability in human-written code? Is it remediated on the same timeline? Is there documentation showing what was found and what was done about it?

“How do you maintain documentation of what each internal application does and what data it handles?”

This is the system documentation question, and it’s one of the most commonly incomplete areas. Auditors want to see system descriptions — documentation that explains what an application does, what data it processes, what systems it connects to, and what controls are in place. This documentation serves multiple purposes: it supports the access control review, it provides context for the security review, and it gives auditors the information they need to evaluate whether the organization’s controls are appropriate for the application’s risk profile.

For applications built quickly with AI assistance, this documentation often doesn’t exist in any organized form. The developer who built it knows how it works. That knowledge may not be written down anywhere.

Where most development teams fall short

The gap between what SOC 2 auditors ask for and what most development teams can produce is not about intent. Development teams building internal applications are generally doing their best to build good software. The gap is structural: the development process wasn’t designed to produce the artifacts that SOC 2 requires.

Change management records don’t exist because the team didn’t have a formal change management process — they had a Jira board and a general understanding that changes needed to be reviewed before deployment. Security review documentation doesn’t exist because the team did review the code but didn’t have a standardized way to document that review. Deployment authorization records don’t exist because approval happened in a team meeting or a Slack channel rather than in a system that creates a documented record.

These are not reckless development practices. They’re normal development practices that weren’t designed with SOC 2 audit documentation requirements in mind. The problem is that “normal development practice” and “SOC 2-compliant development practice” are not the same thing without intentional design to make them so.

The acceleration of internal app development through AI tools makes this gap more consequential. When a team was building one or two internal applications per quarter, the documentation gaps were limited in scope. When a team is building four or five per month with AI assistance, the documentation gaps multiply at the same pace as the development output.

What audit-ready development actually looks like

Organizations that go through SOC 2 audits without material findings on internal application development have one thing in common: they built the documentation infrastructure into the development process rather than treating it as a separate activity.

That means a few specific things in practice.

Every internal application that handles in-scope data goes through a defined intake process before development begins. The intake process documents what the application will do, what data it will handle, what systems it will connect to, and what the intended access model is. This documentation becomes the foundation for the security requirements that will apply during development and the system description that auditors will review.

Change management records are generated as a byproduct of normal development workflow. Every change to a production application creates a documented record in the ticketing or project management system. The record includes what was changed, who reviewed it, what testing was done, and who authorized the deployment. This documentation happens automatically because it’s built into the workflow, not because developers remember to do it manually.

Security review is standardized and documented. The organization has defined criteria for what a security review covers and what must be documented. Automated security scanning runs against every code change. Manual review uses a checklist that creates a record of what was reviewed and what was found. Security findings are tracked in the same system as other issues, with documented resolution timelines and confirmation of remediation.

Access controls are configured from documented specifications. Before an application goes to production, there is a documented access model that specifies who should have access and at what level. The production configuration is verified against that specification. Access review happens on a defined schedule, and the results of those reviews are documented.

All of this is the infrastructure that makes SOC 2 audit preparation a matter of organizing existing documentation rather than reconstructing what happened from memory and informal records.

Preparing before the auditors arrive

If your organization is planning a SOC 2 audit in the next six to twelve months and you have internally built applications in scope, the time to address these gaps is now, not during fieldwork.

A few concrete starting points:

Identify all internally built applications that are in scope or likely to be in scope. For each one, assess what documentation currently exists for change management, access controls, security review, and system description. The gaps that assessment reveals are the work items for the next few months.

Review your current development process and map it against SOC 2 change management requirements. Identify where the current process doesn’t produce the documented artifacts that auditors will look for. Design changes to the process that generate those artifacts as a normal output of development activity, not as additional work that developers have to remember to do.

Establish formal deployment authorization for all production changes to in-scope applications. This doesn’t require a complex approval committee — it requires a defined person with authority to approve production deployments and a documented record that approval was given. That record needs to exist for every deployment in the audit period.

Implement or update security scanning in your development pipeline. If your security review process predates your adoption of AI coding tools, evaluate whether it’s calibrated to catch the vulnerability classes those tools tend to introduce. The scanning tools that exist today are capable of doing this — the question is whether they’re configured and integrated into the workflow.

The audit will happen at some point

SOC 2 certification is increasingly a business requirement rather than a competitive differentiator. Enterprise customers ask for it. Procurement processes require it. Insurance underwriters factor it into coverage decisions. The question for most organizations is not whether they will face a SOC 2 audit, but when — and whether they will face it on their own terms or in response to a customer request with a tight deadline.

The organizations that go through those audits smoothly are the ones that built their development processes to produce the right documentation from the beginning. The ones that find it difficult are the ones that have to reconstruct months of development history under audit pressure.

The audit will ask about your internal applications. It will ask about change management, access controls, security review, and deployment authorization. The answers to those questions exist in your development process. The question is whether they’re organized in a way that an auditor can follow — and whether you find out the answer before or during the audit.

The Bottom Line

SOC 2 auditors are asking detailed questions about internal application development that most teams aren’t currently prepared to answer. The gap is not about whether the development team is doing good work. It’s about whether the development process produces the documented artifacts that SOC 2 requires.

The organizations that address this gap before their audit are the ones that build documentation infrastructure into their development workflow rather than treating it as a separate compliance activity. When that infrastructure is in place, audit preparation is straightforward. When it isn’t, the audit surfaces it the hard way.

CloudApper helps enterprise organizations build governed development environments where SOC 2-required documentation — change management records, deployment authorizations, security review artifacts — is generated automatically as a byproduct of normal development activity. Contact us to see how organizations preparing for SOC 2 audits are using CloudApper to close these gaps.