According to Verizon’s 2026 Data Breach Investigations Report (DBIR), third parties were involved in 48% of breaches, while exploitation of vulnerabilities became the leading initial access vector, accounting for 31% of breaches.
SOC 2 has become an important assurance framework for many software and service providers that handle customer data. Although it is not a legal requirement by itself, customers and procurement teams may require a SOC 2 report as part of vendor due diligence or contractual requirements.
But at first sight, the framework can seem complicated, with phrases like "attestation," "common criteria," and "trust services criteria" being used without much clarification.
This guide simplifies the SOC 2 criteria. You will discover the true scope of the framework, the operation of the five Trust Services Criteria, the distinction between Type 1 and Type 2 audits, the paperwork required, and the mistakes that can lead to audit delays, control exceptions, or a modified auditor’s opinion.
We will also discuss readiness evaluations, scoping, and a useful checklist that you can begin utilizing right now. Let's get started.
Key Takeaways
- The five Trust Services Criteria provide the foundation of SOC 2 standards. However, only security is required for each audit.
- Every SOC 2 report must include the security criterion, often known as the common criteria.
- A SOC 2 Type 1 report evaluates the suitability of the design of controls as of a specified date, whereas a Type 2 report also evaluates their operating effectiveness over a specified period.
- You can avoid surprises during the actual inspection by identifying shortcomings early with the aid of a readiness assessment conducted prior to the formal audit.
- Start early because gathering documentation and evidence usually takes up more audit time than the controls themselves.
- Preparation time varies considerably depending on the organization’s scope, existing controls, remediation needs, and the type of SOC 2 report being pursued..
- SOC 2 is not a regulatory obligation by itself, but some customers and contracts require a current SOC 2 report as part of vendor security assurance..
What are SOC 2 requirements?
SOC 2 is an AICPA attestation framework used to evaluate controls at service organizations against applicable Trust Services Criteria related to security, availability, processing integrity, confidentiality, and privacy.
A SOC 2 report is an attestation report issued by an independent licensed CPA firm after examining the service organization’s system and applicable controls. As a result, you can't just pass or fail a checklist; instead, the auditor considers the data and makes an expert assessment regarding the appropriateness of your controls and, in the case of a Type 2 report, their long-term effectiveness.
Meeting SOC 2 requirements entails addressing the AICPA's Trust Services Criteria, developing policies around them, and demonstrating through evidence that your team actually adheres to those policies on a daily basis.
Two businesses can receive unmodified SOC 2 opinions while using substantially different controls, provided their controls appropriately address the applicable criteria. This flexibility, once understood, is a strength because it allows a five-person startup and a thousand-person organization to accomplish compliance with controls tailored to their respective risk and complexity.
Who Examines the Report?
Knowing who actually reads a SOC 2 report after you have one is also beneficial. To determine whether your company is secure to operate with, procurement officers, enterprise security teams, and occasionally cyber insurance underwriters examine the report. Many businesses also pursue a SOC 3 report for wider distribution because the report itself is extensive and not intended for general marketing usage due to the technical audience.
The five Trust Services Criteria explained
The Trust Services Criteria are organized into five categories: security, availability, processing integrity, confidentiality, and privacy. Security is included in every SOC 2 examination, while the other four categories are included when relevant to the engagement’s scope. Together, they specify the risk categories that your controls need to cover, and each one has specific requirements for how you should create, record, and test controls. A closer look at what each criterion truly requires of your company is provided below.
1. Security requirements under SOC 2
Every SOC 2 report starts with security since it guards against both physical and logical unauthorized access to systems. Firewalls, multi-factor authentication, endpoint monitoring, and role-based access controls that restrict access to sensitive systems are examples of how this is implemented in reality.
Additionally, auditors look for proof that you identify security occurrences and take prompt action, as opposed to depending solely on paper rules.
This criterion typically results in the highest volume of proof requests because security affects almost every tier of your technological stack. Access review logs, vulnerability scan reports, penetration test summaries, and documentation demonstrating that fired personnel quickly lost system access are all likely to be requested by auditors. Strong security measures also show clients that your company responds to issues proactively rather than reactively.
2. Availability requirements for SOC 2
Availability confirms that your systems stay operational and meet the uptime commitments you make to customers. This criterion covers capacity planning, environmental safeguards like backup power, and disaster recovery testing. Because customers often build their own service-level agreements around your uptime, auditors expect to see documented incident logs and recovery drills, not just a stated policy.
Organizations that include availability in their SOC 2 scope typically maintain a business continuity plan, run periodic failover tests, and track system performance against defined thresholds. If your service experiences downtime, auditors will also want to see how quickly your team identified the issue and restored service, since response time matters as much as the incident itself.
3. Processing integrity requirements
Processing integrity ensures that data processing is completed, accurate, timely, and properly authorized from start to finish. Companies that handle client transactions, billing, or reporting typically incorporate this requirement, as customers require assurance that outputs match inputs without silent errors. Before data travels downstream, controls are frequently included, such as reconciliation checks, input validation, and quality assurance testing.
Fintech platforms, e-commerce processors, and any company whose software does computations that impact a customer's financial records should pay particular attention to this criterion. Auditors will usually sample transactions and follow them through your system to verify that processing behaved as anticipated, including how problems are identified and fixed.
4. Confidentiality requirements
Confidentiality safeguards information that your company or clients have classified as sensitive, such as business plans, source code, or private data. Unlike privacy, confidentiality encompasses any material that is subject to a contractual or corporate obligation to remain private. Common measures that meet this need include restricted access lists, data classification procedures, and encryption.
Many B2B SaaS companies expand their SOC 2 scope to include confidentiality because their clients keep secret business data on the platform. Customers are reassured that their competitive information is protected when strong confidentiality mechanisms are demonstrated, such as encryption in transit and at rest, along with explicit data-handling agreements.
5. Privacy requirements under SOC 2
Privacy governs how personal information is gathered, utilized, maintained, and disposed of in accordance with the privacy notice that you provide to customers. This criterion is based on the AICPA's widely accepted privacy guidelines, which apply most directly to organizations that handle personally identifiable information, such as names, addresses, or health information. Consent methods, data subject access protocols, and retention schedules are common anchors for this section of the audit.
Organizations that include privacy in scope may also need to coordinate their SOC 2 controls with applicable privacy laws and contractual requirements. Because privacy obligations vary by jurisdiction, this work often requires coordination among legal, product, security, and privacy teams.
A single control can frequently meet more than one category at once since these five trust services criteria overlap in certain areas. For example, an access-control policy may simultaneously enable confidentiality and security, which minimizes redundant effort during the audit.
Common criteria: the mandatory foundation
Security is frequently referred to as the "common criteria" because it is applicable to all SOC 2 reports, independent of the other categories you include. Auditors also refer to it by its acronym, CC, and divide it into nine subcategories ranging from governance and risk assessment to monitoring operations.
Security is the only Trust Services category that every SOC 2 examination must include. Availability, processing integrity, confidentiality, and privacy are optional and may be added when relevant to the organization’s service commitments, system requirements, or users’ needs.
The common criteria are organized into nine groups, CC1 through CC9, covering areas such as control environment, communication, risk assessment, access controls, system operations, change management, and risk mitigation. The accompanying points of focus provide guidance for understanding and evaluating the criteria rather than functioning as a separate mandatory checklist.
Almost every aspect of the organization is impacted by the common criteria, including vendor management, staff training, and incident response. Most organizations spend the majority of their preparation time in this section, which typically generates the biggest share of evidence requests during a SOC 2 audit.
Building strong common criteria controls early also makes it easier to add optional criteria later since many of the underlying processes, such as access reviews and incident response, already support the additional categories.
Optional criteria and when to add them
You only need to add availability, processing integrity, confidentiality, and privacy if they are important to your service obligations. A payments company, for example, would most likely prioritize processing integrity, but a company that handles customer health data would prioritize privacy.
Unnecessary criteria offer little value and raise the audit's scope, cost, and schedule. Thus, before choosing further criteria, find out what your customers' contracts and security questionnaires genuinely call for. Then, select just those that meet those requirements. Scoping decisions are much simpler to defend internally when recent sales cycles, security questionnaires, and lost-deal comments are examined.
Some organizations broaden their scope in subsequent audit cycles as their customer base grows or they enter new markets. You may control costs while meeting the market need for more confidence by using this phased method.
When a firm signs its first large enterprise customer with stringent uptime needs, for instance, it may launch its first SOC 2 report with only security in scope. Later, if it enters a market or serves customers with additional privacy or confidentiality requirements, it may add the relevant Privacy or Confidentiality criteria.
SOC 2 Type 1 vs. Type 2 requirements
There are two formats for SOC 2 reports, and the distinction affects how purchasers understand them. A SOC 2 Type 1 report evaluates the suitability of the design of controls as of a specified date. A Type 2 report covers a specified period and additionally evaluates whether those controls operated effectively throughout that period.
Many organizations begin with a Type 1 report because it takes less time to complete. Once they have sufficient operating experience to demonstrate consistency, they transition to a Type 2 report.
However, Type 2 reports are typically preferred by enterprise customers because they show consistent practice as opposed to a single picture. Actually, before completing a larger contract, some procurement teams will accept a Type 1 report as a first step but need a Type 2 report.
Early comprehension of SOC 2 Type 1 vs. Type 2 needs enables you to set reasonable expectations with leadership and sales. The AICPA does not prescribe a minimum Type 2 examination period. However, the service auditor must determine whether the selected period provides sufficient appropriate evidence to support an opinion on operating effectiveness. Very short periods may therefore be unsuitable, particularly when important controls operate monthly, quarterly, or annually.
Documentation and evidence you must collect
Every SOC 2 audit revolves around documentation because auditors require evidence, not assurances. Depending on the controls and criteria in scope, documentation may include policies covering areas such as access control, incident response, change management, vendor risk, and data retention..
Operational proof, such as access logs, ticket records, training completion reports, vulnerability scan results, and backup test logs, is also necessary in addition to policy. Every piece of evidence should correspond to a particular control and, preferably, to the AICPA points of focus that underpin that control.
For a Type 2 audit, you will need this proof spaced out over the whole observation period, rather than just near the conclusion, because inspectors sample dates throughout the window to validate your controls stood up over time.
Weak or inconsistent documentation is one of the most common reasons audits stall. Instead of scrambling to reconstruct records after the fact, build a habit of capturing evidence continuously so it is ready whenever the auditor requests it.
Many teams find it useful to maintain a simple evidence log or shared repository organized by control, which turns evidence collection from a last-minute scramble into routine housekeeping.
Readiness assessment and scoping
An organized evaluation that takes place prior to the official SOC 2 audit is called a readiness assessment. In this step, an internal team or outside advisor identifies any gaps in your controls by comparing them to the standards you intend to follow.
This procedure usually results in a prioritized repair list, so before the auditor shows up, you are aware precisely which controls require attention.
Readiness and scoping go hand in hand. Determining which systems, teams, and vendors are included in the audit boundaries is crucial since an overly broad scope can result in needless expenses, while an overly restricted scope may exclude systems that your clients truly care about.
Scoping choices also have an impact on the number of workers and infrastructure your auditor must examine, which has a direct impact on timeliness and cost. It is dangerous to skip this step since any holes found during the audit could cause your report to be delayed by several months.
On the other hand, a comprehensive readiness assessment allows you to quietly address problems long before an outside auditor formally records them. Many organizations use the readiness assessment as a dress rehearsal, complete with fictitious evidence demands, to ensure that their team is prepared for the actual audit.
Practical Tips / Checklist
- Developing a plan is the next step after you comprehend the requirements. Use the checklist below to move from theory to an audit-ready SOC 2 program.
- Conduct a gap assessment first. Compare your current controls to the criteria you intend to pursue so you know exactly where the gaps are before the clock starts.
- Scope only applicable criteria. Limit your audit to the Trust Services Criteria that your clients genuinely need, as a more comprehensive scope may increase expenses without improving value.
- Connect controls to focal points. It is easier to demonstrate to auditors how your control meets the criterion if you link each control to the pertinent AICPA points of focus.
- Automate the gathering of evidence. Set up automated logging and reporting wherever possible so that evidence accumulates rather than relying on manual screenshots each quarter.
- Select your auditor early. Engage an independent licensed CPA firm early enough to accommodate your target examination and reporting dates.
- Choose an appropriate Type 2 examination period. The period should be long enough for the auditor to obtain sufficient evidence of operating effectiveness, taking into account how frequently the controls operate.
Common Mistakes To Avoid
- Even well-intentioned teams run into the same problems when seeking SOC 2 criteria. Keep an eye out for these errors to prevent your timeline from being derailed.
- Treating SOC 2 as a rigid checklist. The framework encourages well-designed rules that fit your business instead of rewarding a copy-and-paste list taken from another organization.
- Over-scoping unneeded criteria. Adding categories that your clients never requested increases your timeline and budget without providing a clear return.
- Skipping the readiness assessment. Gaps are frequently discovered at the worst possible time when a formal audit is conducted without a dry run.
- Weak documentation and evidence. Controls that exist only in someone's head, rather than in writing, rarely survive auditor scrutiny.
- Confusing certification with attestation. Since SOC 2 is an auditor's opinion rather than a pass-or-fail certificate, language that claims to be "SOC 2 certified" may mislead consumers and perhaps attract legal attention.
Final Thoughts
Planning is necessary to meet SOC 2 criteria, but once you grasp the framework, it need not be too difficult. Begin with the Security category and common criteria, then add just the Trust Services criterion that your clients truly require, and establish documenting practices early on so that evidence collection never becomes a last-minute panic. The deficiencies you detect during the readiness assessment are much less expensive to close than those your auditor discovers later, so approach it as a true dry run rather than a formality.
The appropriate route to a SOC 2 report will vary from firm to company because each organization's processes and risk profile are unique. FortNexShield takes a vendor-neutral approach and connects businesses with vetted providers who specialize in SOC 2 readiness, scoping, and audit support, so you can find a partner suited to your specific environment rather than a one-size-fits-all package. Schedule a consultation right now to discuss your SOC 2 obligations.
What are the five criteria for SOC 2?
The five Trust Services Criteria are privacy, confidentiality, processing integrity, security, and availability. Since security is a required common criteria baseline, it is applicable to all SOC 2 reports. Organizations choose the last four requirements based on what their clients' contracts and security questionnaires truly call for. These factors work together to determine the audit's scope and cost.
Is SOC 2 a legal requirement?
No government agency enforces SOC 2, and it is not mandated by law. However, a SOC 2 report is practically required for software vendors and other service providers managing customer data because the majority of enterprise clients and many industry contracts essentially demand one before they will sign a deal.
How hard is it to get SOC 2 compliant?
The degree of difficulty depends on how well-developed your current security measures are. Companies with strong access management, documented policies, and consistent monitoring often move through the process faster, while organizations starting from scratch may need several months to build the required controls, gather evidence, and prepare for the audit. The timeline can potentially be significantly shortened by bringing in outside experts.
What are SOC 1, SOC 2, and SOC 3?
Controls pertinent to a service organization's influence on a client's financial reporting are covered in SOC 1 reports. SOC 2 reports assess security and associated Trust Services Criteria for businesses that handle consumer data. A SOC 3 report is a condensed, publicly accessible synopsis of a SOC 2 report that is meant more for broad audiences than technical reviewers.
How long does SOC 2 compliance take?
There is no universal SOC 2 timeline. Preparation depends on existing control maturity, remediation needs, scope, auditor scheduling, and report type. A Type 2 also requires an examination period during which operating effectiveness can be evaluated. Because it takes several months of monitoring to demonstrate that controls function consistently over time, a Type 2 report typically takes longer.
Who can perform a SOC 2 audit?
A SOC 2 audit can only be carried out by a licensed CPA firm that has experience with attestation engagements. The firm must remain independent from your organization throughout the engagement, and its auditors typically include professionals with both accounting credentials and hands-on information security expertise to properly evaluate technical controls. This combination of knowledge guarantees a reliable, technically sound opinion.
