What to write when they ask what data each vendor can see

What the row is asking

Reviewers ask "what data they access", "what data they handle", "what data they touch", and "what each processes". Some ask for an architecture/data-flow diagram. The words differ. They want the kind of customer data that reaches each company, and the kind that does not.

The purpose cell is the job: hosting, email, payments, or support. The form is also asking which data arrives. Hosting for customer files says more than Hosting. You can mention that kind of data in the purpose line you type.

An architecture/data-flow diagram is a picture of that path. When you do not have one, a short note does the job a reviewer can file. One line per company. The kind of customer data that reaches it, and the kind that does not.

A model provider that receives prompts or files is one of those companies. How long you keep the data is a different sentence. A vendor belongs on the list when it receives, stores, or can read the customer's data. Tools that only see your own company data usually stay off the list.

If a tool sends customer data on to a company you did not name, that company belongs in the note too. Your list names the companies you chose. It does not copy another company's list.

What reviewers accept

They accept a plain description of what is true for each vendor. Name the kind of customer data that reaches it. Name what does not, when you have checked.

If you have not traced a vendor, say you are still checking. Do not write that it sees nothing, and do not write that it sees everything.

A short data-flow note is enough to file when you do not have a diagram. Write only the companies and the kinds of data you have actually followed.

An honest gap is a complete answer. The answer that fails is a diagram, or a list of data kinds, that you cannot stand behind.

Write the sentence only when it is true. A claim about what a vendor can see is a promise to this customer. If they ask to see the path, show the note, or say you do not have a diagram.

What not to write

Do not answer "customer data" for every row. That does not say what arrives, or what does not.

Do not write a kind of data you have not traced through the product.

Do not say a vendor sees nothing because you hope it does not. Check the path, or say you are still checking.

Do not paste an architecture/data-flow diagram you do not have. The short note is the honest file.

Do not hide a second company inside one purpose line. If the help desk sends customer text to a model, both companies belong in the note.

Do not answer what they can see by saying how long they keep the data. That is a different row.

Do not describe data a vendor can see as if you had drawn the diagram, when the path only lives in your head.

Where this answer lives

Keep the full note in the questionnaire answer you control. On the vendor list, you can mention the kind of data in the purpose line you type. That is the only place the list holds it.

Trust Prep has no column for the kind of data, and it does not draw a data-flow diagram. It does not fill this row.

The public page shows your company name, a short summary, and a contact email. Each row shows the company, what it does, the processing location, the agreement link, and the date you saved it. A suggestion can offer a location or a public agreement link, and only after you use it. It does not say what data the vendor can see.

A company, a location, or an agreement link shows on the public page only after you save it.

If you want the longer notes

Why reviewers ask which companies handle customer data is in the vendor list guide.

A table you can copy, with a purpose line and no column for the kind of data, is in the subprocessor list template.

When a model provider sees customer prompts or files, that guide has no column for the kind of data. What to check is in the AI provider guide.

Whether a vendor belongs on the list, because it can read customer data, is in the controller and processor guide.

How long you keep that data is a different sentence from which data reaches the vendor. What to write is in the data retention guide.

Who on your team can still open customer data is a different row from what a company can see. What to write is in the access review guide.

A log of who did what is a different row from what data a vendor can see. What to write is in the audit log guide.

Whether one customer can see another's data is a different row from what a vendor can see. What to write is in the customer data isolation guide.

Whether customer data trains a model is a different row from what a vendor can see. What to write is in the customer data training guide.

What an agent is allowed to read, write, or send is a different row from what data a vendor can see. What to write is in the agent permissions guide.