Policies often fall victim to the the “tick-the-box” mentality. It’s a shame, because policies are an opportunity to empower teams with autonomy based on clarity, direction and defined boundaries.

When they’re implemented as "box-ticking" exercise, not only do they fail to serve a real purpose, but they can also create confusion and lead to an adverse culture that lacks appreciation for established and defined business processes. When it comes to applying these processes at scale, things start to break at the seams without that clarity for a growing team.

Starting with a template or example policy is a good idea to help you consider what is relevant to your business and the types of things to include in your own policies. Why re-invent the wheel? But we frequently see companies adopt "off-the-shelf" policies, like predefined "ISO 27001 toolkit" policies, without effectively adapting them to their own business.

The best way to write a policy is starting with a blank sheet of paper, and referring to those templates or examples. Why? It ensures you only put in what's relevant, aligned to your business, and it keeps the policy succinct. The quality of a policy should not be measured by its length or even following "best-practice" word-smithing, but by how well it works in practice. That is, whether it's actually understood and applied by those that should be using it. In your own business language, clear and succinct works best.

What should be included in a policy?

How do you develop a simple, fit-for-purpose, succinct policy?

There’s conceptually five areas to cover in every policy. The content will look different whether it's a Code of Conduct, Change Management, Security, Incident Management or Onboarding Policy, but the same five areas should be addressed.

1. Purpose/Background/Overview

Why does the policy exist?

This section is simply to communicate how the policy is intended to be used and why it was created in the first place. For change management that might be to set requirements and follow a defined process that mitigates the risk of errors or inappropriate system changes. For risk and incident management it might be to set out the structure for identifying, classifying, responding to and monitoring the risks and incidents. Each area has its own “best practices” and requirements vary based on the nature of those areas. So this section is just articulating at a high level what that objective is and how the policy should be used in practice.

2. Roles and Responsibilities

Who's responsible for each function related to the policy?

Arguably the most important part of a policy is the responsibilities. This clarifies who will decide, approve, investigate, monitor, perform a function, or otherwise handle any operational matters that may arise in that area. The larger the organisation, the more important this is, as responsibilities become more vague and diffused.

Roles and responsibilities should consider the following functional roles, that may apply to each policy area:

• Accountable Owner: Someone with sufficient authority to ensure the objectives of the policy can be achieved beyond any barriers of cost, resources, or any other limitations (eg. Board, CEO, CXO)

• Policy Owner: Ensures the policy is applied in practice, reviewed and updated as needed, and exemptions to the policy are handled effectively. This is often the head of the function covered by the policy.

• Functional Owner(s): Individual roles that are responsible for subsets of the policy, day-to-day management and monitoring of the policy, or other specific functions that support the policy objectives.

• Stakeholder Group(s): Sets responsibilities that relate to groups of stakeholders; customers, users of the system, a management committee, operational team, or all employees. For example, all employees and customers are responsible for ensuring their password settings conform to the security policy requirements.

3. Requirements

What are the boundaries, key practices and protocols of the area covered by the policy?

We refer to this section as requirements, as a broad term to cover the “policies” in the Policy. This section is rarely called "requirements" - it usually takes the form of the sub-components of the area covered by the policy. Eg. in the Security Policy; Network Security, Physical Security, Identity & Access Control, in the Incident Management Policy; Monitoring, Identification, Classification, Response, Resolution.

Each section should set out the key requirements or control activities to address the policy objectives;

• How is network security monitored?

• Who approves physical access?

• What minimum authentication methods must be used?

• How are incidents, risks, classified or rated?

• What are the steps to respond to incidents?

The key focus is on the control activities; those are the activities that mitigate risks in the process and help ensure key objectives are met in all instances.

4. Exceptions

What do you do if the policy doesn't "make sense" in practice?

Every good policy should have a method of allowing and handling exceptions to the policy. It’s impossible to predict every future circumstance and design a policy that will make sense in all cases. To maintain the integrity of the policy, those cases need to be treated as exceptions, not the rule. That might require a policy owner sign-off or other action to compensate for overriding policy requirements.

5. Templates/Appendices/Sign-offs

How do you put the policy into practice?

Templates, appendices and sign-off sections are about putting the policy into practice. This may include a contract template, a new vendor service or access approval forms, key contacts for your business continuity plan, testing plan for disaster recovery capability, and sign-offs for your Code of Conduct and Acceptable Use Policy to be acknowledged by employees. They translate policies into the form that they are applied.

The SOC 2 Perspective

The defined policies cover a broad range of the SOC 2 criteria indirectly. The expectation across all nine common criteria and the additional criteria categories, is that polices define or at least support the design of key control activities. In addition to this indirect relationship, there are two specific criteria that are addressed by the policies.

COSO Principle 12: The entity deploys control activities through policies that establish what is expected and in procedures that put policies into action.

COSO Principle 5: The entity holds individuals accountable for their internal control responsibilities in the pursuit of objectives.

AssuranceLab's Best Practices Series

AssuranceLab's best practices series, is about highlighting the "real operational benefits" that comes from effective control practices. At best, they support your company culture, provide structure and clarity, and enable scalable growth. At worst, they tick the box of what your customers expect, reduce the reactive "firefighting" and time-wasting, and help you demonstrate your compliance with leading standards like SOC 2 and ISO 27001.