SOC 2 compliance requires an independent CPA to examine the controls around a system you use to deliver a service. The CPA then reports whether those controls meet the AICPA Trust Services Criteria you put in scope. Security is always part of that exam. Availability, processing integrity, confidentiality, and privacy are added only when they match promises you make to customers. A Type I report covers whether the controls are suitably designed at one point in time. A Type II report also covers whether they operated effectively across a period.
Get a cybersecurity review before a customer asks for your SOC 2 report.
What SOC 2 compliance requires of your company
A customer asking for SOC 2 compliance is not asking you to buy a certificate. The AICPA designed SOC 2 as an examination of controls at a service organization. You describe the system, you state which criteria apply, and a licensed CPA tests the controls that are supposed to meet those criteria. There is no AICPA scorecard that says “pass these 80 items and you are done.” The requirement is simpler than that. The controls, as designed and operated, must support the commitments you have already made.
That is why two companies can both be “SOC 2 compliant” and still have very different reports. A payroll processor and a file-hosting firm do not make the same promises. The exam follows the promises, not a universal product list.
If you only need the short definition, what SOC 2 compliance is is a separate question. This page is about the requirements themselves.
Which Trust Services Criteria SOC 2 compliance includes
The AICPA Trust Services Criteria group the exam into five categories. Security is the foundation. The other four are optional add-ons that pull in extra criteria on top of the shared set.
| Category | What the criteria require | When it belongs in your report |
|---|---|---|
| Security | Information and systems are protected against unauthorized access, unauthorized disclosure, and damage that could compromise the other categories. | Always. Every SOC 2 examination includes the common criteria that make up security. |
| Availability | Information and systems are available for operation and use so you can meet your objectives. | When you commit to uptime, recovery time, or a hosted service customers depend on staying online. |
| Processing integrity | System processing is complete, valid, accurate, timely, and authorized. | When customers rely on your system to process transactions or produce outputs correctly, not only to store them. |
| Confidentiality | Information you designate as confidential is protected from collection through final disposal. | When contracts or your own policies mark certain customer data, designs, or records as confidential. |
| Privacy | Personal information is collected, used, retained, disclosed, and disposed of in line with your objectives and the notice you gave people. | When you handle personal information and make privacy commitments, which is a different bar from marking a file confidential. |
The wording above follows the AICPA’s Trust Services Criteria for SOC 2. Security uses the common criteria, numbered CC1.1 through CC9.2 in the 2017 criteria (revised points of focus in 2022). Availability, processing integrity, confidentiality, and privacy each add their own criteria. If you select only availability, the auditor still evaluates every common criterion, because a weak access or change-management control can break an availability commitment.
A practical way to choose: read the security, uptime, and data-handling sentences in your customer contracts and on your website. Those sentences are your service commitments. Criteria you cannot tie to a commitment do not belong in the report. Criteria you have already promised, and then leave out, are the ones a prospect’s security reviewer will notice.
The common criteria every SOC 2 report has to cover
The common criteria are the part people underestimate. They are not a single firewall setting. They are nine families of control objectives, and a report that includes any category still has to address all of them.
- Control environment. Someone is accountable, the board or owners set a tone, and people are hired and evaluated with security responsibilities in mind.
- Communication and information. You tell internal users and customers what the security commitments are, and you have a way to receive reports of failures.
- Risk assessment. You identify how the system could fail the commitments, including fraud and vendor risk, and you update that view.
- Monitoring. You watch the controls, investigate exceptions, and tell the right people when something breaks.
- Control activities. Policies exist and are actually carried out, including the technology controls that do the daily work.
- Logical and physical access. People and software get only the access they need, credentials are managed, and offices or closets that hold systems are protected.
- System operations. You detect, respond to, and recover from incidents that threaten commitments.
- Change management. Changes to infrastructure, software, and data are authorized, tested, and approved before they go live.
- Risk mitigation. You select vendors carefully, and you have a way to limit damage when a control fails.
An auditor is not grading your intent. For each criterion they look for a control, a person who owns it, and evidence that it happened. A policy with no operating record does not meet a Type II exam. A tool that nobody reviews does not meet monitoring.
What a SOC 2 system description must include
Controls are only half of the requirement. SOC 2 also requires a description of the system, written against the AICPA description criteria. The description tells a reader what was examined. Without it, the opinion has nothing to attach to.
A description that meets the criteria covers the services in scope, the commitments you make about those services, and the system requirements those commitments create. It names the infrastructure, software, people, procedures, and data. It identifies the boundaries, including what a subservice organization does for you and whether you include their controls (the inclusive method) or exclude them (the carve-out method). It also discloses significant changes during the period and any incidents that are relevant to readers.
This is where Tampa Bay and Florida service firms usually get specific. A 40-person firm that hosts client files, runs Microsoft 365, and outsources after-hours monitoring has a different system than a manufacturer with one on-premises application. The description has to match the real system. Copying a template that lists controls you do not operate is a description failure, not a shortcut.
If the system includes networks, identity, backups, and a help desk that someone else runs, those parties belong in the description. Managed IT support can operate the controls. It cannot be invisible to the report.
Type I and Type II require different proof
Both report types use the same criteria. They do not require the same proof.
- Type I asks whether the description is fairly presented and whether the controls were suitably designed at a specified date. It does not test whether they worked over time.
- Type II asks those same design questions and then tests operating effectiveness throughout a period. The auditor samples tickets, access reviews, change records, alerts, and backups from that window.
Many customer security questionnaires accept a Type I the first time and ask for a Type II at renewal. The requirement that changes is the operating window. You need controls that have been running long enough to produce samples, not a binder assembled the week the auditor arrives. A period shorter than several months rarely gives an auditor enough occurrences to test. Ask the CPA what window they will examine before you pick a start date.
Choosing the report type is a buying decision. Meeting it is an evidence decision. The step-by-step prep lives in the SOC 2 compliance checklist. What matters here is the bar: design only, or design plus operation.
Evidence SOC 2 compliance expects you to keep
You do not need a specific brand of software. You do need records an auditor can re-perform. Across the common criteria, the evidence classes are consistent:
- Access. A current user list, tickets for joiners and leavers, multi-factor authentication on systems in scope, and a periodic review that someone signed.
- Change. Requests, test results, and approvals for production changes, including firewall and cloud configuration changes.
- Operations. Alert history, incident tickets, backup job results, and a restore test. A backup that has never been restored is a weak availability story.
- Risk and vendors. A written risk assessment, vendor reviews for subservice organizations, and proof you followed up on exceptions.
- People. Security training completion, policy acknowledgements, and job descriptions that name who owns the controls.
Penetration testing is not one of the five categories, but it is common evidence for risk assessment and monitoring. If a customer contract or your own policy says you test, the report will expect the test and the remediation. Network penetration testing produces that evidence. It does not replace the access, change, and incident records.
Keep the records in the system that created them. Exporting everything into a slide deck the week of fieldwork is how samples fall apart.
What SOC 2 compliance does not require
A few requirements get assumed and then waste a quarter.
- It is not a legal certification. The AICPA calls the result an examination report, not a license. You can share it with customers under the restrictions the CPA sets. You should not stamp “certified” on a website as if a regulator issued it.
- It is not SOC 1 or SOC 3. SOC 1 covers controls relevant to a customer’s financial-statement audit. SOC 3 is a short general-use report on the same trust services criteria, without the detailed control description SOC 2 readers expect.
- It does not replace HIPAA or PCI DSS. A Florida clinic can need a HIPAA security risk analysis and still have a customer demand SOC 2 for a different system. A firm that stores cardholder data still has PCI DSS obligations. SOC 2 controls often overlap those programs. They do not satisfy them.
- It does not pick your tools. The criteria are outcome-based. A firewall, an EDR agent, and a ticketing system are how many firms implement them. The requirement is the control outcome and the evidence, not a named product.
- It does not cover the whole company by default. The exam covers the system you describe. Leaving a product out is allowed. Quietly processing that product’s data inside the described system is not.
Companies that already map security work to a known structure can reuse it. The NIST Cybersecurity Framework lines up well with the common criteria, but a NIST write-up is not a SOC 2 opinion.
How a Florida service business should read the requirement
Most IGTech365 clients are not SaaS companies with a compliance team. They are healthcare groups, law firms, manufacturers, and contractors whose customers, or whose customers’ customers, send a security questionnaire. The useful reading of SOC 2 compliance for that business is narrow.
- Name the service a customer is actually asking about. “The company” is too broad. “The system that hosts client documents and email” is a system.
- List the commitments already in the contract: who can access data, how fast you restore, whether you encrypt, whether you will notify on an incident.
- Select criteria that match those commitments. Security is included. Add availability or confidentiality only when the contract requires them.
- Write the description from the live environment, including the managed service providers and cloud platforms that operate pieces of it.
- Decide whether the customer will accept design at a date, or whether they need operating effectiveness over a period.
Cyber insurance applications ask for a related but different set of controls. Passing an insurance questionnaire is not a SOC 2 report, and a SOC 2 report will not answer every insurance question. If a carrier is the party asking, start with how to prepare a cyber insurance application and treat SOC 2 as a separate customer requirement.
IGTech365 supports the control side of this work for Tampa Bay companies: identity, monitoring, backup, network security, and the operating records an examiner samples. The CPA still has to be independent. We do not issue the opinion.
Want a straight read on which controls your customers are actually asking for? Call IGTech365 at (866) 365-7798.
Frequently asked questions
Is security required in every SOC 2 report?
Yes. The common criteria that make up the security category are part of every SOC 2 examination. Availability, processing integrity, confidentiality, and privacy are added only when they are in scope, and each one still sits on top of those common criteria.
Does SOC 2 compliance require a Type II report?
No. Type I and Type II are both SOC 2 examinations. Type I covers design at a specified date. Type II also tests whether the controls operated effectively over a period. Your customer contract, not the AICPA, decides which one you need.
How is SOC 2 compliance different from a penetration test?
A penetration test is one piece of evidence about vulnerabilities. SOC 2 compliance is an opinion on a described system against the Trust Services Criteria, covering governance, access, operations, change, and vendor risk as well as technical testing.
Can a managed IT provider make us SOC 2 compliant?
A provider can design and run controls, keep the records, and help write an accurate system description. Only an independent CPA can perform the examination and issue the report. The provider’s own services also have to be disclosed as part of your system.
Does SOC 2 compliance expire?
A Type I report is tied to a date and a Type II report is tied to a period. Customers typically ask for a new report after that window. The criteria do not grant a permanent status.