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.
- Perform a high-level gap analysis of each regulatory requirement and driver that is applicable to determine where policy is needed.
- Develop a prioritized action plan that will help you organize your efforts.
- Prepare a summary document of the impact that the information security policy or policies will have on the organization. The document should:
- Describe the policy
- Communicate the reason or business justification for the policy, as well as the risks and negative impact of not implementing the policy
- Identify regulatory, technical, cultural, and organizational dependencies for implementation of the policy
- Identify milestones and possible roadblocks of implementation, compliance, and enforcement
- Identify impacted stakeholders
- Develop the policy in collaboration with other key stakeholders at your organization.
- 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.
- Review resources such as the standards and regulations that address specific requirements (e.g., PCI DSS 3.0, HIPAA, GLBA).
- Publish, communicate, train, and implement.
Clause 5.2 Policy
Top management must establish an information security policy that is appropriate to the purpose of the organization and must include information security objectives or provides the framework for setting information security objectives. It must also include a commitment to satisfy applicable requirements related to information security and a commitment to continual improvement of the information security management system. The information security policy should be available as documented information. It must be communicated within the organization and be available to interested parties, as appropriate.
An information security policy is the cornerstone of the information security Management system. It should reflect the organization’s objectives for security and the agreed-upon management strategy for securing information. In order to be useful in providing authority to execute the ISMS, it must also be formally agreed upon by executive management. This means that, in order to compose an information security policy document, an organization has to have well-defined objectives for security and an agreed-upon management strategy for securing information. If there is debate over the content of the policy, then the debate will continue throughout subsequent attempts to enforce it, with the consequence that the information security program itself will be dysfunctional. The Information Security Policy actually serves as the main link between your top management and your information security activities, especially because ISO 27001 requires the management to ensure that ISMS and its objectives are compatible with the strategic direction of the company (clause 5.2 of ISO 27001). The policy is probably the best way to do this. The elements of Information security policies are
- To establish a general approach to information security
- To detect and forestall the compromise of information security such as misuse of data, networks, computer systems, and applications.
- To protect the reputation of the company with respect to its ethical and legal responsibilities.
- To observe the rights of the customers; providing effective mechanisms for responding to complaints and queries concerning real or perceived non-compliance with the policy is one way to achieve this objective.
ISP should address all data, programs, systems, facilities, other tech infrastructure, users of technology and third parties in a given organization, without exception.
3. Information security objectives
An organization that strives to compose a working ISP needs to have well-defined objectives concerning security and strategy on which management has reached an agreement. Any existing dissonances in this context may render the information security policy project dysfunctional. The most important thing that a security professional should remember is that his knowing the security management practices would allow him to incorporate them into the documents he is entrusted to draft, and that is a guarantee for completeness, quality, and workability.
Simplification of policy language is one thing that may smooth away the differences and guarantee consensus among management staff. Consequently, ambiguous expressions are to be avoided. Beware also of the correct meaning of terms or common words. For instance, “musts” express negotiability, whereas “shoulds” denote a certain level of discretion. Ideally, the policy should be briefly formulated to the point. Redundancy of the policy’s wording (e.g., pointless repetition in writing) should be avoided as well as it would make documents long-winded and out of sync, with illegibility that encumbers evolution. In the end, tons of details may impede complete compliance at the policy level. So how management views IT security seems to be one of the first steps when a person intends to enforce new rules in this department. Furthermore, a security professional should make sure that the ISP has an equal organizational gravity as other policies enacted within the corporation. In cases where an organization has a sizeable structure, policies may differ and therefore be segregated in order to define the dealings in the intended subset of this organization. Information security is deemed to safeguard three main objectives:
- Confidentiality – data and information assets must be confined to people authorized to access and not be disclosed to others;
- Integrity – keeping the data intact, complete and accurate, and IT systems operational;
Availability – an objective indicating that information or system is at disposal of authorized users when needed.
4. Authority & Access Control Policy
Typically, a security policy has a hierarchical pattern. It means that inferior staff is usually bound not to share the little amount of information they have unless explicitly authorized. Conversely, a senior manager may have enough authority to make a decision on what data can be shared and with whom, which means that they are not tied down by the same information security policy terms. So the logic demands that ISP should address every basic position in the organization with specifications that will clarify their authoritative status.
Policy refinement takes place simultaneously with defining the administrative control, or authority in other words, people in the organization have. In essence, it is the hierarchy-based delegation of control in which one may have authority over his own work, the project manager has authority over project files belonging to a group he is appointed to, and the system administrator has authority solely over system files – a structure reminiscent of the separation of powers doctrine. Obviously, a user may have the “need-to-know” for a particular type of information. Therefore, data must have enough granularity attributes in order to allow the appropriate authorized access. This is the thin line of finding the delicate balance between permitting access to those who need to use the data as part of their job and denying such to unauthorized entities.
Access to a company’s network and servers, whether or not in the physical sense of the word, should be via unique logins that require authentication in the form of either password, biometrics, ID cards, or tokens, etc. Monitoring on all systems must be implemented to record login attempts (both successful ones and failures) and the exact date and time of logon and logoff.
Speaking of evolution in the previous point – as the IT security program matures, the policy may need updating. While doing so will not necessarily be tantamount to improvement in security, it is nevertheless a sensible recommendation.
5. Classification of Data
Data can have a different value. Gradations in the value index may impose separation and specific handling regimes/procedures for each kind. An information classification system, therefore, may succeed to pay attention to the protection of data that has significant importance for the organization and leave out insignificant information that would otherwise overburden an organization’s resources. A data classification policy may arrange the entire set of information as follows:
a) High-Risk Class – data protected by state and federal legislation (the Data Protection Act, HIPAA, FERPA) as well as financial, payroll, and personnel (privacy requirements) are included here.
b) Confidential Class – the data in this class do not enjoy the privilege of being under the wing of law, but the data owner judges that it should be protected against unauthorized disclosure.
c) Class Public – This information can be freely distributed.
Data owners should determine both the data classification and the exact measures a data custodian needs to take to preserve the integrity in accordance with that level.
6) Data Support & Operations
In this part we could find clauses that stipulate:
- The regulation of general system mechanisms responsible for data protection
- The data backup
- Movement of data
7) Security Awareness Sessions
Sharing IT security policies with staff is a critical step. Making them read and sign to acknowledge a document does not necessarily mean that they are familiar with and understand the new policies. A training session would engage employees in a positive attitude to information security, which will ensure that they get a notion of the procedures and mechanisms in place to protect the data, for instance, levels of confidentiality and data sensitivity issues. Such an awareness training should touch on a broad scope of vital topics: how to collect/use/delete data, maintain data quality, records management, confidentiality, privacy, appropriate utilization of IT systems, correct usage of social networking, etc. A small test at the end is perhaps a good idea.
8) Responsibilities, Rights and Duties of Personnel
General considerations in this direction lean towards the responsibility of persons appointed to carry out the implementation, education, incident response, user access reviews, and periodic updates of an ISP. Prevention of theft, information know-how and industrial secrets that could benefit competitors are among the most cited reasons why a business may want to employ an ISP to defend its digital assets and intellectual rights.
8) Reference to Relevant Legislation
10) Other Items that An ISP May Include:
Virus Protection Procedure, Intrusion Detection Procedure, Remote Work Procedure, Technical Guidelines, Audit, Employee Requirements, Consequences for Non-compliance, Disciplinary Actions, Terminated Employees, Physical Security of IT, References to Supporting Documents and so on.
Template for an information security policy
|Information security policy|
|[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.
|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.|
|This 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 security|
|The [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.
| 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.
Example of Security Policy
Annex A: Control objectives and control
A.5 Information security policies
A.5.1 Management direction for information security
To provide management direction and support for information security in accordance with business requirements and relevant laws and regulations.
A. 5.1.1 Policies for information security
A set of policies for information security should be defined, approved by management, published and communicated to employees and relevant external parties.
At the highest level, organizations should deﬁne an “information security policy” which is approved by management and which sets out the organization‘s approach to managing its information security objectives. Information security policies should address requirements created by:
- Business strategy;
- Regulations, legislation, and contracts;
- The current and projected information security threat environment.
The information security policy should contain statements concerning:
- Definition of information security, objectives, and principles to guide all activities relating to information security;
- Assignment of general and specific responsibilities for information security management to defined roles;.
- Processes for handling deviations and exceptions.
At a lower level. the Information security policy should be supported by topic-specific policies. which further mandate the implementation of information security controls and are typically structured to address the needs of certain target groups within an organization or to cover certain topics.
Examples of such policy topics include:
- Access control;
- Information classification and handling ;
- Physical and environmental security;
- End user-oriented topics such as:
- Acceptable use of assets ;
- Clear desk and clear screen;
- Information transfer :
- Mobile devices and teleworking ;
- Restrictions on software installations and use ;
- Information transfer :
- Protection from malware ;
- Management of technical vulnerabilities;
- Cryptographic controls
- Communications security;
- Privacy and protection of personally identifiable information:
- Supplier relationships.
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 security awareness. education and training program”. The need for internal policies for information security varies across organizations. Internal policies are especially useful in larger and more complex organizations where those defining and approving the expected levels of control are segregated from those implementing the controls or in situations where a policy applies to many different people or functions in the organization. Policies for information security can be issued in a single “information security policy” document or as a set of individual but related documents. If any of the information security policies are distributed outside the organization, care should be taken not to disclose conﬁdential information. Some organizations use other terms for these policy documents, such as ‘Standards’, “Directives” or “Rules”.
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.
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.
- 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.
- 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.
- 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.)
- 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.
- 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.
- 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.
- 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.
Few Examples of Security policies
|Example of Security policy of Punjab State Power Corporation Ltd (PSPCL)|
|Example of Cyber Security policy of Food Corporation of India (FCI)|
|Example of Security policy of British Columbia|
A. 5.1.2 Review of the policies for information security
The policies for information security should be reviewed at planned intervals or if signiﬁcant changes occur to ensure their continuing suitability, adequacy, and effectiveness.
Each policy should have an owner who has approved management responsibility for the development, review, and evaluation of the policies. The review should include assessing opportunities for improvement of the organization’s policies and approach to managing information security in response to changes to the organizational environment, business circumstances, legal conditions, or technical environment. The review of policies for information security should take the results of management reviews into account. Management approval for a revised policy should be obtained.
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.
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:
- Document needed changes
- Make changes to a draft version of the policy
- Are the changes significant or alter the intent of the original policy?
- 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
- Publish, communicate, train, and implement
If you need assistance or have any doubt and need to ask any questions contact me at firstname.lastname@example.org. You can also contribute to this discussion and I shall be happy to publish them. Your comments and suggestion are also welcome.