SOC 2 readiness problems usually begin before the examination starts. Teams rush into evidence collection before the system is properly scoped, choose a report type without checking customer expectations, or document controls that are not yet operating consistently. By the time the CPA firm begins testing, the organization may discover that its evidence does not support the story its policies and control matrix are trying to tell.
A stronger readiness process works in the opposite direction. Define the system first, identify which Trust Services Criteria are relevant, map those criteria to controls the business can actually operate, test the controls before the examination period, and build evidence into normal work. The goal is not to create a temporary compliance project. It is to make the eventual SOC 2 examination a review of how the organization already operates.
Define the System Before Building the Control List
One of the most important corrections to the original draft is that the SOC 2 system description is not simply “the auditor's view” of what is in scope. Management prepares the description of the service organization's system, and the independent CPA evaluates whether that description is presented in accordance with the applicable description criteria.
That distinction matters because management has to understand and describe what it is asking the CPA to examine. The scope can include relevant services, infrastructure, software, people, procedures, data, and system boundaries. If those boundaries are vague, the control mapping will be vague too.
Start with the services customers rely on and the commitments the company makes about them. Then identify the systems and processes required to meet those commitments. A cloud platform used only by an internal department may be outside one report's scope, while a less prominent application that stores customer data or supports the delivered service may be directly relevant.
The current AICPA Trust Services Criteria organize the Security category around the common criteria, CC1 through CC9. Security is included in every SOC 2 examination. Availability, Processing Integrity, Confidentiality, and Privacy add category-specific criteria when they are relevant to the service commitments, system requirements, and intended report scope.
Do not automatically add every category because a larger scope looks more impressive. Each additional category should correspond to something the organization genuinely needs to demonstrate and can support with appropriate controls and evidence.
Also avoid redesigning the program around draft standards too early. The AICPA periodically updates its guidance and, as of late 2026, has proposed a future modernization of the Trust Services Criteria. Proposed criteria are not the same as effective criteria. Confirm which version applies to the planned engagement and any transition dates with the CPA firm performing the examination.
Choose Type 1 or Type 2 Based on What Customers Actually Need
A SOC 2 Type 1 report addresses the design and implementation of controls as of a specified date. A Type 2 report goes further by addressing the design and operating effectiveness of controls throughout a specified period.
That makes the decision commercial as well as technical. A company may choose Type 1 because it can be completed without demonstrating operating effectiveness over a historical examination period, then discover that a major prospect or customer requires a Type 2 report.
The opposite mistake also happens: a team commits to Type 2 before its access reviews, change approvals, security monitoring, vendor reviews, and other controls are operating consistently enough to support testing over time.
Review customer contracts, security questionnaires, procurement requirements, and sales commitments before deciding. If a customer says it needs a Type 2 report, determine whether that requirement includes particular Trust Services Categories, a minimum reporting period, or a report covering a particular product or service.
Get the requirement in writing. A vague request to “be SOC 2 compliant” is not enough to design an examination plan.
SOC 2 is also better described as an examination and report than as a certification. A licensed, independent CPA examines the applicable attestation standards and issues an opinion. The result is not a simple universal pass/fail badge; report users evaluate the scope, opinion, system description, controls, testing, results, and other details that matter to their own risk decisions.
Run a Readiness Assessment Before the Formal Examination
Walking into a SOC 2 examination without testing your own readiness first can turn ordinary control gaps into expensive surprises. A structured readiness assessment gives the company time to identify problems while it can still correct the underlying process.
A useful readiness assessment should answer four questions:
- Is the scope correct? Do the system boundaries and selected categories match the services and commitments the organization intends the report to cover?
- Are the controls designed appropriately? Is there a control or combination of controls that addresses each applicable criterion and identified risk?
- Are the controls actually operating? Can the team show recent, representative evidence that the process works as described?
- Can the evidence be retrieved and understood? Does it show who performed the activity, when it happened, what was reviewed, and what happened when an exception was found?
A soc 2 checklist from IS Partners can provide a useful starting structure for scoping, gap analysis, documentation, and evidence collection. It should be adapted to the organization's actual system and planned report rather than treated as a universal list of controls every company must implement.
Readiness findings should end with named remediation actions, owners, and target dates. Fix controls that are absent or ineffective before polishing documentation around them. A well-written policy cannot compensate for a process that employees do not follow.
Turn the Criteria Into Controls People Can Actually Operate
SOC 2 does not prescribe one fixed control set for every service organization. The organization designs controls that address the applicable criteria, its risks, and the commitments it makes to users.
That makes clear control ownership essential. A control should have someone responsible for making sure it operates, someone who can provide or locate the evidence, and an escalation path when the control does not work as expected. One person may own several controls in a smaller company, but responsibility should still be explicit.
Consider a quarterly user-access review. The policy may say that managers review access every quarter, but readiness requires more detail:
- Which systems are included?
- Who generates the user list?
- Who reviews it?
- What does the reviewer check?
- How are inappropriate permissions removed?
- How is completion documented?
- What happens if the review is late?
If nobody can answer those questions consistently, the organization does not yet have a mature control simply because the policy contains the words “quarterly access review.”
Do Not Start a Type 2 Period Before the Controls Are Stable
A common readiness mistake is treating the beginning of the Type 2 examination period as the deadline for finishing control design. That is too late for controls that need to operate repeatedly throughout the period.
Before the period begins, perform sample runs of important controls. Complete an access review, trace a production change from request through approval and deployment, test an incident-response exercise, review a vendor, and verify that evidence is stored where the team expects it to be.
If a control fails during the examination period, fixing it later does not erase the earlier event. The organization should document what happened, assess the cause and impact, remediate the issue, and retain evidence of the response. The service auditor evaluates deviations in the context of the engagement, including their nature and significance.
That is another reason to avoid thinking in terms of “passing” SOC 2. The objective is to operate controls reliably and give the CPA sufficient evidence to evaluate them, not to hide every imperfection.
Build Evidence Collection Into Normal Work
Evidence should be an output of the control, not an archaeological exercise performed months later.
When a production change is approved, preserve the ticket and approval. When a user-access review is completed, retain the population reviewed, the reviewer's decision, and evidence of any follow-up. When security training is completed, keep the completion record. When a vendor is reassessed, retain the assessment and resulting actions.
Good evidence usually answers basic questions without requiring a long explanation:
- What happened?
- Who performed or reviewed it?
- When did it happen?
- What population or system was covered?
- What exceptions were identified?
- How were those exceptions resolved?
Screenshots can be useful, but a screenshot without a date, user, source, or surrounding context may be weaker evidence than teams expect. Likewise, an automated compliance platform can reduce manual collection but cannot make poor evidence reliable simply by importing it.
Test retrieval before the examination begins. Select a small sample of controls and ask the owner to produce the evidence without special preparation. If the team cannot find it, explain it, or connect it to the documented control, fix the process before formal testing.
Treat Exceptions as Information, Not Just Audit Problems
Readiness testing should deliberately look for failure modes. If every test case is the cleanest possible example, the organization learns very little about whether the control will hold under normal operating pressure.
Test a terminated employee whose access crossed several systems. Review an emergency change. Examine a vendor whose security review was completed late. Trace an incident that required escalation. Look at a control that changed owners during the year.
For each exception, determine whether the problem came from control design, inconsistent operation, unclear ownership, missing evidence, or a scope assumption that was wrong from the beginning.
That analysis improves the business as well as the audit. A recurring evidence gap may reveal that a process depends on one employee's memory. A late access removal may expose an HR-to-IT handoff problem. An incomplete vendor review may show that the vendor inventory itself is unreliable.
Handle Vendors and Subservice Organizations Deliberately
Cloud hosts, data processors, infrastructure providers, payment platforms, and other service providers may perform functions that support the in-scope system. Their role should be considered during scoping rather than discovered when the CPA requests evidence.
SOC 2 reporting can address subservice organizations using different presentation methods. Under a carve-out method, the subservice organization's controls are generally excluded from the description of the service organization's controls, while the description identifies the relevant services and related responsibilities.
Under an inclusive method, specified controls at the subservice organization are included in the scope of the report. The appropriate treatment should be discussed with the examining CPA firm.
When relying on a provider's SOC report, do more than confirm that the PDF exists. Check whether the relevant service is in scope, whether the reporting period aligns with your needs, whether the opinion or testing contains relevant exceptions, and whether the report identifies responsibilities that your organization must perform.
Complementary user entity controls require similar attention. These are controls that customers are expected to perform for the service organization's controls to achieve the intended objectives. If customers must configure access appropriately, review reports, or notify the provider of changes, those responsibilities should be understandable and consistent with the actual service model.
Revisit Scope as the Business Changes
A SOC 2 readiness program can become outdated even when the original design was sound. New products, acquisitions, cloud migrations, AI features, office locations, customer types, and vendors can change the system being described, and the risks that controls need to address.
That is why the broader question of whether the data security model can scale with the business matters during SOC 2 readiness. The report should not become a static picture of an architecture or operating model the company has already outgrown.
Build scope review into material change processes. When a new customer-facing service launches or a major infrastructure dependency changes, ask whether the system description, risk assessment, control mapping, subservice-organization treatment, and evidence plan still make sense.
Changes during a Type 2 period also need attention. Do not assume that a replacement tool, redesigned control, or new process can simply be substituted without documentation. Record what changed, why it changed, when the new control became effective, and how the organization maintained the relevant objective during the transition.
Do Not Treat the Issued Report as the Finish Line
A SOC 2 report covers a defined system, scope, and date or period. It does not mean the organization's controls can be ignored until the next examination.
Access reviews, risk assessments, vendor management, incident response, change control, monitoring, security training, and other recurring activities still need to operate. If the team stops collecting evidence after the report is issued, the next readiness cycle will recreate the same scramble.
Ongoing monitoring also gives the organization a chance to identify control drift before a customer or auditor does. Track overdue controls, repeated exceptions, ownership changes, systems added to scope, and evidence that repeatedly requires manual reconstruction.
The strongest SOC 2 programs become less visible internally over time because the controls are embedded in ordinary work. Readiness then stops being a special project and becomes a disciplined way of running the system the company has committed to customers.
Before the Examination Starts: SOC 2 Readiness Questions Teams Still Need to Resolve
What if customers want a Type 2 report but the company is only ready for Type 1?
Do not assume a Type 1 report will satisfy the requirement. Ask the customer what it will accept and for how long. A Type 1 report can demonstrate control design and implementation at a specified date, but it does not provide the same evidence of operating effectiveness over time as a Type 2 report. If the commercial requirement is Type 2, build a realistic path to an examination period rather than presenting Type 1 as an equivalent substitute.
How long should a SOC 2 Type 2 examination period be?
No single period is right for every organisation. Agree on the period with the CPA firm, and make sure it makes sense to the customers or other report users relying on it. The practical readiness question is whether controls can operate consistently and produce sufficient evidence for the entire planned period. Do not choose a longer period simply because it appears stronger if the controls are not ready to support it.
Does one failed control sample mean the company has failed SOC 2?
No automatic rule works that way. The service auditor evaluates exceptions in context, including their nature, frequency, cause, and effect on the relevant criteria and controls. A deviation can still be important, and some issues can affect the auditor's opinion, but the correct response is to investigate and document the problem rather than assume one exception automatically invalidates the entire engagement.
Can compliance automation software replace a readiness assessment?
No. Automation can help inventory systems, map controls, collect recurring evidence, assign owners, and track tasks. It cannot decide the business scope, determine whether a control actually addresses a risk, explain a contradictory piece of evidence, or replace the professional judgment involved in a SOC 2 examination. Use automation to support a sound control environment, not to create the appearance of one.
Does every vendor need its own SOC 2 report?
No. Vendor due diligence should be risk-based. The organization should understand what the vendor does, what data or systems it can access, how critical the service is, and what assurance is appropriate. A SOC report may be highly useful for some providers, while contracts, security questionnaires, certifications, technical testing, or other evidence may be more appropriate for others.
Can one SOC 2 report automatically cover every product the company sells?
Only if those products and the systems supporting them are actually included in the described scope. A company with several products, platforms, or service models should not assume that a report covering one system gives assurance over all of them. Sales and customer-success teams need to understand the report boundaries so they do not make broader claims than the report supports.