When a customer asks to be deleted

A customer has asked you to delete them. Tonight, alone, three things. Confirm the request is from that customer, not from a stranger who knows their email. Remove what the live product can still show: the row, the session, and the file that row pointed at, and load the product as they would to see that it no longer returns them. Then write down what you are keeping, and why, including the backup from yesterday. If any of the three requires the person who built the product, you have not deleted the customer. You have sent a message asking someone else to.

This is the day a real person asks. It is not the afternoon before you open signup, when the account you erase is one you created in order to watch it disappear. That proof is what to prove before public signup, and it is allowed to finish while no customer exists. It is not the drill where you load yesterday onto a system that is not production. A backup you can restore, and a backup that still contains someone you promised to remove, are different problems, and the second one starts only after the first one works. A request to change one fact and keep the person is a different proof: correct one customer's wrong fact. None of this is legal advice. The statute quoted below defines which businesses it covers. A blog post does not decide that for you, and it does not replace the lawyer who reads your terms.

People do ask, and the number that gets repeated is wider than a deletion. Cisco's 2024 Consumer Privacy Survey is a double-blind study, respondents unknown to the researchers and the sponsor unknown to them, gathered in the summer of 2024. "Respondents comprised 2600+ adults (18 years and older) in 12 countries (5 Europe, 4 Asia, and 3 Americas)." The report defines a data-subject request as a right "enabling them to inquire about their data and, in some cases, to request that their data be changed or deleted." Then the figure: "Among survey respondents, 36% indicated they have exercised their rights to inquire about data, up from 28% this past year and 24% two years ago." The same paragraph splits age: "51% of respondents aged 18-24 have exercised a DSAR, compared with just 8% for respondents 75 years and older" (Cisco, 2024 Consumer Privacy Survey). Read the sentence that is in the report. 36% inquired. The report does not print a separate share who asked only to be deleted.

The press release beside that report widens the same pair of figures. Cisco's investor note describes "a significant increase (36% vs. 28% last year) in how consumers exercise their right to access, correct, delete or transfer their personal data via Data Subject Access Requests (DSARs)." Access, correct, delete, and transfer are four rights inside that one request type. The report's own sentence is the inquire line. Quote the report when the press release adds verbs the report did not count separately. 51% and 8% are age slices of that same inquire question, not deletion rates, and not a forecast for your signup form. Cisco sells networking and security products. The sample is adults in twelve countries, not your customers, and not a probability that the next ticket this week is a deletion. What you take from it is smaller. A request of this shape is ordinary enough that a product with customers should have a path the founder can walk. Ordinary is not the same as "already handled by the vendor."

"Gone" has a vocabulary, and a button labeled delete does not pick a rung on it by itself. NIST's guide to media sanitization, SP 800-88 Rev. 1, December 2014, defines sanitization as a process that "renders access to target data on the media infeasible for a given level of effort." It then splits the work into three categories. "Clear applies logical techniques to sanitize data in all user-addressable storage locations for protection against simple non-invasive data recovery techniques; typically applied through the standard Read and Write commands to the storage device, such as by rewriting with a new value or using a menu option to reset the device to the factory state (where rewriting is not supported)." "Purge applies physical or logical techniques that render Target Data recovery infeasible using state of the art laboratory techniques." "Destroy renders Target Data recovery infeasible using state of the art laboratory techniques and results in the subsequent inability to use the media for storage of data" (Kissel, Regenscheid, Scholl, and Stine, NIST SP 800-88 Rev. 1). The publication is about media. It is not a manual for a SaaS row, and Destroy is the wrong category for a database you still intend to operate tomorrow.

Translate the categories into the product you actually have, and stop at the one you performed. A DELETE in the application, followed by a check that the product no longer returns that person, is in the neighborhood of Clear: a logical removal of data the user-facing interface can address, tested against a simple attempt to read it back. It is not Purge. A laboratory with the disk, or a replica, is outside what your product screen can promise. It is not Destroy, because you did not make the disk unusable, and you should not. The backup is a second medium. Clearing the live database does not clear a snapshot taken yesterday, an export sitting in an object store, or a row copied into the vendor's error tracker. If you cannot name those copies, you cannot tell the customer what "deleted" means in your product. You can tell them the screen is empty. Those are different sentences, and only one of them is yours to prove tonight.

The California statute that people mean when they say "delete my data" is narrower than the slogan, and it is not advice. Civil Code section 1798.105(a): "A consumer shall have the right to request that a business delete any personal information about the consumer which the business has collected from the consumer." Subsection (c)(1) is the duty, and it has three parts: a business that receives a verifiable consumer request "shall delete the consumer's personal information from its records, notify any service providers or contractors to delete the consumer's personal information from their records, and notify all third parties to whom the business has sold or shared the personal information to delete the consumer's personal information unless this proves impossible or involves disproportionate effort." Subsection (c)(3) puts the contractor on your instruction, not on the customer's email to them: a service provider or contractor "shall cooperate with the business in responding to a verifiable consumer request, and at the direction of the business, shall delete, or enable the business to delete," and "shall not be required to comply with a deletion request submitted by the consumer directly to the service provider or contractor" to the extent they hold the data in that role (California Civil Code section 1798.105).

Read the direction of the instruction before you forward the ticket. If the statute covers your business, the customer asks you. You tell the contractor. A customer who emails the development shop, and a shop that shrugs because the request did not come through you, is the arrangement the subsection describes. The operational failure is earlier. If you cannot direct the contractor because the production database, the file bucket, and the error tracker sit in an account you do not administer, you do not have a deletion path. You have a favor. The handover you must receive is the list of accounts that had to be in your name before this email arrived. This article assumes that list was real. If it was not, finish that list for the systems that hold this person, and do not tell them the row is gone while a console you cannot open still shows it.

The same section is also a list of reasons a business may keep information, and the list is longer than a founder remembers. Subsection (d) says a business, service provider, or contractor is not required to delete if keeping the information is reasonably necessary in order to do one of the named things. The first three: "Complete the transaction for which the personal information was collected," including a contract with the consumer. "Help to ensure security and integrity to the extent the use of the consumer's personal information is reasonably necessary and proportionate for those purposes." "Debug to identify and repair errors that impair existing intended functionality." The subdivision continues through free speech, a named California privacy statute, research with informed consent, internal uses aligned with what the consumer expected, and a legal obligation. Eight items, not three. A sentence that quotes only "security" and then keeps the whole profile has not used the exception. It has skipped it. Subsection (c)(2) is the narrow record you are allowed to want: the business "may maintain a confidential record of deletion requests solely for the purpose of preventing the personal information of a consumer who has submitted a deletion request from being sold," for compliance, or for other purposes "solely to the extent permissible under this title." The record of the request is not a copy of the account.

The clock is in a different section, and it is a clock, not a technique. Section 1798.130 says the business shall "delete a consumer's personal information, based on the consumer's request, within 45 days of receiving a verifiable consumer request," and that determining whether the request is verifiable "shall not extend" that duty. The period "may be extended once by an additional 45 days when reasonably necessary, provided the consumer is provided notice of the extension within the first 45-day period" (California Civil Code section 1798.130). Forty-five days is the statute's outside bound for businesses it covers. It is not permission to leave the live profile up until day 44 because the backup job runs monthly. It is not a finding that your company has 45 days. If the statute does not cover you, the number is not yours. If it does, the number is a deadline for a verifiable request, and the verification step is inside the deadline rather than a pause before it. Write the date you received the request. Write the date you will answer. Those two dates are how you notice you are late. A chat message that says "we'll get to it" has neither date.

Do the three proofs in one sitting, on the live product, with a second browser that is not your admin session. First, verification. You can point at the signal that convinced you: a reply from the address on the account, a session the customer started, a method you already published. A screenshot forwarded by a stranger is not that signal. Second, the live removal. As an administrator you can reach, delete or disable the account until a search by their email returns nothing, their password no longer opens a session, and the file they uploaded is gone from the place the product serves. Then load the product the way they would, not the way you would, and confirm the same three. Third, the keep-list. One page, in your own words: the invoice or tax record you are retaining, with the fields you actually kept; the confidential note that a deletion was requested, without the profile attached; every backup, export, and log that still contains them, with the date that copy expires or the date you will exclude them from a restore. If you cannot fill the third page because you do not know where the copies are, the second proof is a screen. Say so, to yourself, before you say anything to them.

The backup line is where founders lie by accident. Yesterday's snapshot still has the person, because that is what a snapshot is. Loading it back onto production, as a recovery, would put them back, which is the opposite of the request. Restore yesterday without the vendor is the drill for proving you can load a copy onto a system that is not production. Use that drill. Do not use production as the place you discover the copy still works. When you tell the customer what remains, name the copy and the date it ages out, or name the fact that you do not know. A sentence that says "you have been deleted" while an object store you have never listed still holds their export is the sentence you will have to correct. NIST's point about a given level of effort is the honest version: you made simple recovery through the product infeasible, and you have a dated plan for the other media. You did not make laboratory recovery of every disk infeasible, and you should not claim you did.

Three moves that feel like deletion and are a second copy. Pasting their row into a chatbot so it can draft the reply, which puts the profile into a vendor you did not have yesterday. Asking the model that answers inside your product to "forget" them, which edits a prompt and leaves the table. Deleting every account, or the whole tenant, because the tool you were given has no single-user path. The first is a new disclosure. The second is a fiction. The third is an outage you will explain to the customers who did not ask. The path you wanted was built when the product learned to tell one account from another. Gigbase is a multi-tenant workspace that had to put subscription plans and role-based access for agencies, admins, and team members in one product. The shape that matters here is an admin who can remove one account from the live product while the others still sign in. That case is not a deletion-request story. Nothing in the description is a headcount, a duration, or a result figure. If your admin screen can only turn the whole product off, you do not have a deletion control. You have a kill switch, and it is the wrong tool for one person.

There is a version of this email where hiring someone to build the path is the wrong purchase. No customer has asked, and no customer can yet, because signup is not open. Run the pre-launch erase on an account you created, and leave this article until a real request exists. You have no product, so there is no row to remove and no backup to name. You are still choosing who will build, and the request in front of you is a term sheet. The criteria for that choice sit on the page written for a top saas development company. That page is criteria. It does not rank anyone, including us. A customer has already seen another customer's data. Removing one profile does not close a leak, and the first hour of that incident is a different article. Or you wanted a lawyer to tell you whether the statute covers you. Hire the lawyer. A repository does not answer that, and neither does this page.

When the request is real and the path is missing, the missing object is specific. An admin action, in an account you administer, that removes one person from the live product and leaves a note of what you kept. A startup software development company that expects this will have put that action in your admin, next to the signup switch, before a stranger could create an account. One that needs a call in order for you to remove a customer is telling you who holds the data. If the first slice is a fixed capability rather than an open-ended rebuild, an AI integration sprint is the shape where the acceptance sentence can include one deletion you perform yourself. If you do not yet have customers, and the question is whether the systems you have could support the path, a two-week AI readiness assessment hands you the findings either way. The findings are yours. They are not a promise that a statute applies, and they are not a rate.

Before you answer the customer, do the three proofs and write the date. Confirm it is them. Remove what the live product can show, and look at it the way they would. Name what you are keeping, including yesterday's copy, and do not restore that copy onto production to admire it. Do not ask a model to forget a row. The screen is how you notice the account is gone. It is not the whole of what "deleted" has to mean, and the page where you list the rest is the page you can defend.