What the Netflix Fortitude Case Teaches About Digital Asset Custody

Start with the drive, not the headline

The lawsuit over Netflix, Fortitude, and a stolen hard drive is, for now, a reported custody dispute built from a complaint, a docket entry, and public responses—not adjudicated findings. Op-Fortitude Ltd. v. Netflix, Inc. was filed in the Central District of California on July 29, 2026; the PacerMonitor docket identified the case as No. 2:26-cv-08384, with no answer or motion reflected in the available docket check as of July 30, 2026.[1][2]

For who filed, why the figure is large, and what the docket showed at filing, use the existing Risk Digest records: Who filed the Netflix $105 million lawsuit?, Netflix $105M Lawsuit Details Are Filed, Outcome Pending, and Why Netflix Faces a $105M Lawsuit Over a Missing Film. The narrower question here is what a verification workflow would have required at each point where custody could still be proved.

The custody sequence the complaint puts in issue

The complaint’s load-bearing sequence is compact. It alleges that on June 15, 2026, associate producer Daniel Haido hand-delivered an unencrypted DCP master of the unreleased film Fortitude to Netflix’s Sunset Bronson Studios office, with verbal and written instructions to delete the file after the screening. It further alleges that the drive was left on a desk.[1]

The next ten days matter more than the celebrity angle. The complaint alleges pickup requests between June 17 and June 25, 2026; delayed or ignored retrieval efforts; and a June 25 email from Netflix head of film acquisitions Sean Berney disclosing that the hard drive had been stolen.[1] It also alleges that Netflix did not confirm deletion, did not confirm filing a police report, and did not involve the LAPD after the filmmakers filed their own report.[1]

Those assertions are not findings. They are useful here because they create a traceable map: delivery, storage, screening, deletion, retrieval, incident disclosure, and law-enforcement referral. A risk manager would not need to decide the merits of the lawsuit to see where the record should have existed.

At delivery, the missing record is the encryption decision

If the complaint’s version is right, the first control point failed before anyone got to deletion. An unencrypted DCP master is not just a technical detail; it changes who must prove protection after the handoff. The workflow record should have said one of two things: the asset arrived encrypted with the required access controls, or the asset arrived unencrypted under a documented exception accepted by named people on both sides.

That record would not have needed theatrical language. It would have needed a manifest: asset identifier, file format, drive serial or device identifier if available, encryption status, password or KDM handling status if applicable, delivery time, delivery location, sender, recipient, and exception approval. If the item was accepted without encryption, the exception should have stated who owned the temporary storage risk until deletion or return.

Netflix’s public position makes this point sharper, not cleaner. Bloomberg Law reported that Netflix disputed bearing the risk of loss, said the film was delivered without industry-standard safeguards including encryption or password protection, and described the pre-suit demand as hostile attempts to extort money.[3] That is a public position, not a docketed answer in the checked record. But it shows why the encryption field cannot be left to memory after a drive disappears.

There is also a source-hygiene problem. The operative complaint and complaint-consistent coverage describe the master as unencrypted, while an outlier secondary description elsewhere used the opposite label. That conflict is not a reason to pick the more dramatic version. It is a reason to require an encryption manifest at intake, signed or acknowledged before the drive moves beyond reception.

A deletion instruction is not deletion evidence

The complaint alleges both verbal and written instructions to delete the file after the screening.[1] That is a meaningful fact, but it is not the control. The control is the later record that says deletion happened, who performed it, when it happened, what locations were covered, and whether any copies or temporary files were included.

A deletion confirmation does not have to be elaborate to be useful. It should answer questions that become painful only after loss: Was deletion requested or required? Was it a condition of screening access? Did the receiving party acknowledge it? Was deletion completed before the drive was stored, before pickup was requested, or not at all? Was the confirmation sent to the producer, a legal contact, a security contact, or nobody?

The complaint’s KDM and new-DCP allegations belong here, but only carefully. Plaintiffs allege Netflix later claimed a KDM was needed to access the DCP and offered to create a new DCP; plaintiffs use those points to argue that the files may not have been deleted.[1] That is a contested inference. It is not proof that a copy remained, and it is not proof that deletion failed. It is evidence of why deletion should never depend on implied technical behavior when a written attestation could have existed.

The desk problem is really a named-custodian problem

The allegation that the drive was left on a desk will draw attention because it is visually simple.[1] The harder operational question is who had custody at that moment. A desk is not a custodian. A studio office is not a custody term. A receptionist, acquisitions executive, assistant, security desk, screening coordinator, or archive function may all touch a delivery path, but only a named custodian can later be asked to confirm storage, access, transfer, deletion, or loss.

For high-value digital assets, the storage obligation should be written at intake. If a drive cannot be deleted immediately after screening, the receiving party should know whether it must sit in a locked cabinet, a restricted media vault, an evidence-style bag, an access-controlled room, or some other named storage location. The exact method depends on the organization. The record must show that someone accepted responsibility for it.

Retrieval requests needed a deadline and an escalation owner

The back end of the complaint is not just that a theft was disclosed on June 25. It is that the complaint alleges pickup requests began on June 17 and continued through June 25 before the theft disclosure email.[1] In a custody workflow, retrieval is not a courtesy scheduling thread. It is the point where silence becomes a risk event.

A verification workflow would assign a retrieval deadline when the item is delivered or when the screening ends. If pickup is requested and the drive is not returned, the system should identify the escalation owner before the next business cycle turns into a week of email reconstruction. The escalation owner should not be the person left guessing whether an assistant, acquisitions executive, or security desk has the drive.

• The pickup request should identify the asset, the expected return method, the requester, and the requested return date.
• The receiving party should confirm whether the asset is available, already deleted, already returned, or missing.
• If return is delayed, a named escalation contact should take ownership of locating it.
• If the item cannot be located by the escalation deadline, the matter should move from scheduling to incident response.

This is where many custody disputes become unfair to the person assigned to clean them up. They are asked to reconstruct possession from inbox fragments, calendar memory, and assurances that were never converted into confirmations. The lawsuit’s allegations are still allegations, but the reconstruction burden is familiar.

The theft disclosure should have triggered a second record trail

Once theft is disclosed, the workflow changes. The complaint alleges the June 25 disclosure came by email from Sean Berney.[1] At that point, the important questions are no longer only where the drive was. They are who received notice, who inside each organization was escalated, whether security or legal was engaged, what retrieval attempts remained open, whether access credentials or KDM handling had to be changed, and whether law enforcement was contacted.

The complaint alleges Netflix would not confirm filing a police report or involving the LAPD after the filmmakers filed their own report.[1] That is another disputed allegation, but it identifies a concrete verification field. “Police report filed” should not be an oral assurance. The workflow should capture report number if available, agency, filing party, date, contact person, and any instruction limiting what can be shared.

Breach-notification timing is similar. The complaint does not, by itself, establish a statutory notification violation. The operational control is simpler: when a high-value unencrypted asset is missing, the incident record should show when the owner was notified, who approved the language, what was known versus unknown, what was being done to retrieve or contain the asset, and when the next update was promised.

Why the no-leak point matters, but does not close the file

CBS News reported the lawsuit over the allegedly lost master copy and did not identify a public leak in its coverage; the available source check likewise found no leak as of the July 30–31 reporting window.[4] That matters because an unreleased film is a high-value asset whose damage theory depends partly on exposure risk. It does not answer the custody question.

A no-leak status can be true and still leave a custody failure unresolved. The drive may be missing without a known leak. The file may be inaccessible, deleted, copied, or never accessed. The available record does not establish those outcomes. A good workflow separates leak monitoring from custody proof, because one is an external observation and the other is an internal record.

Six custody checkpoints the Fortitude record puts on the table

The closest site model is not another case recap; it is a verification workflow, like How to verify a perpetual purpose trust’s legal structure. The same discipline also appears in incident-response records such as FBI proof-of-life verification for AI deepfake evidence: do not stop at the alarming event; identify the proof that should exist after each handoff.

None of those checkpoints decides liability in Op-Fortitude v. Netflix. They do something less dramatic and more useful: they make the next reconstruction possible. As of the July 30, 2026 docket check, Netflix had not yet answered in the available docket record, and the complaint allegations remained pending response.[2]

References

1. Complaint, Op-Fortitude Ltd. v. Netflix, Inc. (C.D. Cal. No. 2:26-cv-08384, filed 7/29/2026) — PacerMonitor — July 29, 2026
2. OpFortitude Ltd, a United Kingdom company v Netflix, Inc, a Delaware corporation — PacerMonitor
3. Missing Nicolas Cage Film Spurs $105 Million Netflix Lawsuit — Bloomberg Law
4. Netflix sued for $105 million for allegedly losing master copy — CBS News