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 it must be done systematically, for example, you want all laptops to be built the same way (encryption, authentication, etc). Therefore often times (if not all the time) you will have a documented process that describes how that is done (step one, step two, etc).

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" example the following documents could be applicable:

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

Sometimes activities are well understood and we don't need to have a piece of paper telling us how it should be done, for example, we don't need a document that explains to us how to brush our teeth!

Reflect Reality

Internal Controls are one of four "Solutions" in eramba and is very important that all your Internal Controls 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 activity (Internal Control)
The control is in use, it might not work perfectly well, which is a question of maturity, but it should by all means be in use and ready to audit if needed (it might not pass audits!)

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

A control that is not linked to a problem is like spending money on something we most likely don't need or we need but we are not able to explain why
Whoever performs solutions must understand what problem is solving, accountability is very important when creating Internal Controls as you need to validate their activity runs as expected
Often we see people documenting controls "because we know someone does them" or "because we should be doing them". In eramba you only document the reality of your organisation, if something is not done control does not exist (see the Project Management course).

Projects

If a solution (Internal Control) does not exist then you might opt to create a Project (see Project course) to describe that in the future (not now) an Internal Control will exist. The association in eramba would look as shown below how the Project module links to problems (bottom) and solutions (left).

If you have a control that is "more or less" (happens more often than most people think) you can link Projects to Internal Controls or their Audits in two scenarios:

The control is not mature, so a Project is linked
The control is mature, but it has failed an audit. A remediation plan (project) is now linked to the audit

One to One Mapping

A problem (in GRC or pretty much anywhere else in life) can have:

One solution (Internal Control)
Multiple solutions (Internal Controls)

It depends on how efficiently your GRC (and to a larger extent your organisation) operates. Ideally, you aim for the least and cheapest number of solutions. In eramba, a Risk such as the one shown below can have one or multiple solutions associated:

The same can happen with a different type of problem, such as a compliance requirement or a data flow. The control "AWS SaaS Account Reviews" shown in the screenshot above as you can see is not just dealing with that risk but also with multiple compliance requirements from NIST and ISO:

Ideally, your internal controls will be "leveraged" across multiple problems, making them look a little bit like as shown above.

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-DSS 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.

Broad Vs. Specific

Every time you create a control you are reflecting in eramba:

an activity
who is doing it
what the instructions for that activity are
optionally how you will test it

When writing a control down you will have questions, the first one will be if you should describe the activity in "Broader" or "Specific" terms. Remember you are creating solutions for (ideally) MULTIPLE problems, not ONE. Look at the table below to see a simple example of the comparison of a broad vs specific control (remember, they are activities).

The broad control	Or specific controls?
Network Firewalls	Network Configuration Standards Reviews
	Network Administrator Access Reviews
	Firewall Change Reviews

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

	Broad Internal Controls	Specific Internal Controls
Leverage	If you have 1000 problems you will not need many Internal Controls to address them all.	If you have 1000 problems you will need many Internal Controls to address them all.
Audit Methodology	Their audit will be either: Very generic, auditors might not like this. But if you don't get external audits, they are fine. Detailed and very long, making it highly likely to fail.	Their audit will be very specific, auditors will like this. This approach is much more expensive than the broad one.
Maturity	Broad controls are good for GRC programs that are starting to take form.	Specific controls will set a very high bar from the beginning and this might push your organisation too much (unnecessarily).
Implications of a Control Audit Fails	If you fail an audit for a broad control you will affect many compliance requirements (since they are broad and can meet many items) and that will be reflected on your compliance report as a lot of unwanted fails.	If you fail an audit, you will affect very few compliance requirements.

Testing Owners

Imagine your company performs "Change Management" in all departments, from approving a business trip to making a change in a system. Documenting Internal Controls (such as Change Management) that follow one process (activity) 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.

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.

Playlist