Compliance Management

Introduction

eramba will require you to identify solutions (treatment options) to your Compliance Requirements, these are typically a mix of Internal Controls, Policies, Exceptions and Projects. In this episode, we describe at least one (of many) methods that will help you identify them.

Is impossible to understand this episode without having completed the courses for Policies, Internal Controls, Projects and Exceptions. Do not attempt reading this episode without first having completed the other courses.

Strategy

When analysing compliance requirements you will need to decide what you want to do with them. This implies your strategy and your desire.

Your options in eramba are:

• To be Compliant: this is the most common scenario, you will use the Internal Controls, Policies and Project Module module to explain how your organisation is currently dealing with the requirement
• To disregard them as Not Applicable: this is pretty common, if the requirement does not apply to your scope or organization then you don't need to do anything about them. You may use Compliance Exceptions to sign off on that decision.
• Not to be Compliant: this is a rare, almost unexplainable scenario.

Note the decision you need to make is "what you want to do with them", not what you "are doing today". You might say that you are "Compliant" even if today, you have nothing to treat the requirement.

Possible Solutions

Compliance Requirements require (pun intended) you to describe what your organisation is doing (today, not in the future) in order to deal with these requirements.

You will need to create or re-use already created one or more of the following solutions:

• Internal Controls: are used to describe activities performed in your company. For example, the PCI-DSS v3.2 requirement 1.1.1 requires you to "A formal process for approving and testing all network connections and changes to the firewall and router configurations". The requirement clearly asks for a "Process", this implies an activity (step 1, step 2, etc) and therefore you know you need one or more "Internal Controls". You will also need one or more "Policies" that describe that process.
• Policies: are used to describe documents (of any kind). For example, the PCI-DSS v3.2 requirement 1.1.3 requires a "Current diagram that shows all cardholder data flows across systems and networks". This is simply asking for a "piece of paper" and therefore you need one or more items in the Policy module. Internal Controls are not required.
• Projects: These are used to describe activities (typically Internal Controls) that do not exist today but will exist in the future (in theory if projects are completed).
• Exceptions: are used to describe a top manager's decision to do nothing in regards to a requirement. For example, the PCI-DSS v3.2 requirement 3.5.1 requires a "Maintain a documented description of the cryptographic", but this is only required for "Additional requirement for service providers only". If you are not a Service Provider this does not apply to you and therefore a Compliance Exception can be used.

Todays Reality

The method we use to identify solutions is split in two:

• What solutions currently exist
• What solutions could exist in the future

While your organisation could be doing "today" any of the four solutions, what the organisation does not have "today" as a solution will always be a "project" type of solution.

Identification Process

The process we use to identify solutions for every compliance requirement is described in the diagram below:

• Choose a compliance package, PCI, ISO, Etc
• Read the first requirement from that package
• Decide if the requirement strategy
• If you decide to be compliant, then you need to understand what the requirement is asking from you and identify what is done in the company, within the scope of your compliance package (this could be one or all teams, etc)
  • Set compliance strategy to "Compliant"
  • If the requirement asks for an activity, ask the teams in the scope of this compliance package (one team, two, or all, etc) what activities are currently performed.
  • If the requirement asks for a piece of paper, create those documents in the policy module and link them to the requirement

Note: If you feel the requirements above are not sufficient to be compliant, create projects and link them to the requirement as well

• If you decide the requirement is not applicable
  • Set compliance strategy to "Not Applicable"
  • Create a Compliance Exception and link it to the requirement
• If you decide the requirement is not something your organisation wants to be compliant with
  • Set compliance strategy to "Not Compliant"
  • Let us know in eramba how you come to this conclusion! We will learn something new!

Drivers

This step is optional, and in our experience, this is only required in ISO 27001. For every ISO 27001 ANNEX requirement, you might be expected to link Risks that relate to each ISO requirement.

Maturity

The extent to which you are compliant is a subjective opinion, yours or from an auditor but is probably relevant to document it somehow. In the diagram above we include a last step when it comes to the "Compliant" strategy to record that opinion.