Seven Keys to Information Security Policy Development

How mature is your information security policy program? Do you have a set of outdated documents stored in a binder or intranet site? Or do you have a documented management program that keeps your policies up to date, your users informed and your internal auditors sleeping at night?

In this article we review seven key characteristics of an effective information security policy management program. These elements are culled from our leading practices, information security and privacy frameworks, and incidents involving information security policies. Organizations can use this checklist to evaluate the maturity of their existing information security policies.

1. Written Information Security Policy Documents with Version Control

Even though it seems obvious, nearly every information security standard and framework specifically requires information security policies to be written. Since written information security policies define management's expectations and stated objectives for protecting information, policies cannot be "implied" - but have to be documented. Having a "written security policy document" is the first key control established within the international standard ISO/IEC 1-7799:2005 (ISO 27002), and is critical to performing both internal and external audits. But what are some characteristics that make for an effectively-written policy document?

2. Defined Policy Document Ownership

Each written information security policy document should have a defined owner or author. This statement of ownership is the tie between the written policies and the acknowledgement of management's responsibility for updating and maintaining information security policies. The author also provides a point of contact if anyone in the organization has a question about specific requirements of each policy. Some organizations have written information security policies that are so out-of-date that the author is no longer employed by the organization.

3. Targeted User Groups for each Security Policy

Not all information security policies are appropriate for every role in the company. Therefore, written information security policy documents should be targeted to specific audiences with the organization. Ideally, these audiences should align with functional user roles within the organization.

For example, all users might need to review and acknowledge Internet Acceptable Use policies. However, perhaps only a subset of users would be required to read and acknowledge a Mobile Computing Policy that defines the controls required for working at home or on the road. Employees are already faced with information overload. By simply placing every information security policy on the intranet and asking people to read them, you are really asking no one to read them.

4. Comprehensive Information Security Topic Coverage

Since written information security policies provide the blueprint for the entire security program, it is critical that they address the key logical, technical and management controls required to reduce risk to the organization. Examples include access control, user authentication, network security, media controls, physical security, incident response, and business continuity. While the exact profile of each organization is different, many organizations can look to regulatory requirements to define the security policy topic coverage for their organization. For example, healthcare companies within the United States must address the requirements of HIPAA, financial services companies must address the Gramm-Leach-Bliley Act (GLBA), while organizations that store and process credit cards must follow the requirements of PCI-DSS.

5. A Verified Policy Awareness and Audit Trail

Security policy documents will not be effective unless they are read and understood by all members of the target audience intended for each document. For some documents, such as an Internet Acceptable Use Policy or Code of Conduct, the target audience is likely the entire organization. Each security policy document should have a corresponding "audit trail" that shows which users have read and acknowledged the document, including the date of acknowledgement. This audit trail should reference the specific version of the policy, to record which policies were being enforced during which time periods.

6. A Written Information Security Policy Exception Process

It may be impossible for every part of the organization to follow all of the published information security policies at all times. This is especially true if policies are developed by the legal or information security department without input from business units. Rather than assuming there will be no exceptions to policy, it is preferable to have a documented process for requesting and approving exceptions to policy. Written exception requests should require the approval of one or more managers within the organization, and have a defined time-frame (six months to a year) after which the exceptions will be reviewed again.

7. Regular Security Policy Updates to Reduce Risk

Auditors, regulators, and federal courts have consistently sent the same message - No organization can claim that it is effectively mitigating risk when it has an incomplete, outdated set of written policies. Written security policies form the "blueprint" for the entire information security program, and an effective program must be monitored, reviewed and updated based on a continually changing business environment. To help organizations with this difficult task, some companies publish a library of written information security policies that are updated regularly based on the latest information security threats, regulatory changes and new technologies. Such services can save organizations many thousands of dollars maintaining written policies.