What you deleted is still in the file

On 25 September 2026 Microsoft published its account of an intrusion it tracks as Storm-3168, run by JADEPUFFER, an actor Sysdig discovered in July 2026 and reported as the first documented agentic ransomware operation. Most of the write-up is about what happened inside a cloud tenant at machine speed: about fifteen and a half hours of enumeration with more than three hundred successful read operations, then a destructive sequence lasting roughly seven minutes and involving over a hundred attempts to delete storage accounts.

The part worth borrowing is at the start, before any of that.

The attacker held a service principal's client ID, client secret and tenant ID. Those had been posted, in plaintext, in a public GitHub issue by an employee of the affected organisation. In Microsoft's words, "the issue was later edited to remove the secret, but the secret remained accessible through the issue's public edit history".

Nobody involved did anything unusual. An issue tracker keeps an edit history because people want to see how a thread changed. The person who removed the secret removed it from the view. Removing it from the container is a different operation, and that operation has no button.

Documents work the same way

This is not a property of issue trackers. It is a property of anything that stores a history of itself, and the document formats your organisation runs on are full of history by design.

A tracked deletion is stored, not discarded. Delete a paragraph in a Word document with change tracking on and the text is retained in the file as a revision mark so that it can be reviewed or reinstated. That is the entire point of the feature. It stops being a feature at the moment the file leaves the building with the revisions still in it.

Resolved comments are still comments. Resolving a reviewer's note marks it as dealt with. It does not remove the note, or the name of the person who wrote it, or the timestamp that says how late in the process somebody raised the objection.

A crop is a display instruction. Crop a photograph to remove what was at the edge and, by default, the original image data stays in the file: the crop tells the application which part to display. Office ships a separate compression option precisely because deleting the cropped-out areas is a distinct action that somebody has to choose.

PDF is allowed to append rather than rewrite. The format permits incremental update: a change can be written on the end of the file, leaving the earlier objects in place, which is how signing and annotation work without rewriting a whole document. The visible result is the new version. The earlier one can still be inside the same file.

A black rectangle is a rectangle. Drawing a filled shape over a name hides it from a reader, and from nobody else. The text object underneath is still text, still selectable, still extractable by any library that reads a content stream.

None of this is obscure, and none of it is a vulnerability. Every one of these behaviours exists because someone reasonable wanted it. They add up to a single fact that release processes rarely account for: the document you send is not the document you are looking at.

Why the controls on the way out do not catch it

Ask what actually inspects a document as it leaves an organisation.

Data-loss tooling matches patterns, mostly over the text the file presents: account numbers, national identity numbers, classification markings, keywords. A human reviewer opens the file and reads the rendered page. An approval workflow records that a named person signed off on what they saw.

Every one of those is reading the view. The view is the one place the removed content is guaranteed not to be, because being absent from the view is the definition of removed that everybody was working to.

There is a folk remedy, and it is worth being honest about it. Exporting to a flattened PDF does drop a good deal of this material, which is why so many release processes end with a print-to-PDF step. It also destroys the working file: the formulas, the layers, the coordinates, the structure a downstream system or a counterparty's own tooling needs. The predictable outcome is that the recipient asks for the original, and the original is sent outside the control that the flattening step was standing in for.

The APAC reading

Two territories make the consequence concrete, and neither of them is interested in what the sender intended.

Singapore. The Personal Data Protection Act places the protection obligation on the organisation, covering personal data in its possession or under its control, and unauthorised disclosure is unauthorised disclosure whether or not anyone meant to disclose it. A tender response that carries the previous bidder's figures in its revision history has disclosed them.

South Korea. The amended Personal Information Protection Act was promulgated as Act No. 21445 in March 2026 and its main provisions took effect on 11 September 2026. It authorises administrative fines of up to 10% of a company's total revenue in high-severity cases, as reported by Hunton Andrews Kurth in its analysis of the amendment, which changes the arithmetic on how much personal data an organisation is willing to leave sitting in documents. The provisions making ISMS-P certification mandatory for certain controllers follow on 1 July 2027, which puts a dated deadline on being able to evidence the technical safeguards rather than assert them.

Fuller control mappings for both are on our country pages: Singapore and South Korea.

What helps, and what it does not do

The control has to work at the file layer rather than the view, which means two things in practice.

The first is removal of what the format retains by default: metadata, revision history, comments, document properties. Glasswall Find and Redact removes named data patterns from documents before they are stored or shared, which addresses the content an organisation can describe in advance.

The second is regeneration. Content Disarm and Reconstruction decomposes a file into its component parts, validates each against the manufacturer's published specification and manufactures a new file from that intermediate representation. The original bytes do not pass through, which is the difference between a rebuild and a clean-up, and the reason the output does not inherit structures the specification has no place for.

Now the honest limits, because a piece arguing that people over-trust their controls should not end by asking you to over-trust ours. Neither control decides what is sensitive: a paragraph of visible text that should never have been written is a human problem and stays one. Removing personal data from a document is not anonymisation in any legal sense, and nobody should present it to a regulator as though it were. And a control only ever reaches the files that are routed through it, which in most organisations is a smaller set than the diagram suggests.

What it removes is the part nobody knew was there. On the evidence of how documents actually leave organisations, that is the part that keeps arriving somewhere it should not.

The question worth taking to whoever owns the release process is narrow enough to answer this week: when a document leaves, what inspects it, and is that inspection reading the file or reading the page?