Ex Libris Security
Ex Libris is committed to providing its customers with a highly secure and reliable environment for its hosting and cloud-based applications. It has therefore developed a multi-tiered security model that covers all aspects of hosting and cloud-based Ex Libris systems. The security model and controls are based on international protocols, standards, and industry best practices, such as ISO/IEC 27001, the standard for information security management systems (ISMS).
To learn more about our security policy and its related processes and policies, read our security policy.
Cookies
Session cookies are used to manage session lifecycles and the login flow. For more information about Ex Libris cookies, see Cookie Policy
User Consent for Cookies
In August and September of 2023, we are gradually introducing a new feature in Alma and all our higher-education back-office products that requests user consent for the use of cookies. Your daily activities and Alma functionality will remain unaffected regardless of your cookie preferences.
At the beginning of your session, when using Alma and other back-office solutions, a OneTrust banner is displayed. This banner requests your consent to use cookies in our products.
Once you consent, the OneTrust banner is no longer displayed during subsequent sessions, offering a streamlined user experience. We believe that by allowing you to control your cookie preferences, we enhance transparency and enable you to make choices that align with your privacy preferences. Should you wish to update your preferences at any time, you can do so on the new Cookies Settings page within the user preferences area.
We value your privacy and strive to provide a secure environment for your data. Should you have any questions or concerns, contact our support team.
Data Privacy FAQs
Are there specific anonymization jobs in Alma Analytics?
The Alma Analytics database is populated with ongoing feeds from Alma’s operational database. This process is referred to as ETL: Extract, Transfer and Load. The data in Analytics is an exact reflection of the operational data that is used in Alma. Therefore, data that is anonymized in Alma is reportable in Analytics only in an anonymized format. Alma runs anonymization jobs on the following data elements:
- Loans
- Fines & Fees
- Requests
- Resource Sharing Requests
When any of these records is anonymized, the link between the relevant record and the borrowing patron is permanently removed from the system—that is, it is not restorable in any way. Consequently, any interface that shows information about the loan borrower will have no history information to display.
Does Alma support retention periods for anonymized loan records?
Retaining history information in the system is very useful for auditing purposes. At time, libraries need refer to historical actions, such as loans, requests or fees, to be able to analyze issues of interest, such as what happened to a lost item or how a fee has been handled. An additional need for retaining historical information may be related to being able to extract statistical information, such as how many loans of a given type have been processed in a given period of time, or how many requests have been canceled.
In order to fulfill these requirements, Alma retains history records for fulfillment actions indefinitely. Having these records remain reportable in Analytics is essential to be able to meet the above listed requirements. However, the retaining of full historical information may create a privacy challenge. Many libraries have to abide to strict privacy regulations that forbid storing patron information that is not essential for a patron service. The indefinite storing of fulfillment information is a breach of these regulations.
The Alma process of anonymization is aimed at fulfilling both of these conflicting requirements. It strips relevant fulfillment records of their patron personal information where that information is not required for a current patron service, while retaining enough information to be able to meet the auditing and reporting requirements of the libraries.
Which historical loan records are anonymized?
All historical loan records that meet the following criteria are anonymized:
- The loan has been returned. Lost or claimed returned loans are considered active and are not anonymized.
- The loan has no associated active fees. If there are associated fines—such as lost loan or overdue item fines that are linked to the loan—and the fines have not been fully paid, the loan is not anonymized.
- The loan meets any criteria defined in the Loan Anonymization Rules (see Configuring Anonymization).
When a loan record is anonymized, the link between the loan record and the borrowing patron is permanently removed from the system—that is, it is not restorable in any way. Consequently, any interface that shows information about the borrower of a loan has no history information to display. This includes:
- Returns list in Manage Patron Services
- Loan history in Primo My Account
- History tab in the Item Editor screen, when filtered to view fulfillment history
The loan record includes additional statistical information about the borrower, including:
- User Type
- User Group
- Job Title
- User Statistics 1
- User Statistics 2
- User Statistics 3
- User Statistics 4
- User Statistics 5
This statistical information remains on the loan record and is not lost during the anonymous process.
Which historical fines and fees records are anonymized?
All historical fine and fee records that meet the following criteria are anonymized:
- Fines and fees that have been fully paid.
- Fines and fees that have been fully waived.
- Fines and fees that have been closed by a bursar export.
When a fine/fee record is anonymized, the link between the loan record and the patron is permanently removed from the system—that is, it is not restorable in any way. Consequently, any interface that shows information about the patron owing the fine/fee has no history information to display. This includes:
- The patron's list of fines and fees in the User Edit form
The fine/fee record includes additional statistical information about the patron, including:
- User Group
- User Statistics 1
- User Statistics 2
- User Statistics 3
- User Statistics 4
- User Statistics 5
This statistical information remains on the fine/fee record and is not lost during the anonymous process.
Which historical requests are anonymized?
All historical requests that meet the following criteria are anonymized:
- Requests that have been fulfilled.
- Requests that have been canceled.
When a request is anonymized, the link between the record and the patron is permanently removed from the system—that is, it is not restorable in any way. The requester ID is set to NULL therefore hiding the requester ID from the request history. This is the default behavior, as determined by the should_anonymize_requests. If existing completed requests have not yet been anonymized, they are also anonymized retroactively. For more information, see
Configuring Other Settings.
The record includes statistical information about the patron, including:
- User Group
- User Statistics 1
- User Statistics 2
- User Statistics 3
- User Statistics 4
- User Statistics 5
This statistical information remains on the request record and is not lost during the anonymous process.
Which resource sharing borrowing requests are anonymized?
All historical resource sharing borrowing requests that meet the following criteria are anonymized:
- Request has been canceled by a staff member.
- Request has been canceled by the patron.
- Request has been rejected by the lender.
- Request has been fulfilled and returned to the lender.
- Request has been removed.
- Removed requests are not automatically anonymized when removed. Their anonymization depends on the job configuration.
Anonymizing resource sharing requests may affect:
-
Borrowing Requests - removing the link between the requester and the patron record.
-
Lending Requests - When ISO requests are used, patron information may be included in the request information sent to the lender, per the partner record configuration. The requester information is stored on the request’s note on the lending request. This information is also anonymized by the job.
When a resource sharing request is anonymized, the link between the record and the patron is permanently removed from the system—that is, it is not restorable in any way. Consequently, any interface that shows information about the requesting patron will have no history information to display. This includes:
- List of borrowing requests
- Edit form of borrowing request
- Lending request notes
The borrowing resource sharing record includes additional statistical information about the patron, including:
- User Group
- User Statistics 1
- User Statistics 2
- User Statistics 3
- User Statistics 4
- User Statistics 5
This statistical information remains on the borrowing resource sharing request record and is not lost during the anonymous process.
Which personal data, if any, is stored in Alma Analytics?
The Alma Analytics database is populated with ongoing feeds from Alma’s operational database. Therefore, Analytics can report on the user data that is stored in Alma. This includes:
- Addresses
- Phone Numbers
- Emails
- Identifiers
- Blocks
- Notes
- Roles
- Campus Details
- User Statistics
When the anonymization processes are run, the data elements above are stripped from any user information. All that remains reportable is statistical information. This includes user group information and user statistical categories.
- Alma requires one unique ID to enable the linkage between the Alma user record and the institutional student information system. This may be any unique ID, not necessarily the patron barcode.
- Other data elements are not required, but where they are defined, they are used by the system to provide library services. For example:
- Email address is not mandatory but is used by Alma to enable the sending of library notices, such as overdue letters and courtesy notices. If there is no email in the system, Alma cannot send these notices.
- Phone number is not mandatory, but is used by Alma to send SMS messages to the patron. If there is no phone number in the system, Alma cannot send these SMS messages.
- Additional identifiers are not mandatory, but may be used by Alma where they are defined to facilitate links to other integrated systems, such as a bursar system.
- User group indication is used to facilitate fulfillment rules. The fulfillment rules are based on the user group, and can be implemented only when user group indications are assigned to the user record.
- Alma does not store photos. Rather, they are stored on a customer server on the library's premises. For more information, see photo_server_url.
How are Alma anonymization jobs configured? What are their results?
Alma automatically anonymizes all completed hold requests. Other elements’ anonymization may be activated or deactivated. You can define this on the Fulfillment Jobs Configuration page. For more information, see
Configuring Anonymization.
- Loans – Anonymizing loans will cause a completed loan (i.e., a returned loan) to have its link to the borrower removed from the system. This is a database removal action that is not reversible. Loans anonymization rules can be further refined in the Loan Anonymization Rule Editor (see Loan Anonymization Rules). By default, loans are not anonymized if items are:
- marked Lost but not checked in/deleted.
- marked Claimed Returned but not checked in/deleted.
- linked to fees that are still in process. The loan will be anonymized only after all attached fees are closed.
Anonymized loans are reportable by statistical dimensions such as user statistical categories and user group.
- Fines and Fees – Fines and Fees are anonymized only after fully closed—that is, fully paid, waived or extracted to the bursar. The link to the patron is removed from the Fine/Fee. This is a database removal action that is not reversible. Anonymized fines/fees are reportable by statistical dimensions such as user statistical categories and user group.
- Borrowing and Lending Resource Sharing Requests – Resource sharing requests are anonymized only after their complete lifecycle, for example when the item has been checked back in. The link to the patron record is removed from the request. This is a database removal action that is not reversible. Anonymized resource sharing requests are reportable by statistical dimensions such as user statistical categories and user group.
What is the impact of anonymization on reporting?
The anonymization process strips relevant fulfillment records of their patron personal information where that information is not required for a current patron service (that is, the record is a historical record), while retaining enough information to be able to meet the auditing and reporting requirements of the libraries. The relevant entities (loans, fees, requests and resource sharing requests) remain fully reportable, but without any information on the linked patron record other than statistical information based on the user’s user group and statistical categories.
Anonymized records have no link to any details of the patron, but remain reportable by statistical dimensions such as user statistical categories and user group.
Which (closed) transactions are anonymized?
- Loans
- Reservations
- Fees
- Resource sharing requests
- Logging information - Logging information results from batch jobs or processes that include sensitive data (for example, login tries). Log iles with sensitive data can only be accessed by Ex Libris. Jobs information is irreversibly removed from the system a year after it has been created.
- E-Mails - Emails remain attached to the user record. When the user record is purged from the system, all attached information is purged, including the attached emails. Purging of user data is fully controlled by the library.
Is it possible to activate the anonymization of closed resource sharing requests, loans, fees and overdue fees procedures separately?
Yes. Anonymization is configured on the Fulfillment Jobs Configuration page (Configuration Menu > Fulfillment > General > Fulfillment Jobs Configuration).
Fulfillment Jobs Configuration
As is evident from this screen, the library may decide which element to anonymize, independently of any other element that may be anonymized.
Is it possible to anonymize or delete sent emails? If yes, please explain.
By default, letters sent by Alma are retained indefinitely and available on the
Attachments tab of the User Details. When the user record is purged from the system, all attached information, including the attached emails, is purged. You may also define a letter retention policy to delete sent letters after a certain number of days. See
Setting Letter Retention Periods.
How are hold requests managed in the context of anonymization?
Anonymizing of hold requests may be switched off by using the should_anonymize_requests parameter (Fulfillment > Fulfillment Configuration > Configuration Menu > General > Other Settings). If this parameter is set to true (the default option), when a request is added to the request history, the requester ID does not appear in the history details (it will be null). If this parameter is set to false, the requester ID is visible.
How is the ETL process affected by anonymization?
The Alma Analytics database is populated by ongoing feeds from Alma’s operational database. This process is referred to as ETL – Extract, Transfer and Load. The implication is that all data in Analytics is an exact reflection of the operational data used in Alma. Therefore, data that is anonymized in Alma is reportable in Analytics only in its anonymized format.
Can loans be anonymized based on rules, with sensitivity to different parameters?
You can enable anonymization rules to determine which loans, requests, and fines and fees are anonymized. See
Configuring Anonymization.
Is it true that closed loans with unpaid fees cannot be anonymized?
Yes. Loans with unpaid fees are not anonymized because they still await processing (paying the fines). Keeping them linked to the patron is necessary for functional reasons, such as dispute handling. All Alma libraries are currently using the loans anonymization in this manner.
If data is anonymized, can it enable the user to see historical loans in Primo?
Primo allows patrons to view their historical loans using the List of Historical Loans.
List of Historical Loans
This option relies on Alma retaining the borrower information in the historical loan records. Obviously, this will only be possible if anonymization is not turned on in Alma. Activating anonymization removes all links to the borrower user record from the loan record and prevents the system from being able to link historical data with the patron.
Which type of user data is required in Alma?
Alma requires one unique ID in order to enable the linkage between the Alma user record and the institutional student information system. This may be any unique ID, not necessarily the patron barcode. Other data elements are not required, but where they are defined, they are used by the system to provide library services. For example:
-
Email address is not mandatory but is used by Alma to enable the sending of library notices, such as overdue letters and courtesy notices. If there is no email in the system, Alma cannot send these notices.
-
Phone number is not mandatory, but is used by Alma to send SMS messages to the patron. If there is no phone number in the system, Alma cannot send these SMS messages.
-
Additional identifiers are not mandatory, but may be used by Alma where they are defined to facilitate links to other integrated systems, such as a bursar system.
-
User group indication is used to facilitate fulfillment rules. The fulfillment rules are based on the user group, and can be implemented only when user group indications are assigned to the user record.
What tools does Alma supply for an institution that needs to abide by duty of disclosure?
The vast majority of user information in Alma is imported from the student information system, which serves as the library's primary user information system. All user information may therefore be retrieved from that system. That said, some users may be created in Alma unlinked to any external student information record (for example: visiting researchers, alumni).
All user records in Alma may be exported via Analytics in bulk as per required filters, such as per given user groups. Specific records may be retrieved via APIs based on known IDs. The retrieved information may include fulfillment information such as open loans, fees and requests, or even historical ones if not anonymized.
In addition, Alma supports a range of RESTful APIs that may be used to retrieve that information. Please refer to the
Ex Libris Developer Network for full information about Alma’s user APIs.
Who can access the audit trail report in Alma Analytics?
Any user with an Analytics designer role has access to all Analytics reports. Other users may be granted permission to view specific reports as well.
Does Alma support logging an audit trail of changes?
In Alma, for transactions such as loans, requests and PO lines, an audit trail is displayed in the History tab (see The Alma User Interface - History Tab). For examples, see Managing Patron Services - Viewing Loan History. For cataloging in Metadata Editor, see Versioning. See the table below for a full list of pages for which audit trail is supported.
For entities and transactions beyond the ones described below, Ex Libris retains the creator and last modifier. See The Alma User Interface - Info icon.
Area |
Transaction/Entity |
Page |
Acquisitions |
Purchase Order Line |
Details |
Invoice |
Details |
License |
Details |
Resources Management |
Collection Resource |
Editor |
Bibliographic Record |
Metadata Editor |
Authority Record |
Metadata Editor |
Physical Holdings Record |
Metadata Editor |
Physical Item |
Editor |
Electronic Portfolio |
Editor |
Electronic Service |
Editor |
Electronic Collection |
Editor |
Digital Representation Resource |
Editor |
Fulfillment |
Loan Audit Trail |
Patron Services |
Resource Sharing |
Borrowing Requests |
Details |
Lending Requests |
Details |
Administration |
User |
Details |
Job |
Monitor Jobs |
How can the library get access to logs of activities of Ex Libris employees?
This is done via the login report. The login report shows the login actions of all users for the past 90 days, including those of Ex Libris staff. Users that appear with blank dates have not logged in within the last 3 months. Below is an example of this report:
Staff Login Report
How does Alma monitor unauthorized access to data?
Access to data is limited by Alma to users with appropriate roles only. Users with improper roles cannot use the Alma UI to view restricted data.
An Analytics report shows which user's address and phone information has been viewed and when. See the example below:
Access to Data Report
How does Alma log changes in user data?
User data changes use a similar auditing method as in other areas of the system. The History tab records all changes in the record in a sorted manner, detailing the type of change. Below is an example of a user's history log:
![User History new layout.png](https://knowledge.exlibrisgroup.com/@api/deki/files/86259/User_History_new_layout.png?revision=1)
User Detail Audit Tab
Who in Ex Libris has access to customer data?
According to contracts and procedures, the customer is in full control of the data and Ex Libris is not permitted to perform any transfers to third parties. Ex Libris is permitted to use its global affiliates to perform support services. This access by the Ex Libris affiliates is in accordance to contracts and data protection directives.
What is the retention period of history data?
History records are maintained indefinitely unless requested to be deleted/anonymized. Each institution can decide on the anonymization/retention period according to its needs.
How long are letters sent by Alma retained?