Journal Online
How to Write a Security Policy:
Paul R. Meynen is an
information security
consultant in Chicago,
Illinois, USA. He completed
the Network Security
Policy Manual as part of
an independent study
course at DePaul University,
administered by James Krev.
Meynen may be reached at
MeynenP@gmail.com.
Network Security Policy Manual
For any security professional attempting to write
a security policy, it is critical to understand
the difficulty and hair-pulling nature of the
task. What should be written? How should
it be written? Who is responsible? Writing
information security policies is an art form.
Anyone who thinks that their organizations
80-page security manual underwent writing and
approval in a couple of days should think again.
This article explains the approach the author
adopted to create the ultimate network security
policy manual. While some policy requirements
may be cost-prohibitive or a logistical headache
in certain environments, the idea is similar to a
holiday wish list where people list everything they
desire, except this is for a security environment.
This policy will evolve and mature as personal
experience advances, threats change and security
adapts. It is important to keep the policy
breathing, as it is a living document; it should not
be neglected. The security arena changes rapidly
and the security policy must keep pace.
Existing Resources and Policy Evolution
How does one effectively transform ideas and
strategies into a security policy? Most security
professionals appreciate that executive support is
crucial to implement and sustain an information
security program. To acquire and maintain this
support, the scope of the policy must be explicitly
defined and the policy statements must be
relevant and communicated to all employees.
Existing resources explain the process of
outlining a security policy manual including:1
Purpose
Objective
Applicability
Distribution
Enforcement
Monitoring
Additionally, the SANS Institute has several
examples in its Security Policy Project.2
An article may say to write a policy addressing
risk; what does that mean? Risks to network
security are defined by addressing security
standards. This article details what to document
within the sections listed previously and how to
use a standard effectively to introduce a network
security policy, providing business and IT context.
The objective is to take the language from the
standard and develop the policy statements.
The authors Network Security Policy Manual
(NSPM)3 is based primarily on the Information
Security Forum (ISF)s The Standard of Good
Practice 4 and secondarily on ISO 17799:20055
from the International Organization for
Standardization (ISO).6
Focusing on the networks domain of the ISF
standard, the NSPM covers the requirements of
four of the five control objectives:
Network management
Traffic management
Network operations
Local security management
Voice networks (the fifth control objective,
not listed above) was not included in the scope
of this policy. An easy way to write policy
statements is to transform the standards
language into a policy statement, addressing
an organizations acceptable level of risk. For
the purpose of the NSPM (and the scope of
the voice networks control objective of the ISF
standard), voice networks did not represent a
risk to the overall network and the domain was
subsequently dropped.
Additionally, the NSPM contains statements
not found in the ISF standard. Incorporating
details beyond the scope of the standard, the
NSPM includes a control for network security
and contains significant detail in the firewall
control. An individual standard is not a single,
encompassing solution; however, it may be
used to jumpstart thoughts and ideas on how to
harden network security.
Growing Pains
Throughout the writing and review of the NSPM,
a continual discovery process revealed small
changes to improve clarity of the policy. These
included:
Headings should be used to group common
policy statements.
Roles and responsibilities must be defined
to eliminate any doubt of responsibility. To
accomplish this, roles should be grouped by
position, e.g., director of network security,
ISACA JOURNAL VOLUME 1, 2009 1
 network security engineers, network security architects. Early
drafts defined roles and responsibilities throughout the policy, Policy Writing Example No. 2
creating disjointedness and lacking cohesion. Defining roles The ISF standard suggests that to alleviate a malfunction of
and responsibilities in the beginning of the policy establishes network resources, a company should ensure that network
a foundation for managing the network security program. components may be recovered. The NSPM identifies that
Moreover, this section deserves special attention because critical systems must be recovered first and that capacity
under the umbrella of an enterprisewide information security must exist to recover those systems (figure 2). Furthermore,
program, roles and responsibilities would be defined within an the NSPM incorporates recovery time objectives from the
acceptable-use policy. With the narrow focus of the NSPM on business continuity plan, clearly specifying a value beyond
network security, the network management control objective critical timescales.
addresses roles and responsibilities.
A policy manual must be developed, as opposed to four
Policy Writing Example No. 3
individual policies. Using four separate policies would lack
One must avoid defining a product or technology as it creates
continuity, making it difficult to correlate statements across
restrictions. For example:
policies. While the four control objectives listed previously are
individual policies, creating a manual with chapters provides
External access should be provided using a
context and continuity throughout the entire policy. Moreover,
Kerberos authentication server, which should
defining metadata (e.g., applicability, distribution) in the
provide reliable and complete authentication for
introduction to the policy facilitates easier management, as all
external connections.
subsequent policies adhere to a single rule set.

This explicit definition will cause problems. If the

Policy Writing Example No. 1
authentication technology changes to another solution, the
An introduction must precede both a policy and its control
policy manual must be reviewed and updated. Instead, this
objectives. This provides context to the reader and places
policy statement must be used:
focus on the subsequent policy statements. The ISF standard
and ISO 17799 provide introductory statements prior to
A dedicated remote access server will be used for
each domain and control objective. Additionally, ISO 17799
all external access; it must authenticate external
uses implementation guidance for each control, offering
connections using a reliable and accepted access
direction when constructing policy statements. Leveraging
control (e.g., Kerberos, TACACS+, Radius).
the implementation guidance and summaries will assist in
introducing a domain and its associated control objective(s).
The term e.g. is very useful as it means for example
A standard, such as the ISFs, uses the word should
and is similar to including. In other words, e.g. allows for
consistently. The use of should in a policy will not suffice,
the mentioning of sample technologies while not intending to
as it leaves potential for interpretation and presents difficulty
list all possible solutions.
in enforcing policy following a security incident. A policy is a
set of rules; therefore, the words must or will are used to
Policy Writing Example No. 4
enforce the policy statements. See figure 1.
Finally, remember that the NSPM focuses on network
Figure 1Example 1 Policy Statement Development security. There are additional domains in the ISF and
Example: Principle and objective statements (from ISF) for Incident ISO 17799 standards that would exist within an
Management Control (NW3.3) enterprisewide security program. The NSPM seeks

 rinciple: All network incidentsof any typeshould be

P Figure 2Example 2 Policy Statement Development
recorded, reviewed and resolved using an incident management
process. Example: Network Resilience Control (NW1.3.3) (from ISF).

 bjective: To identify and resolve network incidents effectively,

O The risk of malfunction of critical communications equipment,
their business impact should be minimized, reducing the risk of software, links and services should be reduced by ensuring that key
similar incidents occurring. network components can be replaced within critical timescales.

Policy statement: Any incident occurring on the network must be
recorded, reviewed and resolved following an established incident
management process. Incident management allows for rapid response
and efficient resolution to mitigate impact to the business and future
risk of similar incidents.
Policy statement: To mitigate the risk and effects of a malfunction,
priority must be given to critical system segments and proper
capacity allocated to those segments by ensuring that key network
components are capable of being replaced within the specified
recovery time objectives.

2 ISACA JOURNAL VOLUME ONE 2009

to encompass the aspects of the enterprise program while
not defining rules that would be out of scope. For example,
the wireless access control in the NSPM states:
Documentation must be maintained for wireless
connections. It must include the configuration
of wireless hardware to maintain point-to-point
hardware encryption of a minimum strength.
Defining a 128-bit encryption standard, for example, is
beyond the scope of the NSPM. This policy statement would
belong within an acceptable encryption policy.
Conclusion
Writing security policies is challenging. It requires the
coordination of resources and cooperation of employees
throughout the company. However, policy writing is an
indispensable skill, because, when a policy is established, it
must undergo reviews and updates (most often annually).
Maintenance of the security policy is equally important for
daily business activities and defense against internal and
external malicious threats. The security of personnel data and
customers personally identifiable information is imperative to
the business. Securing credit card data, medical information
or (in the US) a Social Security number, for example, is the
basis of the NSPM. It is the heart of an enterprise information
security program.
Endnotes
1
Simon, Mark; An Enterprise Security Policy Management
Framework Part 1 & 2, ISSA Journal, February 2008,
www.issa.org/Members/Journals-Archive/2008.html. SANS
Institute, Building a Security Policy Framework for a
Large, Multi-national Company, January 2005,
www.giac.org/certified_professionals/practicals/gsec/4276.php.
Gartenberg, Marc; How to Develop an Enterprise Security
Policy, ComputerWorld, January 2005, www.computerworld.
com/securitytopics/security/story/0,10801, 98896,00.html.
Ungerman, Mark; Creating and Enforcing an Effective
Information Security Policy, Information Systems Control
Journal, ISACA, vol. 6, 2005
2
SANS Institute, Security Policy Project,
www.sans.org/resources/policies
3
The Network Security Policy Manual is an original,
copyrighted creation of the author (Paul Meynen). To obtain
a copy of the NSPM, please e-mail MeynenP@gmail.com.
4
Information Security Forum, The Standard of Good Practice,
https://www.isfsecuritystandard.com/SOGP07/index.htm
5
International Organization for Standardization,
ISO 17799:2005, Information TechnologySecurity
TechniquesCode of Practice for Information Security
Management, 2005, www.iso.org
6
A copy of ISO 17799:2005 was not obtained by the author
until the end of the course in which he developed the NSPM.
Consequently, there was not sufficient time to incorporate all
the additional policy statements recommended in
ISO 17799:2005. However, ISO 17799:2005 presents
an incredible level of detail and is a robust standard to
implement a security program. As the NSPM evolves, the
implementation guidance (explained later) in the ISO
standard will be leveraged to incorporate new statements
into the NSPM.
Authors Note
The author would like to thank James Krev for his patience
and guidance in support of this research at DePaul University,
as well as Jacob Furst and Linda Allen for their meticulous
editing of the work.

The ISACA Journal is published by ISACA. Membership in the association, a voluntary organization serving ITgovernance professionals, entitles one to receive an annual subscription
to the Information Systems Control Journal.

Opinions expressed in the ISACA Journal represent the views of the authors and advertisers. They may differ from policies and official statements of ISACA and/or the IT Governance
Institute and their committees, and from opinions endorsed by authors employers, or the editors of this Journal. ISACA Journal does not attest to the originality of authors content.

2009 ISACA. All rights reserved.

Instructors are permitted to photocopy isolated articles for noncommercial classroom use without fee. For other copying, reprint or republication, permission must be obtained in
writing from the association. Where necessary, permission is granted by the copyright owners for those registered with the Copyright Clearance Center (CCC), 27 Congress St.,
Salem, Mass. 01970, to photocopy articles owned by ISACA, for a flat fee of US $2.50 per article plus 25 per page. Send payment to the CCC stating the ISSN (1526-7407), date,
volume, and first and last page number of each article. Copying for other than personal use or internal reference, or of articles or columns not owned by the association without
express permission of the association or the copyright owner is expressly prohibited.

www.isaca.org

ISACA JOURNAL VOLUME 1, 2009 0