What happens when organisations move all files without reviewing ROT and access control first?

When organisations move everything without review, they usually extend the migration window, raise storage spend in the destination cloud, and carry unnecessary risk into the new environment. The problem compounds if file access is not checked first, because inappropriate ACLs can follow the data and preserve access that should have been removed. The result is a larger, riskier target with more governance debt.

Why moving everything first creates avoidable migration drag

Bulk migrations often treat every file as equally valuable, but that assumption turns a clean-up task into a long-lived storage and governance problem. If ROT is not reviewed first, stale copies, duplicates, and obsolete records are carried forward as if they were current business assets, which increases volume, slows cutover, and makes the new environment harder to govern.

That extra volume is not just a cost issue. It creates a larger operational backlog because the destination now has to absorb more data, more exceptions, and more content that no one has revalidated for business need, retention, or ownership.

Why untreated access control is the bigger security fault

Moving files without checking permissions first can preserve legacy access that no longer matches current roles or business need. When that happens, old ACLs, inherited shares, or broad group permissions can be replicated into the destination and remain effective after the move, even though the data has changed location.

That matters because the migration becomes an access-control transfer as much as a data transfer. If the source had weak entitlement hygiene, the destination inherits it unless someone deliberately strips, remaps, or revalidates permissions before cutover.

What the combined failure does to governance and risk

When ROT and access review are both skipped, the organisation usually ends up with more data than it needs and broader access than it intended. Those two failures reinforce each other: excess content increases the amount of information exposed, and excess access increases the number of people or systems that can reach it.

That creates governance debt in the target platform, because the migration project has effectively imported an unreviewed archive and an unreviewed permission model at the same time. The result is a less trustworthy repository that is harder to audit, harder to defend, and more expensive to clean up later.

Risk and Threat Considerations

Skipping ROT review and access control review before migration increases both exposure and attack surface. The most common failure is not a dramatic breach on day one, but persistent overexposure: unnecessary files remain accessible, and old permissions can continue to grant access long after the business justification has expired.

Failure mechanism: The move copies stale content and inherited ACLs into a new platform without reclassification, revocation, or entitlement cleanup, so obsolete data and excessive access survive the migration.

Impact: Sensitive information can remain reachable by the wrong users, third-party shares can persist, and the destination environment inherits avoidable compliance, retention, and insider-risk exposure.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	AC-3 — Access Enforcement	Controls whether migrated files remain reachable by current authorisations.
	AC-6 — Least Privilege	Addresses excessive permissions that can be carried forward during migration.
	AU-6 — Audit Record Review, Analysis, and Reporting	Supports review of migration changes and permission drift after transfer.
Recommendation — Revalidate access mappings so only approved identities retain file access after the move. Reduce permissions before migration and remove any access not needed in the destination. Review migration logs and entitlement changes to detect unintended access persistence.
ISO/IEC 27001:2022	A.5.9 — Inventory of information and other associated assets	ROT review depends on knowing what information assets still matter.
	A.5.15 — Access control	Directly applies to preserving or removing file permissions during transfer.
Recommendation — Inventory files before migration and retire content that no longer has a business purpose. Apply the destination access model before cutover and remove inherited permissions that are no longer justified.

Practitioner Guidance

What to prioritise: Review the file set for ROT and the permission model before bulk transfer, especially where shared drives, legacy folders, or group-based access have accumulated over time. The quickest risk reduction usually comes from reducing volume and pruning high-risk access paths before you move a single directory.

What to verify: Confirm which files still have a business owner, which ones are still subject to retention or legal hold, and whether each destination ACL reflects current roles rather than source-system history. If the move depends on inherited permissions, treat that as a design decision that needs explicit approval, not a default.

Common mistake: Teams often assume migration tools will preserve the “right” access model automatically. In practice, they preserve whatever exists unless someone defines a clean target model, which is how outdated access and inactive content survive into the new environment.

Practitioner takeaway: The safest migration is not the one that moves everything fastest, but the one that removes unnecessary data and resets access before the transfer, so the destination starts smaller, cleaner, and easier to govern.