Data Protection Program

Introduction

Most modules require interaction with other modules to be useful or even available. For example:

• You cannot create a Risk item without an Asset item
• You cannot create a Compliance item without a Control item

 The core (GRC) modules in eramba are split into two broad categories, “Problems” (Risks, Compliance Requirements, etc.) and “Solutions” (i.e. “tools”).

Problems (in light blue) are:

• Things we need to show compliance with, for example PCI-DSS (Compliance Management)
• Risk scenarios or known problems (Risk Management)
• Protecting data as it flows across the organisation (Data Flow Analysis)

Solutions (in green) are:

• Documents such as a Network Diagram, Encryption Standards, Security Procedures etc. (Security Policy module)
• Internal controls are activities such as Firewall Reviews, Laptop Encryption, Access rights audits etc. (Internal Controls)

When a problem is identified that has no solution available (in purple), there are two options:

• Exceptions document the decision that the problem will remain as is, and the organisation won’t do anything about it (Exception Management)
• Projects are used when the solution is not available now, but it will be in the future, on completion of the project (Project Management module)

The arrows on the diagram show the relationships between problems and solutions. Projects are grouped separately because they link everything. You should understand why using the Risk module involves at least four additional modules!

When you implement eramba you need to understand how each of the modules mentioned above work and you need to follow the two implementation and operational principles:

• Link problems to solutions
• Use statuses to know if solutions work or not; your problems will inherit the status of your solutions

First Principle: Problems Solutions Association

There is no point in creating solutions unless you can link them to problems. Solutions cost money and no one will pay for them unless there is a need. 

When implementing eramba start by defining your problems and then for each problem you need to identify what solution your organisation has in place to address it. The chart below is typical for a policy recorded in eramba and shows how many problems are addressed by this single solution (policy). 

Let’s review further examples:

Problem	Solution
A risk scenario that describes the issue of laptops being stolen or lost.	An Internal Control that describes how end-point systems are encrypted and have access controls using strong authentication. A policy about Endpoint encryption and a procedure on how the job is carried out on each laptop.
The data flow that describes how customer data is downloaded to laptops in order to make a report.	The solutions above could be reused in this scenario.
Compliance requirement 3.4.1 from PCI-DSS.	The same control mentioned above can be reused for this problem. We could upload an encryption standards policy onto the system too and link it to the control and compliance requirements.
Compliance requirement 5.1.1 from ISO 27001.	Information Security Policy uploaded on the system.

In summary:

• Start by describing problems. There could easily be thousands of them if you are doing compliance management.
• Identify solutions for each problem. Try to reuse them across your problems as much as possible. A solution that deals with five problems is more cost effective than a solution that deals with one problem. The typical ratio in eramba is 5-15:1. If there are 1,500 problems you would typically expect around 150 solutions.
• All links are made on the problem side, not at the solution side.  Solutions are linked to problems not vice versa.
• If someone asks how you meet PCI-DSS 3.4.1 you follow the arrows up to whatever solution is associated.
• If someone asks you why a review of a Policy is required, just take the policy and follow the arrows down (to the problems) and that will explain why that document is required.

Second Principle: Solution Status

GRC is an ecosystem. Whatever happens to your solutions, your problems should be affected. If you state that PCI-DSS 3.4.1 is addressed by encrypting laptops (Internal Control) then you will want to know at all times if that really is the case.

For example:

• If you upload a policy but never review it, more than likely that policy will not be relevant.
• If you create a control to review endpoint encryption but never test the control, then you don't really know if encryption is being implemented correctly.
• If you create an exception and never review it, it is not an exception, but rather the norm.

GRC is an ecosystem where everything depends on each other. Knowing how things are is important as their status will affect the things they link to. For that reason eramba has statuses for most solutions that should reflect the reality of the organisation.
 

When you:

• Create a Policy you will need to tell eramba when you will review it.
• Create an Internal control you will need to tell eramba when and how you will test it.
• Create a project you will need to tell eramba what the deadline is and the related tasks.
• Create an exception you will need to tell eramba what the deadline is.
• Create a Risk you will need to tell eramba when you will review it.
• Create an Asset you will need to tell eramba when you will review it.

To a large extent GRC is about reflecting the reality of the organisation and for that purpose pretty much anything you upload to eramba will have some form of status that will tell you if you have missed something.

It is the combination of these principles that determines how eramba manages GRC and how eramba is implemented.