Internal Controls

Activities

The most common confusion in regard to what we in eramba call Internal Controls is that people mix them up with things like ISO, NIST, Etc. You can use any terminology you want, but we need you to understand what we mean by Internal Controls.

NIST, ISO, etc. are, what we call, compliance packages. They are a set of requirements or goals for every company on the planet. How you meet those requirements is entirely up to you. For that reason, only you know, what Internal Contros exist in your organisation.

This is why we always talk about "Problems and solutions". If this is not clear to you please review that episode before continuing.

Link to Policies

If Internal Control is an activity that we want it to be done systematically (you want all laptops to be built the same way of course) then is very very likely you will have a documented (or not) process that describes how that is done

The Internal Control module and the Policy module are linked one with another for this reason, ideally when a control is created you will associate "documentation", back to the "End-point encryption" control the following documents could be applicable:

• End-point device build procedure
• Encryption Standards for end-points
• Encryption Policy
• Etc

Reflect Reality

Internal Controls are one of four "Solutions" in eramba and is very important that on all of them, you always reflect the reality of your organisation. A control is "real" if it meets the following criteria:

• It addresses a known problem (Risk, Compliance Requirement, Data Flow)
• There is a team that operates the control and knows the problems associated
• The control is in use, it might not work perfectly well, that is a question of maturity, but it should by all means be in use

If one of the criteria mentioned above is not true, then you do not have an Internal Control. The typical scenario is something like:

• We are going to mitigate Risk A by implementing Internal Control "XZY"
• We are implementing as we speak Internal Control FGT and Policy YFD to mitigate PCI requirement 4.5.6

The situations described above are projects that you can link to your problems (compliance requirements, risks, etc) to describe the situation where something is being done. Until those projects are completed there are no "internal controls" and the problem is not really mitigated.

If you have a control that is more or less working and you have linked it to problems, you can still link the project to:

• the internal control
• a failed audit of that internal control

In both scenarios, you are telling eramba that the control is not working perfectly well but still is operational.

One to One Mapping

If you find yourself creating one “Internal Control” for each PCI-DSS requirement on the standard (or ISO or NIST or anything else) then you are most likely missing the leverage concept of eramba.

Internal controls should be used for many “problems”, not one or two. The typical leverage in the community is 5-15, one internal control will be doing 5-15 things on the problem side (assuming you are using all three types of problems).

For example, if in your organization your Service Desk team installs on every laptop an end-point solution (encryption, AV, etc.), then you could create an internal control called "Endpoint Encryption". That "solution" will be used:

• To meet a Risk called "Unauthorized data leak due to laptops lost or stolen"
• PCI requirements 3.4.1, 4.1 and CIS 7.1, 13.6, etc.
• A data flow where customer data is stored in employees' laptops

The typical leverage in the community is agreed to be around 5-15, that is if you have 1000 problems (in between Risks, Compliance Requirements and Data Flows) you will need some 100 or so Internal Controls. Believe it or not (this is a well-known fact) the rate at which you will create controls will be somewhat reflected in the graph below no matter the organization's size or vertical.

Initially, when implementing eramba you will identify many controls and then, you will see that you will slow down as problems start to become similar enough that by just "adjusting" existing controls you mitigate them. The curve begins to flatten at around 200-250 problems.

The reason why the organisation size or vertical does not affect the number of controls is that larger organizations standardise controls across their scope for operational efficiencies. A 200-employee company and a 20000-employee company are likely to use a centralized encryption solution, meaning one control.

Most people know what controls they have in their organisation, what you need to do is to break down that "explanation" into single items that you can create in eramba. In this course, we will teach you one way to go around this challenge.

Templates

Sometimes people expect "templates" that tell them what "Internal Controls" should "exist" for every "Problem". eramba has a library of templates available to anyone on our website.

Back to the previous point, if PCI asks everyone for Encryption, how your organisation meets that requirement is entirely up to you. There are infinite methods, technologies, and processes to achieve this, templates therefore are of little use other than inspiration.

Assets

Internal Controls are activities that reflect procedures. A procedure takes an input (an asset, etc) does something with it (step 1, step 2, etc) and delivers an output. The key here is that, if well done, a procedure and therefore an Internal Control is systematic. For a known input, you know what the output will be. That is key to auditors.

The number of inputs is completely irrelevant here, a 200-employee company and a 20000-employee company both will most likely use a centralised procedure to encrypt endpoints. If your goal is to know what laptops are not encrypted then ask (or more likely you will audit as part of Internal Controls) whoever runs that procedure and tooling.

You will take a representative sample (out of 200 20000 or 5 million items) that will give you a representative indication (rate which produced expected outputs) of the accuracy of that procedure.

Testing

Controls are activities that are intended to solve problems (e.g. Risks, Compliance Requirements, etc). Unless these activities are tested there is no certainty that problems are being addressed. For that reason, controls must be “tested” or “Audited” regularly.

For example, if a control defines that we will encrypt all laptops because there is a risk of employees losing or getting laptops stolen then we need to check periodically that all laptops have been encrypted. In eramba, for every internal control you create, you can OPTIONALLY define the following attributes for every control:

• When you will test the internal control (every 5ht of March, etc)
• How you will test it (evidence, analysis, etc)
• Sucess Criteria (how you can tell it is a pass or a fail)

If you do not trust your Internal Controls, then you need to test them more often and in more detail. If you trust your Internal Controls then you can reduce both variables.

The "cost" of testing a single control is:

For example, in the "End-Point Laptop Encryption" control example:

• I plan to test 4 times a year
• each test will take me 5 hours
• I can then budget 20 hours of work (remember, time is money).

As explained before, you will have more than one control so numbers depend in the end on three variables as shown in the table below:

Number of Controls	Average number of tests per year	The average duration of each test	Hours Required
50	1.5	3 Hours	225 Hours / Year
75	1.5	3 Hours	315 Hours / Year
100	3	3 Hours	900 Hours / Year

Often people ask us, how much should I test? well, it depends on how much assurance your business needs. If your boss wants to pass "PCI-DSS" audits no matter what or wants to "mitigate" all Risks no matter what, then you will need many controls and more testing to ensure all works when auditors come. You would have tested everything in advance so much you will know exactly how your company controls work.

You should be able to provide your finance team with a good estimation of the amount of money that will cost using the tables above.

Broad Vs. Specific

When you create a control you will have to name it and then specify what the control objective is and optionally how you will test it.

Typically controls fall under two categories, "Broad" and "Specific". The following table shows the equivalent of one broad control against three specific controls.

There are pros and cons against creating one or the other, here is a table that summarises the issue:

Testing Owners

Imagine your company does Change management in all departments, from approving a business trip to making a change in a system. Documenting Internal Controls that follow one process but are executed by different teams might result in more than one control

The broad control	Or specific controls?
Change Management	Change Management - Cloud Team
	Change Management - Applications Team
	Change Management - Database Team

Imagine you create one control that includes all three teams and your audit methodology takes evidence from all three teams. What would be the result of the audit if the Applications teams messed up but the other two did well? Fail or Pass? If you set it to Fail, then the other two teams will most likely remind you they did well.

For that reason, sometimes you might need more than one control even if they relate to the same procedure.