security policy development, security policy management
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 organizations 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.
Technical Controls and Settings
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 in Office 365 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 Information 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 Information 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.
- Manager notifies HR and IT of Termination
- HR schedules exist interview and contacts Physical Security for badge disabling.
- IT suspends User ID and system access
- 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. (A number of pre-written information security procedures are part of the ComplianceShield Content Library) 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, NIST-CSF, PCI-DSS, ISO 27002 and CMMC. 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) as part of our compliance content. This links policy content directly with internal controls.
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.
