In this article we will describe how eramba is typically used for ISO 27001 (Version 2022-10) requirements.
Note: there is a second guide that focus on Annex A requirements
This is a is a long but very practical read, the author of this article has certified ISO 27001 in a dozen organisations in different countries and is also an experienced eramba user.
4 - Context of the Organisation
These requirements (involved parties, their needs, which ones can be addressed by the ISMS, external and internal issues, etc) are typically documented in some policy, this document is typically stored in the Policy module in eramba.
The eramba policy module helps you write your policies, follow up their reviews, assign ownership, get notifications upon deadlines, approve these documents and also publish them all using a Policy Portal. When using the Awareness Portal you can also perform policy attestation.
You might want to use the Organisation module to document the organisation External and Internal issues, you can read more about the organisation module on this post: Program Module - What is it for? - #2
5- Leadership
In 5.1 the idea is to make it clear to auditors the senior management loves the idea of implementing and operating an ISO 27001 ISMS. The easiest way to prove this is by having your ISMS Policy (requirement 5.2) on eramba’s Policy module, this policy will be subject to reviews with management approval.
The eramba policy module helps you write your policies, follow up their reviews, assign ownership, get notifications upon deadlines, approve these documents and also publish them all using a Policy Portal. When using the Awareness Portal you can also perform policy attestation.
In 5.1 ISO mentions (5.1.a and 5.1.e where the outcomes are measured) “information security objectives”, which in eramba lingo means “Goals”. This is also refered to in 6.2. Here we basically agree with senior management what goals we want to achieve with all this ISO thing and somehow measure if we are there or not.
You might want to use the Organisation module to document and measure the organisation Goals, you can read more about the organisation module on this post: Program Module - What is it for? - #2
In 5.2 we are asked for a piece of paper, formally known as “Information Security Policy” that as mentioned already will be stored in the Policy module.
In 5.3 we write in stone those that manage the ISMS and are responsible to make the magic happen. This is either a piece of paper (typically part of the “Information Security Policy”) or you can also use the Organisation module to document these roles.
You might want to use the Organisation module to document ISMS roles and responsabilities, you can read more about the organisation module on this post: Program Module - What is it for? - #2
6 - Planning
6.1.1 is telling you to think what can go wrong when trying to deal with the issues you defined in 4.x. In our experience this is part of Risk Management (comes later) and therefore nothing to be worried much here.
ISO 27001 (2022, previous versions were a bit different here, see the CIA article for example) likes to split Risk Management in two parts: assessment (finding risks), treatment (doing something with them),
The Risk module in eramba helps you identify, document, classify, review and treat Risks in your organisation, no matter what their origin is. This module is perfectly compatible with ISO and most International Risk frameworks.
6.1.2.a-1-2, this is basically Risk Classifications and Risk Matrix, this is the place where you tell eramba how you want to classify Risks and what in theory you will do based depending on that classification, the key here for ISO is that you are “consistent”. They do not care how you do this as long as it is “consistent, valid and comparable”.
6.1.2.c here the standard talks about identifying risks, finding them. eramba does not find risks in your organisation for you, this is typically done through interviews with human beings. These interviews can be done with Online Assessments or simply talking in the coffee corner of your office (if your company still has them).
The online assessment module helps you define any questionaire you want using Spreadsheet files and then submitting them to anyone (inside or outside your organisation). The recipients will receive email notifications and be redirected to a special portal where they will submit their answers for your review.
Is important to highlight, the standard does not use the word “Threat” or “Vulnerability” anywhere when referring to risks identification since the 2005 standard. It does also not mention the word “Asset” anywhere (the entire 27001 standard). This means you could come up with a list of Risks with no relation to these attributes and be perfectly certifiable.
6.1.2.c also talks about risk owners, this is very important in eramba and in fact a mandatory field when creating risks.
6.1.2.d well here you need to classify your risks, while it does not tell you how to do it, it does say that you must (yes, must) consider their “consequences” and “likelihood” and out of that, define their risk “leve”. In eramba you will classify risks in any way you want (is a setting) and the level of Risk will be shown based on a Risk matrix (which you also define).
6.1.2.e you are supposed to be able to compare risks in between then, easy peasy in eramba. You can use views.
Views in eramba let you see data in a module, you can adjust its sorting, the columns you wish to see and which ones you prefer to hide, you can filter data against those filters, you can export as CSV and many more.
6.1.3 here the idea is that once you identified Risks, you define somehow (is not really mandated how) their treatment.
In eramba you have four possible treatment options, Internal Controls, Policies, Exceptions and Projects.
The internal control module documents activities performed in your company such as latpop encrpyion, provision and de-provision of accounts, change management, log reviews, etc. These Internal Controls will help explain people what you “do” (activities, remember?) in order to deal with Risks and Compliance requirements. These controls in eramba can be tested at regular intervals to collect and analyse evidence that proves they work (or not).
The eramba policy module helps you write your policies, follow up their reviews, assign ownership, get notifications upon deadlines, approve these documents and also publish them all using a Policy Portal. When using the Awareness Portal you can also perform policy attestation.
The exception module helps you document the situation where the organisation has decided that no treatment is needed for a Risk and until a certain deadline arrives that is the decision.
The project module helps you define what your organisation will do IN THE FUTURE to deal with a problem (Risk, Compliance requirement, failed Control, failed Policy, Etc). The project module has owners, deadlines, tasks, Etc.
Here ISO also tells you something like, choose form our Annex controls which ones are applicable for your Risks. ISO is explicit you can use your own controls and that their Annex list is by no means complete.
In eramba the SOA document will be extracted from the Compliance module, for every Annex control you can (optionally) link Risks. In that way you will see Annex controls and Risks mapped. If you need to exclude Annex controls you can use Compliance Expcetions.
The Compliance Exceptions module is used to document the decision of the organisation that a given compliance requirement (ISO or whatever) is not applicable to the organisation. Exceptions have owners, deadlines, notifications, etc.
6.1.3.e the “plan” iso refers, in eramba is the whole story we have discussed so far. As for item “f” the approval of the Risk Owner is recorded as part of the Risk Reviews.
6.2 no longer talks about Risk (finally…!) and moves to the “Objectives” or as we call them “Goals” story. We have discussed this as part of 5.1, the Organisation module can help with this.
You might want to use the Organisation module to document and measure the organisation Goals, you can read more about the organisation module on this post: Program Module - What is it for? - #2
Note that ISO is pretty explicit on many things that MUST be explained for each one of these goals, for example: what will be done, responsible people, when they will be completed, etc.
Some people uses the Project Management module for this since it sort of aligns well, the exception is that Goals in eramba can be regularly tested while Projects not (they are assumed that they start and end at some point)
The project module helps you define what your organisation will do IN THE FUTURE to deal with a problem (Risk, Compliance requirement, failed Control, failed Policy, Etc). The project module has owners, deadlines, tasks, Etc.
7 - Support
7.2 this one is very similar to 5.3 in the sense that when you document the roles and responsibilities in eramba, you can also upload as attachment to these items proof of their “competence” as ISO calls it (certifications, degrees, etc)
You might want to use the Organisation module to document ISMS roles and responsabilities, you can read more about the organisation module on this post: Program Module - What is it for? - #2
7.3 here you will most likely need to create one short awareness course for each department, where you describe what “things” they need to be aware (risks, controls they operate, etc). Typically a few slides is enough.
The awareness program module in eramba helps you upload videos, disclaimer texts and multiple choice questionnaires and define audiences that must complete these trainings at regular intervals.
7.4 here you typically have a document on the policy module where you describe how you will communicate in the event of incidents, issues, etc.
The eramba policy module helps you write your policies, follow up their reviews, assign ownership, get notifications upon deadlines, approve these documents and also publish them all using a Policy Portal. When using the Awareness Portal you can also perform policy attestation.
7.5 well here ISO says that you need to document the things required on this standard, for this again we use the policy module. 7.5.2.c clearly states you need to get them approved (no specifications by whom) and reviewed (this implied regularly), these two tasks are also covered by the policy module. 7.5.3 talks about making this documents available and for that you have the policy portal in eramba.
The eramba policy module helps you write your policies, follow up their reviews, assign ownership, get notifications upon deadlines, approve these documents and also publish them all using a Policy Portal. When using the Awareness Portal you can also perform policy attestation.
8 - Operation
In theory all you need to do to “run” the ISMS is here (is not, there are more things in real life) but the focus is on “plan, implement and control the processes”. In eramba these processes will be documented and audited (tested) as “Internal Controls”.
The internal control module documents activities performed in your company such as latpop encrpyion, provision and de-provision of accounts, change management, log reviews, etc. These Internal Controls will help explain people what you “do” (activities, remember?) in order to deal with Risks and Compliance requirements. These controls in eramba can be tested at regular intervals to collect and analyse evidence that proves they work (or not).
8.2-3 is all about risk again, that you need to assess and treat risks regularly, again in eramba the risk module forces you to set risk review dates where you must perform these activities.
The Risk module in eramba helps you identify, document, classify, review and treat Risks in your organisation, no matter what their origin is. This module is perfectly compatible with ISO and most International Risk frameworks.
9 - Performance Evaluation
9.1 … this is the most expensive bit (along side 8.2-3) of the standard, because this means you need to “what needs to be monitored and measured” (this implies that there must be something you need to monitor, in any way you see fit) and then it talks about “selected should produce comparable and reproducible results” … meaning that your monitoring must be systematic. Is very specific about defining “dates”, “who”, “results”, etc. The “Internal Control” module in eramba does this in detail. You need to produce evidence of doing this or you will get in trouble, auditors will look in detail against Annex controls (and any other control you may have).
The internal control module documents activities performed in your company such as latpop encrpyion, provision and de-provision of accounts, change management, log reviews, etc. These Internal Controls will help explain people what you “do” (activities, remember?) in order to deal with Risks and Compliance requirements. These controls in eramba can be tested at regular intervals to collect and analyse evidence that proves they work (or not).
9.2 is about “Internal Audits” , this means that at “planned intervals” (so here they don’t say how often you must do it) there must be a review of the ISMS (including its processes, remember point 8) by “select auditors and conduct audits that ensure objectivity and the impartiality of the audit process” … this means it can not be you.
The idea here is, you will test your own controls using the “Internal Control” module over the year (as per 9.1) and then, you will call someone (can be an internal audit department, an external company, etc) to do their own test, but since you have tested they will most likely rely on your testing for the most part. Of course they will have additional questions and sampling, but if you test more or less the same way they would test, you are sure things will be ok. This is the very key piece of ISO, TESTING BEFORE HAND.
9.3 - Management Review
with all their wisdom, managers need to do their part (tiny, very well paid part) and here ISO says that managers, not just have to empower people to implement and operate the ISMS (requirement 5), but also must “Review” (you can imagine how much these people understand of all this).
this is often times called a “Committee” meeting, which is a glorified name for a meeting with slides where you show, typically, the result of your “monitoring” (requirement 9), risk operational landscape (requirement 8) and how the goals / objectives are fantastically being met (requirement 5). A few slides will do, you can copy/paste eramba built in reports / charts too.
Note that ISO is pretty speific on the content on this meeting, many times auditos compare that the agenda of your committee includes each one of these points, i recommend not missing any of them even if they don’t make a lot of sense.
The outcome of this meeting, is a document on the policy module.
The eramba policy module helps you write your policies, follow up their reviews, assign ownership, get notifications upon deadlines, approve these documents and also publish them all using a Policy Portal. When using the Awareness Portal you can also perform policy attestation.
10 - Improvement
This one is an auditor favourite, the story here is that when a “nonconformity” is identified (there is no definition of what this means in the standard, but in theory means when a requirement is not met) you should have a “Plan” on how you will get it fixed. This is often times: internal controls audit findings, incidents, external audit findings, etc. The “Project Management” module is good for this.
The project module helps you define what your organisation will do IN THE FUTURE to deal with a problem (Risk, Compliance requirement, failed Control, failed Policy, Etc). The project module has owners, deadlines, tasks, Etc.