Since the introduction of the GDPR, companies have struggled to figure out how to handle data access requests and erasures across all the places that their data is stored. Data deletion, especially, is a sensitive subject because of the downstream impact of deleting data. It is known in legal terms as:

Right to be forgotten
Request to delete
Erasure request

Most organizations are surprised to find that typically a "deletion" doesn't actually mean you have to null the entire row of user information in a database.

When Ethyca executes an Erasure request, it orchestrates deletes and/or updates in two places:

Each database connected to your deployed Atlas (Step 5 above)
Each of your 3rd party SaaS integrations (Step 7 above)

If your organization has Ethyca's Atlas deployed, the first deletion sequence is executed against the databases connected to Atlas. After Atlas completes its deletion sequence, it will hand off to Ethyca's web services to orchestrate the deletion of SaaS Integrations connected to your Control Panel.

External SaaS Integration Data Deletion (Pseudonymization)

Please refer to the Data Integration support page to see how each of Ethyca's 3rd party data integrations handles deletion within each service provider

Atlas Data Deletion (Pseudonymization)

Because every business has different rules and tolerances for how "functionally deleted" data should be handled, Ethyca developed a few offerings for all data flow operations. When Atlas executes an erasure request it will employ one of five different "masking strategies" against each column of the database (if SQL) or against each field in a document (if NoSQL).

These masking strategies are:

1. Null value

The most obvious way to remove information is to null the values in the row. When Ethyca performs the update to the database table, we null all fields (or use null equivalents) as specified by your PII mapping. For example, we will null integers as 0, but strings as NULL. For those that prefer the .yaml mapping, no explicitly specified masking strategy will perform this action:

entities:
- name: "usertable"
  has_pii: true
  properties:
  - name: "id"
    datatype: "integer"
    data_attribute: "id"
  - name: "firstname"
    datatype: "varchar"
  - name: "lastname"
    datatype: "varchar"
  - name: "email"
    datatype: "varchar"

2. Fixed default value

If you determine that using a fixed string would be preferable for certain data, you can choose to change the value to whatever string value you prefer. Typically this is used with fields that have format validation, such as phone number, SSN, and email address. Note that the string value can be set per property in the Atlas UI or the .yaml file:

entities:
- name: "usertable"
  has_pii: true
  properties:
  - name: "id"
    datatype: "integer"
    data_attribute: "id"
  - name: "firstname"
    datatype: "varchar"
    default_value: "MASKED"
  - name: "lastname"
    datatype: "varchar"
    default_value: "MASKED"
  - name: "email"
    datatype: "varchar"
    default_value: "MASKED"

3. Randomized (UUID) default value

There may be a situation where you want to replace each row value with a unique fixed-length value. Ethyca offers the standard 128-bit long UUID with 36 characters by utilizing the asterisk ("*") in the .yaml notation. As you can see in the example above, each property is assigned a unique UUID and can be used in combination with a fixed default value string as you can see in the example with 'email':

entities:
- name: "usertable"
  has_pii: true
  properties:
  - name: "id"
    datatype: "integer"
    data_attribute: "id"
  - name: "firstname"
    datatype: "varchar"
    default_value: "*"
  - name: "lastname"
    datatype: "varchar"
    default_value: "*"
  - name: "email"
    datatype: "varchar"
    default_value: "*@masked.com"

4. Hashed value using an organization-specific salt

Ethyca also offers the ability to hash the value in the field with a cryptographically strong secret salt that Ethyca maintains on behalf of your organization. If your data flow operations require the ability to maintain referential integrity to a field because it may flow to a data lake, other ETL processes are performed, or aggregation occurs downstream, this may be the best option for you.

entities:
- name: "usertable"
  has_pii: true
  properties:
  - name: "id"
    datatype: "integer"
    data_attribute: "id"
  - name: "firstname"
    datatype: "varchar"
    masking_strategy: internal_hash_correlate
  - name: "lastname"
    datatype: "varchar"
    masking_strategy: internal_hash_correlate
  - name: "email"
    datatype: "varchar"
    masking_strategy: internal_hash_correlate

5. No masking at all

Sometimes your business may need certain information to be retained for tax or auditing purposes, and thus you will not want to delete it. However, to provide your customers (data subjects) the most complete PII in their data subject request package, you will want to retrieve this information. To do so, indicate "None" in Atlas 1.5, or update the .yaml with the following masking_strategy:

entities:
- name: "usertable"
  has_pii: true
  properties:
  - name: "id"
    datatype: "integer"
    data_attribute: "id"
  - name: "firstname"
    datatype: "varchar"
    masking_strategy: "not_masked"
  - name: "lastname"
    datatype: "varchar"
    masking_strategy: "not_masked"
  - name: "email"
    datatype: "varchar"
    masking_strategy: "not_masked"

You'll notice in each masking example that the ID is never deleted. Ethyca assumes that whatever you use as the primary key or ID is not personally identifying because an ID on its own is generally not considered PII. This allows Atlas deletions to remain as minimally disruptive to normal business data operations as possible.

Support

Please contact [email protected] or your dedicated Customer Success Manager if you require any technical assistance for the installation or configuration of Ethyca's Atlas.