Security Control Decay: The Risk You Already Signed Off On
When did lost technology last turn up inside your own program? I don't mean the museum kind. I mean a control you stood up years ago, still on the books, quietly rotting since the day it went in. And here's the harder one. If it no longer does what you certified, whose name is on the attestation that says it does?
If you're carrying that question, good. It means you already sense the gap between what you're accountable for and what's actually holding.
Here's the short version first. Lost technology, or security control decay, isn't a control that fails on a Tuesday. It's a skill that erodes over time, across handoffs, until the work barely resembles what was originally certified. One step is omitted or dropped. A standard drifts. Nobody meant any harm. Then you, as the responsible person, attest the control is in place and working. But the honest answer is that you no longer know. That's the exposure.
The version that started perfect, but then slipped
Lost technology is a craft once performed at full skill that leaks away, one omission at a time, until the later work is visibly worse than the early work. This is most evident with the Egyptians in their granite stonework. Their earliest hard-stone work is so exact it still stops engineers cold, and their later work, same civilization, same quarries, doesn't even remotely come close.
Picture the red and pink granite out of Aswan, one of the hardest stones on Earth. Early Egyptian craftsmen bored clean round holes straight through it and cut faces true to a fraction of a millimeter. Somebody had defined what this standard looked like, and the craft could literally hit it every time, without variance. That work has stood four thousand years through floods and earthquakes, and it's still sharp.
Now walk the centuries forward and watch the same civilization do the same job. The cuts get rougher. Joints stop fitting. The precision slips. Historians place the finest hard-stone work at the very beginning and track the fall from there. Egyptologist Andrew Bevan documents the quality, quantity, and variety of hard-stone vessels already in decline by the Fourth Dynasty, the craft carrying on afterward only in a thinner, cruder form. A 2025 study in npj Heritage Science scanned Predynastic vessels and confirmed the early precision was real, done by hand, held to exacting tolerances and perfection.
The standard never changed. However, it stopped being met in the hand holding the tool. Each generation kept a little less, nobody noticed the small exception, and then you line up early against late and the loss is impossible to miss.
Ever watch that happen to a process you owned? A runbook that was tight two reorgs ago, and now nobody can explain half of it?
How a craft leaks away, following an invariable law
The mechanism of decay is the same in a security program as in granite: a step gets skipped because nobody remembers why it mattered, and the next person inherits the version with the hole and assumes that's how it always was. Not direct sabotage. Neglect, compounding quietly, until the current work barely resembles what you started with.
This is where the word “Technology” deserves critical attention. It comes from the Greek tekhne, art, craft, and practiced skill, joined to -logy, the study of it. Technology is never the tool or the license. It's the applied craft of putting the thing to use well, or poorly. Owning the tool was never the same as having the skill, and having it once is never the same as keeping it. A craft that's fed continues. A craft or skill left alone decays. There isn’t any holding still.
Put your own environment in place of the stone. None of the drift announces itself. It accumulates, the way a shortcut becomes a habit, until you're looking at late granite and calling it done. Watch where it creeps in:
- Your M365 front door access policy stood up two years ago by an engineer who's since moved on.
- An MFA rollout that started strong, then took a quiet exclusion for a vendor, an executive, then another and another, etc.
- A break-glass account created for a real reason nobody has tested since.
- A standard trimmed to whatever was easy in the moment, but never restored.
Reading a live security policy for that drift before it's expensive is a specific skill, and one we drill with teams in our coaching sessions.
When that decayed control has your name on it
For a CISO, the cost of lost technology isn't the rough cut. It's that the decayed and accumulated controls are the ones you attested were working to a board, an auditor, an insurer, and possibly a court. The stone worker's bad joint stayed in the wall. Your bad joint sits under a signature.
The engineer owns whether the control operates. You own whether the risk is defensible and documented, on someone else's clock. When a control decays without you knowing, three things stop being true at once.
- The board heard the control was working, so you lose the room the moment it isn't.
- The insurance application said the control covered what it no longer covers. In Travelers v. International Control Services (2022), after a ransomware claim the carrier moved to void the company's $1 million policy, because the application said MFA protected privileged access and the forensics said it only covered the firewall. The policy was rescinded. An erroneous attestation like that can erase your coverage after the loss.
- The exposure lands on you personally. A security chief was criminally convicted over a breach cover-up, and the SEC charged a CISO over security disclosures. However those cases resolve, they changed how every person in the chair reads their own liability.
There's a false belief driving the whole failure: that a control, once configured correctly, stays correct. It might hold for a bit, but it doesn't. Configuration is a moment. The craft is keeping it true as people, vendors, and threats move underneath it. Miss that and you're attesting to a snapshot from two years ago.
Ever certified something as working because it was working the day you checked, and never went back? Most of us have. The Egyptians would easily recognize it too.
The confidence side is just as concrete, and it's provable rather than hopeful. When the standard is written down, taught with its reasons, and reviewed on a cadence, your team reads a policy and catches the drift in minutes, and you walk into the board room with evidence instead of a promise.
The cure the Egyptians never applied
If you could go back and stop the Egyptians from losing the craft, you already know what you'd tell them, because it's the same thing that holds any security program true. It's the model we coach, in three plain parts. Standards: define what right looks like and write it so it doesn't leave when a person does. Application: hit the bar today and pass it on with its reasons intact, because a step nobody understands is a step someone will drop. Review: measure real work against your standards to catch any drift while it's still inexpensive, then update both as threats move or evolve. Do all three and it compounds. Skip them and it decays the same way every time, until you're paying to patch damage that never had to happen.
Here's where to start this week, whatever your size:
- Pick the two controls you'd least want to be wrong about in front of a regulator. Verify each against what you last attested, not against memory.
- Find one control whose original owner has left. Write down what it should look like, and why, before that knowledge is gone.
- Put a recurring review on the calendar that compares current state to the written standard. A break-glass test and a Conditional Access drift check are good first passes.
- Before you sign the next attestation, ask one thing of each claim: is this true today, or was it true the day we built it.
A year from that, the room feels different. The board asks if you're secure and you reach for evidence instead of hope. An insurer's questions don't make your stomach drop. The controls you signed off on are the ones actually protecting or running, because someone is keeping the craft and skill alive on purpose. Same cure the Egyptians skipped, standing in front of stone we still can't reproduce.
FAQ
Q. What does “lost technology” mean in cybersecurity?
A. It's a security capability that decays across handoffs until the real work no longer matches what was designed or certified. No single failure causes it. A dropped step, a quiet exclusion, an untested account add up until a control you consider solid has holes you can't see.
Q. Why is control decay a personal risk for a CISO specifically?
A. You attest to controls in front of boards, insurers, auditors, and regulators. When a control decays silently, your attestation goes false without you knowing. That can void insurance coverage after a loss and, in recent cases, expose the person in the seat to legal liability.
Q. Isn't a control safe once it's configured correctly?
A. No. Correct configuration is a single moment. People leave, vendors change, exclusions get added, threats shift. Without a review that compares live state to the written standard, a control that was right two years ago can drift into something you'd no longer certify.
Q. What's the fastest way to catch this before an audit?
A. Verify your highest-stakes controls against your most recent attestation, not from memory. Write down the standard for any control whose owner has left. Then confirm each attestation claim is true today, not just true the day it shipped.
Glossary
Lost technology: a craft or capability that erodes gradually as it passes hand to hand, until the current work is a degraded version of the original, often without anyone noticing the decline.
Attestation: a formal statement, to a board, insurer, auditor, or regulator, that a control or practice is in place and working. Its accuracy is the CISO's responsibility.
Control drift: the slow divergence between how a security control was designed and how it actually behaves now, caused by changes, exclusions, and neglect over time.
Break-glass account: an emergency administrator account kept for when normal access fails. It needs testing and tight controls, or it becomes a forgotten risk.
Conditional Access: a Microsoft Entra policy engine that decides whether to allow, block, or challenge a sign-in based on conditions like user, device, location, and risk.
Residual risk: the risk that remains after controls are applied. A CISO's job is to make that remaining risk defensible and documented.
