A one-off assessment is useful. It shows where the gaps are. But by itself, it rarely fixes anything.
That is because the assessment is the easy part. The hard part starts after the report lands: ownership, prioritisation, funding, supplier coordination, testing, and follow-through.
In regulated environments, that gap shows up quickly. A bank can assess secure configuration baselines across core systems, internet banking, and infrastructure, and still be left with the same weak protocols, broad permissions, and inconsistent hardening months later.
Why? Because the findings usually cut across multiple teams. Security identifies the issue, but infrastructure owns the server, application teams own the behaviour, and suppliers own parts of the delivery. Nobody owns the full fix.
When a finding stops moving
A good example is a payments reconciliation service running on legacy Windows servers. The assessment flagged broad local admin rights, outdated protocols, and inherited configuration settings that no longer matched the bank’s baseline. On paper, the fix looked simple: tighten permissions, disable the old protocols, and bring the servers back in line with policy.
In practice, it was not simple at all. The service sat between the core banking platform and an external managed service provider. Engineering said the changes would require testing and probably some code-level adjustments. The MSP said the work was outside scope and would need a formal change request. At the same time, the application owner was worried the service would fail during month-end processing if the baseline was enforced too aggressively.
So the issue was acknowledged, but it did not move. It was high risk, visible, and well documented, yet no one wanted to own the budget, the operational impact, or the final risk decision. The finding stayed open far longer than anyone expected.
That is the real limitation of one-off assessments. They create visibility, not momentum.
What matters is what happens next: clear ownership, deadlines, formal exceptions, and a way to track whether the baseline actually changes. Without that, the assessment is just a snapshot of a problem everyone already knows exists.
So the better question is not “when was the last assessment?” It is: what happened after it?