An enterprise platform's security review produces hundreds of findings across dozens of systems, and remediation capacity cannot keep up. What is structurally wrong, and what changes?
Show the full answer Hide the answer
What is structurally wrong
The security model is detective, and detective controls scale with headcount while findings scale with the estate. Beyond a certain size the backlog grows faster than it is cleared, and the organisation's compliance position is defended by exception rather than by design.
A second structural problem usually accompanies it: findings are not prioritised by exploitability, so remediation capacity is spent on volume rather than on risk. A thousand findings ranked by scanner severity is not a risk assessment.
What changes
1. Move the highest-consequence controls from detective to preventive. Deny-by-default policy at the control plane for the small set of actions whose consequences are severe and irreversible: public data exposure, unencrypted storage, credentials in code, unapproved regions. Prevention scales with automation; detection scales with people.
2. Fix classes, not instances. Two hundred findings of "missing security header" is one platform change, not two hundred tickets. The remediation unit should be the shared library, the base image, the service template — so fixing it once fixes it everywhere and prevents recurrence.
3. Rank by exploitability and blast radius, not by scanner severity. An internet-facing service holding customer data outranks an internal tool behind a VPN with the same nominal finding. This usually reduces the urgent list by an order of magnitude and makes it actionable.
4. Make the secure path the default path. A service template with authentication, secret management, logging and network policy already correct means new services start compliant. This is the only mechanism that stops the backlog growing.
5. Attribute findings to owners with a service catalogue. Unowned findings are never fixed. The absence of an ownership map is frequently the real blocker.
The enterprise-specific trap
A central security team as a gate. If every change requires review with a multi-week lead time, teams route around it — and the organisation ends up with a rigorous process covering a fraction of the estate and no visibility into the rest.
The counter is the paved road: make the compliant path faster. A team that can provision a compliant environment in an hour will use it; one facing a six-week intake will not, and will be right not to.
The principle
Security debt behaves like technical debt: it accumulates at the rate of change and is repaid at the rate of capacity. If those two rates are wrong, no amount of remediation effort converges. The only durable fixes reduce the accumulation rate — preventive controls and secure defaults — rather than increasing the repayment rate.