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

Supplementary documents to consider are:

Roles and responsibilities -- Descriptions of security responsibilities executed by departments other than the security group. For example, technology development departments may be tasked with testing for security vulnerabilities prior to deploying code and human resources departments may be tasked with keeping accurate lists of current employees and contractors.

Technology standards -- Descriptions of technical configuration parameters and associated values that have been determined to ensure that management can control access to electronic information assets.

Process - Workflows demonstrating how security functions performed by different departments combine to ensure secure information-handling.

Procedures -- Step by step instructions for untrained staff to perform routine security tasks in ways that ensure that the associated preventive, detective, and/or response mechanisms work as planned.

Guidelines -- Advice on the easiest way to comply with security policy, usually written for non-technical users who have multiple options for secure information-handling processes.

What an Information Security Policy Includes

This leaves the question: what is the minimum information required to be included in an Information Security Policy? It must be at least enough to communicate management aims and direction with respect to security. It should include:

1. Scope -- should address all information, systems, facilities, programs, data, networks and all users of technology in the organization, without exception

2. Information classification - should provide content-specific definitions rather than generic "confidential" or "restricted"

3. Management goals for secure handling of information in each classification category (e.g. legal, regulatory, and contractual obligations for security, may be combined and phrased as generic objectives such as "customer privacy entails no authorized cleartext access to customer data for anyone but customer representatives and only for purposes of communicating with customer," "information integrity entails no write access outside accountable job functions," and "prevent loss of assets")

4. Placement of the policy in the context of other management directives and supplementary documents (e.g., is agreed by all at executive level, all other information handling documents must be consistent with it)

5. References to supporting documents (e.g. roles and responsibilities, process, technology standards, procedures, guidelines)

6. Specific instruction on well-established organization-wide security mandates (e.g. all access to any computer system requires identity verification and authentication, no sharing of individual authentication mechanisms)

7. Specific designation of well-established responsibilities (e.g. the technology department is the sole provider of telecommunications lines)

8. Consequences for non-compliance (e.g. up to and including dismissal or termination of contract)

This list of items will suffice for information security policy completeness with respect to current industry best practice as long as accountability for prescribing specific security measures is established within the "supplementary documents" and "responsibilities" section. While items 6 and 7 may contain a large variety of other agreed-upon details with respect to security measures, it is ok to keep them to a minimum to maintain policy readability, and rely on sub-policies or supporting documents to include the requirements. Again, it is more important to have complete compliance at the policy level than to have the policy include a lot of detail.

Note that the policy production process itself is something that necessarily exists outside of the policy document itself. Documentation with respect to policy approvals, updates, and version control should also be carefully preserved and available in the event that the policy production process itself is audited.

Jennifer Bayuk is an information security consultant and former CISO. She has written or co-edited several books including Enterprise Information Security and Privacy, Stepping Through the IS Audit, 2nd Edition, Stepping Through the InfoSec Program, and a forthcoming work on Security Leadership.

Tags security policy

Show Comments