16.3 Cloud Legal, Regulatory, and Third-Party Requirements
Key Takeaways
- SSCP knowledge area 7.4 continues with legal and regulatory concerns: privacy, surveillance, data ownership, jurisdiction, eDiscovery, and shadow information technology. The region you click in a console is not automatically the law that applies.
- A Software as a Service vendor in another country can be subject to that country's lawful-access and surveillance rules; contracts must state data location, subprocessors, and how eDiscovery holds are executed.
- Data storage, processing, and transmission still require archiving, backup, recovery, and resilience you can test — snapshots in the provider console are not a tested recovery plan.
- Third-party and outsourcing requirements on the outline are the service-level agreement plus data portability, privacy, destruction, and auditing. Paying the invoice is not an audit right.
- Shadow IT SaaS is unsanctioned processing. Discover it, classify the data that already left, and replace it with a contracted alternative; do not treat it as the provider's legal problem merely because it is Software as a Service.
Legal and regulatory concerns are still 7.4 operations
Knowledge area 7.4 continues past models into legal and regulatory concerns (privacy, surveillance, data ownership, jurisdiction, eDiscovery, shadow information technology (IT)), data storage, processing, and transmission (archiving, backup, recovery, resilience), and third-party / outsourcing requirements (service-level agreement (SLA), data portability / privacy / destruction / auditing). Domain 3 already taught jurisdiction and privacy as risk concepts. Here the SSCP expects you to configure and contract cloud so those concerns are not theater.
| Concern | What it means in cloud operations | SSCP tell |
|---|---|---|
| Privacy | Lawful processing of personally identifiable information (PII) and protected health information (PHI): minimization, access, retention, individual rights | Tenant sharing links that make a chart world-readable are a privacy failure, not a hypervisor failure |
| Surveillance / lawful access | Provider or government access under the law of the provider's country or the region's | A foreign SaaS mailbox may be subject to that country's production orders even if your headquarters is elsewhere |
| Data ownership | Who owns the content versus who operates the platform; what happens to derived logs and backups | The contract must say the customer owns the records and the provider is a processor or custodian |
| Jurisdiction | Which courts and regulators can compel the provider or you | Storage region, provider incorporation, and subprocessor locations can differ |
| eDiscovery | Preserving and producing electronically stored information for litigation or investigation | You need export, hold, and logging features — not a promise to turn off deletion someday |
| Shadow IT | Unsanctioned cloud services staff adopt without procurement or security review | Marketing's foreign survey tool with member emails is still your processing |
Scenario (SaaS vendor in another country). Finance wants a SaaS accounts-payable tool whose operator is incorporated abroad. The demo is excellent. The data-processing addendum is vague on region and silent on subprocessors.
- Jurisdiction and surveillance. Records may be stored in Region A, supported from Country B, and backed up in Country C. A production order against the vendor in Country B is not the same as a U.S. or local discovery process you already know. If the stem asks what you must establish before go-live, the answer is data location, lawful-access terms, and which law governs — not a stronger local guest antivirus.
- Data ownership. The contract should state that invoice images and vendor bank details remain the clinic's, that the provider processes them on instruction, and that derived analytics are not the provider's product to resell.
- Privacy. If the tool will hold tax identifiers, execute a processing agreement that matches the applicable privacy law (for U.S. health data that often also means Health Insurance Portability and Accountability Act (HIPAA) business-associate terms when a vendor handles PHI — only when that statute actually applies). Do not invent a statute the stem did not give you; do name privacy, ownership, and location.
- eDiscovery. Litigation hold must freeze relevant objects in that tenant, including mail-like messages the tool stores. If the vendor cannot place a hold or export in a forensically useful way, that is a 7.4 gap, not a feature request for later.
- Operations follow-through. Restrict the tenant to an approved region, turn off unsanctioned sharing, federate identity so joiner-mover-leaver still works, and log administration. Shared responsibility did not move those jobs to the vendor's country.
Exam trap: answering that because the product is SaaS, legal issues are the provider's, or that choosing a nearby flag in the console equals jurisdiction.
Shadow IT is unsanctioned processing
Shadow IT is the outline's explicit example because cloud makes it easy. A department credit card and a browser bypass procurement, identity, backup, and the data loss prevention (DLP) stack you spent Domain 6 and 7.2 building.
Scenario (shadow IT SaaS). Marketing launches a campaign using a free foreign survey SaaS. Staff paste member emails and appointment dates into the form. There is no business-associate or processing agreement, no MFA tied to your identity provider, and no export path you control. This is shadow IT, not community cloud and not approved SaaS.
Operational response:
- Discover — cloud access security broker (CASB), firewall or secure web gateway logs, expense reports, DNS, and identity-provider unsanctioned OAuth grants. You cannot contract what you cannot see.
- Contain the data path — block the unsanctioned domain where policy allows, revoke OAuth tokens, and stop new posts of member data.
- Classify what already left — if PII or PHI is in the foreign tenant, that is a privacy and possibly incident-response problem (knowledge area 4.1), not a lecture.
- Replace — offer a sanctioned survey tool under an SLA that covers privacy, location, destruction, and audit. Awareness training without a sanctioned alternative just drives the next card to another brand.
- Do not call this the provider's legal problem merely because the logo says SaaS. You had no contract. The processing is yours.
Data storage, processing, and transmission
The outline's examples are archiving, backup, recovery, and resilience. Cloud does not erase those jobs; it changes where the bits live.
| Activity | Cloud meaning | Failure mode |
|---|---|---|
| Archiving | Long-term retention in cheaper, often immutable or write-once storage, with legal retention clocks | Leaving archives in the same writable bucket as production so ransomware encrypts both |
| Backup | Copies you can restore, preferably cross-account or cross-region, with separate credentials | Snapshots that live on the same disk pool, or backups the attacker can delete with the same administrator role |
| Recovery | Tested restore that meets recovery time objective (RTO) and recovery point objective (RPO) from Domain 4 | Never-restored backups; identity still broken after the disks return |
| Resilience | Availability design: multi-zone, failover, immutable infrastructure, documented degraded modes | Assuming the provider's published region availability is your application RTO |
| Transmission | Encryption in transit, approved interconnects, and DLP on egress to unsanctioned SaaS | Cleartext database replication or personal file-sync of work data |
For IaaS you design backup jobs, snapshot policy, and restore tests. For SaaS you must still ask where backups live, how long, how you restore a single mailbox or record, and whether you can take an export that is yours if the vendor fails. Resilience is not the same as backup: a multi-zone SaaS that loses your tenant configuration still needs a documented recovery of identity and data.
Third-party and outsourcing: SLA, portability, privacy, destruction, audit
When you outsource a platform you do not outsource accountability. The outline's examples are the SLA and data portability / privacy / destruction / auditing.
| Clause | What good looks like | Exam trap |
|---|---|---|
| SLA | Measurable availability, support, security-event notice, and consequences — plus the data clauses below | Uptime percentage with silence on security incidents |
| Portability | Export in usable formats on a stated schedule and at contract end | Proprietary dump you cannot load elsewhere |
| Privacy | Roles (controller / processor or equivalent), subprocessors, breach notice, no secondary use | Privacy policy URL instead of a signed processing term |
| Destruction | Certified deletion or cryptographic shred of production, backups, and archives at end of contract or on request, with a timeline | We will delete someday; backups are excluded forever |
| Auditing | Right to review independent reports (for example SOC 2 or ISO/IEC 27001 attestations) and, where justified, targeted audit or evidence | Paying the invoice counts as the audit |
Destruction must include copies you cannot see: replicas, backups, and support snapshots. Crypto-shredding (destroying keys) is a legitimate method when physical media is multi-tenant, provided keys were unique and managed. A certificate of destruction that excludes backups is incomplete.
Portability is how you avoid lock-in during an incident or a vendor failure. If you cannot export identity mappings and records, your documented recovery is fiction.
Exam traps. Treating shadow IT as approved SaaS because the data is in a famous brand. Assuming a foreign vendor follows your courtroom's eDiscovery rules without a clause. Calling snapshots a tested recovery. Treating an uptime SLA as a privacy program. Skipping destruction of backups at offboarding.
When a CAT item names a SaaS vendor in another country, answer jurisdiction, ownership, privacy, and eDiscovery support — then SLA clauses for portability, destruction, and audit. When it names a department tool nobody contracted, answer shadow IT and discovery plus a sanctioned replacement.
Finance wants a Software as a Service accounts-payable tool whose operator is incorporated in another country. The data-processing addendum is silent on region, subprocessors, and litigation hold. What must the SSCP establish before go-live?
Marketing pastes member emails into a free foreign survey tool that was never contracted, has no federation to the clinic identity provider, and offers no export you control. What is this, and what should operations do first?
Which service-level agreement set matches SSCP knowledge area 7.4 third-party and outsourcing requirements when offboarding a cloud vendor?