Name who received their row

A customer asks which other companies received their data. Tonight, in this order, and alone. Confirm the request is from that person. Name each company the live product actually sent that person's data to, or write that the list cannot be finished. Then check that a different customer's identifier is not on the page you are about to send. If any of the three needs the person who built the product, you do not have a list. You have a category, and a category is not a name.

This is the list of companies. It is not the file of the customer's own rows. Hand one customer their file is that copy: their data, in a form they can open, with the next person absent. A file can be complete and still not say who else was given a copy of it. It is not the afternoon you change one fact. Correct one customer's wrong fact is the change, and the notice you then owe to people you already disclosed the old fact to. You cannot notify a recipient you never wrote down. It is not the text they were shown when they agreed. Show the consent they gave is that text, the act, and the time. Agreement to a purpose is not a list of the companies that later received the row. It is not deletion. When a customer asks to be deleted removes what the product can still show. Removing the person does not, by itself, tell them where the row already went.

None of what follows decides whether a statute covers your business, and none of it is legal advice. The texts below are the clearest public statements of what a recipient is, and of when a category stops being an acceptable answer. They do not tell you which law binds a Virginia company with a customer in another country. They do not replace the lawyer you call when the request is a letter from counsel. They do tell you the shape of a list a founder can defend, which is a product question you can answer this week.

A recipient and a third party are not the same word, and a privacy notice that uses one for both has already blurred the list. Regulation (EU) 2016/679, Article 4(9), defines a recipient as "a natural or legal person, public authority, agency or another body, to which the personal data are disclosed, whether a third party or not." The exception in the same paragraph is narrow: public authorities which may receive personal data in the framework of a particular inquiry, in accordance with Union or Member State law, "shall not be regarded as recipients." Article 4(10) defines a third party as a person or body "other than the data subject, controller, processor and persons who, under the direct authority of the controller or processor, are authorised to process personal data" (European Union, Regulation (EU) 2016/679). Read the two definitions together. A processor is not a third party. A processor is still a recipient, because disclosure to a processor is disclosure "whether a third party or not." The company that hosts the database, the company whose model was given the row, and the company that sends the receipt are recipients if the row was disclosed to them. Calling all three "service providers" in a policy is a category. The category is allowed at a stage when the names do not exist yet. It is not the list a person is entitled to once the names exist.

The stage is the whole distinction. Article 13(1)(e), for data collected from the person, and Article 14(1)(e), for data collected from somewhere else, each require "the recipients or categories of recipients of the personal data, if any." That information is given at the start, when a hotel, a travel agency, or a support vendor may still be a kind of company rather than a named one. Article 15(1)(c) is later. It is "the recipients or categories of recipient to whom the personal data have been or will be disclosed, in particular recipients in third countries or international organisations." The English text prints "categories of recipient" here and "categories of recipients" in Articles 13 and 14. This article does not build a theory on that singular. It does not skip the difference. The access right is about disclosure that has happened or will happen, for this person, not about the menu you published before anyone signed up.

The European Data Protection Board says the controller does not get to keep the menu once the person asks. Guidelines 01/2022 on the right of access, version 2.1, record adoption on 28 March 2023 and minor corrections on 30 May 2024. Paragraph 117 quotes the Court of Justice, case C-154/21, Österreichische Post, paragraph 36: unlike Articles 13 and 14, which lay down an obligation on the controller, "Article 15 of the GDPR lays down a genuine right of access for the data subject, with the result that the data subject must have the option of obtaining either information about the specific recipients to whom the data have been or will be disclosed, where possible, or information about the categories of recipients." The guidelines then state the operational rule in their own words. If the person has not chosen otherwise, "the controller is obliged to name the actual recipients, unless it is impossible to identify those recipients or the controller demonstrates that the data subject's requests for access are manifestly unfounded or excessive within the meaning of Article 12(5)." They add that storing information about the actual recipients is necessary in order to comply with Article 5(2) and Article 19 (EDPB, Guidelines 01/2022). The quotation of the Court is the guidelines' quotation, ellipsis included. The judgment is a different document. Open it if you are going to rely on a sentence this page did not print.

Their example is the one to copy, because it separates the notice from the later list. An employer's privacy notice may lawfully say that data go to "travel agencies" or "hotels," under Articles 13 and 14, because at that stage the names are not known. After the trips, an access request should name the agencies and the hotels that received the data, unless the employee asked for categories. A founder's "we use service providers to operate the product" is the notice. The Tuesday reply that repeats that sentence, after the product has already called three named companies, is the example's failure. Footnote 72 of the same guidelines says the mere fact that data were disclosed to a large number of recipients does not, by itself, make the request excessive. Volume is not the impossibility exception. Impossibility is a claim you can support, not a mood about how many vendors a startup collects.

A vendor who adds a further company is a change to the list, not a detail under the first name. Article 28(2) says the processor "shall not engage another processor without prior specific or general written authorisation of the controller." In the case of general written authorisation, "the processor shall inform the controller of any intended changes concerning the addition or replacement of other processors, thereby giving the controller the opportunity to object to such changes." General authorisation is not silence. It is a written permission plus a duty to tell you before the next company is added, so you can object. If your contract says the vendor may use subprocessors, and you cannot name the ones who received this row, the list you would send the customer is unfinished. Write that. Do not send the category and call it the Article 15 answer. Article 28 does not decide that this regulation covers your company. It decides the shape of a list when a processor stands between you and the next company.

People say they do not know what companies do with data, and that feeling is not a count of your recipients. Pew Research Center's American Trends Panel, wave 127, interviewed 5,101 U.S. adults from 15 to 21 May 2023. Everyone who took part is a member of the panel, which is recruited through national random sampling of residential addresses. Interviews were in English and Spanish. Of 5,841 panelists sampled, 5,101 responded, a response rate of 87%. The cumulative response rate, counting recruitment and attrition, is 3%. The data are weighted. The report's concern question, CONCERNCO, prints 35% very concerned, 46% somewhat, 16% not too, and 3% not at all. 35 and 46 are the 81% the prose calls very or somewhat concerned. 16 and 3 are the 19% the prose calls the least concerned. Those four cells are one question. They are not a split of who received a row.

The understanding question is the closer feeling, and it is still a feeling. UNDERSTANDCO prints 6% a great deal, 26% some, 49% very little, 18% nothing, and 1% no answer. 49 and 18 are the 67% who understand little or nothing about what companies do with the data collected about them, up from 59% in 2019. 6 and 26 are a different answer, people who understand some or a great deal. Do not fold 67 and 32 into one mood. The control question is where the report and the topline should be read side by side. The prose says 73% feel very little or no control over data companies collect. The topline cells for that question are 51% very little control and 23% no control, which add to 74, plus 5% a great deal, 21% some, and 1% no answer. Those five cells add to 101, which is rounding, not a sixth answer. This article does not decide whether 73 or 74 is the figure Pew would stand behind. It does not print 73 as if the cells were 50 and 23. The 2019 cells on the same topline are 51% very little and 30% none. The report says the share ticked down. It does not print an arithmetic that turns those two pairs into the size of the tick (Pew Research Center, How Americans View Data Privacy, and the topline).

A second question in the same report is about selling, and it is not this list. 76% have little or no trust that leaders of social media companies will not sell users' personal data to others without consent. 46% have no trust at all in that sentence. The question is trust in social-media executives, about selling, with a consent condition inside it. It is not a share of companies that disclosed a row, not a share of startups, and not a probability that your next ticket asks for recipients. 81%, 67%, and 76% are three questions. None of them is a log. Pew is a research center. It does not sell you a recipient register. What you take from the 67% is smaller than the headline. A person who asks where their data went is asking for names. A product that can only repeat a category is the thing they already said they do not understand.

Do the three proofs in one sitting, on the live product, with a login that is yours. 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 date you received the ask, and whether they asked for names or for categories. If they asked for categories, the notice may be enough, and you should say that you are answering the question they asked. If they asked who received the data, categories are the fallback you use only when you can say why the names are impossible, in the guidelines' sense, not because the spreadsheet was never built.

Second, the names, from systems you can open. Start with the path of one row you can point at: the database, the mail provider that was handed the address, the model vendor that was handed the text, the error tracker that received the stack with the email still in it, the support desk, the payment company, the analytics host. For each, the legal name, the date or the rule by which you know the disclosure happened, and whether it was this person or a batch that included them. A processor your contract allows, and a subprocessor that processor added last month, are two lines. If the second line is "they might use others," the list is unfinished. Article 28(2)'s chance to object is useless if the change never reached you. The backup from yesterday is a copy you hold. It is not a recipient unless you disclosed it. The handover is the inventory of accounts you were supposed to receive. Tonight's page is narrower. It is the companies that got this person's data, not every vendor the company has ever paid.

Third, the page you would send does not name the next customer. Search it for an email, an id, or an invoice that belongs to someone else. A list of your vendors, pasted from the website footer, fails this even when every logo is true, because it is not a list of disclosures of this row, and it may include a vendor who never saw this person. It also fails if the only name on it is yours. The founder is the controller in the story you tell customers. The companies the product called are the recipients. Mixing your own legal name into the recipient list, and leaving the model vendor off, inverts Article 4. Store the page where the request is handled. Do not paste the customer's whole account into a chat tool in order to draft the reply. The log is the evidence. The account is a different disclosure, and that chat tool is a recipient you have just created if the row went with the prompt.

What a list looks like when a product actually has more than one organization is ordinary. Gigbase is a multi-tenant workspace: projects, contracts, invoices, and roles, with more than one organization in the same system, and an admin dashboard. Nothing in that description is a headcount, a duration, a result figure, or a recipient log. The shape is the point. A disclosure from one organization is not a disclosure from the neighboring one. If you cannot separate those two, you cannot name who received this person's row without naming a company that received someone else's. The product either records the call per tenant, or the afternoon ends with the unfinished line.

There is a version of this request where hiring more engineering is the wrong purchase. Nothing has been built, so there is no call to name. You are still choosing firms, and neither has a system you administer. No customer has asked, and the product holds no personal data, because it is a brochure. The basis of the processing is a contract for a thing the person asked you to do, and no other company was given the row. Say that, if it is true, and do not invent recipients to look thorough. A customer has already seen another customer's data. That is an incident, and a recipient list does not close a leak. The person is a child, and you are about to decide a parent's rights from a blog post. Stop, and do not use this page as the decision. Or the buyer wants a lawyer. The proofs here are a list you can produce. They are not an opinion that the regulation applies, and they are not a filing.

Before you reply "we only share data with service providers," open the log. Name each company that received this person's data, or write the line that says the list is unfinished and why. Keep the next customer off the page. A startup software development company that expects this will have the disclosure written down at the time of the call, because reconstructing it from a vendor's memory is the impossibility claim you did not mean to make. Where the next slice is one capability and the acceptance test can include a recipient line for a single test user, an AI integration sprint is the shape that can require the line before anyone calls the feature done. The criteria for who should hold the login that can read that log sit on the page written for a top saas development company. That page is criteria. It does not rank anyone, including us. 67% is a feeling of understanding in a weighted survey of U.S. adults. 81% is a feeling of concern. Neither is your recipient rate, and neither belongs on the invoice.