We need to talk about Information Security Policy…

Policy Folders

I’m sure you’re already well on the way to planning your 2021…what it’s December already? Yup, the annus horribilis that is 2020 is coming to an end. With multiple vaccines in the pipeline, 2021 should [hopefully] be a year where we can get things back to normal. Well, a new normal! Whilst 2020 has placed a number of restrictions on us all, it has also been an opportunity for a little bit more freedom in terms of how we all work. New technologies have been rapidly implemented, with perhaps less governance than normal. People have been given the freedom to work from home. where they would otherwise have been prohibited due to compliance issues. All this may be great but has your GRC policy corpus kept up. In this article, we’ll discuss what you may wish to consider for your 2021 annual policy review…

Policy Review? What?

Remember that set of ISO 27001 policy templates you bought off the Internet? The ones you bought because a prospect asked for your security policy during a due-diligence exercise? The policies that your Senior Management Team and Board rubber-stamped on your recommendation – but did not read nor understand? The documents you simply added your company logo, changed the font and then did a Ctrl-F {Insert Company Name}, Ctrl-R “Acme Ltd”…

…The policies you have never looked at since (and neither has anyone else).

You reader are probably not guilty of any of the above because you know this; once policy gets approved by your company’s leadership, they became documents with which your organisation can be held accountable. If something goes wrong in your organisation and you have a reportable data breach, the ICO may want to check whether you were doing what your policy says you were supposed to be doing. If you’re not, you could end up in the same situation as Ticketmaster. If you have insurance that provides cover predicated on the submissions you have made in a certification (e.g. Cyber Essentials), that insurance coverage may not pay out if it is identified you are not doing what you say you’re doing in the policy you said you had on the submission form.

With all risk associated with paying lip service to policy, organisations, and specifically, the person accountable for maintaining policy, must ensure there is a mechanism to confirm compliance with what is actually written in the policy. One of the ways organisations can demonstrate they are compliant is to conduct an annual policy review.

So what is a policy review? Basically, it’s pretty much what it says on the tin. It’s a review of all your policy documents against your current business operations. The review seeks to ascertain whether your policies are fit for purpose, are implemented within your organisation and are enforced where non-compliance creeps in.

Why have a policy review?

When you first start writing (or “borrowing”) policy documents, you may find they reflect a utopian view about what good looks like. It’s only after a period of time post-policy implementation do you see what is (and is not) enforceable in your particular organisation. In many cases, the policy requirements were completely reasonable at conception. but things have now changed. Essentially, just like your business operations, policy requirements don’t remain static. So what triggers the need to update policy? The list below outlines common reasons why policy requires periodic update:

  • Change in risk appetite: It often gets glossed over but an organisation’s policies are a manifestation of the organisation’s risk appetite. An organisation with risk appetite statements such as: “we have zero tolerance for data leakage” must reflect that appetite with appropriate policy requirements. If risk appetite reduces for a particular scenario (e.g. on the back of a major data breach), then policy may need to become stricter. For example, an organisation with zero tolerance for data leakage (e.g. GCHQ or the NSA) would need to have policy statements that reflected how zero tolerance was to be achieved – and the consequences for non-compliance!
  • The current policy is not followed: Sometimes policy can’t be followed for operational reasons. For example, you have a policy requirement that states all systems containing personal data must only be accessible utilising Multi Factor Authentication (MFA). Great requirement. However, at the time you implemented this policy, 5 core systems exist that don’t support MFA. The policy requirement simply cannot be met without a costly migration away from these 5 core systems. Another situation could be that people choose to ignore the policy because there are no consequences to non-compliance. A statement in policy may need to be added to state “failure to comply may result in disciplinary action, up to and including dismissal
  • Policy is no longer effective or having the desired effect: A good example of this is the change management policy statement “All changes must be raised at least 5 days before CAB“. The spirit of this requirement is to give the reviewers and approvers sufficient time to assess the change. The challenge? The word “raise”. What happens in practice is the Change Agent feels they can now game the system by “raising” a blank change and only adding the content to the change just before the CAB. The Change Agent has complied with the letter of the policy but has now left no time to properly review the change. The policy wording needs to be updated to remove this unintended loophole.
  • New issues have arisen that require the policy to be amended: Many issues can arise that can trigger the need to amend policy. An event such as the 2020 global pandemic, new laws or regulations such as EU GDPRCCPAEU Cybersecurity Act or, the acquisition or divestment of a business unit could all mean policy needs amendment. In each of the cases, the organisation’s risk appetite is likely to change, and so to must policy to reflect that change in risk appetite. For example, if your organisation is acquired by another, their risk appetite may be higher (i.e. they are willing to take on more risk) and so policy may need to be loosened. Increased fines associated with GDPR caused many organisations to think again about the impact of non-compliance and thus took steps to make “enhance” their data protection policies. New regulation from the UK FSA on operational resilience is another example where banks may need to up their game in the coming years.
  • Changes to one policy conflict with another policy, or makes a policy redundant: A good example of this could be an information security policy that includes a requirement for third-parties to undergo due-diligence prior to contract signing. This policy requirement may also be in a newly created general procurement policy. An example of a policy conflict could be the requirement that users are prohibited from having local admin rights to systems that connect to the corporate network and a newly introduced Bring Your Own Device policy.
  • Policy is ambiguous or unclear: This can often kick in where policy statements have commas in the wrong place and that changes the meaning of the statement. My favourite (non-security) example of this is:

“I like cooking my family and my pets” (Use commas, don’t be a psycho!)

So, quite a few reasons why policy needs review. The question now is how often should the review be conducted.

When should policy be reviewed?

I know this is going to cause some to speak of unnecessary bureaucracy but organisations really need to have a Policy Framework. A key part of this policy about policy should be the setting out of the criteria for when policy reviews will be triggered. A good rule of thumb would be to review on the criteria described in the previous section but it is also useful to assign time-bound review triggers. If you’re particularly stuck for how frequent a policy review should occur, choose annually. If you find that your policies are fairly static consider pushing some out to two years. Just make sure if you have a two year review period, that doesn’t override one of the other triggers kicking in if something changes in the meantime! Ok, we know the why and the how often, but what should a policy review look like…?

What is the structure of a policy review?

I’ve conducted hundreds of third-party due-diligence reviews and the policy documents are always a good indicator of the organisation’s attitude to security. Policies that have been copied without removing the names of the prior organisation. Policies that talk about systems the organisation has never owned. Policies that have names and roles that simply don’t exist…and that’s before actually talking about the content and whether it is has been implemented. All these things show the third party in a bad light and could mean they don’t get shortlisted – which means losing out on a potentially lucrative contract. On the review side, one of the things I see time and again is a tendency for the policy owner to just change the dates in the version control section – et voila, policy reviewed! When a copy of the pre and post review policy is provided, the documents are identical…less the date.

So here is what should occur in a policy review:

  1. Policy Owner reads the policy documents (even if they know them off by heart)
  2. Policy Owner* gathers relevant data (control metrics, incident reports, risk assessments, external horizon scanning, new legislation impact assessments, risk appetite statement, organisation strategy) and analyse against your current policy.
  3. Policy Owner creates review copies of policies
  4. Turn “Track Changes” on (if you’re using Word)
  5. Policy Owner writes up analysis including reasons for any suggested policy updates
  6. Policy Owner updates policy documents
  7. Circulate review copies to stakeholders and ask them to make comments and suggest edits
  8. Review Meeting – Interested parties attend and present their suggested changes and highlight the potential impact of proposed changes (including costs to implement).
  9. Policy Owner considers suggested changes and updates document
  10. Final draft re-circulated to Stakeholders
  11. Document submitted to Policy Board for approval, alongside policy analysis and review meeting minutes as appendices.
  12. Updated policy published to central policy library showing tracked changes
  13. All employees (and relevant third parties) are informed of the update with an accompanying summary of policy amendments.

*or delegate

As you can see a policy review is more involved than just changing the dates and hoping no one noticed nothing has actually changed. It may well be that nothing has actually changed but that would be reflected in the analysis and review meeting minutes. If a policy does not change from one policy review to the next, it would be pretty surprising as things change all the time. If your new to auditing policy documents, a lack of change in policy from one review to the next is a definite red flag!

You dropped in “Policy Board” without much discussion…

I did just drop Policy Board in to the last section didn’t I, but what is it? Basically, a policy should not just be signed off and published. Policy requirements cost money and so the people with the purse strings must be willing to stump up the cash to resource each and every policy requirement. Therefore a policy must first go through an approvals process that involves discussion before going “live”. For some organisations, the Policy Board may be a section in one of the senior management operations committee meetings, for others, it may be a standalone session. Suffice to say that, whichever approach is used, there must be a Terms of Reference document that sets out how the Policy Board shall function. It needs to include details of who is a voting member, what makes a quorum, the remit of the Board, the challenge process should someone not accept the content of a new policy, the standing agenda, supporting documents to be provided alongside the policy (e.g. analysis report and review minutes) and, of course, the mechanism in which policies are to be approved (e.g. will it be by unanimous approval required or a simple majority).

Policy review is not just a change-the-date tick box exercise

Policy in of itself won’t do the heavy lifting when it comes to keeping an organisation within risk appetite but policy is the cornerstone of every organisation’s governance, risk and compliance programme. Without good policy, your GRC programme is at risk of being ignored, circumvented or at worse deemed an irrelevance. Policy is the manifestation of an organisation’s risk appetite so it must be reflect that appetite. It’s what holds everyone to account should something go wrong so if it isn’t clear, employees could run amuck!

Policy review is therefore an essential periodic exercise to make sure that policy is effective, adhered to and ultimate fit for your needs…not just a generic document someone on the internet has written hoping to cover as many organisations as possible. If you would like for us at Fox Red Risk to facilitate your next policy review or, help you set up/improve your wider policy framework, get in touch, we can help!

About Fox Red Risk

Fox Red Risk is a boutique data protection and cybersecurity consultancy and Managed Security Service Provider which, amongst other things, helps client organisations with implementing control frameworks for resilience, data protection and information security risk management. Call us on 020 8242 6047 or contact us via the website to discuss your needs.

22301 22301:2019 article 28 awareness bcms BIA business continuity calculating risk change management ciso controller cybersecurity data breach data privacy Data Protection data protection by design data protection officer data protection service Data Subject Access Request DPO DSAR GDPR incident management information security leadership monitoring operational resilience Outsourced DPO Privacy processor risk risk appetite risk management ROI security security as a service small business strategic strategy Subject Access Request tools training transparency vciso virtual ciso

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.