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:

Customer sends us the request to be forgotten/deleted.
We send the customer an email to confirm it was really them.
If the customer confirms, we go through the deletion process in Olympus (see below).
Ellen needs to be told about the request so the customer can also be deleted from our CRM system.
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:

If a person is flagged as an employee, manager, consultant, contractor, or author, the system will not perform any deletions. (However, it is possible to edit the record to clear those flags manually, after which a deletion can proceed under the remaining rules).
If a person is also an author who has authored articles for us, that author is under contract to have provided content for dispaly on our web site and other places, and that contract is attributed to that author and promoted as such. This type of name cannot be deleted or anonymized.
If a person has acted as a trainer/presenter for one of our events, similar rules as to authoring articles apply, and the name can neither be annonymized nor deleted.
If a person has invoices on file that are no older than 4 years, we need to retain these records for legal reasons. We can remove that person's account record and make sure no correspondance will be sent to that name (either in email or print or any other method), but the record cannot be deleted.
If a person is part of any internal EPS email groups, the name cannot be deleted. (In that case, the person must be an employee or contractor. Note however that if the name is removed from internal email group and thus probably from employment, this rule will not apply anymore).
- Similarly, if the person is assigned an EPS internal security rule, the same rules apply.
If a person has signed up for an event, we annonymize the signup (we point to a dummy placeholder name). This way, we still get accurate stats for number and time of signups, but we do not know why that specific signup was.
If a person has applied for a position at EPS within the last year, the name cannot be annonymized or deleted, but we can remove account information and make sure the person is not being contacted.
If a person has an active subscription, we cannot delete the person. Note however that the subscription can be terminated manually and the deletion of the name can then be performed as a separate step. (Note: We should double-check with the customer that this is really what they want as they will lose access to a service they paid for).

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:

Name or Person: These terms are synonymous and refer to a real person (“John Smith”) or a legal person (“ACME Corp”). Our system treats all such entities the same way. This includes consulting customers, subscribers, event attendees, trainers, presenters, employees, contractors, authors, and so on. Almost all information our system keeps track of is ultimately tied to a “name”.
Communication Information: A way to communicate with a “name”. This includes email, phone numbers, social media handles, and the like (but not addresses… see below). Communication information can be flagged as verified or inactive. Inactive communication information may be tracked in the system, but the system will never use it to communicate with the name. It is thus keps for historical reasons and database consistency only. A name can have an unlimited number of communication information elements associated with a name. (Note: Theoretically, communication information can be shared by multiple names, but we haven't made use of that ability.)
Addresses: A name can have any number of associated addresses. Addresses can be flagged as USPS verified (in the US only). They can also be flagged as inactive. The system will not send to an inactive address. (However, it will send to an unverified address. Address verification is only to be seen as an added benefit and additional layer of confidence. Verified addresses should be used over unverified addresses when possible.)
Account: Each name can optionally have one or more accounts. An account is a way to log in. It allows users to log in and access features like subscriptions or event materials. Note that not every name must have an account, but in order to access online materials, at least one account must be established. Accounts - in simple terms - are a combination of a user name and a password that link to a name and can thus identify and verify that a person is in fact who they are. Accounts can be deleted and re-established at will, without much impact to the rest of the system. We can also flag a name as “do not create accounts”. Thus deleting all accounts and flagging the name as such, will ensure the user can never log in to the system again in the future.
Annonymizing: This refers to the practice of removing all personally identifying information, such as the name or birth date. When a record is annonymized, we can still keep information such as invoices or event attendance, but we do not know the identify of the person that got the invoice or attended an event (to name two examples). It does however preserve database integrity and prevents falsification of statistics, among other things.
Blocking: Our system has the ability to block a name for email communications. With very few exceptions (such as sending password reminders), the system will block any outbound email communications with that name, regardless of any other flags.
Key: We use “globally unique keys” (GUIDs) in our database to identify person-records. The key itself holds no personal information about the person. We can thus retain the fact that the key was in use for a deleted person, since the key alone does not allow us to idenfity a person. However, the fact that the key was once used to identify a person can be used as a safeguard to make sure the person can never re-appear.

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):

All accounts are deleted, and the person is flagged as “don't create new accounts”.
All inquiries the person may have placed are deleted.
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.
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.
Job applications older than 1 year are deleted (as are our internal ratings of those job applications).
Subscription offer codes specific to the person are unassigned.
All non-active subscriptions (expired, terminated, or flagged as “deleted”) are annonymized (assigned to a dummy record).
Article ratings the person may have placed are deleted.
All correspondance sent to the person is deleted. (“Correspondance” in this case means all data from the “correspondance” table, which is different from Emails).
Interest assignments we may have on file for the person are deleted.
Coupons used by the person are assigned to a dummy record and thus annonymized. (Similar to the event signup scenario).
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).
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).
All files associated with the person are unassigned.
All email notifications ever sent to the person are annonymized (linked to a dummy record).
All subscription fulfillment information is unassigned (annonymized) and linked to a dummy record.
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:

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

...

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).
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.
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:

the personal information was collected by the business from the consumer
it is no longer necessary for the business or service provider to maintain the personal information in order to fulfill one of the purposes identified in Cal. Civ. Code Sec. 1798.105 (d) AND
the business is not entitled to retain the personal information under one of the generals exemptions under Cal. Civ. Code Sec. 1798.145

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.