Data Processing Agreement

Last updated: October 2, 2026

This Data Processing Agreement (“DPA”) forms part of the agreement between Lyra Library LLC (“Lyra”) and the school, school district, diocese, educational institution, or other person or entity that has subscribed to Lyra’s services (the “Customer”). It governs Lyra’s handling of personal information about students, teachers, and other library patrons that the Customer makes available to Lyra in connection with the Lyra service.

This DPA is incorporated by reference into Lyra’s Terms of Service. By subscribing to Lyra, the Customer agrees to this DPA. A Customer that requires a countersigned copy may request one at support@lyralibrary.com; the text will be the same.

Lyra’s posted Terms are designed for self-service subscriptions and private educational customers. Public schools, school districts, state education agencies, and other government entities may be required to use separate procurement terms, and Lyra is not bound by any customer purchase-order, procurement, or government terms unless Lyra expressly agrees to them in a signed writing.

1. Background and roles

1.1 The service. Lyra provides a cloud-based library management system that allows the Customer’s library staff to manage the Customer’s library collection and circulation activities. To operate the service, the Customer uploads or enters records about its library patrons — primarily students and teachers — into Lyra.

1.2 The Customer is the controller. As between Lyra and the Customer, Customer determines which patrons to enroll, what information to provide about them, and how the library service is configured. Lyra acts on Customer’s behalf and under Customer’s instructions. Where Customer is a school or other educational institution, Customer is the controller, covered entity, and educational agency or institution with respect to patron data. Where Customer is not a school or educational institution, Customer is responsible for having all rights, authority, notices, and consents necessary for Lyra to process patron data as described in this DPA.

1.3 Lyra’s role. With respect to patron data, Lyra acts as Customer’s service provider and processor under applicable student privacy and consumer privacy laws. Where Customer is a school or other educational institution that may designate Lyra as a school official, Lyra also acts as a school official with legitimate educational interests under the Family Educational Rights and Privacy Act (“FERPA”), 34 CFR § 99.31(a)(1)(i)(B), performing services for which the Customer would otherwise use its own employees. Where Customer is authorized to provide consent under COPPA’s school-consent framework, Lyra acts as Customer’s agent for that purpose, acting only as needed to provide the library service Customer has authorized.

1.4 The Customer’s authority. The Customer represents that it has the authority to provide patron data to Lyra and to authorize Lyra’s processing under FERPA, COPPA, applicable state student privacy laws, and other applicable laws. Customer is responsible for providing any notices to parents, guardians, patrons, and other individuals, and for obtaining any consents or permissions, that the law requires Customer to provide or obtain. If Customer is not a school or educational institution, Customer may not rely on Lyra’s FERPA school-official or COPPA school-consent language as a substitute for any parent, guardian, or individual consent Customer is required to obtain.

2. Definitions

Capitalized terms used but not defined in this DPA have the meanings given in the Terms of Service. The following additional definitions apply:

• “Education Record” has the meaning given in FERPA, 34 CFR § 99.3, and includes records that contain personally identifiable information about a student and are maintained by Lyra on behalf of the Customer.
• “Patron Data” means personal information about library patrons (including students, teachers, and other authorized users of the Customer’s library) that the Customer makes available to Lyra in connection with the service, including records the Customer uploads or enters, records generated through patron activity in the service (such as checkouts, holds, and search history), and records derived from those.
• “Patron” means a student, teacher, or other person whose library activity is managed in Lyra on behalf of the Customer.
• “Personally Identifiable Information” or “PII” has the meaning given in FERPA, 34 CFR § 99.3.
• “Security Incident” means a confirmed unauthorized access to, acquisition of, disclosure of, or loss of Patron Data while in Lyra’s custody. Unsuccessful attempts and routine security events that do not result in unauthorized access (such as pings, port scans, denial-of-service attempts, and failed login attempts) are not Security Incidents.
• “Subprocessor” means a third party engaged by Lyra to process Patron Data on Lyra’s behalf in connection with providing the service.

3. Scope and purpose of processing

3.1 Permitted purposes. Lyra will process Patron Data only:

• To provide, maintain, secure, and support the Lyra service for the Customer
• To comply with the Customer’s documented instructions, including configuration choices the Customer makes within the service
• To comply with applicable law
• As otherwise expressly permitted by this DPA

3.2 Prohibited uses. Lyra will not:

• Sell Patron Data
• Use Patron Data for targeted advertising or to build profiles of students for non-educational purposes
• Use Patron Data, or any PII derived from Patron Data, to train, fine-tune, or improve artificial intelligence or machine learning models, including models offered to third parties. Lyra may generate catalog embeddings and process catalog text and search queries to provide semantic catalog search, but this processing is not used to train, fine-tune, or improve third-party models. Search queries are transmitted without identifiers attributing them to the person who entered them; Lyra does not filter the text of a query itself.
• Use Patron Data to develop a commercial product or service unrelated to the Lyra service the Customer has subscribed to
• Disclose Patron Data to third parties except as expressly permitted by this DPA

3.3 Aggregated and de-identified data. Lyra may process Patron Data to generate analytics, reports, dashboards, circulation statistics, catalog embeddings, and similar outputs for the benefit of the Customer within the service. Lyra does not sell Patron Data, does not build cross-customer benchmarking datasets from Patron Data, and does not retain de-identified or aggregated student datasets for Lyra’s own research, marketing, external reporting, or product-improvement purposes after the associated Patron Data has been deleted. To the extent Lyra creates de-identified data, de-identification will be performed in accordance with the standards in FERPA, 34 CFR § 99.31(b), and Lyra will not attempt to re-identify it.

3.4 Customer instructions. Customer’s documented instructions include the configuration choices, administrator actions, imports, integrations, and deletion or export requests Customer makes through the service. Lyra may decline or delay an instruction to the extent Lyra reasonably determines that the instruction is unlawful, technically infeasible, would compromise the security or integrity of the service, or is outside the scope of the contracted service.

4. Categories of data and patrons

4.1 Categories of Patron Data Lyra processes. Depending on what the Customer chooses to enter and how the Customer configures the service, Patron Data may include:

• Patron identifiers (name, preferred name, patron barcode, internal patron ID)
• Patron contact information (email address, parent or guardian notification email addresses)
• Patron classification (student or teacher status, class year, homeroom assignment, teacher title)
• Authentication information (PIN, if used for student sign-in)
• Library activity (current and historical checkouts, holds, search history within the OPAC, items associated with the patron)
• Policy and account state (circulation policies applied, account flags)

4.2 Categories of patrons. Patron Data describes students and teachers of the Customer. Some students may be under 13 years of age.

4.3 Sensitive data. Lyra is not designed to receive, and the Customer will not provide, Sensitive Data as defined in the Terms of Service (such as Social Security numbers, financial account numbers, government ID numbers, health information regulated by HIPAA, or biometric data). Patron Data as described in Section 4.1 is not Sensitive Data.

5. Security

5.1 Security measures. Lyra will implement and maintain technical and organizational measures appropriate to the nature of Patron Data and the risks of processing, designed to protect Patron Data against unauthorized access, disclosure, alteration, loss, and destruction. These measures include:

• Encryption of Patron Data in transit using TLS
• Encryption of Patron Data at rest in Lyra’s database and storage layers
• Logical separation of each Customer’s Patron Data from that of other Customers, enforced at the database row-level security layer
• Access controls limiting Lyra personnel access to Patron Data to those with a legitimate need
• Audit logging of access to production systems
• Regular review and updating of security practices

5.2 Personnel. Lyra will limit personnel access to Patron Data to individuals with a legitimate need to access it to provide, secure, support, or maintain the service. Lyra will ensure that personnel authorized to access Patron Data are bound by confidentiality obligations consistent with this DPA. Before granting future employees or contractors access to Patron Data, Lyra will conduct commercially reasonable screening appropriate to the role and provide data-handling and security guidance appropriate to the individual’s responsibilities.

5.3 Updates to security measures. Lyra may update its security measures from time to time. Updates will not materially reduce the overall level of protection of Patron Data.

6. Security incidents

6.1 Notification. Lyra will notify the Customer of a Security Incident affecting the Customer’s Patron Data without undue delay, and in any event within seventy-two (72) hours after Lyra confirms the Security Incident.

6.2 Content of notification. The notification will include, to the extent then known: a description of the nature of the Security Incident, the categories and approximate number of patrons and records affected, the likely consequences, and the measures Lyra has taken or proposes to take to address it.

6.3 Investigation and cooperation. Lyra will investigate the Security Incident, take reasonable steps to mitigate its effects and to prevent recurrence, and reasonably cooperate with the Customer in the Customer’s own response, including in providing information the Customer needs to comply with its notification obligations to patrons, parents, regulators, or others.

6.4 No admission. Lyra’s notification of, or response to, a Security Incident is not an acknowledgment of fault or liability.

6.5 Law-enforcement delay. Lyra may delay a Security Incident notification to the extent a law-enforcement agency or regulator determines in writing that notification would impede an investigation, threaten public safety, or otherwise be required to be delayed by law. Lyra will provide the delayed notification as soon as the reason for delay no longer applies or as otherwise permitted by the agency, regulator, or applicable law.

7. Subprocessors

7.1 Authorization. The Customer authorizes Lyra to engage Subprocessors to process Patron Data in connection with providing the service. A current list of Subprocessors is maintained on Lyra’s Subprocessors page.

7.2 Subprocessor obligations. Lyra will:

• Enter into a written agreement with each Subprocessor that imposes data protection obligations no less protective than those in this DPA, as applicable to the Subprocessor’s role
• Remain responsible to the Customer for each Subprocessor’s performance of its obligations

7.3 Changes. Lyra will maintain a current public list of Subprocessors and will update that list when Subprocessors are added, removed, or materially changed. Posting an update to the Subprocessors page constitutes notice of the change. Lyra will use commercially reasonable efforts to post changes at least thirty (30) days before a new Subprocessor begins processing Patron Data, unless the change is required sooner for security, availability, legal compliance, or continuity of service. Customer may contact Lyra with reasonable data-protection concerns about a Subprocessor, and Lyra will work in good faith to address those concerns, but Customer does not have approval or veto rights over Lyra’s use of Subprocessors.

8. Artificial intelligence features

8.1 AI providers as Subprocessors. Lyra uses third-party artificial intelligence providers — currently Anthropic for the Vega conversational analyst feature and call-number suggestions, and OpenAI for embeddings used in semantic catalog search — as Subprocessors. These providers are listed on the Subprocessors page and bound by the obligations in Section 7.

8.2 Data minimization for AI. Lyra’s AI features are designed so that Personally Identifiable Information about patrons is architecturally excluded from the Patron Data that Lyra reads out of the Customer’s records and sends to AI providers. That exclusion is enforced in Lyra’s application code, not solely by policy. It does not extend to free text that a user enters into the service — a staff member’s question to the Vega assistant, or a patron’s catalog search query — which is transmitted to the applicable AI provider as entered. Lyra instructs users not to enter patron-identifying information into these fields, and the Vega assistant is instructed to decline patron-specific questions, but Lyra does not filter user-entered text. The categories of data sent to AI providers, and the categories excluded, are described in Lyra’s AI Privacy page.

8.3 No training on Patron Data. Lyra’s agreements with its AI Subprocessors prohibit the use of Lyra’s API data to train the providers’ models. Lyra will not use Patron Data or patron-identifying information to train, fine-tune, or improve AI or machine-learning models, including models offered to third parties. Catalog embeddings and semantic-search processing are used only to provide search and staff-assistant functionality for the Customer’s library and are not used for model training.

8.4 AI feature controls. An account owner may turn off, for the Customer’s entire account, (a) the features that use Anthropic, including the Vega assistant and model-generated call-number suggestions, and (b) the features that use OpenAI, including semantic catalog search, independently of each other. While a control is off, Lyra sends no Patron Data or other Customer data to the corresponding AI Subprocessor on the Customer’s behalf. Both controls are on unless an account owner turns them off. Data already stored in the service, such as Vega conversations and catalog embeddings, is retained under the Customer’s agreement while a control is off and is used again if the control is turned back on.

9. Assistance to the Customer

9.1 Patron and parent requests. If Lyra receives a request from a patron, parent, or guardian to access, correct, delete, or otherwise act on Patron Data, Lyra will, without acting on the request itself, refer the requester to the Customer and, where the request identifies the Customer, notify the Customer of the request without undue delay.

9.2 Tools for the Customer. Lyra will, through features of the service, provide the Customer with reasonable means to access, correct, export, and delete Patron Data, so the Customer can respond to requests it receives directly from patrons, parents, or others.

9.3 Legal process. If Lyra receives a subpoena, court order, or other legal demand for Patron Data, Lyra will, unless legally prohibited, promptly notify the Customer and reasonably cooperate with the Customer in any effort to object to or limit the disclosure. If Lyra is legally compelled to disclose Patron Data, Lyra will disclose only what is required.

10. Audits and security questionnaires

10.1 Documentation. On the Customer’s reasonable written request and no more than once per twelve (12) month period (except following a Security Incident), Lyra will:

• Make available a summary of its then-current security practices
• Provide a SOC 2 report or comparable third-party assessment if and when one is available
• Respond to a reasonable security questionnaire from the Customer

10.2 No on-site audits. Given the multi-tenant nature of Lyra’s service, the Customer’s audit rights are exercised through the documentation and questionnaire process described in Section 10.1. The Customer does not have the right to inspect Lyra’s facilities or systems directly.

11. International transfers

Lyra and its Subprocessors process Patron Data in the United States. If Lyra adds a Subprocessor that processes Patron Data outside the United States, the change will be handled under Section 7.3, and Lyra will implement transfer mechanisms appropriate to the destination.

12. Return and deletion of Patron Data

12.1 During the Subscription. The Customer may export Patron Data from the service at any time during the Subscription Term using features of the service.

12.2 On termination, expiration or lapse. After termination, expiration, or lapse of a Subscription, Lyra will make Patron Data available for export for thirty (30) days, unless Customer requests earlier deletion. After that export period, Lyra will delete the account and Patron Data from active systems, and will complete deletion within thirty (30) days thereafter. If Customer requests deletion without an export step, Lyra will delete the account and Patron Data from active systems and complete deletion within thirty (30) days after the request, unless retention is required by applicable law.

12.3 Backups and recovery history. Lyra’s production database uses a rolling point-in-time recovery window currently configured for seven (7) days. Patron Data deleted from active systems may remain temporarily recoverable within that rolling recovery window and then ages out automatically. Lyra does not use backup or recovery copies for any purpose other than disaster recovery, and any restored deletion will be re-applied. Backup and recovery copies remain subject to the security and confidentiality obligations of this DPA.

12.4 Legal hold. Lyra may retain Patron Data as required by applicable law, subject to the security and confidentiality obligations of this DPA.

12.5 Deletion confirmation. On Customer’s written request, Lyra will provide written confirmation that the account and Patron Data have been deleted in accordance with this Section 12.

13. Term, modification, and conflicts

13.1 Term. This DPA takes effect when the Customer enters into the Terms of Service and continues until all Patron Data has been deleted or returned in accordance with Section 12.

13.2 Modification. Lyra may update this DPA from time to time. Updates will not materially reduce Lyra’s overall obligations during a then-current Subscription Term. Lyra will notify the Customer of material updates by email or through the service.

13.3 Conflicts. If there is a conflict between this DPA and the Terms of Service with respect to the processing of Patron Data, this DPA controls.

13.4 Survival. Sections that by their nature should survive termination — including Sections 3.2 (Prohibited uses), 6 (Security Incidents) for incidents arising during the term, 9.3 (Legal process), 12 (Return and deletion), and this Section 13 — survive termination or expiration of this DPA.

14. Contact

Questions about this DPA, requests for a countersigned copy, or Subprocessor objections under Section 7.3 should be sent to support@lyralibrary.com.