Last updated: Jun 19 2018

Episerver CMS

Collecting data

Episerver CMS Core logs system activities such as events and system errors. From CMS Core 11.4.0, these log file do not include any Personally Identifiable Information (PII), such as usernames or IP addresses.

To be fully GDPR compliant, Episerver recommends you to upgrade to at least version 11.4.0. If you are unable to do so, you can, as a workaround, stop the log files from recording PII by having the episerverlog.config file prevent logging from 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 can have been moved between versions so the recommended config for versions older than 11.4.0 is to prevent logging as:

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

Asking for consent

Visitor groups

Visitor groups provide a means to personalize content but can be disabled on a per-request basis to reflect brand privacy policy and consent. One option is to react to “do not track” headers but should be customized to fit the brand privacy policy. Some of the 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 do track and store PII using customer visitor group criteria, ensure you have consent first.

Storing data

DXC Service

Securing data

The DXC service secures access to stored PII in several ways. All content stored in DXC Service is encrypted at rest, access to the underlying storage technologies and infrastructure is restricted to Episerver personnel, and access to the website is secured through the included Web Application Firewall. Most vulnerabilities are usually found in the application layer, so we strongly recommend running regular scans of all sites using the optional Web Vulnerability Scanner, or similar technology of your own choosing.

CMS

Securing data

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

Profiles

The built-in profile system does not track PII by default but can certainly 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, etc.) and that consent is explicitly given by users represented by the profiles.

Fetching data

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, and so no data to correct or query here. Anything stored in cookies can of course be deleted by the visitor simply by clearing cookies.

Deleting data

DXC Service

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

Comments