SOC 2 Requirements
For companies handling customer data, SOC 2 attestation has rapidly shifted from a “nice-to-have” to a core market requirement.
Today, 65% of organizations report that buyers, investors, and partners demand proof of compliance, making SOC 2 the most requested attestation across B2B SaaS.
The operational benefits are immediate: companies with a valid SOC 2 and a trust portal complete security reviews up to 81% faster, saving security and sales teams significant time.
More critically, SOC 2 manages risk. With roughly30% of data breaches now involving vendors, procurement teams view this report as the absolute baseline for third-party security.
In this guide, we’ll break down exactly what SOC 2 compliance requires, demystify the auditing process, and share the practical steps you can take to maintain it efficiently.
What is a SOC 2 Report?
A SOC 2 report is an independent audit that examines how a service organization protects and manages data according to the Trust Services Criteria from the American Institute of Certified Public Accountants (AICPA), which cover security, availability, processing integrity, confidentiality, and privacy.
Organizations that handle sensitive or regulated data such as technology and SaaS companies, financial institutions and managed service providers rely on SOC 2 to show clients and partners that their data protection practices meet recognized standards.

SOC 2 sits alongside SOC 1 and SOC 3 as one of the 3 System and Organization Control report types.
SOC 2 report comes in two forms:
- SOC 2 Type I evaluates the design of controls at a specific moment to determine whether the control structure is suitable for meeting the trust criteria,
- SOC 2 Type II evaluates how those controls operate over a defined period, often 6 to 12 months, to show whether they function consistently.
What are the SOC 2 Trust Services Criteria?
The Trust Services Criteria (TSC) are the foundation of SOC 2. They are not just themes or general goals, they are the actual requirements that define what your organization must maintain to achieve and sustain SOC 2 compliance.
When a company pursues SOC 2, it is assessed against these criteria. Each one contains specific control objectives that outline what you need to have in place, prove, and keep operating consistently.
Here’s how that works in practice:

1. Security
Security is the foundation of SOC 2 and the only mandatory criterion across all reports. It focuses on protecting systems and data from unauthorized access, disclosure, or damage.
This involves preventive, detective, and corrective measures like firewalls, intrusion detection systems, multi-factor authentication, and security awareness training.
The principle also requires governance elements, including risk assessments, defined security roles, and continuous monitoring. Most controls under this category, known as Common Criteria, overlap with the other four Trust Services Criteria.
These controls often include access restriction policies, change management, and physical safeguards to protect infrastructure.
In practice: Organizations demonstrate compliance through formalized policies, security incident response procedures, and regular penetration tests.

Examples or control expectations:
- Firewalls and intrusion detection: Configure firewalls to restrict inbound and outbound traffic and deploy monitoring tools that alert when suspicious activity occurs.
- Multi-factor authentication (MFA): Require more than one form of verification (for example, password plus mobile app code) for all admin and remote logins.
- Security roles and responsibilities: Define who owns what in security management, from IT admins to executives, and maintain documentation for accountability.
- Risk assessments: Perform periodic reviews to identify vulnerabilities, rank their impact, and plan mitigation strategies.
- Access control policies: Use the principle of least privilege to restrict user access to only what’s necessary for their role.
- Physical security: Limit data center access to authorized personnel, using keycards, cameras, and visitor logs.
Relevant SOC 2 Security Criteria (CC):
- CC2.2: The entity internally communicates information, including objectives and responsibilities for internal control, necessary to support the functioning of internal control.
- CC3.2: The entity identifies risks to achieving its objectives and analyzes risks to determine how they should be managed.
- CC6.1: The entity implements logical access security software, infrastructure, and architectures over protected information assets to protect them from security events.
2. Availability
Availability ensures systems and data remain accessible and operational when needed. It’s not about 24/7 uptime, but about proactive planning for resilience and disaster recovery. This includes backup systems, failover processes, capacity management, and environmental threat assessments.
Entities must also evaluate processing capacity and recovery procedures to meet operational goals. The focus here is business continuity, maintaining reliable service for customers even during disruptions.
In practice: Auditors expect documented recovery objectives (RTO/RPO), tested disaster recovery plans, and monitoring systems that detect capacity or performance risks early.

Examples or control expectations:
- Disaster recovery plans: Define how systems will be restored after an outage and test these plans at least annually.
- Recovery time and point objectives (RTO/RPO): Document acceptable downtime and data loss limits, and verify they match business and customer expectations.
- System monitoring: Use automated tools to track uptime, performance, and capacity trends so problems can be addressed before failure.
- Backup and replication: Schedule frequent, encrypted backups to offsite or cloud storage and test restoration regularly.
- Failover mechanisms: Configure standby systems or redundant servers to automatically take over when a primary system fails.
- Environmental safeguards: Install temperature, humidity, and power monitoring to prevent physical equipment failure.
Relevant SOC 2 Availability Criteria (A):
- A1.1 – The entity maintains, monitors, and evaluates current processing capacity and use of system components (infrastructure, data, and software) to manage capacity demand and enable additional capacity to meet objectives.
- A1.3 – The entity tests recovery plan procedures supporting system recovery to meet its objectives.
3. Confidentiality
Confidentiality deals with protecting sensitive business information such as intellectual property, financial data, or customer contracts. The principle ensures that confidential data is both shared and destroyed securely. It differs from privacy in that privacy focuses on personal information, while confidentiality extends to all non-public organizational data.
Controls here include restricting access to authorized personnel, defining data retention timelines, and verifying secure disposal. Criteria also include identifying confidential data at creation and verifying secure deletion at the end of its lifecycle.
In practice: Encryption in transit and at rest, contractual non-disclosure terms, and documented data classification frameworks are key elements.

Examples or control expectations:
- Data classification: Tag information based on sensitivity (public, internal, confidential) and define how each type must be handled.
- Encryption: Encrypt confidential data both when stored (at rest) and when transferred (in transit) across networks.
- Access restrictions: Limit file and database access to employees who require it, verified through role-based permissions.
- Retention and disposal: Keep data only as long as necessary for business or legal purposes, then delete it using secure methods like cryptographic wiping.
- Third-party controls: Use nondisclosure agreements (NDAs) with vendors who handle confidential data and verify they meet security standards.
- Audit trails: Maintain logs showing who accessed or modified confidential data and review them regularly.
Relevant SOC 2 Confidentiality Criteria (C):
- C1.1 – The entity identifies and maintains confidential information to meet confidentiality objectives.
- C1.2 – The entity disposes of confidential information to meet confidentiality objectives.
4. Processing Integrity
Processing integrity checks whether a company’s systems process data accurately, completely, and on time. It confirms that services operate as intended and outputs are reliable. For example, an e-commerce platform must correctly handle orders and payments without duplication or errors.
This principle focuses on input validation, processing accuracy, and output review. Organizations should have mechanisms for error detection and prompt correction, supported by quality assurance controls and monitoring tools.
In practice: Companies implement automated data validation, regular reconciliation processes, and controls around application updates to prevent processing errors.

Examples or control expectations:
- Input validation: Automatically check data as it’s entered into systems to prevent errors, duplicates, or invalid values.
- Transaction logging: Record each transaction and track it through all stages of processing to identify anomalies or failures.
- Reconciliation procedures: Compare system outputs with source data (for example, accounting reports vs. transaction logs) to catch discrepancies.
- Error handling: Define how system or data errors are reported, corrected, and reviewed for recurring issues.
Relevant SOC 2 Processing Integrity Criteria (PI):
- PI1.1 – The entity obtains or generates, uses, and communicates quality information regarding processing objectives, including data definitions and specifications.
- PI1.2 – The entity implements policies and procedures over system inputs, including controls for completeness and accuracy.
- PI1.3 – The entity implements policies and procedures over system processing to meet objectives for products, services, and reporting.
5. Privacy
Privacy governs the collection, use, retention, disclosure, and disposal of personal information. It aligns closely with privacy laws such as GDPR or CCPA. Compliance in this area requires lawful collection, consent management, and clear communication of data handling practices.
Transparency is also key, including informing users about data usage, honoring opt-out requests, and maintaining secure storage.
Auditors will look for policies covering notice, choice, access, and enforcement. Privacy also intersects with confidentiality but focuses strictly on personally identifiable information (PII).
In practice: Strong privacy programs include consent workflows, limited data collection, privacy impact assessments, and staff training on handling sensitive information.

Examples or control expectations:
- Data collection transparency: Give users clear notice about what personal information is collected and why.
- Consent and choice: Obtain explicit consent where required and offer options to opt out or delete data.
- Access rights: Allow individuals to view, correct, or request deletion of their personal information.
- Data minimization: Collect only what’s necessary for a defined purpose, not everything that could be gathered.
- Privacy impact assessments: Evaluate new products or processes for privacy risks before launch.
- Secure storage and deletion: Store personal data in encrypted systems and remove it securely once no longer needed.
Relevant SOC 2 Privacy Criteria (P):
- P1.1 – The entity provides notice to data subjects about its privacy practices and updates the notice promptly when changes occur.
- P2.1 – The entity communicates available choices regarding collection, use, retention, disclosure, and disposal of personal information, including the consequences of each choice.
Note: The AICPA is the official issuer of the framework and standards underpinning SOC 2 reports. If you want you can visit the AICPA website here to to learn more about SOC 2.
What Are SOC 2 Compliance Requirements?
SOC 2 compliance is based on the AICPA Trust Services Criteria (TSC). These criteria help organizations show that their systems protect customer data through strong security and privacy controls. The five principles of SOC 2 are security, availability, processing integrity, confidentiality, and privacy. Every company must meet the security principle, while the others depend on the services provided.

1. Understanding the Trust Services Criteria (TSC)
Before starting a SOC 2 audit, you must understand how the TSC applies to your business. The audit focuses on how your systems manage risks and protect data. Key conditions include:
- Information security: Prevent unauthorized access or misuse of data.
- Logical and physical access controls: Manage who can enter systems and facilities, limiting access to only those who need it.
- System operations: Detect and correct irregularities that affect performance or security.
- Change management: Use a formal process to control changes to systems, reducing the risk of unintended or harmful updates.
- Risk mitigation: Identify and address risks from vendors, outages, and business disruptions.
Each organization can choose its own controls to meet these criteria. For example, one company might use multi-factor authentication and data loss prevention tools, while another might focus on monitoring systems, limiting data center access, and reviewing user rights quarterly.
2. Scoping and Selecting Criteria
The first step is to define which systems, processes, and data fall within your SOC 2 scope. This step determines what the audit will cover. After that, select the Trust Services Criteria that apply to your operations.
- A cloud provider may include availability because uptime is critical.
- A healthcare organization may include privacy because it handles personal health information.
3. Implementing Security Controls
Security is mandatory for all SOC 2 audits. You must demonstrate that your organization protects systems and data from unauthorized access. Common security controls include:
- Multi-factor authentication (MFA) for users and administrators
- Firewalls and intrusion detection systems
- Secure configurations for servers and applications
- Employee background checks and regular security awareness training
- Documented incident response and escalation procedures
These measures show that security risks are managed, and that only approved personnel can access sensitive systems.
4. Addressing Additional Criteria
If you include other TSC categories, you’ll need extra controls:
- Availability: Maintain backups, redundancy, and disaster recovery plans to keep services running.
- Processing integrity: Confirm that systems process data accurately and completely through validation and reconciliation.
- Confidentiality: Protect nonpublic information (like financial data or intellectual property) with encryption and strict access policies.
- Privacy: Handle personal data responsibly, following written policies and laws. Maintain consent records and handle deletion requests properly.
5. Documenting Policies and Evidence
Auditors rely on documentation to confirm that your controls exist and function as intended. You’ll need records such as:
- Access review logs
- Training completion lists
- Incident response reports
- Vendor risk assessments
Thorough documentation helps auditors verify your compliance and supports management’s claims about your security practices.
6. Proving Controls Work Over Time
For a SOC 2 Type II report, the auditor reviews how your controls perform over a specific time period. This means you must show ongoing monitoring, control testing, and incident tracking. Consistency matters as much as design; the goal is to prove that the controls are effective in practice, not just on paper.
SOC 2 Password Requirements
SOC 2 uses principle based controls, so it does not mandate a specific password formula. Auditors look for a documented, enforced policy that follows current standards such as NIST 80063B and meets the Trust Services Criteria for logical access.
Typical expectations in 2025
- Length: Minimum of 12 characters for workforce and admin accounts, with support for long passphrases.
- Complexity: Traditional character type rules are acceptable, although many teams rely on length and breached password checks instead of heavy composition rules.
- History and reuse: Block reuse of at least 6 to 10 previous passwords.
- Lockout controls: Lock or throttle after 3 to 5 unsuccessful attempts. Trigger alerts if repeated lockouts occur.
- Dormant accounts: Disable accounts that show no activity after 60 to 90 days.
- Rotation: Regular rotation is not required for standard users if MFA and strong screening are in place. Many teams choose 180 to 365 days for standard users and 60 to 90 days for privileged roles.
- MFA: Required for remote access, cloud consoles, production systems, and all admin accounts. App based TOTP or hardware based factors are preferred over SMS.
- Storage and transmission: Passwords must be hashed with modern algorithms such as Argon2, bcrypt, or PBKDF2, stored with unique salts, never logged, and transmitted only over encrypted channels.
- Breached password checks: Block common, weak, or known compromised passwords through identity provider features or external services.
- Administrative handling: Use password managers for staff, remove default credentials before deployment, apply strict provisioning and deprovisioning, and maintain regular access reviews.
What is a SOC 2 Readiness Assessment?
A SOC 2 Readiness Assessment is a preparatory review that measures how well an organization’s existing controls and policies align with the AICPA’s Trust Services Criteria for security, availability, processing integrity, confidentiality, and privacy. It takes place before the formal SOC 2 audit to evaluate current compliance and pinpoint gaps.

Auditors or consultants review documentation, technical safeguards, and operational practices to see whether they meet SOC 2 requirements. The outcome is a gap analysis and action plan that help the organization fix weaknesses, organize evidence, and strengthen security controls.
Completing a readiness assessment lowers the risk of audit issues, shortens the audit process, and confirms that the organization’s controls are mature enough for a SOC 2 Type I or Type II report.
What are the AICPA Points of Focus?
The AICPA Points of Focus are detailed guidance notes that explain how each Trust Services Criterion should be understood and applied.
They help organizations and auditors interpret SOC 2 requirements consistently and evaluate whether controls are properly designed and operating as intended.

Revised in 2022, these points reflect modern security and compliance challenges, including vendor oversight, technology updates, and continuous monitoring. They do not change the Trust Services Criteria but clarify what effective controls look like in practice.
Each Trust Services category has its own set of related points of focus:
- Security: Access control, change management, incident response, and system monitoring.
- Availability: Backup, disaster recovery, and capacity planning to maintain system uptime.
- Processing Integrity: Input validation, transaction accuracy, and error correction.
- Confidentiality: Data classification, restricted access, encryption, and secure disposal.
- Privacy: Lawful data collection, user consent, and safe handling of personal information.
Although not mandatory, points of focus are valuable for designing and reviewing controls. They provide clear direction when creating policies, gathering audit evidence, and maintaining compliance with SOC 2 standards.
Why SOC 2 Compliance Is Important?
SOC 2 is important for companies in SaaS, finance, and healthcare. It shows that your organization keeps customer data safe and handles it responsibly, which helps build public trust.
Here are a few reasons why SOC 2 matters for your business:

1. Builds Trust with Customers and Partners
SOC 2 compliance gives clients confidence that their data is handled safely and responsibly. It shows that your organization has the right security controls in place to protect information and maintain system reliability.
Trust is particularly critical for SaaS, healthcare, and finance companies that process sensitive data. With the average cost of a data breach now reaching $4.4 million globally, independent assurance such as SOC 2 has become a key differentiator when winning customer trust and closing contracts.
2. Demonstrates Strong Data Protection Practices
About 22% of breaches involve stolen credentials and 20% result from exploited vulnerabilities. SOC 2 directly addresses these risks through controls focused on access management, vulnerability remediation, and continuous monitoring, helping reduce the chance of data loss and service interruption.
Built around the AICPA Trust Services Criteria: security, availability, processing integrity, confidentiality, and privacy, SOC 2 demonstrates that an organization manages data responsibly and maintains strong safeguards.
3. Supports Regulatory and Contractual Requirements
Roughly 30% of data breaches involve third-party partners, which has made SOC 2 reports a growing expectation during vendor risk assessments. Many customers and partners now ask for them before finalizing agreements.
Having a completed report speeds up those reviews and helps move deals forward more quickly. Beyond meeting customer demands, SOC 2 also aligns operations with frameworks such as ISO 27001, HIPAA, and GDPR. This overlap allows organizations to meet regulatory and contractual obligations more efficiently and with less duplication of effort.
4. Strengthens Internal Processes
About 93% of organizations report that a single hour of downtime costs at least $300,000. SOC 2 preparation helps reduce that risk by reinforcing availability and resilience through defined controls.
The process involves reviewing access control, incident response, system monitoring, and documentation practices. These activities strengthen operational maturity and accountability while lowering the chance of costly outages and related financial losses.
5. Fit for Multiple Sectors
SOC 2 applies to a wide range of service organizations, including SaaS platforms, cloud hosting, payments, healthcare IT, and managed services. The AICPA frames SOC as a suite of services for system-level controls across industries, which is why firms in many sectors adopt SOC 2 to meet customer and contract expectations.
6. Measurable Operating Effectiveness
A Type I report evaluates control design at a point in time. A Type II report also evaluates operating effectiveness across a period, which provides a richer signal of day-to-day practice for customers that depend on your service. AICPA materials and training outline this difference and show how Type II evidence helps readers gauge reliability over time.
Who Can Perform a SOC Audit
A SOC audit can only be carried out by a Certified Public Accountant (CPA) or a CPA firm registered with the AICPA. Since the SOC framework is governed by the American Institute of Certified Public Accountants, only licensed auditors can issue official SOC 1, SOC 2, or SOC 3 reports.

These auditors are trained to evaluate how an organization’s internal controls meet the Trust Services Criteria for security, availability, processing integrity, confidentiality, and privacy. Their role is to independently verify that the controls are properly designed and working as intended.
Key facts about SOC auditors:
• Must be licensed CPAs or AICPA-accredited firms
• Must remain independent from the organization being audited
• Often specialize in IT security, risk, and compliance audits
• Conduct either Type I (design of controls) or Type II (design and operating effectiveness) audits
Consultants or security firms can help a company prepare through a readiness assessment, but only a CPA or CPA firm can perform the official SOC audit and issue the report recognized by clients, partners, and regulators.
SOC 2 Audit Checklist
Preparing for a SOC 2 audit means confirming that your controls meet the AICPA Trust Services Criteria for security, availability, confidentiality, processing integrity, and privacy.
Use this audit checklist to stay organized:

- Scope – Select Type I or Type II, decide which categories apply, define system boundaries, and include sub-service providers.
- Description – Summarize your system, service commitments, and any major changes.
- Controls – Map policies to the Trust Services Criteria (CC1–CC9).
- Policies – Cover governance, risk assessment, access, change management, monitoring, continuity, vendors, and privacy.
- Evidence – Keep records for access reviews, change logs, incidents, patching, encryption, backups, and vendor assessments.
- Readiness – Run a gap check, address weaknesses, and organize evidence for your auditor.
- Audit – Provide the management assertion, system description, and supporting evidence; review results and plan the next cycle.
SOC 2 Audit Process
The SOC 2 audit typically occurs in several phases. Below is a brief overview of each stage in the audit process.

Step 1. Preparation and Readiness Assessment
The process starts with a readiness assessment, often conducted by an experienced or certified auditor. This assessment functions as a practice run to predict how the actual audit might unfold. It helps the organization assess existing operational controls, verify documentation, and identify weaknesses that could cause findings later.
Some companies bring in external security consulting firms to handle this stage or to perform an internal pre-audit review. Early preparation supports a strong control environment that auditors can later validate.
Step 2. Gap Analysis
Next, a gap analysis is performed. The qualified auditor compares the organization’s current security controls against the SOC 2 Trust Services Criteria. This step highlights areas that need improvement before the formal audit begins.
Teams also identify confidential information that requires extra protection and document why certain criteria might not apply. During this stage, attention to the HIPAA Security Rule becomes critical for entities handling healthcare data.
Step 3. Control Remediation and Documentation
Based on the findings from the readiness and gap phases, teams address any missing or weak controls. This may include updating policies, refining incident response steps, or improving monitoring.
Clear documentation of processes, controls, and risk assessments is critical, since auditors will request evidence for each control during the actual audit. Recording data inputs and maintaining accurate audit trails support both transparency and accountability.
Step 4. Formal SOC 2 Audit
A third-party certified public accountant (CPA) firm conducts the official SOC 2 audit. They examine both the design and operational effectiveness of controls.
For Type I, the audit looks at controls at a single point in time. For Type II, the focus extends to control performance across several months. A well-prepared organization demonstrates a strong control environment that helps ensure compliance throughout the review period.
Step 5. Reporting and Continuous Improvement
The audit concludes with a formal report summarizing findings, control effectiveness, and any exceptions. Organizations use the results to guide continuous improvement, strengthen governance, and gain a competitive advantage through greater trust and reliability.
SOC 2 Type I and SOC 2 Type II
SOC 2 reports come in two types, and the difference lies in what they assess and over what time period.
| Aspect | SOC 2 Type I | SOC 2 Type II |
| Focus | Reviews control design at one point in time. | Tests control performance over several months. |
| Evidence | Policies, procedures, and setup documents. | Logs, reports, and real operational data. |
| Timeframe | Single date snapshot. | Ongoing review period. |
| Purpose | Shows readiness and proper design. | Proves controls work as intended. |
| Use Case | For organizations starting their SOC 2 process. | For mature programs showing consistent security. |
| Trust Level | Basic assurance. | Stronger assurance for clients and partners. |
These reports often tie directly to service level agreements to demonstrate operational consistency.
Why Businesses Choose Bright Defense for SOC 2 Readiness
Bright Defense helps organizations achieve and maintain SOC 2 compliance through expert guidance and practical support. Our team conducts gap assessments, defines scope, and helps implement controls for access management, change control, incident response, and vendor risk.
We offer a compliance platform that centralizes training, phishing simulations, and evidence collection to simplify audits. For companies without a full-time security leader, our virtual CISO service provides expert direction throughout the SOC 2 process.
Bright Defense focuses on helping small and mid-sized businesses store customer data securely and build lasting security programs that meet customer expectations and strengthen trust through proven, well-documented controls.
FAQ
The five Trust Services Criteria cover controls relevant to data security, availability, processing integrity, confidentiality, and privacy. These categories guide how organizations protect sensitive customer data and manage customer data responsibly.
The primary document is the “2017 Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy.” It explains what a service organization must address when designing and evaluating its control environment for regulatory compliance.
There is also a companion document titled “Description Criteria for a Description of a Service Organization’s System in a SOC 2 Report,” which outlines what the system description section must include, including any data processing details.
For the Availability category, a service organization must satisfy all the common criteria (CC1 through CC9) plus the availability-specific criteria (A-series). Requirements include:
– Capacity management: Monitoring and forecasting current processing capacity and usage, then making changes when needed to maintain financial reporting reliability.
– Environmental protections, backup, and recovery: Addressing environmental threats, performing backups, storing data offsite as appropriate, and managing recovery infrastructure with attention to risk management and vendor management.
Availability focuses on whether systems support operation, monitoring, and maintenance. It does not prescribe specific uptime targets; instead, organizations define their own commitments (for example, via SLAs) and design controls to meet those, often validated through a third party auditor.
No federal or state law mandates SOC 2 compliance for all organizations. However, many customers, especially in business-to-business or enterprise contexts, require a current SOC 2 report as part of contractual terms, particularly when protected health information or other regulated data is involved.
Get In Touch


