Limiting exposure of personal information

Current version: 10.1
Warning

This Privacy Guide provides technical guidance on how your developers can choose to configure your Sitecore product implementation to support you with data privacy compliance. 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 information. Your resulting implementation is based entirely on your own configuration choices.

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

Marking facets as [PIISensitive]

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

Indexing of data marked PIISensitive

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

Personal information in logs

You might choose to exclude personal information 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 information from the log entry.

Note

If you must log a reference to a contact for debugging reasons, you might consider using the alias identifier rather than the contact ID. The alias identifier is deleted when the right to erasure 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 information from EXM logs

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

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

Personal information is excluded from the logs by default.

Limiting personal information loaded into session

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

Contact IDs in external systems

You might 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 erasure 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 erasure is executed.

The LocaleInfo facet

You might choose not to populate the GeoCoordinate property of the LocaleInfo interaction facet. Interaction facets are not cleared when the right to erasure 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 might choose not to store personal information in interaction facets and events, as interaction data is not cleared when the right to erasure 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 erasure is executed against the contact.

Disabling analytics for a particular page

If a page does not need to be tracked, you might 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 might 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 might choose not to 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 information in Marketing Automation activities

Be aware of any custom Marketing Automation activities that store personal information 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, which enables you to manage contact lists, also 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 information can be exported in this manner.

Search events

If you are  triggering the search event from the tracker, consider the type of data that 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 an individual’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 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 addresses the recommendations in this guide. Alternatively, you can choose not to serialize personal information.

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

Do you have some feedback for us?

If you have suggestions for improving this article,