Correct one customer's wrong fact

A customer says one fact about them is wrong. Tonight, alone, three things. Confirm the request is from that customer. Change that fact on the live record, and load the product the way they would until the screen shows the new fact and not the old one. Then write down every copy that still has the old fact, or write that you cannot name those copies. If any of the three requires the person who built the product, you have not corrected the record. You have sent a message asking someone else to.

This is a fact that stays attached to a person who stays. It is not a request to delete them. That proof — confirm it is them, remove what the live product can still show, and name what you are keeping — is when a customer asks to be deleted. Erasing the row makes the wrong fact disappear by making the person disappear, which is a different answer from the one they asked for. It is also not the drill that loads yesterday onto a system that is not production. Restore yesterday without the vendor proves a copy can be loaded. A correction that you then overwrite by restoring yesterday has undone itself. None of this is legal advice. The regulation quoted below defines which processing it covers. A blog post does not decide that for your company, and it does not replace the lawyer who reads your terms.

People feel they cannot fix what a company holds, and the number is a feeling, not a count of tickets. Special Eurobarometer 431, wave 83.1, was carried out by TNS opinion & social for the European Commission. Fieldwork for the wave ran through 9 March 2015. The report's cover dates publication to June 2015. It covers residents of the EU28 aged 15 and over. Interviews were face-to-face in people's homes. The full sample printed in the report is 27,980. The control question was asked only of people who provide personal information online, a base of 19,430. The question, QB4, is: "How much control do you feel you have over the information you provide online, e.g. the ability to correct, change or delete this information?" The report's summary: "Just 15% of people in this group feel they have complete control, while half (50%) say they have partial control, and nearly a third (31%) feel that they have no control at all" (European Commission, Special Eurobarometer 431).

Read the question that was asked. Correct, change, and delete are three examples inside one feeling of control. 15% is not a share who filed a correction. 31% is not a share whose record was wrong. The questionnaire also offered "it depends on the website or application" and don't-know. The summary prints 15, 50, and 31 and does not print those other two as their own EU figures, so the three you can quote do not add to 100, and you should not force them to. A later question, asked only of people who do not feel complete control (base 16,244), finds 67% concerned in total: 18% very concerned and 49% fairly concerned. The report's other side of that cut is 28% not very concerned and 4% not at all, which it calls around one-third (32%). That 67 is a share of the 16,244, not of the 19,430, and not of the 27,980. Age on the control question: 20% of ages 15–24 feel complete control, against 12% of ages 55 and over; 37% of ages 55 and over feel no control at all, against 22% of ages 15–24. A 2010 question about social networking sites printed 26, 52, and 20. The report says direct comparisons cannot be drawn. TNS ran the survey. The sample is EU residents in 2015, not your users, and not a probability that the next email this week is a correction.

The duty the slogan compresses is an accuracy rule, and it is older than the email in your inbox. Regulation (EU) 2016/679, Article 5(1)(d), says personal data shall be "accurate and, where necessary, kept up to date; every reasonable step must be taken to ensure that personal data that are inaccurate, having regard to the purposes for which they are processed, are erased or rectified without delay" (EUR-Lex, Regulation (EU) 2016/679). Erased or rectified. The principle itself offers both, and the purposes decide which one is the reasonable step. A wrong phone number on an account the person still uses is a rectification. A fact you no longer need, about a person who has asked to leave, is the deletion article. Quoting "accurate" and then deleting the account because that was the button you had is not the principle. It is the button.

The right they are exercising, when the regulation covers the processing, is Article 16. "The data subject shall have the right to obtain from the controller without undue delay the rectification of inaccurate personal data concerning him or her. Taking into account the purposes of the processing, the data subject shall have the right to have incomplete personal data completed, including by means of providing a supplementary statement." Two operations, one article. Rectification replaces an inaccurate fact. Completion fills a gap, including by a supplementary statement, and only taking the purposes into account. A customer who says "also, my company name is missing" is not asking you to rewrite the row they already had. A customer who says "that company name is wrong" is not asking you to add a second company beside it. Write down which of the two you did. A screen that now shows a longer profile has not told you.

While you are still checking, the regulation has a third state that is neither a correction nor a deletion. Article 18(1)(a) gives a right to restriction of processing "where the accuracy of the personal data is contested by the data subject, for a period enabling the controller to verify the accuracy of the personal data." Article 18(2) then limits what you may do with restricted data: with the exception of storage, it is processed only with the person's consent, or for a legal claim, or to protect someone's rights, or for an important public interest the article names. Storage of the contested fact, while you verify, is the state the paragraph allows. Using that fact to send the next invoice, or to let a model answer as if it were settled, is the state it limits. Restriction is how you stop the old fact from acting. It is not the correction, and it has an end: Article 18(3) says the person who obtained the restriction is informed before the restriction is lifted.

The copies are a separate sentence, and they are easy to skip because the screen already looks right. Article 19: "The controller shall communicate any rectification or erasure of personal data or restriction of processing carried out in accordance with Article 16, Article 17(1) and Article 18 to each recipient to whom the personal data have been disclosed, unless this proves impossible or involves disproportionate effort. The controller shall inform the data subject about those recipients if the data subject requests it." A recipient is someone you disclosed the fact to. The backup from yesterday is a copy you hold, which is your problem even when it is not a recipient. The vendor whose model was given the old address, the support tool that cached the profile, and the partner you emailed the record to are recipients if you disclosed it. "Impossible or disproportionate" is the regulation's exception, and it is an argument you have to be able to make, not a mood. If the person asks who still has the old fact, Article 19's second sentence is a list. A list you cannot produce is the honest answer. A sentence that says "everyone has been updated" is the one you will have to correct.

The clock for telling them what you did sits in Article 12, and it is not a licence to leave the wrong fact up. Article 12(3) says the controller provides information on action taken on a request under Articles 15 to 22 "without undue delay and in any event within one month of receipt of the request." That period "may be extended by two further months where necessary, taking into account the complexity and number of the requests," and the person is told of the extension "within one month of receipt of the request, together with the reasons for the delay." Article 16's own words for the correction are "without undue delay." The month is the outside bound for the information about the action, for processing the regulation covers. It is not a finding that your company has a month. If the regulation does not cover you, the number is not yours. If it does, parking the wrong phone number until day 29 because the letter is not due yet has used the reporting clock as permission to keep using the fact. Article 12(6) is the identity check: where you have reasonable doubts, you may ask for information necessary to confirm the identity. The check is inside the period. It is not a pause that starts the month over.

Do the three proofs in one sitting, on the live product, with a second browser that is not your admin session. First, the request. You can point at the signal that convinced you it is them: a reply from the address on the account, a session they started, a method you already published. A screenshot from a stranger who knows their email is not that signal. Write the fact they say is wrong, the fact they say is right, and the date you received it. Second, the live record. As an administrator you can reach, change that field, and only that field. Load the product the way they would. The screen shows the new fact. A search a teammate would run shows the new fact. The old fact is not still the one the product acts on. Third, the copy list. One page: yesterday's backup, with the date it ages out or the date you will exclude this correction from a restore; every export and log that still has the old fact; every recipient Article 19 would name, or a line that says you cannot name them. If the third page is blank because you do not know where the copies are, the second proof is a screen. Say so to yourself before you tell them the record is fixed.

The backup line is where a correction goes bad quietly. Yesterday's snapshot has the old fact, because that is what a snapshot is. Loading it back onto production, to prove the copy still works, writes the wrong fact over the one you just fixed. Run that load on a system that is not production, which is what the restore drill is for. When you tell the customer what remains, name the copy and the date, or name the fact that you do not know. Three moves that feel like a correction and are a second problem. Pasting the whole profile into a chatbot so it can draft the reply, which puts the record into a vendor you did not have this morning. Asking the model inside your product to "remember the new address," which edits a prompt and leaves the table. Changing every customer, or the whole tenant, because the tool you were given has no single-field path. The first is a new disclosure. The second is a fiction. The third is an outage for the people who did not write to you.

The path you wanted was built when the product learned to tell one account from another and one field from the row. Gigbase is a multi-tenant workspace with subscription plans and role-based access for agencies, admins, and team members, and a dedicated admin dashboard. The shape that matters here is an admin, in an account you administer, who can change one account's stored fact while the others still sign in. That case is not a rectification story. Nothing in the description is a headcount, a duration, or a result figure. If the only control on the admin screen turns the whole product off, or rewrites every profile from a prompt, you do not have a correction. You have a kill switch and a paragraph, and neither is the field they named.

There is a version of this email where hiring someone to build the path is the wrong purchase. No customer has said a fact is wrong, and no customer can yet, because nobody is using the product. You have no product, so there is no field to change and no copy to name. You are still choosing who will build, and the document 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. Fixing one field does not close a leak. Or you wanted a lawyer to tell you whether the regulation covers you. Hire the lawyer. A repository does not answer that, and neither does this page.

When the request is real and the field is missing as a control, the missing object is specific. An admin action, in an account you administer, that changes one fact on one person and leaves a note of the copies. A startup software development company that expects this will have put that action next to the rest of the account admin, before a stranger could store a fact you might later have to stand behind. One that needs a call in order for you to change a phone number is telling you who holds the record. The accounts that had to be in your name before this email arrived are the handover you must receive. If the first slice is a fixed capability, an AI integration sprint is the shape where the acceptance sentence can include one correction 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 regulation applies, and they are not a rate.

Before you answer the customer, do the three proofs and write the date. Confirm it is them. Change the live fact, and look at it the way they would. Name the copies that still have the old one, including yesterday's snapshot, and do not restore that snapshot onto production to admire it. Do not ask a model to remember a field. The screen is how you notice the new fact is showing. The page where you list the copies is the page you can defend.