SOC 2 readiness: what to fix before the audit period begins.

Begin with the customer decision the report must support

An enterprise prospect asks for a SOC 2 report. Sales needs a delivery date, engineering sees a new project, and someone suggests buying a compliance platform. Before choosing software or promising an audit window, establish what the customer actually needs to evaluate. A useful readiness plan connects that request to a defined service, the commitments made about it, and controls that people can operate consistently.

Consider a fictional SaaS company that provides scheduling software to regional service businesses. Its application stores customer contact information and appointment records, runs on a cloud platform, and uses an outsourced support team. A prospective customer requests a Type 2 report covering the scheduling service. This example is illustrative, not an SPS client engagement. The question is whether the company can demonstrate how it protects and operates that service over time.

Ask the buyer to confirm the report type, relevant service, expected coverage, and delivery deadline. Separate a contract requirement from a preference stated in a questionnaire, and record who can resolve ambiguity. SOC reports are assurance reports provided by CPAs; a readiness engagement prepares the organization for that independent work. [1] Budget for both preparation and the examination, including the time your own control owners will spend producing and explaining evidence.

Choose the report type before working backward from a date

A SOC 2 Type 1 examination addresses the system description and suitability of control design at a specified point in time. A Type 2 also addresses operating effectiveness throughout a specified period and includes the service auditor’s tests of controls and their results. [2] This distinction changes the preparation problem: a newly approved process cannot, by itself, demonstrate that the process operated during earlier months.

For the fictional scheduling company, a Type 1 may be a useful initial milestone only if the buyer agrees it serves the buyer’s needs. Do not assume that substituting one report for the other resolves a contractual request. Discuss the proposed Type 2 period with the independent CPA firm and the report’s intended users. Set the dates around the service, control operation, evidence availability, and user needs; avoid treating a standard package length as the answer for every company.

Build a plan with separate milestones for scope agreement, remediation, trial operation, examination coverage, fieldwork, and report delivery. Leave room for evidence questions and corrections to the draft system description. Starting the coverage period is not the same as receiving a report. If a commercial deadline leaves insufficient preparation time, give leadership a concrete choice about resources, customer discussions, or timing before the promise becomes difficult to change.

Draw the boundary around the service you actually deliver

AICPA’s Trust Services Criteria address security, availability, processing integrity, confidentiality, and privacy; the applicable categories need to match the engagement. [3] Start with the service commitments and system requirements behind the buyer’s request. For the scheduling company, protection of customer records and commitments about service availability deserve explicit discussion. Choose categories with the service auditor based on those needs, rather than adding categories because a longer list looks more impressive.

Describe the application and API, production infrastructure, relevant data, staff, support workflows, and procedures that keep the service running. Include the systems through which people administer or change production, such as identity and deployment tooling. AICPA publishes separate description criteria for preparing and evaluating the system description. [4] Use that description as a working account of the service, and reconcile it with the architecture and the way people actually perform their jobs.

Keep exclusions explicit. A separate experimental product may be outside the proposed service boundary, but shared administrators or deployment systems can still affect the scheduling platform. Ask what those connections mean for scope instead of erasing them from the diagram. Record the owner, reason, and supporting facts for important boundary decisions. Revisit them when the company adds a product, changes its hosting arrangement, or makes a new customer commitment.

Assign the responsibilities that remain with your company

A cloud provider’s assurance report is useful input, but your team still needs to understand its own responsibilities. AWS, for example, describes security and compliance as shared responsibilities whose allocation depends on the services a customer uses. [5] Review the actual services and settings in your environment. A provider’s work on its infrastructure does not demonstrate how your company approves application changes, reviews privileged access, or handles customer support records.

For each important dependency, record what it does, the data or operations it affects, the relevant assurance available, and the controls your company must operate. Review a provider report for the covered services, period, exceptions, and responsibilities it expects customers to fulfill. Assign someone to follow up on gaps or outdated information. Confirm with your service auditor how subservice organizations will be presented, including the use of carve-out or inclusive treatment and the resulting examination coverage.

In the fictional example, the support partner can view appointment records while resolving tickets. The SaaS company should be able to explain who authorizes that access, what handling rules apply, and how it learns about a support incident. Its own customers may also have responsibilities, such as selecting appropriate tenant administrators. Make those expectations visible in the service documentation. A responsibility that everyone assumes belongs to someone else is a readiness issue worth resolving early.

Turn each control into work an owner can repeat

Build a control matrix that connects applicable criteria to the activity, owner, frequency or triggering event, systems involved, and evidence source. The recommendations here are practical preparation steps; they are not a universal list of SOC 2 controls or mandatory frequencies. A control should explain what happens in your environment well enough that a trained backup owner could perform it when the usual owner is unavailable.

Suppose the scheduling company chooses a monthly review of production administrative access. The owner needs a reliable list of relevant accounts, a basis for deciding which permissions remain appropriate, a way to record decisions, and a process for confirming removals. Saving an account export proves that someone generated a list. The review record should also show who evaluated it, when that happened, which changes were requested, and whether those changes were completed.

Apply the same discipline to other relevant activities, such as approving releases, investigating alerts, checking backups, and assessing vendors. Look for controls that depend on manual work nobody has time to perform. If evidence collection is automated, check that the connector reaches the correct environment and captures the intended population. An attractive dashboard can summarize work, but the owner still needs to explain the underlying activity and investigate missing or inconsistent records.

Design an honest process for exceptions and missed work

Controls need a response path when reality differs from the procedure. A release may use emergency approval, an access review may finish late, or a restoration exercise may uncover a broken dependency. Define who records the issue, who assesses its impact, and who decides the corrective action. Separate an approved alternative process from an unplanned failure to follow the control, and retain the facts needed to understand both.

Imagine the scheduling company discovers that an emergency production change lacked the review required by its procedure. Keep the original change record, record when the omission was discovered, and investigate what happened. A later technical review can help identify defects and guide remediation, but it does not turn the original change into a previously approved change. Date subsequent work accurately and improve the emergency process so the next urgent release follows a workable path.

Track exceptions to resolution with an owner, target date, evidence of action, and follow-up result. Management’s acceptance of risk does not erase a control deviation or determine the service auditor’s conclusion. Discuss significant issues with the CPA firm and provide the underlying facts. Treat repeated exceptions as a possible design or resourcing problem: a procedure that routinely fails under normal workload may need a different implementation, clearer authority, or a more realistic operating schedule.

Rehearse an evidence request before the period begins

Run a trial using records produced by real control activity. Ask owners to retrieve records for selected dates and events without reconstructing or backdating the underlying activity. For example, follow an employee departure through account removal, a production release through its approval, and a backup check through its recorded result. A rehearsal tests whether your procedures produce understandable records and whether another person can retrieve them without relying on the original operator’s memory.

Check the completeness of the underlying population as well as individual examples. If a release list excludes emergency deployments, selecting a clean release from that list does not reveal the missing work. Compare relevant records across systems where practical, and document the limits of the comparison. Your readiness sampling helps find gaps; the independent auditor determines its own examination procedures and evidence needs. Agree how to provide records securely without unnecessarily exposing customer data.

Classify each rehearsal result as complete, unclear, unavailable, or showing an unresolved issue, then assign the next action. A missing historical record cannot be repaired by manufacturing a past approval. If the activity was performed but evidence is incomplete, explain what is known and discuss its implications with the service auditor. Use the trial to improve future operation and retrieval before committing to dates that rely on evidence you cannot produce.

Make a readiness decision with explicit conditions

Hold a readiness review with the executive sponsor and the people who operate the controls. Bring the agreed scope, control matrix, trial results, exception register, and proposed period. Review significant unresolved issues individually. A percentage-complete score can hide an important gap: many finished policies do not compensate for an unowned production control. Record what supports the decision, what remains uncertain, and who has authority to approve the next step.

Use plain internal planning labels. Ready means the team has a defensible basis to propose the period and sustain the work. Conditional means named gaps require specified actions and another decision before affected dates are confirmed. Not ready means unresolved scope, control, ownership, or evidence problems make the current plan unsound. These are suggested management labels, not AICPA designations, a certification, or an advance opinion from the CPA firm.

The fictional company might be conditional while it demonstrates that emergency releases enter the change population and confirms how its support partner’s responsibilities are documented. Its action plan should name the owners, verification needed, and decision date. Leadership can then judge a real dependency instead of hearing that the audit is almost ready. Share the plan and material limitations with the service auditor; a readiness memo does not guarantee the examination result.

Prepare the handoff and keep the controls running

Once the period begins, preserve the operating rhythm. Plan for staff absences, vendor changes, new customer commitments, and product releases that affect scope or controls. Keep records of when significant changes occurred and discuss their examination implications with the CPA firm. Give leadership a useful progress view: controls due, exceptions awaiting decisions, missing evidence, and changes to the service. Continue the work after fieldwork ends so the next reporting cycle has a dependable starting point.

SPS’s SOC 2 Type II Readiness service supports system scoping, gap assessment, control design, policies, a draft system description, and an evidence index. It also includes a mock evidence request across a trial period and a readiness memo identifying remaining work. Your management owns the service and control decisions; the independent CPA firm you engage performs the examination and issues its report. For an initial discussion, bring the customer request, service diagram, target dates, and a candid list of processes that are not yet repeatable.