You Own the Records. But Can You Get Them Back?

In March, a public television station in St. Louis discovered that seventy years of its own history had become unreachable. In June, nonprofits across several countries began reporting that organizational records in Microsoft 365 had stopped existing, or appeared to have.

None of them had lost ownership of anything. That is what makes both episodes worth a records manager’s attention. The legal argument that storing records with a cloud provider does not transfer ownership was settled years ago, and it held in both of these disasters. It simply turned out to be the wrong argument.

Nine PBS had been storing its archive with Open Source Storage since 2019, on annual renewals covering hardware, software and cloud storage. More than 50 terabytes: seventy years of programming, coverage of East St. Louis, the Great Flood of 1993, the pandemic.

In February 2026, the station tried to arrange a renewal meeting. OSS did not respond. It was, by then, delinquent with the Colorado Secretary of State. On 6 March — the contract’s expiration date — access disappeared. The contract had provided thirty days after termination for Nine PBS to retrieve its data.

The hardware itself sat, and sits, in an Iron Mountain facility in Denver. But Iron Mountain’s customer was OSS, not Nine PBS. Iron Mountain supplies space, power, and connectivity for a client’s equipment; handing a third party access to that equipment without the client’s authorization, it argued, would breach its privacy and contractual obligations. This is not an unreasonable position. It is arguably the correct one. That is precisely what makes the case instructive rather than merely outrageous.

Nine PBS obtained a default judgment in St. Louis Circuit Court establishing that it owned the data and had an immediate right to possess it. Iron Mountain was not a party to that judgment.

In August, in the Denver District Court, Judge Eric Elliff ordered Iron Mountain to cooperate with a 30-day retrieval. The framework tells you more than the ruling does. Nine PBS must identify a third-party vendor capable of accessing the cage — the candidate in question is a former OSS employee. It must pay Iron Mountain’s current and past-due storage fees, meaning the defunct intermediary’s arrears. It must indemnify Iron Mountain against the corruption of other clients’ data. And it must verify that nothing belonging to anyone else comes out with its own. The parties were to report back by 14 September.

Nine PBS owned its archive throughout. What it lost was the practical capacity to exercise that ownership, and the price of restoring it was a lawsuit, a court order, a former employee of a dead company, somebody else’s unpaid invoices, and an indemnity. “We are committed to ensuring we can recover and restore full access to this valuable content, which Nine PBS rightfully owns,” the station’s VP and CCO, Leah Freeman, said. The word doing the work in that sentence is access, not owns.

Now the inverse case.

On 14 May 2025, Microsoft announced that its Microsoft 365 Business Premium and Office 365 E1 grants for nonprofits would be discontinued at each customer’s next renewal date on or after 1 July 2025, replaced by up to 300 complimentary Business Basic licenses and discounts of up to 75 percent. Many organizations transitioned without incident. Managed service providers who look after nonprofit tenants report receiving repeated warnings over many months and migrating their clients cleanly.

Others did not. Beginning in the spring of 2026 and clustering hard between 10 and 15 June, nonprofit administrators began posting on Microsoft’s own community forums to report that their SharePoint and OneDrive content had vanished. A US nonprofit reported roughly 500 gigabytes inaccessible, no locatable termination notice, and $0-balance invoices still arriving as recently as 21 May. A Dutch organization was told, after more than twenty exchanges with support, “We are very sorry, but the data is gone for good!” An Italian nonprofit bought a replacement license and found its OneDrive empty. A German association lost, in its administrator’s words, nearly all its records of past years — with confirmed working access one day and none the next. A volunteer fire company reported losing decades of its own history and was told, it says, that its files were gone and nothing would be done.

The organizations affected were small, international, and often operating with limited technical capacity. That matters, because cloud controls that depend on dedicated administrators, monitored billing accounts, independent backup, and rapid support escalation impose very different burdens on a two-person nonprofit than on an enterprise IT department.

Nine PBS’s ownership of its archive was established by a court and never seriously contested; Iron Mountain’s position was about authorization and privity, not title. On the Microsoft side, there was no ownership dispute at all — no one asserted a competing claim to a nonprofit’s spreadsheets, and Microsoft’s public statements were about transition deadlines, not entitlement.

So, in a St. Louis broadcaster with 50 terabytes and a volunteer fire company with a few gigabytes, the answer to who owned these records was the same and never in doubt. It did almost no work in either case. Why?

Because who owns the records and who can act on them are different questions, answered by different mechanisms, held by different parties. And the records-management standards produced by ISO/TC 46/SC 11 have a more precise vocabulary for this than the news coverage does.

Start not with risk but with definition. ISO 15489-1:2016, clause 5.2.2.4:

A useable record is one that can be located, retrieved, presented and interpreted within a time period deemed reasonable by stakeholders.

Useability is one of four characteristics of an authoritative record, alongside authenticity, reliability and integrity. And here is the observation that organizes everything that follows: nothing in the evidence presently demonstrates that authenticity, reliability, or integrity were lost. What is clearly demonstrated is loss of useability.

Nine PBS’s 50 terabytes apparently still exist at the Denver facility, and there is no evidence in the record that their contents were altered. What the station lost was the ability to locate and retrieve them. Useability is the one characteristic of the four that depends less on the record itself than on the systems, contracts and relationships arranged around it — which is precisely why it can fail while the record sits untouched.

Note also the clock embedded in that definition: within a time period deemed reasonable by stakeholders. Six months of litigation is not that period. Neither, as we will see, is a fourteen-day escalation race.

ISO 18128:2024, Records risks — Risk assessment for records management, was published in March 2024 by SC 11, replacing the 2014 Technical Report of the same lineage. Its promotion from TR to full International Standard reflects the maturing of records-risk assessment as a discipline. It provides methods for identifying and documenting risks to records, records processes, controls and systems; techniques for analyzing them; and guidance for evaluating them. Notably, it does not prescribe mitigation — it makes risk visible and leaves treatment to the organization.

That last inclusion, systems, is doing heavy lifting here. Because “the cloud failed” is not a risk statement. It is four or five risk statements wearing one coat: loss of access; dependency on an external provider; failure of an exit control; failure of a notification control; inability to determine the state of one’s own records; business continuity; and the transfer of recovery costs onto the record owner.

Risk, in the 18128 framing, does not live in the probability that a service goes down. It lives in the relationships among records, controls, systems, contracts, and actors.

Most records controls model a single arrow: organization → service provider. Real cloud dependency chains look more like: records owner → SaaS or storage provider → hosting provider → physical hardware → backup provider → identity provider → licensing regime.

Nine PBS never chose Iron Mountain, never contracted with it, and had no leverage over it. Once OSS evaporated, Iron Mountain’s policies — reasonable policies, protecting its other customers — became the binding constraint on a seventy-year public media archive.

Two secondary dependencies are worth naming because most risk registers miss both. The first is tacit knowledge: the retrieval plan depends on a former employee of the defunct vendor who understands how the storage was configured. Institutional knowledge was outsourced along with the infrastructure, and it left when the company did. The second is commingling: Nine PBS must prove it is not taking anyone else’s data out with its own. Multi-tenancy is an accessibility risk, not merely a confidentiality one.

ISO/TR 22428-1:2020, Managing records in cloud computing environments — Part 1: Issues and concerns, models exactly this multi-party structure. Its stakeholder model separates the service customer, the service provider (split across SaaS, PaaS, and IaaS), and the service partner — the records management agent and auditor of clause 4.4.

Be careful with the mapping, though, because the interesting thing is where it doesn’t fit. Iron Mountain sits beneath the direct provider relationship rather than fitting the customer–provider dyad at all, which is exactly why neither Nine PBS’s contract nor its judgment reached it. The court-designated retrieval vendor, by contrast, is close to what 22428-1 calls an agent: a third party engaged in a defined role to act on behalf of records the customer cannot access itself. It took a judge to introduce one.

The records manager’s risk map cannot stop at the vendor named on the invoice.

Nine PBS had a contractual right to thirty days of post-termination retrieval. Access ended on the expiration date. The control existed on paper and produced nothing.

A clause saying the customer may retrieve its records for thirty days is not an architecture capable of delivering retrieval in thirty days. A contractual right without a technically executable exit mechanism is a weak records control. ISO/TR 22428-1 anticipates this precisely in clause 8.2.3, "inability to enforce contractual terms," sitting alongside 8.2.4 on non-negotiable licensing terms, 8.2.5 on data ownership issues, and 8.2.6 on conflicts between terms and conditions.

The Microsoft situation offers a subtler version of the same failure, and it needs to be stated carefully, because “Microsoft gave no notice” is not supportable. Microsoft announced the change publicly, documented it, and notified customers; many administrators received repeated warnings and acted on them.

What the record shows instead is that the notification control worked reliably for organizations with professional IT support and unreliably for those without — which is to say, for the organizations the grant existed to serve. Notices went to admin mailboxes that small nonprofits did not monitor. And several organizations report that their own administrative indicators actively told them they were fine: $0 invoices arriving weeks before the loss; a portal expiry date months in the future; in one German case, a Microsoft email dated 1 June 2026 stating that the license would expire on 17 September, sent to an organization whose users were hitting errors by mid-month.

A control whose effectiveness correlates with the customer’s IT sophistication is not a records control. It is a filter.

Here is where this stops being a story about deletion.

Organizations treat subscription expiration, license downgrade, tenant closure, account cancellation, and grant retirement as IT or procurement events. In a SaaS environment, each can function as a disposition trigger. What records management specifies is: records requirement → appraisal → retention rule → authorized disposition → documented destruction. What the architecture substitutes is: licensing state → system state → recoverability window → effective disposition.

Microsoft documents multiple overlapping state machines through which customer content can pass: subscription states, user-deletion states, unlicensed-account states, recycle-bin states, archive states, and backend recovery states. Each carries its own clock.

The subscription lifecycle runs Active → Expired → Disabled → Deleted: thirty days in Expired — a stage removed in February 2026 for license-based subscriptions bought directly under a Microsoft Customer Agreement — then ninety days in Disabled, during which, in the language of Microsoft’s compliance documentation, data is retained “in a limited-function account for 90 days to enable the subscriber to extract the data.” Deletion follows no later than 180 days. But a subscription that is explicitly deleted skips Expired and Disabled entirely, and SharePoint and OneDrive content is removed immediately.

Alongside that: the OneDrive user-deletion lifecycle, which begins only when a user is deleted from the directory and runs a default thirty-day orphan retention before the site moves to the recycle bin. The SharePoint recycle bin itself: ninety-three days. Post-hard-deletion backups: fourteen days, after which Microsoft’s term for the result is “commercially unrecoverable.” Microsoft 365 Archive, where content is inaccessible to users but remains searchable and reactivates losslessly — provided pay-as-you-go billing is enabled. And, from 1 July 2026, a separate unlicensed-account lifecycle running for 60, 93, 275, and 365 days.

These are not steps in one sequence. They are six distinct mechanisms with overlapping and sometimes competing clocks, and which one governs a given organization’s content at a given moment is not something that organization can readily observe. The complexity is itself the risk. Not one of these clocks is the organization’s retention schedule.

And then there is the sentence that reframes the whole affair. Microsoft’s OneDrive retention documentation states:

No other action causes the cleanup process to occur, including blocking the user from signing in or removing the user’s license.

Cleanup begins only when a user is deleted from the directory, and it is announced: the manager or secondary owner receives an email, then a reminder seven days before the retention period expires. In a two-person nonprofit, that manager may be nobody. Unlicensed OneDrive accounts, meanwhile, are archived on day ninety-three and are deleted only after roughly twelve unpaid months.

On Microsoft’s own published rules, a lapsed nonprofit grant should not have destroyed anything.

Either something other than simple license expiry occurred in June 2026 — a tenant-level subscription deletion, or user objects removed from the directory as part of a deprovisioning routine — or the publicly documented lifecycle does not fully explain what these customers experienced. The customers had no way to tell which. Neither, judging by the inconsistent answers they received, did the support staff they spoke to: one organization was told by a licensing team that deletion for lack of a license was not possible, and by the SharePoint product team that several thousand tenants were affected and their data was unrecoverable.

The consequence is that reported losses have to be classified by what is actually established rather than by what is said to support them.

Some organizations relicensed, and their data came back: nothing was ever demonstrated to have been destroyed. Some landed in an archived state and recovered within days. Some required backend intervention. And in the most instructive case, an organization that had reported roughly 500 gigabytes gone — the same organization, posting across Microsoft’s forum and elsewhere — eventually got everything back. After ordinary support and relicensing failed, an escalation team performed a point-in-time restore of each affected user’s OneDrive site. The administrator’s warning to others was that the restore could only go back 14 days.

In at least one documented case, then, the decisive variable was not the organization’s records schedule but whether its support case reached a recovery-capable team before the backend restore window closed. That is a fourteen-day race, and the organizations least equipped to run it are the ones that file web tickets rather than call an account manager.

It also means that most of the accounts in circulation should be written as Microsoft support told the organization its data was unrecoverable — not as Microsoft permanently deleted the data. First-line support saying data is gone has been demonstrated, at least once, not to be evidence that it is gone.

To the customer, data could appear lost while remaining recoverable somewhere within the provider’s infrastructure — provided the right escalation reached the right layer before the clock expired.

One organization, R. Fathers M.A.D., Inc., reports a state that is not in any published lifecycle. Its grant lapsed on 27 May 2026; it purchased a replacement subscription on 15 June. Microsoft’s Data Protection Team successfully linked the accounts and licenses. But a frontline eDiscovery search returned empty — because, the organization says, the metadata indexing pointers had been severed during grant decommissioning. Its account is that the content remained intact and within the retention window, and that a Tier-3 engineer was needed to trigger backend re-indexing to reconnect the files to the remapped user profiles.

The organization therefore had records that apparently still existed but could not be found by the system designed to verify their existence.

Availability, preservation and findability are separate properties. A record can survive physically while becoming operationally invisible. Against ISO 15489-1’s definition, this is exact: whatever the physical state of the content, it could not be located or retrieved — a loss of useability, with no indication that authenticity, reliability or integrity had been compromised. It is also worse than an ordinary access failure, because the instrument an organization would use to prove its records survived is the instrument that reported they had not.

M.A.D.’s diagnosis of severed indexing pointers is its own; Microsoft has not endorsed it. But the broader phenomenon does not depend on that diagnosis being right. Microsoft’s own eDiscovery documentation states plainly that “the Recycle Bin in SharePoint sites isn’t indexed and therefore unavailable for searching,” with the consequence that eDiscovery searches cannot find recycle-bin content at all. Content can fall well within Microsoft’s documented retention windows and be entirely invisible to the tool an organization would use to search for it. Existence and discoverability are, by design, different things.

This is the organization’s own technical account, posted on Microsoft’s community platform; Microsoft has not confirmed it. The same ticket number and facts appear in two separate posts.

The instinct, reading this far, is to say: they should have had backups. True, and insufficient. Backup answers one question: can the bits be restored after a technical failure? It does not answer preservation (do the records remain authentic and usable over time), portability (can they move, with metadata intact), exit (can we retrieve them when the relationship ends), custody (who has the authority and the capability to act), or continuity (can essential records stay available during a dispute or migration).

Nine PBS fails on exit, custody, and continuity, while backup is very nearly beside the point. The bits are fine.

A backup strategy asks what happens when the disk dies. A records-risk strategy asks what happens when the relationship dies.

Applied as an ISO 18128 exercise, three risks emerge that most cloud risk registers do not contain:

Provider termination or failure prevents access to required records. Sources include insolvency, contract termination, licensing change, subcontractor dispute, and loss of vendor-side tacit knowledge. The control weaknesses are the tell: dependency on provider cooperation, an export capability never tested at full volume, no independent copy, undisclosed subcontractor dependencies, and no contractual privity with the party physically holding the hardware.

Provider-controlled deletion occurs independently of authorized disposition. Microsoft documents one especially consequential example: explicitly deleting a subscription bypasses the normal Expired and Disabled states and immediately deletes SharePoint and OneDrive content. That is effectively a disposition-capable administrative action — available, in most small organizations, to whoever holds the billing credentials, and taken with no appraisal, no authorization, and no documentation. Restrict who can perform it, and treat it in policy as what it is.

The organization cannot determine the state of its own records. This is the one 2026 added to the list. Register the provider’s documented state machine and every recovery window in the retention schedule itself. Require contractual notification of state transitions that affect recoverability. Pre-establish and test an escalation path against the shortest window, not the longest. And keep an independent copy of anything whose loss would be unacceptable, on the working assumption that state is unobservable.

That last risk is where these two stories converge, and it is the question SC 11’s framework puts most sharply:

Can an organization claim to control its records when it cannot independently determine whether those records are active, disabled, archived, soft-deleted, hard-deleted, recoverable from backup, or commercially unrecoverable?

A backup strategy asks what happens when the disk dies. A records-risk strategy asks what happens when the relationship dies.

For 20 years, the sector largely prevailed in the legal argument that storing records with a cloud provider does not transfer ownership. These cases show ownership was only ever one component of control.

Nine PBS owned records it could not retrieve. The nonprofits owned records whose existence they could not verify.

The asymmetry in how the two were resolved is worth sitting with. Nine PBS got a judge, a retrieval framework and a deadline — in five months, at the cost of litigation most nonprofits could not fund. The nonprofits got a support ticket. Microsoft has said nothing publicly about the deletions beyond a statement given to Slate on the day it published, which restated the transition advice it had issued in 2025. For nine weeks the story existed only on Microsoft’s own user forums.

So the question for the next generation of cloud services is not who owns the data. It is: who can preserve it, retrieve it, migrate it, halt its deletion, and guarantee its availability when the commercial relationship breaks down?

If the answer is “only the vendor,” then the organization owns the records but does not control their fate.

Reconstructing what happened to one nonprofit’s 500 gigabytes required reading two platforms. Microsoft’s own community forum preserves the failure: a case opened on 20 June, never resolved there. The recovery — the escalation team, the point-in-time restore, the fourteen-day limit — is recorded elsewhere entirely. A researcher consulting only Microsoft’s forum would reasonably conclude the records were lost.

Even the record of what happened to these records is fragmented across custodians, incomplete in every single location, and preserved by no one whose job it was.

Nine PBS facts are drawn from the filed complaint and court orders as reported by Current and Gizmodo. Microsoft’s lifecycle, retention, archive, and grant-transition rules are drawn from Microsoft’s published documentation and TechSoup’s contemporaneous guidance for nonprofits. Accounts of individual losses are as reported by the affected organizations on Microsoft’s Community Hub and Q&A forums, on Reddit, and in Slate*; they are those organizations’ accounts, and Microsoft has not publicly responded to them. A widely repeated figure of 171,000 affected organizations originates in a Microsoft support representative’s remark to a single customer; Microsoft has not confirmed it, and Microsoft’s SharePoint product team separately told a German nonprofit that “several thousand tenants” were affected.*