Optimizely Content Management System

Collect data

Optimizely Content Management System (CMS) Core logs system activities such as events and system errors. From CMS Core 11.4.0, these log files do not include Personally Identifiable Information (PII), such as usernames or IP addresses. See also Collect data.

To be fully GDPR compliant, upgrade to at least CMS version 11.4.0. (See also Why upgrade to CMS 12?) If you cannot upgrade to at least version 11.4.0, as a workaround, you can stop the log files from recording PII by having the episerverlog.config file prevents logging from the following namespaces and levels:

EPiServer.Framework.Web.AspNetAntiForgery –Error
EPiServer.DataAccess.Internal.ContentAclDB – *Info
EPiServer.DataAccess.Internal.ContentSaveDB – Debug
EPiServer.DataAccess.Internal.ContentTypeDB – Info
EPiServer.DataAccess.Internal.DynamicPropertiesDB – Info
EPiServer.DataAccess.Internal.PermissionDB – Info
EPiServer.DataAccess.Internal.PropertyDefinitionDB – Info**

The classes in Internal namespaces could have moved between versions, so the recommended configuration for versions older than 11.4.0 is to prevent logging as:

EPiServer.Framework.Web.AspNetAntiForgery - Error
EPiServer.DataAccess – Info

Ask for consent

Visitor groups

Visitor groups provide a means to personalize content. You can deactivate visitor groups on a per-request basis to reflect brand privacy policy and consent. One option is to react to “do not track” headers, but you should customize it to fit the brand privacy policy. Some built-in visitor groups collect data using cookies with a limited lifetime, but nothing personally identifiable is stored centrally by default, which is the recommended pattern. If you track and store PII using customer visitor group criteria, ensure you have consent first.

Store data

See also Store data and Data guidelines.

Secure data (DXP)

Optimizely Digital Experience Platform (DXP) secures access to stored PII in several ways. Content stored in DXP is encrypted at rest, access to the underlying storage technologies and infrastructure is restricted to Optimizely personnel, and access to the website is secured through the included Web Application Firewall. Most vulnerabilities are usually found in the application layer, so you should run regular scans of sites using the optional Web Vulnerability Scanner or similar technology you choose.

Secure data (CMS)

The CMS relies on the SQL server for most of its storage needs, so you should restrict access to the SQL server and use the built-in encryption capabilities to protect PII data at rest.

CMS Profiles

The built-in profile system does not track PII by default but can be used that way. If you choose to store PII in the profile system, ensure the underlying storage is appropriately protected (encryption, regular vulnerability scanning, and so on) and users represented by the profiles explicitly give that consent.

Fetch data (CMS)

CMS Profiles

The profile system provides the ability to query and update profiles.

Visitor Groups

Unless you have added your own or third-party visitor group criteria, you should not have any PII collected by visitor groups, so there is no data to correct or query here. The visitor can, of course, delete anything stored in cookies by clearing cookies.

Delete data (DXP)

Data deleted from the underlying storage is deallocated and physically deleted through NIST-certified methods. Deallocated data is physically deleted within at most 180 days.