No circumstances should allow for operational deviation from security policies

Information Security Policies (ISP)  is a set of rules enacted by an organization to ensure that all users or networks of the IT structure within the organization’s domain abide by the prescriptions regarding the security of data stored digitally within the boundaries the organization stretches its authority. An ISP is governing the protection of information, which is one of the many assets a corporation needs to protect.  Putting to work the logical arguments of rationalization, one could say that a policy can be as broad as the creators want it to be: Basically, everything from A to Z in terms of IT security, and even more. Characteristics of good security policies include conciseness, readability, actionability, enforceability, and flexibility. Policies are short and to the point in conveying principles that guide activity within the organization. Policies contain a minimum of specialized vernacular and acronyms; clearly explain any industry-specific terms. Employees at all levels will read the security policies to discern how they should act in the best interest of the organization; therefore, the policy should be actionable at every level of executive strategic planning, management of operations, and actual performance of tasks. The policy must allow for determination of compliance with the policy and enforcement of noncompliance. Moreover, policies should potentially apply to the organization for years and not become outdated with the end of life of any product supporting the policy. Any mention of specific product use is in a standard, not a policy. Explanations on how to use products are in procedures, not in policy.

Review your information security policies on a regular basis, with no more than 12 months from the last review. Define trigger events for a policy review. The first trigger event is the last review plus 12 months. Other trigger events may include a change in the business environment, like a merger, acquisition, or new business venture. Certainly, new legislation or regulatory reform will prompt policy review. Include a statement of review/revision trigger events in the information security policy. A key question is why capture all this detail in written documentation. Just like a contract, written documentation ensures a meeting of the minds. The organization is working off a common understanding of the expectations (e.g., the SMF interpretation guide) and a common understanding of terms (e.g., organization-specific security glossary or risk management glossary). Moreover, the key point is for the organization to capture the policy, standards, procedures, interpretations, and definitions that ensure these details are not just in the minds of a few individuals. It is possible to have excellent security practices in organizations that do not have a single written procedure. Although the practice is good, it is only as good and as enduring as the individual that practices it. The loss of that individual through retirement, resignation, or being hit by the proverbial bus implies a loss (or at least a degradation) of that excellent practice to the organization. Documentation captures knowledge and promotes the learning organization, where proven good practice by one becomes good practice available to all.

Out of carelessness mostly, many organizations without giving much thought choose to download IT policy samples from a website and copy/paste this ready-made material in an attempt to readjust somehow their objectives and policy goals to a mold that is usually crude and has to broad-spectrum protection. Understandably, if the fit is not quite right, the dress would eventually slip off. A high-grade ISP can make the difference between a growing business and a successful one. Improved efficiency, increased productivity, clarity of the objectives each entity has, understanding what IT and data should be secured and why identifying the type and levels of security required, and defining the applicable information security best practices are enough reasons to back up this statement. To put a period to this topic in simple terms, let’s say that if you want to lead a prosperous company in today’s digital era, you certainly need to have a good information security policy. The initial process in developing an information security policy is to identify which laws, regulations, and information security drivers are applicable to your organization.

1. Perform a high-level gap analysis of each regulatory requirement and driver that is applicable to determine where policy is needed.
2. Develop a prioritized action plan that will help you organize your efforts.
3. Prepare a summary document of the impact that the information security policy or policies will have on the organization. The document should:
   1. Describe the policy
   2. Communicate the reason or business justification for the policy, as well as the risks and negative impact of not implementing the policy
   3. Identify regulatory, technical, cultural, and organizational dependencies for implementation of the policy
   4. Identify milestones and possible roadblocks of implementation, compliance, and enforcement
   5. Identify impacted stakeholders
4. Develop the policy in collaboration with other key stakeholders at your organization.
5. Ensure the policy is vetted by impacted subject matter experts and business owners, including information security, legal counsel, human resources, and any other applicable steering committees.
6. Review resources such as the standards and regulations that address specific requirements (e.g., PCI DSS 3.0, HIPAA, GLBA).
7. Publish, communicate, train, and implement.

A. 5.1.1 Policies for information security

Control

Information security policy and topic-specific policies should be defined, approved by management, published, communicated to and acknowledged by relevant personnel and relevant interested parties, and reviewed at planned intervals and if significant changes occur.

Purpose

To ensure continuing suitability, adequacy, effectiveness of management direction and support for information security in accordance with business, legal, statutory, regulatory and contractual requirements.

ISO 27002 Guidelines

At the highest level, the organization should define an “information security policy” which is approved by top management and which sets out the organization’s approach to managing its information security. The information security policy should take into consideration requirements derived from:

1. business strategy and requirements;
2. regulations, legislation and contracts;
3. the current and projected information security risks and threats.

The information security policy should contain statements concerning:

1. definition of information security;
2. information security objectives or the framework for setting information security objectives;
3. principles to guide all activities relating to information security;
4. commitment to satisfy applicable requirements related to information security;
5. commitment to continual improvement of the information security management system;
6. assignment of responsibilities for information security management to defined roles;
7. procedures for handling exemptions and exceptions.

Top management should approve any changes to the information security policy.

At a lower level, the information security policy should be supported by topic-specific policies as needed, to further mandate the implementation of information security controls. Topic-specific policies are typically structured to address the needs of certain target groups within an organization or to cover certain security areas. Topic-specific policies should be aligned with and complementary to the information security policy of the organization.
Examples of such topics include:

1. access control;
2. physical and environmental security;
3. asset management;
4. information transfer;
5. secure configuration and handling of user endpoint devices;
6. networking security;
7. information security incident management;
8. backup;
9. cryptography and key management;
10. information classification and handling;
11. management of technical vulnerabilities;
12. secure development.

The responsibility for the development, review and approval of the topic-specific policies should be allocated to relevant personnel based on their appropriate level of authority and technical competency. The review should include assessing opportunities for improvement of the organization’s information security policy and topic-specific policies and managing information security in response to changes to:

1. the organization’s business strategy;
2. the organization’s technical environment;
3. regulations, statutes, legislation and contracts;
4. information security risks;
5. the current and projected information security threat environment;
6. lessons learned from information security events and incidents.

The review of information security policy and topic-specific policies should take the results of management reviews and audits into account. Review and update of other related policies should be considered when one policy is changed to maintain consistency. The information security policy and topic-specific policies should be communicated to relevant personnel and interested parties in a form that is relevant, accessible and understandable to the intended reader. Recipients of the policies should be required to acknowledge they understand and agree to comply with the policies where applicable. The organization can determine the formats and names of these policy documents that meet the organization’s needs. In some organizations, the information security policy and topic-specific policies can be in a single document. The organization can name these topic-specific policies as standards, directives, policies or others.
If the information security policy or any topic-specific policy is distributed outside the organization, care should be taken not to improperly disclose confidential information.

Differences between information security policy and topic-specific policy

Information security policy

Level of detail: General or high-level

Documented and formally approved by: Top Management

Topic-specific policy

Level of detail: Specific and detailed

Documented and formally approved by: Appropriate level of management

Topic-specific policies can vary across organizations.

A Formal Approach to establish policy

The adoption of one or more information security policies is the first step that the organization takes to express its commitment to the protection of their information resources and the information entrusted to them by their and partners. The policy statement should clearly communicate the organization’s beliefs, goals, and objectives for information security.
The information security policy also provides the Organization’s leaders with an opportunity to set a clear plan for information security, describe its role in supporting the missions of the organization, and its commitment to comply with relevant laws and regulations. The policy should be brief, clear to understand, enforceable, and focused on desired behaviors and outcomes, and most importantly, balanced in affording security while enabling and preserving productivity.
An overarching information security policy document is often (though not always) drafted through a consensus-building process with solicitation and feedback from all identified stakeholders. Once approved and published, its effective communication and periodic reviewing and updating ensure that the policy stated intent and corresponding expectations are consistent and relevant over time to reflect changes in technology, laws, business practices, and other factors.
Prior to starting the policy development process, it is important to understand the difference between policies, procedures, guidelines, and standards. Organizational policies are typically broad, short statements that reflect the philosophies, attitudes, or values of an organization related to a specific issue. Procedures are more detailed and generally mandatory, describing how to accomplish a task or reach a goal. Guidelines sometimes referred to as best practices, contain information about how to accomplish a task or reach a specific goal, but may not be mandatory. Standards establish a rule from a recognized authority, with no deviation allowed.

Difference between Policy standard, Guidelines, Procedure, and checklist.

What’s in a name? We frequently hear people use the names “policy”, “standard”, and “guideline” to refer to documents that fall within the policy infrastructure. So that those who participate in this consensus process can communicate effectively, we’ll use the following definitions.

• A policy is typically a document that outlines specific requirements or rules that must be met. In the information/network security realm, policies are usually point-specific, covering a single area. For example, an “Acceptable Use” policy would cover the rules and regulations for appropriate use of the computing facilities. Policies are statements that reflect the philosophies, attitudes, or values of an organization related to a specific issue. They are generally represented in a paragraph or perhaps two but not pages. They might say “what” but not “how”. Checklists, procedures, standards, and guidelines all must implement, reflect, and support the applicable policy or policies. The entire set of statements is sometimes considered to be the “Policy.”
• A standard is typically a collection of system-specific or procedural-specific requirements that must be met by everyone. Standards are statements dictating the state of affairs or action in a particular circumstance. They establish a rule from a recognized authority, with no deviation allowed. For example, you might have a standard that describes how to harden a Windows 8.1 workstation for placement on an external (DMZ) network. People must follow this standard exactly if they wish to install a Windows 8.1 workstation on an external network segment. In addition, a standard can be a technology selection, e.g. Company Name uses Tenable SecurityCenter for continuous monitoring, and supporting policies and procedures define how it is used.
• A guideline is typically a collection of system-specific or procedural-specific “suggestions” for best practice. They are not requirements to be met but are strongly recommended. in other words, they are not mandatory, but a good idea. Effective security policies make frequent references to standards and guidelines that exist within an organization. Guidelines contain information about how to accomplish some task or reach a specific goal.   They may also contain an element of “best practice” — alternate actions might be available and might work, but what is being provided has proven to be the fastest, cheapest, etc. The more explanatory text is usually involved.
• Procedures contain one or more sentences describing how to accomplish a task or reach a goal – i.e., directive statements. The specified actions are generally mandatory for a specific situation. The more explanatory text is usually involved. A sequence is not necessary but sometimes is important.
• Checklists contain one or more statements dictating how to accomplish a task – i.e., “commands”. The items are applicable to immediate circumstances and mandatory in that situation. They are typically immediately at hand and written in simple language with no amplifying text. The sequence is always important. Flowcharts are also used as a method for conveying similar information.

Some organization has developed a “policy on policies” that provide an organizational statement and set of procedures about how policies are formatted, who develops them, and how they get approved. The benefit of a formal approach is that it makes policy development consistent and recognizes policy development and policy approval authorities. The formal approach can contain the following stages: 1) identify issues, 2) conduct analysis, 3) draft language, 4) get approvals, 5) determine distribution/education, 6) solicit evaluation and review, and 7) plan measurement and compliance. Stages 1 and 2 are considered “pre-development”. Stages 3-5 are part of “development”. Stages 6 and 7 are “maintenance”.
First, issue identification contains a proactive component and is designed to build upon a security risk analysis, including the identification of existing information or data security policies. Second, the identification of the policy owner, policy path, and team to develop the policy is critical to ensuring the ultimate success of the security policy. There are mixed views about whether or not to include legal counsel as part of the policy drafting team or whether they should be a part of a subsequent review process to determine the legal sufficiency of policy documents. There is a danger that security policy could become too legalistic or written in terms too complex for users or employees. On the other hand, lawyers should be knowledgeable about security requirements under Federal or state law. Third, drafting language and getting approvals is a strategic and political process at most organizations. Because of the urgency of computer and network security for our organizations, it may be more expedient to issue “guidelines” or “interim policies and procedures” to protect assets and ensure legal compliance while using shared governance processes for formal review and adoption of organizational policy. Fourth, increasing education and awareness of security issues and corresponding policies and procedures is critical. A policy that no one knows about or worse yet a policy that is not followed can do more harm than good. Finally, the maintenance stage underscores the importance of regularly evaluating security policies to ensure that they are effective and evolve as technology changes.

Policy Elements

If the goal of organizational policies is to direct individual behavior and guide organizational decisions, then the effectiveness of formal policy statements will depend upon their readability and usefulness. Many organization suffers from the lack of a common and consistent approach or format to writing organizational policies. The outline below suggests some common elements that should be included in any security policies.

1. Rationale or Purpose. The rationale or purpose statement expresses “why” the policy is being written. The rationale or purpose may also contain or cross-reference “background” materials or more explanatory details regarding legal, regulatory, or other factors that led to the development of the policy.
2. Policy Statement. The policy statement should be a concise statement of “what” the policy is intended to accomplish. The policy should only be a one or two-sentence description of general organization intent with respect to the specific topic of the policy. The policy statement should be general enough to provide some flexibility and accommodation to periodic changes in technology.
3. Scope of Policy. The scope of the policy can set important parameters such as to whom will the policy apply (e.g., faculty, staff, customers, vendors, and guests) and to what (e.g., paper and electronic records, information and computer assets, etc.)
4. Procedures. The procedures will detail “how” the policy statement will be attained. Procedures may include information on how to report computer security incidents. Procedures may also describe enforcement provisions or methods for appeal. Procedures are some times provided in a separate document or left for local determination to provide greater flexibility for updates as well as local control.
5. Roles and Responsibilities. The procedures may contain details about who is responsible for what. The policy should also identify who is responsible for enforcement or compliance and who will provide interpretations in the event of the need for clarification or when there is a dispute.
6. Definitions. Policies should be precise and easy to understand. Some times terms will need to be defined to clarify meaning. However, the policy should attempt to convey messages in simple yet precise terms; excessive definitions may make a policy document unreadable or subject it to greater scrutiny.
7. References. It is possible that there are other policies or organizational documents that complement, supplement, or help explain the provisions contained within the current policy. References to other policies or organizational documents and citations to statutory or regulatory items can improve the usefulness of the policy.

If a policy is a statement of intent (according to most definitions), then a policy for information security can be defined as a formal high-level statement that embodies the course of action adopted by an organization regarding the use and safeguarding of the organizational information resources. The policy statement should clearly communicate the institution’s beliefs, goals, and objectives for information security.
To be effective an information security policy must:

• Require compliance (i.e., it should be mandatory to the intended audience)
• Be implementable (e.g., impact on legacy systems and current infrastructure)
• Be enforceable. (i.e., failure to comply should result in disciplinary actions)
• Be brief and easy to understand
• Balance protection with productivity

Also, the information security policy should:

• State why the policy is needed (i.e., business reasons)
• Exemplify the organization’s commitment to information security
• Express leadership support for the role of information security in the carrying out of the organization’s missions,
• Focus on desired behaviours (e.g., acceptable use) and outcomes
• Define roles and responsibilities
• Outline the standards and procedures to be followed.

A careful balance must be reached to ensure that the policy enhances organizational security by providing enough detail that community members understand their expected role and contribution but not so much detail that the organization is exposed to unnecessary risk.

Policies for Information Security

There are a number of methods that can be used as a foundation for an organization’s information security policy framework.  Choosing the right policy framework is all about what will work best for the organization and its missions. The organization should consider the following when selecting a framework for its information security policy:

• What works for the Organization?
• What has not worked before?
• What fits the organization’s culture?
• What regulatory requirements must be met?
• What are the organizational drivers?
• What future technology is on the organization’s roadmap?
• What resources (staff, budget, skillsets) are needed to obtain the desired outcomes?

It is important to keep in mind that one of the main goals of an information security policy is to issue directives. The difficult part is deciding on the appropriate level of control to exert. The appropriate level should be informed by the following facts:

• If policies are too restrictive or hard to implement, people will find ways to circumvent the controls.
• Technical controls are not always possible or, at times, desirable.
• Ensure that directives are ‘top-down’—i.e., fully supported by top management.

Organizational Drivers

Since most information security practitioners would agree that it is impossible to protect everything the same way all the time, organizations should identify the business and technical drivers that will guide the creation and implementation of the information security policy as well as assist in its vetting, approval, and socialization. These drivers can be high-level statements that convey the organization’s priorities and direction and help stakeholders make the right decisions regarding what standards to require, what technology to deploy, and how to build the architecture required to implement the policy.
The information security CIA triad exemplifies the highest level driver – to preserve the confidentiality, integrity, and availability of organizational information resources. More specific examples include:

• Uniquely identify and authenticate all users and entities affiliated with the organization.
• Provide users with the least access required to perform their job function
• Adopt information security industry standards where appropriate.
• Implement mitigating controls proactively and based on risk and cost of risk mitigation
• Identify what information the organization maintains, where is it located, and who owns is responsible for it
• Classify the organizational data and safeguard it based on risk
• Balance the business needs to offer and deploy new applications and services against the security risks it might pose to the organization

Review of Information Security Policy

Most organizations will have a documented periodic policy review process in place (e.g., annually) to ensure that policies are kept up to date and relevant. In some cases, a policy manager would be the individual who would determine the need for a new policy or the update to an existing policy. In a small organization, the role of policy manager may be played by the Business Owner (e.g., the Chief Information Security Officer may be the owner/manager of the information security policy.)

Policy Review and Update Drivers

The information security policy owner or manager will review and update the policy at the required intervals or when external or internal drivers require the review and update of the policy. The following are the most common drivers that would prompt a review of the institution’s information security policy.

• Changes in Federal or State laws and regulations
• Changes in technology (e.g., increased use of mobile devices on campus)
• Major information security project deployments (e.g., deployment of Mobile device Management (MDM)
• Audit findings
• Policy format changes (e.g., new policy management function and process)
• Increased reliance on third-party service providers (e.g., outsourcing, cloud)
• New business practices (e.g., online education, telecommuting, telemedicine)

Policy Review and Update Process

The process to review and update the information security policy should include the following steps:

1. Document needed changes
2. Make changes to a draft version of the policy
3. Are the changes significant or alter the intent of the original policy?
4. If Yes, ensure the changes are vetted by impacted subject matter experts and business owners, information security, legal counsel, human resources if applicable, any other applicable steering committee
5. Publish, communicate, train, and implement

Example of Information security policy

Information security policyIntroduction[ORGANISATION]’s computer and information systems underpin all [ORGANISATION]’s activities, and are essential to [ENTER MAIN BUSINESS/FUNCTIONAL OBJECTIVES HERE].
The [ORGANISATION] recognizes the need for its members, employees, and visitors to have access to the information they require in order to carry out their work and recognizes the role of information security in enabling this.
Security of information must, therefore, be an integral part of the [ORGANISATION]’s management structure in order to maintain continuity of its business, legal compliance and adhere to the University’s own regulations and policies. Purpose This information security policy defines the framework within which information security will be managed across the [ORGANISATION] and demonstrates management direction and support for information security throughout the [ORGANISATION]. This policy is the primary policy under which all other technical and security related policies reside. [ENTER ANNEX LINK HERE] provides a list of all other policies and procedures that support this policy. ScopeThis policy is applicable to and will be communicated to [EXAMPLE: all staff, customer and other relevant parties including senior and junior members, employees, visitors, and contractors]. It covers but is not limited to, any systems or data attached to the [ORGANISATION]’s computer or telephone networks, any systems supplied by the [ORGANISATION], any communications sent to or from the [ORGANISATION] and any data – which is owned either by the University or the [ORGANISATION] – held on systems external to the [ORGANISATION]’s network. Organisation of information securityThe [HEAD OF DEPARTMENT] is ultimately responsible for the maintenance of this policy and for compliance within the [ORGANISATION]. This policy has been approved by [SENIOR MANAGEMENT GROUP] and forms part of its policies and procedures. [SENIOR MANAGEMENT GROUP] are responsible for reviewing this policy on an annual basis. They will provide clear direction, visible support and promote information security through appropriate commitment and adequate resourcing. The [INFORMATION SECURITY ROLE] is responsible for the management of information security and, specifically, to provide advice and guidance on the implementation of this policy.
[OPTIONAL DEPENDING ON ORGANISATION SIZE]
The [INFORMATION SECURITY ADVISORY GROUP] comprising representatives from all relevant sections of the [DEPARTMENT/ OTHER UNIT] is responsible for identifying and assessing security requirements and risks. It is the responsibility of all line managers to implement this policy within their area of responsibility and to ensure that all staff for which they are responsible are 1) made fully aware of the policy, and 2) given appropriate support and resources to comply. It is the responsibility of each member of staff to adhere to this policy. Policy Statement The [ORGANISATION] is committed to protecting the security of its information and information systems. It is also committed to a policy of education, training, and awareness for information security and to ensuring the continued business of the [DEPARTMENT/ other units]. It is the [ORGANISATION]’s policy that the information it manages shall be appropriately secured to protect against breaches of confidentiality, failures of integrity or interruptions to the availability of that information and to ensure appropriate legal, regulatory and contractual compliance. To determine the appropriate level of security control that should be applied to information systems, a process of risk assessment shall be carried out in order to define security requirements and identify the probability and impact of security breaches.
Specialist advice on information security shall be made available throughout the [DEPARTMENT/OTHER UNIT] and advice can be sought via the Organization’s Information Security Team [ADD URL] and/or [ADD ADDITIONAL URLS, if required]. It is the [UNIT NAME]’s policy to report all information or IT security incidents or other suspected breaches of this policy. The [UNIT NAME] will follow the Organization’s advice for the escalation and reporting of security incidents and data breaches that involve personal data will subsequently be reported to the Organization’s Data Protection Officer. Records of the number of security breaches and their type should be kept and reported on a regular basis to the [SENIOR MANAGEMENT GROUP/INFORMATION SECURITY ROLE].
Failure to comply with this policy that occurs as a result of deliberate, malicious or negligent behaviour, may result in disciplinary action.

Back to Home Page

If you need assistance or have any doubt and need to ask any questions contact me at [email protected]. You can also contribute to this discussion and I shall be happy to publish them. Your comments and suggestion are also welcome.