Part 3 – [ ________ ] is the Best Policy

Bringing You Up to Speed

In part 1 and part 2 of the '[ ________ ] is the Best Policy' series, we looked at how open source policies can quite often lead to the wrong type of behavior in an organization. As we saw, 41% of development professionals stated they are generally looking for the path of least resistance when it comes to compliance with policies -- many of whom will put a non-trivial amount of effort into working such policies.

We then discovered that 39% of survey participants said their policies, whilst in place, do not address security concerns. Perhaps their policies were constructed as a box-ticking exercise, intentional or not.

These first two areas should be of real concern for those of us striving to improve and secure the use of technology in organizations. While open source policies can be a bit of a blunt tool, they are developed for a reason and often times cost a lot of time and money to create.

Tell me what you want, what you really, really want

In this final blog in my series, we look at why it’s important to have clarity in the policies you produce. According to the survey, 1 in 3 participants said their policies did not make it clear as to what is expected of them. In my opinion, there is a strong chance that the policy will ultimately fail to achieve its goal.

Let’s return our focus to the policy stakeholders. When writing policies you should consider the perspectives of the various audiences to ensure the correct message is always conveyed. Typically open source policies will be used by:

• The working group who helps create the policy
• The people who approve the policy e.g. senior management
• The internal risk and/or governance functions within an organization
• An auditing or regulatory body
• And finally, the people who need to implement and adhere to the policy

Writing a policy is hard especially when you have to consider a wide range of audiences. Care needs to be taken to ensure the initial intent is not lost. We also want to avoid any discombobulation, ensuring the primary aims of the policy are achieved -- without it, policy in itself will be ineffective.

Navigating the Path of Policy Creation

To help you with the policy creation process, I have defined 7 things to consider when navigating the path of policy creation:

• People -- Consider your audience. Yes, all of stakeholders. The most successful policies will be clear to all of them.
• Focus -- Ensure that, at each stage of policy creation, the original intent is always maintained. This must be an imperative and non-negotiable.
• Measurable-- The implementation of the open source policy must be measurable (that point is worth repeating three times). If you are writing a policy for auditors or regulators, when it comes to the auditing of the policy you’ll need to show quantitative as well as qualitative results.
• Achievable -- Be sure your policy is achievable within a realistic timeframe.
• Quality -- Taking an old adage from the British Army, remember the 7 Ps: Prior Planning and Preparation Prevent Piss Poor Performance.
• Complementary -- Make sure policies do not overlap with other policies already in place. Overlapping policies will lead to confusion and add further costs.
• Succinct -- After drafting the policy, review it to remove as many words as possible whilst still retaining the same message. Verbiage leads to confusion.

Policies are really important. A good open source policy carries enormous weight.

When dealing with IT policy creation it can take a long time to get the desired results but the results will far out way any investment required. Hopefully you will find nuggets of advice in these pages that will help you with your own successes.