In my last three 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 and objectives. We left the podium wondering how one should go about writing a security policy. Let us go ahead…
Different personnel have different perspective of looking towards security policy, few are listed below:
- Security policy is nothing but you may copy a policy document for another organization, change everywhere name to current organization and it’s almost done. My take- you can always refer to some existing policies but ditto copying is not only violation of IP but also will not match organization respective security requirements. Try avoid doing it.
- Security policy document must not contain mandatory control but only the policy statements of applicable security controls. Some auditors claim that mandatory controls or security framework can be a part of different document called as ISMS policy which is different from security policy. My take- You decide, one document or two documents- ISO27001 never mandates anything on it. It depends on how better you may manage one/ two docs. Legibility is good in having two docs but it has document management overhead. You may always contest auditor, if one asks for two.
- Security policy document should contain “What is to be done” and not “how this is to be done” as the later part has to be included in procedure document. My take- I agree but sometimes, SMEs simply copy paste the statements given in ISO 27001 standard which is not correct. I would recommend not to leave the flavor of standard but try to bring originality in your document by reframing the sentences and at times you may shuffle the positions of mandatory controls, though some auditors may not agree to this and there is no harm if little tweaking to be done just to satisfy auditors.
- I have seen some government auditors commenting “your policy is good but it doesn’t seems if it belongs to the target organization” in another word they want to highlight that flavor of customer organization is missing. My take- use terminologies, technologies (not specific product as they are likely to change over time) used by the customer generously in your policy document. This will not only bring required flavor also it will make the document resilient to be copied if one tries to do that thus an attempt to save your IPR.
- Security policy document has to be short as this will encourage readers to go through it. My take- Agreed but again it depends what additions/ subtractions you may want to do here based on your bandwidth of document management.
Can’t think of more right now, and readers may add few as comments but before we write down a policy we have to ask ourselves a simple question “What is the basis of this security policy?” Ideally its basis are context of the organization which we covered in while defining scope and the security requirements for the organization. What are the different sources to collect the security requirements for the customer? How do I record them? Let us try to find out these answers in my next post… thanks for giving your time to read.
Will try to continue this series to give an insight of how one should go about certifying n organization for ISO27001.