{"id":1682,"date":"2018-11-30T12:53:57","date_gmt":"2018-11-30T12:53:57","guid":{"rendered":"https:\/\/iso27001.solutions\/?p=1682"},"modified":"2019-03-11T17:57:46","modified_gmt":"2019-03-11T17:57:46","slug":"how-to-write-your-information-security-policy-according-to-iso-27001","status":"publish","type":"post","link":"https:\/\/ismsalliance.com\/trends\/about-iso-27001-standard\/how-to-write-your-information-security-policy-according-to-iso-27001\/","title":{"rendered":"How to write your Information Security Policy according to ISO 27001"},"content":{"rendered":"
An information security policy is the cornerstone of an information security program. It should reflect the organization’s objectives for security and the agreed upon management strategy for securing information.<\/p>\n
In order to be useful in providing authority to execute the remainder of the information security program, it must also be formally agreed upon by executive management. This means that, in order to compose an information security policy document, an organization has to have well-defined objectives for security and an agreed-upon management strategy for securing information. If there is debate over the content of the policy, then the debate will continue throughout subsequent attempts to enforce it, with the consequence that the information security program itself will be dysfunctional.<\/p>\n<\/div>
There is a plethora of security-policy-in-a-box products<\/a> on the market, but few of them will be formally agreed upon by executive management without being explained in detail by a security professional<\/a>. This is not likely to happen due to time constraints inherent in executive management.<\/p>\n Even if it was possible to immediately have management endorse an off-the-shelf policy, it is not the right approach to attempt to teach management how to think about security. Rather, the first step in composing a security policy is to find out how management views security. As a security policy is, by definition, a set of management mandates with respect to information security, these mandates provide the marching orders for the security professional. If the security professional instead provides mandates to executive management to sign off on, management requirements are likely to be overlooked.<\/p>\n If there is debate over the content of the policy, then the debate will continue throughout subsequent attempts to enforce it, with the consequence that the information security program itself will be dysfunctional.<\/p>\n A security professional whose job it is to compose security policy must therefore assume the role of sponge and scribe for executive management. A sponge is a good listener who is able to easily absorb the content of each person’s conversation regardless of the group’s diversity with respect to communication skills and culture. A scribe documents that content faithfully without embellishment or annotation. A good sponge and scribe will be able to capture common themes from management interviews and prepare a positive statement about how the organization as a whole wants its information protected. The time and effort spent to gain executive consensus on policy will pay off in the authority it lends to the policy enforcement process.<\/p>\n Good interview questions that solicit management’s opinions on information security are:<\/strong><\/p>\n From these questions, an information classification system can be developed (e.g., customer info, financial info, marketing info, etc), and appropriate handling procedures for each can be described at the business process level.<\/p>\n Of course, a seasoned security professional will also have advice on how to mold the management opinion with respect to security into a comprehensive organizational strategy. Once it is clear that the security professional completely understands management’s opinions, it should be possible to introduce a security framework that is consistent with it. The framework will be the foundation of the organization’s Information Security Program, and thus will service as a guide for creating an outline of the information security policy.<\/p>\n<\/div> Often, a security industry standards document is used as the baseline framework. For example, the Security Forum’s Standard of Good Practice<\/i>(www.securityforum.org<\/a>), the International Standards Organization’s\u00a0Security Management<\/i> series (27001, 27002, 27005, www.iso.org<\/a>), and the Information Systems Audit and Control Association’s Control Objectives for Information Technology<\/i> (CoBIT, www.isaca.org<\/a>). This is a reasonable approach, as it helps to ensure that the policy will be accepted as adequate not only by company management, but also by external auditors and others who may have a stake in the organization’s Information Security Program.<\/p>\n However, these documents are inherently generic and do not state specific management objectives for security. So they must be combined with management input to produce the policy outline. Moreover, it is not reasonable to expect the management of an organization to change the way the organization is managed in order to comply with a standards document. Rather, the information security professional may learn about good security management practices from these documents, and see if it is possible to incorporate them into the current structure of the target organization.<\/p>\n<\/div> It is important that security policy always reflect actual practice. Otherwise, the moment the policy is published, the organization is not compliant. It is better to keep policy as a very small set of mandates to which everyone agrees and can comply than to have a very far-reaching policy that few in the organization observe. The information security program can then function to enforce policy compliance while the controversial issues are simultaneously addressed.<\/p>\n … where people are aware that there are no exceptions to policy, they will generally be more willing to assist in getting it right up front.<\/p>\n Another reason that it is better to keep policy as a very small set of mandates to which everyone agrees is that, where people are aware that there are no exceptions to policy, they will generally be more willing to assist in getting it right up front to ensure that they will be able to comply going forward. Once a phrase such as “exceptions to this policy may be made by contacting the executive in charge of….” slips into the policy itself or the program in which it is used, the document becomes completely meaningless. It no longer represents management commitment to an information security program, but instead communicates suspicion that the policy will not be workable.<\/p>\n A security professional should consider that if such language were to make its way into a human resources or accounting policy, people could thus be excused from sexual harassment or expense report fraud. A security professional should strive to ensure that information security policy is observed at the same level as other policies enforced within the organization. Policy language should be crafted in such a way that guarantees complete consensus among executive management.<\/p>\n For example, suppose there is debate about whether users should have access to removable media such as USB storage devices. A security professional may believe that such access should never be required while a technology executive may believe that technology operations departments responsible for data manipulation must have the ability to move data around on any type of media. At the policy level, the consensus-driven approach would produce a general statement that “all access to removable media devices is approved via a process supported by an accountable executive.” The details of the approval processes used by the technology executive can be further negotiated as discussions continue. The general policy statement still prohibits anyone without an accountable executive supporting an approval process from using removable media devices.<\/p>\n<\/div> In very large organizations, details on policy compliance alternatives may differ considerably. In these cases, it may be appropriate to segregate policies by intended audience. The organization-wide policy then becomes a global policy, including only the least common denominator of security mandates. Different sub-organizations may then publish their own policies. Such distributed policies are most effective where the audience of sub-policy documents is a well-defined subset of the organization. In this case, the same high level of management commitment need not be sought in order to update these documents.<\/p>\n For example, information technology operations policy should require only information technology department head approval as long as it is consistent with the global security policy, and only increases the management commitment to consistent security strategy overall. It would presumably include such directives as “only authorized administrators should be provided access capable of implementing operating system configuration changes<\/i>” and “passwords for generic IDs should be accessed only in the context of authorized change control processes<\/i>.” Another type of sub-policy may involve people in different departments engaged in some unusual activity that is nevertheless subject to similar security controls, such as outsourcing information processing, or encrypting email communications.<\/p>\n\n
Creating a framework<\/h2>\n<\/div>
Make it about mandates<\/h2>\n<\/div>
Employing sub-policies<\/h2>\n<\/div>