Moving from SOC 2 Type 1 to Type 2

A Type 1 proves controls are designed at a date; a Type 2 proves they operated over a period. This page explains the step up, the cost difference in published estimates and what drives it.

On this page

How moving from SOC 2 Type 1 to Type 2 changes the work

When a customer or contract now asks for a Type 2, the question is whether your controls have been running and leaving evidence for the whole period the auditor will cover. A Type 2 adds an opinion on operating effectiveness over a period, so the auditor can only report once the controls have operated across that window and produced records they can test. A Type 1 only asked whether the design was suitable on one date. The Type 2 turns the same control set into a record of daily behavior, which changes the work from writing controls to running them on schedule and keeping proof. The cost gap is part of the decision. The Justice Department's October 2024 regulatory analysis (89 FR 86116) cited published vendor estimates of $5,000 to $25,000 for a Type 1 and $30,000 to $100,000 for a Type 2. These are estimates drawn from vendor publications, not quotes, and your figures will depend on scope, the number of systems, and the period length. Ask any firm to break its quote into the CPA fee, the readiness work, and the evidence collection, and confirm which of these recur each year. The ownership split stays the same in a Type 2. Your organization owns its controls and the decisions behind them. An implementation partner can prepare the systems, automate evidence capture, and document the process, but only the independent CPA firm issues the report. Before the period starts, assign an internal owner for each control, confirm which evidence the auditor will sample, and agree with the firm in writing when the period begins and ends.

How to move from Type 1 to the first Type 2

The sequence turns a point-in-time Type 1 into a Type 2 by confirming what the Type 1 found, fixing a period and control set, and proving that controls operated across the whole period before the CPA firm can issue an opinion.

  1. Confirm the Type 1 findings and gaps

    Review the Type 1 report, the auditor's findings and any gaps between the control design and what the team actually does day to day. Management owns this review, and an implementation partner can help map each finding to a control owner and a fix. The output is a written gap list with an owner and a target for each item, agreed with the CPA firm before any change is made to the control set. Confirm with the auditor which Type 1 observations they expect to see closed before the Type 2 period starts.

  2. Choose the observation period start date

    Management selects the start date for the first Type 2 period, and the CPA firm confirms it fits the scope and the customers' expectations. Ask the auditor and key customers how long a period they will accept, since the standards do not set a generally accepted minimum. The output is a documented period start date and end date, plus a note explaining the choice. Choose a date that gives the team time to close the Type 1 gaps before the first control runs under the period.

  3. Lock the control set and assign owners

    Freeze the control matrix that will be tested for the period, including each control's description, frequency, owner and evidence source. Changes made after this point must be tracked as changes, because the system description and the tests will refer to the locked version. The output is an approved control matrix with a named owner for every control and a change log that starts on the period start date. Each owner should confirm in writing that they understand what evidence they must keep.

  4. Run controls and collect evidence through the period

    Control owners perform each control at the frequency it defines, such as access reviews, change approvals, vulnerability scans and onboarding checks, and file the evidence in a repository that the auditor can sample. Exceptions are logged when a control does not operate as designed, along with the corrective action and its closure date. The output is a complete evidence trail for the whole period, with no gaps for the controls that run periodically. Ask the auditor early how they will sample populations, because the sample comes from the full period.

  5. Monitor the controls and track deficiencies

    Before fieldwork, the team reviews whether each control is still operating, looks for missing evidence and tests a sample internally. Any deficiency found during the period is tracked to closure, since an unresolved exception can affect the opinion on operating effectiveness. The output is a monitoring log showing deficiencies, their root causes and the date each was closed, along with a list of controls that need additional evidence. Internal reviewers should be separate from the people who operate the controls wherever the team is large enough to allow it.

  6. Perform a readiness review

    Before the period ends, run a readiness review that checks the evidence against the control matrix, the system description and the auditor's request list. The review also confirms that management can produce the written representations the auditor will require for a Type 2 examination. The output is a readiness memo that lists any remaining gaps, their owners and the actions needed to close them before the CPA firm starts fieldwork. Some teams use an outside reviewer for this step, but the review does not replace the auditor's independent testing.

  7. Complete fieldwork and report issuance

    The CPA firm tests the controls against the evidence, samples the population for each control and documents the results. Management signs the representation letter, and the auditor then issues the Type 2 report, which describes the system, the tests performed and the results. Only the independent CPA firm issues the report, and it can do so only after the period has ended and testing is complete. The output is the signed Type 2 report and a list of any exceptions. Confirm the expected report timing with the auditor and customers before the period begins.

What a Type 2 costs and who gets paid

This table compares the main cost components of moving from a Type 1 to a Type 2, showing who is paid, whether each cost is one-time or recurring, and what drives it. Read the estimates in the cells as published third-party figures, not quotes, and use the last column to decide what to request in writing.

Cost componentWho is paid or who bears itOne-time or recurringWhat drives the cost
CPA firm audit feeIndependent CPA firm issuing the Type 2 reportRecurring each cycleNumber of criteria in scope, sample sizes, population size and the length of the observation period
Type 1 remediationInternal staff, and any implementation partner or tool vendor used to fix design gapsOne-timeHow many Type 1 findings or design gaps exist and how many controls must be redesigned
Implementation partner workOutside firm preparing systems, control design and evidence routinesOne-time or retainerScope agreed in writing, existing maturity, and whether evidence collection is automated
Internal staff timeYour own employees running reviews, access checks, change approvals and evidence requestsRecurring across the full periodNumber of controls performed manually and how many systems are in the boundary
Tooling and monitoringSoftware vendors, or your own infrastructure if the tools are self-hosted open sourceRecurring (licenses or hosting), plus setupNumber of systems monitored, retention needs and whether evidence is generated automatically
Published Type 1 and Type 2 estimatesCited by the Justice Department's October 2024 regulatory analysis (89 FR 86116), drawn from vendor publications: $5,000 to $25,000 for Type 1 and $30,000 to $100,000 for Type 2Estimates onlyUse as a sense check, not a budget. Confirm the actual fee with your auditor's engagement letter

What makes the Type 2 cost more or take longer

A Type 2 examination tests whether controls operated across a full period, so its cost and duration follow from how much the auditor must test and how much evidence the team must produce. The six drivers below set that workload, and each one can be planned before the period starts.

Criteria in scope

Every SOC 2 covers the common criteria CC1 to CC9. Adding availability, confidentiality, processing integrity or privacy adds criteria the auditor must test over the whole period, and privacy alone carries a large set of its own criteria. Before the Type 2 starts, confirm the category list in writing with the CPA firm and drop any category the customers do not require. Each extra category adds controls to test, evidence to collect and a larger system description to maintain.

Systems and locations in scope

Every production system, cloud account, region and office in scope multiplies the access reviews, configuration checks and change records the auditor samples. A single cloud account with one application is far cheaper to test than several accounts with shared services. Keep the boundary as narrow as customers allow, and document each in-scope asset in the system description and the asset inventory before the period opens.

Subservice organizations

Hosting providers, identity platforms and other vendors that handle customer data are subservice organizations. You can carve them out and rely on their own SOC reports, or include them and test their controls alongside yours. Carve-outs are cheaper but need a current report from each vendor, a bridge letter where the dates do not line up, and a clear list of complementary user entity controls. Ask the CPA firm which approach it expects before you sign.

Quality of Type 1 evidence

A Type 1 examination checks design at a single date, so gaps in evidence often surface only when the Type 2 begins. Missing access review records, undocumented change approvals and inconsistent ticket history each force the auditor to test more samples or report exceptions. Before the Type 2 period starts, run a mock sample against each control and fix any control whose evidence cannot be pulled quickly for a given date.

Control changes during the period

Each significant change to infrastructure, software, data handling or procedures during the period must be assessed under CC3.4 and recorded in the system description. Frequent changes mean more change tickets to sample, more places where a control can lapse, and more exceptions to explain. Freeze non-essential changes where possible, route every change through the same approval workflow, and log any control adjustment on the day it happens.

Length of the observation period

The AICPA does not set a minimum length for a SOC 2 Type 2 period, so the period you choose drives the sample sizes and the fieldwork time. Longer periods give the auditor more instances to test and more evidence to read, but they also give customers a more current report. Agree the period length with the CPA firm and your key customers before it starts, since changing it midway usually means restarting the testing window.

Who runs the controls, who prepares evidence and who reports

The organization owns its SOC 2 controls and the assertion behind them. During the observation period, management must actually run access reviews, change approvals, vulnerability follow-up, incident handling and vendor reviews, and it must be able to show that these happened on the dates the controls require. Management also signs the written representations the service auditor requests, so the people who sign them need to understand what the system description says.

  • Control ownership: Each control in the control matrix has a named owner who performs it and answers for exceptions.
  • Management's description: Leadership keeps the system description current for changes made during the period.
  • Representations: Management signs the representation letter and stands behind the statements in it.
  • Staff time: Engineers, HR and operations staff spend recurring time on reviews and tickets, which is an internal cost that outside help does not remove.
  • Retained records: Tickets, approvals and logs are kept in a form the auditor can sample.

Before the period starts, confirm which named person owns each control and whether that person has the access and time to perform it.

What must be in place before the Type 2 period starts

A Type 2 report tests whether controls operated across a period, so the controls, owners, records and descriptions must already exist when that period opens. The cards below cover what should be settled before day one and how to check each item against the Type 1 report.

Named owners for every control

Each control in the matrix needs one accountable person who runs it, reviews it and produces its evidence. Shared or vague ownership is a common reason controls lapse in the first weeks, and the service auditor will ask who performed each test. To check this, pick five controls at random and confirm the named owner can describe the task, the frequency and where the record sits.

Evidence collection schedule

Write down which evidence each control produces, how often it is collected, where it is stored and who collects it. A Type 2 auditor samples across the whole period, so an access review done in month one but missed in month four leaves a gap. To check this, confirm that every recurring control has a calendar entry and that the last cycle's evidence is filed where the schedule says it should be.

Recorded change log

Changes to infrastructure, software, configuration and procedures should be logged with the approval, the test and the deployment record. Change management is evaluated across the period, not at a single date, so the log must be complete from the first day. To check this, select a recent production change and trace it from request to approval, testing and deployment without relying on memory.

Control matrix matched to the Type 1 description

The control matrix should carry the same controls, criteria and system boundary that the Type 1 system description states. If controls were added or redesigned after the Type 1 date, the description and the matrix must say so before the Type 2 period starts. To check this, compare each control in the matrix with the Type 1 description and list any differences for management to resolve in writing.

Test of the first weeks of operation

Before the period opens, run each control at least once in its designed form and keep the output. A short dry run reveals missing approvers, broken alerts and unclear tickets while there is still time to fix them, and it shows whether the evidence the auditor will request actually exists. Ask the implementation team or auditor to review a sample of those first records before relying on the period.

Platform and tooling access for evidence

The systems that generate evidence, such as the identity provider, logging stack, ticketing tool and configuration scanner, must retain records for the full period and allow the auditor to view them. Retention settings and admin access to these tools are often overlooked until a sample is requested. To check this, confirm the retention period, export a sample record from each tool and verify that records cannot be edited after the fact.

Questions buyers ask about moving to Type 2

Does a SOC 2 Type 1 report count toward a Type 2?

No. A Type 1 report covers the system description and the suitability of control design as of one date, while a Type 2 report adds an opinion on whether controls operated effectively over a period. The Type 1 is useful evidence that the design is sound, but the Type 2 period has to be tested on its own. Its controls must already be running at the start of the period, and the service auditor samples evidence across the whole window. In practice, the Type 1 shows that the design works and the Type 2 shows that it kept working. Plan the Type 2 period to begin once the controls described in the Type 1 are operating consistently, not on the day the Type 1 is issued.

How long should the first SOC 2 Type 2 period be?

There is no generally accepted minimum for a SOC 2 Type 2 period, and management chooses the period with the auditor's agreement. The period needs to be long enough for the auditor to opine on operating effectiveness and to meet what customers need to see. Many organizations work toward a window that gives the auditor meaningful samples across recurring controls, such as access reviews and change approvals. Very short windows invite questions from customers and peer reviewers. The sibling topic on the SOC 2 Type 2 observation period covers how larger providers set their periods and why short windows draw scrutiny.

Do we need a bridge letter between the Type 1 and the Type 2?

A bridge letter is generally needed when a gap exists between the end of one report period and the date a customer needs assurance for. Where the Type 1 date and the Type 2 period leave time uncovered, customers may ask management for a written statement that no material changes occurred. Whether one is needed, and how far it must reach, depends on your contracts and on what your auditor and customers expect. Confirm the requirement with your CPA firm and the customers who asked for the report before the period closes.

What does the Type 2 work need from our internal team?

The team has to operate controls every day, not just prepare for the audit. Expect demands in four areas:

  • Owners for each control who perform it on schedule, such as quarterly access reviews and monthly vulnerability review.
  • Records that prove each control ran, including tickets, approvals, logs and sign-offs, kept in a form the auditor can sample.
  • A system description kept current when systems, vendors or teams change during the period.
  • A named contact who answers evidence requests quickly and explains exceptions.

The effort is mostly recurring, so the question to settle early is who owns each control after the first period ends.

Can we move from Type 1 to Type 2 without an implementation partner?

Yes, many organizations run the transition with in-house staff and their CPA firm, provided they have people with the time and skills to design evidence collection and keep controls operating. A partner is useful when controls are missing, when engineers lack time to build monitoring and evidence pipelines, or when the team needs help hardening systems before the period starts. DeployOpen prepares systems, controls and evidence for compliance assessments within a fixed scope agreed in writing, but it does not issue reports or opinions. Only the independent CPA firm issues the Type 2 report. Ask any partner to define which parts of the work it owns and which remain with your team.

What do published SOC 2 Type 2 cost estimates include?

Published estimates are rough guides, not quotes. The Justice Department's October 2024 regulatory analysis, drawing on vendor publications, cited $5,000 to $25,000 for a Type 1 audit and $30,000 to $100,000 for a Type 2 audit. Those figures generally reflect the auditor's fees, not the cost of building controls, tooling, staff time, remediation or a consultant. Type 2 costs also rise with the period length, the number of systems and criteria in scope, and the sample volume. Ask each quote to separate the auditor's fee, readiness support, tooling, and internal time, and confirm whether the first Type 2 includes the Type 1 work.

Why do Type 2 engagements take longer after a Type 1?

A Type 2 cannot be issued until the auditor has tested operating effectiveness across the full period, which means the controls must have run for that entire window. Timing therefore depends on when the period starts, how long it runs, and how quickly the auditor receives evidence after the period closes. Gaps found during the period, such as a missed access review, can lead to exceptions in the report. Build a calendar of recurring controls before the period starts and track evidence weekly. Confirm the expected report date with your auditor in the engagement letter.

What delays the Type 2 or inflates its cost

A Type 2 report tests whether controls operated across the whole period, so most delays and surprise costs trace back to gaps in the first weeks and months. The risks below are the ones that most often force an extended period, extra sampling or a re-run.

Starting the period too early

The observation period should begin only when the controls described in the Type 1 are operating as written. If access reviews, change approvals or logging are still being set up when the period opens, the auditor will test a period that already contains failures, and the first exceptions can push the report out. Before the start date, run each control once end to end and confirm that the owner can produce its evidence. Ask the auditor to review the control matrix against the live environment before you commit to dates.

Evidence that is missing or incomplete

Auditors test operating effectiveness by sampling evidence from across the period, so a control that ran but left no record counts as a failure. Typical gaps include access reviews without a dated sign-off, tickets closed without approval, and screenshots that cannot be tied to a date. Set a recurring evidence calendar with named owners, store records in a central location with fixed retention, and sample your own evidence monthly to catch gaps while they are still small.

Undocumented changes to systems

Infrastructure, software, data flows and vendors that change during the period must be reflected in the system description, and the change-management controls must show that each change was authorized and tested. Hotfixes applied directly to production and new subservice providers added without review are common sources of exceptions. Route every change through the same ticketing and approval path, including emergency changes, and log vendor additions in the risk register as they happen.

Relying on monitoring dashboards alone

Dashboards show current state, but a Type 2 needs records that each control ran, who reviewed the result and what was done about exceptions. A dashboard that shows no failing checks today does not prove that the access review happened in March or that a deficiency found in June was tracked to closure. Pair automated monitoring with dated review records and documented follow-up. Ask your auditor which dashboard exports they will accept as evidence before you build the process around them.

Choosing a period too short to convince customers

The AICPA does not set a minimum length for a Type 2 period, and the choice is management's, but a short window gives customers less assurance that controls hold up over time. Users and their auditors often ask why the period was chosen, and a very short one invites follow-up questions and sometimes a request for a bridge letter or a second report. Agree the period length with your main customers and the CPA firm before the period starts, and record the reason for the choice in the engagement documents.

How DeployOpen prepares systems and evidence for the Type 2

DeployOpen works on the platforms behind your SOC 2 scope, not on the report itself. We help you move from a Type 1 to a first Type 2 by preparing systems, controls and evidence that can operate and be documented across the observation period. Your auditor, a licensed CPA firm, tests the controls and issues the report.

How we scope

  • We agree the written scope for the Type 2 transition, including which systems, environments and criteria are in the examination boundary.
  • We map each Type 1 control to the period it must operate in, and flag controls that need a longer or clearer evidence trail before the window opens.
  • We confirm with you which tasks the auditor, your team and DeployOpen each own, so responsibilities are recorded before work starts.

How we build

  • We configure self-hosted open-source platforms in your own cloud accounts or data centers so that access, logging, change and backup controls generate evidence automatically.
  • We set up recurring control activities such as access reviews, vulnerability tracking and change approvals, with records kept in a form your auditor can sample.
  • We document system changes made during the period in the system description inputs, so the description matches what operated.

How we hand over

  • We deliver the control matrix, procedure documents and evidence index, organized by criterion so your auditor can request samples without rework.
  • We walk your team through the evidence each control produces and where it is stored, so operation continues after our engagement ends.
  • We prepare the materials your auditor will ask for, but the auditor decides what is tested, issues the report and signs the opinion.

How we support

  • Fixed-scope engagements have agreed deliverables and timelines, and we confirm any change to scope in writing before it is worked.
  • Ongoing support, upgrades and continuous testing are available as a retainer if your team needs help keeping controls operating between audits.
  • We can review evidence gaps found during the period and agree a remediation plan, while you retain ownership of the controls and their results.

Talk to our team.

Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.

  • 30-minute call: free, with no obligation.
  • NDA on request: we can sign before you share details.
  • Clear next steps: a scope and plan after the call.