Compliance Management

Introduction

GRC is a management practice like Sales or Marketing, we all do it and we all do it in slightly different ways in order 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 solution available there are two options:

• Exceptions which the decision that the problem will remain as is, and the organisation won’t do anything about it.
• 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:

• First tell what problems your organisation has.
• Then for each one of these problems, what solutions exist in your organisation.

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 will simply follow the arrows upward to whatever solution it has associated.
• If someone challenges you as to why you need this Policy or that Internal Control, you will follow the arrows downward to whatever problem is driving the need for that solution.

The chart below shows the typical way 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 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.

Leverage

Is really not that complicated to have 500 or more problems. In particular today with some much compliance pressure. 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.

If you have 1000 problems you do not need 1000 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 above, 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.

This is again back to the "reflecting the reality" topic.

Say you have a problem, a risk, that your "Website could be hacked". You stated in eramba in the Risk module 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. Now imagine no one has run that Vulnerability Test for a while and your website gets hacked. People will think you are not aware of what really is happening (to put it politely) in the organisation and this is of course very unprofessional.

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 clearly 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 really compliant with PCI?
• Are these Risks really mitigated?

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