This commitment included efforts I worked on.
Another item this commitment included was an updated security policy.
The two came into conflict — the new policy, written during the breech and approved immediately upon recovery, was absolute. Part of its strictness was a lack of a clear policy exception process.
The other problem is that the policy enacted while in reaction-mode was not time limited.
Fast forward 6 months and my team and I are ready to implement a bunch of positive security changes to the customer environment, measurable and demonstrative positive changes to the customer environment. Other actions by others are also in process.
We can’t make the changes needed because of the policy. There is no clear exemption path, no clear exemption requirements, and fear about what happens to whomever allows an exception to go forward.
In the calmer, reflective time of the better part of a year between the initial breech and our exception discussions, the customer agreed that the new policy is poorly written, misunderstood, and should be revised.
The policy is so absolute in its wording there is no clear path to doing anything about it until the next general policy review in something like 2023.
Meanwhile, multiple security tracks to improve the security posture effectively stop for eighteen months. The customer is still on the hook to pay for the contracted services in the interim.
Takeaway: anything done in the immediate aftermath of a security breech should be time limited. Some things will be through the nature of subscription or contract. Those that aren’t, like new policies crafted during or immediately after a breech, should have a time limit.
- The customer did not mention what existing priority would get demoted, a mistake. If everything — or too many things — is a priority, then nothing is a priority.