Request failed with status code 502
Server Error
Server Error
Server Error
Server Error
Server Error
Server Error
Server Error
Server Error
Server Error
Server Error
Server Error
Server Error
Server Error
Server Error
Server Error
Server Error
Server Error
Server Error
Server Error

Policy Management

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

  • Episodes8
  • Duration31m 55s
  • 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.

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 are required because you have a problem (Risk, Compliance Requirement or Data Flow) that requires them. You might also create them if you have an Awareness Program already on the system.
  • A clear 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 done in the organisation

The key to identifying documents that will be stored in the Policy module is to start with a Problem or an existing Internal Control (which will be linked to a Problem).

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 there is no document in the organisation that addresses this problem, then is best to create a Project and link that project to the problem. This indicates that today nothing is done in regards to this problem.
  • 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 items in eramba are created in those scenarios 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 your identification process, you have the following scenarios:

  • You identified a problem that requires a document
  • 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.

 

If your Internal Control does not have any supporting documentation or there is documentation but is not reflecting the reality you will need a project linked to the Internal Control. The Internal Control will be linked to your problem.

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 in order to do that! The identification phase is over!