SOC 2 compliance isn't optional when you're handling protected health information, it's the baseline expectation from every hospital, health system, and EHR vendor you'll work with. But the AICPA SOC 2 guide and its underlying framework can be dense, and figuring out exactly what's required, which Trust Services Criteria apply, how reporting works, what auditors actually evaluate, takes real effort to untangle. Whether you're preparing for your first examination or tightening controls ahead of a renewal, understanding the AICPA's standards from the source matters more than reading someone's summary of a summary.

At SoFaaS, we built our managed SMART on FHIR platform on SOC 2 Type II compliant infrastructure because healthcare application developers shouldn't have to choose between moving fast and meeting enterprise security requirements. Going through the SOC 2 process ourselves gave us firsthand experience with the criteria, controls, and reporting steps that this guide covers, and reinforced why getting compliance right from the start saves months of rework down the line.

This article breaks down the AICPA's SOC 2 framework into concrete, actionable pieces: the five Trust Services Criteria, how Type I and Type II reports differ, the steps involved in preparing for and completing an examination, and what the final report actually contains. By the end, you'll have a clear picture of what SOC 2 requires and how to approach each phase of the process with confidence.

What the AICPA SOC 2 guide is and isn't

The AICPA SOC 2 guide refers to a set of authoritative documents published by the American Institute of Certified Public Accountants. The primary components are AT-C Section 105 and AT-C Section 205 (the clarified attestation standards) along with the companion Trust Services Criteria (TSC) document. These publications define how licensed CPAs conduct SOC 2 examinations and what criteria they apply when evaluating your controls. If you're preparing for SOC 2 or managing a renewal, these are the documents your auditor works from directly, not third-party summaries or vendor-produced interpretations of them.

What the AICPA SOC 2 guide actually is

The AICPA publishes the TSC document under its System and Organization Controls framework, and it serves two distinct purposes. First, it establishes the five Trust Services Criteria categories: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Second, it provides specific "points of focus" under each criterion that describe the behaviors and control activities auditors look for when they test your environment. The points of focus aren't hard requirements by themselves, but auditors treat them as the primary lens for judging whether your controls genuinely satisfy each criterion's intent.

The Trust Services Criteria document receives periodic updates, so always confirm you're using the current version before you finalize your control mapping.

The AICPA also publishes SOC 2 reporting guidance that explains how CPAs structure their reports, what management's written assertion must cover, and how auditors form and express their opinions. This layer of guidance covers the format of both Type I and Type II reports, the distinction between a system description and an auditor's opinion on controls, and what constitutes sufficient, appropriate evidence. Understanding this reporting structure lets you communicate precisely with your auditor and prevents confusion when the draft report lands in your inbox.

What the AICPA SOC 2 guide doesn't do

The guide does not prescribe specific technologies, vendor configurations, or minimum technical specifications. It defines what outcomes your controls must achieve, not which firewall product to deploy or how many characters your password policy must require. That distinction gives you real flexibility in how you build your control environment, but it also means you cannot follow a fixed checklist and call yourself compliant. Your auditor applies professional judgment when evaluating whether your controls satisfy the criteria, so controls that pass in one organization's environment may need adjustment in yours depending on your system boundaries and risk profile.

The guide also does not replace the role of a licensed CPA. SOC 2 is an attestation engagement, which means only a licensed CPA firm can perform the examination and issue the final report. No internal team, consultant, or compliance automation tool can produce a valid SOC 2 report on its own. What the guide gives you is a solid foundation: the knowledge to design your control environment accurately, write a complete system description, and engage your auditing firm from a position of preparation rather than guesswork. Knowing the standards thoroughly is the single best way to reduce the back-and-forth that extends timelines and drives up audit costs.

SOC 2 criteria, categories, and points of focus

The five Trust Services Criteria categories form the backbone of every SOC 2 examination. The AICPA SOC 2 guide organizes these categories so you can select the ones relevant to your system and build your controls around their specific requirements. Security (also called the Common Criteria) is mandatory for every engagement; the other four categories are optional and apply only when your services include those functions.

The five categories explained

Each category covers a distinct aspect of how your system protects data and delivers services reliably. The table below gives you a quick reference for what each category evaluates and when to include it in your scope, which helps you avoid over-scoping or leaving critical areas unaddressed before fieldwork begins.

Category	What it evaluates	Include when...
Security	Logical and physical access, risk management, change management	Always required
Availability	System uptime and performance against commitments	You commit to uptime SLAs
Processing Integrity	Complete, accurate, timely processing	You process transactions or data on clients' behalf
Confidentiality	Protection of information designated as confidential	You store or transmit confidential business data
Privacy	Collection, use, retention, and disposal of personal information	You collect or process personal data

Selecting the right categories upfront prevents scope gaps that auditors flag during fieldwork, which delays your final report.

Points of focus and how auditors use them

Under each category, the AICPA lists specific points of focus that describe the control behaviors auditors expect to see in practice. These points of focus are not a pass/fail checklist; auditors use them to evaluate whether your controls satisfy the intent of each criterion given your particular system. For example, under the Security category's logical access controls, a point of focus calls for restricting access to authorized users. Your control satisfies that point whether you use role-based access control, attribute-based access control, or another approach, as long as you demonstrate the outcome with clear evidence.

When you map your controls to the criteria, write each control description so it directly references the specific criterion it addresses. Auditors document this mapping in their working papers, and a precise, well-organized mapping reduces back-and-forth clarification requests and shortens the overall fieldwork phase considerably.

Step 1. Choose report type and timeline

Before you schedule your first call with an auditing firm, you need to decide which report type fits your current situation. This decision shapes your entire preparation timeline, how you collect evidence, and what your final report actually communicates to customers and partners. Getting this wrong early means either redoing work or delivering a report that doesn't satisfy the requirements of your prospective clients.

Type I versus Type II: what each report proves

A Type I report captures a point-in-time assessment: your auditor reviews your system description and evaluates whether your controls are suitably designed to meet the relevant Trust Services Criteria as of a specific date. It does not test whether those controls operated effectively over time. Type I reports are useful when you need to demonstrate a baseline level of compliance quickly, for example, to unblock a sales deal or satisfy an initial vendor review.

A Type II report covers an observation period, typically between six and twelve months, and requires your auditor to test whether your controls actually operated as described throughout that window. Healthcare customers and enterprise procurement teams almost universally require a Type II report before signing contracts, because it provides evidence of consistent control operation rather than a single snapshot. If you're building a healthcare application that handles PHI and integrating with EHR systems, plan for Type II from the start rather than treating Type I as a stepping stone.

Most auditing firms recommend a minimum six-month observation period for a first Type II report to give your controls time to generate sufficient evidence without compressing the timeline.

Planning your timeline realistically

Use the template below to set realistic milestones for a first-time Type II engagement based on a six-month observation window:

Phase	Activity	Typical duration
Preparation	Scope definition, control design, gap remediation	8 to 12 weeks
Observation period	Controls operate and evidence accumulates	6 months
Fieldwork	Auditor testing, evidence review, walkthroughs	4 to 6 weeks
Report finalization	Draft review, management response, final issuance	2 to 4 weeks

Your total calendar time from kickoff to issued report typically runs nine to twelve months for a first Type II engagement. Build that into your product roadmap and any enterprise sales commitments well before you engage an auditing firm.

Step 2. Scope your system and vendors

Scoping is where most first-time SOC 2 engagements go wrong. Define your scope too narrowly and your auditor flags gaps in coverage that delay your report; define it too broadly and you generate evidence requirements that exhaust your team. The AICPA SOC 2 guide frames scope around your "system," which encompasses the infrastructure, software, people, data, and procedures that your service organization uses to deliver its services. Your job in this step is to draw precise boundaries around that system before your auditor even starts fieldwork.

Define your system boundaries

Your system description must cover every component that directly supports the services you've committed to in your customer agreements. That includes your production environment, the personnel who operate and maintain it, and the processes they follow to manage access, change, and incidents. Listing vague categories like "cloud infrastructure" isn't enough. Auditors expect you to name specific environments, regions, and services so they can trace evidence back to concrete components.

Use the template below to document your system components before you send anything to your auditor:

Component type	Specific items to list	Example
Infrastructure	Cloud providers, data centers, network segments	AWS us-east-1, VPC ID vpc-0abc123
Software	Applications, APIs, databases, operating systems	Node.js API v18, PostgreSQL 15
People	Roles with system access	DevOps engineers, on-call SREs
Data	Data types processed and stored	PHI, OAuth tokens, audit logs
Procedures	Key operational processes	Incident response, access reviews

A precise system description reduces auditor questions during fieldwork and directly shapes the strength of the opinion in your final report.

Evaluate your vendor risk

Every third-party service your system depends on to deliver its commitments is a potential gap in your control environment unless you address it explicitly. Your auditor will ask how you monitor and manage the risks that subservice organizations introduce, so you need to document each vendor, what they do, and what controls you rely on them to operate.

For each vendor, record the services they provide, the data they access, and the evidence you use to monitor their compliance, such as their own SOC 2 report, contractual security requirements, or annual security questionnaire results. Build this inventory before scoping conversations with your auditor so you can confirm which vendors fall inside your boundaries and which you address through complementary user entity controls.

Step 3. Design controls and collect evidence

Controls design and evidence collection run in parallel once your scope is locked. The AICPA SOC 2 guide maps each Trust Services Criterion to specific control objectives, and your job is to build controls that demonstrably satisfy those objectives within your defined system boundaries. Document every control before the observation period starts so your auditor has a complete picture of your environment from day one, not partway through fieldwork.

Build controls that map directly to criteria

Each control you write should reference the specific criterion it addresses and describe exactly who performs the activity, how often, and what record it produces. Auditors test controls by tracing evidence back to those descriptions, so vague language creates gaps. Write instead of "we review access quarterly": "The DevOps lead reviews IAM role assignments in AWS every 90 days and exports the review log to the designated compliance folder."

Tie every control to at least one point of focus from the Trust Services Criteria before you send your control inventory to your auditor.

Use the template below to structure each control entry consistently:

Field	Example
Control ID	CC6.1-001
Criterion reference	CC6.1 Logical access restrictions
Control owner	DevOps lead
Control description	IAM role review every 90 days with exported log
Evidence artifact	Access review log, S3 path, date stamped
Frequency	Quarterly

Collect and organize evidence from day one

Evidence collection is the phase that most teams underestimate until fieldwork is already underway. Start collecting from the first day of your observation period, not the week before your auditor arrives. Each control in your inventory needs a corresponding evidence artifact for every instance it operated during the observation window, so gaps compound quickly if you delay.

Organize your artifacts by control ID in a shared repository your auditor can access directly. For each artifact, include the control ID, the date the activity occurred, and the name of the person who performed it. This structure cuts down the back-and-forth during fieldwork and keeps your team from scrambling to reconstruct activity logs under time pressure.

Step 4. Execute the examination and review the report

Once your observation period closes, your auditing firm enters active fieldwork. During this phase, auditors conduct walkthroughs with your team, test samples of the evidence you've collected, and verify that your system description accurately reflects how your environment actually operates. Your job is to respond promptly to every request for additional evidence, clarify control descriptions when auditors flag ambiguities, and make sure the right people are available for interviews. Delays in this phase are almost always caused by slow responses from the service organization, not from the auditor's side.

What happens during fieldwork

Auditors work through your control inventory systematically, selecting samples from each control's evidence population to test whether the control operated as described. For a quarterly access review, they might pull two or three instances from the observation period and verify that each log was completed on time, by the right person, and stored in the correct location. They also conduct walkthroughs for key processes like change management, incident response, and vendor risk reviews, where a team member walks the auditor through how each process works in practice.

Missing evidence for even a single control instance can result in a qualified opinion or an exception note in your final report, so keep your evidence repository complete throughout the entire observation period.

When auditors identify gaps or control failures, they issue management comment letters that describe the finding and its potential impact. Address each finding clearly and specifically, and if remediation is possible before the report closes, complete it and document exactly what you changed.

Review the draft report carefully

Your auditor sends a draft report before issuing the final version, and this is your last opportunity to catch inaccuracies in the system description, management assertion, or control listings. Read every section against your original scope documentation and flag anything that misrepresents your environment. The AICPA SOC 2 guide requires your management assertion to be accurate and complete, so errors here carry real liability that you cannot correct after the report is issued.

Pay particular attention to the description of your subservice organizations and complementary user entity controls, since auditors sometimes simplify these sections in ways that leave coverage gaps. Once you sign off, the report is final, so treat the draft review with the same rigor you brought to evidence collection.

Keep SOC 2 useful after the report date

Your SOC 2 report has a date on it, but the work that produced it doesn't stop there. The AICPA SOC 2 guide expects your controls to operate continuously, not just during an observation window, so treat your report as a baseline rather than a finish line. Review your control inventory quarterly, update your risk assessment when your system changes, and add new controls before gaps appear rather than after your auditor flags them.

Compliance becomes a real business asset when you maintain it actively. Share your report with prospective customers early in the sales process, address every exception from your last audit before it carries into the next observation period, and keep your evidence repository current so your next Type II engagement starts clean instead of scrambling. If your healthcare application needs SMART on FHIR integration built on SOC 2 Type II infrastructure, SoFaaS handles the compliance foundation so your team can focus on building.