Many engineering organizations first encounter SOC 2 when a customer or prospect requests proof of compliance before proceeding with a relationship. Access controls, change management processes, logging configurations, vulnerability scanning, and incident response procedures all need to be in place, documented, and producing evidence before an auditor evaluates them. A 2026 benchmark of 75 SOC 2 examinations found that these engineering-owned areas were the most common sources of exceptions.
This checklist covers the full SOC 2 process in four phases: define scope and plan, close gaps and implement controls, collect evidence and complete the audit, and maintain continuous compliance. It addresses both the cross-functional program and the engineering responsibilities within it. Your organization's scope, infrastructure, and risk profile will determine which steps need more attention. Where tooling can reduce manual compliance work, we’ll say so. Tooling can get you audit-ready, but the CPA firm’s examination decides the outcome.
What is SOC 2 compliance?
SOC 2 is a framework developed by the AICPA for evaluating an organization's controls against a set of criteria called the Trust Services Criteria. The output of a SOC 2 examination is an attestation report issued by an independent CPA firm. It carries the firm's opinion on whether the organization's controls meet the criteria. It is not a certification, and no official SOC 2 badge or seal exists.
SOC 2 reports come in two types. A Type 1 report evaluates control design at a single point in time: are the controls in place and suitably designed? A Type 2 report goes further and evaluates whether those controls operated effectively over a defined period, typically six to twelve months. Some organizations pursuing SOC 2 for the first time start with a Type 1 and then move to Type 2, though others go directly to Type 2. Type 2 is what customers and prospects generally expect to see.
The five Trust Services criteria
Every SOC 2 examination evaluates controls against the AICPA's Trust Services Criteria, which are organized into five categories. The common criteria (CC1–CC9) make up the Security category and apply to every SOC 2 examination. In practice, Security appears in 100% of SOC 2 reports. The remaining four categories are included based on the organization's services, commitments, and the scope of the examination.
Availability appeared in 75.3% of the SOC 2 reports in the CBIZ sample, and Confidentiality in 64.4%, which reflects how commonly organizations include criteria beyond Security. The criteria themselves do not prescribe specific controls; each organization identifies its own controls to meet them. This is why two companies with similar SOC 2 reports can have very different control environments.
The SOC 2 compliance checklist
The following checklist is organized into four phases. It is intended as a starting point and can be expanded, shortened, or altered to fit your organization's requirements.
SOC 2 is a cross-functional effort. Engineering typically owns the technical controls, evidence, and service-level documentation, while legal, HR, security, and compliance teams handle policies, vendor assessments, personnel controls, and auditor coordination. The steps below cover the full program but spend more time on the areas that engineering teams are responsible for.
Phase 1: Define scope and plan
Step 1: Set SOC 2 objectives, timeline, and stakeholders. Before anything else, clarify why your organization is pursuing SOC 2. In most cases the driver is a customer or sales requirement, so ask those customers which report type and Trust Services Criteria they expect before you set scope. Define the target timeline, identify which teams will be involved, and make sure you have leadership support, because SOC 2 preparation touches almost every part of the engineering organization.
Step 2: Choose the examination type and applicable Trust Services Criteria. Decide whether to pursue a Type 1 or Type 2 report, and determine which Trust Services Criteria apply beyond Security. Type 1 evaluates control design at a point in time, while Type 2 evaluates operating effectiveness over a period. If this is your first SOC 2, a Type 1 is a faster initial milestone before moving to Type 2, though some organizations go directly to Type 2.
Step 3: Define the system boundary. Identify the systems, infrastructure, applications, data flows, and teams that fall within the scope of the examination. Auditors recommend defining the system boundary before selecting criteria, since the boundary determines which controls are relevant and what evidence you'll need to produce. SOC 2 reports have been growing in scope, with 23% of reports now containing more than 150 security controls, so be disciplined about what's in and what's out of scope.
Step 4: Inventory in-scope services and assign ownership. Once the boundary is set, map the services within scope to their owners, repositories, dependencies, and documentation. Accurate inventory and clear ownership are necessary for every later step in this process, from applying controls to collecting evidence to responding to auditor questions. If ownership is unclear, the rest of the program stalls. Cortex gives you a live service and ownership map, automatically syncing team and ownership data from your Git provider, identity provider, HR system, ITSM tool, on-call tool, or cloud tags, so that ownership records stay current as people move between teams.
Step 5: Run a gap assessment. With your inventory and ownership in place, assess where your current controls, documentation, and evidence fall short of what the examination requires. Identify missing controls, incomplete documentation, services without clear owners, and areas where evidence does not yet exist. This assessment gives you a prioritized list of work for Phase 2.
Phase 2: Close gaps and implement controls
Step 6: Prioritize gaps and assign control owners. Take the output of your gap assessment and turn it into prioritized work. Each gap needs an owner, a deadline, and enough context for the person responsible to act on it without chasing down background information. Controls that affect the most services or carry the highest audit risk should move to the top of the list.
Step 7: Document required policies and procedures. SOC 2 requires documented policies and procedures that support in-scope controls. Some of these are cross-functional (acceptable use policies, HR onboarding and offboarding procedures, vendor management policies), while others are engineering-specific (change management procedures, incident response plans, access review processes). If your organization already has these documented, review them for accuracy and completeness. If they exist only as tribal knowledge, now is the time to write them down, because auditors will ask to see them.
Step 8: Implement required organizational and technical controls. The common criteria (CC1–CC9) fall under the Security Trust Services Criterion and cover the areas where engineering teams do most of the hands-on work. In the Lazarus Alliance benchmark, the most frequent exception areas map directly to these criteria: access control and user provisioning showed up in 51% of examinations, change management in 41%, logging, monitoring, and alerting in 37%, security configuration and vulnerability management in 24%, and incident response and continuity testing in 19%.
For engineering teams, common controls include least-privilege access policies and timely deprovisioning when employees leave, branch protection and required pull request approvals so that code changes go through peer review before merging, encryption in transit (TLS) and at rest for sensitive data, logging and monitoring configurations that produce auditable records of system activity, vulnerability scanning with defined remediation SLAs, and on-call ownership so that incident response has a clear escalation path. The specific controls your organization needs will depend on the scope and criteria you defined in Phase 1, and these examples are not an exhaustive list. Start with access control, since it topped the exception list above. Cortex Workflows can route requests for production environments and other sensitive resources through a self-service form with approval steps, so every access grant follows the same path instead of starting as a Slack DM.
Step 9: Codify engineering requirements as measurable standards. Once you've identified the engineering controls that support your SOC 2 program, the next question is how to verify that those controls remain in place across all in-scope services as code changes, teams reorganize, and infrastructure evolves. Defining requirements as measurable rules and evaluating them continuously is more reliable than checking a spreadsheet once before the audit.
Cortex Scorecards can continuously evaluate engineering standards across your services. Cortex offers a prebuilt SOC 2 Compliance Scorecard that checks for service ownership, on-call assignment, TLS configuration, branch protection, required PR approvals, vulnerability scanning, unit testing, a recent risk assessment, and links to penetration-test results and data-retention documentation. Each rule is evaluated against live data from the tools you already use, such as GitHub for branch protection or PagerDuty for on-call, so a result reflects the current configuration and not what a team reported in a spreadsheet. Organizations can modify these rules or add their own to match their specific control environment, and teams already using Scorecards for production readiness will find that many of the same rules apply. A passing Scorecard indicates that the defined engineering conditions are being met; it does not determine SOC 2 compliance, which is the auditor's role.
Step 10: Test controls and address remaining gaps. Before the examination begins, verify that your controls work as intended. Run through the scenarios your controls are designed to address: try to merge code without the required approvals, confirm that access revocations take effect within your defined SLA, verify that logging is producing the records you expect. Address any gaps that surface during testing. It is better to find problems now than to have them show up as exceptions in the auditor's report.
Engineering controls are only one part of the broader SOC 2 program. Steps 6 through 10 should be running in parallel with the cross-functional work on policies, HR controls, vendor assessments, and physical security that other teams are responsible for.
Phase 3: Collect evidence and complete the audit
Step 11: Map controls to supporting evidence. Each control in your SOC 2 program needs supporting evidence, and that evidence needs to be connected to the system, service, and owner it relates to. Examinations average roughly 1,450 evidence artifacts (about 1,650 for Type 2 and 900 for Type 1), and 88% of examinations require at least one additional round of evidence after the first submission. The same benchmark found that organizations that pre-mapped controls to evidence needed fewer of those clarification rounds. Scattering evidence across Google Drive folders, Confluence pages, and Slack threads makes retrieval slow and increases the likelihood that something is missing or outdated when the auditor asks for it.
For engineering-specific evidence, this means connecting items like penetration-test results, data-retention policies, and vulnerability scan outputs to the services they apply to. Cortex Workflows can standardize how evidence is linked to the relevant service entity, so that retrieval during the examination is a lookup rather than a search.
Step 12: Collect and validate audit-ready evidence. Before providing evidence to the auditor, confirm that it is current, complete, and relevant to the controls it supports. For a Type 1 examination, the auditor evaluates control design at a point in time, so evidence needs to demonstrate that the controls exist and are suitably designed. For a Type 2 examination, the auditor also evaluates operating effectiveness over the review period, which means evidence needs to show that controls operated consistently throughout that window.
Check that access review records are complete, that vulnerability scan results cover the full review period, that change management logs show the approval workflow operating as designed, and that incident response records include the expected documentation. If something is missing, find it now, before the auditor asks for a second round of evidence.
Step 13: Complete the examination and address findings. The SOC 2 examination is conducted by an independent CPA firm. During the engagement, expect evidence requests, control demonstrations, walkthroughs of key processes, and follow-up questions where the auditor needs additional documentation or clarification. If the auditor identifies exceptions (controls that were not designed or operating effectively), you'll have the opportunity to provide additional context, though the auditor ultimately decides whether to include the exception in the report.
One Cortex customer, a talent management software company with approximately 100 to 150 engineers, used Cortex Catalogs and Scorecards to create a real-time view of service ownership, domain relationships, repository links, and SOC 2 control alignment. During the examination, they were able to demonstrate control status to auditors in real time rather than compiling manual evidence packages, and they reported saving five minutes per service per Scorecard rule by replacing manual assessments with real-time checks..
Phase 4: Maintain continuous compliance
Step 14: Continuously monitor SOC 2-related control conditions. Because a Type 2 report evaluates controls over a defined period, typically six months for a first report and twelve months after that, and most organizations renew annually with no gap in coverage, your controls need to operate and produce evidence continuously. A quarter where a control lapsed will show up as an exception in the next examination.
Monitor the engineering controls you defined in Phase 2 to catch drift while there is still time to fix it. If a service loses its on-call rotation after a team reorganization, or a repository's branch protection gets disabled during a migration, those gaps need to surface quickly. Cortex MCP can surface this information directly in an engineer's workflow: asking "How is my SOC 2 Scorecard doing?" returns which entities are failing Scorecard rules and suggests next steps. The auditor's examination, not the Scorecard, determines whether controls meet the criteria.
Step 15: Turn identified control gaps into owned remediation work. When a service falls out of compliance with a defined standard, the remediation needs an owner, a deadline, and visibility. Cortex Initiatives can assign remediation deadlines, open Jira tickets, and notify service owners when their entities are failing, so that identified gaps move through a tracked workflow.
Step 16: Refresh evidence and review controls regularly. Evidence goes stale. Penetration tests expire, risk assessments become outdated as infrastructure changes, and access review records need to cover the current review period. Establish a recurring cadence for refreshing evidence, reviewing policies, and confirming that access privileges still reflect current roles. The Lazarus Alliance benchmark found that renewals had exceptions 60% of the time compared to 84% for first-time examinations, partly because control ownership was already established.
Step 17: Update scope and controls as the environment changes. Your SOC 2 scope is not static. New services, infrastructure migrations, vendor changes, acquisitions, and team reorganizations can all affect which systems fall within the boundary and which controls apply to them. When significant changes occur, reassess the affected controls and evidence rather than waiting for the next examination cycle to discover that the system description no longer matches the live environment. Cortex flags new services and ownership gaps as the environment changes, and services scaffolded through Workflows start out cataloged, owned, and measured against your Scorecard baseline, so new systems don't enter scope without an owner or a control check.
Why SOC 2 compliance becomes a fire drill
Most SOC 2 scrambles trace back to three conditions: the engineering standards behind SOC 2 controls live in a policy doc or wiki page, ownership records for in-scope services are out of date, and evidence sits in whichever tool produced it. If nobody is tracking whether those controls are operating between audits, the months before an examination turn into a scramble to verify the current state, chase down owners, and compile evidence that should have been connected to the relevant services all along.
Defining engineering requirements once and evaluating them continuously across in-scope services can prevent much of this work from piling up. That approach involves two separate activities: linking evidence to a service (attaching a penetration-test report to the service it covers) and continuously monitoring the underlying technical condition (verifying that branch protection is still enabled on a repository). Both reduce manual audit preparation, but they serve different purposes. As one CPA firm partner noted, automated tools can collect user lists, configuration snapshots, and change approvals, but they cannot judge whether that evidence is complete, valid, or sufficient. The auditor's assessment of control design and operating effectiveness is a separate activity that tooling supports but does not replace.
How Cortex helps engineering teams stay SOC 2-ready
The checklist above describes a process that runs across multiple teams and tools. Cortex covers the engineering side of that process by connecting several capabilities into one workflow.
It starts with knowing what you have and who owns it. Cortex Context Graph maintains a live inventory of services, owners, repositories, and dependencies, with ownership data synced automatically so that it stays current through team changes and reorganizations. This inventory is the foundation that the rest of the SOC 2 workflow depends on, because controls, evidence, and remediation all need to be tied to a specific service and a specific owner.
From there, the prebuilt SOC 2 Compliance Scorecard evaluates those services against the engineering checks covered in Step 9. A failing rule becomes an Initiative with an owner and a deadline, and the evidence that proves the fix, such as a new penetration-test report, is linked to the same service through Workflows. Because Scorecard results, remediation work, and evidence are all tied to the same entity, an engineer who asks Cortex MCP about SOC 2 status gets the failing rules and suggested next steps for their own services.
Cortex is an Engineering Operations Platform that helps keep the engineering side of SOC 2 continuously audit-ready and complements your organization's broader compliance and GRC processes. It does not replace policy management, HR controls, auditor coordination, or the examination itself. We go through the same examination ourselves: Cortex holds its own SOC 2 Type 2 report and ISO/IEC 27001:2022 certification, documented in the Cortex Trust Center.
To see how Cortex fits into your SOC 2 program, schedule a demo.
FAQs
Is SOC 2 a certification?
No. A SOC 2 report is an attestation issued by an independent CPA firm, not a certification. The report contains the firm's opinion on whether your organization's controls meet the Trust Services Criteria. There is no official SOC 2 certificate, badge, or seal, and the examination itself does not use the word "compliance" as a formal term. Organizations that refer to "SOC 2 compliance" are generally describing the state of meeting the standards evaluated in the report.
What is the difference between a SOC 2 Type 1 and Type 2 report?
A Type 1 report evaluates whether controls are suitably designed at a specific point in time. A Type 2 report evaluates both design and operating effectiveness over a defined period, typically three to twelve months, with at least six months recommended. Type 2 is what most customers and prospects expect to see, because it demonstrates that controls are sustained over time rather than assessed on a single date. Some organizations start with a Type 1 and move to Type 2 within a year, while others pursue Type 2 directly.
How long does SOC 2 take, and how often do you need to re-audit?
For a first-time SOC 2, expect roughly six to twelve months to reach a Type 2 report and two to four months for a Type 1. The preparation time depends on how many controls are already in place and how much remediation is needed. After the initial report, Type 2 examinations renew annually with no gap in coverage between reporting periods, so organizations maintain a continuous cycle rather than starting from scratch each year.
How much does SOC 2 compliance cost?
Costs vary significantly depending on the size and complexity of the organization, the number of Trust Services Criteria in scope, and whether it's a first-time or renewal examination. Audit fees from CPA firms range from roughly $20,000 to $150,000, with a median around $30,000, and internal preparation typically requires 40 to 80 hours of staff time in the first year across engineering, IT or security, and HR. Organizations also invest in tooling, remediation work, and ongoing maintenance, which adds to the total cost but is harder to generalize.
Who can perform a SOC 2 audit?
Only a licensed CPA firm can conduct a SOC 2 examination and issue the attestation report. The AICPA sets the professional standards that govern the examination, and the firm's work is subject to peer review. In 2026, the AICPA publicly raised concerns about compliance automation vendors marketing fast, inexpensive SOC 2 reports, noting that tool vendors that are not CPA firms cannot attest to controls. When selecting an auditor, it is worth checking the firm's SOC examination experience, peer review results, and sampling methodology.
How do engineering teams keep SOC 2 evidence current between audits?
The most common approach is to establish a recurring cadence for refreshing evidence, reviewing access privileges, and confirming that controls are still operating as designed. Penetration-test results, risk assessments, and access review records all have a shelf life and need to be updated within the review period. Automating the evaluation of engineering standards across services can flag drift between examinations, so that a lapsed control or a missing owner shows up in a dashboard or notification rather than in the auditor's exception report. If a reorg leaves a payments service without an on-call rotation in March, a continuous check flags it that week; without one, the gap can sit open until the auditor samples that service. The Lazarus Alliance benchmark found that renewal examinations had fewer exceptions than first-time examinations, in part because control ownership was already established.
