SOC 2 Trust Services Criteria 2027: What the AICPA Exposure Draft Changes
The 2027 SOC 2 Trust Services Criteria are an AICPA exposure draft, not a final standard. Comments are due January 15, 2027, and if the draft is issued as final it applies to engagements beginning on or after December 31, 2027, with early adoption permitted. The draft cuts the common criteria from 33 to 20, gives vendor management its own category, and adds AI-related points of focus to 17 criteria. Nothing changes for a SOC 2 examination today, but organizations that plan audits for 2028 should know what is coming. This article covers the dates, the major changes to prepare for, a crosswalk from the 2017 criteria, and what to do before the text is final. Key Dates for the 2027 SOC 2 Trust Services Criteria Item Detail Comments due January 15, 2027 Effective date, if issued as final Engagements beginning on or after December 31, 2027 Early adoption Permitted Until then The 2017 criteria with the 2022 revised points of focus remain current The AICPA defines the effective date by when an engagement begins, not by when the report period ends, so a Type 2 period that spans December 31, 2027 is a question to put to your service auditor. The draft is dated October 27, 2026 and applies to SOC 2 and SOC 3 engagements, while SOC for Cybersecurity and SOC for Supply Chain stay on the 2017 criteria. The matching Description Criteria draft has not been released yet. What Happens Between Now and the Effective Date The comment period runs to January 15, 2027, and the AICPA’s Assurance Services Executive Committee considers the comments it receives. It may then revise the draft and issue a final version, and the draft does not say when that would happen. If it is issued as final, the December 31, 2027 date applies unless the final text changes it, and early adoption stays optional. Until then, every statement about what the criteria will require is provisional. Three questions are worth putting to your service auditor now: which version of the criteria applies to your next engagement, whether the firm will offer early adoption, and how the engagement start date works for a Type 2 period that spans December 31, 2027. The answers depend on the firm’s own engagement timing, so it helps to have them before a 2028 audit is scheduled. Major Changes to Prepare For Fewer Criteria in Eight Categories The common criteria, which apply to every SOC 2 examination, go from 33 criteria in nine series to 20 in eight: control environment, information and communication, risk assessment, monitoring activities, logical and physical asset protection, system operations, system development and change management, and vendor management. Asset protection has the most criteria. The AICPA gives two aims: to reduce complexity by combining similar criteria, removing unnecessary ones, and rewriting the language so it is uniform, and to modernize the criteria for emerging technologies such as AI. The drop from 33 to 20 applies to the common criteria only. The additional criteria change less: availability goes from three criteria to four, confidentiality from two to three, and processing integrity (five) and privacy (eighteen) keep their counts. These counts are Elevate’s reading of the draft against the 2017 criteria, because the draft does not publish one. Criteria remain outcome statements, and the points of focus beneath them are not a checklist. No point of focus requires a specific control, and an examination does not require assessing whether each one is addressed. Vendor Management Becomes a Category Vendor and business partner risk was criterion CC9.2 in 2017, and the draft makes it a category of its own, CC8. Its points of focus describe a full vendor program: specific requirements for each engagement covering scope, roles, compliance, and service levels; evaluation of the vulnerabilities that vendor relationships create, including third-party access and network connections; and a vendor inventory that is tiered and assessed periodically, including the vendors’ own vendors. They also cover accountability, communication and exception handling, performance reviews, subservice organizations, termination procedures, and confidentiality and privacy commitments from vendors. One point of focus is new in emphasis. External components, which may include hardware, software, AI models, APIs, and plugins, are evaluated for security and reliability before use and after updates. For a service organization that builds on third-party AI, that is where the vendor program meets the AI points of focus. Elevate’s guide to vendor risk assessment covers the process. AI Points of Focus in 17 Criteria The draft adds AI-related points of focus to 17 criteria, and 12 of them are common criteria, so they bear on every SOC 2 examination. The other five sit in the availability, processing integrity, and privacy series, which apply only when those categories are in scope. The points of focus cover AI-specific risks such as training data manipulation, adversarial inputs, and prompt injection, access reviews that include AI and other technology accounts, controls against unsanctioned AI tools and unauthorized AI software, monitoring AI components for drift and anomalous outputs, evaluating changes to training data, informing users when outputs are AI-generated, and AI components supplied by vendors. Several are conditional. The training data points apply when the entity has the ability to train an AI model, so an organization that only calls a third-party model sees a lighter version, with more weight on vendor management. These points of focus guide how an auditor evaluates a system that uses AI and do not create a mandatory list of controls. An auditor working from them might reasonably ask where the AI components are, who approved changes to their data, how drift is detected, and which AI tools employees may use. Business Disruption Planning Moves Under Availability The 2017 criteria covered business disruption risk in the common criteria, as CC9.1. The draft has no common criterion for it, and the related points of focus, on planning for the mitigation of business disruption risks and on testing business continuity and crisis management plans, appear in the availability criteria. A Security-only examination
SOC 2 vs FedRAMP: What SOC 2 Type 2 Actually Gets You
SOC 2 vs FedRAMP is usually the wrong comparison to be making, because the two are not competing answers to the same question. SOC 2 Type 2 tells a commercial customer that an auditor tested a company’s controls against a set of trust principles over a period of months. FedRAMP tells the federal government that a cloud service meets a specific, much larger baseline of NIST 800-53 controls, verified through a formal assessment process the government itself recognizes. A company holding SOC 2 Type 2 and eyeing federal contracts needs to know exactly where that investment counts toward FedRAMP and where it does not, because the honest answer is narrower than most sales conversations imply and more useful than starting from zero. Why “SOC 2 vs FedRAMP” Is the Wrong Frame SOC 2’s Trust Services Criteria SOC 2 evaluates an organization against the Trust Services Criteria: security, availability, processing integrity, confidentiality, and privacy, with security as the only mandatory category and the other four selected based on what the organization’s service actually does. A Type 2 report goes further than a Type 1 by testing whether those controls operated effectively over an observation period, typically six to twelve months, rather than confirming they existed on a single date. The report itself is not a certification in the way FedRAMP uses the term. It is an attestation, produced by a licensed CPA firm, that describes the controls in place and the auditor’s findings. Different companies scope different criteria, use different control language, and can legitimately hold very different SOC 2 reports while both being described as SOC 2 Type 2 compliant. FedRAMP’s NIST 800-53 Baseline FedRAMP starts from a fixed, government-defined control catalog rather than a customizable set of criteria. Under the Consolidated Rules for 2026, a cloud service is certified against one of four Certification Classes, B through D under Rev5 plus the temporary Class A, with control counts ranging from roughly 125 for Class B to over 400 for Class D. The controls come from NIST SP 800-53, adapted specifically for cloud service models, and the assessment is conducted by a FedRAMP Recognized Assessor working from a published methodology rather than a firm’s own audit approach. The scope difference alone makes the two frameworks structurally different. SOC 2 lets an organization choose which trust principles to include. FedRAMP does not offer that choice. A cloud service pursuing FedRAMP implements the full control set for its class, whether or not every control feels relevant to the service’s specific risk profile. Why the Comparison Is Not Apples to Apples The reason “SOC 2 vs FedRAMP” invites a bad question is that SOC 2 was built to answer “can we trust this vendor with our data” for a commercial buyer making its own risk decision, while FedRAMP was built to answer “does this cloud service meet a fixed government baseline” for an agency that is not permitted to make that judgment case by case. One is a flexible attestation aimed at commercial trust. The other is a standardized certification aimed at regulatory compliance. A company with an excellent SOC 2 Type 2 report has demonstrated real security maturity, and that maturity does not automatically translate into meeting a fixed federal control catalog it was never measured against. Where SOC 2 Type 2 Actually Fits Inside FedRAMP The One Place It Counts: The Class A Prerequisite There is exactly one place in the current FedRAMP structure where SOC 2 Type 2 does something concrete: it is one of the qualifying prior audits for FedRAMP Class A authorization. Class A requires a prior audit from an approved alternative framework, specifically FedRAMP Rev5 work including Legacy FedRAMP Ready, a SOC 2 Type 2, or GovRAMP at any impact level. Stacking unrelated audits, such as combining an ISO 27001 certificate with a HIPAA assessment, does not satisfy this requirement. SOC 2 Type 2 is one of three named doors into Class A, not a general-purpose credential that opens every door in FedRAMP. Class A itself is a temporary, low-risk pilot authorization. It is not a certification level a provider holds indefinitely, and it carries no reciprocity toward Class B, C, or D. The prerequisite value of SOC 2 Type 2 is real, but it buys entry into a two-year bridge, not a shortcut through the full certification. What SOC 2 Type 2 Does Not Buy at Class B, C, or D Outside the Class A prerequisite, SOC 2 Type 2 has no formal role in a FedRAMP certification package. A provider targeting Class B, C, or D directly does not submit a SOC 2 report in place of the required control documentation, and an assessor evaluating that provider does not treat SOC 2 evidence as satisfying a FedRAMP control on its own. The two assessments run on different criteria, different scoping rules, and different evidence standards, which means a control that passed under SOC 2’s Trust Services Criteria still has to be independently evidenced against the specific NIST 800-53 control language FedRAMP requires. This is the point most often misunderstood in a sales conversation, and it is worth stating plainly rather than softening: an organization cannot present its SOC 2 Type 2 report to a FedRAMP assessor and expect credit against the Class C control set. The report is useful background. It is not substitute evidence. Where the Controls Actually Overlap What Carries Over in Substance The practical value of an existing SOC 2 Type 2 program shows up in the underlying operational maturity rather than in any formal control mapping. An organization that has run SOC 2 Type 2 for a full observation period has typically already built access review cycles, change management processes, incident response procedures, vendor risk practices, and logging and monitoring capability. Those same operational disciplines are exactly what a FedRAMP control implementation has to demonstrate, even though the specific control language, evidence format, and testing methodology differ. Area What SOC 2 Type 2 typically demonstrates What FedRAMP additionally requires Access
SOC 2 Type 2 Cost: The Full Audit and Readiness Budget
SOC 2 Type 2 cost is not a single number but a budget spread across several components, and the organizations that are surprised by it are usually the ones that budgeted only for the audit fee and forgot everything around it. The audit itself is one line; the readiness work to pass it, the tooling to sustain it, and the internal time it consumes are the others, and together they often dwarf the fee. This guide breaks the cost into its real components and explains what drives each, so the budget you build reflects the whole effort rather than a fraction of it. The reason a component view matters more than a headline figure is that the total varies enormously with scope and starting maturity, so any single number quoted out of context is misleading. A startup with one product and a narrow scope faces a very different budget from a mid-market firm with several systems and four criteria in scope. Understanding the drivers lets you estimate your own budget honestly, and it lets you see which levers actually reduce it. What Goes Into SOC 2 Type 2 Cost A realistic budget covers four components, not one. The audit fee is what a licensed CPA firm charges to perform the examination and issue the report. The readiness work is everything done beforehand to be ready to pass, from a gap analysis through remediation. The tooling is the software used to collect evidence and monitor controls. And the internal time is the staff effort to prepare for and then sustain the program. The table below sets them out with their main drivers. Cost component What it covers Main driver Audit fee The CPA firm’s examination and report Scope and observation period Readiness work Gap analysis and remediation before the audit Starting maturity Tooling Evidence collection and continuous monitoring Environment size and complexity Internal time Staff effort to prepare and maintain the program Program maturity The component that organizations most often underestimate is the readiness work, because it is invisible until a gap analysis reveals how much needs building. For an organization with informal controls, the readiness effort can exceed the audit fee several times over, while a mature organization may need very little. That variance is exactly why the starting point matters more than any published price, and why the honest way to budget is by component rather than by a single figure. What Drives the Audit Fee The audit fee, charged by the CPA firm rather than an advisor, is driven mainly by scope and the nature of a Type 2 examination. Scope means how many of the Trust Services Criteria are included: a Security-only report is narrower and less expensive to examine than one adding Availability, Confidentiality, and others. The size and complexity of the environment matter too, since more systems and locations mean more for the auditor to test. A Type 2 examination also costs more than a Type 1 for a structural reason: it assesses whether controls operated effectively across a period rather than existed at a point in time, which is more work to examine. The length of that observation period and the volume of evidence to review both feed the fee. None of these are levers an organization pulls at audit time; they are set earlier, when scope is chosen and the environment is defined, which is why scoping deliberately is the first cost decision. What Drives the Readiness Cost The readiness cost is driven above all by starting maturity, which is the single biggest variable in the whole budget. An organization whose controls already exist, operate consistently, and are evidenced needs little remediation, while one starting from informal or undocumented controls needs substantial work to write policies, implement controls, and set up evidence collection. The gap between those two starting points is where most of the budget variance lives. This is why a SOC 2 gap analysis is the most cost-relevant early step: it converts an unknown readiness cost into a specific, priced list of work, so the budget stops being a guess. Whether the remediation is done internally or through a SOC 2 readiness assessment with an advisor is another driver, trading internal time against external fees. Either way, the readiness cost is the component most within an organization’s control, because it responds directly to how mature the program was before the effort began. Tools and Ongoing Cost Tooling is the third component, covering the software used to collect evidence and monitor controls continuously, and its cost scales with the size and complexity of the environment. More important than its size, though, is a budgeting point organizations often miss: SOC 2 Type 2 is not a one-time expense. Because the report covers a period and customers expect a current one, the examination recurs, typically annually, and so do the readiness maintenance and tooling that support it. Budgeting for SOC 2 as a project with an end date, rather than an ongoing program, is a common and costly mistake. The first year is usually the most expensive because it includes the initial readiness build, but the recurring annual cost of the audit, the tooling, and the maintenance continues indefinitely. A budget that accounts only for year one understates the true commitment, so the realistic view treats the cost as an annual line rather than a one-time outlay. How to Build a Realistic SOC 2 Type 2 Budget Building a realistic budget follows the components in order. Start by setting scope, which a SOC 2 compliance checklist can help map, since it drives both the audit fee and much of the readiness work, and resist the urge to include criteria your customers do not require. Next, assess starting maturity honestly, ideally through a gap analysis, because that is what turns the largest and most variable component into a known quantity. Then obtain a scoped quote from a CPA firm for the audit fee and an estimate for the readiness work, and finally add the
SOC 2 Gap Analysis: What It Finds, Fixes, and Costs
A SOC 2 gap analysis compares your current controls against what SOC 2 requires and identifies exactly where you fall short before an auditor does, which is the difference between fixing gaps on your own schedule and discovering them during a live examination. It is the diagnostic step that turns a vague sense of unreadiness into a specific, prioritized list of what to build, and it is what most organizations should do first when pursuing SOC 2. This guide explains what the analysis finds, what remediation involves, what drives its cost, and how doing it early shortens the path to a clean Type 2 report. The reason to run the analysis before the audit rather than treating the audit as the discovery mechanism is timing. A SOC 2 examination, especially a Type 2, judges whether your controls operated over a period of time, so gaps found during the audit cannot simply be patched; they can require restarting the clock on the observation window. Finding those gaps in advance, while there is still time to fix them and let the fixes run, is the entire value of the exercise. What a SOC 2 Gap Analysis Is The analysis is a structured comparison of your current state against the requirements of the Trust Services Criteria that apply to your report. It examines your existing policies, controls, and evidence, determines where they meet the criteria and where they do not, and produces a documented list of gaps with a plan to close them. It is a readiness exercise, not the audit itself, so it is performed to prepare you rather than to judge you. It helps to distinguish the analysis from the two things it sits between. It is more guided and diagnostic than working through a self-serve SOC 2 compliance checklist on your own, and it is narrower and more concrete than the broader question of choosing a readiness service, covered in the guide to a SOC 2 readiness assessment. The gap analysis is the specific diagnostic that tells you, control by control, what stands between you and a clean report. What a SOC 2 Gap Analysis Finds What the analysis finds is remarkably consistent across organizations, because the same gaps recur. The table below maps the common gap areas to what they typically look like and how they are remediated. Gap area Typical finding Remediation Policies Missing or outdated policies that do not match practice Write or update policies to reflect actual controls Controls Controls not implemented or applied inconsistently Implement and operationalize the missing controls Evidence No proof that controls actually operate Set up systematic evidence collection Access Access reviews not performed or done ad hoc Establish periodic, documented access reviews Ownership Controls with no accountable owner Assign owners responsible for running and evidencing each control The pattern across these findings is that most organizations have more of a documentation and evidence problem than a security one; the controls often exist informally but are not written down, applied consistently, or evidenced. That is good news, because it means the path to readiness is usually about formalizing and evidencing what you already do rather than building security from scratch, which is a faster and cheaper problem to solve. What Remediation Looks Like Remediation turns the gap list into an ordered plan of work, and it generally spans a few kinds of effort. Documentation work formalizes policies and procedures so they match what you actually do. Control work implements or tightens the safeguards that were missing or inconsistent. Evidence work sets up the systematic collection of proof that controls operate, which is essential for a Type 2 report. And organizational work assigns owners so each control has someone accountable for running it and retaining its evidence. The sequencing matters as much as the tasks. Because a Type 2 report requires controls to have operated over a period, the remediation that must happen first is whatever needs time to accumulate evidence, since starting it late pushes back the whole timeline. A good gap analysis therefore prioritizes not just by severity but by lead time, front-loading the fixes whose evidence takes longest to build so the observation window can start sooner. What Drives the Cost The cost of the analysis follows its scope rather than a fixed rate, so the useful way to understand it is through the drivers. The main ones are how many of the Trust Services Criteria are in scope, since a Security-only analysis is narrower than one covering Availability, Confidentiality, and more; the size and complexity of the environment being assessed; and the current maturity of the organization, because a more mature starting point means a shorter analysis. The report type you are targeting matters too, as preparing for a Type 2 involves more consideration of evidence over time than a Type 1. Because these variables differ so widely between organizations, a scoped estimate is more reliable than any published figure, and the value of the analysis is best weighed against its return. A gap analysis that costs a fraction of the audit and prevents a failed or delayed examination pays for itself, since the far larger cost is a certification effort that stalls because gaps surfaced too late to fix. Framing the cost against that risk, rather than in isolation, is what shows why the analysis is worth doing. How It Shortens the Path to a Clean Type 2 Report The payoff of the analysis is a shorter, more predictable path to a clean Type 2 report, and the mechanism is timing. By finding gaps before the observation period begins, the analysis lets you remediate and then start the clock with controls already operating, so that when the auditor examines the period, the controls have been running cleanly throughout. Without the analysis, gaps tend to surface during the examination, when the only remedies are a qualified report or restarting the observation window, both of which cost months. A clean Type 2 report is what customers actually want, since
SOC 2 Compliance Checklist: Every Trust Services Criterion Covered
A SOC 2 compliance checklist is most useful when it follows the structure SOC 2 itself uses, which is the Trust Services Criteria, because that is exactly how an auditor evaluates you. SOC 2 is not a fixed list of controls but a framework built on five criteria, only one of which is always required, and preparing against the right ones with the right evidence is what turns a daunting audit into a manageable process. This checklist maps SOC 2 to the Trust Services Criteria, shows the evidence auditors sample for each, and flags the gaps that most often delay a report. The reason to organize preparation this way is that a SOC 2 report is issued by a licensed CPA firm that examines your controls against these criteria, so aligning your readiness to them is aligning it to how you will actually be judged. A checklist built any other way risks preparing for the wrong thing, while one mapped to the criteria prepares you for the examination as it will really happen. The Trust Services Criteria SOC 2 is built on five Trust Services Criteria, and the first decision in any SOC 2 effort is which of them are in scope. Security is always required and forms the backbone of every SOC 2 report, while the other four are included only if they are relevant to the service you provide and the commitments you make to customers. Trust Services Criterion What it covers Required? Security (Common Criteria) Protection of systems and data against unauthorized access Always required Availability Systems are available for operation and use as committed Optional Processing Integrity Processing is complete, valid, accurate, and timely Optional Confidentiality Information designated confidential is protected Optional Privacy Personal information is handled per stated commitments Optional The table makes the scoping decision concrete: every SOC 2 report covers Security, and you add the other criteria based on what matters to your customers. A cloud infrastructure provider often adds Availability, a payment processor may add Processing Integrity, and a service handling personal data adds Privacy. Choosing the criteria deliberately, rather than including all five by default, keeps the audit scoped to what your customers actually care about and controls the effort involved. The SOC 2 Compliance Checklist by Criterion With scope set, the checklist works through each in-scope criterion, confirming both that the controls exist and that you can evidence them, because an auditor tests both. Security carries the most weight, since it is required and the broadest. Security, the Common Criteria Security, expressed through the Common Criteria, covers the foundational controls every SOC 2 report examines: access controls and authentication, network and system protection, change management, risk assessment, monitoring, and incident response, along with the governance and organizational controls that sit above them. This is where most of the preparation effort goes, because the Common Criteria are comprehensive and apply regardless of which optional criteria you add. The checklist for Security is effectively a checklist for a sound security program, evidenced. Availability, Processing Integrity, Confidentiality, and Privacy The optional criteria each add a focused set of requirements on top of Security. Availability adds controls around capacity, monitoring, backup, and recovery that show systems meet their availability commitments. Processing Integrity adds controls ensuring that system processing is complete, accurate, and authorized. Confidentiality adds controls for identifying and protecting confidential information through its lifecycle, and Privacy adds a substantial set of controls governing how personal information is collected, used, retained, and disposed of in line with stated commitments. Each in-scope optional criterion extends the checklist, which is why scoping them to genuine relevance matters. Evidence Auditors Sample A SOC 2 examination is an evidence exercise, and knowing what auditors sample lets you prepare the right proof rather than scrambling during fieldwork. Auditors typically request policies and procedures that define your controls, then sample evidence that those controls actually operated: access reviews, system configurations, monitoring and alerting records, change tickets, onboarding and offboarding records, vendor reviews, and incident records among them. The recurring theme is that a control you cannot evidence is treated as a control you do not have, so the evidence trail is as important as the control itself. The depth of evidence depends on the report type. For a Type II report, which is what most customers now expect, the auditor needs evidence that each control operated consistently across the entire audit period, not just that it existed at a point in time, so gaps in the evidence during the period become findings. Building the habit of retaining this evidence continuously, rather than assembling it before the audit, is what separates a smooth examination from a painful one. Type I vs Type II SOC 2 comes in two report types, and knowing which you need shapes the checklist. A Type I report assesses whether your controls are suitably designed at a single point in time, which is faster to achieve and useful as a first step or an interim signal. A Type II report assesses whether those controls operated effectively over a defined period, commonly several months to a year, and it is the report most customers and prospects actually want because it demonstrates sustained operation rather than a snapshot. The practical implication is that Type II requires your controls to be not just designed but running and evidenced throughout the audit period, which is why organizations often pursue a Type I first and a Type II once controls have operated long enough to demonstrate, a path the guide to SOC 2 for startups covers for earlier-stage companies. Deciding the target report type early is important, because it determines how far in advance you need your controls operating and your evidence accumulating. Gaps That Delay SOC 2 Reports The gaps that delay a SOC 2 report are consistent, and most of them are avoidable with the checklist in hand. The most common is missing or incomplete evidence that controls operated across the full period, which is fatal for a Type