How to Prepare for a SOC 2 Audit: Scope, Controls, Evidence

You landed a major health system contract, but there's a catch. They need your SOC 2 report before you can go live. Now you're staring at requirements you barely understand, wondering how to document controls you're not sure you have, and trying to figure out what evidence an auditor actually wants. The stakes are high. Miss something critical, and you could delay the contract or fail the audit entirely.

The good news is that SOC 2 preparation follows a predictable pattern. You don't need a compliance team or unlimited budget. You need a clear scope, the right security controls in place, organized evidence, and a plan to work effectively with your auditor. Get these four elements right, and you'll move through the audit process with confidence instead of chaos.

This guide walks you through each step of preparing for your SOC 2 audit. You'll learn how to define your audit scope without overcommitting, build a control set that maps to SOC 2 requirements, collect the evidence your auditor needs, and maintain compliance after you pass. By the end, you'll have a roadmap that takes you from first conversation with an auditor to your final report.

What SOC 2 is and why it matters

SOC 2 is an audit framework that verifies how your organization protects customer data. The American Institute of CPAs (AICPA) created this standard specifically for service organizations that handle sensitive information on behalf of their clients. When you pass a SOC 2 audit, an independent auditor confirms that your security controls meet specific criteria and operate as documented.

The five Trust Services Criteria

SOC 2 evaluates your controls against five Trust Services Criteria: Security (mandatory for all audits), Availability, Processing Integrity, Confidentiality, and Privacy. You choose which criteria apply to your services beyond the required Security baseline. Most healthcare vendors pursue Security plus one or two additional criteria depending on what their customers require. The auditor tests whether your controls meet these criteria and whether they function consistently over time (Type II) or at a specific point (Type I).

Why health systems demand SOC 2 reports

Health systems require SOC 2 reports before they integrate third-party vendors into their EPIC EHR workflows. They need proof that your application won't create security vulnerabilities in their clinical environment. Without a SOC 2 report, you can't complete vendor assessments, won't pass procurement reviews, and ultimately can't close the contract. Understanding how to prepare for soc 2 audit becomes critical when these deals hang in the balance.

SOC 2 certification serves as your ticket into the healthcare market, not just a compliance checkbox.

The report you receive after passing validates your security posture to current and future customers. You can share it during sales cycles to accelerate procurement, demonstrate your commitment to data protection, and differentiate yourself from competitors who lack formal attestation. Each report remains valid for twelve months, which means you'll need to plan for annual audits to maintain your compliance status.

Step 1. Define your SOC 2 scope and goals

Your first move when learning how to prepare for soc 2 audit is deciding exactly what you're auditing. Scope determines which systems, processes, and criteria the auditor examines. Get this wrong, and you'll either audit too much (wasting money on unnecessary controls) or too little (failing to cover what customers actually need). Start by answering three questions: which report type satisfies your contracts, which Trust Services Criteria your customers require, and which systems handle customer data.

Choose Type I or Type II based on customer requirements

Type I reports evaluate whether your controls are properly designed at a specific point in time. The auditor reviews your policies, examines your control documentation, and confirms that your security measures align with SOC 2 requirements. This audit typically completes in four to eight weeks and costs significantly less than Type II. You might choose Type I if you're establishing initial compliance, proving you have the right controls in place before running them over time, or meeting a customer requirement that accepts this level of attestation.

Type II reports verify that your controls operate effectively over a defined period, usually six to twelve months. The auditor tests your controls repeatedly throughout this window to confirm consistent operation. Health systems generally require Type II because it demonstrates ongoing security practices rather than a snapshot. Budget for three to six months from engagement to final report delivery. Most healthcare vendors start with Type I to validate their approach, then pursue Type II for their production environments once they've refined their processes.

Select your Trust Services Criteria

Security is mandatory for every SOC 2 audit. Beyond this baseline, you choose additional criteria based on what your service handles and what your customers demand. Healthcare vendors commonly add Availability (proving uptime for clinical workflows), Confidentiality (protecting patient identifiers and clinical notes), or Privacy (demonstrating HIPAA alignment through SOC 2). Processing Integrity matters less for most EPIC integrations unless you perform calculations or transformations on clinical data.

Review your customer contracts and RFP requirements to identify which criteria appear most frequently. Most vendors find that Security plus Availability covers 80% of procurement requirements. Adding Privacy makes sense when you store or process protected health information beyond basic access logs. Skip criteria that don't apply to your service to keep audit costs manageable.

Document your system boundaries

Create a written scope document that defines which systems, applications, and infrastructure components fall inside your audit. List every service that processes, stores, or transmits customer data: your application servers, databases, authentication systems, monitoring tools, and third-party services with data access. Exclude internal systems that never touch customer information, like your marketing website or internal wiki.

Your scope document should specify:

Component	In Scope	Justification
Production FHIR API	Yes	Processes patient data from EPIC
Staging environment	No	Uses synthetic test data only
AWS RDS database	Yes	Stores customer PHI
Employee laptops	Yes	Access production systems
Marketing site	No	No customer data access

This boundary definition prevents scope creep during the audit and helps you focus control implementation on systems that actually matter for compliance. Share this document with your auditor during initial conversations to confirm alignment before you begin the formal engagement.

Step 2. Build your control set and policies

Once you've defined your scope, you need to implement the actual security controls that will be tested during your audit. Your control set consists of documented policies, technical configurations, and operational procedures that protect customer data according to SOC 2 requirements. The auditor will evaluate whether these controls exist, match your documentation, and operate consistently. Building this foundation correctly before the audit starts saves you from scrambling to backfill controls when the auditor requests evidence.

Map controls to your selected Trust Services Criteria

Start by identifying which specific controls address each Trust Services Criterion in your scope. Security requires controls for access management, encryption, monitoring, incident response, and risk assessment. Availability demands controls for system monitoring, disaster recovery, and capacity planning. Confidentiality needs data classification, secure transmission, and restricted access protocols. Create a control matrix that maps each requirement to your implementation.

Your control matrix should follow this structure:

Trust Services Criterion	Control Objective	Your Control	Evidence Type
Security (CC6.1)	Logical access restricted	MFA required for all production access	SSO logs, policy doc
Security (CC6.6)	Systems protected from threats	WAF blocks malicious traffic	AWS WAF logs
Availability (A1.2)	System availability monitored	PagerDuty alerts on downtime	Incident tickets

This matrix becomes your roadmap for implementation and evidence collection. Most healthcare vendors need 40 to 60 controls total across their chosen criteria. Reference the AICPA Trust Services Criteria documentation directly rather than relying on generic templates, since your controls must address your specific technology stack and workflows.

Document each control with enough detail that an auditor unfamiliar with your systems can understand exactly how it operates.

Write your information security policies

Your policies document how your organization commits to protecting customer data and what procedures employees follow to maintain security. You need a comprehensive information security policy as your foundation, plus supporting policies for specific control areas. Essential policy documents include acceptable use, access control, incident response, change management, data classification, vendor management, and disaster recovery.

Each policy should include these components: purpose statement, scope definition, roles and responsibilities, specific requirements, procedures for implementation, and review frequency. Keep policies between two and five pages so employees actually read them. Technical details belong in procedures or runbooks, not policies. Your incident response policy might state "security incidents must be contained within four hours," while your incident response procedure explains the specific steps your team follows to achieve that target.

Avoid copying generic policy templates without customization. The auditor will notice if your disaster recovery policy mentions "tape backups" when you run entirely in AWS. Write policies that reflect your actual infrastructure, tools, and processes. If you use GitHub for code repositories, your change management policy should reference pull requests and branch protection rules. If you host on AWS, your access control policy should mention IAM roles and security groups.

Implement technical controls in your infrastructure

Technical controls are the automated safeguards built into your systems that enforce your policies. These controls operate continuously without manual intervention and generate logs that serve as audit evidence. Priority technical controls for healthcare vendors include multi-factor authentication, encryption at rest and in transit, database access logging, web application firewalls, intrusion detection, and automated backup systems.

Configure each technical control to generate audit trails that prove operation. Enable CloudTrail for AWS API calls, configure your database to log all queries, turn on access logs for your load balancers, and route security events to a SIEM or log aggregation service. Store these logs for at least one year to cover your entire Type II audit period plus some buffer. When you learn how to prepare for soc 2 audit, you'll find that having 13 months of continuous logs eliminates most auditor concerns about gaps in your evidence.

Test your controls before the audit begins. Try accessing production without MFA to confirm it blocks you. Attempt to deploy code without approval to verify your change management controls work. Simulate a security incident to validate your detection and response procedures. Document these tests as evidence that your controls function as designed.

Step 3. Collect evidence and run a readiness check

Evidence collection separates organizations that pass their SOC 2 audit from those that scramble at the last minute. Your auditor will request proof that each control operates as documented, which means you need organized artifacts that demonstrate consistent security practices. Start collecting evidence at least three months before your planned audit to ensure you have enough data points for a Type II assessment. When you understand how to prepare for soc 2 audit, you realize that evidence quality matters more than evidence quantity.

Create an evidence repository

Build a centralized folder structure where you store all audit evidence before the auditor requests it. Organize your repository by control domain rather than by document type. Create folders for Access Control, Change Management, Monitoring, Incident Response, Vendor Management, and Risk Assessment. Within each folder, store the specific evidence that proves those controls work: log exports, screenshots, approved tickets, signed policies, and test results.

Your evidence repository should include these artifact types:

Evidence Type	What to Collect	Retention Period
Access logs	Authentication attempts, role changes, terminations	12 months minimum
Change records	Pull requests, deployment approvals, release notes	12 months minimum
Security scans	Vulnerability assessments, penetration test reports	Most recent quarterly
Training records	Completion certificates, attendance logs	All current employees
Vendor documents	SOC 2 reports, BAAs, security questionnaires	Current contracts only

Name your files with dates and clear descriptions so auditors can find what they need without asking follow-up questions. Use "2025-Q4-Vulnerability-Scan.pdf" instead of "scan.pdf". This specificity reduces back-and-forth during the audit and demonstrates organizational maturity.

Run a gap analysis against SOC 2 requirements

Compare your current controls against SOC 2 requirements for your chosen Trust Services Criteria to identify missing implementations or incomplete documentation. Walk through each control in your matrix and honestly assess whether you have the policy, the technical implementation, and the evidence that proves operation. Mark controls as Complete, Partial, or Missing based on your evaluation.

Partial implementations need immediate attention. You might have multi-factor authentication configured but missing documentation of your MFA policy. You could have backups running but no tested restore procedure. These gaps will appear as exceptions in your audit report if you don't address them before the auditor arrives. Focus remediation efforts on controls that protect customer data directly rather than administrative controls that matter less for your risk profile.

Document every gap with a specific remediation plan, owner assignment, and target completion date.

Conduct an internal readiness assessment

Schedule a mock audit where someone unfamiliar with your systems attempts to locate evidence for ten random controls from your matrix. This exercise reveals documentation gaps, unclear procedures, and missing artifacts before the real auditor finds them. Time how long it takes to produce each piece of evidence. Anything requiring more than five minutes to locate needs better organization or clearer file naming.

Test your technical controls by attempting to violate them. Try accessing production without proper authentication, deploying code without approval, or extracting data without logging. Successful violations indicate control weaknesses that need fixing before your audit begins. Document these tests as evidence of your quality assurance process and include the remediation steps you took after discovering each issue.

Step 4. Work with your auditor and stay compliant

Your relationship with your auditor determines how smoothly your SOC 2 audit progresses. You need an independent CPA firm licensed to perform SOC 2 audits and familiar with healthcare technology environments. Start conversations with auditors at least two months before you want your report, since their calendars fill quickly and you'll need time to align on scope, timeline, and deliverables. The auditor becomes your compliance partner, not an adversary looking to fail you.

Select your auditor based on healthcare experience

Look for auditors who have completed SOC 2 reports for companies similar to yours in size, technology stack, and industry. Ask potential firms how many EPIC integration vendors they've audited and whether they understand FHIR specifications and healthcare data flows. Request references from current clients and verify the auditor maintains their AICPA membership through the organization's database. Compare engagement letters from three firms to understand pricing structure, timeline commitments, and what deliverables you receive.

Schedule a scoping call where you present your system architecture, control matrix, and evidence repository. The auditor will confirm which controls they'll test, identify any obvious gaps, and provide a formal proposal with fixed pricing. Clarify expectations around response times, communication channels, and whether they conduct the audit on-site or remotely. Most healthcare vendor audits happen entirely virtual through shared document repositories and video calls.

Respond to evidence requests efficiently

Your auditor will send evidence requests throughout the engagement period. Create a shared folder where they can access your evidence repository directly rather than emailing individual files. Assign a single point of contact from your team who tracks all requests, coordinates responses, and ensures nothing falls through the cracks. Response speed directly affects your audit timeline. When you learn how to prepare for soc 2 audit, you discover that answering requests within 48 hours keeps the process moving smoothly.

Auditors typically request 80 to 120 pieces of evidence for a standard SOC 2 Type II audit across all control areas.

Expect clarification questions when your evidence doesn't clearly demonstrate control operation. The auditor might ask you to re-export logs with additional columns, provide screenshots showing configuration details, or explain procedures in writing. Treat these requests as opportunities to improve your documentation rather than criticism of your controls.

Build your continuous compliance program

Your SOC 2 report expires twelve months after issuance, which means you need ongoing compliance monitoring to maintain certification status. Schedule quarterly internal reviews where you verify controls still operate as documented, update policies to reflect infrastructure changes, and collect evidence for your next audit. Set calendar reminders for recurring compliance activities like annual penetration testing, security awareness training, and disaster recovery drills.

Track control changes in a shared document that logs modifications to policies, infrastructure, or procedures. This change log becomes evidence that you maintain your security posture between audits and helps your auditor understand what shifted since your last assessment.

Bring your SOC 2 program together

Learning how to prepare for soc 2 audit gives you the framework to secure health system contracts without derailing your roadmap. You now understand that success requires clear scope definition, controls that match your actual infrastructure, organized evidence collection, and consistent execution over time. Start with the scope that covers your production environment, implement controls that protect customer data, and build documentation habits that make audits routine rather than exceptional events.

Your SOC 2 report becomes one component of your healthcare go-to-market strategy, not the final destination. Health systems want more than attestation reports. They need vendors who can integrate seamlessly into clinical workflows, deploy quickly, and maintain security without introducing operational overhead. The compliance work you complete for SOC 2 demonstrates that your organization takes security seriously and operates with the maturity level healthcare customers demand.

Building SMART on FHIR applications for EPIC integration requires the same attention to detail and systematic approach that makes SOC 2 audits successful. Focus your engineering resources on your core product while meeting the integration and compliance requirements that unlock health system contracts.