Have You Updated Your WISP Lately?

When I tell people that I am an IT consultant specializing in cybersecurity and privacy, our conversations usually revolve around a recent hack or data breach that was reported in the news. We talk about smartphone vulnerabilities, the perils associated with the collection of geolocation data, whether voice data collected by a person's smart speaker can be used against them in a court of law, and whether a password or PIN best protects a person's Fifth Amendment right against self-incrimination. We talk only about the provocative and exciting side of cybersecurity and privacy.

Do you know what we don't talk about? We don't talk about a college or university's written information security policy (WISP). We don't talk about whether campus community members know about the WISP or whether they understand their roles and responsibilities regarding cybersecurity. We don't talk about how to use the WISP and other cybersecurity policies as tools to educate the campus community about how to protect institutional IT resources and data. We certainly don't talk about how often the WISP and related cybersecurity policies should be reviewed and updated. It's not an exciting topic. Policies are the woolen underwear of cybersecurity practice.

And, like itchy bloomers, policies are foundational. They form the basis of a comprehensive institutional information security program. Without policies, institutions have no way of expressing the importance of information security practices or institutional goals related to information security. Without policies, institutions have no way to designate departments with information security authority and responsibility, and they certainly have no way to distill and publish the rules that help end users protect data or hold them accountable for violating IT-systems or data-use best practices. Without policies, an institution has no producible artifacts to demonstrate compliance with the numerous laws and regulations that require it to have a written information security policy.

Writing and implementing a WISP is not a one-and-done activity or a simple activity that can be completed in an afternoon. Instead, it is an activity that requires a core group of people who are dedicated to reviewing the business processes of the institution and understanding the laws and regulations that apply to the IT systems and data used in those processes; identifying potential information security gaps and weaknesses; finding the right compromises between business practices and security and reducing the resulting information security "rules" to writing, soliciting, and implementing stakeholder feedback; and educating end users about the policy once it is approved by institutional leadership—and then doing it all over again.

What is the reason for starting the process over again? Because both the cybersecurity landscape and the IT systems and data of higher education institutions are constantly evolving. A WISP that was drafted ten, five, or even three years ago may not be sufficient to address institutional business practices today. For instance, the rise in the use of cloud services should have forced a review of an institution's WISP. Why? Because the scope of most WISPs written several years ago may only include on-premises IT systems and data. Those policies are probably insufficient to deal with situations where a third party runs an institution's IT systems or holds its data. At the very least, an institution would need to update its WISP to ensure that procurement contracts for outsourcing arrangements contain appropriate information security controls to protect an institution's data.

I recommend that institutions consider a policy-lifecycle approach to creating and updating their WISP and related cybersecurity policies. The lifecycle approach has the following high-level stages:

1. Development
2. Stakeholder review
3. Management approval
4. Implementation
5. Compliance
6. Evaluation

Policy Development and Stakeholder Review

During the development stage, an institution studies why it needs a WISP (or reviews or revises its WISP). When first considering developing a WISP or related information security policy, an institution must be able to specify the business reason or justification for the policy, as well as the risks and potential impacts of not implementing a policy. Sometimes it is easy to articulate a reason for a policy. For instance, an institution might be implementing a WISP because a law or regulation requires it to have one. In other instances, an institution might be trying to change its culture to focus on information security improvement. There can be many reasons why an institution wants to implement a policy. (Keep in mind that these same requirements apply to policy revisions as well. Much like The Song That Never Ends, the policy lifecycle is continual and applies to policy revisions as well.)¹

In addition to specifying the business reason for a policy, an institution must also be able to clearly describe a number of elements:

• Impacted stakeholders: The people, units, departments, and processes to which the policy will apply.
• Any institutional dependencies that would impact the implementation of the policy (or revision) (e.g., technical, regulatory, or institutional dependencies).
• Policy (or revision) implementation milestones: Is there a date by which the policy must be reviewed and approved? If so, that date should be clearly understood.
• Compliance and enforcement expectations.

Following a review of these items, the institution will decide on a course of action for the proposed policy (or revision). Possible courses of action include drafting a new document, making revisions to an existing policy document, choosing not to take action, or pursuing some other type of action. At this point, if necessary, WISP drafting (or revising) should commence according to the institution's policy-development process.

Stakeholder review is one of the most important steps in the policy-lifecycle process. There is no one best process for stakeholder review. Stakeholders are individuals with direct policy responsibilities, such as compliance and enforcement. They are also institutional leaders in departments that will have to follow the WISP and related policies. Stakeholders usually include information security representatives, legal counsel, human resources staff, operational staff, and any other applicable data or IT steering committee members. These individuals must have an opportunity to review any draft policies (or revisions).

Stakeholder review often unearths issues that may negatively impact policy implementation, helps identify avenues to explore for compliance and enforcement, and ultimately builds consensus for the policy. Stakeholders can conduct their review of draft policies (or revisions) by thinking about the following questions:

• Is this policy (or revision) understandable?
• Is this the right type of policy (or revision) for this situation, or would some other course of action be more useful? (And why?)
• Does the policy (or revision) balance security/protection with productivity? For the institution? For my unit/department?
• What does the institution (or my unit/department) need to do to comply with this policy (or revision)? Can we comply with it, or will we need an exception? (Keep in mind that one difficulty with a WISP and related policies is that a balance must be struck between providing enough detail that community members understand their responsibilities but not so much detail that the institution is exposed to unnecessary information security risk).
• Do people know what they will need to do to comply with the policy (or revision) by reading the document, or is more guidance needed? As a leader, do I know what I will need to do to support the policy?
• Are there any potential barriers or obstacles to policy implementation? How can those be overcome?

After stakeholder review, the unit responsible for drafting the proposed policy (or revisions) may choose to make changes to the document. Substantive changes should always be reviewed again by stakeholders for additional feedback (this helps build consensus). Following the conclusion of this stage, stakeholders should largely agree on the terms contained in the draft policy (or revision).

A new or revised WISP may go through many rounds of revision and stakeholder review before it is considered "done." At this point, the WISP is ready for the next stages in the lifecycle approach: management approval and implementation.

Management Approval and Implementation

During the management approval stage, the unit responsible for drafting the proposed WISP (or revision) presents the draft to institutional leaders (or signatories) for review and approval. Generally speaking, the highest applicable leadership level should sign or ratify a WISP and related documents. This shows the institution that executive leadership supports information security efforts and views them as important. Once the WISP is signed (or the revision is ratified), the document is considered an official institutional policy.

Often, individuals responsible for drafting a WISP or a revision focus only on getting the document to the management approval stage. Management approval is a significant milestone in the policy-development process. However, in my opinion, it's not the most important stage in the policy-development lifecycle. The most important stage is the implementation stage.

During the implementation stage, the unit responsible for the policy must make sure that the entire institution (or at the very least the audiences that are subject to the policy) is aware of the policy and knows what it needs to do to comply with the policy. The effectiveness of the policy will be in jeopardy if the institution and audiences don't know about the policy or their responsibilities under it. This stage requires the unit responsible for the policy to consider the following questions:

• Has the policy been posted to the institutional policy repository or website (or internal intranet site)?
• Does this policy (or revision) need to be communicated to the entire institution, and what communication vehicles (e.g., newsletters, email, social media, listservs) are most appropriate?
• How often should the policy (or revision) be communicated to the various audiences?
• Do members of the institution need general or specialized training on the policy?

Communicating the new WISP is critically important. Without the implementation step, institutional end users may not know that an information security policy exists or what they need to do in response to it. Posting a new or revised WISP to a webpage or institutional bulletin board and then walking away without further thought to ongoing communications or training is not sufficient to help an institution meet its information security goals or demonstrate compliance.

At this point, the institution must enforce the WISP and continue to review its IT and cybersecurity landscapes for changed circumstances that might require a policy revision.

Compliance and Evaluation

The compliance stage includes actions taken by the unit responsible for the WISP and related policies to ensure that the policies are being followed. That unit must also ensure that any exceptions to policy compliance are documented, approved, and regularly reviewed. Understanding where policy exceptions exist is important because each policy exception could potentially create an information security gap or weakness that could be exploited to cause harm to the institution. During this stage, the unit responsible for the policy may take the following general actions:

• Coordinate with other units/departments on their policy compliance activities.
• Coordinate with internal audit and other oversight groups regarding institutional policy compliance.
• Respond to questions about the policy or compliance issues.
• Follow a documented policy exception process and ensure that requested policy exceptions are reviewed according to that process.

During the compliance stage, an institution may also develop ongoing communications about policy compliance (e.g., policy reminders and non-mandatory policy training). It may also coordinate or schedule required policy compliance training.

Continuous review and improvement are critical parts of the information security policy lifecycle. The evaluation stage ensures that the WISP and related policies are regularly reviewed and that they continue to meet the institution's information security goals. In most instances, the unit responsible for the policy will review the institution's WISP at regular intervals or when external or internal triggers require the review and update of the policy. Sometimes a policy will indicate the timeframe for review (e.g., every three to five years). If not, the responsible department should establish and follow a review cycle for policies.

Following are some of the most common triggers that would indicate that policy review is needed:

• Changes in federal or state laws and regulations
• Audit findings
• Changes in technology or in how technology is provisioned
• Major information security project deployments
• New institutional business practices
• Conversations with institutional stakeholders that indicate a need for policy support

Following the policy review, the unit responsible for reviewing a policy may decide that the WISP is still accurate and does not need to be updated or revised. It could also decide that the document needs to be updated or requires other revisions. In some cases, the institution could conclude that circumstances are so changed that the WISP or related documents are no longer needed and should be rescinded. (It's true. Every once in a while, this happens.)

And that's it! The policy lifecycle is a tool that information security practitioners can use to ensure that its WISP and related information security policies are properly managed from conception to retirement. Proper policy management is important because a WISP is a foundational policy that forms the basis of a comprehensive institutional information security program.

Note

1. "The Song That Never Ends," is a single-verse children's song written in an infinite-loop motif. See Wikipedia, s.v. "The Song that Never Ends," last modified December 20, 2020. ↩

---

Joanna Lyn Grama is Associate Vice President at Vantage Technology Consulting Group.