#DataSpringCleaning 2021 – Email and Patron Data

A white and brown short-haired dog places their right front paw on top of a open laptop keyboard. The laptop screen shows a blurred Gmail inbox window.
Image source: https://www.flickr.com/photos/karenbaijens/16241866468/ (CC BY 2.0)

Welcome to the first week of Spring in the Northern Hemisphere! This month marks one year of working from home for some library workers and the hybrid remote/onsite work limbo for others. In both cases, this anniversary also marks a year’s worth of patron data collected and stored all over the place due to the abrupt switch to remote work and virtual services. It’s safe to say that many disaster or business continuity plans didn’t plan for a pandemic, and the resulting scramble to virtual or reduced physical services/work created new or exacerbated existing data privacy gaps. Last year’s #DataSpringCleaning focused on setting up the home office to address a common privacy problem – the over-retention of patron data. Check out the post and the companion workshop materials about protecting patron privacy while working from home if you haven’t already done so.

This year’s #DataSpringCleaning project is ambitious as it is daunting. This year is the Sisyphean project of data cleanup projects – no matter how many times we try and fail, we keep coming back to this one project in hopes of finally completing it. Let us go back once more into the breach, friends. It’s time to scrub our work email.

Email as Major Privacy Risk to Patron Privacy

While many library workers are aware that their emails can contain patron data, they might not be aware of how much patron data is stored in their accounts. Personally identifiable information, or PII, includes data about a patron as well as data of a patron’s activity. The former can be easy to identify and easy to email without much thought about the privacy risk of doing so:

  • Name
  • Physical and email addresses
  • Birthdate or age
  • Patron record number
  • Username and password

A patron’s activities, on the other hand, can be harder to identify once you factor in the types of emails a library worker can receive or send in any given day:

  • Help desk ticket threads
  • Reference form or chat tickets or transcripts
  • Direct email from patrons
  • System or application reports or alerts
  • Vendor service desk tickets or reports

This list is just a small selection of the types of emails that can contain data around a patron’s activities such as:

  • Reference questions
  • Search and circulation histories
  • IP addresses
  • Electronic resource authentication and access history
  • Library computer and wifi logs and activity

And that’s just the start of how much patron data is in staff emails!

The ease of storing and sharing data through email makes it difficult to control data sharing and retention once the data hits the email system. The risk to patron privacy compounds once the email containing patron data leaves the library’s email system and into a third-party email account, be it a vendor or even a personal email account. Another risk for many libraries is that staff emails are subject to public disclosure requests. Several state and local regulations protect patron record data from disclosure, but in some cases, this protection might not extend to patron data in staff email. If your library’s emails can be publicly requested, don’t assume that you’ll get a chance to redact patron data before the emails are released to the public.

Starting the Long Journey of Protecting Patron Privacy in Staff Email

Scrubbing patron data from library email is a Sisyphean task. You can tell patrons not to email PII only to have patrons send over their logins for the financial website they can’t log into on a public computer. You can tell staff not to store patron data in work email, only to have staff use email as their primary knowledgebase for reference chat questions and answers. However, you have more control over how staff uses library email than you do patrons – this is where we start our scrubbing journey.

We’ll break this journey into two parts: the short and long term. The following are some actions workers and organizations can take in mitigating patron privacy risk in library emails:

Short term (individual) actions

  • First, get familiar with your email system’s filter and search capabilities! These will make the deletion process less painful.
  • Find and delete system-generated emails that contain patron data. These can be found through searching by a shared email address or subject line.
  • Search for emails with attachments and delete attachments if they contain patron data
  • Before deleting the email, migrate patron data that absolutely must be retained for a demonstrated operational need from email to a secured storage area designated by work (if one is available)
  • Create email rules to automatically delete incoming system-generated emails containing patron data
  • Learn how to use the ticketing system or other help desk or information desk systems as the primary mode of communication with other library staff about tickets and other

Long term (organizational) actions

  • Create policies and procedures around restricting the use of staff email to transmit or store certain types of patron data based on data classification level and/or privacy risk
  • Create secured data/file transfer options for sharing patron data, particularly between staff and authorized third parties
  • Set up applications and systems to not include patron data in system-generated reports and emails
  • Set up retention policies in email systems to automatically delete email  based on organizational retention schedules or retention schedules set by legal regulation
  • Create procedures or processes to use the ticketing system or other help desk or information desk systems as the primary mode of communication between staff as well as between staff and patrons
  • Create secured storage outside of staff email for patron data that absolutely must be retained for a demonstrated operational need, and create retention schedules for the data retained in storage

The short-term actions can take a while with manual reviewing of attachments and individual emails. But, with the magic of search and filter options, you can quickly eliminate a good portion of privacy risks by deleting the archive of system-generated emails. The long-term actions require a team effort in the organization, from administration drafting policies to IT creating automatic retention policies and secured storage and transmission options.

None of us want to spend more time dealing with email than we have to, and trying to keep up with the current email inbox count is near impossible as it is. Nonetheless, we need to keep in mind that work email can put patron privacy at risk, and we must address that risk as part of our library duties. It’s a #DataSpringCleaning project that never ends, but as long as we have email, there will always be the need to clean our inboxes to protect patron privacy.

Just Published! Library Data Risk Assessment Guide

Welcome to this week’s Tip of the Hat!

To build or to outsource?

Building an application or creating a process in a library takes time and resources. A major benefit of keeping it local, though, is that libraries have the greatest control over the data collected, stored, and processed by that application or system. Conversely, a major drawback of keeping it local is the sheer number of moving parts to keep track of in the building process. Some libraries have the technical know-how to build their own applications or have the resources to keep a process in house. Keeping track of privacy risks is another matter. Risk assessment and management must be addressed in any system or process that touches patron data, so how can libraries with limited privacy risk assessment or management experience make sure that their local systems and processes mitigate patron privacy risks?

Libraries have a new resource to help with privacy risk management! The Digital Library Federation’s Privacy and Ethics in Technology Working Group (formerly known as the Technologies of Surveillance Working Group) published “A Practical Guide to Performing a Library User Data Risk Assessment in Library-Built Systems“. This 28-page guide provides best practices and practical strategies in conducting a data risk assessment, including:

  • Classifications of library user data and privacy risk
  • A table of common risk areas, including probability, severity, and mitigation strategies
  • Practical steps to mitigate data privacy risks in the library, ranging from policy to data minimization
  • A template for readers to conduct their own user data inventory and risk assessment

This guide joins the other valuable resources produced by the DLF Privacy and Ethics in Technology Working Group:

The group also plans to publish a set of guidelines around vendor privacy in the coming months, so be sure to bookmark https://wiki.diglib.org/Privacy_and_Ethics_in_Technology and check back for any updates!

CRMS 101

Welcome to this week’s Tip of the Hat! Today we have a brief overview of an acronym that is becoming a popular tool in libraries – the customer relationship management system [CRMS] – and how this new player in the library field affects patron privacy. While some folks know about CRMS, there might be others that are not exactly sure what they are, and what they have to do with libraries. Below is a “101”- type guide to help folks get up to speed on the ongoing conversation.


What is a CRMS?

A customer relationship management system [CRMS] manages an organization’s interactions with customers with the goal to grow and maintain customer relationships with the organization. CRMS products have been used in other fields outside of librarianship for decades, mostly in commercial businesses, but the increased importance in data analysis and improving customer experiences has led for wider adoption of CRMS products in other fields, including libraries.

What is a CRMS used for?

Many organizations use CRMS products to track various communications with customers (email, social media, phone, etc.) as well as data about a customer’s interests, demographics, and other data that can be used for data analysis. This analysis is then used to improve and customize the user experience (targeted marketing, personal recommendations, and invitations, etc.) as well as making business decisions surrounding products, services, and organization-customer relations. This analysis can also be used to create user profiles or for market segmentation research.

What are some examples of CRMS?

There are many proprietary and open source options, though Salesforce is one of the most recognized CRM companies in the overall field. In the library world, several library vendors sell standalone CRMS products, such as OrangeBoy’s Savannah. Other library vendors have started offering products that integrate the CRMS into the Integrated Library System [ILS]. OCLC’s WISE is one such example of this integration, while other library vendors plan to release their versions in the near future.

What data is collected in a CRMS?

A CRMS is capable of collecting a large quantity of very detailed data about a customer. Types of patron data that can be collected with a library CRMS includes (but not limited to):

  • Demographic information
  • Circulation information like total checkouts, types of materials checked out, and physical location of checkouts
  • Public computer reservation information
  • Electronic resource usage
  • Program attendance

In addition to library supplied data, other data sets from external sources can be imported into the CRMS ranging from US Census data to open data sets from cities and other organizations that could include other demographic information by geographical area (such as zip code) or by other indicators.

How is patron privacy impacted by CRMS?

The amount of information that can be collected by a CRMS is akin to the type of information collected by commercial companies who sell services and products. By creating a user profile, the company can use that information to personalize that customer’s experience and interactions with the company, with the ultimate goal of creating and maintaining return customers. Traditionally libraries do collect and store some of the same information that CRMS products collect; however, it is usually not stored in one central database. Creating a profile of a patron’s use of the library leaves both the library and the patron at high risk for harm on both a personal and organizational level. This user profile is subject to unauthorized access by library staff, data breaches and leaks, or intentional misuse by staff or by the vendor that is hosting the system. This user profile can also be subject to a judicial subpoena, which puts patrons who are part of vulnerable populations at higher risk for personal harm if the information is collected and stored in the CRMS.

Further reading on the conflict between the CRMS, data collection, and library privacy:

What can we do to mitigate privacy risks if we use a CRMS?

If your library chooses to use a CRMS:

  • Limit the type and amount of patron data collected by the system. For data that is collected and stored in the CRMS, consider de-identification methods, such as aggregation, obfuscation, and truncation
  • Perform risk assessments to gauge the level of potential harm connected by collecting and storing certain types of patron information as well as matching up patron information with imported data sets from external sources
  • Negotiate at the contract signing or renewal stage with the vendor regarding privacy and security policies and standards around the collection, storage, access, and deletion/retention of patron data, as well as who is responsible for what in case there is a data breach
  • Perform regular privacy and security audits for both the library and the vendor

We hope that you find this guide useful! Please feel free to forward or pass along the guide in your organizations if you are having conversations about CRMS adoption or implementation. LDH can also help you through the decision, negotiation, or implementation processes – contact us to learn more!

[REDACTED] – Redacting PII From Digital Collections

Welcome to this week’s Tip of the Hat! The Executive Assistant is back, and you know what that means…

A sitting black cat looking up at the camera, meowing loudly.
We’re back in business, newsletter-wise!

This week’s topic comes from a recent post to the Code4Lib mailing list. A library is planning to scan a batch of archival documents to PDF format, and are looking for ways to automate the process of identifying personally identifiable information [PII] in the documents and redacting said PII. The person mentioned that the documents might contain Social Security Numbers or credit card numbers.

Many libraries and archives have resources – digital and physical – that contain some form of PII in the source. While physical resources can be restricted to specific physical locations (unless someone copies the source via copier, pencil and paper, camera, etc.), digital resources that are available through a digital repository can increase the risk of privacy harm if that digital resource contains unredacted PII.

When libraries and archives are incorporating personal collections, research data sets, or other resources that may contain PII, here are some considerations to keep in mind to help through the process of mitigating the risk of data breaches and other privacy harms:

Who is included or mentioned in the resource – Some archival collections contain PII surrounding the individual who donated their materials. When dealing with institutional/educational records or research data sets, however, you might be dealing with different types of PII regulations and policies depending on who is included in the resource and what type of PII is present.

What PII is in the resource – When most folks think about PII, they think about information about a person: name, Social Security number, financial information, addresses, and so on. What tends to be overlooked is PII that is information about an activity surrounding a person that could identify that person. Think library checkout histories, web search histories, and purchase history. You will need to decide what types of PII needs redacting, but keep both facets of PII in mind when deciding.

What is the redaction workflow – This gets into the question from the mailing list. The workflow of redacting PII depends on several factors, including what PII needs to be redacted, the number of resources needing to be redacted, and what format the resource is in. Integrating redaction into a digitization or intake workflow reduces the time spent retroactively redacting PII by staff. Here I’d like to offer a word of caution – while automating workflows for efficiency can be positive, sub-optimizing a part of a workflow can lead to a less efficient overall workflow as well as have negative effects on work quality or resources.

What tools and resources are available – While looking at the overall workflow for redacting PII, the available resources and knowledge available to you as an organization to build and maintain a redaction workflow will greatly shape said workflow, or even the ability to redact PII in a systematic manner. There are many commercial tools that automate data classification and redaction workflows, and there are options to “roll your own” identification and redaction tool using various programming languages and regular expressions. If you work at a library or archive that is part of a bigger institution, there might be tools or resources already available through central IT or through departments that oversee compliance or information security and privacy. Don’t be afraid to reach out to these folks!

If you’re wondering where to begin or what other organizations approach redaction, here are a few resources, here are some resources to start with: