shopping cartShop
Call Us: 888 641 0500


A Security Policy Framework for IT Risk Assessments

The completion of an information security risk assessment is a key requirement in all information security frameworks, including ISO 27002, NIST 800:53, HIPAA and PCI-DSS.  A recent analysis of regulatory enforcement under HIPAA identifies risk assessment as a key area of weakness.

While risk assessments are required, the specifics for how to perform a risk assessment are purposefully vague in many regulations.   There are both qualitative and quantitative methods.  There are many different types of IT risk and threat models.  The only widely accepted standard – NIST 800-30 Guide for Conducting Risk Assessments – can be very complicated and not practical for many small and medium-sized businesses.

Regardless of how the risk assessment is performed, there are some key areas where the IT risk management processes intersect with information security controls and thus written security policies.  In this article we discuss a few of those key control points and how your risk assessment policies can best support your information security program.

Risk Management Controls

There is a subtle but clear distinction between the term “risk management” and “risk assessment.”  We view a risk assessment as a specific exercise that is undertaken at a point in time.  (For example, a single organization-wide risk assessment that identifies key systems and the threats to those systems.)   We use the term “risk management” to describe the ways in which specific risk assessments are integrated with the ongoing process of identifying and managing risks.

Risk Management Roles and Responsibilities

Your written information security policies should clearly define the requirements for defining roles and responsibilities for risk management.  These can include such groups as a Risk Management Steering Committee or individual such as an IT Risk Specialist that has specific training in identifying vulnerabilities on specific IT systems.

Information Technology Risk Framework

One of the keys for successful IT risk management is to coordinate the activities with the rest of the organization’s risk-management program.   For example, publicly traded companies are often performing operational risk management for Sarbanes-Oxley compliance.

If other parts of the organization are working on risk management, the Information Security Risk Management program should try to align with this process as much as possible.The integration points can be very simple, such as picking a risk measurement methodology or using a similar risk and control taxonomy.

Risk Assessment Controls

Identifying Critical Assets

Within the risk assessment process itself, many regulations specifically require that the organization consider all threats and vulnerabilities that may impact the organization.  To do this, the organization must first understand the different types of information and technology assets by completing an IT Asset Inventory.

Sample Policy: IT Asset Inventory – The Information Systems Department must prepare an annual inventory of production information systems detailing all existing production hardware, software, and communications links.

Establishing Information Security Controls

Since an IT risk assessments can be long and complex, it is easy to lose sight of its true purpose – to establish an internal control baseline that mitigates risk.  The reason this is so important is that it is these very controls that must be documented within your written information security policies.

Within the scope of risk management, information security controls are designed to either reduce the “likelihood” of a threat event happening or reduce the “impact” of an event.

Risk Assessment Scope

Another key policy element is the scope of risk assessments.  Written information security policies should define both the types and scope of risk assessments that will be performed.   For simplicity sake, there are two common levels of risk assessments – organization and system specific.  Most organizations will need to complete at least a single Organization Wide Risk Assessment on an annual basis.   If the organization is very large, the environment might be separated into different risk domains – say by organizational unit.  For example:

Sample Policy:  Business Unit Risk Assessment – Each critical organizational or business unit within Company X that manages its own computers or networks must also perform, at least annually, a security-related risk analysis of these same systems, coordinated through the Information Security Department, and then certify that adequate security measures have been implemented to mitigate the risks.

Risk Reporting Controls

To have an effective risk governance process, the results of IT risk assessments should be communicated to senior management or any other stakeholders with are responsibility for risk management.

Sample Policy:  Annual Information Technology Risk Report – IT management must submit to the Board of Directors a special annual report. This report is to include a description of all material Company X information technology-related risks, as well as an assessment of how these risks are currently being managed.

Risk Treatment Controls

As part of risk management, the organization must consider how to treat risks that are identified and not properly mitigated by IT controls.   Typically this process involved the following options:  (1) Accept Risk, (2) Defer, (3) Mitigate or (4) Insure.

Whatever the outcome, the important control point is that the organization makes a formal decision regarding risks.   This is another option for demonstrating due-diligence that is often overlooked.   Even if the risk assessment is not perfect (which they are not almost by definition), the organization can strive for excellence is performing the steps necessary to achieve a reasonable result.

Sample Policy:  Material Information Security Risks – For every material\significant information systems security risk identified management must make a specific decision about the degree to which Company X will be self-insured and accept the risk, seek external insurance, or adjust controls to reduce expected losses to an acceptable cost of conducting business.

Cyber Insurance Coverage

In many organizations, the link between business insurance and information security risk management does not exist.  However, the dramatic increase in data breaches has driven a corresponding growth in “cyber” insurance policies.  The market for specific cyber insurance policies is still new and evolving rapidly.  In theory, however, insurance coverage should be designed to cover risks that are not properly mitigated within the existing security program.  This link can be express in written policy as follows:

Sample Policy:  BCP and Insurance – Company X will maintain insurance commensurate with those residual risks identified from a corporate BIA which pose potential for financial loss or other disastrous consequences, as well as the expenses related to recovering from a disaster. 

Policies such as this one help to create awareness that there are many facets and types of losses to a potential disaster that must be considered when scoping and pricing insurance coverage.


While the types and scope of risk assessment can vary dramatically, an organization can still adopt a very structured approach to management the risk assessment process, especially within written security policies.   These various control points are also listed within the Information Shield Common Policy Library (CPL) and specifically within our Sample IT Risk Assessment Policy.


Security Policies, Standards and Procedures: What’s the Difference?

One of the key challenges to developing effective information security policies is agreeing on a proper nomenclature.   Even before writing the first line of a security policy, many organizations get dragged into lengthy discussions regarding the definitions and nuances of these three key elements:  Information security policies, standards and procedures.   In this article we will provide a structure and set of definitions that organization can adopt to move forward with policy development process.

The Hierarchy of Security Policies, Standards and Procedures

In our model, information security documents follow a hierarchy as shown in Figure 1 with information security policies sitting at the top.

Figure 1:  Security Document Hierarchy

Information Security Policies are high-level business rules that the organization agrees to follow that reduce risk and protect information. They define “what” the organization is going to do and often “who” is going to do it.

Information Security Standards provide more specific details that enable  policies to be implemented within the organization using different technologies.  For example, an Information Disposal Standard would define how various type of media are destroyed to implement a policy.

Information Security Procedures are step-by-step instructions that people will follow to implement policies (or even standards.)  Procedures provide the “how” – where an information security control is translated into a business process.

These are in a true hierarchy because “standards” and “procedures” provide the extra level of detail sometimes required to make a policy enforceable across a variety of departments and technical environments.

In our discussion we also introduce the concept of a Technical Control.

Technical Controls are settings or features of information security technologies that automatically enforce policies and standards.   An example would be a setting on a Windows Server that enforces password resets every 90 days.  These technical controls are often referred to by vendors as “policy” – further adding to the confusion.  But for our discussion, anything that involves a machine or software setting is a “technical control.”

Policies, Standards, Procedures:  Examples and Details

While the above definitions are not perfect, they are designed to illustrate the key differences between these elements.  Let’s look at a specific example.

Characteristics of Information Security Policies

Information Security Policies have some important characteristics.  First, Information security policies are not supposed to be optional, so they should include specific words such as “must” to define behaviors or technical implementations.   Many organizations make the mistake of using vague language in policy statements.  “Users should consider security when accessing the internet.”

Second, information security policies should not refer to any specific technical platform.  Policies are not settings on machines, but high-level rules that may ultimately be implemented on technologies.  Third, policies can be viewed as  “contract” between the organization and it’s stakeholders who are concerned with information security:  Management, Employees, Customers, Regulators and Auditors.

Perhaps most importantly, an information security policy should describe an information security control in that can be enforced and measured.  In cases where policies do not provide this level of detail, they can then refer to standards that DO provide this level of detail.  When would we want to put details in standards instead of policies?  Let’s look at a common example relating to systems.

Policy Example:   “Company X must change all default passwords and account settings on IT systems before they are placed into production.”

In this example, a “Configuration Baseline Standard” for various types of operating systems, firewalls, databases, etc. would provide enough detail so that this policy can be implemented on all of the various technologies now in use in most organizations.  This would enable to the organization to create a single policy that can be enforces across the entire enterprise.

Standard Example:  “Company X Baseline Configuration Standard for Windows Servers”

Characteristics of Security Standards

In our model, information security standards provide the necessary level of detail to make a security policy practical across the entire organization.  This concept is most useful when an organization wants to to address a wide variety of technical systems.  A Minimum Baseline Standard can provide the detail required so that passwords, account settings, security settings and log settings all support written policies.

The important idea is this:  Whether you call it a “policy” or a “standard” is not as important as the requirement that the statements translated into meaningful controls that can be enforced and measured.

Characteristics of Security Procedures

Information security procedures are step-by-step instructions that people within the organization must follow to implement an information security control.  One good example is the “Employee Termination Procedure” that is often called for within various regulatory frameworks.  In this case the procedure would outline a set of steps that would effectively remove physical and logical access rights.

  1. Manager notifies HR and IT of Termination
  2. HR schedules exist interview and contacts Physical Security for badge disabling.
  3. IT suspends User ID and system access
  4. Manager and HR collect company property.

Procedures are generally required when a security control must be enforced by people as well as technology.  Within this definition lies an important fact:  Procedures translate into business processes that must be implemented by people according to their job roles.

Change Control Procedures, System Patching Procedures, Incident Response Procedures and System Recovery Procedures are all common examples of security controls that translated into business processes.  One of most common problems we observe with IT-GRC implementations is that policies, standards and procedures are not defined well enough to translate into a specific business process that can be assigned and tracked.

Information Security Frameworks

It is nearly impossible to discuss information security and data privacy without the concept of regulatory compliance.  Regulatory compliance is now the most common driver for implementing and funding an information security program.

To consider compliance, we must introduce another level within the overall structure of information security that we call Information Security Frameworks.   Information Security Frameworks provide categories of related information security controls that must be implemented to comply with a specific regulation or governance system such as ISO 27001.     Examples of common frameworks include:  NIST SP 800-53, HIPAA, PCI-DSS, ISO 27002:2013 and FFIEC.

An updated version of our hierarchy (Figure 2) would put frameworks at the very top of the pyramid:

Figure 2:  Security Document Hierarchy including Frameworks

For the most part, all Information Security Frameworks require a common set of information security controls.  However, there are dramatic differences in the way each framework describes these common controls.  To solve this problem, we have developed the Common Policy Library (CPL).

When it comes to compliance, here is a critical point:  Information security policies provide the key link between Compliance Frameworks and the information security program of an organization.    The organization should be able to map specific information security policies “upward” in the hierarchy to one or more Frameworks.  This mapping provides the crucial link between governance requirements and the rest of the information security program.

Key Takeaways

The argument of what is a “policy” versus and “standard” or “procedure” has been around for at least 30 years.   They key point for an organization is to pick a set of definitions that work and make sure that everyone in the organization is on the same page.  In our experience, this is best done by providing specific examples of policies, standards and procedures as they apply to the organization.   In this article we have provided a structure that has worked successfully in hundreds of organizations.

The second key point to make sure that your documentation (policies, standards and procedures) document your information security controls to the point where they can be implemented and monitored.   Without these two specific elements, security policies (and thus your program) can never be validated.










Distributing Information Security Policies

To be effective, information security policies need to be read and understood by every member of the organization. This seemingly simple requirement is now becoming a standard practice to reduce risk, comply with regulations and demonstrate due-diligence.  Why is this control so important and how can it be done in practice?

Regulatory Requirements

Every regulatory framework or information security standard has some variation of the following requirement:  “Validate that written information security policies are distributed to every member of the organization.”  (See the table below)

Many organizations are being exposed to information security for the first time via a regulatory requirement.  For example, a company that processes credit cards must comply with PCI-DSS.  A contractor to a Federal agency may be required to adopt FISMA.  In these cases, organizations are presented with an onerous checklist of items they must comply with.  Often, the reasons behind these requirements are vague or difficult to understand.

There are two fundamental reasons why organizations must distribute security policies and track acknowledgement.   The first is that written security policies define “rules of behavior” for the way in which users interact with data and systems.  Given the fact that most data breaches can be traced back to some form of human error – this seems to be a reasonable way to reduce risk.   If employees don’t understand how to use systems securely, it creates a dramatic increase in potential risk.  These “rules of behavior” are most commonly expressed as Acceptable Use Policies.

The second (and perhaps less appreciated) reason is to demonstrate due-diligence regarding information security.  Information security is not a prescriptive science.  In other words, organization are often encourages to adjust their information controls based on “the size and scope of the business” or “the results of a risk assessment.”  Variations of these statements show up in regulations like HIPAA/HiTECH and GLBA.  This essentially implies that organization can add or remove controls based on a risk assessment or other business justification.

This is fine until there is a data breach or other serious incident.  Once an incident happens, the organizations are quickly under scrutiny to determine if they were are fault.  (The issue of culpability and issuing fines is way beyond the scope of this article.  However, there is a consistent pattern.  If organizations are willfully negligent, the penalties and fines increase dramatically.)

Reducing Risk

[In the classic view of risk analysis, information security controls have two primary functions:  To reduce the “likelihood” that an event will happen and reduce the “impact” of an event that does happen.  In that context, requiring users to read policies fits both conditions.   Educating uses should help them reduce mistakes, and performing due-diligence is likely to reduce fines or criminal charges for negligence.]

Demonstrating Due Diligence

Requiring users to read and acknowledge security policies is simply one of the most effective ways to demonstrate due-diligence with regard to information security.   Despite the large and growing army of technical solutions, information security is still a people-oriented business.  And information security policies represent a key control point where security technology meets human behavior.

There have been numerous legal cases in which users were disciplined for not following corporate policy.  However, in those cases some employees argued effectively that they have never seen or understood the policy.

This seems like a reasonable idea.  But for organizations with hundreds or thousands of employees and contractors, this can present a huge challenge.  In fact, the process is not really feasible unless some of technology is used to automate the process.

Policy User Acknowledgement: Key Elements

So now that we understand that this is a good idea, how does an organization go about doing this in practice?  For organizations with hundreds or thousands of employees and contractors, this can present a huge challenge.  Our experience with hundreds of organizations can be distilled into two key requirements.

Security Policy Design

First, make sure that security policies are targeted at the right audience.    Some organizations still make the mistake of “co-mingling” technical and process policies with user-oriented policies.  In other words, most users need to understand Acceptable Use of computer and communication systems.  They to NOT need to know how a firewall is configured or how to document a system change.  Information security policies need to be organized by topic and targeted at the appropriate user groups.

Security Policy Automation

Second, use a policy automation tool to distribute policies to different users groups. In fact, the entire policy distribution process is not really feasible unless some of technology is used to automate the process. Security policy automation or management tools provide the following key functions:

1. Enable a documented workflow for creating, reviewing and approving policy documents;

2. Enable targeting of specific users and groups based on their job functions;

3. Require formal acknowledgement of the written policy document;

4. Provide reports that document progress across the organization.

Every policy management tool must have some variation of these key requirements.   This has now become a required feature in Governance Risk and Compliance (GRC) tools. In 1998, there was only one commercial tool available to help automate policy management.  Today, there are dozens.  Information Shield has chosen to partner with Policy Hub because we believe it has the strongest set of functions available in the market when it comes to “pure” policy management.

Of course, commercial tools are not required.  Organization can develop their own systems using custom code, MS-Sharepoint or even a combination of email with logging software.   In general, though, unless these systems are already in place within the enterprise, it can be difficult to justify development when so many robust commercial tools are now available.


Information Security Policy Requirements of various compliance frameworks

ISO 27002: Section 5.1.1 “A set of policies for information security should be defined, approved by management, published and communicated to employees and relevant external parties.

“These policies should be communicated to employees and relevant external parties in a form that is relevant, accessible and understandable to the intended reader, e.g. in the context of an “information securi y awareness, education and training programme” (see 7.2.2).”

PCI-DSS 3.0:  12.1 Establish, publish, maintain, and disseminate a security policy.

Examination Procedures: 12.1 – Examine the information security policy and verify that the policy is published and disseminated to all relevant personnel (including vendors and business partners).

Gramm-Leach-Bliley Act (GLBA) Title V – Section 501 –  “Each Bank shall implement a comprehensive written information security program [policies] that includes administrative, technical and physical safeguards.”

NIST SP 800-53: AC-1 Control:  The organization: a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles] … An access control policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance;


New Security Policy Map for US CyberSecurity Framework

In February 2014, NIST released version 1.0 of the Framework for Improving Critical Infrastructure Cyber-security.   The frameworks is intended to be a “voluntary” set of standards that can help small and medium sized businesses develop an information security program.   (Part of the problem, of course, is that we don’t need another framework – but a rational and scaled down version of other frameworks such as NIST 800-53 or ISO 27002 that would make sense for small businesses.)  While the framework is currently voluntary, some speculate that it could become a default standard for evaluating smaller businesses and contractors that have a part of the critical infrastructure.

Mapping ISO 27002 to the CyberSecurity Framework

For those organizations that base their information security program on the ISO 27002 information security standard, we have developed a new policy map between the control categories of ISO 27002:2013 and the Cyber Security Framework.  This mapping should help your organization rationalize security controls across these two frameworks.  For existing customers, this mapping also includes references to the sample information security policies found within Information Security Policies Made Easy.

Download the ISO 27002:2013 to Cyber Security Framework Mapping Document.



The ROI of Pre-Written Information Security Policies

Often it is difficult to justify security policy development to management.   In many cases, this is due to a lack of understanding on just how detailed and complex policy writing can be.  “Just go find a template on the internet.”   For those of you who have tried this approach, you quickly discover that there is much more to the process IF you want to create a set of quality, consistent policy documents.

Buy or Build?

For those of you still struggling to justify the purchase of a policy package, download our whitepaper The ROI of Pre-Written Information Security Policies.   In this short paper we present a simple model for estimated the cost of writing information security policies.  Understanding this cost is the best way to computer a “return on investment” of purchasing a quality set of templates such as Information Security Policies Made Easy.

Understanding the Total Cost of Policy Development

But remember, developing information security policies is only one part of the ongoing management process.  To better understand the entire life-cycle costs of developing and maintaining policies, read our whitepaper The Total Cost of Information Security Policy Management.   Using these tools should help you estimate the costs of your policy development project, including using in-house resources versus outside consultants.



New Point-of-Sale Device Security Policy

The piercing lens of information security changes focus quite often.  In recent weeks the security vulnerability lens is focused on point-of-sale (POS) devices.  And there seems to be good reason.  The Target breach, perhaps the largest reporting breach in history, seems to be the result of malicious software inserted into these devices via a network hole and stolen vendor credentials.   As the news of the breach was unfolding, the National Cyber Investigations Joint Task Force (NCIJTF) issued new warnings about sophisticated malware attacks directly targeting POS devices.  While malicious software is a threat, the devices are also prone to physical tampering, prompting a new set of controls within the latest update to PCI-DSS 3.0.

As part of our ongoing updates to our PolicyShield Security Policy Subscription, we have added a new sample information security policy:  Point-of-Sale (POS) Device Security Policy.  This new security policy has controls that help mitigate the risks of malware infection, as well as the risks of physical tampering and theft.  The new sample policy is free to all existing PolicyShield subscribers.


How to Structure Information Security Policies

We talk to customers every day about  security policies.   One of the most common questions we receive is this:  How should we structure our information security policies?  When we dig deeper, we usually find that this is a really a two-part question regarding policy structure.

  1. First, how should we name and organize our documents.
  2. Second, what content or detail should go in each policy document.   These are both great questions and we will address each separately.

Why the Confusion?  HIPAA, PCI, FERC, NIST – Oh My!

Why do people struggle with this basic starting point for developing policies?  In our opinion, this has to do with the various and confusing outlines of different information security frameworks and laws such as ISO 27002, HIPAA,PCI-DSS and NIST.    People who (quite naturally) want to base their security policies on an established standard fall into a trap.  These common frameworks are designed to organization information security requirements, not form an outline for security policies.  For example, the NIST 800-53 outline is heavily biased toward technology.  The first major section of PCI-DSS is devoted almost entirely to managing firewalls.

These common frameworks are designed to organization information security requirements, not form an outline for security policies.

As an example, the first control objective (5.1 Information Security Policy Document) of ISO 27002 requires that an organization have a written security policy.  It does not specify how they will organized or grouped.  If you simply adopt the ISO 27002 outline, you will find it very difficult to place certain items, such as Acceptable Use of Assets, which are targeted at end-users.  The topic of IT Risk Management (which is called out in HIPAA and NIST) is not even part of the 11 domains listed.  The NIST outline specifies that written policies and procedures are required in each of the 17 different domains.   But if you simply adopt the NIST 800-53 outline, you will have challenges addressing common items like Third Party Security or Internet Acceptable Use.

The Common Policy Approach

We recommend a simple approach that is based on subject matter and target audience.  We use this approach in our Common Policy Library (CPL).  Using the CPL approach, information security policies are broken into a set of 10-20 policy documents, each covering a specific topic.  These topics are chosen to overlap with the most common requirements of various laws and regulations.  (Notice, we didn’t say ALL of the topics, but most of them.)    Here is a sample list of documents using the CPL outline:

  1. IT Risk Management Policy (Risk Assessment)
  2. Security Program Policy (Policy, Planning, Personnel)
  3. Asset Management Policy (Inventory, Acceptable Use, Protection)
  4. Information Management Policy (Collection, Classification, Storage, Disposal)
  5. Third Party Security Policy (Assessment, Contracts)
  6. Personnel Security Policy (Screening, training, termination)
  7. Access Control Policy (Systems, Accounts, Passwords)
  8. Network Security  Policy  (Firewalls, Structure, Wireless)
  9. Physical Security Policy(Visitors, IT Systems)
  10. Operations Management (Configuration, Change Control, Malware)
  11. Application Security Policy (Development, Testing)
  12. Security Incident Management Policy (Reporting, Response, Investigation)
  13. IT Business Continuity Policy    (backup, Business Continuity)
  14. Security Monitoring Policy (Logging, Audit, Monitoring)
  15. Customer Privacy Policy
  16. Employee Data Privacy Policy

Using this approach, each policy document contains all of the essential controls fora broad security topic (or domain using ISO terminology.)   Each documents contains a set of more specific policies, usually between five and twenty statements per document.   This provides enough detail to mitigate the risks of each category, but does overwhelm the stakeholders with information.  (This is the approach we use with our information security policy library.)

In many cases, these topics align nicely with major categories of the ISO 27002 standard or NIST 800-53.   Just as important is the fact these topics also have a specific target audiences (or “stakeholders”.   For example, a Security Program Policy is generally targeted at management, oversight committees or external auditors.  A Personnel Security Policy is targeted at hiring manager and the Human Resources department.   Having a well-defined set of stakeholders makes each policy easier to review, update, approve and manage.  This point is worth repeating:

Having a well-defined set of stakeholders will make any policy easier to approve and manage.

Avoid  The One-To-Many Policy Approach

Some information security practitioners use what we call the “One to Many Approach”.  In this approach, the organization has a single, overarching policy document with a group of very high-level policy statements.  An example would be, “Company X protects access to all sensitive data”.  These documents then refer to a group of  “standards” documents to provide more detail.  In our experience, this approach simply creates another level of abstraction that does not help get security policies written and approved.

Information Security Policies Versus Standards and Procedures

Another key to this approach is to make sure that these documents contain only “policy” statements.  In other words, these documents describe very specific rules for what behavior and processes and technologies will be implemented within the organization.   But they don’t specify how they will be implemented.  For example, the Incident Management Policy can (and should) require that the organization develop specific incident response procedures.  But these procedures should be in separate documents that refer back to the policy they are designed to support.  (Procedures support and implement policies.)  As another example, a baseline standard for an operating system can list the specific settings for parameters, accounts, and services.  But these details should never be part of a security policy.  Standards can be updated as frequently as needed.

Off the Shelf and Into Action

One of the great advantages of organizing security policies by topic and stakeholders (organizational roles) comes during implementation.   For example, most information security regulations specify that personnel should be training on the policies that apply to them.   When an organization mixes technical management and personnel policies in a single document, this becomes very difficult.   When you limit each document to a limited set of policy statements, and then limit those to a specific audience, the process is very simple.  Using this approach makes it very simple to use automated policy management tools.

Summary: Effective Security Policy Structure

In summary, break your security policy development into a series of policy documents covering various topics.   Anywhere from 10 to 30 documents is common, depending on the size and scope of the organization.   Within each document, have a group of specific security policy statements (from 5 to 25 is common.)   Try to break up the topics to match the requirements of your business as well as the target audience.  This approach not only makes it easy for your organization to demonstrate compliance with a specific law, but it will dramatically reduce the effort required to manage each policy.








Information Security Policies for PCI-DSS V3

The PCI Security Standards Council just released Version 3.0 of the Payment Card Industry Data Security Standard (PCI-DSS), the set of requirements for protecting credit card data.  The update had some significant changes, including a greater focus on third-party information security.

There are many articles describing the new changes to PCI-DSS V3, including a nice summary of changes from the Council, so we won’t duplicate that effort here.  For our purposes, we wanted to look at the implications for information security policy development, so we will focus our analysis on Requirement 12:  Maintain and Information Security Policy.

Requirement 12 – A misnomer

First, Requirement 12 “Maintain an Information Security Policy” is essentially misnamed.  While it does outline the specific requirements of written information security policies (12.1), it should really be named “Maintain an Information Security Program” – since it covers all of the organizational aspects of information security, including risk assessments, personnel security, and third-party security.  Unfortunately, this name carried forward to the new update.

This confusing name just adds to the overall global confusion regarding security compliance and security policy.  Customers met with these requirement go looking for a single “information security policy” – when in fact what they need is a SET of information security policies and procedures that document their information security program.

PCI-DSS Information Security Policy Requirements

PCI has always been a strange standard compared with other outlines like ISO 27002 or NIST.  While the PCI recommendations go into specific detail in areas like firewall management and configuration (what we might refer to as a “standard” or even technical configurations), requirement 12 makes much higher-level statements about security policy.

12.1 Changes – Security Policies Moved

One of the key PCI-DSS requirements is that the organization have written security policies and procedures that cover each of the security categories.   But now they say it a bit differently.

One of the major changes in the outline was to take the previous requirement (12.1) to have written policies and procedures and spread it out into the various topic sections.  So rather than saying you must “have policies and procedures that cover the PCI-DSS topics” it simply adds that requirement at the end of each section (physical security, access control, etc.)  This is more in line with the NIST SP 800-53 approach.  But it adds little in the way of guidance or clarity.   This approach also seems to leave out the requirements to document the previous 11 categories of the standard, which is clearly not the case.

PCI-DSS Information Security Policies in 4 Steps

So what DOES PCI-DSS V3 really say about Information Security Policy?   Let us try to summarize in four basic steps:

1. Written security policies should document the overall structure of your information security program, (as such, written information security policies are key pieces of evidence for auditors and assessors seeking to validate your program)

2. You must have written information security policies and procedures that cover all of the control categories of your security program.  (Access control, physical security, personnel security, incident response, etc.) (12.1)

3. Like your program, information security policies must be reviewed and updated to reflect changes in your program and security environment, (12.2)

4. Your written policies should be distributed to the key personnel that need to follow them. (12.1)

Not surprisingly, this is what ISO 27002 says about written policies (5.1) and HIPAA says about information security policy.  Did we need another standard with another numbering system?  We’ll let you be the judge of that.

The bottom line is that these are the core components of any effective information security policy program.  If your organization adopts these best practices, then addressing the specific requirements of different regulations will basically fall into place.

About Information Shield

Information Shield publishes the leading library of information security policy templates, including Information Security Policies Made Easy.   Our products allow organizations to quickly document their information security program for compliance with regulations and frameworks including PCI-DSS, HIPAA, NIST, ISO 27002 and CoBIT.



ISO 27002:2013 Change Summary Heatmap

The British Standards Institute (BSI)  recently released an updated version of ISO/IEC 27002 – Code of Practice for Information Security Controls.  This was the first major update since the 2005 release.  Many organizations are interested in how the changes will impact their information security program.

What Really Changed?

In our review, very little in the way of information security substance was changed in this version.  While several controls were added and several more removed, the update is largely an exercise in moving and renumbering.  The essential “key” controls are still required – they have just been moved to a different location.

Some of the key moves seem justified – like consolidating all third-party security controls into one domain.   (Understanding the rationale for renaming the domain “Supplier Relationships” from ‘Third-Party” is more difficult.)  While some sections such as 5.0 Information Security Policy remained unchanged, several areas such as Operational Security had major changes.

The ISO 27002:2013 Change Heat Map

In our efforts to decipher the changes between ISO 27002:2005 and 2013, we found it very difficult to wade through the vast numbering changes.  In order to help our clients manage this information, we created a change “heat map”.  In short, the map uses color coding to try to indicate areas of large change (red) versus areas that remained similar (green).

The heat map aligns both of the versions (like this sample image) to try to visualize what was maintained, added and removed between versions.

So what does this mean for Information Security Policies?

Most organizations will change little with this update -  unless they included specific ISO 27002 references in written policy documents.  In that case, they will have to change a large number of references.  (Which it might make sense to remove for future versions!)

The core requirements to develop, maintain and distribute written information security policies are still key to the standard.   (As they are with every information security regulation.)   The work will be in deciding how and when to address  the new control objectives, and then include those within your written information security policies.  In future releases of  our PolicyShield Security Policy Subscription and Information Security Policies Made Easy, we will include any needed sample policies to fill in the gaps.

 Get the ISO 27002 Change Summary Heat Map here.





Information Security Policies According to NIST

Five Best Practices from NIST 800-53

In April 2013, NIST made the final updates to their complete catalog of information security requirements, Special Publication 800-53 Revision 4 – Security and Privacy Controls for Federal Information Systems and Organizations.  The catalog is BIG – it contains hundreds of information security and data privacy requirements organized into 17 different topic categories.  Each category is called a “family”, and covers a key information security topic such as access control (AC), incident response (IR) or physical security (PE).

For people not familiar with FISMA or NIST, this document is essentially the security “encyclopedia” for how to protect systems and organizations.  As such, even organizations that are not required to comply with federal information security laws still reference the NIST standards for guidance on all things security.

So what does NIST SP 800-53 say about written information security policies?  In this article we take a slice through the outline and pull out the requirements as they relate to information security policies.  For this article, we will use the NIST family Access Control (AC) as a working example.  The result is a list of five key principles of information security policies according to NIST:

1: Written information security policies and procedures are essential

The first control in every domain is a requirement to have written information security policies.  The specific requirement says:

The organization Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]: (1) An access control policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance;

Notice the term “documents”.  This implies that policies need to be written down.  While this seems obvious, many organization still fall short in documenting their specific security policies.  (This is often sites as the greatest deficiency when audits are conducted for HIPAA/HiTECH by the OCR.)  The second part calls for written procedures to support the policy:

(2)    Procedures to facilitate the implementation of the access control policy and associated access controls; and

Each of the 17 other control categories (or families) follows the same format, with the first requirement always calling for written for policies and procedures.  What this also implies is that the policy document for each section covers the key controls required for that domain.   For example, within Access Control (AC), your Access Control Security Policies could cover:  Account management (AC-2), access enforcement (AC-3), information flow enforcement (AC-4), separation of duties (AC-5) and so on.  While NIST also specified a minimum set of these controls, the typical organization may choose a smaller subset.  But the structure can remain the same – one or more policy statements for each topic.

2: Security policy documents must have a defined structure

NIST SP 800-53 also goes into detail about what needs to be covered within the security policies.  The requirement for an Access Control Policy specifies that the organization develop:

(1)    An access control policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance;

For example, each document should cover the “scope” of the organization or systems that the policy applies to.  It should also include references to specific organizational roles required to take action as part of the policy.  To address these requirements, each policy and procedure document should have a standard format with sections addressing each of these required areas.  A standard format not only speeds up the review and update cycle, it helps the written information security policies integrated with other standard corporate policies.   A similar standard format is built into each of the 30 sample policy documents included within Information Security Policies Made Easy.

3:  Security policies must be periodically updated

The NIST guidance is once again very specific about this requirement.  Written information security policies and procedures need to updates to reflect the latest changes in the organization.

The organization: (b) Reviews and updates the current: (1) Access control policy [Assignment: organization-defined frequency]; and (2) Access control procedures [Assignment: organization-defined frequency].

Notice that the requirement allows the organization to set a specific time-period or frequency for updates.  A common time period is annually for information security policies.  Information security procedures can be updated at the same period or triggered as part of a policy update.  For example, the organization may update the Employment Termination Procedure to reflect new requirements, but the Personnel Security Policy that requires this procedure can remain unchanged.

4: Security policies must be distributed to the organization

Information security policies and procedures are not effective unless the drive organizational behavior.  To do this, policy and procedure documents need to be distributed to the users in the organization so they can be read and understood.

The organization Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]:

Some other implied requirements come from the need to “disseminate.”  First, organizations should target specific policies to user groups and roles within the organization.  For example, all users do not need to be aware of the contents of the Network Security Policy, while all users should know how to safely use the internet and email.   Another implied requirement is that these documents are understood.  The organization should perform due-diligence in educating users on the security requirements of their jobs, including the information security policies and procedures that apply to them.

5: Security policies must be managed with a defined process

The previous four elements lead up to this key requirement:  Organizations must establish a formal management process for information security documents.  This requires that the organization treat information security policy documentation as an ongoing project, not a one-time event.   This implies several other requirements, such as assigning ownership to each policy document and to the entire policy management process.  How can an organization possibly manage the specific security policy elements – including reviewing, management commitment, coordination and compliance – without a management process?  Sadly, this is where many organizations fail.  The development of information security policies is delegating to a single individual as a part-time project with minimum visibility into management, rather than being treated as a project that requires funding and resources.  While this approach may get the organization by, it usually fails after the first major audit.  As always, up-to-date information security policies are key pieces of evidence to support due-diligence.


While your organization may not be required to comply with FISMA, the NIST family of publications can provide excellent guidance on developing and managing an information security program.  When it comes to written information security policies, the message is clear:  Security and privacy policies need to be living documents.


Example:  The full catalog listing for AC-1 within NIST SP 800-53.


Control:  The organization:

a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]:

  1. An access control policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and
  2. Procedures to facilitate the implementation of the access control policy and associated access controls; and

b. Reviews and updates the current:

  1. Access control policy [Assignment: organization-defined frequency]; and
  2. Access control procedures [Assignment: organization-defined frequency].

Supplemental Guidance:  This control addresses the establishment of policy and procedures for the effective implementation of selected security controls and control enhancements in the AC family. Policy and procedures reflect applicable federal laws, Executive Orders, directives, regulations, policies, standards, and guidance. Security program policies and procedures at the organization level may make the need for system-specific policies and procedures unnecessary. The policy can be included as part of the general information security policy for organizations or conversely, can be represented by multiple policies reflecting the complex nature of certain organizations. The procedures can be established for the security program in general and for particular information systems, if needed. The organizational risk management strategy is a key factor in establishing policy and procedures. Related control: PM-9.

Control Enhancements:  None.

References:  NIST Special Publications 800-12, 800-100.

Priority and Baseline Allocation:

P1 LOW   AC-1 MOD   AC-1

Older posts «