Just Do It!

The best practice for deprovisioning is to make sure it gets done! If an account is no longer needed, it should be disabled so it cannot be hijacked by an unauthorized user. Unfortunately, deprovisioning is notoriously overlooked in settings that lack mature identity management. To minimize the possibility of abandoned or unused accounts, you should implement automation to trigger periodic account review and deprovisioning. In a company setting, an HR system may initiate a deprovisioning workflow when a user is terminated. In a university environment, a student information system may trigger account deprovisioning upon graduation, at least for access reserved for current students. Even the best automation fails at some point, however, so a periodic audit of existing accounts is essential to find accounts that are no longer appropriate so they can be deprovisioned. In consumer-facing environments, it may be appropriate to consider deprovisioning accounts which have had no activity for many years. 

Provide a Soft Delete Technique

Human beings make mistakes. If you provide a “delete account” button, it’s almost guaranteed that someone will delete their account by mistake. To save yourself the trouble of restoring customer data when that occurs, you can make it harder to erroneously delete an account by implementing a soft delete. This can take the form of a confirmation screen (“Caution: are you sure you want to delete your account? This cannot be undone!”), and marking an account as deleted while providing a grace period before the account is truly deleted. During the grace period, an “undelete account” capability should be available. You can also send a confirmation email at the beginning of the grace period explaining that the account is marked for removal and will be permanently deleted at the end of the grace period. While not foolproof, this may prevent some accidental account removals and the work to restore mistakenly deleted accounts.

Reserve Deprovisioned Identities

When deprovisioning accounts, it is best to preserve a list of deleted account identifiers and prevent each identifier from being reused by a new owner in the future. If this is not done, a new person could create an account with a previously used identifier and might be able to request historical data associated with that identifier to get data that belonged to the previous owner of the account. If a deleted account identifier was used in a single sign-on scenario and was used to access multiple applications, the owner of a new account with the same identifier might be able to access the previous person’s data in those applications. This is especially important if an email address is used as the sole identifier for an account. (See Chapter 4 for why this is problematic.) By reserving previously used identifiers and checking all new identifiers for uniqueness against both active and deprovisioned accounts, several issues can be avoided.

Preserve Account Record

You never know when unauthorized activity might be detected. It could be weeks or even months after the fact. Because a fraud investigation may arise at any time, even after an account has been closed, you should consider whether information should be kept for a reasonable period of time about deleted accounts, including transactions, the time they were submitted, the accounts that performed them, identity data linked to the accounts, and any other information needed for forensic evidence. When an account is deleted, it may be appropriate to preserve some account identity information along with the date, time, and reason why an account was disabled or terminated. If an account is terminated due to abuse, keeping sufficient records may help identify if a user attempts to open another account, at least with the same identity data.

One caveat is that privacy regulations require that data be kept only as long as needed for legitimate business purposes, and users have the right to request that personal data about them be erased. These rights may conflict with the need to have backups and audit logs. In practice, approaches are being worked out to satisfy the intent of privacy rights as well as operational system needs. Such approaches include minimizing data that is retained, encrypting and restricting access to retained data, and following defined data retention policies and procedures. Such policies and procedures should be created with guidance from legal and privacy advisors to ensure alignment with best current practices.

Data Transfer

It may be helpful or even required to provide customers a means to download or transfer data out of your service. Users may have this right as part of privacy legislation, such as the GDPR (General Data Privacy Regulation). Providing such a feature may also make customers who worry about vendor lock-in more likely to sign up because they know if they are unhappy, they can take their data and go elsewhere. Corporate customers will often request the ability to periodically obtain an extract of all their data to protect themselves against a vendor failure.

For consumer users, the most scalable option is to provide a self-service means to download customer-owned data. The feature to download data can be shown in the “Delete account” process as an option before the account is deleted. You should consider the data formats that will be most useful to customers. For sensitive data, you should have a procedure to validate the requestor before providing a data dump. Requiring step-up authentication or at least reauthentication to obtain the data is one good precaution. This protects a user’s data if they have walked away from their keyboard without locking their screen.

For corporate or business customers, there are a few more points to consider. It may make sense to require the involvement of two people from the customer in the request process to prevent a lone actor from downloading sensitive corporate data for unauthorized purposes. Once suitable customer validation is obtained for the download request, it should be provided in the most direct, self-service manner to minimize the service provider’s access to the customer’s data. For example, if a data dump were done manually by the service provider, it might be downloaded to a person’s laptop or transferred to the customer by a channel that introduces risk.

For corporate customer data that involves user identities and passwords, the passwords should have been stored in a hashed format and may not be usable elsewhere if different hashing functions are used. Chapter 4 discusses options for migrating user identity data between systems. As with consumer users, thought should be given to the data format for a transfer as well as the security of the transfer process. Even if a customer is leaving, providing a good experience may keep a future opportunity open.

Privacy Right to Erasure

When a user deletes their account, it may not be enough to simply delete data your own service holds about a user. Article 17 of the GDPR provides consumers the right to erasure, commonly referred to as the right to be forgotten, which enables a user to request that an organization delete the data it has about the user. Under Article 19 of the GDPR, data controllers are obligated to communicate an erasure request to any data processors to whom they’ve given personal data. Users who wish to delete their account may wish to exercise their right to erasure, which may require deleting data in an application’s user repository and possibly other data processor services.

It should be noted that the right of erasure does not nullify other obligations a business or organization may have that require keeping records, including those which contain personal information. Article 17, paragraph 3, of the GDPR outlines several situations where the right of erasure does not apply. These include the fulfillment of legal obligations on the part of a data controller or processor, supporting rights for freedom of information and establishing, exercising, or defending legal claims. Financial institutions may have legal obligations to retain records with personal information for a period of time after an account is closed. Healthcare organizations often are required to retain healthcare-related records for a period after the date of service. Even small businesses have legal obligations to retain employment and tax records for a period of time. Balancing privacy rights and other legal obligations can be complex, so organizations should define a data retention policy and procedures for handling erasure requests, in consultation with legal and privacy experts.

Certificate of Deletion

In addition to having procedures for disabling and terminating individual user accounts for privacy reasons, corporate customers that terminate their use of a service may request that their corporate account be deleted. This can include the user data of administrative users associated with the account, application data related to the service, and user data. Customers may request a certificate of deletion that states that all their data has been deleted. If sensitive data is involved, including data about users, customers may request a certificate of secure deletion. This demonstrates due diligence to ensure data they’ve given to vendors deleted when no longer needed, which helps protect sensitive information.

Secure Delete

It can be surprisingly complex to “completely delete” data. Simply issuing a delete command in a database or to delete a file may not completely delete the data. In some cases, such a delete simply removes pointers to the data, but does not alter the space on the disk where it was stored, allowing specially written tools to recover the data.

Various techniques have been employed to effect secure deletion. One approach is to encrypt data and throw away the encryption key. This effectively deletes the data because it can no longer be decrypted. This approach assumes the time required to decrypt the data using brute force mechanisms is significantly longer than the time during which the data is likely to be valuable to data thieves. Since it is impossible to predict how long this assumption will be true, this is not a best option.

Another method of deleting data from a disk or other magnetic storage media involves degaussing a disk. Information is stored on disks by magnetizing the surface of the disk with small pulses of electricity as the read/write head of the disk passes over it. A disk can be erased with a special tool called a degausser which generates a powerful magnetic field that scrambles and removes magnetic fields on a disk. This method may be feasible when all information on a disk needs to be removed, as when the disk will be completely decommissioned from use. A drawback is that degaussing, as with physical destruction of a disk, may render the disk unusable and contribute to e-waste. Degaussing to remove only one customer’s data is also not feasible in a cloud service where many customers’ data resides on the same disk.

When a disk stores data of many customers, one customer’s data can effectively be erased by overwriting the data with random 0s and 1s. The question is how many times the data must be overwritten in order to ensure that residual magnetic traces do not allow data recovery. The US Department of Defense (DoD) 5220.22-M protocol has been cited for this. The 1995 version of this standard indicated data should be overwritten three times. This is now considered obsolete however.ⁱ For specific sanitization details, it has been superceded by the National Institute of Standards and Technology’s (NIST) “Special Publication 800-88: Guidelines for Media Sanitization” which indicates that for most of today’s media, overwriting with a fixed pattern, such as all zeros, with at least one pass is sufficient.ⁱⁱ This technique would require a service to create features to perform the overwriting. Requirements for secure delete may vary by industry and country so researching requirements for your target customer base will provide the best guidance on secure account deletion expectations.

Consider Reprovisioning Requirements

It may be worth considering the likelihood of requests from customers to reprovision their previously deprovisioned account and establishing policies for this. It would constitute a security breach if an account were reprovisioned and given to someone other than the authorized owner, so one option is to not support reprovisioning. If reprovisioning is to be supported, you’ll need procedures for validating that a requestor is an authorized owner of the account. Any practices to support this should also be aligned with applicable privacy legislation.

Key Points