Statement on Processing of Customer Data for Cloud Services

This Statement on Processing of Customer Data for Liferay Cloud Services (the “Statement”) describes how Liferay, Inc., Liferay International Limited or one of its respective affiliates (the applicable entity referred to as “Liferay” ) process information, relating to an identified or identifiable natural person, where an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person (“Personal Data”) submitted by an authorized user (“Customer”) to Liferay through the use of certain Liferay hosted services and applications (the “Services”), on Customer's behalf.

Liferay will process the Personal Data only as set forth in this Statement, only for purposes set forth in this Statement, subject to the confidentiality and other relevant terms of Customer’s agreement with Liferay governing the provision of the applicable Services by Liferay to Customer, and, if applicable, in accordance with the applicable data protection addendum.
 
Liferay reserves the right to update this Statement from time to time by posting an updated version. Liferay encourages Customer to check this page for updates regularly, in particular, before Customer starts using any kind of additional Liferay Services offering Liferay might introduce in the future. Customer’s continued use of and access to the Services signifies Customer’s acceptance of the updated Statement. Notwithstanding the aforesaid, Liferay will notify Customer of any updates of this statement separately, if and as might be required under a written agreement between Customer and Liferay.

In addition to the Subprocessors listed above, for purposes of Liferay Analytics Cloud Liferay also relies on the following Subprocessors:

Within the scope of Customer’s use of the Services, Customer may submit Personal Data to the Services. The extent, categories, and types of such Personal Data that Customer submits to the Services is fully controlled and determined by Customer and may vary depending on Customer’s individual use of the Services.
Liferay anticipates that such Personal Data may, for example, include Personal Data of the following categories of data subjects:

• employees, agents, advisors, contractors of the Customer and Customer Affiliates.  
• Employees, agents, advisors and contractors of Customer’s and Customer’s Affiliates’ prospects, customers, business partners, vendors.

Liferay anticipates that such Personal Data may, for example, include, the following types of Personal Data:

• First and last name
• Gender
• Title
• Position
• Company
• Private or professional Email
• Phone number
• Business or private address
• Further contact information, such as e. g. Skype ID
• Geo-localization data
• Language preferences
• IP addresses
• Access data
• Usage data
• Authorization data
• Other use case specific data, such as posts, documents transmitted, contract or invoice data, etc.

Liferay takes the following security measures to process Personal Data submitted by Customer to the Services, as certified by the SOC 2 Type 2 and ISO 27001: 2013 compliance report available upon request, and assures that any sub-processors utilized by Liferay provide for at least the same level of protection:

• Office Space: Access to Liferay’s  office space is physically secured through a badge management system, lockdown procedures, and access monitoring.
• Passwords and Credentials:  Not only are the systems protected from inappropriate access by employees involved in the performance of the Service ("Team Members”), but also from unwanted access from non-Team Members. For this reason, all Team Members are obliged  to use strong and protected credentials.
• Password Protection:  All Team Members are obliged to use a password management system, verified by Liferay’s  committee for security and dependability (“Security Committee”). All Services related account credentials must be stored in this password management system.
• Automatic blocking is enabled on all personal machines and internal systems.
• Multi-Factor Authentication (MFA): Wherever possible, MFA is enforced, and even mandatory, on all system accounts. If MFA is not possible, accounts must authenticate through a third-party account that provides MFA (e.g. Google, GitHub). If neither of these options are possible and only basic authentication is available (e.g. computer login), the account password must follow strict standards.
• Encryption: All private and restricted data is encrypted at rest using AES-256. All data is encrypted at rest and in transit.
• Need to Know: Individuals are prohibited from accessing information they otherwise would not have a need to know, unless required to do so in the performance of specific authorized tasks. Security Committee  revokes any unnecessary access when it does not comply with this policy.
• User Roles: Access control privileges to systems are assigned to users via user roles wherever possible and practical. Roles are established based upon department and job function and are reviewed and updated when job or departmental functions change.
• Review of Administrator Access: When a change to an individual’s access privileges is needed, they must contact the Security Committee. Then, at least one of the members of the Security Committee will review the individual's role and make system changes to grant or maintain access. The Security Committee must review all systems and all individuals’ administrator access according to the Compliance Monitoring Policy.
• Group Credentials: Whenever possible, no administrator access is given in the form of a group account, that is, one credential that validates multiple individuals. This way of authentication provides no way of monitoring individual access and introduces risks from shared passwords and tokens. If a system requires this type of authentication, the password or token is changed when an individual is removed from the group.
• All direct access to servers via SSH will be connected through a Bastion Host solution to prevent brute force attacks. All SSH activity is being logged and kept forever. Only members who must have access,  may have access. All Security Policies also apply to remote access situations. All credentials must be compliant with the Access Control Policy.
• Customers' databases are segregated in their own virtual machines and every project environment is segregated on it's own private network.
• No production data is used in any development environment.
• Individuals are prohibited from accessing information they otherwise would not have a need to know, unless required to do so in the performance of specific authorized tasks.
• It is the Security Committee’s responsibility to revoke any unnecessary access when it does not comply with this policy.
• All data in transit uses enforced TLS connections with minimum AES-256 encryption.
• All requests are signed by the request actor in the form of user access token or ID.
• All server and database history is logged and retained forever.
• All document creation, changes, and deletion are kept in recorded logs. These logs are retained for 6 months and protected against unauthorized tampering by secure redundancy and access controls.
• For the system infrastructure, backup routines are run every 30 minutes, all backups are replicated in different regions, encrypted at rest, and permanently retained. For Personal Data, backup routines are run by default every day and retained for 30 days. All backups are replicated in different regions and encrypted at rest.
• Firewall configurations provide rugged inbound/outbound rules that are tested annually by internal/external penetration testing.
• System availability is monitored and reported according to Liferay’s System Availability Policy.
• A disaster recovery plan is in place, documented and tested regularly.
• In the event where an incident requires a full disaster recovery, the entire infrastructure can be brought back online within 2 hours.
• The screens of Liferay employee computers are always locked when left unattended; Personal Data is not shared informally; Personal Data is not saved to personal computers.
• All incidents are promoted immediately to the Security Committee and logged in an incident registry and graded by impact. Incidents are treated by priority and a post mortem root cause analysis is completed by the Security Committee regarding every incident.
• All systems are built to provide adequate pseudonymisation and data protection to not risk their availability, confidentiality, or integrity.