In my last five articles, we understood about, deployment of initial security resource, understanding the standard and its mandatory controls, defining scope/ out of scope items, security ownerships visions, objectives and some perspectives about security policy with its basis. Let us now understand about Statement of Applicability.
Statement of Applicability or SoA is simply a formal declaration of all the security controls an organization has adapted to take forward its security program. This document is directly related to the scope of ISMS as security controls to be deployed must be applicable to the assets covered by the scope and hence has to be carefully selected. It is a must document if one wants to go in for ISO27001 certification. Generally, after security policy, the next thing auditor asks for is the SoA and I have seen auditors questioning the SoA based on the scope of ISMS and based on same comes the recommendation for inclusion/ exclusion of some controls.
Because we are going to ISO27001 certification, we have to give justification for each and every control we have selected from the standard and also the justification for not selecting a control from the standard. But do we restrict ourselves to the controls which are given in standard or is there something extra we may do? The answer is that ISO27001 has given the list of security objectives and controls which are generally applicable to most of the organizations, however, it allows to select control partially from it, or adapted it completely and also allows you to add your own controls to it and there is no limit to those numbers. Similarly, ISO27002 gives the code of practice for this standard which means though it gives you a fairly good amount of idea on how to implement a certain control by giving some implementation pointers, but again it never mandates you to specifically implement the given guidelines. One always have the option to implement the control in one’s own way without following ISO27002, as far as the basic objective of control is met and same may be proved to the auditor as well. But sometimes, RFPs specially mention compliance towards ISO27002 as well, so here the project requirement doesn’t allow you to skip them, hence mind your requirements very cautiously and clearly
We got slightly deviated from our SoA topic, so now want to through some light on how to make a SoA. Generally, it is a good practice to have it as a separate document. For the large organization as having multiple types of entities having the different type of controls applicable to different entities, there are two ways. One, make a common SoA for the entire organization and maintain a delta SoA at location/ entity level, specifying differences with common SoA. Two, make SoA document in a matrix fashion with each type of entity as column and controls as rows and now applicability and justification can be filled at relevant places in this matrix. I prefer the second one as it is easier to maintain especially when you have limited or almost nil presence of core security team at distributed locations/ entities. Also, make sure that mapping or each control you select is given to the exact clause mapping to the ISO27001 standard while clearly identifying additional controls, if any or be assured of getting this as an action item in your audit.
Will try to continue this series to give an insight of how one should go about certifying n organization for ISO27001. I have also posted an article on the importance of documentation when we execute a project which is equally applicable when we are doing ISO27001 certification so requesting readers to go through same as well, though not marked as part of this series. But am seriously looking forward to comments, which are just not coming and requesting again for same.
Look forward to seeing you in next article.
Authored by Naveen Gupta