Who should own the decision to remove public access from shared files?

Why This Matters for Security Teams

Removing public access from shared files is not just a housekeeping task. It is a control decision that affects data exposure, collaboration, legal defensibility, and incident response. If ownership is unclear, public links often survive beyond their business need, especially in environments where file sharing is decentralized across SaaS platforms, cloud drives, and external collaboration spaces. That creates a gap between policy and actual exposure.

The practical issue is that public access is usually created for speed, then forgotten. Teams often assume another function will clean it up, but no one is accountable for verifying whether the file is still sensitive, still needed, or still reachable by search and forwarding. That is why access removal should be assigned to the group that can confirm sensitivity and execute revocation, with governance aligned to NIST SP 800-53 Rev 5 Security and Privacy Controls for access control and information flow management.

For NHI and AI-enabled workflows, the same ownership question extends to non-human identities that generate links, sync content, or approve sharing on behalf of users. If those service accounts or agents are not governed, public access can persist even after the human requester has moved on. In practice, many security teams discover shared-file exposure only after a data request, partner complaint, or incident review has already surfaced the problem, rather than through intentional access governance.

How It Works in Practice

The most reliable operating model is a joint workflow with clear decision rights. Data owners decide whether the file should remain public based on classification and business purpose. IAM or platform admins execute the technical revocation. Compliance or privacy teams define the policy threshold for when public sharing is allowed, time-limited, or prohibited. Security teams then monitor for exceptions, stale links, and patterns of excessive sharing.

In mature environments, this is supported by metadata, not manual memory. Files should carry classification labels, owner information, expiration dates, and sharing context so revocation can be automated or queued for approval. Where possible, access reviews should include public links alongside internal permissions, because a file can be correctly permissioned for users while still exposed externally through an old link.

• Define who can approve public sharing and who can revoke it.
• Require a sensitivity label or classification before external access is granted.
• Set expiry for public links by default, with exceptions documented.
• Log creation, renewal, and removal of shared links for auditability.
• Review orphaned links after role changes, project closure, or vendor offboarding.

For environments with automated content workflows, the identity behind the sharing action also matters. If a bot, integration, or AI agent creates or republishes links, ownership should extend to the service account or agent lifecycle as well. That is where guidance from the OWASP Non-Human Identity Top 10 becomes useful, because the revocation problem is often really a non-human identity governance problem. These controls tend to break down when file sharing spans multiple tenants or unmanaged external collaboration tools because revocation authority does not follow the data.

Common Variations and Edge Cases

Tighter public-access control often increases operational friction, requiring organisations to balance collaboration speed against exposure risk. That tradeoff is most visible in marketing, partner enablement, research, and customer success teams, where public links may be used as a practical delivery mechanism rather than a deliberate security exception.

There is no universal standard for exactly which team must own every removal decision. Current guidance suggests that ownership should follow the team best positioned to judge sensitivity and enforce the change, but the decision can be delegated differently depending on data domain, regulatory pressure, and platform design. In highly regulated environments, compliance may set the rule, while the business data owner approves exceptions and IT executes revocation. In fast-moving SaaS environments, platform admins may automate removal based on expiry policy, with business owners retaining review authority.

The edge cases are usually around delegated sharing and machine-generated access. A shared file can look harmless until it contains customer data, internal strategy, or regulated content embedded in comments or attachments. Public access should also be reassessed after mergers, restructures, and vendor exits, because link ownership may not map cleanly to the current org chart. Where AI assistants or automated workflows generate or distribute files, organisations should define whether those actions inherit human approval or require separate non-human identity controls before publication.

Related resources from NHI Mgmt Group

• How should security teams run access reviews for non-human identities?
• How should security teams govern non-human identities that have persistent access?
• When do NHI access reviews create more value than a one-time cleanup?
• What is the difference between reviewing human access and reviewing NHIs?