For most software companies that sell to other businesses, a SOC 2 report is part of the cost of doing business. The AICPA introduced SOC reporting in 2011, when it replaced the older SAS 70 standard, and security and procurement teams now expect a SOC 2 report from any vendor that handles customer data.
However, the work that goes into a SOC 2 examination is often still manual and periodic. In many organizations, preparation means weeks of exporting user lists, collecting screenshots of repository and cloud settings, and tracking control status in spreadsheets, after which the evidence sits untouched until the next audit cycle.Teams keep adding services and shipping code faster with AI-assisted development, and nothing checks whether controls are still in place.
SOC 2 compliance automation developed as a way to reduce this burden. Automation tools connect to systems such as the identity provider and Git host and collect evidence on a schedule, which removes much of the repetitive work. That evidence shows a control existed when the tool checked. Engineering teams also need to know whether each control stays in place across every service, all the time. In this article we'll cover what SOC 2 compliance automation does and where human judgment still applies, and we'll walk through how to move toward continuous evaluation of engineering-owned controls.
What is SOC 2 compliance automation?
SOC 2 compliance automation is software that reduces the manual work of preparing for and maintaining a SOC 2 examination. Most tools connect to the systems where controls are configured, such as cloud accounts, the identity provider, HR systems, and the Git host. From there, the software collects evidence and monitors each control against the configuration in place.
The controls these tools check come from the AICPA's Trust Services Criteria, which cover five categories: security, availability, processing integrity, confidentiality, and privacy. Security (the common criteria, CC1 through CC9) is required in every SOC 2 report. The organization chooses the others based on its customer commitments. A company that stores financial records will add confidentiality; one with uptime SLAs will add availability.
(SOC 2 examinations never use the word "compliance." A CPA firm issues an attestation report on control design and, for Type 2, on how controls operated over a period. This article uses that shorthand.)
Why automate SOC 2 compliance?
For many compliance teams, SOC 2 is one audit among several. In A-LIGN's 2026 Compliance Benchmark Report, 97% of respondents said they run at least two audits each year. The requirements behind those audits are also growing, and PwC's Global Compliance Survey 2025 found that 85% of executives consider compliance requirements more complex than they were three years earlier. For the security and engineering teams who collect evidence by hand, each additional audit and each new system adds to a growing list of tedious tasks.
Automated evidence collection addresses the most repetitive part of that work. When software pulls user lists, configuration settings, and change records directly from the systems where they live, teams no longer spend the weeks before fieldwork gathering screenshots, and the same evidence can support more than one audit. Continuous monitoring extends this by checking control status between audits, which gives teams a chance to find a failed control months before an auditor would. PwC's respondents who use compliance technology reported results of this kind, with 64% saying they have better visibility of risks and 53% saying they identify and respond to issues faster.
In a manual program, teams usually record a failed control in a spreadsheet and track the fix in a ticketing system, and those two records often fall out of sync. Automation tools that track gaps in one place connect each failed control to an owner and a status, so the team can see which fixes are complete and which are still open. This matters more as an organization grows and more services, repositories, and cloud accounts fall under SOC 2 scope. Staffing is already a constraint for many teams, and in A-LIGN's survey 20% of respondents named limited staff as a key barrier.
What can and can't be automated for SOC 2?
Software can do much of the repetitive work in a SOC 2 program, including configuration checks, evidence collection, and reminders for recurring tasks. People in the organization make the decisions about policy, audit scope, and accountability, and auditors expect to know who made each decision. The table at the end of this section lists common SOC 2 activities and shows whether each one is automated, partially automated, or done by humans.
What you can automate
Most teams begin with evidence collection and control monitoring. A tool can pull configuration data from cloud accounts on a schedule, record changes to user permissions in the identity provider, and keep a history of both for the audit period. For access reviews, software can list the users and permissions for each system and send the list to the correct reviewer. Policy tracking is another common use, because software can record which employees received and acknowledged each policy. Many tools also send vendor assessment questionnaires on a schedule and flag vendors whose reviews have expired.
Engineering controls are often the easiest to check with software, because their settings are already stored in developer tools. Examples include service ownership, TLS configuration, branch protection on the default branch, a required pull request approval before merge, limits on open vulnerabilities, and data retention settings. Each of these has a clear pass or fail result, so a system can check every service at once.
What still requires human judgment
People in the organization write and approve policies, and they decide with their auditor which Trust Services Criteria and systems are in scope. Engineers design and carry out complex fixes, such as changes to network segmentation or data isolation, because those fixes require architectural decisions. Executives sign off on the program, and people operate and review physical security controls, such as badge access to an office or data center.
Some activities are partially automated. For example, software can collect access-review data or flag a new risk, and a person reviews the result and makes the final decision. The AICPA has made a similar point about auditors. In May 2026, its Peer Review Board issued an alert that tells peer reviewers to examine how CPA firms use SOC platforms and whether each engagement fits the client's risks. An AICPA vice president also said that some firms rely too much on third-party SOC platforms without applying professional judgment.
Evidence collection isn't the same as continuous compliance
Evidence collection is an important part of any SOC 2 program. Auditors need proof that controls are in place, and automation tools make that proof easier to gather. However, most evidence only describes one system at one point in time. A screenshot of branch protection settings proves that one repository was protected on the day the screenshot was taken. It does not prove that the organization's other repositories are protected, or that the setting was still turned on a month later.
Continuous compliance means checking every control on every service in scope, all the time. With continuous checks, a team can find a new repository without branch protection as soon as someone creates it, and can show an auditor that the control was in place for the entire audit period.
Cloud credentials are a common example of this problem. Many security teams have a policy that requires access keys to be rotated every year. However, Datadog's 2025 State of Cloud Security report found that 59% of AWS IAM users had an access key that was more than one year old. For a company with a one-year rotation policy, each of those keys is a failed control.
This problem gets bigger as organizations add services and deploy more often, and AI-assisted development adds to both. The 2025 DORA report found that 90% of respondents use AI at work, and that higher AI adoption is associated with higher delivery throughput and higher delivery instability. According to DORA, more changes without strong controls, such as automated testing and good version control practices, lead to more instability. DORA's research covers delivery performance. We expect a similar effect on SOC 2 controls, because every new service and every configuration change can cause a control to fail.
Auditors have also raised this issue. In a February 2026 Journal of Accountancy article, members of the AICPA SOC 2 Working Group said that tools which pull evidence from client systems into one dashboard are useful, because they replace many screenshots and spreadsheets. However, they were concerned about vendors that advertise SOC 2 reports as fast and easy. According to the article, this kind of marketing can lead to templated reports and to pressure on CPA firms to do fewer audit procedures. The AICPA's SOC page also states that the AICPA is looking into allegations about one compliance vendor's SOC business practices.
Compliance leaders describe the same need. In PwC's 2025 Global Compliance Survey, Anil Markose, Chief Compliance Officer at Oracle SaaS, said that compliance programs need tools that confirm obligations are met at all times, and that teams should find and fix compliance drift faster. For engineering controls, this means checking each control on every service in scope whenever the service changes, and keeping a record of each result.
What to look for in SOC 2 compliance automation software
SOC 2 automation tools generally offer the same core capabilities: evidence collection, control monitoring, and integrations with cloud and identity systems. The differences show up in which specific systems a tool connects to, how often it checks controls, and what it does when something fails.
Because the tool can only collect evidence from systems it connects to, teams usually start by listing their own cloud providers, identity provider, HR system, Git host, and ticketing system, and checking which of them the tool supports.
Some tools collect evidence only during audit preparation. Others run checks on a schedule, such as daily, and save every result. With daily checks, the team sees failures close to when they happen, and the results give the auditor evidence for the full audit period.
A good remediation workflow assigns each failure to the person who owns the affected system, sets a due date, and tracks the work to completion. For organizations with many open findings, this replaces the work of copying each one into a ticketing system and following up with each owner individually.
Most SOC 2 programs require yearly access reviews and policy acknowledgments, and both tasks involve coordination across many people in the organization. For access reviews, the tool pulls the current list of users and permissions from each system, routes the list to the correct reviewer, and records each decision. Policy acknowledgment is simpler, since the tool distributes each policy to employees and records who has acknowledged it.
Many organizations also prepare for ISO 27001, HIPAA, or other frameworks alongside SOC 2. When a tool maps one control to several frameworks, the team collects evidence once and applies it across audits. The AICPA publishes mappings from the Trust Services Criteria to ISO 27001 and to NIST CSF, which show significant overlap between these frameworks.
Engineering teams own many of the controls in a SOC 2 program, including branch protection, required pull request approvals, TLS configuration, and vulnerability thresholds. These controls apply to every service and repository in scope, and the number of services changes frequently as teams build new ones. A tool that tests each of these controls across the full service catalog continuously, and shows which services are failing and who owns them, gives the team a complete picture across all of their services.
How to implement SOC 2 compliance automation
Implementation typically starts with connecting the systems that the automation tool will monitor: the cloud providers, identity provider, HR system, Git host, and any other tools where SOC 2 controls are configured. Once the integrations are in place, the tool can read the current state of each system and begin collecting data.
The next step is mapping the organization's controls to its environment. This means identifying which Trust Services Criteria are in scope, where each control is configured, and where gaps exist today. For engineering controls, this includes identifying which services and repositories need branch protection, pull request approvals, TLS, and vulnerability scanning, and confirming that each service has a designated owner.
With the mapping complete, the team can turn on automated evidence collection and monitoring. The tool collects evidence from each connected system on a schedule and checks each control against the configuration it finds. For engineering controls, teams can define each standard once and evaluate it against every service in the catalog.
The mapping will also show gaps: controls that are documented but not yet configured, services without owners, or settings that do not match the standard. A remediation workflow assigns each gap to an owner with a target remediation date, and the tool tracks each fix to completion. As the team closes gaps, the tool records the updated state as new evidence.
Once the team closes the initial gaps, the tool continues to check each control on its schedule. When someone creates a new service or changes a setting, the check runs again. The team and the auditor can both see the record of each control's status for the full audit period.
Where Cortex fits into SOC 2 compliance automation
Cortex's engineering operations platform complements GRC and compliance automation tools. A GRC platform manages the broader compliance program and produces the evidence packages that go to the auditor. Cortex continuously evaluates the SOC 2 controls that engineering teams own, across every service in the organization's catalog.
Cortex Catalog maps every service to its owner, its dependencies, and its connections to tools like the Git host, cloud provider, and incident management system. Cortex Scorecards use that data to grade each service against a set of rules. Teams define a rule once, and the Scorecard evaluates it against every service that the rule applies to.
Cortex includes a SOC 2 Compliance Scorecard template organized into three levels. Foundational Security checks whether each service has an owner, has on-call coverage, has TLS enabled, has branch protection on the default branch, and requires pull request approval before merge. Operational Compliance adds a linked data retention policy, passing vulnerability scans at medium severity and above, and unit testing. Advanced SOC 2 Maturity adds a linked penetration test, a risk assessment completed within the last year, and passing vulnerability scans at all severity levels. Teams can modify these rules or write new ones in Cortex Query Language (CQL).
When a service fails a Scorecard rule, Catalog's ownership data identifies the engineering team responsible. Teams can create Initiatives to turn failed rules into organization-wide remediation programs with assigned owners, target dates, progress tracking, and notifications. For example, a team might create an Initiative called "Ensure data retention policy is linked for all services" and set a deadline for completion.
SOC 2-related documents, such as penetration test reports and risk assessments, can be linked to the services they apply to. Scorecard rules verify that these documents exist and that time-sensitive requirements, such as an annual risk assessment, are current.
Cortex MCP lets teams query Cortex data from an AI assistant. A team can ask "How is my SOC 2 Scorecard doing?" and get a summary of which services are failing which rules, who owns them, and what to fix next.
As LetsGetChecked grew from about 15 to over 100 services, the company used Cortex Scorecards to embed compliance and quality requirements into how services are built. LetsGetChecked reported a 67% reduction in MTTR and a 2× increase in deployment frequency. These are engineering health outcomes, and teams can track them through Engineering Intelligence, but they also support the operational requirements of a SOC 2 program, since faster incident response and consistent build practices contribute to the controls an auditor examines.
Book a Cortex demo to see how a SOC 2 Scorecard can continuously evaluate engineering-owned controls across your service catalog.
Frequently asked questions
Does SOC 2 compliance automation replace an auditor?
No. A CPA firm must perform the SOC 2 examination and issue the report. Automation tools collect evidence from the organization's systems and monitor control status, which makes the auditor's work easier by keeping evidence organized and current. The auditor still decides whether each control is designed correctly and, for a Type 2 report, whether the control operated effectively over the audit period. In May 2026, the AICPA Peer Review Board issued an alert that specifically addresses CPA firms that rely too much on SOC platforms without applying professional judgment.
Can SOC 2 compliance automation support other frameworks like ISO 27001 and HIPAA?
Many SOC 2 controls overlap with controls in other frameworks. The AICPA publishes mappings from the Trust Services Criteria to ISO 27001 and to NIST CSF, which show that organizations already doing SOC 2 have completed a significant portion of the work for those frameworks. Most automation tools can map one control to several frameworks so the team collects evidence once and applies it across audits. The AICPA does not publish a direct mapping to HIPAA, but many of the security controls in a SOC 2 program, such as access management, encryption, and vulnerability scanning, also apply to HIPAA compliance.
How is continuous compliance different from a point-in-time SOC 2 audit?
A point-in-time audit looks at whether controls were in place on a specific date or during a specific period. The evidence for that audit is collected before or during the examination. Continuous compliance means the organization checks each control on every service in scope on a recurring schedule, such as daily, and saves each result. This gives the team a running record of control status, so they can find and fix a failure close to when it happens. When the next audit begins, the evidence already exists for the full period.
Who owns SOC 2 controls that live in engineering?
In most organizations, the security or compliance team owns the SOC 2 program, but the controls that depend on engineering configuration, such as branch protection, TLS, and vulnerability scanning, are maintained by the engineering teams that own the services. This can create a gap: the compliance team documents the control, and the engineering team is responsible for keeping it configured correctly on each service. Tools like Cortex Catalog connect each service to its engineering owner, so when a Scorecard rule fails, the team responsible for that service can see the failure and fix it.
How does SOC 2 automation work alongside a GRC platform?
A GRC platform typically manages the overall compliance program: policies, risk registers, vendor assessments, and the evidence packages that go to the auditor. SOC 2 automation tools connect to the organization's cloud, identity, HR, and developer systems to collect evidence and monitor controls. An Engineering Operations Platform like Cortex adds a third layer by continuously evaluating the engineering-owned controls that the GRC platform documents. For example, a GRC platform might document that the organization requires branch protection on all repositories, and Cortex Scorecards can verify that every repository actually has it enabled. The three tools serve different parts of the compliance program, and the evidence from each one can feed into the auditor's examination.
