# Governing privacy and equity on legacy systems
A caseworker in a county benefits office types a client's name into a modern case-management dashboard. Behind the screen, that dashboard is quietly pinging a mainframe installed when Reagan was president. The mainframe holds 40 years of eligibility history in a format almost no one on staff can read anymore. To help this one client, the county has to link those two systems. That single act of linking is where privacy risk, equity risk, and technical debt all collide.
This lesson walks through that linkage decision. It is a common one in public agencies, and it is rarely as simple as "just connect the databases."
Most people assume government runs on old technology because agencies are lazy or underfunded. The real reasons are structural.
Benefits systems (unemployment insurance, Medicaid eligibility, SNAP) often run on COBOL, a programming language from 1959 that still processes a large share of government transactions. During the 2020 unemployment surge, several states publicly asked for COBOL programmers because their systems could not scale.
You cannot simply replace these systems. They work. They are load-bearing. A failed modernization can cut off benefits to real people for weeks. So the practical reality is: you govern data on systems you did not choose and cannot fully change.
Say you want to link two records:
To connect them, you need a join key, a shared field that matches a record in one system to the same person in the other. The obvious key is the SSN. That is also the most dangerous field you could possibly move around.
Here is the tension in one line:
The field that makes linkage EASY (SSN)
is the same field that makes RE-IDENTIFICATION easy.Re-identification is when supposedly anonymous data gets traced back to a specific person. Classic research showed that a large share of the US population can be uniquely identified by just ZIP code, birth date, and sex. So stripping names is not enough.
Instead of copying SSNs between systems, teams increasingly use a hashed identifier or a separate master person index.
Hashing runs the SSN through a one-way function that produces a scrambled string. The same SSN always produces the same hash, so you can still match records, but the raw SSN never leaves the mainframe.
import hashlib
def link_key(ssn: str, secret_salt: str) -> str:
# salt prevents attackers from precomputing hashes of every SSN
return hashlib.sha256((secret_salt + ssn).encode()).hexdigest()
# Same person, same key, across both systems. Raw SSN stays home.
link_key("123-45-6789", secret_salt="agency-only-value")The salt (a secret value added before hashing) matters. Without it, an attacker can hash all possible SSNs (there are fewer than a billion) and reverse your "anonymous" keys in minutes. This is not theoretical: unsalted hashing has caused real breaches.
For a plain-language grounding in de-identification methods, the US Department of Health and Human Services guidance on de-identifying protected health information is a solid free reference, even outside healthcare.
Public sector data linkage usually triggers formal rules. Define these on first use:
Purpose limitation is where public trust is won or lost. If clients believe their benefits data might be handed to immigration enforcement, they stop applying, even for benefits their children legally qualify for. That chilling effect is a documented equity harm, not just a privacy footnote.
🎬 [VIDEO: "The Privacy Paradox in Government Data" — youtube.com — an accessible overview of how agencies balance data utility against re-identification risk]
Once systems are linked, agencies often build tools on top: a risk score to flag likely fraud, or a model to prioritize outreach. This is where an algorithmic equity audit comes in.
An equity audit checks whether a data-drivendata-drivenAn approach where decisions are systematically informed by data analysis rather than intuition alone.View full definition → decision produces different outcomes across groups (race, disability status, language, geography) in ways that are not justified.
The legacy angle makes this harder. Old mainframe data encodes old assumptions.
Suppose the 1985 system only recorded certain benefit categories that were common in wealthier suburbs, while rural and immigrant applicants were more often processed on paper and never fully digitized. Decades later, a model trained on that mainframe history "sees" less data for those groups.
Fewer records can look like lower need, or it can inflate a fraud score because the person's history looks "thin" or "inconsistent." The bias is not in the code. It is baked into what got recorded 40 years ago.
An honest equity audit therefore has to ask two questions:
1. Outcome fairness: are error rates similar across groups? (For example, is the false-positive fraud rate higher for one language group?)
2. Data provenance: who is systematically missing or thinly represented in the source data, and why?
Skipping question two is the most common mistake. Teams audit the model and declare it fair, without noticing the underlying data was never neutral.
A useful first pass is a subgroup comparison. You do not need advanced math to start:
| Group | Flagged rate | Confirmed-correct rate | False-positive rate |
|-------|-------------|------------------------|---------------------|
| Group A | 8% | 90% | 10% |
| Group B | 8% | 62% | 38% |
Equal flagging rates (8% each) can hide very unequal error rates. Group B here is wrongly flagged far more often. That is the pattern an audit exists to surface.
Knowledge check
1. According to the lesson, what is the primary reason public agencies continue running on legacy systems like COBOL mainframes?
2. What is a 'join key' in the context of linking a mainframe record to a modern case-management record?
3. Why does using the SSN as the join key create the central tension described in the lesson?
4. Select ALL correct answers. Which risks does the lesson say collide in the single act of linking a legacy mainframe to a modern dashboard?
Select all the correct answers.
5. Select ALL correct answers. Which statements accurately reflect the challenges of governing data on legacy benefits systems?
Select all the correct answers.
You have three forces: privacy risk, equity risk, and a mainframe you cannot replace. Here is how experienced teams navigate them.
Do not lift the whole mainframe into the modern tool. Move the smallest possible slice needed for the task, using hashed keys, not raw SSNs. Less data in transit means less to breach and less to re-identify.
You often cannot touch the mainframe safely. Instead, teams build a middleware layer (sometimes an APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.View full definition →) that sits between the old system and the new one. The mainframe stays untouched. The middleware controls exactly what data passes and logs every access.
Logging matters for equity too: you cannot audit what you did not record.
Write a short data provenance note for each field: where it came from, what era, known gaps. When someone later builds a risk model, that note warns them that "thin history" may mean "processed on paper in 1990," not "low need."
Equity audits work better when the people represented in the data help interpret it. A missing-data pattern that looks like fraud to an analyst may be obvious to a community advocate who remembers the paper-based intake process.
Set thresholds before you launch. If false-positive rates differ across groups by more than an agreed amount, the tool pauses. Deciding this ahead of time removes the temptation to rationalize a biased result once money and reputation are on the line.