Policy Management

Multiple Use Cases

The policy module is used for different use cases:

• Risk Mgt
• Compliance Mgt
• Data Privacy
• Awareness Programs

Policies link as well with projects, but this is not a use case in itself, this is simply an association in eramba used when your policies are not in top shape and need a project to improve them.

There is no point in using the policy module in isolation, this means uploading policies and not linking them to other modules. As explained in this course Policies are "solutions" that should only be created after a "Problem" has been identified. The course will also explain in which order you need to use these modules.

Link to Controls

Policies link with Internal Controls because these are activities that must be done systematically. Anything systematic requires a procedure and is that document that is typically stored in the Policy module and linked to the Internal Control.

The combination of these two modules will allow you to answer questions such as "Are my policies or procedures being followed up?". The screenshot above shows a custom label in blue created that triggers when the associated controls to a policy are not tested.

Accountability

Among other things, the typical GRC department is tasked with dealing with problems (Risks, Compliance and Data flows) across the organisation. The solutions (Internal Controls, Policies, Exceptions and Projects) used in eramba to deal with these problems are therefore everywhere in the organisation.

For example, if an Internal Control is required to meet a hiring-related risk then an Internal Control will be created where all hire background checks are reviewed and their contracts are tightly organised and signed. HR might have a "Hiring Policy" and a "Hiring Procedure" that they follow for that process. They are the authors of that document, not the GRC department.

This is why two roles are always needed in eramba when creating a document:

• The GRC department needs a solution to a problem
• The HR department implements and operates a solution that among other things, deals with the problem the GRC department has

Is very important in eramba to set accountability right from the beginning.

Policy Content

eramba will store your policy attributes, things like:

• name
• description
• version
• owner
• etc

It will also store a reference to the actual document content. When you create a Policy that content will be defined in three possible ways:

• Using a content editor built in eramba where you can write policies
• Using a URL that points to your Sharepoint or Google Drives
• Uploading attachments, things like PDFs, Etc

The idea of having your policies in eramba is that if anyone asks at any time where a policy is you can find the source.

Remote URLs

If you store your policies in a remote repository the question is how you manage reviews of that policy. Reviews are easily managed when the content is in eramba or when using attachments, but when using a remote repository things are bit a trickier.

If someone changes the document in that remote repository, how would you (or eramba) know about it?

Here are our thoughts:

• Whatever repository you use, it should have some form of version control where your (GRC) team is involved (as an approver, notified, etc). When a version changes you will be notified and then you can create a new review in eramba with that new version (even if the URL remains the same), we recommend attaching a PDF of that new version as a comment to the review in eramba.
• If your document management repository has APIs you could also trigger a new review for this document in eramba. This requires a lot of coding work so is clearly not an option for everyone.