Single-Cluster SaaS Tenancy for PHI Claims Processing
A regional health insurer is migrating its claims adjudication platform to a SaaS offering. The vendor hosts all tenants in a single PostgreSQL cluster and isolates records with a tenant_id column enforced by application middleware; its documentation states that "row-level security is enforced at the application layer." Data is encrypted at rest with AES-256 using keys the vendor generates and stores in its own KMS; the insurer can neither import nor hold its own keys. The platform processes PHI for 2.3 million members and must satisfy HIPAA plus the insurer's internal requirement that PHI be logically segregated from other tenants. The vendor offers a "dedicated schema" tier at a 40% premium, contractually available only in its US-East region; the insurer's DR strategy requires a second region. A proof-of-concept is scheduled in six weeks, and the security team has asked you to decide whether the standard tier can be approved with compensating controls.
1. Evaluate the tenancy isolation model. What is the core architectural risk, and what evidence would you require before accepting it?
Read the worked answer
Core risk: isolation is a property of application code, not of the data store. A single missing WHERE tenant_id = ? predicate, an ORM bypass, or a SQL-injection path collapses the boundary between tenants. This is a single point of failure with no defense in depth: the database itself would happily return another tenant's rows.
Evidence to require before acceptance:
- Results of a penetration test that specifically targets cross-tenant object references and IDOR, not a generic web-app scan.
- A code-review or architecture attestation showing tenant scoping is enforced in a shared data-access layer, with tests that fail the build when a query omits the tenant predicate.
- Confirmation of whether database-native row-level security exists as a second layer; if not, ask why not.
- Incident history for cross-tenant exposure, and the vendor's breach-notification timeline.
Judgement: compensating controls (SIEM alerting on anomalous record-volume reads, contractual audit rights, cyber insurance) reduce detection time but do not prevent the defect. They are proportionate only if the risk owner formally accepts the residual exposure. The internal "logical segregation" requirement is arguably met on paper, but its reliability is the real question. For PHI at this scale, the dedicated-schema tier is the stronger architectural answer if the DR constraint can be renegotiated.
2. Assess the vendor-managed key model against the insurer's obligations. What options and trade-offs would you present?
Read the worked answer
What vendor-managed keys mean: the insurer cannot revoke the vendor's access to its own ciphertext, cannot crypto-shred on exit, and cannot independently attest key custody. Encryption at rest becomes a control the insurer must trust rather than operate. HIPAA does not mandate customer-held keys, so this is not automatically a compliance failure, but it may conflict with internal policy or state requirements and it weakens the exit strategy.
Options to present:
- Accept vendor keys with evidence - request the KMS subservice organization's SOC 2 or ISO 27001 report, key-rotation logs, separation-of-duties evidence, and contractual deletion attestation. Cheapest, weakest assurance.
- BYOK/HYOK - ask whether the dedicated tier supports customer-supplied key material. This restores revocation and crypto-shredding but adds operational burden: lost keys mean lost data, and the insurer must run its own key-management lifecycle.
- Dedicated schema plus BYOK - best assurance, but the 40% premium and single-region constraint collide with the DR requirement.
Judgement: do not let the regional constraint silently drive the security decision. Escalate the trade-off - multi-region DR versus key control versus tenancy isolation - to the risk owner as an explicit decision with documented rationale, rather than approving the standard tier by default because the PoC date is fixed.
3. The vendor's SOC 2 Type II report covers the platform but explicitly carves out the KMS subservice organization. How does that affect your approval decision?
Read the worked answer
What the carve-out means: the auditor did not test controls at the KMS provider. The encryption control the insurer is relying on is therefore only half-evidenced - the platform's use of the KMS is in scope, but key generation, storage, rotation, and access control at the subservice organization are not. A carve-out is not automatically disqualifying, but it shifts the burden to the insurer.
Request: the KMS provider's own SOC 2 Type II or ISO 27001 certificate, a bridge letter covering the gap between the report period and today, and the vendor's complementary subservice organization controls (CSOCs) mapping showing how it monitors that provider. Also ask for the vendor's vendor-management evidence: contract flow-down of security obligations, right to audit, and notification of subprocessor changes.
If unavailable: treat the encryption control as unverified rather than failed. Options are to downgrade reliance, add independent evidence (configuration exports, key-policy screenshots, rotation tickets), or require the dedicated tier where a different KMS arrangement may apply. Document the gap in the risk register and reflect it in the approval conditions. The mistake to avoid is citing the SOC 2 as blanket assurance when the report itself says the most security-critical component was excluded.