Compliance Management

Introduction

In this episode, we share with you the methods we use to identify Compliance requirements across the organisation. While some requirements are very obvious others might not. This is one of many methods used to identify compliance requirements, feel free to use any method that works for you and your organisation.

Scope

GRC can apply to different parts of your organization, for example:

• It could be one department, two, all, etc.
• It could be a process, two or all.
• It could be one, two or all locations.

The key is to define clearly with your management what is the scope of your GRC practices so nothing is left out. The scope can be (or not) different for Risk than Compliance, the objective is to make that clear (pros, cons, consequences, etc.) to your management.

Types

Compliance is a very generic term and oftentimes is interpenetrated differently depending on whom you are talking. eramba is used by CyberSecurity, Quality, Finance, Legal and god knows what other types of teams. For that reason is important to clarify that the method described in this training applies to all of them.

Generally speaking:

• Regulatory Requirements: this means that a regulation made by an authority is asking you to do (comply) with something. These typically are government agencies that come up with something like Sarbanes Oxley, Financial Services Regulations, general data protection regulations, Etc. 
• Contractual Requirements: these are agreements between organisations that state what each party must do and what penalties exist if not. If eramba would like to sell services to a large company they would most likely send a list of requirements our company "must always comply with" or face penalties.
• Best Practice Requirements: these are typically not mandatory by a government (regulatory) but agreed to be best practices in a given industry. These are also typically mentioned in Contractual requirements. Here we have ISO, PCI, NIST, Etc.

The list above is likely not extensive but certainly covers the most common use cases in eramba. If you have a legal team in your organisation they might come in handy in some scenarios.

Identification Process

If you want to do Compliance Management in eramba you need to first identify everything you want to be compliant with and then put it into eramba. The process we use to identify compliance requirements is shown below:

• Define the scope and break it into teams
• Ask them what they do and with whom, and help them think about what regulations, contracts, and best practices they are or they should follow. In theory, they are experts in their area so they should know.
• Compliance requirements will start to pop up, this is inevitable.
• Classify them into the type of compliance package they are, this is important to understand the consequences of not following up things. Legal, Contractual and Best Practices have very different consequences.
• Once you come up with a list of things you need to comply with, for each one of them define the exact scope. This might sound confusing, the first step is about scope so we will try to clarify it for you. For example: the GRC scope might be the entire company, but Sarbanes Oxley's scope might be the Finance team and all systems and processes that are involved.

Once you have the list of things you need to be compliant you can start thinking about how to put them into eramba. Is of course important that this process is reviewed at intervals or when something changes drastically in each department.