Policy and Procedures

We talked a little bit about policies. Policies are high-level statements of intent. Policies typically have senior sponsorship, and they answer the what and the why with regard to identity and access management. So with our policy, we’re trying to explain what is required. This can be done through the use of a purpose statement outlining why the organization is using the policy. We typically want to try and describe the remit of the policy as well. To what areas is the policy applicable? Who is covered by the policy? Who falls within its scope?

Again, by explaining what we want to achieve and why we want to achieve it, the policy as a high level statement can help us in terms of generating that buy-in from our end users. So we’re trying to explain to people the what and the why, very, very high-level. So typically, again, we have senior managers, either drafting these policies, and if they’re not drafting them, they are very much involved in the active support or the sign-off, the adoption of the policy within the business. The policy is a high-level document. It’s usually fairly short in terms of length. These documents tend to be a couple of sides. They don’t tend to be long documents. But again, very important in generating buy-in.

At the opposite end of the spectrum, we have procedures. Procedures are low-level, detail-orientated documents. These are typically telling people within the business how to achieve a specific function, how to operate to meet a particular goal.

These procedures, there may be many different types of for each policy. So we will see a single policy potentially having 10-20 procedures. And this varies massively, depending on the type of organization that you work within, that you operate within. Any procedure, though, should have the involvement of our stakeholders within the business to make sure that they’re appropriate, that they are fit for purpose, that they help us to support the business. Procedures that aren’t considered in light of the business can contain steps that may not be practical, that may not be possible to undertake.

For example, if we have a sales team who are highly mobile, and we are asking them to undertake a login to their desk at least once a month to perform updates to the systems or services, we may experience problems. This may not align with the way these teams work. So we can resolve these problems before they occur through effective engagement with our stakeholders. Typically, again, we want that business unit approval. Procedures answer a very different question to our policies. These are telling us how we undertake the task, how we gain the compliance with the policy, and also who is responsible. We may have the same policy enforced through different procedures in different parts of the business.

And again, we may have tiered procedures that are applied to different parts of the organization, depending on the type and level of access that they have, and, again, based partly upon the risk around their day to day activities. With our procedures, if we rely on paper procedures, we may end up with fairly low levels of compliance – one of the risks. One way to help mitigate that issue is through the use of electronic workflow type systems. So here what we can do is embed our process into our individual systems, into our ERP system or our CRM system. And this enforces the way people work.

So actually to undertake a particular process, like the creation of a new user, for example, if people have to follow a step-by-step, wizard-type approach, then our logic, our procedural logic is enforced, and it removes the ability for people to operate in a way that isn’t congruent with the procedure. So this can be really helpful. And we have web-based workflow systems, like SharePoint or ServiceDesks or Salesforce. All of these different products, most products, will support some kind of configurable workflow to achieve particular functions or tasks. So again, our policy is the what and the why for our approach to identity and access management. Our procedure is the how and the who.