Deleting Names

While we generally do not delete a lot of data manually, we do delete and remove names (and their associated information) from our systems, in an effort to satisfy customer wishes and to comply with data privacy laws (in partifular the “right to be forgotten” as specified in the European GDPR law and the Californian CCPA law… see below for more details). Note however, that not every name can be deleted or should be deleted. This document explains not just how to perform deletions, but also what the rules are the system applies.

Deletion Process

For a customer to be deleted permanently under the “right to be forgotten” rules, the customer has to contact us. It is up to the customer to decide how they want to do that, and we are happy to comply either way. However, we need to make sure that the person that contacts us really is the person they claim to be, to prevent fraudulent deletions. (After all, customers may lose access to purchased materials if they go through this process). We do this by sending them an email to ask for verification.

In short, the process works like this:

  1. Customer sends us the request to be forgotten/deleted.
  2. We send the customer an email to confirm it was really them.
  3. If the customer confirms, we go through the deletion process in Olympus (see below).
  4. Ellen needs to be told about the request so the customer can also be deleted from our CRM system.
  5. When this process completes, the customer needs to be informed of the result by email.

Note that we have at least 30 days to comply with the request (and more in certain cases). However, there is no benefit for us in having a customer who does not want to be a customer in our database (but there are downsides, such as expenses). Therefore, we want to delete that customer right away.

Note: We are in the process of updating the codemag.com web site to provide customers an explanation of the process.

Deleting a Name from Olympus

The customer/subscriber edit form in Olympus has a Delete Name button that triggers the deletion process. When this button is clicked, the system launches the following form:

This form provides detailed information about whether or not a person can be deleted, what the person's current state and data is, and so on.

Immediately, after launching this form, the system performs a number of checks on the name to see what data exists. Data that is problematic for deletion (see below) is highlighted in this form. The form gives an indication whether it is possible to completely delete the person. If it is possible to delete the person (at least in part), the Delete Person Permanently button becomes available. Click this button to perform the actual deletion.

Note that this action cannot be undone!!! Once a person is deleted this way, we have no trace of the person, and we cannot help them with customer service requests (such as “where is my magazine”) anymore. We simply do not have such data and cannot recover it. (That's the whole point of this exercise, after all).

Note that unless there is a very specific reason to not delete the name (such as the name being an employee… see below for all the rules), the system will do its best to delete as much as possible, even if some things can't be deleted. For instance, accounts are generally deleted, even if we are legally obligated to keep other data. The name is also put on our “blocked email” list (although just by anonymized name ID… we cannot filter/block by email as we are obligated to delete the email address and thus cannot associated the name with that email address anymore). After the process completes, the system will display what data was deleted (hopefully all of it) and what still remains.

Deletion Conditions

Our system can perform record deletions as well as status checks of a name/person/entity to verify eligibility for deletion without actually performing a deletion. Either way, the following steps and rules are processed:

In all other cases, a person can be deleted from our system, with all associated information.

An Explanation of Relevant Terms

There are different technical aspects that go with a “name” or "person". To avoid confusion, here is a glossary of terms relavant for the situation:

Technical/Legal Notes

Privacy laws generally do not specify how a request for erasure has to be made. We accept inquiries of any kind (although we have to make a reasonable effort to verify the user's identity). Ideally, a user will use login and self-service options on the codemag.com web site.

Privacy laws generally specify that data has to be deleted in a way that would make it difficult/unreasonable to retrieve the data in the future. What that means is up for debate. While some say storage media has to be physically destroyed, others state it has to be just “overwritten”. In general, it seems to be agreed that if one would have to go to significant efforts to restore data (such as having forensic organization re-create data on a physical harddrive), the data is "deleted enough".

We store all our data on the Microsoft cloud (“Azure”). We do not have "reasonable access" to data on that cloud once we delete it. For instance, we do not have access to the drives or even servers the data resided on, other than through the means Microsoft provides us. For instance, we could not run data retrieval tools that would be available on a local server or harddrive. We thus feel we comply with the laws by using the deletion methods Microsoft provides us.

Depending on the privacy law applicable, data generally has to be deleted within 30 or 45 days (although extensions for up to 90 days can usually be had). One of the trickier points in data deletion is usually the topic of backups. Our backup retention policy thus plays into this.

What Exactly Gets Deleted, Removed, Blocked, and Logged

Regardless of whether a person can be deleted completely, the following deletions will happen (unless an employee-related flag is set… see above):

  1. All accounts are deleted, and the person is flagged as “don't create new accounts”.
  2. All inquiries the person may have placed are deleted.
  3. Event signups are annonymized. This means that we keep track of the fact that there was a signup, but the signup is linked to a dummy name. This way, we have no trace of the original name that signed up, but our statistics still produce the correct number of signups.
  4. Invoices (as well as invoice line items, invoice payment records, invoice billing steps, associated coupon uses, and associated subscription history) older than 4 years are deleted.
  5. Job applications older than 1 year are deleted (as are our internal ratings of those job applications).
  6. Subscription offer codes specific to the person are unassigned.
  7. All non-active subscriptions (expired, terminated, or flagged as “deleted”) are annonymized (assigned to a dummy record).
  8. Article ratings the person may have placed are deleted.
  9. All correspondance sent to the person is deleted. (“Correspondance” in this case means all data from the "correspondance" table, which is different from Emails).
  10. Interest assignments we may have on file for the person are deleted.
  11. Coupons used by the person are assigned to a dummy record and thus annonymized. (Similar to the event signup scenario).
  12. Coupons “owned” by a person (so they can give other people coupons) are annonymized. (This way, they can still be used by whoever received the coupon, but the original person "owning" them will not get credit for coupon use anymore).
  13. The person's original key is annonymously added to our blocked email list. (This is a safeguard in case the person re-appears for some unknown reason. In which case, the system would still not send them anything ever again).
  14. All files associated with the person are unassigned.
  15. All email notifications ever sent to the person are annonymized (linked to a dummy record).
  16. All subscription fulfillment information is unassigned (annonymized) and linked to a dummy record.
  17. We log the person's key in a deleted log, which we use as a safeguard in case the person ever re-appears for some reason.

If no “undeletable” information remains, the actual name record itself is deleted by taking the following steps:

  1. The main person record is deleted.
  2. All communication information is deleted (email, phone, social media,...).
  3. All address assignments are deleted (and if the addresses aren't shared by other names, the addresses themselves are deleted).
  4. Name-category assignments are removed.
  5. User role assignments are removed.
  6. External account information (such as links to Facebook accounts, or similar external accounts) is deleted.
  7. Author information is removed (this is a separate 1:1 table).
  8. Client information is removed (this is a separate 1:1 table).
  9. Customer informatoin is removed (this is a separate 1:1 table).
  10. Employee information is removed (this is a separate 1:1 table).

Applicable Privacy Laws

The “right to be forgotten” is a key element in different privacy laws around the world. CCPA applies to our customers from California. GDPR applies to our customers from anywhere in the European Union (EU). While in theory we could differentiate and only grant these rights to people from within these juristictions, in practise, we do not make a difference and grant these rights equally to all users, since that makes sense anyway.

While different privacy laws have differ from each other, the core elements important to us remain similar and we thus treat all users the same. Sometimes, privacy laws are contradictory and would require different implementation based on where a person is from. However, at this point we have not found any such case that applies to us, and thus we are able to treat everyone with the same set of rules.

The section of the law applicable to us is listed below. In short, the following applies:

...

Art. 17 GDPR - Right to erasure (‘right to be forgotten’)

  1. The data subject shall have the right to obtain from the controller the erasure of personal data concerning him or her without undue delay and the controller shall have the obligation to erase personal data without undue delay where one of the following grounds applies:
    1. the personal data are no longer necessary in relation to the purposes for which they were collected or otherwise processed;
    2. the data subject withdraws consent on which the processing is based according to point (a) of Article 6(1), or point (a) of Article 9(2), and where there is no other legal ground for the processing;
    3. the data subject objects to the processing pursuant to Article 21(1) and there are no overriding legitimate grounds for the processing, or the data subject objects to the processing pursuant to Article 21(2);
    4. the personal data have been unlawfully processed;
    5. the personal data have to be erased for compliance with a legal obligation in Union or Member State law to which the controller is subject;
    6. the personal data have been collected in relation to the offer of information society services referred to in Article 8(1).
  2. Where the controller has made the personal data public and is obliged pursuant to paragraph 1 to erase the personal data, the controller, taking account of available technology and the cost of implementation, shall take reasonable steps, including technical measures, to inform controllers which are processing the personal data that the data subject has requested the erasure by such controllers of any links to, or copy or replication of, those personal data.
  3. Paragraphs 1 and 2 shall not apply to the extent that processing is necessary:
    1. for exercising the right of freedom of expression and information;
    2. for compliance with a legal obligation which requires processing by Union or Member State law to which the controller is subject or for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller;
    3. for reasons of public interest in the area of public health in accordance with points (h) and (i) of Article 9(2) as well as Article 9(3);
    4. for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes in accordance with Article 89(1) in so far as the right referred to in paragraph 1 is likely to render impossible or seriously impair the achievement of the objectives of that processing; or
    5. for the establishment, exercise or defence of legal claims.

For more information about GDPR, the following site is found to be useful: https://gdpr-info.eu.

California Civ. Code Sec. 1798.105

Consumers can exercise the right to delete their personal information if:

Organizations must inform consumer’s in their CCPA privacy policies of the fact that the consumer has a right to request that information be deleted.

In responding to a request to delete, a business may present the consumer with the choice to delete select portions of their personal information only if a global option to delete all is also offered and more prominently presented than the other choices. (See, CCPA proposed rules 999.313 (d)(8)

More information about CCPA can be found here: https://medium.com/golden-data/right-to-delete-under-ccpa-55338a324944.