SaaS Renewal With a Type I Report and a Residency Mismatch
Meridian Retail uses a marketing-analytics SaaS platform to segment its 200,000 customers by purchase history and send campaigns. Data sent to the vendor: name, email, postcode, order history and loyalty tier - no payment card data and no government identifiers. The vendor's security pack contains a SOC 2 Type I report covering the security and availability principles, dated eight months ago, with no confidentiality or privacy criteria; no penetration-test summary; and a subprocessor list showing hosting in two countries, one of which is outside the region where Meridian's privacy notice says data is stored. The master agreement auto-renews in 30 days and contains no breach-notification timeline, no security obligations and no audit right. The vendor's sales team says the SOC 2 report 'covers everything' and offers a 99.9% uptime SLA as a substitute. Meridian's legal counsel has asked security for a recommendation before the renewal.
1. Recommend: approve, approve with conditions, or reject. Justify against the data actually being processed.
Read the worked answer
Approve with conditions. An outright rejection is disproportionate to the data: name, email, postcode, order history and loyalty tier - no card data, no government identifiers. But 200,000 data subjects, plus the ability to infer sensitive attributes from purchase patterns, puts this above low sensitivity and above a click-through approval.
Conditions, in priority order:
- Resolve the residency mismatch before further data is sent. Data is hosted outside the region your privacy notice names. That is a compliance and trust issue independent of security, and it is the one item that can stop the processing regardless of the vendor's controls. Either move hosting or amend the notice and put the correct transfer mechanism in place - legal owns this decision.
- Security addendum as a condition of renewal: breach notification within 24-72 hours of discovery, specific security obligations, annual audit or evidence rights, subprocessor change notification, deletion/return with certification on exit.
- Data minimisation: test whether postcode and full order history are actually needed for segmentation. Hashing identifiers or sending aggregated segments reduces exposure with no loss of marketing value in most cases.
- Restrict the integration to a named field set and forbid free-text fields that staff could populate with anything.
- Re-review at 12 months or next renewal against a Type II report.
The business owner should sign the residual-risk acceptance in writing; security recommends, the accountable business owner accepts.
2. What specific evidence would you request, and how much weight should a SOC 2 Type I report carry?
Read the worked answer
Evidence to request:
- SOC 2 Type II covering a period (6-12 months), including the confidentiality principle, plus a bridge letter for the gap since the Type I date.
- Penetration-test attestation letter: scope, date, counts of critical and high findings, and remediation evidence. The full report with exploit detail is commonly refused and you do not need it.
- Subprocessor list with hosting regions and the transfer mechanism for each.
- Encryption at rest and in transit, and who owns key management.
- Access control for administrative and support staff (MFA, least privilege, session logging).
- Vulnerability management SLAs and patch cadence; backup and DR with stated RTO/RPO.
- The vendor's incident notification commitments and recent history.
- A DPA where personal data is processed.
Weight of a Type I: it is a point-in-time description of controls at a date. It tells you controls were designed and existed on that day - not that they operated effectively over a period. It is a legitimate starting point because an independent auditor was involved, but the missing confidentiality principle is precisely the one that matters for a processor holding a customer list. The absence of a Type II means change management, monitoring and operating effectiveness are simply untested. Read the system description too: SOC 2 scope is chosen by the vendor, so check what is excluded - the analytics environment, offshore support staff access, and the subprocessors often are.
3. Which contract changes matter most from a security standpoint, and what do you do about the cross-border storage discrepancy?
Read the worked answer
Contract, in priority order:
- Breach notification: timeline from discovery (24-72 hours), who is notified, what content, who bears notification cost.
- Security schedule with specific, testable obligations and an annual evidence right - audit rights are weak without defined controls.
- Audit or assessment right: on-site with notice, or via an acceptable independent report.
- Subprocessor approval and prior notification, with flow-down of the same obligations.
- Data return and certified deletion on termination.
- Liability: security incidents should not sit under a cap equal to 12 months of fees; push for a separate super-cap with counsel.
- Reject the SLA as a security substitute. 99.9% uptime is about availability; it says nothing about confidentiality and is not a control.
Cross-border storage: do not take the vendor's word or the sales team's reassurance. Put the hosting regions in writing - the subprocessor list is evidence - and map them against the privacy notice and whatever transfer mechanism applies (adequacy decision, SCCs). Inform legal and the privacy owner; the remediation is either architectural (move region) or documentary (amend notice and paper the transfer), and it must be chosen before more data flows.
Use the 30-day clock: renewal is your moment of maximum leverage. Seek an extension, and make the security addendum a condition of renewal rather than something negotiated after auto-renewal.