Oversharing Remediation at Scale with DSPM
Cobalt Grid Analytics has 6,000 employees plus an acquired subsidiary that still uses Google Workspace. Forcepoint DSPM scans 48 TB across SharePoint Online, OneDrive and Google Drive and flags 310,000 files as shared externally; 2,100 of those are reachable through 'anyone with the link'. The DSPM inventory shows 4,600 files containing customer PII and 180 files that resemble proprietary source code. IT has 12 administrators, there is no maintained data-owner mapping, and three SharePoint sites are under legal hold. The chief operating officer has told the security team that the 'anyone with link' count must reach zero in 30 days, and the general counsel has asked what could break if access is revoked automatically.
1. Build a prioritisation model for the 310,000 files. What factors drive order of work, and what do you refuse to automate?
Read the worked answer
Treat 310,000 as an inventory problem, not a ticket queue. Rank each file, or better each site and library, on four factors:
- Sensitivity: PII and source code first; marketing collateral can wait.
- Exposure breadth: 'anyone with the link' beats 'external user with named access', because the link is unauthenticated and may already be indexed.
- Activity: recently accessed or modified files indicate live business use; a link nobody has opened in two years is low urgency even if it is public.
- Regulatory and legal weight: the three sites under legal hold are excluded from automated permission changes entirely, because altering access can affect preservation arguments.
The high-priority segment is PII or source code, publicly linked, on a non-hold site, accessed in the last 90 days. That is likely a few hundred items and achievable in the window.
Validate before acting: sample 100 classifier hits and hand-check them. ML classifiers on legacy file shares produce false positives, and a mistaken revocation of a client deliverable costs credibility you need later. Automate link removal only where the owner has been notified or the file is clearly low-value; route the rest through owner confirmation. Refuse to automate anything on hold, anything with no identifiable owner in a business-critical library, and anything where the only copy lives in that location.
2. The COO wants the link count at zero in 30 days. Describe the remediation mechanics and how you prevent the change from breaking partner access.
Read the worked answer
Two distinct problems hide inside the number. Per-file links can be removed programmatically; site-level inheritance from 'everyone except external users' cannot, and revoking inheritance changes access for whole libraries.
Mechanics. Use the DSPM and platform APIs to remove direct 'anyone' links in batches by site and library, largest exposure first. Do not delete files. Where site-level sharing is the cause, change the sharing capability at the site or library level after notifying the site owner, and re-scan to confirm the effect. Track each batch so you can reverse a specific one if a business process fails.
Partner continuity. Many of those links are how partners download deliverables. Before removal, identify links with recent external access and give the owner a short window to replace them with authenticated guest access or an expiring link. Publish a self-service route: partner requests access, owner approves, access is time-bound. Without that route, staff will re-share using links you cannot see, and the count returns.
Cadence. Re-scan weekly, report by business unit, and give the COO a burn-down against the 2,100 baseline rather than a narrative. State the limit of the metric: a zero link count with staff moving files to personal storage is not a win, so watch egress DLP and cloud app discovery for compensating behaviour.
3. How should the DSPM findings connect to Forcepoint DLP enforcement, and what would you measure after 90 days to show the programme is working?
Read the worked answer
DSPM tells you where sensitive data sits and who can reach it at rest; DLP controls where it moves. Link them through metadata, not file lists.
Connection. Map DSPM classification results onto sensitivity labels or policy tags in Microsoft 365 and Google, then write DLP rules against the label rather than against file paths, which change. Egress rules then cover the same population: files classified as PII or source code cannot be shared externally, downloaded to unmanaged devices, or posted to unsanctioned cloud storage. Feed new high-risk findings into the DLP incident queue so reviewers see 'publicly shared and now being downloaded' as one event rather than two disconnected alerts.
Measure at 90 days:
- Publicly linked sensitive files against the 2,100 baseline, and recurrence rate - how many removed links reappear, which is the real test of behaviour change.
- Percentage of sensitive files with a named owner, since ownerless data cannot be governed.
- Time from finding to remediation, split by automated and owner-confirmed.
- DLP incidents on labelled sensitive content, particularly outbound from sanctioned to unsanctioned apps.
- A control check that the scan still covers newly created sites and the subsidiary tenant.
Report recurrence and ownership next to the headline count. A falling link count with rising recurrence means you are cleaning, not fixing.