SaaS Misconfiguration Data Exposure Playbook

Most SaaS data exposures are not hacks: a site, a share link or a guest setting made internal records readable by people who should never have seen them, and the exposure lasted until someone outside noticed. This playbook gives [Organisation] a ready-to-use response procedure for that specific incident: an "Anyone" link on a sensitive file, a public knowledge base, an Experience Cloud or portal page that returns records to unauthenticated visitors, or guest accounts with access far beyond their purpose. It covers triage, containment in the right order, the evidence to keep before you change settings, how to work out whether anyone actually accessed the data, and the notification decision. It is written for SaaS administrators, security operations and privacy teams. Platforms are listed alphabetically: Google Workspace, Microsoft 365 (SharePoint and OneDrive), Salesforce and ServiceNow; the order is not a ranking. Broader SaaS incidents (account takeover, token theft) follow the SaaS Incident Response Guide, and exposed cloud buckets follow the Cloud Storage Exposure Playbook.

How to use this template

Adopt it per platform: keep sections 1 to 8 as written and fill the platform tables in sections 3 and 4 with your own tenant names, admin roles and log retention.
Replace bracketed text: [Organisation], [Incident lead], [Privacy lead], [SaaS admin team], [SOC] and bracketed time limits take your own values. Time limits shown are NHI Mgmt Group suggestions, except where a law is cited.
Preserve before you contain, but only briefly: the evidence steps in section 3 take minutes. Do not leave a public exposure open for hours to collect perfect evidence.
Treat it as a personal data incident until shown otherwise: the 72-hour clock under UK and EU GDPR starts at awareness, not at the end of the investigation.
Test it: run a tabletop at least once a year using one scenario per platform you operate, and record which log you could not get.

1. Scope and triggers

1.1 This playbook applies when data held in a SaaS application used by [Organisation] has been, or may have been, readable by people outside the intended audience because of a configuration or sharing setting, rather than because an account was compromised.

1.2 It covers four exposure types:

Exposure type	Typical examples	Why it is easy to miss
Anonymous share links	"Anyone" links in SharePoint and OneDrive, "Anyone with the link" in Google Drive	The link works for whoever holds it; it can be forwarded, indexed or pasted into a ticket
Public sites and portals	Salesforce Experience Cloud sites, ServiceNow public pages and knowledge bases, published Google Sites or Docs	The page was meant to be public; the data behind it was not
Guest and external accounts	Entra B2B guests in SharePoint, Google visitor sharing, portal external users	Access was granted for one project and never reviewed
Integration and publishing jobs	A migration or sync script that copies internal files into a public library or portal	No human made the sharing decision, so nobody owns it

1.3 Triggers: a report from a researcher, customer or journalist; an SSPM or DSPM alert; a search engine result showing internal content; audit log entries such as an anonymous link created on a restricted library; a data loss prevention match on a public item; or a finding from a routine sharing review.

1.4 Out of scope: compromised accounts and stolen OAuth tokens (use the SaaS incident response procedure), and exposed object storage (use the cloud storage procedure). If the investigation shows an account was compromised, switch procedures and keep this record.

2. Roles and contacts

Role	Responsibility in this playbook
[Incident lead]	Declares the incident, owns the timeline and decisions, signs off closure
[SaaS admin team] for each platform	Pulls configuration and audit evidence, applies containment changes, records every change made
Data or content owner	Confirms what the exposed items contain and who legitimately needs access
[Privacy lead] / Data Protection Officer	Runs the risk assessment and the notification decision in section 7
[SOC]	Searches audit logs for access by external or anonymous users, watches for reuse of any exposed secrets
Legal and communications	Handles reporter contact, regulator and customer messaging
SaaS provider support	Engaged when logs needed for scoping are not available to tenant admins or have aged out

2.1 Keep an out-of-hours contact for each platform admin team. Public exposures are often reported at weekends because external researchers find them.

3. Detection and triage

3.1 First 30 minutes. Answer these questions in the incident record:

Which platform, site, library, knowledge base or object is exposed, and through which mechanism (link, public page, guest account, sync job)?
Is it still exposed right now? Test from an unauthenticated browser session on a network outside [Organisation], and record the result with a timestamp.
What data classes are involved: personal data, special category data, credentials or keys, customer confidential, regulated financial or health data?
When did the exposure start? Use the link creation event, the site publication date or the configuration change in the audit log.
Who reported it, and do they hold a copy?

3.2 Preserve evidence before changing anything. Export the current sharing configuration and the relevant audit log range, screenshot the public view, and record link URLs and IDs. These records prove what was exposed and for how long, and they disappear or change once you contain.

3.3 Where to look, by platform:

Platform	Configuration to capture	Access evidence to export
Google Workspace	Drive sharing settings for the affected organisational unit and any group overrides (group settings override OU settings); the item's general access setting	Drive log events filtered on Visibility "Shared externally", Prior visibility, Old and New publish visibility value, Visitor, Download and View events for the item
Microsoft 365 (SharePoint and OneDrive)	Organisation and site sharing levels, default link type, Anyone link expiry and permissions, domain restrictions	Purview audit operations AnonymousLinkCreated, AnonymousLinkUsed, SecureLinkCreated, AddedToSecureLink, SharingInvitationAccepted, SharingSet and FileAccessed, filtered on TargetUserOrGroupType Guest where relevant
Salesforce	Site guest user profile and permission sets, guest user sharing rules, public site settings, the "Let guest users see other members of this site" setting	Setup audit trail for the configuration changes; site and event logs available under your licence for guest user requests
ServiceNow	Knowledge base user criteria (Can Read, Cannot Read, Can Contribute, Cannot Contribute), Public Pages (sys_public) records, ACLs carrying the public role, the property glide.knowman.block_access_with_no_user_criteria	User Criteria Diagnostics results for unauthenticated users, system logs and transaction logs for guest sessions

3.4 Severity. Rate the incident [High] if the exposed data includes special category data, credentials, or more than [1,000] individuals' records, or if there is evidence of anonymous access by unknown parties. Rate it [Medium] if personal data is exposed with no evidence of access. Rate it [Low] for internal-only business data with no personal data and no access by unintended parties.

3.5 For deeper scoping of what was taken, use the Data Security Incident Scoping Playbook.

4. Containment

4.1 Contain in this order. Each step reduces the audience; later steps are slower and carry more business disruption.

Remove the specific exposure: delete the anonymous link, unpublish the page, remove the guest from the item or group, or stop the sync job. Record the time.
Close the same mechanism across the affected container: other anonymous links in the same site, library, shared drive or knowledge base are usually just as exposed.
Tighten the setting that allowed it: lower the site or organisational unit sharing level, set expiry and view-only on links, restrict guest sharing rules.
Rotate anything secret in the exposed content: API keys, passwords, connection strings and tokens found in exposed files must be treated as compromised. See the API Key Leak Response Playbook.
Request removal from search caches and third parties where the content was indexed or reposted.

4.2 Platform containment actions:

Platform	Containment actions	Baseline value to restore
Google Workspace	Change the item's general access to Restricted; remove external users; in the Admin console, restrict external sharing for the organisational unit and turn off "anyone with the link" availability where external sharing stays on	CISA SCuBA: external sharing restricted to allowlisted domains (GWS.DRIVEDOCS.1.1v1), "Private to owner" as the default for new items (1.8v1), access checking set to recipients only (1.6v1)
Microsoft 365 (SharePoint and OneDrive)	Delete the Anyone link; set the site sharing level to Existing guests or Only people in your organization; set the default link type to Specific people; require Anyone links to expire and set them to view only	CISA SCuBA: external sharing limited to Existing guests or Only people in your organization (MS.SHAREPOINT.1.1v1, 1.2v1); default scope Specific people (2.1v1); Anyone links expire in 30 days or less (3.1v1) and are view only (3.2v1)
Salesforce	Deactivate or narrow the guest user sharing rule; remove object permissions and Apex class access from the guest profile; take the site offline if records are still returned	Guest external org-wide defaults are always Private and guests get read access at most, through guest user sharing rules only (Salesforce guest user security policies)
ServiceNow	Add Can Read user criteria to the knowledge base or set the article to Cannot Read for the public; remove the sys_public record or public-role ACL that opened the table	Set glide.knowman.block_access_with_no_user_criteria to true so knowledge bases without criteria stop being readable by unauthenticated users; run the Fix unsecured knowledge bases fix script

4.3 Guest-based exposure: when a guest account is the path, remove its access, then check whether the same guest has access elsewhere in the tenant. See How to audit guest and external users.

4.4 Rollback: every containment change is recorded with the previous value. If a change breaks a legitimate external process, restore access for named people only, never by re-enabling the anonymous mechanism.

5. Eradication

5.1 Find the root cause, not just the link. Record which of these applies:

Permissive tenant default: the organisation or organisational unit default allowed anonymous sharing, so users chose it without thinking.
Site or portal design: a public site was built on an object, table or Apex class that also holds non-public records.
Publishing automation: a script or integration placed internal content in a public location. A configuration error has the same effect: in the Cisco DevHub breach, Cisco said files not intended for public download were inadvertently published on its public resource centre as a result of a configuration error.
Stale guest access: external collaborators kept access after the project ended.

5.2 Search the whole tenant for the same root cause. One exposed knowledge base usually means others share the missing user criteria; one Anyone link on a finance library usually means the site default allows them. Use your SSPM or the platform reports described in the How to Audit Google Drive External Sharing and Public Links guide and the platform hardening guides, listed alphabetically: Google Workspace Security Guide, SharePoint and OneDrive Security Guide, Salesforce Experience Cloud Security and ServiceNow Security Guide.

5.3 Fix the generating process: change the default, add a review step to the publishing job, or add a guest expiry policy.

6. Recovery

Restore legitimate external collaboration through specific-people sharing, approved domains or named guests with an expiry date.
Re-test from an unauthenticated session and from a guest test account that the exposed items are no longer reachable.
Confirm any rotated secrets are in use and the old values are revoked, not just replaced.
Set a detection rule for the same pattern: new anonymous link on a sensitive-labelled library, visibility change to public on web, new guest sharing rule, or new sys_public record.
Keep the item under watch for [30] days for renewed external access.

7. Communication and notification

7.1 Was the data actually accessed? Work this out from the access evidence in section 3.3. Classify each exposed item as: accessed by unintended parties (evidence of AnonymousLinkUsed, external Download or View events, or guest sessions), possibly accessed (exposed but logs absent or expired), or not accessed (logs present and show only intended users). Absence of logs is not evidence of no access.

7.2 Regulator notification. Under UK and EU GDPR Article 33, a controller must notify the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of a personal data breach, unless the breach is unlikely to result in a risk to individuals. The ICO allows information to be provided in phases where not all details are available within 72 hours. Other jurisdictions apply their own tests and deadlines; see the Breach Notification Laws by Country Guide.

7.3 Individuals. Under Article 34, tell affected individuals without undue delay when the breach is likely to result in a high risk to them. Exposure of credentials, financial details, identity documents or special category data usually meets that threshold.

7.4 Record every breach. Article 33(5) requires the controller to document the facts, effects and remedial action for every personal data breach, including those not reported. Record the reasoning when you decide not to notify.

7.5 Customers and partners: check contracts for notification clauses, which are often shorter than the regulatory deadline. Coordinate with the reporter on disclosure timing and thank them.

8. Post-incident review

8.1 Hold the review within [10] working days. Record: exposure duration, detection source, time to contain, number of items and records exposed, evidence of access, root cause and the tenant-wide fixes applied.

8.2 Update the platform baselines and this playbook. Add any log you needed but could not get to the logging requirements, with the retention period that would have covered this incident.

Implementation guidance

Set baselines before the incident: the CISA Secure Cloud Business Applications (SCuBA) baselines for Microsoft 365 and Google Workspace give testable sharing values, and they are a good starting point for any platform. Measure drift against them weekly.
Check log retention now: the question in section 7.1 can only be answered from audit logs that still exist. Confirm retention for Purview audit, Google Drive log events, Salesforce event data and ServiceNow transaction logs, and export to your SIEM if native retention is shorter than your investigation window. See the SaaS Audit Log Retention Guide.
Know your public surfaces: keep a list of every public site, portal, published document and knowledge base, with an owner and the objects or tables it reads. A public surface with no owner is a finding on its own.
Where identity fits: guest accounts, portal guest users and the integration users that run publishing jobs are identities with access to data. Give each an owner and an expiry, and include them in access reviews. See the ServiceNow Integration Users and OAuth Security Guide for the integration side.
Metrics: count of active anonymous links on sensitive-labelled content; percentage of guests with an owner and expiry; public surfaces with a named owner; mean time from exposure report to containment; exposures found internally versus reported externally; drift findings against the sharing baseline.

Framework	Reference	How this playbook supports it
NIST SP 800-53 Rev. 5	AC-3 Access Enforcement, AC-21 Information Sharing, CM-6 Configuration Settings, AU-6 Audit Record Review, IR-4 Incident Handling, IR-6 Incident Reporting	Sharing baselines, log review for access evidence, handling and reporting steps
NIST CSF 2.0	PR.AA-05, PR.PS-01, DE.CM-03, RS.AN-03, RS.MA-01	Access policy, configuration management, monitoring, root cause and coordinated response
CIS Controls v8.1	Safeguard 3.3 Configure Data Access Control Lists	Tenant and site sharing settings and guest permissions
ISO/IEC 27001:2022 Annex A	A.5.24 to A.5.26 incident management, A.8.9 Configuration management	Response procedure and baseline control
MITRE ATT&CK	T1213 Data from Information Repositories, T1213.002 Sharepoint, T1530 Data from Cloud Storage, T1080 Taint Shared Content	How exposed repositories are collected or tampered with; drives detection queries

SaaS Misconfiguration Data Exposure Playbook: Close Public Sites, Links and Guest Access Fast