Policy Management

Record your Policies, Procedures, Standards, Etc and manage their Reviews

  • Episodes8
  • Duration32m 13s
  • LanguagesEN
Episode 6

Identifying Policies

The methods we recommend to identify policies

Introduction

Policies, procedures, standards, etc are tangible things that are very easy to understand and identify in the organisation.

We oftentimes see people upload them quickly to eramba and then not knowing exactly what to do with them. In this guide, we will share with you the method we use to identify policies (regardless if they exist or not in your organisation) that will later be used to create them in eramba.

Is fundamental to this episode that you clearly understand the problem/solution principle in eramba.

The method described here is one of many, you can use any method you want to identify and document controls in eramba.

Requirements

Policies should only be documented in eramba if three conditions are true:

  • They fully or partially address a problem (Risk, Compliance Requirement or Data Flow). You might also create them if you have an Awareness Program already on the system and would like to track awareness against that document.
  • A team in your organisation can be identified as the one that wrote the document and maintains it updated.
  • The document reflects the reality of what is being done in the organisation.

The key to identifying documents that will be stored in the Policy module is to start with a Problem (Risk, Compliance Requirement or Data Flow) or an existing Internal Control (which will be linked to a Problem). We strongly advise you not to upload policies to eramba just because you have these documents in your organisation.

By all means, avoid creating Policies in eramba just because you know they exist in your organisation.

Identification

The process we use to identify Policies in eramba is shown in the diagram below and depends on the use case you are giving the Policy module:

  • You always start with a problem:
    • A Risk, Compliance Requirement or a Data Flow
    • The solution to this problem MUST require a document. For example, if the problem is a compliance requirement that requires you to have "A network diagram", then the solution to this problem is a Document, not an Internal Control.
  • You need an existing document:
    • You must identify an existing document in your organisation to deal with this problem
    • The document must not be a draft or loosely reflect the reality of the organisation
    • If no document in the organisation addresses this problem, then is best to create a Project and link that project to the problem. This indicates that at this point the problem has no solution (gap).
  • The document needs an owner:
    • Whoever wrote that document must be identified, typically this is a Team (IT, Finance, etc.)
    • You must explain to the owner what problem is being addressed by the document they wrote and maintain
    • If there is no owner for that document this is a sign of a lack of maturity and is best to create a project

At the end of the process, you end up with two scenarios:

  • You have identified a document that will be stored in the Policy module
  • You do not have a document and you end up with a Project

Whatever documents are created they will be linked to the problem you analysed. As you see you do not create policies in eramba without having clear problems first.

Attributes

Once you have identified a document that meets the criteria to be created in eramba, you will need the following attributes discussed with the owner of the document:

  • Where will be a document stored (eramba, URL or Attachments)
  • What is the current version of the document
  • When will be the next review and with whom

Is best to clarify these items before creating anything in eramba, as you would want that discussion to be recorded in eramba right from the beginning.

Summary

In the end after the identification process is completed, you have the following scenarios:

  • You identified a problem and through interviews, you identified a valid document in the organisation, who owns it and is now created in eramba and linked to the problem.
  • You identified a problem that requires a document but that document does not exist or is not accurate and therefore you have a new project linked to the problem instead of a document.

In the next episode, we will explain to you how to create this document, the important thing for now is that you have all you need to do that! The identification phase is over!