The Last 20% Is Where The Risk Lives

Every IT leader knows this feeling.

A critical issue lands. The team mobilises. Stakeholders are briefed. Decisions are made quickly. The most visible and urgent parts of the problem get resolved. And then, gradually, the crisis passes. The noise dies down. The team moves on to the next thing. And the backlog quietly absorbs everything that was not quite urgent enough to stay on fire.

Six months later, twelve months later, the thing you half-fixed comes back.

Not because your team is incompetent. Because organisations are not designed to finish things. They are designed to respond to urgency. And urgency is a finite resource.

This week, Polyfill made that argument better than I ever could.

In 2024, the polyfill.io domain was acquired by a Chinese entity after expiring. The new owners began injecting malicious JavaScript into scripts served by the CDN, affecting over 100,000 websites that had a dependency on the service. The security community raised the alarm clearly. Developers were told to remove the dependency. The domain was flagged as malicious. Guidance was published, warnings were issued, and most organisations acted. The incident was resolved, filed away, and the world moved on.

Except it was not fully resolved. Not everywhere.

In late May 2026, the domain came back to life. It began responding to requests with HTTP 401 authentication challenges. Any website still carrying a reference to polyfill.io, even a dormant one, even a single forgotten script tag buried in a template, suddenly started serving fake login prompts to its visitors. The prompts looked like native browser authentication windows, not phishing pages. Toshiba warned its users. Muji did the same. Zojirushi, FiNC Technologies, Ishiyaku Publishers, and Hobonichi were all affected. Samsung Smart TVs were serving the rogue authentication dialogs from June 1. The organisations affected are not small, careless, or incompetent. They are large, well-resourced companies with technical teams. They just did not finish the job in 2024.

The cleanup tasks went into the backlog. The next urgent thing arrived. Nobody came back.

I have seen this pattern more times than I can count, and I have seen it in every context, infrastructure programmes, cloud migrations, security remediations, software upgrades, organisational restructures. The shape is always the same. A significant piece of work gets 80% done. The most visible risk is addressed. The pressure lifts. And the remaining 20%, the edge cases, the legacy dependencies, the awkward exceptions that do not fit the standard process, those get parked with the intention of coming back to them.

The intention is genuine. The return rarely happens.

The reason is structural, not motivational. Organisations reward the teams that respond to incidents. The recognition, the visibility, the career progression, all of it flows toward the people who were in the room when the crisis was happening. Nobody gets promoted for closing out the tail end of a remediation programme six months after the incident it was responding to. The incentive to finish is weaker than the incentive to respond to what is on fire right now.

This is not a security problem. It is a leadership and governance problem. The question of what happens to the work that was started but not completed is a management question, and in most organisations it does not have a clean answer.

The Polyfill story is a supply chain illustration, but the pattern it represents shows up in every area of IT. The migration that left forty servers on the old platform because they were complicated. The access review that was 90% complete when the audit window closed. The configuration hardening programme that covered production systems and quietly stopped before it reached development and test. The decommission project that removed the main system but left the backup, the archive, and the reporting extract running on infrastructure that nobody is patching.

Every IT estate I have ever worked in has a version of this. A programme that was declared complete because the critical path was done, while the things that did not make the critical path are still sitting exactly where they were.

The dangerous thing about the last 20% is not that it exists. It is that it is invisible. The incidents and the dashboards and the risk registers all reflect what people are actively looking at. The half-finished remediation from last year is not on anyone’s radar because it was officially resolved. It sits in a state that looks like done but is not, and it waits.

Polyfill waited two years. Then it came back.

The question I would ask of any IT leader reading this is not about their current incidents or their active programmes. It is about what got 80% resolved the last time something urgent landed. What is the thing in your estate right now that everyone thinks is finished but is not quite?

That is where the risk lives.