Writing an Effective Security Policy (Part 1)

If you would like to read the next part in this article series please go to Writing an Effective Security Policy (Part 2).


Many organisations have security policies, these policies are designed to manage the company’s resources and help in keeping authorised users and resources secure and free from abuse. In the following series of articles we will cover how the security policy can be used as viable tool, and how the policy can be written to help with current challenges.

On many occasions when consulting on information security, I ask the question; what does your security policy say? I normally get the dear in the headlights look. Well we do not really have one, or the one we have we got off the web, can you help us fix it up? I like to refer to the security policy as, whilst consulting, it is important to point the organisation to technical controls that they have already agreed on and the users have sight of.

A recommendation is that the policy is written to be aligned and consistent with business goals and that IT governance objectives are achieved. Another key component is that policy can not stand alone, there will need to be supporting documentation that refers to guideline and procedural documents. This document will define the expected user behaviour so it needs to be written clearly and without ambiguous meaning. The intention of the policy is not to be counter productive but to influence user behaviour, so that a moderated outcome can be observed.

The challenge

Most security policies that are written do not have teeth, this means that if the policy is breached no disciplinary action can be sought. This is primarily due to lack of management support and because the policy is not signed off as part of the terms and conditions of employment enforcement is challenging. Both senior management and HR involvement buy in is vital in keeping the living document enforced.

Writing an enforceable policy is also important, as many policies are difficult to understand and are left to interpretation. The key is to write a policy that has a good foundation, which is clear, enforceable and easy to read. This administrative control is often written in an unrealistic manner encompassing ideals and not really addressing the challenges of all business units.

Already the user would have read multiple documents; highlighting different areas of the business, an effective policy can be concise and meaningful. The lifecycle of this document is between three to five years and the document needs to be reviewed on a yearly basis to ensure consistency and alignment with the business strategy.

The challenge is that few security professionals have skill in this area and often the document is copied from a source that refers to ideals, this is done in order to fill in a compliance gap. Although some of the best practices are covered, you will find when it comes to implementing the technical controls little attention to realistic goals and practicality has been considered.

What is a policy?

A policy is document that plays a large part in influencing people’s actions, a plan or guide that is formulated to achieve a certain outcome. The guide (policy) is not a how-to document.


The policy should have the full buy in from senior management or business ownership, without this support the document will not be enforceable and will only be another piece of paper. Clear cause and effect (consequences) should be documented so that all are aware of the repercussions of not following the guideline.

Adding requirements without approval will result in departments needing budgets for technical controls. Technical controls cost money  and thus management approval of the policy is crucial.


Know that you will keep adding to the policy as time goes on, as the business goals change the adoption of the policy needs to be considered and the user behaviour will change. Ensuring that the flock is going to be led out of harms way is our primary concern, but, protecting the company’s information assets is critical.

Keep your companies budget in mind, this also allows for the organisation to plan on the technical controls that will be implemented and in the stages that the technical controls are implemented. If the policy advises behavioural requirements and there are no technical controls to enforce the policy user avoid policy enforcement.

Do not try to mitigate all eventualities, this a clear guide that is to be read as an overview or what should or should not be done. You may find that more detail is needed. (Rather than confusing the issue refer to an appendix and document the detail there.)

A comprehensive security policy will require the involvement of all business units, carefully co-ordinating this policy will result in less risk exposure. Similarly mergers with other organisations may expose yours as now new uncharted waters are included.

Always apply the rule of least privilege. This will ensure that the smallest attack surface area is exposed, the lower the exposure the lower the risk.

Note the guidelines, and note the mandatory parts of the policy. If this is not clear then users may feel that parts are optional when in fact they are not. Colour coding this or italicising the optional components might be useful.

Some policies may have portions that exclude certain users; these exclusions should be in the appendix and not in the body of the document as it could be confused.

Compartmentalise the policy so different parts of the policy apply to different departments, in a more restrictive manner. Although this highly complicates the policy, a general policy may be too loose and increase the exposure. For this reason it might be best to append more detail to each department and inform the line managers only, HR can help in keeping track of the policy elements. Different departments will have different security postures; this is why this approach may work for your organisation.

Make the elements of the policy achievable, if they are unrealistic then the whole policy could be ignored, or taken less seriously by the users.

The policy should enforce legal and compliance regulations, this reinforces the elements and gives the document a more authoritative focus; using references to these writings will be useful so that users can refer to the legal documentation.

Who should the policy apply to?

The security policy should apply to any user of the company’s facilities. This includes consultants and foreign entities, no matter how remote or local they are. Failing to consider a user can result in exposure, so it is important that before an entity uses the facilities that they read and agree to the policy.

Technical controls

There are hundreds of technical controls, antivirus, backups, content filters, firewalls, endpoint encryption, anti malware tools and many more. These technical controls can be mentioned in the security policy and should be described as controls that have been implemented to protect the company’s assets. Tampering, removal or alteration of such controls should be prohibited and thus a policy that advises this is important. On many occasions whilst auditing large corporate, one of my people found that a breach was caused because of the tampering of a technical control. The policy did not make mention of any technical control and how the user should interact and thus no action was possible.

Managing, protecting and dealing with data

The policy should cover how an individual deals with company data, this will encompass, storage of the data in a secure way, transmitting the data in a secure way and transacting the data in a secure way.


Reporting on the technical controls is also important as this will ensure that users are both notified of transgression, and that organisation is aware of risk and exposure. Not knowing that users are exposing the company might as well be the same as not having a policy.


In this article we covered important factors that need to be considered when writing an effective security policy. At the end of this series, a security professional should be able to collate the information and write their own security policy. Professional help is always available but hopefully the articles will identify areas that you as a security professional should look out for.

If you would like to read the next part in this article series please go to Writing an Effective Security Policy (Part 2).

About The Author

Leave a Comment

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

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top