Risk Management Policy Considerations

Identifying, minimizing, and controlling exposures to loss are important functions for all institutions.  Most of you have already implemented a risk management policy for your college or university, or are in the process of developing or updating one.

My institution, Washington State University (WSU), published an administrative Policy on Risk Management (EP6) in January 2019.  In August 2023, we finalized a revision to EP6 which included a number of new approaches for overseeing this process that I thought I'd share for your consideration.

Enterprise Type—Campus or System

WSU has multiple campuses in various parts of the state, plus an online (global) campus.  For many years, our Pullman campus was our main administrative hub.  A few years ago, the administration decided to move to a systemwide management model, with each campus, including our flagship Pullman campus, led by a separate campus chancellor, who in turn reports to our system president. 

Some administrative functions are best served by specific campus oversight, and some are best served by systemwide oversight.  International standards encourage an enterprise (systemwide) approach to risk management.  WSU follows International Organization for Standardization (ISO) 31000: 2018—Risk Management Guidelines to identify potential obstacles or occurrences that could threaten an enterprise's ability to meet its mission and goals.

Enterprise Risk Management Software

The state of Washington also encourages an enterprise approach to risk management by state agencies, of which WSU is one.  To facilitate this, the Washington Department of Enterprise Services (DES) provides software modules to the risk management offices at all state agencies to assist with risk identification and rating, risk controls, and planning for managing risks.  The software that DES selected to distribute is the Origami risk management information system. The software platform integrates insurance, risk, safety, and compliance solutions.

I found this addition to our policy rather fascinating, as I'm a fan of tech solutions.  Since the software is distributed directly to our RM office only, little direct information was put into our executive policy.  If you're interested in investigating this further, go to the link above to get more information from the manufacturer's website.

Administrative Oversight

WSU decided to implement a four-level approach to administrative oversight of risk management:

1. Risk Management Executive Committee (RMEC):  RMEC is a presidential committee that provides executive oversight for enterprise and operational risk. It oversees the Enterprise Risk Management (ERM) process. RMEC also provides guidance to the Risk Management Advisory Group (RMAG) and Risk Management (RM) office.
   
2. Risk Management Advisory Group (RMAG): RMAG is appointed by our Executive Vice President of Finance and Administration. Its membership is representative of system units engaged in daily risk management. Units may request to join RMAG through the Risk Management Office.
   
3. Risk Management Office (RM): The RM office at WSU is a part of Compliance and Risk Management under Finance and Administration. RM coordinates and evaluates the risk management program for the WSU system and has responsibility and authority in four primary areas:
• Risk awareness, assessment, and assistance services to units and personnel;
• Coordination of systemwide risk committees;
• Managing and administering insurance coverages and related services to units; and,
• Reporting risks, accidents, injuries, liabilities, and other risk management activities to university departments and applicable state and federal agencies.


4. Individuals and Units: Individual employees, departments, and units are responsible for taking steps to reduce the risk of injury and accidental loss to the greatest extent possible, consistent with carrying out the institution's mission and goals. RM is available to provide assistance to individuals and units, as needed.

Every institution handles risk management processes differently, but as we've all found, it is a good idea to formalize a policy for managing risks.  I hope what I've shared from the WSU perspective helps you start or continue your own conversations about developing or revising risk management at your institution.

Making Your Policies Accessible to All Audiences

Most institutions are now aware of the need for recognizing and respecting the differences among the members of our stakeholder communities. As policy administrators, many of us are building equity review into our policy development processes.

Most of us now publish our institutions' policies online and share our policy drafts electronically, rather than in paper policy manuals or through paper documents. Just as it's important to consider adding equity review to the development of policies, it's also important that we consider how to prepare the content for distribution in ways that make it accessible to a wide range of people, including those who use assistive devices.

Here are some considerations for your institutions, all of which we’ve put in place here at Washington State University (WSU):

• Establish a policy and/or procedures for improving the accessibility of online and electronic content. As an example, here at WSU we have an executive policy and supporting procedures:
  • University Web Accessibility Policy
  • Ensuring Electronic and Information Technology Accessibility
• Require web accessibility training for all institutional online developers and webmasters.
• Provide issue reporting and complaint/grievance procedures regarding accessibility issues.

At WSU, our Web Communications unit handles web accessibility problems and our institution's ADA (Americans with Disabilities Act) coordinator is responsible for managing access complaints and grievances.

Creating Accessible Word and PDF Documents

Most of us use Word to create our source documents and either Word or PDF for drafts and creating web versions of our policies. Taking in consideration of assistive devices, here's some key components for making Word and PDF documents accessible to all:

• Headings:
  • Headings create a hierarchy in the document that a screen reader can follow.
• Document Title, Description, and Tags:
  • A default document title is necessary for a screen reader to be able to scan and read out loud to its user.
  • A document description gives screen reader users a brief summary of the document they are about to read.
  • Document tags allow a screen reader to know if they are looking at an image, a paragraph, a heading, etc.
• Hyperlinks:
  • Hyperlinks need to have clearly defined labels of the destination of each link so that a screen reader is able to read them out loud when scanning the document.
  • It's preferable to embed link URLs (attach the URL in the background to a word or phrase using the Link function), also known as contextual links, rather than writing out URLs in the document.
• Tables:
  • Clear table structures and headers are necessary for a screen reader to be able to scan the document.
• Alt Text:
  • Alt Text data allows a screen reader to scan a description of tables, figures, or images that may be on the document.
• Lists:
  • The built in formatting tools of Word make it easier for the screen reader to scan the document.
• Capitalized Words:
  • Use bold for emphasis and avoiding capitalization of words.
  • Assistive devices may provide capitalized words to users by reading each individual letter, instead of complete words.
• Tab/Reading Order
  • For PDFs, identifying the reading order of a document’s text helps a screen reader present the text as it is meant to be read, rather than just as random blocks of text.
    

Creating Fully Functional PDFs from Word

With the latest versions of Word in Office365, all accessibility functionality in a Word source document may be directly transferred to a PDF version:

• Select File->Save As
• Change the file type (suffix) from the default Word Document (.docx) to PDF (.pdf).
  A PDF file created in this way includes all of your active hyperlinks and other functionality.
  

Creating Accessible Documents from Scanned Images

In order to make scanned document images accessible to a screen reader user, a few things need to be done, otherwise none of the information on the document can be read by a screen reader:

• Make or convert the scanned image to PDF
• Under Tools (in Adobe Acrobat Pro):
  • Select Optical Character Recognition (OCR)
  • Select Text Recognition and In This File, and
  • Select the pages to be included
• Under Tools:
  • Select Action Wizard, then
  • Select Make Accessible
  • Select Find Recognize Text Using OCR
• In the Recognize Text -- General Settings window:
  • Select the applicable language and
  • Select Searchable as the PDF Output Style
• Select OK
  

Accessibility Guides

The process of increasing equity in our policies and policy access is ongoing. Here are some accessibility guides to provide you with further ideas as you get started:

• World Wide Web Consortium (W3C) Web Content Accessibility Guidelines (WCAG) 2.0
• U.S. General Services Administration (GSA) 18F Accessibility Guide
• WSU Web Communications Accessibility Guides

Framework Recommendations Instead of Templates

In conversations and webinars with other policy administrators, the debate about whether or not to use templates for writing and developing policies continually comes up. A number of institutions mandate the use of one or more templates for their users who want to develop policy and/or procedures documents.

I've worked for the past 25 years in the administrative policies office for Washington State University. We've chosen not to use a template for developing the administrative policies and/or procedures our office publishes. We do have a style guide, but it’s mostly involved with formatting and layout so that sections and policies have a uniform “look.” Our choice has predominantly been based on the idea of providing flexibility to our subject expert departments as they update or add new sections to our long-established administrative policy manuals.

In accordance with WSU's executive Policy on Policies (EP5), departments may begin development of their administrative policy/procedure rough drafts prior to bringing my office into the process or may request our assistance with developing the drafts from the beginning. As subject expert administrators get started, we do occasionally get requests for policy framework guidance from those who are new to policy writing and development.

Here’s a general outline that my office recommends for writing a new policy or policy/procedure section for placement in one of our administrative manuals:

• Overview and/or Policy Statement
  
  It’s sometimes useful to have both. If a section is especially long, placing a set of links to subsections in the document in the overview can be useful. For examples, see the beginnings of WSU's policy sections EP8 and EP38.
  
  In a section that's predominantly procedural, an overview might be more appropriate as a place to provide a summary of or references to the applicable policy.
  
  
• Purpose
  
  A purpose statement provides a brief description of the purpose of the policy and/or activity. In some cases, a purpose statement is provided in an overview or policy statement.
  
  
• Scope
  
  A scope statement describes the limitations or boundaries of the policy/procedure. Some writers choose to combine scope statements/subsections in either an overview or policy statement or within an applicability statement.
  
  
• Applicability
  
  An applicability statement or subsection describes the members of the institution's community (internal and/or external) directly impacted by the policy and/or expected to follow the policy/procedures.
  
  
• Roles and Responsibilities
  
  Roles and responsibilities statements provide a summary of the actions and/expectations each employee or role category is expected to fulfill with relation to the policy/procedures.
  
  
• Requirements
  
  Policy requirements are provided in this subsection. If procedures are included, any required procedural steps would be provided in the order the actions are to occur.
  
  
• Procedures (if applicable)
  
  Some institutions choose to keep policies and procedures separate. At WSU, we have quite a number of combined policy and procedures sections in our administrative manuals. For the most part, we recommend publishing procedures and policy/procedures within our business and safety manuals. However, we do have a small number of executive policies in which the executive administrators insisted upon including both policies and procedures.
  
  
• Definitions
  
  We recommend providing definitions applicable to the policy/procedures in their own subsection, especially if terms are used that are specific to a subject and/or include jargon. If there are only one or two terms that need to be defined, the definitions may be included directly with the reference.
  
  If this subsection is short, it might be placed after the applicability statement. However, if the definitions list is longer than a page, we often recommend placing the subsection at or near the end and providing an internal document link and/or reference, if needed, earlier in the policy.
  
  
• Additional Resources
  An additional resources subsection provides descriptions or lists and references (e.g., website URLs) including, but not limited to, supporting department contacts, state and federal agencies' websites, other supporting or related institutional policies and procedures.

Every policy office and institution handles their policy development process differently, and there's really no right or wrong answer. Does your institution mandate policy/procedure templates? Or make framework recommendations? Things to consider for both you and your users…

NOTE: ACUPA members have access to a number of resources, including templates, samples, and other tools that you may find useful in writing and developing your policies and procedures. To access the Templates and Tools under the Resources tab, sign in as a member.