29 Patron Data Privacy

Desired Result

The privacy of patrons’ reading habits has a long history as a library value.  Privacy was added to the Library Bill of Rights in 2019,^[1] and privacy of library circulation records is provided for in nearly all states’ laws.^[2] With eresources, however, privacy legislation has largely not kept up with technology.  Unlike traditional print circulation records, eresources are typically hosted on the vendor’s platform, and the vendor has the ability to track patrons’ use directly.  It is up to the license agreement to ensure that data collection is within the bounds that library patrons expect for their library use, is compliant with all relevant law, and consistent with library values. This should mean that individual users are not directly identifiable by the vendor, and that the vendor is prohibited from re-identifying patrons or selling or misusing usage data.^[3]

Essentials of the Law

The US does not have comprehensive federal privacy legislation.  Instead, state level laws and subject-specific federal legislation provide a patchwork of requirements and protections applicable to libraries and library patrons.  State and federal US regulations that may apply to library data are described below, however it is frequently more helpful to refer to EU privacy law since much of the law that influences privacy terms originates in the EU.

The European General Data Protection Regulation (GDPR)

The EU General Data Protection Regulation (GDPR) is a European Union privacy regulation that has had a far-reaching impact on online privacy, and is relevant to even US-based library eresource negotiations.  GDPR applies to vendors located or doing business in the EU and to companies providing services to an individual located in the EU, or monitoring the behavior of an individual present in the EU.^[4] If you have remote users accessing eresources from European locations, therefore, or are working with an EU-based vendor, GDPR will apply.  Because most eresource vendors do at least some business in the EU, and because excluding EU access is generally not desirable, most eresource vendors are familiar with and capable of complying with GDPR requirements, which also makes it a good standard to ask for, even for institutions with few ties to the EU.

The GDPR provides a broad set of privacy protections for user data: data must be collected for a legitimate purpose that is disclosed to the end user, it must be stored securely, it can only be kept as long as necessary for the specified purpose, and the end user has rights to access, correct, delete, and restrict data about themselves.^[5]  The US and the EU have also negotiated a Data Privacy Framework (EU-US DPF)^[6] that organizations can self-certify into, which provides a set of standards for US businesses that are consistent with EU legal requirements.  Vendors that have certified into the EU-US DPF can be looked up in a central database,^[7] and their compliance with the EU-US DPF terms is enforceable under US law.  The European Commission has also adopted Standard Contractual Clauses (SCCs) that companies can use that provide standardized terms that have been certified to comply with EU requirements.^[8]

The GDPR covers identifiable data relating to an individual (called the “data subject”), including name, ID numbers, location data, or physical, physiological, genetic, mental, economic, cultural or social traits of that individual.^[9]  Data subjects hold a number of rights with respect to their data, including the rights to be informed about data collection, to access data about themselves, correct or erase their personal data or restrict its processing, and to receive interoperable copies of their data.^[10]  Companies complying with GDPR must justify their data collection under one of six specific rationales, which include consent of the data subject, data collection necessary to performance of a contract with the data subject, and the legitimate business interests of the company, and must document those rationales for the data subject, usually in the form of a posted privacy policy.^[11]  Personal data must be handled with appropriate technical and organizational security measures,^[12] data breaches must be disclosed,^[13] and GDPR violations are subject to significant penalties for the company.^[14]

The GDPR also defines the roles involved in processing of regulated personal data: where multiple parties are contracting around the handling of personal data, one party is the “data controller” and the other is the “data processor.” The data controller is ultimately responsible for GDPR compliance, and also determines what data is collected, what the lawful basis for the collection is, and what is done with the data.^[15]  The data processor is bound to only handle the personal data according to the instructions of the controller and cannot use it for any other purpose.^[16]  Understanding the roles of data controller and processor is important for eresource licensing because these terms will frequently come up in GDPR-based privacy clauses and they have significant implications for the handling of library patron data.  Vendors who are seeking to use patron data for their own purposes are likely to assert that they will be the data controller for any patron data anticipated under the contract, whereas a library seeking to minimize the privacy risk to their patrons may prefer that the vendor be a data processor only.

US Privacy Law

In the US, the Federal Trade Commission (FTC) is empowered to bring enforcement actions against for-profit companies that do not comply with their own privacy policies, making companies accountable to their own posted standards.^[17]  An increasing number of states have also enacted comprehensive consumer privacy laws, which impose security requirements and provide consumers in that state with various data rights, along similar lines to those described above for the GDPR.^[18]  These laws will be highly relevant to libraries located in those states, and may also apply to institutions that have ties to or patrons located in those states.^[19]

All fifty states also have protections in place for the confidentiality of library records.^[20]  Most such laws provide confidentiality in relation to state public records laws, and provide that library circulation records maintained by a public library are exempt from public records requests.^[21]  In states that narrowly limit the scope of such laws, they can be of limited relevance to eresources, such as when they are limited to records maintained by the library (rather than a third party, such as a vendor), to print circulation records, or limit public disclosure but not disclosure to third parties or misuse.  In some states and for some institutions, however, they may provide a basis for limiting the patron information that the library shares with the vendor.

Finally, while the US does not have a comprehensive federal privacy law, the US does have federal-level privacy legislation in specific subject areas.  The most likely to be relevant to libraries is the Family Educational Rights and Privacy Act (FERPA).^[22]  FERPA applies to educational institutions that receive funding from the US Department of Education, and will therefore apply to most school and university libraries. FERPA covers records that are directly related to a student and are maintained by the institution or a party acting for the institution.^[23] This is a broad definition and interpretations vary of whether it applies to library records, or records of eresource use.^[24] Libraries at educational institutions should be aware of their institution’s interpretation of FERPA.  An eresource that requires identifying information to authenticate authorized users and also collects usage information could be regulated under FERPA and trigger FERPA requirements, for example.  Those requirements include prior consent from the student or their parent for external disclosure of the information, and the ability of the student or parent to inspect the records, both of which can be difficult to manage for eresources.

Other legislation that may apply in some situations includes the Children’s Online Privacy Protection Act (COPPA), which applies to the collection of information about children 13 years of age or younger.^[25]  Libraries with younger patrons should be aware of COPPA and its effect in eresource negotiations.  Among other requirements, COPPA requires website operators to obtain parental consent prior to collecting information from children’s online activity.^[26]

Desired Language

The broad patchwork of legal regulation of privacy can be daunting, but it also provides for a lot of potential guidance, and fortunately many of the sources of law follow the same general pattern.  The following model language can be used to provide a clearer understanding of the privacy practices in effect for a given eresource.

The parties hereby agree to the following terms for the protection of Personally Identifiable Information:

• For purposes of this clause, “Personally Identifiable Information,” shall mean any information relating to any identifiable faculty member, student, employee, or other affiliated person of the Licensee (an “Authorized User”), whether directly or indirectly.  In particular Personally Identifiable Information includes: names, identification numbers including student or employee IDs, social security numbers, driver’s license numbers, credit card numbers, bank account numbers, passport numbers, any other identification number, email addresses, contact information including address and telephone number, location data, IP addresses, dates of birth, accessibility status, an online identifier, financial information, transaction logs, one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person, students’ education records as that term is defined by The Family Educational Rights and Privacy Act (FERPA) (20 U.S.C. § 1232g; 34 CFR Part 99), and any other information that could potentially be linked back to an identifiable individual.

• The Licensee’s privacy policy is available at [link], and shall apply to the parties and Authorized Users under this Agreement.

• Licensor shall not use, and not allow the use of, Personally Identifiable Information for any purpose other than the  performance of services for Licensee and Authorized Users, and shall limit access to Personally Identifiable Information to Licensor’s employees and contractors who have a specific need for such access in order to perform services under the Agreement.

• Licensor shall provide clear notice to Authorized Users prior to data collection.

• Licensor shall cause all Personally Identifiable Information to be encrypted when in storage and when transmitted, and shall ensure that all systems in which such information is stored are maintained according to reasonable, current security standards.

• Licensor shall ensure that Personally Identifiable Information is deleted from Licensor’s systems on a reasonable, regular basis, or as communicated by the Licensee from time to time, and that all such data shall be deleted upon termination of the Agreement.

• With respect to any Personally Identifiable Information which constitutes students’ education records as that term is defined by The Family Educational Rights and Privacy Act (FERPA) (20 U.S.C. § 1232g; 34 CFR Part 99), Licensor acknowledges that Licensee has a statutory duty to maintain the privacy of such records, that Licensor is performing an institutional service for which Licensee would otherwise use Licensee employees, and that Licensor will comply with all applicable FERPA requirements governing the use and redisclosure of Personally Identifiable Information from education records, including without limitation the requirements of 34 CFR §99.33(a).

• Licensor shall reasonably assist Licensee as necessary in complying with requests from an Authorized User to retrieve, delete, or amend any Personally Identifiable Information relating to that Authorized User within Licensor’s systems.

• Licensor shall promptly notify Licensee of any event that creates a substantial risk of unauthorized acquisition or use of Personally Identifiable Information or of other harm to any person whose Personally Identifiable Information is involved in the event, and reasonably cooperate with Licensee in the remediation of such event.

• Licensor shall enforce and be responsible for compliance by all its employees and contractors with the requirements of this Amendment and all confidentiality obligations to Licensee and Authorized Users.

• The provisions of this clause shall survive the termination of the Agreement.^[27]

Tricks and Traps

Your institution’s needs and obligations around user privacy will vary.  All libraries share a commitment to reader privacy, but specific obligations may additionally apply based on jurisdiction, and governmental status or funding.  You should familiarize yourself with the privacy law in your jurisdiction and your institution’s policies.

Privacy concerns will also vary between different products and access methods.  For an eresource with an access method based on IP filtering, for example, the amount of identifying data available for the vendor to collect can be minimal: an IP address and timestamp.  That information doesn’t directly identify an individual but can become identifying when combined with other log information.^[28]  In this example, it may make more sense to focus privacy language on prohibiting re-identification of individuals, combination of use data with other data sets, and external data use.  Increasingly, however, vendors are requesting more personal information in order to provide access to eresources.  This can include requiring users to register with their name and email address, or providing an optional registration in order to access additional features.^[29]  Many forms of two-factor authentication also share more personal information with the vendor than you might expect.  The InCommon Research & Scholarship Category, which provides standards for federated access to eresources for most libraries, for example, requires that participants release ID attributes including name and email address for eresource authentication.^[30]  The attributes used to identify a patron as an authorized user can be an anonymous unique ID number, but many vendors configure access to require identifying information.  This requires the library to release directly identifying patron information to a third-party, in a way which is not transparent or visible to the patron.  Worse, the identifying information when combined with reading history and usage logs could reveal unpublished research directions or constitute a student educational record under FERPA.^[31]  Additional caution should be taken when personal information will be directly released to the vendor, and should be reflected in the contract terms between the parties.

Negotiating within the larger privacy context

Because user privacy is, at least in some jurisdictions, a heavily regulated space, many eresource vendors will have already spent considerable time and resources developing their own privacy practices and policies.  In general this is a good thing, and will mean that the vendor will have the technical and organizational infrastructure in place to protect user privacy, at least to the extent to which they are legally required.  It also, however, results in a very common tendency in vendor-provided eresource contracts, to try to rely on privacy terms outside of the four corners of the contract.  Frequently this takes the form of a link to the vendor’s privacy policy.  This should be resisted for a couple of reasons.  First, it’s generally undesirable to have important provisions controlled through outside documents.  The content of the vendor’s privacy policy can be changed unilaterally by the vendor, frequently without notice or input, which does not provide a clear or stable understanding of the terms for the library.  Second, and more importantly, however, the vendor’s privacy policy may not do what you need it to do.  Privacy policies serve multiple functions including compliance with mandatory disclosures and may address multiple products, services and platforms, and can be resultantly vague, disclosing many (possibly alarming) types of personal information that “may” be collected without providing any specificity about what will apply in the specific circumstances of the eresource contract.^[32]  The goal of an eresource privacy clause should be to establish a clear baseline of privacy protections that will apply to Authorized Users of the licensed content, which is frequently not possible to determine just from reviewing the vendor’s privacy policy.

The model language above provides concrete baseline terms for the handling of patron data.  A good way to approach it is to start from something like this model language, and ask the vendor to review it as compared to their current practices.  It can be a hard sell to ask a vendor to change an aspect of their data security, however if they can adjust your language to match their practices (and their practices meet your requirements), that can become a mutually agreeable part of the contract.  The model language above also includes a link to the library’s privacy policy.  If you have a robust privacy policy that describes your standard practices with regard to licensed eresources, this can be another way to reinforce your desired baseline.  It can also be a useful negotiating chip – both parties want the privacy terms to be controlled by their own privacy policy, so perhaps the reasonable thing to do is to remove references to either.

External privacy policies can also raise difficulties when the library is either subject to different legal requirements than the vendor, or is not subject to strong legal requirements but wants to provide strong user protections anyway.  If you are in the latter situation, be cautious of language that limits obligations “to the extent required by law,” which may be under-inclusive of your goals.  Many privacy policies that are designed for GDPR compliance, for example, will disclose to users a list of user privacy rights, but will not guarantee that they are available to all users, saying something like “Under the legislation applicable to you, you may be entitled to exercise some or all of the following rights.”^[33]  Companies can be held accountable to the promises they make in their privacy policies^[34] so they generally do not want to promise anything in them beyond the minimum legal requirements that they can be held to.  If the library wants to be able to provide a uniform set of privacy rights for their patrons, regardless of whether they are EU or California data citizens, for example, that needs to be done in the contract rather than relying on an external privacy policy.

Some vendors will also have more extensive privacy contract language available, such as a standard Data Processing Agreement (DPA),^[35] or a template incorporating the EU Standard Contractual Clauses (SCCs),^[36] which you may be able to use or adapt for your contract.  You should review any such language to ensure that it meets the needs and obligations of your institution.  Keep in mind that SCCs will generally not be negotiable, but additional contract language could be added to fill any gaps between GDPR compliance and the library’s needs.  An additional point of contention when dealing with GDPR-based privacy terms is who, between the parties, is the data controller, and who is the data processor.  In general, a vendor who wants to be the data controller wants to be able to use the data for purposes outside of the uses contemplated in the contract.

An additional issue that may come up occasionally is the responsibility between the parties for compliance with the Children’s Online Privacy Protection Act (COPPA).^[37]  COPPA will generally not be referenced directly by name, however if you see a reference to “children 13 years of age or younger” in a contract with a US-based company, that is a strong tell that COPPA compliance is at issue.  Many companies do not maintain COPPA-compliant infrastructure, and instead use terms of use to prohibit use of their services by the population covered by COPPA (children under 14) without parental consent.^[38]  In an eresource contract, that may translate into passing the buck by attempting to require the library to warrant that parental consent has been obtained.  Since this is likely to be impossible for the library to accomplish, this language should be resisted.

Informing your users about the privacy terms

Online privacy is complicated, and communicating to your end users about their rights, negotiated protections, and exceptions to those negotiated protections can also be complicated.  Standardized privacy language is beneficial in this regard because it allows you to provide a standard set of expectations for end users when using library resources.  It’s generally advisable to explain your standard terms in a library privacy policy.  Equally, if not more important, if you agree to privacy terms that do not match your standard terms, those should be disclosed to patrons in the library’s own privacy policy.

Importance and Risk

Privacy is a long-held value of libraries, as well as an area with regulatory oversight which may or may not affect your library.  Prior to negotiating privacy terms, you should familiarize yourself with the laws that directly apply to your institution,^[39] and incorporate any specific requirements into your desired contract language.  Libraries generally have a lot of public trust in their privacy standards, which should translate into corresponding care taken around patron privacy.

There are several threat models to consider when assessing the risk associated with user privacy terms.  The first is compliance risk, where the library may be held accountable by a regulatory agency or an individual for compliance with applicable laws. Libraries are, perhaps, an unlikely target for enforcement of privacy laws, but the consequences of an enforcement action can be large^[40] and should be taken seriously.  With respect to eresources, this is largely covered by ensuring that vendors are held to the same standards legally applicable to the library.

The second, and most prominent, threat model for privacy risk for eresource contracts is the risk that the eresource vendor themselves will misuse the personal information of library patrons.  Some eresource vendors increasingly position themselves as “data analytics” providers,^[41] and have an interest in aggregating data about users for their own purposes.^[42]  For most of the 20th century, the legal threat model of most concern to librarians was use of library records for government surveillance.^[43]  In more recent years, corporate and commercial surveillance have increasingly been the subject of concern,^[44] with the added note that corporate surveillance records can then be obtained by the government for government surveillance.^[45]  The most prominent recent example of this is the boycotts and protests surrounding LexisNexis.^[46]  LexisNexis provides both highly used legal databases which are a standard product in many libraries and data brokering services selling packages of personal data to government agencies and law enforcement.^[47]  LexisNexis has a contract supplying a database of personal information to the U.S. Immigration and Customs Enforcement (“ICE”), which has led to protests and calls for universities to cancel their LexisNexis contracts.^[48] That the same companies that handle patron data are also aggregating dossiers of personal information to sell to law enforcement should give us pause, and a good reason to negotiate strong protections around the use of patron data via our contracts.

A third threat model that privacy language should consider is threats from third-party bad actors.  While it may also seem like libraries are an unlikely target for cybersecurity threats, the 2023 British Library cyberattack, in which British Library services were disrupted and personal data held for ransom before being publicly sold,^[49] demonstrates that threats exist and can be extensive.  Risks can be minimized by limiting the amount of personal information shared with eresource vendors, and negotiating privacy terms that require vendors to maintain sufficient security measures.