Platform Administration and Architecture

Limiting exposure of personal data

Abstract

Guide to the places where personal data can be found in your Sitecore implementation.

Warning

This Privacy Guide provides technical guidance on how your developers can choose to configure your Sitecore product implementation to support you on your data privacy compliance journey. This guide does not provide exhaustive guidance, and should not be construed or used as legal advice about the content, interpretation, or application of any law or regulation. You, the customer, will always be in the best position to assess your own risks, and must seek your own legal counsel to understand the applicability of any law or regulation to your business, including how you process personal data. Your resulting implementation is based entirely on your own configuration choices.

In addition to securing the platform and complying with GDPR data rights, it is recommended that you review the spread of personal data throughout your implementation. Use the following list as a starting point.

Marking facets as [PIISensitive]

Make sure that any custom contact facets with personal data are marked [PIISensitive] - these facets are cleared when the right to be forgotten is executed.

Indexing of data marked PIISensitive

By default, contact facets marked [PIISensitive] are not indexed. This means that sensitive personal data is not stored in the xDB index. Be wary of enabling the indexing of PII sensitive data, unless it is absolutely necessary.

Personal data in logs

You may choose to exclude personal data from logging that you perform in your code - for example, when a visitor logs in or registers, you might exclude their email address or other personal data from the log entry.

Note

If you must log a reference to a contact for debugging reasons, you may consider using the alias identifier rather than the contact ID. The alias identifier is deleted when the right to be forgotten is executed, thereby severing the link between contact and log entry. This assumes that the storage and lifetime of your logs comply with legislation.

Excluding personal data from EXM logs

In Sitecore 9.0 Update-1 and later, you can use the following configuration setting to include or exclude personal data in the EXM logs:

  <setting name="EXM.IncludePIIinLogFiles" value="false"/>

Personal data is excluded from the logs by default.

Limiting personal data loaded into session

Use configuration to limit which facets containing personal data are loaded into session. This reduces the amount of personal data that is stored in the Shared Session State Store for the duration of a contact’s session.

Contact IDs in external systems

You may choose not to expose contact IDs in external systems or expose them in interfaces or URLs.

Contact IDs in the Collection database are sequentially generated by the xConnect service layer. This means that it is technically possible for an application with access to the  xConnect API to guess a contact ID and retrieve a contact that it should not have access to.

If you want to store an anonymous reference to a contact in an external system, consider using the alias identifier. Identifiers are removed when the right to be forgotten is executed against a contact, and any link between the alias identifier and a third party system will be broken.

Hashing or redacting IPs

IP addresses are hashed by default, and can be redacted. IP addresses are stored in IpInfo interaction facet and are not cleared when the right to be forgotten is executed.

The LocaleInfo facet

You may choose not to populate the GeoCoordinate property of the LocaleInfo interaction facet. Interaction facets are not cleared when the right to be forgotten is executed.

Note

In the tracker, these properties are populated automatically if you are using Sitecore’s IP Geolocation Service. You can disable the service to prevent sensitive data from being stored in interactions.

Sensitive data in interactions or events

You can create custom event models and extend interactions with facets. You may choose not to store personal data in interaction facets and events, as interaction data is not cleared when the right to be forgotten is executed.

Email Experience Manager’s EmailEvent does not store an email address. Instead, the EmailAddressHistoryEntryId property of each event references an entry in the EmailAddressHistory facet on the contact. This facet is marked [PIISensitive] and is cleared when the right to be forgotten is executed against the contact.

Disabling analytics for a particular page

If a page does not need to be tracked, you may choose to disable analytics to reduce the amount of behavioral data that you are collecting.

Sensitive information in URL query strings

If tracking is enabled, the complete URL of a page - including the query string - is persisted in session and mapped to the Url property of the PageViewEvent before being submitted to xConnect. You may choose not to include contact IDs, email addresses, usernames, or any other data that can be linked back to a contact, user, or customer entity.

Tip

Disable analytics for any page that exposes sensitive data in the URL.

Personal data in the xDB Reporting database

Processing and aggregation produces aggregate data that is stored in the xDB Reporting database. To avoid creating a link between data in the xDB Reporting database and a specific contact, you may choose not store contact IDs, interaction IDs, or any other data that can be linked back to a contact, user, or customer entity.

Limiting the use of personal data in Marketing Automation activities

Be aware of any custom Marketing Automation activities that store personal data in an activity’s custom values. This data is stored in the Marketing Automation database.

Limiting use of List Manager CSV export

The List Manager interface allows you to export lists of contacts to a CSV. Use role-based authorization to lock down this interface and make sure that the organization is aware that personal data can be exported in this manner.

Search events

If you are  triggering the search event from the tracker, consider the type of data might be included in the search text. For example, if you raise the search event as part of map search, the search text might include a data subject’s home address. The search event is saved to the xDB Collection database as a SearchEvent, and cannot be edited once it has been saved.

Note

Sitecore Experience Accelerator (SXA) components that use search will automatically trigger the search event.

Serialized xConnect data

Make sure that any custom cache or custom storage role that contains serialized contacts or interactions is secure and compliant. Alternatively, you can choose not to serialize personal data.

Cookie lifetime

Consider whether the default lifetime of the SC_ANALYTICS_GLOBAL_COOKIE needs to be changed. See Tracker configuration for more information.