Components of a Security Policy
Policies form the basic framework of a security program. At the program level, policies represent senior management's security objectives. At the system level, they provide rules for the construction and operation of specific systems. Whether program or system specific, policies help prevent inconsistencies by forming the basis for detailed standards, guidelines, and procedures. They also serve as tools to inform employees about appropriate activities and restrictions required for regulatory compliance. Finally, policies make clear management's expectations of employee involvement in protecting information assets.
When building a policy, make sure it's clear and flexible. It shouldn't provide so much detail that it forces unreasonable constraints on operational areas of your business. Leave room to make management decisions that fit particular challenges as they arise.
Program policies establish the security program. They provide its form and character. The sections that make up a program policy include purpose, scope, responsibilities, and compliance. Following are the basic components of a security policy:
Purpose includes the objectives of the program, such as:
- Improved recovery times
- Reduced costs or downtime due to loss of data
- Reduction in errors for both system changes and operational activities
- Regulatory compliance
- Management of overall confidentiality, integrity, and availability
Scope provides guidance on whom and what are covered by the policy. Coverage may include:
- Lines of business
- Employees or departments
Responsibilities for the implementation and management of the policy are assigned in this section. Organizational units or individuals are potential assignment candidates.
Compliance provides for the policy's enforcement. Describe oversight activities and disciplinary considerations clearly. But the contents of this section are meaningless unless an effective awareness program is in place.
System specific policies provide the framework for system and issue specific security programs. Like program policies, system policies should be flexible enough to allow managers to make effective operational decisions while safeguarding the confidentiality, integrity, and availability of information assets. System policies typically address two areas: security objectives and operational security standards.
Policies that describe security objectives clearly define measurable, achievable goals. These goals focus on data owner directives intended to protect specific systems. The policies are written to take into account the system's functional requirements as seen by business users. Because policies apply constraints on how a system or a technology may be deployed and used, there's always a danger that meeting security objectives may adversely impact operational efficiency. It's important to balance reduction in risk with the cost associated with potential losses in productivity.
Operational security standards provide a clear set of rules for operating and managing a system or a technology. As with system policy objectives, these rules shouldn't be so restrictive that they paralyze your organization. In addition, the administrative burden associated with managing and enforcing overly restrictive policies may cost your organization more than the business impact you're trying to protect against. The elements of a system/issue specific policy include purpose, objectives, scope, roles and responsibilities, compliance, and policy owner and contact information.
Purpose defines the challenge management is addressing. Challenges might include regulatory constraints, protection of highly sensitive data, or the safe use of certain technologies. In some cases, it may be necessary to define terms. It's important that everyone affected by the policy clearly understands its content. Finally, clearly state the conditions under which the policy is applicable.
Objectives may include actions and configurations prohibited or controlled. Although they're normally defined outside a policy, circumstances and organizational practices may require placing certain standards and guidelines in this section. In any case, it's in this section that you define the results you expect from policy enforcement.
Scope specifies where, when, how, and to whom the policy applies.
Roles and Responsibilities identify the business units or individuals responsible for the various areas of implementation and enforcement of the policy.
Compliance is just as important in a system or issue level policy as it is in a program policy. You should clearly state the possible consequences of not conforming to the standards and guidelines listed in Objectives.
Policy Owner and Contact Information lists the person who is ultimately responsible for managing the policy. Since the data owner is responsible for defining the protection required for a specific system, she may be a good choice for policy owner. Ensure that contact information for the policy owner is kept up to date. This allows individuals responsible for implementing systems under the policy to contact the policy owner for clarification on standards and guidelines.
The final step in the construction of a policy is approval by senior management. Without their approval and support, a policy isn't worth very much. One way to ensure management support is to involve relevant areas of the business in the construction of each policy. This helps prevent the perception that information security policies, and information security in general, are an IS problem. It also nurtures a feeling of ownership across the organization. Managers are more willing to support operational restrictions that result in clear business value they helped define.
Although you can start with a blank sheet, I recommend you look at some example policies. A good place to start is the SANS Security Policy Project page .