Risk and Certification
Risk too...for Certification
The previous discussion on information and cyber security risk was focused toward the micro and small business; the purpose being an attempt to get their ball-rolling on looking at risk.
Certification to ISO/IEC 27001:2013 (information security management system (ISMS), requirements) needs the business to seriously focus on information and cyber security risk. In fact, clause 6 (Planning) and its sub-clauses are all focused on risk; this is the 'plan' element of the plan, do, check, act (PDCA) dance. On the other hand, clause 8 (Operation) and in particular 8.2 and 8.3 are all about carrying out risk assessment and treatment, the 'do' element of PDCA.
The International Organisation for Standardisation (ISO) does not dictate to your business any particular process or methodology for risk. But, whatever process you adopt it must produce consistent, valid and comparable results (clause 6.1.2b). If not, the system will collapse because, and let me be frank about this, it will not be an effective.
ISO/IEC 27001:2013 (27K1:13) is split into two parts - Clauses, and Annex A. Whilst the clauses will need some serious interpretation, it is Annex A that appears to cause one of the biggest challenges.
Let's bust a myth here; Annex A is catalogue of 114 controls, and as pointed out within ISO/IEC 27003:2017 (information security management system, guidance) they are a generic representation of controls and as highlighted in 27K1:13 under note 1 within clause 6.1.3c; Annex A is there to ensure that no necessary controls are overlooked. Although Annex A is important, you are justified in using other control catalogues (e.g.: NIST SP 800-53r5 (or 4)) if they are more appropriate when addressing the business risk treatment options. It is a business decision, not an ISO or Certifying Body decision.
Another myth to bust is one that is centred upon why a particular control (or set of controls) has been implemented. There is a simple answer to this conundrum; it is because the business has identified a need through the risk assessment process; a decision has been made to treat that risk (in someway) and has implemented a particular control (or measure). It is a business decision, not an ISO or Certifying Body decision.
The problem (and it is a serious problem) is when a business has simply knee-jerked, implemented a control (usually a technical one) without actually justifying (through the risk process) its need. In terms of your ISMS, and your certification, the cracks will start to form. If they do then any Certifying Body (CB) auditor worth their salt, will point these cracks out to you.
Final (for today at least) myth to bust is the Statement of Applicability (SoA). To kick-off, this is a required document (Clause 6.1.3d) that contains the necessary controls. To this end it is an output document, not an input document. It is the output of your risk process all tied up with a nice neat bow. If your CB is due to audit your ISMS on Tuesday, then run the SoA off on the Monday - fresh, uptodate and ready to go. One final point on the SoA. This is a seriously important document, not simply for CB audit purposes, because it contains a 'roadmap' of your information and cyber security controls, and the status of those controls. Should the document ever fall into the wrong hands, just think about the consequences for a second or two. In fact, why not simply do a risk assessment on the information that the SoA contains, and determine what if any treatment/controls need to be put in place to protect (secure) that information.
Points to take away:
Let's bust a myth here; Annex A is catalogue of 114 controls, and as pointed out within ISO/IEC 27003:2017 (information security management system, guidance) they are a generic representation of controls and as highlighted in 27K1:13 under note 1 within clause 6.1.3c; Annex A is there to ensure that no necessary controls are overlooked. Although Annex A is important, you are justified in using other control catalogues (e.g.: NIST SP 800-53r5 (or 4)) if they are more appropriate when addressing the business risk treatment options. It is a business decision, not an ISO or Certifying Body decision.
Another myth to bust is one that is centred upon why a particular control (or set of controls) has been implemented. There is a simple answer to this conundrum; it is because the business has identified a need through the risk assessment process; a decision has been made to treat that risk (in someway) and has implemented a particular control (or measure). It is a business decision, not an ISO or Certifying Body decision.
The problem (and it is a serious problem) is when a business has simply knee-jerked, implemented a control (usually a technical one) without actually justifying (through the risk process) its need. In terms of your ISMS, and your certification, the cracks will start to form. If they do then any Certifying Body (CB) auditor worth their salt, will point these cracks out to you.
Final (for today at least) myth to bust is the Statement of Applicability (SoA). To kick-off, this is a required document (Clause 6.1.3d) that contains the necessary controls. To this end it is an output document, not an input document. It is the output of your risk process all tied up with a nice neat bow. If your CB is due to audit your ISMS on Tuesday, then run the SoA off on the Monday - fresh, uptodate and ready to go. One final point on the SoA. This is a seriously important document, not simply for CB audit purposes, because it contains a 'roadmap' of your information and cyber security controls, and the status of those controls. Should the document ever fall into the wrong hands, just think about the consequences for a second or two. In fact, why not simply do a risk assessment on the information that the SoA contains, and determine what if any treatment/controls need to be put in place to protect (secure) that information.
Points to take away:
- Information and cyber security risk management is central to your ISMS;
- ISO does not dictate the risk process you adopt; there are stacks available - some good, some not so good - it's your choice. But, whatever you do, you must do something;
- On the understanding that as a business you are in fact planning and operationally conducting risk assessments, the output (treatment/controls) will be a business decision, based upon its needs, not those of ISO or the CB.
- Annex A is a reasonable (if a bit out of date) catalogue of controls; others are available, and you can use them or, design your own. On the understanding of course that you have justified why your are doing what you are doing through the risk process.
- Your SoA is an output document that should be kept confidential to the business.
- The direction of travel is - risk assessment process --> treatment options --> controls (measures). Not, controls (measures) then fudge the risk process later on down the line.
- There is an awful lot more to achieve for example; the 'check' element of the PDCA dance has not yet been covered. Think about monitoring and reviewing the controls (measures) you have adopted. Do they remain valid?
- Last (but not least) - communicate. Talk to people (internal and external stakeholders), let them know what is happening, or seek guidance. Whatever you do, communicate.
