Ownership should sit with the identity and data governance teams together, because file access spans entitlements, permissions, and response actions. If access reviews only happen in one platform, outdated rights will persist elsewhere. Lifecycle governance has to follow the data across every file service that stores sensitive information.
Why This Matters for Security Teams
File access review gets difficult fast once sensitive data is spread across SaaS drives, object stores, collaboration suites, and legacy shares. The ownership question is not just administrative. It determines whether stale permissions, orphaned accounts, and overly broad group membership are actually removed or merely documented. For NHIs, the risk is even sharper because machine access often survives human job changes and platform migrations.
NHIMG research shows why this is not a theoretical issue: only 5.7% of organisations have full visibility into their service accounts, and 97% of NHIs carry excessive privileges, which is exactly the sort of condition that makes cross-platform access review unreliable. The broader governance pattern is covered in the Ultimate Guide to NHIs, while the control problem is reinforced by the OWASP Non-Human Identity Top 10. In practice, many security teams encounter toxic access only after a platform migration, an audit finding, or a data exposure has already occurred, rather than through intentional review design.
How It Works in Practice
Ownership should be split by function, not by storage location. Identity governance owns the entitlement model, recertification workflow, and evidence trail. Data governance owns the sensitivity classification, retention rules, and business context that determines who should have access. Platform owners then execute the technical changes in each file service. That division keeps the review accountable without forcing one team to understand every permission model in detail.
A workable process usually includes four steps. First, build an inventory of the file services in scope, including shadow IT and downstream repositories. Second, normalise identity sources so human accounts, service accounts, API keys, and workload identities can be reviewed against the same policy baseline. Third, define review rules based on data class and business purpose, not just folder ownership. Fourth, require remediation evidence so revoked access is actually removed in each platform, not merely approved on paper. The NHI Lifecycle Management Guide is useful here because lifecycle governance must follow the identity wherever it is used, and the same principle applies to file access entitlements.
Current guidance suggests combining periodic access recertification with event-driven review when data moves, teams change, or third-party integrations are added. For machine access, short-lived credentials and workload identity reduce the chance that a dormant account continues to read files across multiple systems. That approach aligns with the control logic in the OWASP Non-Human Identity Top 10 and with zero-trust thinking in the Ultimate Guide to NHIs, Key Challenges and Risks. These controls tend to break down when each platform has its own approval queue and no shared entitlement source of truth, because revocation becomes inconsistent across systems.
Common Variations and Edge Cases
Tighter review ownership often increases operational overhead, requiring organisations to balance governance rigor against platform complexity and review fatigue. That tradeoff is real, especially when dozens of repositories, synced folders, and external sharing paths must be reconciled.
There is no universal standard for this yet, but current practice is to treat shared drives, content platforms, and object stores differently only at the execution layer, not at the accountability layer. For highly regulated data, a central review board may be warranted; for low-risk collaboration content, delegated reviewers may be acceptable if policy thresholds are explicit. The hardest edge case is a mixed human and NHI environment, where a service account inherits access through group nesting or app-to-app delegation. In that situation, review owners must verify both the business need and the technical path, or the same permission will persist through a different identity route.
Teams should also avoid assuming that a file owner can unilaterally certify access. In multi-platform environments, ownership often sits with the business steward for the data, the identity team for the entitlement process, and the platform team for enforcement. That operating model is consistent with the research view in Ultimate Guide to NHIs, Key Research and Survey Results and with the lifecycle discipline described in the 52 NHI Breaches Analysis. Best practice is evolving, but one point is stable: if no single owner is accountable for cross-platform revocation, stale access survives the next migration.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Covers lifecycle and rotation gaps that leave access active across platforms. |
| NIST CSF 2.0 | PR.AC-4 | Addresses access management and least privilege for shared file access. |
| NIST AI RMF | Supports governance and accountability where automated access decisions are involved. |
Map every file service entitlement to NHI-03 and require documented revocation across all systems.
Related resources from NHI Mgmt Group
- Who should own access decisions when identity controls are spread across multiple platforms?
- Who should own access review decisions across multiple applications and tenants?
- How should teams govern data access when datasets are spread across multiple platforms?
- Why do IAM platforms struggle to govern access across enterprise environments?
