Learn · SOC 2 Readiness

What a SOC 2 Readiness
Assessment Actually Involves

A readiness assessment is the work that has to happen before an examination can succeed. Done properly it produces six things: a scoped system boundary, a selected criteria set, a control set mapped to criteria, a gap list with owners and dates, an evidence plan, and a timeline you can defend. It is a consulting service. It issues no opinion, and it produces nothing a customer can rely on.

The line that gets blurred: readiness is a consulting service; the examination is an attestation performed by a licensed CPA firm under AT-C 205. The readiness provider can find your gaps and specify your evidence. Your management still owns every control-design decision, and the firm that helped you build the controls generally should not be the firm signing the opinion on them.

Talk to a Compliance Advisor SOC 2 Audit Preparation

6deliverables a readiness assessment should produce

33common criteria in scope on every SOC 2

250+SOC 2 engagements supported by TCSA

Plain-English explainer · AT-C 205 examination · Last reviewed August 2026

A SOC 2 readiness assessment is a structured, non-assurance exercise that establishes what your report will cover, which criteria apply, which controls meet them, where you fall short, what evidence each control must produce, and the earliest date an observation period can honestly begin. Every one of those is a decision or an artefact; none of them is an opinion. The examination itself is a separate engagement, performed by a licensed CPA firm under the AICPA attestation standards codified at AT-C sections 105 and 205, and that firm will re-test independently everything readiness looked at. Readiness is mis-sold constantly: as a “pre-audit”, as a document you can send a customer, as a certificate of preparedness, and — most damagingly — as something that can be performed by the same people who will later sign the report on the controls they designed.

Key Takeaways

A readiness assessment should produce six deliverables — a scoped system boundary, a selected criteria set, a control set mapped to criteria, a gap list with owners and dates, an evidence plan, and a dated timeline. If you cannot point to all six at the end, you bought a workshop.
Readiness is a consulting service and issues no opinion. Nothing in it is performed under AT-C 105 or AT-C 205, and the output has no standing with a customer’s vendor-risk team.
Management must own every control-design decision. Under the AICPA’s nonattest services provisions the client assumes management responsibilities, oversees the work through someone able to evaluate it, and accepts the results — a provider that decides for you creates a threat no safeguard cures.
Budget your own time as well as the fee. A first assessment typically consumes 35–50 hours of client time across six to nine people before remediation even starts, and the schedule slips when those people are not booked.
Remediation is rarely the slow part — evidence maturation is. A control fixed on 1 April produces no testable population until it has run, which is why the honest output of readiness is often a later period start than the sales plan assumed.
Check log retention before the period opens — by fieldwork it is already too late. A control that operated correctly all period but whose month-one evidence has aged out of a 90-day window tests as an exception.

What it produces

The six deliverables

A readiness engagement is easy to sell and hard to price, because the visible artefact — a deck, a spreadsheet — is not the value. These six outputs are. Read the right-hand column when scoping: the ownership split is where disputes begin, and where the independence rules bite.

Deliverable	What makes it usable	Who owns the decision
A scoped system boundary	The services, products, environments, legal entities and data flows the report will cover — plus the exclusions, written down with their reasons. Drafted to the level of detail the system description will later need under DC section 200.	Management decides. The readiness provider drafts and challenges.
A selected criteria set	Security in every case, plus a reasoned inclusion or exclusion of Availability, Processing Integrity, Confidentiality and Privacy. Each decision should trace to a service commitment — an uptime clause, a confidentiality obligation — rather than to a guess about what buyers want.	Management decides, on advice.
A control set mapped to criteria	Every applicable criterion mapped to one or more named controls, each with an owner, an operating frequency and a named evidence source. Criteria that map to nothing are gaps; controls that map to nothing are usually policies nobody reads.	Management owns the decision. A provider may draft and challenge; management must evaluate and accept.
A gap list with owners and dates	One row per difference between the mapped control set and what actually operates. Each carries a severity, a named human owner, a specific action, a target date and the criteria it unblocks. A gap without an owner and a date is an observation.	The readiness provider identifies; management commits.
An evidence plan	For each control: the population it generates, the system of record that produces it, who extracts it, how long that system retains it, and how completeness and accuracy will be shown. The deliverable most often missing, and the one that decides whether fieldwork takes three weeks or three months.	Joint — specified by the provider, produced by control owners.
A realistic timeline	A dated plan from remediation, through the earliest defensible period start, to the report date — with the CPA firm’s own lead time built in rather than assumed. Its most valuable output is the date the period can honestly begin.	Management, with the CPA firm’s calendar as a constraint.

A seventh artefact usually exists — a summary memo for the board or an investor. Treat it as internal: it carries no opinion and no independent testing.

What it costs you

The hours that come out of your side

Proposals quote a fee and a duration. The number that actually determines whether a four-to-eight-week assessment finishes in four or in twelve is how much of your team’s calendar it consumes, and which specific people have to be in the room. Nobody can answer a control walkthrough on behalf of the person who runs the control.

Week	Activity	Who from your side	Client hours
Week 1	Boundary and criteria sessions — what the report covers, which entity it names, which trust services categories the contracts already commit you to.	CTO or founder, Head of Platform, and whoever owns the MSA (legal or commercial).	6–10 hrs
Weeks 2–3	Control walkthroughs by domain: logical access, change management, incident response, vendor management, HR and onboarding, business continuity and recovery.	One owner per domain, plus HR for onboarding, background checks and training records.	2–3 hrs per domain; 12–20 hrs total
Weeks 3–4	Evidence-source discovery — one live export run per system, in the room, so the report name, the filters and the retention window are all captured while someone who can run it is present.	Whoever holds admin on each system: cloud accounts, identity provider, code repository, ticketing, HR platform, endpoint tooling.	8–12 hrs
Weeks 4–5	Mapping review and gap-list walkthrough — severity agreed, owners named, target dates and evidence-ready dates committed against a calendar.	All named gap owners, plus the executive who will sign the management assertion.	4–6 hrs
Through remediation	Weekly gap-list review. Short, dated, and the single practice that separates a plan from a document.	Each gap owner, plus one accountable executive.	~1 hr per owner per week

Totalled, a first assessment for a single product on a single cloud platform typically takes 35–50 hours of client time across six to nine people, excluding remediation itself. These are figures we observe in practice; no standard sets them, and a team that has been through an ISO 27001 certification will land at the lower end because the documentation and the ownership map already exist. The single highest-leverage thing you can do with this table is put the week 2–3 walkthroughs in calendars before kick-off. Remediation effort is separate and sized in the table further down, and the split of who is accountable for each control afterwards is covered in SOC 2 control ownership.

Five confusions

What readiness is not

These come up regularly with teams who have already paid for readiness and believed they had bought something else. The third column is the part that costs money.

What you were told you bought	What the deliverable actually is	What happens if you believe the first column
A pre-audit	A consulting review. Nothing is performed under AT-C 105 or AT-C 205, nothing is tested to an assurance standard, and the provider forms views where a service auditor would form an opinion.	You arrive at fieldwork believing the testing has effectively been done once. The service auditor defines its own populations, selects its own samples and reaches its own conclusions, and the calendar you built on the other assumption is wrong by weeks.
A pre-audit opinion — “you would pass”	A prediction. Passing is determined by an independent firm applying its own procedures and judgement to evidence that mostly does not exist yet, because the period has not run.	The prediction gets repeated to a customer or a board. When the report lands with exceptions in Section 4, the gap being explained is between what someone promised and what an examination measured.
Something you can send a customer	A private working document with no opinion, no management assertion and no independent testing behind it.	You send the gap list to a prospect, and their security team now holds a pre-remediation list of your weaknesses with no opinion attached to contextualise it. There is no way to un-send it.
A certificate — “SOC 2 ready”	A project status. SOC 2 is an attestation by a licensed CPA firm and the deliverable is a report carrying an opinion; there is no certificate at any stage.	The CPA firm re-performs everything, and the eight weeks you thought were credit toward the examination were preparation. Meanwhile a buyer told you were “certified” asks for the certificate.
A “readiness opinion” issued by a non-CPA	A document styled like an assurance product without an assurance standard behind it. There is no attestation standard under which it was performed and no licensed firm accepting responsibility for it.	Nobody downstream can rely on it. A vendor-risk team that accepts it once will not accept it twice, and a buyer who checks the issuing firm’s licence finds there is nothing to check.

The vocabulary matters more than it looks. A buyer who has been told you are “SOC 2 ready” and later learns there is no report, no period and no auditor engaged will reasonably conclude they were managed rather than informed. The honest formulation is a date: our observation period runs from X to Y and the report is expected in Z. We cover the wording in what to tell customers while a SOC 2 is in progress, and the certification-versus-attestation distinction in SOC 2 certified vs attested.

Scope and criteria

The two decisions that set everything else

Readiness begins with the system boundary because everything downstream inherits from it. The boundary names the services in scope and the infrastructure, software, people, procedures and data that deliver them — the five system components management will later describe under the AICPA description criteria at DC section 200 (2018, with revised implementation guidance issued in 2022; DC 200 is SOC 2 only — SOC 1 descriptions fall under AT-C 320). This is where a readiness provider earns its fee, because the work is adversarial in the right way: every inclusion adds evidence burden, every exclusion invites a customer to ask whether the thing they buy is inside it. The failure to avoid is a boundary drawn to minimise work that quietly excludes the product under negotiation.

The second decision is the criteria set. The 2017 Trust Services Criteria (with revised points of focus, 2022) contain 61 criteria: 33 common criteria organised as CC1 through CC9 and mandatory in every SOC 2, plus 28 additional criteria across Availability (A1.1 – A1.3, three criteria), Processing Integrity (PI1.1 – PI1.5, five criteria), Confidentiality (C1.1 – C1.2, two criteria) and Privacy (eighteen criteria running from P1.1 to P8.1 across eight series). Three plus five plus two plus eighteen is the 28. Selecting a category is a commitment traceable to something you already signed, which is what the table below is for. Points of focus are not requirements — they are considerations that may assist in applying a criterion, and a control set built to satisfy every one of them is usually overbuilt. The selection logic is in choosing your trust services criteria, and the SOC 2 simulator will show you which criteria your current control set already covers before you commit to a category.

Category	The contractual trigger that puts it in scope	Evidence burden it adds
Security	Always in scope. The common criteria apply to every SOC 2 examination.	The 33 common criteria, CC1 through CC9 — control environment, communication, risk assessment, monitoring, control activities, logical and physical access, operations, change management and vendor risk.
Availability (A1.1–A1.3)	An uptime commitment, an RTO or RPO, or a service-credit clause in the MSA, the SLA or the order form.	Capacity monitoring and forecasting, backup processes and recovery infrastructure, a recovery-plan test that falls inside the period, and availability incident records.
Confidentiality (C1.1–C1.2)	Contractual data-handling obligations, NDA terms, or retention and destruction commitments made to customers.	Data classification applied in practice, retention and disposal records that show confidential information was actually destroyed, and confidentiality provisions carried through into vendor contracts.
Processing Integrity (PI1.1–PI1.5)	A contractual commitment on the accuracy, completeness, validity or timeliness of processing — common in payments, payroll, billing and data-pipeline products.	Input validation, reconciliation, exception identification and handling, and evidence that processing errors were detected and resolved within the committed window.
Privacy (P1.1–P8.1)	You act as a controller of personal information and have made commitments in a privacy notice. Processing personal data on a customer’s instructions usually points to Confidentiality instead.	Consent and notice records, data-subject access and correction handling, disclosure tracking, quality and retention controls, and disposal evidence across the eight P-series criteria. The heaviest of the four by a distance.

Read the middle column as the test. If nothing you have signed triggers a category, including it because a competitor’s report has it is the expensive version of this decision: you inherit its evidence burden for every period from now on. Two boundary questions belong here too, and are routinely deferred to fieldwork where they cost more. The first is subservice organisations — which vendors are material enough to name, and whether each is handled by the carve-out or inclusive method. The second is the set of complementary user entity controls you intend to assign to your customers. Both change the description, and the description is the thing management asserts to.

Independence

Why the firm doing readiness should not sign

This is the part of readiness with actual professional rules attached, and it is the part most often waved through.

A service auditor must be independent of the service organisation. Readiness is a nonattest service, addressed by the Nonattest Services subtopic of the AICPA Code of Professional Conduct at ET section 1.295, which sits under the Independence Rule (ET section 1.200.001). The general requirements interpretation (ET section 1.295.040) is unambiguous about what the client must do before a firm performs nonattest work for an attest client: assume all management responsibilities; designate an individual with suitable skills, knowledge or experience to oversee the service; evaluate the adequacy and results of the work; and accept responsibility for those results. If the practitioner instead assumes a management responsibility, the management participation threat created is so significant that no safeguard reduces it to an acceptable level. The AICPA’s SOC 2 guide, updated in 2022, put noticeably more weight on independence and nonattest services than its predecessor.

“A firm cannot design and implement your controls and then form an independent opinion on whether those controls were suitably designed. That is auditing its own work.”

— the self-review threat, in one sentence

The strict position is narrower than the market assumes. Readiness performed as a properly-safeguarded nonattest service — identifying gaps, drafting and proposing control design, advising, and leaving every decision with a management team able to evaluate and accept it — can be compatible with a later examination by the same firm. What is incompatible is deciding the control set, writing the policies as the client’s own, operating a control on the client’s behalf or making the scoping decisions, and then opining on them. Most reputable CPA firms manage this by declining deep remediation work for attestation clients, and many buyers apply a simpler rule of their own: they would rather the two roles sat with two organisations. That preference is worth respecting even where the rules would permit otherwise. See SOC 2 auditor independence and who can perform a SOC 2 audit.

It is the reason our own role is drawn where it is. Tranquility Cybersecurity performs readiness, implementation and evidence work and coordinates the examination with a licensed CPA firm. We do not certify, attest, audit or sign — the opinion belongs to the CPA firm, and keeping those roles apart is what makes the resulting report worth something to your customers.

The gap list

A structure that actually gets remediated

Most gap lists arrive sorted by criterion, because that is how the assessment was performed. Nobody remediates by criterion. People remediate by owner, in priority order, against a date. Nine fields make a row workable.

Criteria blocked

The criteria the gap blocks — CC6.2, CC7.2, A1.2. One gap can block several; list them all, because closing it unblocks several at once.

Observed state

What happens today, in a sentence a control owner recognises. Not “inadequate access management” — “access reviews have not been performed on the production console since launch.”

Required state

The specific control that would close it, with a frequency and an owner role. Ambiguity here becomes an argument in month three.

Severity

Blocking (the period cannot start), material (an exception is likely), or improvement (worth doing; it does not gate the start). Three tiers is enough; five invites debate about tiers instead of work.

Named owner

A person. Gaps assigned to “Engineering” have no owner at all.

Target date

When remediation completes — distinct from when the control has produced enough evidence to test.

Evidence-ready date

The date from which the control generates a testable population. Almost every gap list omits it, and it is the field that determines the period start.

Evidence source

The system of record that will produce the artefact, named at the level of detail someone else could re-run: the queue and the saved report, down to the report name.

Status and date closed

Maintained weekly. Weekly is what keeps it a plan.

Three filled rows, in the schema’s own shape. Watch the two date columns: on the CC7.2 row the evidence-ready date trails the target date by two months because triage history has to accumulate before there is anything to sample, and on the A1.2 row it trails by nothing at all because the evidence is the event. That relationship — between when a control exists and when it can be tested — is the whole reason a gap list needs both columns.

Criteria blocked	Observed state	Required state	Severity	Named owner	Target date	Evidence-ready date	Evidence source	Status
CC6.3	Leavers are removed from the identity provider, but downstream database credentials are revoked ad hoc with no record.	Offboarding checklist executed within one business day of the last working day, evidenced by one ticket per leaver with a named approver.	Blocking	Head of Platform	27 Mar 2026	1 Apr 2026	Offboarding queue, saved report “Offboarding — closed”	Closed 26 Mar
CC7.2	Alerts route to a shared inbox. Nothing records who triaged an alert, when, or what the disposition was.	Every alert above the defined severity threshold raises a ticket carrying an assignee, a triage timestamp and a documented disposition.	Material	Security Engineer (named)	10 Apr 2026	9 Jun 2026 — 60 days of triage history has to accumulate before there is a population	Alerting platform → incident queue, saved report “Alerts — triaged”	Open — routing live 8 Apr, history accruing
A1.2, A1.3	Backups run nightly and are monitored, but no restoration has ever been performed from them.	Documented restoration test at least annually, recording scope, timings, result and follow-up actions.	Improvement	Head of Infrastructure	30 Jun 2026	30 Jun 2026 — the date of the first successful documented restore, and there is only ever one occurrence a year	DR test report, stored in the runbook repository	Scheduled

Rows in that shape can be worked. “Improve offboarding” cannot. If you want to see which criteria your existing control set already covers before building the list, the SOC 2 simulator walks the same mapping interactively.

Remediation effort

How long gaps really take to close

Two clocks run here. Remediation time is how long it takes to make the control exist. Evidence maturation is how long it then has to run before there is a population an auditor can sample. Plans that budget only for the first are the commonest cause of a period start that has to move. Everything in this table — the ranges and the expectations alike — is what we typically observe in practice; no standard fixes any of it, and a team with strong engineering capacity will beat these numbers.

Gap type	Criteria blocked	What remediation involves	Remediation	Evidence maturation	Why it slips
Policy missing, or approved but never published	CC1.1, CC2.2, CC5.3	Draft, review, approve, publish, collect acknowledgements.	1–3 weeks	2–4 weeks for the acknowledgement cycle	The approver is not scheduled and the document waits for a monthly meeting.
Process operates but is undocumented	CC2.2, CC5.3	Write down what already happens; align the ticket workflow to it.	1–2 weeks	Usually none — the historical population may already exist	Two engineers describe the process differently and the write-up stalls.
User access review never performed	CC6.2, CC6.3	Define population and reviewers, run the first review, evidence decisions and removals.	2–4 weeks	A quarterly review usually needs two occurrences inside the period	The team runs it once and opens the period the next day.
Joiner / leaver controls with no evidence trail	CC6.1, CC6.2, CC6.3	Instrument onboarding and offboarding so each event leaves a dated record.	2–6 weeks	The period needs to contain actual joiners and leavers	A hiring freeze leaves an empty population, which is a testing problem in its own right.
Logging, alerting and triage gaps	CC7.1, CC7.2, CC7.3	Deploy or tune detection, define alert routing and severities, document triage.	4–10 weeks	1–3 months of alert and triage history before anything can be sampled	Alerting goes live but nobody records the triage.
Vendor and subservice risk management	CC9.2	Build the inventory, risk-rank it, collect assurance reports, set a review cadence.	4–8 weeks	An annual review needs to fall inside the period	A critical subservice organisation surfaces late and changes the description.
No formal risk assessment	CC3.1–CC3.4	Run it, document it, link risks to the control set and to treatment decisions.	3–6 weeks	Typically annual — an auditor will expect one occurrence inside the period	The register is never connected to the controls it is meant to justify.
Change management not enforced in the tooling	CC8.1	Enable branch protection and required approvals; align the procedure to enforced reality.	1–4 weeks	An auditor will expect the change population to show enforcement for the whole period	The period starts before enforcement does, so early changes test as exceptions.
Encryption or architecture change	CC6.1, CC6.6, CC6.7	Engineering work — at-rest encryption on a legacy datastore, segmentation, key management.	6 weeks – 6 months	Configuration evidence exists at cutover, and the change itself needs to pass change management	It is scoped as a compliance task and queues behind revenue work.
Backup restoration or disaster-recovery test never run	A1.2, A1.3	Schedule it, execute it, document results, timings and follow-ups.	2–6 weeks to the first test	Commonly annual — an auditor will expect one credible occurrence inside the period	The first test fails, which is useful engineering and awkward timing.

The pattern is consistent: documentation gaps are fast, evidence gaps are slow. A team can rewrite its entire policy set in a fortnight and still be four months from a defensible period start, because the annual and quarterly controls have not had an occurrence yet. That is arithmetic, and effort does not compress it — which is why readiness should end with a date.

Worked example

A 42-person SaaS team, January to December

An illustrative composite, with the dates that actually moved.

12 Jan 2026

Readiness kick-off

Boundary scoped to one production platform in a single cloud account. A legacy on-premise reporting tool and a separately-run professional-services entity are excluded, both written down with reasons — because a customer will ask.

23 Jan 2026

Criteria selected

Security, Availability and Confidentiality. Availability follows a 99.9% uptime commitment in the standard MSA; Confidentiality follows contractual data-handling obligations. Processing Integrity is excluded, with the reason recorded. That is 33 common criteria plus A1.1–A1.3 and C1.1–C1.2 — 38 applicable criteria.

6 Feb 2026

Control set mapped

61 controls across the 38 criteria, each with an owner, a frequency and a named evidence source. Nine exist only as policy statements with no operating history.

13 Feb 2026

Gap list issued

22 gaps: 5 documentation, 9 process-without-evidence, 6 tooling, 2 engineering. Seven are blocking. The engineering items are at-rest encryption on a legacy datastore and enforced approvals in the code repository. Client time consumed to this point: 44 hours across seven people.

20 Feb 2026

The date conversation

The sales plan assumed a 1 March start. Evidence maturation says otherwise: the encryption work runs 11 weeks from the 13 February gap list, landing 1 May, and the quarterly access review needs two occurrences inside the period. The start moves to 1 May.

27 Feb 2026

Retention audited

CloudTrail is running on Event History only, so the console holds about 90 days. A trail to S3 is enabled on 2 March, ahead of the period, and the SIEM tier is moved from 30-day to 12-month searchable storage. Cost: a line item. Not doing it: a re-run period.

20 Mar 2026

CPA firm engaged

A separate licensed CPA firm signs its engagement letter, independent of the readiness work. Fieldwork slots are reserved in November — the constraint nobody plans for until it bites.

1 May 2026

Period opens

Six-month Type 2 period, 1 May to 31 October. All seven blocking gaps closed; two improvement-tier gaps stay open by documented management decision.

11 May 2026

Walkthroughs

The service auditor runs its own walkthroughs and forms its own view of control design. Nothing from readiness is inherited; two control descriptions are rewritten at its request.

2 Nov 2026

Fieldwork

Populations pulled with parameters and record counts. Three evidence requests are rejected as incomplete and re-pulled — the evidence plan is why it is three and not thirty.

15 Dec 2026

Report dated

Eleven months from kick-off: one month of assessment, then eleven weeks of remediation and evidence maturation before the period could open, then the period and fieldwork. Moving the period start by two months in February is what kept Section 4 clean.

Evidence

What the CPA firm actually requests

The evidence plan is the deliverable that separates a readiness assessment from a questionnaire. Here is what it has to anticipate.

A service auditor testing operating effectiveness does not ask for “evidence of access reviews”. It asks for a population — the complete set of occurrences of that control during the period — then selects a sample from it, and it will not select anything until satisfied the population is complete and accurate. This is the discipline around information produced by the entity (IPE, sometimes rendered “information provided by the entity”), and it is where first-time examinations lose weeks. For each extract, expect the firm to want the report name, the source system, the exact filters or query used, the period covered, and the date and time it was generated — usually as a screenshot showing the parameters alongside the output, plus a record count that reconciles back to the system.

Control frequency	Population in a 6-month period	Sample commonly selected	Typical artefact
Annual	1	1	The dated deliverable itself — risk assessment, DR test report, policy approval record.
Quarterly	2	2 (both occurrences — small populations are normally tested in full)	Completed access review showing reviewer, date, decisions and the resulting removals.
Monthly	6	2–3 (2 is defensible; 3 at higher assessed risk)	Reconciliation or review sign-off with a timestamp and an identifiable reviewer.
Weekly	26	5–8	Vulnerability scan output, backup verification log, patch compliance report.
Daily	~180 calendar days / ~130 business days	15–25	Job success and failure logs, alert triage records, monitoring dashboards with retention.
Event-driven	Varies with volume	25–40 from the full population	Joiner, leaver, change and incident tickets carrying approvals and system timestamps.

Two conventions to note in that table. Daily automated jobs are counted on calendar days and daily manual controls on business days, which is why the population cell carries both; our companion page on sampling and sample sizes works from twelve-month periods and therefore shows larger numbers. And below roughly twenty-five items, sampling stops saving anyone effort, so small populations are normally tested in full — which is why the quarterly row selects both occurrences rather than one.

No AICPA rule fixes these numbers. Sample sizes are a matter of the service auditor’s professional judgement, informed by the population, the assessed risk and the tolerable deviation rate; most firms work from the AICPA Audit Sampling Guide, whose tables address large populations at a minimum ninety per cent confidence level and, separately, small populations and infrequently operating controls. Treat the column above as a planning assumption and confirm it with your auditor. One consequence is worth planning for: when a deviation turns up, the usual response is to expand the sample rather than fail the control immediately — and an expanded sample means another evidence request, in the week you hoped to be finished.

What gets accepted

System-generated reports exported from the source system with the query parameters visible.
Tickets and approvals carrying system timestamps and identifiable actors.
Screenshots showing the full window — URL or server identification, the system clock, the filter applied.
Record counts that reconcile to the system, so the auditor can conclude the population is complete.

What gets rejected

A spreadsheet with no indication of how it was produced — completeness cannot be established from a list.
Screenshots cropped to remove the date, the clock or the system identification.
Evidence dated outside the period, or a policy approved after the period opened offered as proof it applied throughout.
Exports whose filters changed between the first request and the follow-up, so two populations of the same control disagree.
A compliance-platform dashboard showing a green tick, offered instead of the underlying artefact.

The retention trap

The most expensive evidence problem in a first examination has nothing to do with control design. It is that the log which proves the control operated in month one has already rolled off by the time fieldwork asks for it. Retention windows are set by product tier and configuration, they are shorter than most teams assume, and almost none of them backfill.

AWS CloudTrail

Event History in the console shows roughly the last 90 days of management events. Anything longer requires a trail delivering to S3, or CloudTrail Lake — and it has to be configured before the events you will need, because it does not backfill.

GitHub audit log

Retention and API access depend on the plan tier. Teams routinely assume the log is permanent and discover at fieldwork that the window is shorter than the period.

Google Workspace and Okta admin logs

Both retain admin and system-log activity for a finite, plan-dependent window rather than indefinitely. Check the number for your tier and write it into the evidence plan.

SIEM hot storage

Commercial tiers commonly default to 30 or 90 days of searchable storage, with older data in an archive that has to be rehydrated — which costs money and takes days you will not have in fieldwork week.

The rule is simple enough to apply in an afternoon. Before the period opens, confirm that every evidence source retains at least the period length plus your fieldwork lead time — period plus three months is the working number — and where it falls short, turn on archival on day one rather than day ninety. Take a dated screenshot of the retention setting itself while you are there, because the configuration is evidence too. The consequence of skipping this is the one nobody budgets for: a control that operated correctly every day of the period, whose early evidence has aged out, tests as an exception. An auditor can only conclude on what it can see, and “the log rolled off” is an explanation rather than a mitigating factor.

A good evidence plan front-loads all of this: for every control, the system, the report, the person who can run it, the retention window, and any known completeness problem — that the ticketing system was migrated in month two, say, so the population comes from two sources and needs reconciling. Discovering that in November is a bad week. Discovering it in February is a task. The mechanics of collection are covered in SOC 2 evidence collection.

The handoff

What the CPA firm re-examines anyway

A readiness assessment does not transfer credit to the examination. Nothing carries over as assurance. Understanding what genuinely does carry over — and what does not — keeps expectations honest at handoff.

What carries over

Artefacts and organisation: the drafted system description, the control-to-criteria mapping, the evidence inventory, the named owners, and a workforce that has been through a dress rehearsal. Real value — it compresses fieldwork substantially — but preparation, not assurance.

What is re-performed from zero

Everything that touches the opinion. The service auditor evaluates the description against the description criteria itself, forms its own view on whether each control is suitably designed to meet the criterion, runs its own walkthroughs, defines its own populations, selects its own samples and reaches its own conclusions on operating effectiveness. It may reject a mapping readiness accepted, and it frequently rewrites control descriptions.

What management must sign

The written assertion. AT-C 205 requires a written assertion from the responsible party, and the AICPA guide requires one for a SOC 2 — the auditor opines on the description and the controls, but the examination cannot proceed without management’s assertion. No consultant can assert on your behalf, which is the practical expression of the rule that management owns the control environment.

What the auditor will not do

Decide your controls, own your policies, settle your boundary, or tell you what your criteria set should be. If it does, its independence is what you have compromised — and the report is the asset that loses value.

One scheduling note that belongs in the readiness timeline rather than in an email in October: CPA firms allocate fieldwork capacity months ahead, and SSAE No. 23 — effective for engagements beginning on or after 15 December 2025 — aligned the attestation standards with the AICPA’s quality management standards, which has made firms more deliberate about engagement acceptance and staffing. Book the firm when you set the period start. By the time the period ends the slots are gone.

Where this gets contested

Edge cases and awkward questions

The automation platform says we are audit-ready

Compliance-automation tools test configuration state continuously and are genuinely useful for evidence collection. What they do not do is evaluate whether a control is suitably designed to meet a criterion in your specific system, write a description that conforms to the description criteria, or reach an opinion. A green dashboard is an input to readiness; the judgement is bought elsewhere, and no service auditor accepts a platform’s conclusion in place of its own testing.

A control is designed but has never operated

The Type 1 versus Type 2 distinction in miniature. A newly-designed control can be evaluated for design as of a date; it can be tested for operating effectiveness only once it has operated. Teams sometimes propose a Type 1 to escape the wait — legitimate as an interim milestone, and the Type 2 period still has to contain occurrences.

The scope changes after readiness finishes

A new region, a new product, an acquisition, a mid-period migration. The description must reflect what the system actually was, and a Type 2 description is expected to disclose significant changes during the period. Re-open the boundary decision rather than hoping it goes unnoticed; auditors read change tickets.

A subservice organisation surfaces late

Usually a payments processor, an email service or a managed database nobody classified as material. Late discovery forces a description change, a carve-out or inclusive decision, and possibly new complementary user entity controls. The cheapest place to find it is the readiness boundary session.

The readiness provider wants to sign the report

Ask two questions: did you make any control-design or scoping decision on our behalf, and would your independence evaluation survive a peer review? If the first answer is yes, the second is already decided. Some buyers will also object on principle even where the rules permit — a commercial cost of a technically defensible arrangement.

Readiness was completed a year ago and never used

Control environments drift: people leave, tooling changes, the product moves. A year-old gap list is a historical document. Re-baseline the boundary and the mapping rather than resuming from it — usually shorter than the first pass, and still a real piece of work.

Two entities, one brand

Where the contracting entity and the operating entity differ — common when delivery sits in one country and the contract in another — the description has to identify the entity whose system is being reported on, and the assertion comes from that entity’s management. Settle in readiness which entity the report names; depending on how the system and the reporting entity are defined, both sometimes appear. Buyers check it against the invoice, and a mismatch they find themselves generates an awkward call.

A security incident lands inside the period

Not automatically fatal, and concealment is worse than the incident. The description criteria contemplate disclosure of incidents, and how one was detected, escalated and closed is itself evidence about the control environment.

Further reading on two of these: a security incident during the observation period and the common SOC 2 pitfalls.

The failure mode

Readiness done, remediation not, period starts anyway

This is the most common way a first SOC 2 goes wrong, and it is almost never caused by ignorance. It is caused by a customer deadline being louder than a gap list.

The sequence is predictable. Readiness completes in February and identifies seven blocking gaps. An enterprise deal needs a report by year end. Someone works backwards from the deal date, concludes the period has to open on 1 March, and it does — with four gaps still open and a shared belief they will close “in the first few weeks”. Sometimes they do. The problem is that the examination reports on the period as it was throughout, including the weeks those four gaps stayed open.

Outcome 1

Exceptions in Section 4, opinion still unmodified

The most common landing, and the most survivable. The control failed for part of the period; the matrix says so; management responds in the unaudited section. Sophisticated buyers read exceptions in context rather than counting them — but every security review now opens with a question about that row.

Outcome 2

A qualified opinion

Where a criterion was not met for the period, the opinion is modified. It is a durable fact about a document you will be sending to customers for the next year, and it is the outcome that turns a compliance project into a sales problem.

Outcome 3

Scope reduction or a period reset

Pulling a category out of scope, shortening the period, or abandoning it and restarting. Honest, occasionally the right call, and expensive — the clock restarts and the deal date is missed anyway, now with sunk fees behind it.

The mitigation is unglamorous: treat the blocking tier of the gap list as a real gate on the period start, and negotiate the deal date against a shorter first period rather than a compromised one. A clean three-month Type 2 beginning in May outperforms a six-month period beginning in March with four open gaps — in the report, and in the conversation about the report. The two options are compared in choosing your observation period and opinions and exceptions.

Objection handling

What a buyer’s security team pushes back on

Six of these come up often enough to prepare answers for. The answers are short because the honest ones always are.

“Your readiness firm and your auditor are the same organisation.”

Answer with the safeguards themselves: who made the control-design decisions, who wrote the policies, whether any control was operated on your behalf, and how the firm documented its independence evaluation. If the honest answers are uncomfortable, the fix is structural — change one of the two firms — and doing that before fieldwork is cheaper than arguing about it afterwards.

“You said you were SOC 2 ready — send us the report.”

There is no report yet, and a readiness deliverable is not one. Replace the status word with dates: the period runs from X to Y, the CPA firm is engaged, the report is expected in Z. If the buyer needs something interim, a Type 1 or a documented control summary is a real answer; the readiness memo is not.

“Send us the gap list.”

Almost nobody should. It is an internal working document describing your controls before remediation, prepared without independent testing, and it reads as a list of weaknesses rather than a record of work done. Offer the examination scope, the period dates and — once issued — the report, which is the document designed to answer the question.

“Your remediation dates fall inside your observation period.”

The sharpest question on the list, because it is checkable: Section 4 shows when controls operated, and management responses often name remediation dates. If a control was implemented in month two of a six-month period, say so plainly and explain what covered the risk before it. The unrecoverable version is the one where the buyer finds it and you had not mentioned it.

“Your report scope excludes the product we are buying.”

Checkable in Section 3, and buyers do check it. If the service on the order form sits outside the stated boundary, the report does not cover them, and explaining the boundary will not change that — the fix is a scope change effective from the next period, offered with dates attached. This is exactly why every exclusion should be written down with its reason during readiness: the reason is what you read out when this question arrives, and a boundary drawn to minimise evidence work is the one that produces it.

“This is only a Type 1 — we need a Type 2.” / “Your period is only three months.”

A Type 1 is an opinion on suitability of design as of a specified date; it is a legitimate interim milestone and it says nothing about how controls operated over time. Say which of the two you are offering rather than letting the buyer assume. On period length: a clean three-month first period with a stated plan to run twelve months thereafter is a stronger position than a six-month period carrying exceptions from gaps that were still open when it opened. Attach the next period’s dates to the answer, because that turns a limitation into a schedule.

How it gets delivered

Platform, in-house, or a readiness provider

Most pages on this subject treat readiness as one undifferentiated service. In practice there are three routes, most teams use some blend of them, and the honest comparison is not a grid of ticks — it is what each route actually hands you for each of the six deliverables. Read down the column you are considering.

Deliverable	Compliance platform alone	In-house	Readiness provider
System boundary	You define it. The tool inherits whatever you type into the scoping wizard and will monitor a boundary that excludes the product your buyer is asking about, without ever flagging it.	Achievable if someone has been through an examination before. The common failure is drawing the boundary around the org chart instead of around the service commitment.	Drafted adversarially against the contracts: every inclusion priced in evidence burden, every exclusion written down with its reason, in the shape the description will need under DC 200.
Criteria set	Presented as a checkbox per category. The platform has not read your MSA, so it cannot tell you that an uptime clause you signed two years ago has already committed you to Availability.	The decision is yours and you hold the contracts. What is usually missing is a feel for what each category costs in evidence across a full period.	Each category argued back to a specific service commitment, with the excluded ones documented — so an answer exists on the day a buyer asks why Privacy is out.
Control-to-criteria mapping	A pre-built template mapping, and a genuinely strong starting point. It maps generic controls to criteria rather than your controls to your architecture, and criteria satisfied only by a template control fail at walkthrough.	Possible with the TSC document open. Expect to over-map: teams attach five controls to a criterion that needs one, which multiplies the evidence they then have to produce for a year.	One or more named controls per applicable criterion, each with an owner, a frequency and an evidence source, sized so the set is defensible without being over-built.
Gap list	A list of failing automated checks — real and useful, but bounded by what the integrations can see. The manual controls (reviews, approvals, risk assessment, vendor management) show as unmonitored rather than as gaps.	You will find the obvious ones. The gaps teams reliably miss are evidence gaps: a control that operates correctly every time and leaves no record an auditor can sample.	One row per difference, each carrying severity, a named owner, a target date, an evidence-ready date and the criteria it unblocks.
Evidence plan	Automated collection for integrated systems only. Nothing for the manual controls that generate most exceptions, and nothing that anticipates an IPE challenge on a report you exported by hand.	Rarely produced at all. Most first-time teams discover what an evidence plan is by having fieldwork requests rejected in November.	Per control: the population, the system of record, the named report, the person who can run it, the retention window, and how completeness and accuracy will be demonstrated.
Timeline	A readiness percentage. It moves as checks pass and has no view of evidence maturation, the auditor’s fieldwork calendar, or how long an annual control takes to occur.	Usually derived backwards from a customer deadline, which is the mechanism behind the failure mode further down this page.	Derived forwards from the evidence-ready dates and the CPA firm’s booked capacity. Its output is the earliest date the period can honestly open.

The pattern the table earns is worth stating plainly: a platform is excellent as the evidence layer and poor as the decisions layer, and the six deliverables split cleanly along that line. Automation genuinely removes weeks of collection work and holds policy acknowledgements reliably. It cannot draw a boundary against a contract it has not read, or judge whether a control is suitably designed for your architecture. In-house is realistic where somebody has been through an examination before and has the calendar to run it; where nobody has, the cost usually appears later as rejected evidence requests. Whatever the blend, the CPA firm remains a separate engagement in all three columns — the examination is never a route you can choose your way out of.

Frequently Asked Questions

How long does a SOC 2 readiness assessment take?

The assessment itself is usually four to eight weeks for a single product on a single cloud platform — boundary sessions, control walkthroughs, mapping and the gap list — and it consumes roughly 35 to 50 hours of your team’s time across six to nine people over that window. What varies is what follows. Remediation for a team with reasonable engineering hygiene and no architectural gaps typically runs four to eight weeks; a team carrying an encryption or segmentation project can be four to six months from a defensible period start. Readiness should end by telling you which of those you are, with a date attached.

Is a readiness assessment required before a SOC 2 audit?

No standard requires one. Neither AT-C 205 nor the AICPA description criteria mention readiness — it is entirely market practice, which is why nothing on this page describes readiness as a requirement. It is market practice for a reason, though: the examination tests what happened during a stated period, so anything not in place when the period opens is untestable, and the only way to know that in advance is to look. Organisations that skip readiness generally find the same gaps later, in the auditor’s findings rather than in their own plan.

Can the same firm do our readiness assessment and our SOC 2 audit?

Sometimes, with safeguards, and often it is better not to. The AICPA Code of Professional Conduct addresses nonattest services for attest clients at ET section 1.295, under the Independence Rule at ET section 1.200.001: the client must assume all management responsibilities, designate someone with suitable skills to oversee the work, evaluate the results and accept responsibility for them. A firm may draft and propose control design within those safeguards. If it decides the control set, owns the policies or makes scoping decisions for you, the management participation and self-review threats are not curable by safeguards. Many buyers apply a stricter rule and prefer two organisations.

What is the difference between a readiness assessment and a gap analysis?

A gap analysis is one component of a readiness assessment — the comparison of current state against the criteria. Readiness should also produce the scoped boundary, the criteria selection, the control-to-criteria mapping, the evidence plan and the dated timeline. If what you bought produces only a list of gaps, you have a gap analysis, and the two most valuable outputs — the evidence plan and an honest period start date — are missing from it. A quick test at proposal stage: ask whether the deliverable includes an evidence-ready date per gap. Gap analyses do not carry that column.

How much of our own team’s time does readiness consume?

Typically 35 to 50 hours across six to nine people for a first assessment on a single product, before any remediation. The shape is consistent: six to ten hours in week one for boundary and criteria decisions with the founder or CTO and whoever owns the customer contracts; twelve to twenty hours across weeks two and three for domain walkthroughs, at two to three hours per domain; eight to twelve hours running live evidence exports with whoever holds admin on each system; and four to six hours reviewing the mapping and the gap list. These are figures we observe rather than a standard, and the schedule slips when those people are not booked in advance.

Does readiness produce a report we can send to customers?

No, and it should not be used that way. The readiness output has no auditor opinion, no management assertion and no independent testing behind it; it is a private working document describing your controls before remediation. Sending it to a prospect substitutes a list of your weaknesses for the assurance they asked for, and it cannot be un-sent. The document designed for that purpose is the SOC 2 report, and the interim answer is your period dates plus the name of the engaged CPA firm.

What does a SOC 2 readiness assessment cost?

We scope first and quote after, with a fixed fee from $4,000 for early-stage startups. What moves the number is the count of products and environments in the boundary, how many trust services categories you take, whether subservice organisations need mapping, and how much of the control set already exists. The CPA firm’s attestation fee is separate and billed by that firm — no readiness provider should quote you a single number that silently includes someone else’s opinion. Budget your own hours alongside the fee; 35 to 50 of them is the usual internal cost.

Can we start the observation period before remediation is finished?

You can, and it is usually a mistake. The examination reports on the period as it was, so a control implemented in month two of a six-month period is tested against the whole period and generates an exception for the part it did not cover. The better move is almost always to keep the blocking tier of the gap list as a hard gate and shorten the first period instead. A clean short period reads far better than a longer one carrying avoidable exceptions, particularly when you can attach the next period’s dates to the answer.

How far back do our logs need to go before the period starts?

Far enough to cover the whole period plus your fieldwork lead time — period length plus about three months is the working rule, because the auditor requests month-one evidence months after month one has passed. Check each source individually rather than assuming: AWS CloudTrail Event History holds roughly ninety days unless a trail is delivering to S3, SIEM tiers commonly default to thirty or ninety days of searchable storage, and audit-log retention in GitHub, Google Workspace and Okta is finite and depends on your plan. None of them backfill, so archival has to be switched on before the period opens. A control that operated correctly but whose evidence has aged out tests as an exception.

Do compliance automation platforms replace a readiness assessment?

They replace part of the evidence-collection work and none of the judgement. A platform can monitor configuration continuously, hold policy acknowledgements and shorten fieldwork considerably. It cannot decide your system boundary, choose your criteria set, evaluate whether a control is suitably designed for your architecture, or write a system description that conforms to the description criteria. Its gap list is also bounded by what its integrations can see, so manual controls — reviews, approvals, risk assessment, vendor management — show as unmonitored rather than as gaps. Treat the platform as the evidence layer and readiness as the decisions layer.

Written By Expert Auditors

Surendra Pal Singh

Chief Information Security Officer & Data Protection Officer

CISODPOCISAMCSEITILISO 27001 Lead AuditorISO 27701 Lead AuditorISO 42001 Lead Auditor

Saundhi Chauhan

Lead Auditor

ISO 27001 Lead AuditorISO 27701 Lead Auditor

Last reviewed: August 2026•Content verified by certified lead auditors

Keep Exploring

Get in touch

Book a free consultation or send us your requirements. We respond within 24 hours.

Quick Call

Pick a time slot

Send Requirements

Get a custom quote in 24 hours

We're Online

What a SOC 2 ReadinessAssessment Actually Involves