{"id":3023,"date":"2026-11-01T06:55:00","date_gmt":"2026-11-01T06:55:00","guid":{"rendered":"https:\/\/www.cancershospitals.com\/blog\/?p=3023"},"modified":"2026-11-01T06:55:00","modified_gmt":"2026-11-01T06:55:00","slug":"datasecops-cancer-registry-release-steps","status":"publish","type":"post","link":"https:\/\/www.cancershospitals.com\/blog\/datasecops-cancer-registry-release-steps\/","title":{"rendered":"Releasing a Cancer Registry Safely: A DataSecOps Walkthrough"},"content":{"rendered":"

Sooner or later every oncology registry faces the same request: a research group, a public-health agency, or an AI team wants an extract. Handing over raw rows is indefensible; refusing every request starves the science. DataSecOps<\/strong> treats the middle path \u2014 a controlled release \u2014 as a procedure rather than a leap of faith, and this walkthrough follows the procedure end to end for a hypothetical registry of three thousand treatment records. The term itself dates to 4 August 2021, when Satori Cyber’s Ben Herzberg attached it to security work embedded in the flow of data that never stops changing, and nothing in that definition is a standard; the established name for the discipline remains data security governance. What follows borrows its rigour from published rules, and every claim below traces to one of them; the DataSecOps practice notes at Ops Atlas<\/a> hold the wider loop this procedure hangs from.<\/p>\n

Step 1: Freeze the extract and inventory every field<\/h2>\n

Decide the extract’s shape before touching any value. Which tables, which date range, which columns \u2014 write it down, then run discovery against that scope so nothing outside it moves. The inventory matters because registries hide identifiers in unsuspicious places: treating-consultant names in free-text notes, device serial numbers in pathology fields, appointment timestamps that triangulate a small-town patient. Classification software produces the first pass, and a person reviews each tag, because scanners in the Google and Presidio families demonstrably miss values and over-flag others. The evidence habit starts here: the inventory memo, dated and versioned, becomes the first exhibit in the release file.<\/p>\n

Step 2: Run the eighteen-identifier sweep<\/h2>\n

Where the destination is the United States research context, HIPAA’s Safe Harbor list sets the floor. Eighteen identifier categories must leave the dataset before anyone may call it de-identified \u2014 names, geography finer than the first three postcode digits, most dates, contact details, record and account numbers, biometric templates, photographs, and the rest of the statutory roster. Two clauses deserve special attention for a cancer registry. Where a postcode area holds twenty thousand people or fewer, the digits collapse to zeros. Every age above eighty-nine folds into a single band, because a ninety-four-year-old with a rare tumour is close to unique without that rule. Analysts hate both clauses; regulators wrote them anyway, on evidence.<\/p>\n

Step 3: Pick one DataSecOps treatment per field<\/h2>\n

The sweep handles the obvious; the judgement calls remain, and they split into distinct operations that must not be confused with one another. The de-identification guidance published as NIST SP 800-188 draws the line clearly: masking hides values from eyes without a need to see, while de-identification prepares data to leave the protected zone with measured leftover risk. The menu runs from generalising a value (age bands instead of birth dates) through masking at query time (the registry keeps its truth; the extract viewer sees asterisks) to pseudonymisation (names swapped for keyed codes under GDPR Article 4(5), the technique Article 32 lists among proper security measures and Article 25 expects designs to apply). Registries that personalise therapy per patient \u2014 the practice described in how cancer hospitals build personalized treatment plans<\/a> \u2014 feel this tension daily, because the granular data that steers treatment is exactly the granular data that identifies.<\/p>\n

Step 4: Measure what the treatment leaves behind<\/h2>\n

De-identification without arithmetic is a slogan. The classic result still governs the risk estimate: Latanya Sweeney’s experiment showed 87 percent of Americans uniquely identifiable from postcode, sex, and date of birth together, which is why the Safe Harbor sweep removes precisely those combinations. After treatment, quantify what remains \u2014 how many records keep a unique signature across the released columns, and how joinable the hashed fields are. The hashed-email question deserves its own paragraph in this memo: a deterministic hash yields one output per input, so hashed addresses link records across tables and fall to a dictionary attack whenever the attacker holds a candidate list. Call it pseudonymisation, because that is all it is. Luxembourg’s highest court sharpened the picture on 4 September 2025: ruling in the EDPS v SRB appeal (C-413\/23 P), the Court of Justice decided that pseudonymised records do not, for such a recipient, carry personal-data status at all, while the keyholder’s own copy keeps that status throughout.<\/p>\n

Step 5: Gate the exit before the file moves<\/h2>\n

A prepared extract still has to leave the building, and the exit is where records leak. Egress controls belong in the plan, not after it: export commands whitelisted, bulk downloads logged and size-capped, data-loss-prevention rules watching the channels files actually travel. The draft guidance from the European Data Protection Board \u2014 Guidelines 01\/2025 \u2014 tempers optimism here too, cautioning that name-swapping does not, standing alone, make circulation safe, so the board expects the surrounding controls to carry real weight. For the registry team, that means the release memo names the exact route the file takes, who may pull it, and when the permission dies. Bulk commands deserve a specific line, too: whichever verb the warehouse uses for writing results outward \u2014 export, unload, copy-out \u2014 goes on the whitelist with a named destination and a row ceiling, and every other path fails closed. The same evidentiary thinking helps patients judge any institution that will hold their records; the questions worth raising after receiving a cancer diagnosis<\/a> now include who can export a record, and under whose sign-off.<\/p>\n

Step 6: Date the DataSecOps decision and keep the receipt<\/h2>\n

The final step converts good work into provable work. The release memo records the scope, the sweep results, the per-field treatments, the residual-risk arithmetic, the egress route, and the sign-off \u2014 each with a date and a name. Read-access history on the destination system then keeps the receipt current: it shows who opened the extract and when, which is what a review needs when it reconvenes next quarter. Data protection authorities no longer accept vibes on this point, and neither do research-ethics boards. A dated memo costs an afternoon; reconstructing one after an incident costs a lawyer.<\/p>\n

What the walkthrough proves<\/h2>\n

Six steps, one principle: the release is a decision, and decisions leave records. The pattern generalises beyond research extracts \u2014 second-opinion packets sent between hospitals, cost-estimation datasets shared with insurers, quality registries reported upward \u2014 anywhere a cancer record crosses a boundary. Patients comparing institutions absorb this instinct quickly, whether they are reading about costs, support, and second opinions<\/a> or auditing a hospital’s privacy page; the organisations that can show their memos are the ones that have actually done the work.<\/p>\n