Internal Controls

GRC is a management practice like Sales or Marketing, we all do it and we all do it in slightly different ways to accommodate our organization's circumstances: budget, resources, maturity, localization aspects, Etc.

eramba does GRC in a certain way and is important you understand what that method is so you can compare it with your methods and decide if this is a good fit or not.

eramba organizes its core modules in two: Problems and Solutions.

Problems (Blue) are:

• Things we need to be compliant with, for example, ISO 27001, SOX, SOC2, PCI-DSS, Etc
• Organization Risks
• Answering the question: How do we protect Data?

Solutions (in Green) are:

• Policies such as a Network Diagram, Encryption Standards, Security Procedures etc.
• Internal controls are activities such as Firewall Reviews, Laptop Encryption, Access rights audits etc.

When a problem has no available solution there are two options:

• Exceptions: if the organization decides it does not want to deal with the problem for the time being.
• Projects: are used when the solution is not available now but will be in the future.

The important thing to understand at this point is that you implement eramba by doing two very important things:

• First tell what problems your organisation has.
• Then for each one of these problems, ask yourself what solutions (Internal Controls and Policies) exist in your organisation. If there are no solutions what do you want to do next (Projects & Exceptions)

Reflecting Reality

When looking at the solutions and problems (compliance is the exception) is important to remark that we are talking about the actual solutions and problems that exist in your organisation. There are no templates for this.

For example:

• Everyone has an Internal Control called "End Point Encryption" because everyone is encrypting endpoints, but we all use different technologies, procedures, teams to implement them, Etc.
• Everyone has a procedure to provision and de-provision accounts to a system, but again while they will all look similar they will all be different.
• Everyone is subject to theft, but circumstances will be different again for everyone. The impact and likelihood will also be different.

In eramba we want you to reflect the reality of your organisation and there is no template for that. The only thing all organisations have are compliance requirements, things like ISO, PCI, Etc. The rest needs to come from you.

First Principle

The first principle in eramba is the one that states that for every problem there will be a solution.

• If an auditor asks you how you meet PCI requirement 1.1.1 (does that even exist?) you can simply follow the arrows "upward" to whatever solution it has associated.
• If someone challenges you as to why you need a Policy or an Internal Control, you can follow the arrows downward to whatever problem is driving the need for that solution.

The chart below shows the typical chart eramba uses to depict these relationships. The Privacy Policy (in the policy module) is used to meet three compliance requirements from two different packages. The same report can be obtained for Risks, Controls, Projects, Etc.

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 describes how customer data is downloaded to laptops 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.

Leverage

Is not that complicated for any organization today to have 500 or more problems. PCI has 260 requirements, and ISO some 150. Add to that 100 risks and 100 data flows you could easily be in the 500 problems range.

If you have 500 problems you do not need 500 solutions because solutions will be re-used across your problems multiple times. The agreed leverage in the community says that for every solution you will address anywhere in between 5 and 15 problems.  An example of this situation is demonstrated in the table above.

Second Principle

As shown in the diagrams below (yes, you will see this diagram pretty often in eramba), we think of GRC as an ecosystem.

Whatever happens to your solutions, your problems should be affected. If a solution is not really implemented, is not working, is partially working, etc. that should reflect in your problems because perhaps that is not even a real solution.

Say you have a problem, a risk, that your "Website could be hacked". You created the Risk and then you document that the solution to that problem is an Internal Control called "Vulnerability Scans" where a scan runs every checking for potential issues. So far you have completed the first principle (problem and solution).

Now imagine, that someone forgot to perform audits on that Internal Control and your website gets hacked. People will think you are not aware of what is happening (to put it politely) in the organisation and this is of course very unprofessional. If you claim there are solutions, then they should be there. If they do not work you should also know.

To avoid this situation we have the Second Principle which is all about the "Status" of everything, in particular your solutions. 

• Projects, Exceptions and Policies have mandatory deadlines for review. If you don't do them on time they will get a "Yellow" status.
• You can (optionally) describe a testing methodology and calendar for your Internal Controls. If you don't test on time they will get a Yellow status. If the testing fails, they will get a Red status.

The screenshot above shows clearly policies with their reviews and the labels that tell us which ones are okay and which ones are not. The same applies to any module in eramba.

Is only when all is reviewed on time and passed that labels are green. If any "Solution" gets a "Yellow" status, whatever problem will inherit that status as well. The Risks shown in the screenshot below clearly show those labels.

Using the Second Principle is very easy to tell:

• Am I compliant with PCI?
• Are these Risks mitigated?

Remember everyone can tell there are solutions, but most can not diligently prove it.