In my earlier four 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. Let us now understand, how one should collect security requirement for a customer.
Security policy document generally comprises of mandatory controls given in standards and the policy statements of security controls which are selected for the project. To know the later part, we need to know security requirements of the customer and also security requirements at the time will help you to identify critical information/ data to be protected. Multiple sources of identifying same are as follows:
- Request for Proposal or RFP: The first and foremost source is an RFP issued by a client. For a large program, it may span into multiple volumes with each volume into hundreds of pages. One must go through each and every line of RFP. These documents give an idea about customer business and what is expected out of the work which is offered to its vendors. It generally gives details about the functions and technologies expected to be deployed in the project and at times, it prescribes the products to be used as well. Don’t skip volumes related to finance as it sometimes defines important milestones for the project. Some issues give sample copy of MSA (master service agreement) which also gives one idea about terms and conditions of a contract which may include security related T&C as well. At times, RFPs have security specific section and SMEs do a common mistake of confining them to the same section only but that’s not what I recommend. Read RFP end to end and you may find capturing requirements which could run into multiple hundreds of line. Don’t get stumped by looking at this volume with worries about how you will implement because implementing them is project team collective responsibility. By capturing them, you are ensuring easy tracking of same.
- Information Security Risk Assessment: An Ideal way of doing it to have a methodology defined, get it approved by the customer and do it afterward, but generally management doesn’t provide you the liberty of doing same especially due to time constraints and hence you should do a high-level risk assessment and document it. How much high the level of assessment depends upon time and knowledgeable human resources in hand? The exercise will help you identify addition security controls to be deployed, which are in addition to what we have identified from RFP.
- Discussions with client/ customer: This must not be skipped, as this not only help you to get idea of few pointers which are practical, are in customer’s mind (specially the one who are at top management or head of major functions) and you may find that such ideas are generally never got a space in any document or RFPs. These will help you identify the security critical assets/ information/ data which will always require special focus while implementing security. It is very important to record MoM of each discussion and get customer’s sign off on same. To avoid multiple visits to customer security representative may become part of the team who is collecting functional requirements from customer or one may choose to give a set of questionnaire to such team so that they may represent security SME while interacting with the customer.
Aren’t we at a stage where not only we are defining our security policy document but we are also on the verge of completing our Statement of Applicability (SoA). But what is a SoA? Shall we confine ourselves to the controls given in ISO27001 standard or do we have to choose all of them? I will discuss this in my next posts.
If you like this post, please share and comment.