The Data Still Exists. You Just Can’t Reach It.

Owning your data has never guaranteed you can retrieve your data — and most organizations don’t discover they’d conflated the two until the company holding it disappears.

That’s the situation Nine PBS is in right now. The St. Louis public television station has roughly 70 years of programming — about 50 terabytes of it — sitting in a Denver data center it cannot get into. Nobody has reported the archive destroyed. No ransomware, no fire, no failed disk array. The data, as far as anyone has confirmed, still exists. Nine PBS could not retrieve it through the relationships it already had, and a court ultimately had to establish a process for getting the data out.

What Actually Failed

The sequence is plain enough once you lay it out, and none of it requires a framework to understand.

Nine PBS contracted with a cloud storage vendor called Open Source Storage (OSS) starting in 2019, renewing annually without incident through 2025. In February 2026, the station tried to reach OSS about that year’s renewal and got no response. The existing contract expired March 6, 2026. Its own terms gave Nine PBS 30 days after expiration to retrieve its data. OSS cut off access before that window closed.

It turned out OSS had gone defunct — its website was gone, and Colorado’s Secretary of State listed the company as delinquent. But the archive wasn’t simply out of reach — it was one contractual layer removed. OSS was itself a customer of Iron Mountain Data Centers, which operates the Denver facility housing OSS’s hardware. When Nine PBS came looking for its data, Iron Mountain didn’t dispute that the archive was inside its building. It maintained something narrower: that it had no logical access to the data at all. The servers, and the data on them, belonged to its own customer — OSS — not to Iron Mountain. A judge later confirmed the same distinction from the bench, describing Iron Mountain as the data’s “custodian” while noting explicitly that Iron Mountain was never the vendor Nine PBS actually contracted with. That obligation stayed with OSS.

Nine PBS owned 70 years of its own history. But its contract stopped with OSS, while the hardware containing the archive remained inside infrastructure operated by Iron Mountain.

The Three-Layer Problem

Strip the specifics away and the structure looks like this:

Nine PBS’s contract stopped at layer 2. When layer 2 disappeared, layer 1 discovered it had no path to layer 3 — not a broken path, an absent one. Nobody removed a connection that used to exist. It was never built.

Owning The Data Isn’t The Same As Being Able To Retrieve Your Data

Most data protection programs are built to answer questions about the asset itself: where is it, how long is it retained, is it durable against hardware failure, does the backup restore cleanly. Nine PBS could probably have answered all of those questions correctly for years. None of them is the question that actually failed.

The question nobody asked was simpler and much less technical: if the company we contracted with disappeared tomorrow, who could actually hand us our data?

That’s not a backup question. A backup that restores cleanly assumes you can reach the system it restores from. It’s not quite a vendor-risk question either, in the usual sense — Nine PBS didn’t get breached, defrauded, or ransomed. Nobody did anything to the data. The failure sits one layer beneath all of that: the organization had never established a direct contractual path to the party that actually held the infrastructure containing its asset. Durability was never in question. The organization had never established who could actually provide the data when the contracted provider disappeared.

Why The Court Became Part of the Recovery Path

The reason this matters architecturally, not just legally, is what happened next.

A default judgment obtained earlier this year established that Nine PBS owns the data and that OSS breached its agreement by cutting off access early. That judgment did nothing to move Iron Mountain. OSS wasn’t around to contest anything, and a default judgment against a defunct company doesn’t obligate a party that was never named in it. Nine PBS had to file a second, separate suit — this time against Iron Mountain directly, in Denver.

That sequence is the actual evidence for this post’s argument, and it’s worth being precise about why. Once OSS disappeared, there was no operational, technical, or contractual mechanism available to Nine PBS to reach its own archive on its own. The court had to establish a retrieval process that the existing contractual and operational relationships had never provided. That’s not a story about a lawsuit. It’s a story about what’s left once a lawsuit is the only lever available.

Where This Generalizes

Nothing about this is specific to public broadcasting, or to Open Source Storage, or even to cloud storage narrowly defined. The same three-layer structure — owner, contracted intermediary, actual custodian — sits underneath a long list of routine enterprise relationships:

The diagnostic question doesn’t change across any of these: if the company you contracted with disappeared tomorrow, who could actually hand you your data? Most organizations have never asked it, because the question that gets asked instead — is our data protected — has a comfortable answer. This one usually doesn’t, until something forces it.

Differentiation

This isn’t a recovery-dependency problem, and it isn’t the same shape as authority surviving an incident. Three frameworks already on this site ask adjacent but distinct questions:

Framework	What It Asks	What This Post Asks
#101 — Dependency Recovery Blindness	What hidden dependency prevents recovery from completing?	Who has standing to release an asset that was never hidden in the first place?
#122 — Recovery Dependency Collapse	Which recovery dependency became unavailable during recovery?	Does ownership grant a recoverable access path at all — independent of any incident?
#144 — Disaster Recovery Authority	Did the incident degrade the internal chain an organization needs to execute its own recovery?	Did the organization ever have a direct path to the party holding its data, incident or not?
#169 — Authority Persistence Boundary	Can authority remain valid after the trust relationship that justified it has failed?	What happens when the trusted intermediary disappears entirely, revealing a path that was never built to the actual custodian?

Both #122 and #144 live in the Disaster Recovery & Failover Architecture stage of the Data Protection Learning Path, if either warrants a deeper read.

None of these are wrong to invoke here — they’re neighbors, not overlaps. This post’s failure predates any incident, requires no compromised trust, and would exist even if OSS had shut down quietly instead of disputing anything. Ownership was never in doubt. The path to exercise it was.

A closer cousin runs the same clock-mismatch shape in the opposite direction: a vendor’s audit rights outliving a customer’s declared exit, the subject of Vendor Relationships End. Audit Rights Often Don’t. There, the customer thinks the relationship is over and the contract disagrees. Here, the owner’s rights never extended far enough to reach the custodian in the first place. Same underlying pattern — an operational milestone and the parallel legal reality run on clocks nobody owns jointly — running in opposite directions.

Architecture Check

Data protection architecture planning routinely tests durability, retention, and restore integrity. It almost never tests the one thing this case actually broke:

None of this requires new tooling or a new assessment category. It requires treating the retrieval path as an architectural property — one that can be validated in advance, the same way durability already is — rather than something an organization discovers it never had, at the exact moment it needs it most.

Verify before staging: confirm the Recovery Readiness Assessment’s actual scope covers intermediary/retrieval-path exposure before this sentence ships. If it doesn’t, this CTA promises a diagnostic the assessment doesn’t perform — swap to a more general Infrastructure Architecture Review framing instead rather than overclaim the assessment’s coverage.

Additional Resources