Basics

How to Write an Information Security Policy

Jennifer Bayuk explains the critical first step, what to cover and how make your infosec policy - and program - effective

By Jennifer Bayuk

Page 3

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.

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.

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" and "passwords for generic IDs should be accessed only in the context of authorized change control processes." 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.

On the other hand, subject-specific policies that apply to all users should not be cause to draft new policies, but should be added as sections in the global policy. Multiple policies containing organization-wide mandates should be discouraged because multiple policy sources make it more difficult to accomplish a consistent level of security awareness for the any given individual user. It is hard enough to establish policy-awareness programs that reach all in the intended community, without having to clarify why multiple policy documents were created when one would do. For example, new organization-wide restrictions on Internet access need not be cause to create a new "Internet Access" policy. Rather, an "Internet Access" section can be added to the global security policy. Another caveat for the security professional using the sub-policy approach is to make sure sub-policies do not repeat what is in the global policy, and at the same time are consistent with it. Repetition must be prohibited as it would allow policy documents to get out of sync as they individually evolve. Rather, the sub-documents should refer back to the global document and the two documents should be linked in a manner convenient for the reader.