Don’t fail an audit over a neglected annual policy review

When did you last have a light-bulb moment? For me, it was very recent. I was working with a client, supporting them in their latest Payment Card Industry Data Security Standard (PCI DSS) annual compliance assessment, and, in discussion with the Qualified Security Assessor (QSA), I had a sudden urge to challenge something we’ve all, always, believed to be a fundamental tenet of managing information security – the need for annual policy reviews.

There were a number of policy documents being relied upon for evidence, but they did not have a current date. Given that there was nothing fundamental that needed to be changed in the content itself, it struck me that failing an audit over neglected policy review would be an insensible outcome for either side.

I’ve been 25 years working in security and celebrate 20 years of managing my own consultancy next month and so I now find myself being “the oldest in the room” or indeed “the grownup”. If the last few years (pandemic, Russia declaring war, employment strikes, recession, significant increases in fuel, etc) have taught us anything, one rule that I live by now, more than ever, is to seize the day and challenge some of the assumptions that we are forced to deal with on a daily basis.

It was with this psychological background that it suddenly struck me – why are we slaves to the annual policy review? And, why do we accept the possibility of a low audit score for failing to conduct these reviews? The slavish pursuit of satisfying the requirements, which usually state something along the lines of, “Security Policy should be reviewed at least once every 12 months”, produces a very harsh audit response if the supporting documentation has not been subject to such review.

There can be several challenges with achieving the required outcome:

1. The content may have been reviewed, but the process of ensuring that the up-to-date version of policy or standard is available in the right location at the time of an external audit lags behind.
2. The content was not reviewed due to a lack of resources.
3. The content was not reviewed due to a lack of priority.
4. The content was not reviewed due to there being nothing to review as no content needed updating.

It was the last point that struck me most profoundly.

In this instance, the PCI DSS requirement states the following:

What if we just removed the first bullet point requirement and its equivalent in other compliance requirements, legislation, and regulation? Given how much effort goes into the crafting and creation of policies, standards, controls and supporting procedural documentation, and how lengthy the review process can be, how bad would it be if we didn’t all have to go through the motions of annual policy content reviews?

From an auditor’s point of view, a policy document which contains all the right content, but has not been reviewed within the last 12 months, would fail an audit with the above requirement for annual review. However, the existence of a policy does not intrinsically make our estate more secure. That’s the reality. 20 years ago, I would have vehemently argued the opposite, but experience brings a reality of day-to-day operations that does not fit in a neat, auditable box.

Let’s take a look at some of the policies that get assessed:

Information Security Policy – We promise to look after our customer/client/employee data and protect this with all relevant organisational and technical measures…  How will that change, annually? Why would we need to review that?

Information Security Training Policy – What would fundamentally change here from one year to the next? “We ensure that all our employees receive relevant related information security training on an annual basis”. The Policy doesn’t need to change, or even be reviewed. What needs to be reviewed are the training records to ensure that they exist – and that requires the support of the Learning & Development team and/or People Management, or Human Resources (HR).

Data Retention Policy – this would only need to be updated if there were changes to applicable legislation or regulation that required a change to, or an addition to the retention of certain organisational records or artefacts. Annual review of this document serves no valuable purpose.

In isolation, these policies don’t make our estate more secure. I am sure that you can probably think of several others.

If you are part of a relevant governance team, and are keeping yourself abreast of any changes in your applicable regulation, legislation or standards, then you would be updating your content as necessary anyway, whether annually or otherwise. Top tip – stay ahead!

Rest assured, I appreciate that the functional operation of the holistic suite of security policy content is what we all strive for. However, every now and then, we need to metaphorically shake the security thinking tree, challenge the status quo, and ask why we are expending time and effort on activities that don’t actively improve our overall security posture. What would truly add value to our organizations is to ensure that we have up-to-date data asset inventories, with evidence that these are running on up-to-date software, with no vulnerabilities that the criminals can infiltrate and breach.

About the Author:

Andrea Simmons is an experienced information governance, risk and compliance (GRC) specialist with over 25 years of expertise in designing and delivering information and cyber security governance frameworks, maturity assessments, and business transformation. Andrea has global experience in both the private and public sector, implementing compliance programmes and information security management systems (ISMS). Andrea’s PhD research concluded that the greatest of the GRC requirements is governance, and she created a new framework to support the findings, i3GRC™ – integrated and informed governance, risk, and compliance. Andrea is also author of two practical information security books, and has recently qualified as a Copy Editor and Proofreader.

Editor’s Note: The opinions expressed in this guest author article are solely those of the contributor, and do not necessarily reflect those of Tripwire, Inc.