ISO 27001 Statement of Applicability ISO27001: 2005 Ref. ISO27001: 2013 ref Section / Title SPF Ref. V10 (new) Progress Evidence Responsibility Recommendations / Actions Document name / location A.5 SECURITY POLICY A.5.1 Information security policy A.5.1.1 Information security policy document MR 4 MR 6 Complete Information Security Policy InfoSec Mgr.
Here is an example on how I have created an Excel spreadsheet to mirror the Annex A and have called it our Statement of Applicability. We use a simple scale to evaluate relevance of the controls to our organizations.
We have had this discussion on this forum before, but our scale is at a high level and of course can get much more granular as the organization matures. For most groups and organization going through the ISO review/audit process, it is hard enough to figure out if the control is: 1) Applicable, implemented, and measured by this organization. 2) Applicable, implemented locally and measured by another corporate organization. 3) Not Applicable: No business conducted for this objective.
Option 1: means that this group is in complete control of the objective such as for example the Asset Management process Option 2: means that this group must follow and abide to this objective but is mandated and managed by another corporate group, such as HR or Corporate real estate Option 3: means that this this groups does not require this controls, for example if the organization does not do any software development, then those controls would be out of scope. If they are still working on a control or have not implemented and plan to implement, we mark this as a finding and document that they do not have sufficient controls in this area. As internal auditors we scrutinize anytime the group selects to take one of the ISO controls out of scope.
The external auditor will also scrutinize because the ISO certification board will as well. There is no Requirement for the SoA to describe how the control has been implemented.
'justifications for inclusion, whether implemented or not, justifications for exclusion' but Auditors find the SoA a very useful document, and I think the more info you can put on there about your impementation of the control, the happier your auditors will be. A short para describing your implementation, with links to procedures, evidence etc. Is well worth considering, and is useful practice to just make you assess your own level of implementation if nothing else. Ed Robert Whitcher 12/4/2016, 3:56 น.
My view is that the justification for inclusion or exclusion of a control is the risk assessment process. It should clearly show the risks and the risk treatment by selecting a control from Annex A (or elsewhere). Why would you need something different? The SoA does have to show whether a control has been implemented, which the example posted doesn't appear to show. Please remember the two updates to the standard which can be found on ISO's website by entering ISO/IEC 27001 in the search field.
Both updates are clarifications, but the do help. My question is really focused on the controls that really refer to implementation of the standard itself - like the two I listed above. Controls like multi-factor auth, web application firewall, fire suppression, etc, will clearly fall out from the risk assessment and hence have direct justifications.
But do I need to reverse engineer risks to justify the controls that refer to standard itself? I see that some use generic justifications (for some?) controls.
Is this acceptable? Or do I need a justification like in my examples? Or a specific risk?
Also, I am not implying that I would not provide other details about the controls. It's just that I am asking about justification specifically.
Ed 12/4/2016, 9:45 น. It should be possible to justify almost everything we do - otherwise why do we do it? The ISMS itself can be justified in business terms: compared to not having an ISMS, management will be able to handle the organization's information risks better i.e. More efficiently and more effectively, in a more structured, systematic and deterministic manner (as opposed to lurching from one crisis to the next!). Management can more easily identify and if appropriate adopt generally-accepted good information security practices, avoid or cut down on poor practices, fulfil assorted compliance obligations or expectations, and continuously adapt the approach in response to changes and to drive further improvements. These are the sorts of assertions that might be made in a business case or investment proposal for the ISMS, preferably with more details to explain and substantiate them in the context of the particular organization and its broader business objectives, goals, strategies and constraints. For further inspiration, the introduction to 27001 states (in part): 'The information security management system protects the confidentiality, integrity and availability of information by applying a risk management process and gives confidence to interested parties that risks are adequately managed.
It is important that the information security management system is part of and integrated with the organization’s processes and overall management structure and that information security is considered in the design of processes, information systems, and controls. It is expected that an information security management system implementation will be scaled in accordance with the needs of the organization.' A further justification is that.certified. compliance demonstrates the organization's commitment to the information risk management principles and practices espoused in international standards, enhancing brand value etc. I'm not sure the standard formally requires you to incorporate any of that in your SoA, specifically, but someone probably ought to think through your organization's business objectives for the ISMS (adding more specific details to the generic blah that I've offered above), document them, discuss them and the options for achieving them with management, use them to generate management-level metrics, and occasionally review/revisit them to make sure the ISMS continues to support the business.
Kind regards, Gary Dr Gary Hinson PhD MBA CISSP Cprof CEO of IsecT Ltd., New Zealand Passionate about information risk and security awareness, standards and metrics -Original Message- From: mailto: On Behalf Of Barry Kaplan Sent: Wednesday, 13 April 2016 4:32 a.m. To: ISO 27001 security Subject: ISO 27001 security SOA control justifications Beatrice Turler 13/4/2016, 3:42 น.