Bear with me for a bit. When my son started intermediate school he wanted to scoot there. He had a flash scooter, so we got him a padlock and insisted he use it. Over the next few weeks we checked that this was happening. 6 months later we discovered that his padlock had seized up and he couldn’t use it. I reached for that old NZ standby – CRC – and got it working again.
We checked that everything was all good. Then three months later his scooter was stolen. A bunch of scooters were interfered with, but his was the only one stolen. It was the only one without a padlock. As you can imagine there was a lot of frustration, screaming and swearing. And a domestic investigation: how could this have happened? Well, it turns out that after several weeks he had stopped using that padlock. He had left it in a pair of shorts rather than in his bag, and so sometimes didn’t have it at school.
You can probably see where this is going. If I think about this from a security perspective, that padlock was a security control. We had correctly identified the risk and implemented the best control for managing it. We even audited it (lightly) by checking that he was using it. But after three months that audit result was meaningless. Controls can fall into disrepair. Perhaps through a technical failure (like the padlock seizing up) or people failing to run a key process (like forgetting to take it to school). And so the accuracy and value of the audit result decreases over time: it goes stale.
When working on customer gigs I often hear complaints like: “That’s already been audited, why do you need to look at that?” Or, “Recertification is just a waste of time.” Sometimes people even try and to provide a three year old screenshot as evidence. Each time, I’m taken back to that situation with my son and his scooter all over again. But this time the consequences of the audit going stale can be much, much worse. It’s not just a scooter worth a few hundred bucks at risk, but personal information, public services, revenue and stakeholder confidence. Maybe even the survival of the organisation.
Audits are just point in time assessments – and those assessments can go stale. Obviously, the “best before date” on an audit result depends. The question I ask myself is “how quickly can a control go off?” For some controls that is rather slow – your policies don’t go stale very quickly. But someone could stop patching your servers the day after you run the audit. (Especially if they only patched them for the audit!). In general I wouldn’t have a lot of confidence in any audit result over six months old, and anything over a year I wouldn’t trust at all.
So – you can’t rely on old audit results. You need to keep re-auditing your controls to have the right level of assurance over them. This is why at Axenic we recommend re-running risk and assurance (known as certification and accreditation if you are in government) processes periodically. It’s why security certifications such as ISO 27001 require annual audits. An even better option is some form of continuous assurance – checking controls on a regular, frequent basis. (We should probably blog about that sometime soon!)
Needless to say my son does not have a scooter, and we regularly check that he is still using his bike lock.
As always if you have any questions about audits or continuous assurance we are happy to have a chat. Just get in touch.