Request failed with status code 502

Data Protection Program

Learn how to implement and operate a data protection program - long

  • Episodes13
  • Duration29m 40s
  • LanguagesEN
Episode 3

Problem vs. Solution Principle

Fundamental GRC relationships in eramba that you must understand before using the software


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

  • You cannot create a Risk (module) without an Asset (module)
  • You cannot do Compliance (module) without a Control (module)
  • Etc

Eramba uses the methodology of splitting the core (GRC) modules 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, for example PCI-DSS (Compliance Mgt)
  • Risky scenarios or known problems (Risk Management)
  • Protecting data as it flows across the organization (Data Flow Analysis)

Solutions (in light green) are:

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

When we have a problem that has no solution available (in light fuxia), you have two options:

  • Exceptions will document the decision that the problem will remain as is, and the organization 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 (Project Management module)

The arrows on the diagram show the relationships between problems and solutions. Projects are on the side because they link to everything. Hopefully by now, you 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, you start by defining your problems, and then, for each problem, you need to identify what solution your organization has. The chart below is typical for a policy; eramba describes how many problems are being addressed by this single solution. 

Let’s review further examples:



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 enforced with strong authentication. A policy about Endpoint encryption and a procedure on how the job is done on each laptop.
The store 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 encryption standards policy on 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:

  • You start describing problems. You could easily have thousands of them if you are doing compliance management.
  • You identify solutions for each of them. You try to reuse them across your problems as much as possible. A solution that deals with five problems is more cost efficient than a solution that deals with one problem. The typical leverage in eramba is 5–15. If you have 1,500 problems, you need 150 solutions or so.
  • All links are done on the problem side, not at the solution side.
  • If someone asks how you meet PCI-DSS 3.4.1, you follow the arrows up to whatever solution they have 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 told people PCI-DSS 3.4.1 is addressed by encrypting laptops (Internal Control), you want to know at all times if that really is the case.

For example:

  • If you upload a policy and 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 they will affect the things they link to. For that reason, eramba has statuses for most solutions that hopefully reflect the reality of the organization.

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 their tasks, too).
  • 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 organization, 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 does (operates) GRC, and how eramba is implemented.