Compliance Management

Introduction

In this episode, we help you clarify some of the most common misconceptions about compliance management in eramba.

Terminology

In eramba ISO, PCI, FCA, GDPR, NIST, etc. are called "Compliance Packages". eramba has an extensive database available to the general public. These are CSV files that contain whatever is asked from these standards. It is literally a copy/paste of those standards, regulations, etc into a CSV file you can upload to eramba.

These requirements are one shoe size for all organizations on the planet - they tell organisations what is expected from them. For example: you should have access controls that deliver this and that.

Some people call these individual statements "Controls", we do not, we call them "requirements". These are requirements that someone invented and wrote and you decided to follow for whatever reason. 

GRC Templates

The treatment your organisation has to meet Compliance Requirements are what we call in eramba: "solutions". This concept is well explained in the Problem and Solutions principle, please review this episode in this course before continuing reading.

In eramba, you will most likely use a combination of Security Policies and/or Internal Controls to deal with most of your Compliance Requirements. These solutions (Policies and Controls) are always different across organisations, there is not one fit for everyone.

Two companies doing ISO or PCI or whatever will be asked the same things, how they do those things in their companies is entirely their business. The "template" is ISO, PCI, etc, in eramba we focus on reflecting the reality of the organisation and how it deals (or not) with those problems.

For example: two companies dealing with ISO 27001 requirement 9.2.2, "User Provisioning" will need a Process (Policy in eramba) by which they describe how the provision and de-provision of accounts and roles in any kind of system. and one or more Internal Controls that will test how that is done. The technologies they use will be different, their procedures will be different, their teams will be different, the evidence they use to test will be different and the list goes on and on.

While templates can be good for "inspiration" in case your organisation has no treatment option implemented, they should not be the "default solution" for any problem. You would not be reflecting the reality and that is a big no!

One to One Associations

As explained in the diagram above, for every compliance requirement you will need to tell eramba what solution you have. If you find yourself creating one Internal Control or Policy for every requirement then you are doing things wrong (sorry to tell you!).

The typical leverage (the ratio of problems and solutions) in the community is well-accepted to be in the range of 5-15. If you have 1000 problems (compliance requirements), chances are you will need somewhere around 200 to 66 solutions (Policies and Internal Controls for the most part).

The screenshot below shows how one Internal Control is used across six Compliance Requirements from four different. Compliance Packages. These relationships could easily extend to Risks and Data Privacy flows.

The reason for this leverage is that one Internal Control will be used multiple times even within the same Compliance Package. For example:

• An Internal Control that tests "Accounts Provisioning" could be used in ISO 4-5 times in chapter 9 of the Annex.
• A general Security Policy could be used tens of times in ISO.

When more than one compliance package comes into the equation, the leverage tends to increase (typically double).

Mappings

The term "mapping" means different things to different people.

In eramba, the Problems and Solutions principle that drives the method eramba uses clearly defines that Compliance Requirements are linked to solutions: Internal Controls, Policies, Projects and Exceptions.

Compliance Requirements are one of three problems in eramba, you also have Risks and Data Privacy.

Solutions are used across the three problems, not just Compliance. If you look at the diagram above from "a little higher", it actually looks like the diagram below (the problem and solution principle).

 

Yes, it looks like a nightmare of arrows. The point is that solutions will be used not just in Compliance but also in Risks and Data Flows. This is what increases the leverage even more.

In eramba "Compliance Mappings" means something like this:

• ISO 27001 requirement 1.4 links to CIS 7.1 requirement 2.4, the reason is that they "ask for the same thing".

In eramba, that relationship would look like this:

These relationships do not tell us what solution the organisation has for those problems. For that reason when you do such relationships in eramba (we call the Compliance Mappings) you will still need to tell what solutions you have. The way Compliance Mappings are used in eramba is:

• Step 1: Create the mapping between ISO (source) and CIS (destination)
• Step 2: Create an internal control and a policy, link them to ISO 27001 requirement 1.4 and eramba will automatically link it to CIS requirement 2.4 because of the mapping you created in step 1.

We recommend that before using "Compliance Mappings" you consider the following:

• Compliance Requirements across different Packages can sometimes look the same but they will never be the same, otherwise copyright issues would quickly emerge between them.
• The authority "Source" will many times not map to anything in the "Destination". For example, if your source will be ISO 27001 and the destination happens to be PCI-DSS you will find that many PCI requirements are not covered by ISO. Many. In that scenario, you will link our "solutions" directly to PCI requirements "bypassing" ISO. This scenario is very frequent.
• When mappings are used you will need a "Source" and a "Destination". For example: ISO maps to CIS, NIST, Etc. The problem we see all the time is that companies "tie" themselves to a "Source" compliance package. That package might lose relevance, become outdated, Etc. There is no point in doing that since eramba uses a Problem-and-solution approach (the solutions can link to any compliance package).
• The "Source" can quickly become outdated (ISO, some of NIST standards, etc.) since they could be updated far less frequently than their "Destinations".
• If the scopes differ between compliance packages, mappings are automatically not applicable.
• Compliance typically involves auditors. An ISO auditor can not audit PCI, no matter how similar you think they are. The point we are trying to make here is that no matter how similar they look, they are audited very differently and therefore assuming compliance with other frameworks is not realistic.

In general and in real life in particular when external auditors are involved, Compliance Mappings are hardly ever a real way to deal with compliance. Please use them carefully.

Scopes

When doing any compliance (PCI, ISO, etc.), your first step is to define the scope. What will be in the scope of the compliance program? This decision affects directly what your certificate will say at the end. Examples of scopes are:

• The entire organisation
• Every company in my group of companies
• The Processes A, B and C
• The finance department
• Etc

The scope affects how your company identifies "solutions". If the scope of an organisation is Process C and A, then HR is likely not to be included. If the scope is the entire organisation then all is included.

For example, let's continue with the example above: say you want to work with requirement 9.2.2 from ISO 27001, "User Provisioning".

• If the scope is the entire organisation I need to cover all processes involved with that account provisioning (A, B, C and D) and my testing should include all systems (A, B, C and D)
• If the scope is the IT department, then the processes involved I only need to cover processes A and C, my testing will likely focus on system C alone.

Is important that you carefully understand your scope in order to identify solutions. The scope has huge implementations as well for those of you that use "Compliance Mappings", if the scope on the "Source" and the "Destination" is different in any way, is very likely you will end up with gaps.

Multiple Scopes

If you have multiple scopes (and sometimes certifications) then is very common that you would upload the package in question multiple times, for example, if we are doing ISO in three locations and each one of them has its own certificate we would upload the ISO standard three times:

• ISO 27001 - UK
• ISO 27001 - Germany
• ISO 27001 - Alabama

When mapping controls and policies, some will apply to all three and some not. For example:

• if we have a standard "change management process" that applies worldwide, then that process (Policy in eramba) and its related Internal Controls will apply equality to all three packages.
• We might have CCTV in all locations, but perhaps due to stringent privacy regulations in Europe, retention times and what can be recorded differ. For that reason, we might have two CCTV standards, one for European locations and one for USA locations.  Our internal controls will be inevitably different as well, forcing us to create one for Europe and another for USA

Uploading multiple compliance packages will also allow you to visualize from a reporting perspective very clearly how each scope (country, company, etc) is doing in terms of compliance. 

Assets

Some people want to link "Assets" to compliance requirements. While possible (see relationships diagram above), eramba takes a step back with this type of approach for various reasons which are explained in detail in the Asset Management course.

Most GRC teams are not staffed adequately to do GRC let alone to manage, in real-time, all assets in the company.

The "asset" based GRC approach developed in the late 90s is, for the most part, unrealistic in the world we live in now as most things are not tangible but virtual and in most cases in large companies provisioned and de-provisioned thousands of times a day.

If you want to know "what systems are in the scope of PCI-DSS" then look at what solutions are in the scope:

• Internal Controls
• Policies, Procedures and Standards

These items will have "Owners" that will be spread across the organisation, they will be able to tell you what assets are affected.