The Shadow SaaS Rollout
Your 18-person marketing team signs up for a project-management SaaS using their corporate Google accounts and "Sign in with Google." The OAuth consent screen requested read access to all Drive files and calendar, and three people clicked through without reading it. No security review was performed and no data-processing agreement exists with the vendor. A shared Drive folder the team used as a staging area contains the unannounced Q3 earnings draft. The acceptable-use policy was last revised six years ago and does not mention cloud services. The procurement policy requires security review for new SaaS but has no enforcement mechanism. Nothing in policy addresses third-party OAuth grants. Legal wants a recommendation this afternoon.
1. Sequence your first four hours. What do you do first, and what do you deliberately not do?
Read the worked answer
Order matters because the evidence and the risk are both perishable.
- Capture the grant record before you revoke it (10 minutes, non-disruptive): Google Workspace audit log export for the OAuth token grant - app name, client ID, requesting scopes, granting user, timestamp, and the app's verified/trusted status. Revoking first destroys the cleanest record of what was authorised.
- Revoke the OAuth grant for all three users via admin API access control / app allowlisting. This is time-sensitive; scope is read-only and read has already had hours to run.
- Reduce exposure of the sensitive files: identify every copy of the earnings draft, confirm sharing permissions, and move them out of the team's broad-share staging folder to a restricted location. Do not delete - deletion destroys the record of who could see them.
- Interview the three users factually: did they upload anything, when, and did the tool sync or prompt a copy?
- Report facts, not conclusions, to Legal - scope granted, files in scope, users involved, times.
Deliberately not:
- Do not delete the app, the files, or the audit logs.
- Do not contact the vendor or notify the affected executives on your own initiative before Legal gives direction - external contact can create contractual or disclosure obligations you did not intend.
- Do not call it a breach in writing yet.
2. Is this an incident, a policy violation, or both - and what actually determines whether it becomes reportable?
Read the worked answer
It is unambiguously a policy violation. Whether it is an incident depends on facts you do not yet have.
- Violation: procurement policy required a review that did not happen. Confirmed, no investigation needed.
- Incident: requires unauthorised access to, or exposure of, data. An OAuth scope is a permission, not an access. "Read access to all Drive files" means the grant permits reading; it does not mean the vendor's servers read anything. Conflating scope with access is the error that turns an afternoon of work into a misdirected breach notification.
Reportability hinges on three things, in this order:
- Data classification of what was actually in scope - unannounced earnings information is material non-public information, which is a securities/insider-trading exposure, not a privacy one. Personal data (customer lists, employee data in the same Drive) imports GDPR/HIPAA/state-law clocks with fixed deadlines.
- Evidence of access - vendor-side session logs if obtainable, the app's sync behaviour, whether the tool copied files into its own tenant or reads on demand. If you cannot get evidence, you reason from the app's documented architecture and say so.
- Jurisdiction and contract - where the affected data subjects reside, and what the (absent) DPA would have required. Absence of a DPA is itself a finding.
Recommendation to Legal: classify as a suspected incident, hold the notification decision pending the access question, and start the GDPR-style 72-hour clock only if EU personal data is confirmed in scope. Flag the insider-trading risk separately - the vendor's staff now potentially had material non-public information, which is a compliance escalation, not just a privacy one.
3. Pick one structural control so the next team cannot do this, and defend it against the alternatives.
Read the worked answer
Default-deny third-party OAuth consent, with an admin-approved allowlist. In Workspace terms: restrict API access so users cannot grant scopes to unlisted apps, and publish an approval path that takes hours, not weeks.
Why this one, against the alternatives:
- Rewrite the AUP (necessary, insufficient). It should be updated - cloud services, data classification, prohibitions - but the evidence in front of you is that three of eighteen people clicked an all-Drive scope consent. A policy that depends on the user reading a consent screen has a measured failure rate you already know.
- Fix procurement (insufficient). The whole point of shadow IT is that signup requires no procurement. A review gate that a credit card can bypass is not a control; it is a hope. Note that this policy already existed and did not stop this.
- Deploy a CASB (partial). Good visibility and good retrospection - it tells you what is being used and by whom. But a CASB that observes a grant that has already been made is detective, not preventive, and by the time it alerts, the earnings draft is already in scope. Use it as the second layer.
- Default-deny consent (preventive). It attacks the exact mechanism used. The click has no effect until an admin approves the app, which forces the security review that procurement was supposed to force.
Pair it with the honest governance point: the policy failed because it had no enforcement mechanism, so the fix must be to make the technical control the enforcement, and to write the policy to match what the technology now enforces.