Customer story · Healthcare SaaS

Nine months to a SOC 2 Type 2, with the auditor working inside the workspace.

Northwind sells analytics to hospital systems, so every enterprise deal ended with the same two questions: where is your SOC 2, and how do you handle PHI. They had answers in a shared drive and a spreadsheet, and no way to prove either was current. This is what the next nine months looked like.

Northwind Health Analytics51–200 employeesCloud-only, AWS
77%ready

Readiness over 120 days

26%to77%

Recorded nightly, shown to the assessor.

SOC 2 Type 2HIPAA Security Rule

About this story. Northwind Health Analytics is the company inside our demo environment, not a named customer. The steps, screens, roles and numbers on this page are exactly what you will see in a demo, and the gaps are real gaps the product surfaces. The company is not, and neither is its assessor, Brackenridge Assurance LLP, nor any person named here. When a customer agrees to be named, this page will tell their story instead, and say so.

The question that decided the purchase

"What happens when the auditor asks for something we don't have?" Not whether the tool tracks controls — every tool tracks controls. Whether it would tell them about the hole before the assessor found it, and whether handing the assessor a login would expose more than it proved.

Frameworks
SOC 2 and HIPAA together
Controls in scope
77 of 81
Evidence on file
27 artifacts
Audit
SOC 2 Type 2, FY26 window
Assessor
Brackenridge Assurance LLP
Auditor access
Read-only login, no billable seat

What happened

Nine months, in the order they happened.

  1. Month 1

    Two frameworks, one control set, and a number nobody liked.

    Northwind enabled SOC 2 and HIPAA on the same afternoon. AuditSquire built the control set behind both: 77 of the 81 unified controls map to those two frameworks. Two were marked not applicable, each with a written justification, because Northwind runs no on-premise infrastructure and the database trigger will not accept "N/A" without a reason.

    The first readiness number was 26 percent. It was low because the product refused to credit anything without current evidence attached. A shared drive full of screenshots and a spreadsheet of "done" columns did not count. That was uncomfortable, and it was the point: it was the same number a Type 2 would have produced.

  2. Months 2–4

    Working the gap list instead of the checklist.

    The dashboard ranked every unsatisfied control by how many in-scope requirements it unblocked. Periodic access reviews sat at the top: one control, fourteen requirements across both frameworks. Dana Whitfield, who runs security and compliance, assigned owners to the top ten and turned them into tasks in one click.

    Six people owned controls. Priya in platform engineering carried the technical ones; Tom in IT operations owned logging and endpoints; Sarah in people operations owned onboarding, offboarding and training. Each saw only their slice. Nina in customer success, with no compliance job at all, saw two tasks and three policies to acknowledge and nothing else. Nobody needed a training session to find their part.

    The readiness line climbed 51 points in 120 days. Nightly snapshots recorded every step, which mattered later: the auditor asked how the program had progressed over the observation window, and the answer was a chart rather than a recollection.

  3. Month 6

    The evidence that quietly stopped counting.

    Three artifacts lapsed mid-window: the annual penetration test, the semi-annual firewall rule review, and the Q1 access review. None of them had been deleted or forgotten. They had simply aged past the shelf life Northwind set for evidence, and the product moved each control from satisfied to evidence expired the night it happened.

    The "evidence expiring" card had been warning about all three for weeks. Two were re-collected before fieldwork. The penetration test was not, and the control was reported as a gap to the assessor rather than hidden behind a stale PDF. That was the outcome Northwind had bought the product for: it made the hole visible on their timeline, not the auditor's.

  4. Month 9

    Fieldwork with the assessor inside, not in an inbox.

    Ray Coleman, the lead auditor at Brackenridge, was invited with the auditor role. Read-only across the whole workspace, no ability to change a status or edit a policy, and no billable seat. He raised evidence requests inside the audit record; the owning control's person answered by attaching evidence already on file, and the request closed with a note of who responded and when.

    Before kickoff, Northwind exported the readiness report. It lists every framework percentage, every control's health, the top gaps and the policy validation summary, with each figure traceable to the screen it came from. The assessor started from the same document the company had been staring at for months, so there were no surprises in either direction.

Fieldwork

What the assessor was given.

A login, not a folder. Here is what that login could and could not do.

Read-only, enforced in the database

The auditor role cannot write anything except an evidence request. That is a row-level policy in Postgres, not a hidden button, so an assessor cannot accidentally change what they are assessing.

Evidence requests with a paper trail

Each request names the requirement, the person who raised it, the person who answered, the evidence attached and the date. The audit record becomes the index of what was asked and what was shown.

The activity log

Every approval, status change and evidence upload over the observation window is timestamped with the person who did it. When the assessor asked who approved the access control policy and when, it was one row.

The readiness report as the leave-behind

Printable, high contrast, no interactivity. Written to be read by an assessor rather than a dashboard user, and handed over at kickoff so both sides work from the same numbers.

How that access is enforced, and who else can see a workspace, is on the security and trust page.

The gaps

What went wrong, and what the product did about it.

A story with no gaps is a brochure. These are the three that surfaced, and where each one stood when the assessor arrived.

A policy went past its review date

What surfaced
The incident response policy was approved, owned and acknowledged, and eleven days overdue for its annual review. Validation scored it as failed outright, because an out-of-cycle policy is not evidence at any level of completeness.
What happened next
The owner reviewed it, the approval was re-recorded, and the failure cleared the same day. Without the lifecycle check it would have been found by the assessor, who checks review dates first.

Two vendors had no current SOC 2 report

What surfaced
The vendor register flagged Snowflake and Twilio, both handling PHI or contact data, as missing a current report for the third-party risk control.
What happened next
Marcus, who owns vendor management, requested both reports and attached them as evidence. The control moved to satisfied and the assessor was shown the register rather than told about it.

The penetration test was not re-run in time

What surfaced
The prior test aged out of its shelf life six weeks before fieldwork. It was on the expiring-evidence card the whole time; the vendor could not schedule the re-test before the window closed.
What happened next
It was reported as an open gap with a scheduled remediation task attached. That is the honest state, and it is what the product is for: the company knew, on its own timeline, what the assessor was going to find.

See the same walkthrough with your frameworks.

Thirty minutes. We enable the standards you are working toward, show you your first gap list, and hand you the readiness report your auditor will ask for.