Part 3 – [ ________ ] Is the Best Policy

Part 3 – [ _________ ] Is the Best Policy

August 18, 2014
By David Jones

3 minute read time

In part 1 and part 2 of the "[ _________ ] is the best policy" series, we looked at how open source policies often lead to the wrong type of behavior in an organization. As we saw, 41% of development professionals said 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 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 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 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 focus on 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 discombobulation, ensuring the primary aims of the policy are achieved. Without it, policy will be ineffective.

Navigating the Path of Policy Creation

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

People : Consider your audience. Yes, all 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, you'll need to show quantitative as well as qualitative results when it comes to the auditing of the policy.
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 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 outweigh any investment required. Hopefully, you will find nuggets of advice in these pages that will help you with your own successes.

Written by David Jones
David is a former Chief Solutions Architect at Sonatype. He is now the Head of Developer Tools & Services at Credit Suisse.