Your security team's growing backlog is not their fault
When every vulnerability alert lands on the security team's desk, the result is not accountability. It is a queue that never shrinks. A clearer split of duties is the only fix.

Key points
- Most organisations wrongly assign both the discovery and the fixing of security weaknesses to the same small security team, creating a backlog that grows faster than it can be cleared.
- The U.S. National Institute of Standards and Technology (NIST) explicitly describes patching, which means applying software updates to fix known weaknesses, as routine business maintenance, not a specialist security task.
- CISA, the U.S. Cybersecurity and Infrastructure Security Agency, publishes a free Known Exploited Vulnerabilities Catalog that helps organisations decide which weaknesses to fix first based on real-world criminal activity.
- Stricter deadlines alone cannot shrink a backlog when the teams responsible still lack the time, tools, or authority to do the work.
- Executives, not security staff, must make the final call when a fix clashes with a product launch, a customer commitment, or a budget limit.
Picture a hospital maintenance team that is expected not only to inspect every fire door in the building, but also to replace the hinges, repaint the frames, and chase the ward managers to sign off the paperwork. Their inspection log would grow forever, and they would be blamed for a problem that was never really theirs to solve.
That is precisely how most organisations run cybersecurity today.
Who actually owns the problem?
Security teams should own the list of risks and set the priorities. They should not own the act of fixing things. That distinction, straightforward on paper, is ignored constantly in practice.
When a scanning tool, software that automatically checks systems for known weaknesses, flags an outdated piece of software, the security team is expected to patch the server. When a cloud platform, meaning an organisation's rented computing infrastructure hosted online, flags an open storage bucket exposing company data, security is expected to redesign the setup. When an audit finds that too many staff have access to a sensitive business system, security is expected to negotiate the access changes with the relevant department.
None of those things is a security job. Each is an operational job that security spotted.
CSO Online made a related point recently: patching deadlines, known in the industry as SLAs or service-level agreements, should be the floor of a strategy, not the strategy itself. Green compliance numbers can hide the small handful of genuinely dangerous risks that matter most.
Why stricter deadlines make it worse
Tightening the deadline changes nothing about capacity. Telling an engineering team that critical vulnerabilities must be fixed within 15 days does not give that team an extra 15 days of spare time. The servers still need maintaining. The product still ships on Friday.
A backlog is a record of unanswered management questions: Who owns this system? Who can approve the change? What else gets delayed if this jumps the queue? When leadership does not answer those questions, the finding simply ages on the dashboard, and the security team gets blamed for a list they can read but cannot clear.
How should the work actually be split?
The model recommended by NIST's Cybersecurity Framework 2.0 and its enterprise patch management guidance is straightforward.
| Role | Responsibility |
|---|---|
| Security team | Risk inventory, prioritisation, escalation, closure verification |
| Infrastructure teams | Patching servers, endpoints, and network devices |
| Cloud platform teams | Fixing identity, storage, and logging controls |
| Application teams | Updating code dependencies, redesigning vulnerable features |
| Business system owners | Approving workflow and access changes |
| Executives | Resolving conflicts between remediation and business priorities |
For prioritisation, CISA recommends using its Known Exploited Vulnerabilities Catalog as a primary input. A medium-severity flaw that criminals are actively exploiting in the wild is more urgent than a critical-rated flaw sitting on an isolated test machine that no one outside the building can reach.
What should ordinary employees watch for?
If your organisation is telling a small IT security group to both find and fix every weakness, raise it. That model creates a backlog that becomes a liability. Staff in any department who own systems, manage software, or approve access requests are part of the fix chain whether or not they hold a security title.
When a security team flags a risk in your area, the question to ask your manager is simple: who has the authority to get this fixed, and is that person aware of it?


