Conditional Approval of a SaaS Vendor With SOC 2 Exceptions
BrightPath Clinics wants to deploy a SaaS patient-scheduling platform that will store names, dates of birth, insurance IDs, and appointment notes for 400,000 patients. The vendor provided a SOC 2 Type II report with three exceptions: access reviews were not performed for two quarters, encryption at rest was not enabled for a logging bucket, and incident notification relies on the customer noticing. The contract lacks a right-to-audit clause and names a subprocessor in another country. Launch is in 45 days, and the business sponsor says the vendor is the only one that meets clinical workflow requirements. BrightPath is subject to HIPAA and state breach notification. The security team has one week to make a recommendation.
1. What recommendation should the security team make: approve, conditionally approve, or reject? Justify the decision.
Read the worked answer
I would recommend conditional approval only if the business accepts a dated remediation plan and the contract is amended. Rejecting outright may be unrealistic because the vendor is the only fit and 45 days is short, but unconditional approval ignores the exceptions. The access-review gap is significant because it can leave terminated or excessive access in place; the logging-bucket encryption gap is narrower but still relevant for sensitive operational data; and incident notification by customer discovery is unacceptable for a HIPAA-related service. The decision should be framed as risk acceptance with conditions: contractual notification timelines, evidence of access-review remediation, encryption of the logging bucket before go-live, and a subprocessor assessment. If the vendor refuses the contract changes and cannot show remediation, the recommendation should move to reject because BrightPath cannot detect or control a breach.
2. What compensating controls and contract terms should be in place before go-live?
Read the worked answer
Before go-live I would require a signed business associate agreement, a 24-hour security incident notification clause, a right to audit or accept an independent audit report plus bridge letter, and approval rights over new subprocessors. Technically, I would require field-level encryption or tokenisation for insurance IDs, restrict access to appointment notes, enable CASB or SaaS security posture monitoring, enforce SSO with phishing-resistant MFA, and require vendor access reviews quarterly with evidence. The logging bucket must be encrypted and access-logged. Network access should be limited to the vendor’s documented endpoints. I would also require data return and destruction terms. These controls reduce the likelihood and impact of the exceptions without pretending the vendor’s SOC 2 report is clean.
3. What ongoing monitoring and exit plan should BrightPath require after launch?
Read the worked answer
Ongoing monitoring should include annual SOC 2 review with a bridge letter for the gap period, quarterly access-review attestations, notification of material changes or subprocessor additions, and an annual security questionnaire. I would track vendor incident response times and any deviations from the contract. Internally, I would monitor CASB alerts, unusual download volumes, and SSO anomalies. The exit plan should define data export formats, retention periods, secure destruction, transition assistance, and a tested restore path. Because patient scheduling is operationally critical, the plan should also cover a temporary manual fallback and a maximum tolerable outage. A vendor risk decision is not finished at contract signature; it needs evidence that the conditions are being met and a way out if they are not.