SOC 2 in 90 Days: How a Healthcare SaaS Passed Its First Audit

Representative engagement. Client details anonymized and specifics changed under NDA.

The email that started this was not from a security team. It was forwarded by a founder, three lines long, with the subject “we might lose the deal.” A healthcare SaaS company of about 40 people had an enterprise contract sitting in legal, and the buyer’s vendor-risk group had replied with a single condition: provide a SOC 2 report before go-live. The company did not have one. They had 90 days before the renewal window closed.

That is how most SOC 2 readiness work actually begins. Not with a security team deciding to mature, but with a customer holding a contract until you prove you take security seriously. Ninety days is genuinely tight, but it is workable for a Type II with a short observation window if you move fast and stop treating the audit as a paperwork drill. The trap is scope. Teams routinely burn the first month arguing about what to include instead of collecting evidence.

Here is what we did, what the gap assessment turned up, and the handful of changes that let them pass.

Key takeaways

• SOC 2 readiness is about proving controls operate over time, not writing policies the week before the auditor arrives. Start the evidence clock on day one.
• For a Type II on a short window, the fastest route is a tight scope: the production system that touches customer data, and nothing else.
• The gaps that fail first audits are mundane. No access reviews, no offboarding proof, logging that runs but nobody reads. Not exotic attacks.
• Wire evidence collection into identity, cloud config, and ticketing so controls generate their own proof instead of relying on screenshots.
• A readiness assessment before the audit turns “we hope this passes” into a known list of gaps with owners and dates.

What SOC 2 actually asks of a company

SOC 2 is an attestation report produced by a licensed CPA firm against the AICPA Trust Services Criteria. Every SOC 2 covers Security, known as the common criteria, and you optionally add Availability, Confidentiality, Processing Integrity, or Privacy. A Type I report says your controls were designed correctly on one specific date. A Type II says they actually operated over a period, usually three to twelve months. Enterprise buyers almost always want Type II, because a design-only snapshot proves nothing about how you behave day to day.

For a healthcare SaaS, Confidentiality is usually in scope, and there is a second reality stacked on top: if you touch protected health information, HIPAA still applies. SOC 2 is not a HIPAA substitute. In this engagement the two overlapped enough that we mapped each control once and satisfied both requirements wherever they lined up, which spared the team from doing the same work twice.

Here is the part people miss. SOC 2 does not hand you a list of controls to implement. There is no master checklist from the AICPA. You define your own controls against the criteria, and the auditor tests whether those controls exist and work. That freedom is exactly why unguided teams stall out.

The 90-day plan we ran

We split the window into three phases and started the evidence clock immediately, rather than waiting for the policy set to be perfect.

Days 1 to 20: scope, gap assessment, and the evidence clock

First we locked scope, and it was a fight. The client’s instinct was to include everything: the marketing site, an internal analytics tool, three separate AWS accounts. We cut it to the single production account that hosts the application and processes customer data. Scope creep is the most expensive mistake in a first audit. Every system you pull in multiplies the evidence you have to produce and the controls you have to keep running for the whole observation period.

Then the readiness assessment. We walked every common-criteria control and marked it present, partial, or missing. The output was a plain gap register with one owner and one due date per row, not a 60-page report that nobody opens after the kickoff.

Days 20 to 55: remediation

This is where the real work happens. We stood up the missing controls, wired evidence collection into the tools the team already used, and got the observation window running so the auditor would have genuine operating history to sample rather than a week of hastily faked activity.

Days 55 to 90: operate, collect, and the audit

Controls ran while evidence piled up on its own. We did an internal dry run against the auditor’s expected request list, fixed the two items that were still thin, and handed a clean evidence package to the CPA firm.

What we found in the gap assessment

None of the serious gaps were glamorous. That is the pattern on nearly every first-time SOC 2 readiness engagement we run. What fails audits is operational hygiene, not zero-days.

No user access reviews. Nobody had ever sat down and asked who could reach production and whether they still needed it. Two former contractors still had live IAM users, one of them almost a year after the contract ended. CC6.1 and CC6.2 both care about this, and access is one of the first things an auditor samples.

Offboarding was informal. When someone left, the laptop came back but access got revoked “whenever someone remembered.” No ticket, no timestamp, no proof. An auditor does not accept “we always do it.” They pick a leaver from the HR roster and ask you to show the deprovisioning record with a date on it.

Logging was on but unwatched. CloudTrail was enabled, which teams love to point at. The logs landed in an S3 bucket that no human and no alert ever touched. Detection you never look at is not a control. It is storage with a monthly bill.

No formal change management. Engineers merged and deployed through peer-reviewed pull requests in GitHub, which was actually solid practice. But nothing in writing tied that practice to a control, so from the auditor’s chair it did not exist.

Vendor management was a spreadsheet last touched in 2023. A healthcare SaaS leans on subprocessors, and the criteria expect you to track them and keep tabs on their security posture.

Look at how many of these are documentation and proof problems rather than “we do not do this at all.” A large share of SOC 2 readiness is making good-but-invisible practices legible to someone who was not in the room.

How we closed the gaps without slowing engineering

The rule we set with the client was blunt: automate evidence so a control produces its own proof, and only fall back to a manual process where automation is not worth the effort.

For identity and access, we moved everyone behind SSO, enforced MFA, and set a recurring quarterly access review with the output stored as a dated artifact instead of a Slack thread that scrolls into oblivion. For deprovisioning, we tied offboarding to a ticket template, so every departure now generates a timestamped record of access removal. That one change converted an unprovable control into an auditable one.

For logging and monitoring we did not go buy a large platform. We routed CloudTrail and application logs into a destination with alerting on the events that matter: root account use, IAM policy changes, and failed console logins past a threshold. Then we documented who reviews alerts and how often. Here is how it read in their control matrix:

Control ID : CC7.2
Statement  : Security events are logged and monitored; anomalies alert the on-call.
Evidence   : CloudTrail -> log sink; alert rules (root use, IAM change, failed logins);
             on-call rotation; sample alert + triage ticket from the observation window.
Frequency  : Continuous; reviewed weekly.
Owner      : Head of Engineering

For change management we changed nothing about how engineers worked. We wrote the policy to match the reality already in place: pull request, required review, CI checks, protected main branch. Then we used the existing GitHub history as evidence. Aligning the document to the practice is far faster, and far more honest, than bolting on a new process the week before the auditor shows up.

Policies came last. We wrote the security, access control, incident response, change management, and vendor management policies to describe controls that were already operating. Policies written ahead of practice describe a fantasy, and auditors are very good at spotting the gap between a shiny policy and what the logs actually say happened.

The outcome

They passed. The CPA firm issued a SOC 2 Type II report with no exceptions in the common-criteria scope, which is a strong result for a first audit. Framed as a representative outcome for a company this size: the readiness assessment surfaced roughly a dozen meaningful gaps, most were closed inside the remediation phase, and the enterprise deal that kicked the whole thing off reached go-live.

The more durable win was quieter. Evidence collection became a background process. Access reviews, offboarding records, and alert triage now generate their own artifacts, so the next audit period is mostly maintenance instead of another 90-day scramble. That is the real line between chasing a report and running a security program.

How CyberXplore helps

We run SOC 2 readiness the way we ran this one. Scope tightly, assess honestly, close the gaps auditors actually test, and wire in evidence so your controls prove themselves. We map controls to the Trust Services Criteria, run the pre-audit dry run against the request list, and work alongside your CPA firm so nothing ambushes you on the way to the report. If you have a buyer waiting on a report or a deadline you did not choose, get a quote and we will tell you honestly whether your window is realistic and what it takes to hit it.

FAQ

Can you really get SOC 2 in 90 days?

You can reach SOC 2 readiness and complete a Type II with a short observation window in roughly 90 days if scope is tight and you start collecting evidence right away. The constraint is the observation period, since Type II requires controls to operate over time and you cannot compress that to zero. Some CPA firms will not observe under three months, so a common fallback is a Type I first to satisfy an urgent buyer, followed by a Type II period.

What is the difference between SOC 2 Type I and Type II?

Type I attests that your controls are designed appropriately on a single date. Type II attests that those controls actually operated effectively over a period, typically three to twelve months. Enterprise buyers usually require Type II because it proves behavior over time, not just intent on one day.

Does SOC 2 cover HIPAA for a healthcare SaaS?

No. SOC 2 and HIPAA are separate. SOC 2 is an attestation against the AICPA Trust Services Criteria, while HIPAA is a US regulation covering protected health information. They overlap on many security controls, so you can map work to satisfy both, but a SOC 2 report does not make you HIPAA compliant on its own.

Which Trust Services Criteria should we include?

Every SOC 2 must include Security, the common criteria. You add Availability, Confidentiality, Processing Integrity, or Privacy based on what you promise customers. Most SaaS companies start with Security plus Availability and Confidentiality, and add Privacy only when they make specific privacy commitments.

What causes companies to fail their first audit?

Almost never exotic security failures. It is missing evidence: no access reviews, no dated offboarding records, logging that nobody monitors, and policies that describe a process the team does not actually follow. A readiness assessment before the auditor arrives is the cheapest way to find those gaps while you still have time to fix them.

How much of this can be automated?

A large share. Identity and access evidence, cloud configuration checks, change history, and log monitoring can all generate their own artifacts on a schedule. Automating evidence collection is what turns SOC 2 from a recurring fire drill into a maintenance task, and it is the single change that pays off most across future audit periods.