## 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 any Personally Identifiable Information (PII), such as usernames or IP addresses. See also [Collect data](🔗).
To be fully GDPR compliant, Optimizely recommends you to upgrade to at least version 11.4.0. (See also [Why upgrade to CMS 12?](🔗)) If you are unable to 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 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 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
## 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. All 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 we strongly recommend running regular scans of all sites using the optional Web Vulnerability Scanner, or similar technology of your own choosing.
## Secure data (CMS)
The CMS relies on SQL server for most of its storage needs, so you should restrict access to 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 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, and so on) and that consent is explicitly given by users represented by the profiles.
## 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, and so no data to correct or query here. Anything stored in cookies can of course be deleted by the visitor by clearing cookies.
See also [Fetch and update data](🔗).
## Delete data (DXP)
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.
See also [Delete data](🔗).