Trust Prep

All guides

Who can open the data

What to write when they ask who can still open customer data

The row asks which people on your team can still open production and customer data, how often you actually review that access, what happens when someone leaves, and whether MFA is enforced. Write only what is true. If it is not true yet, say not yet.

This is a practical note for a security review, not legal advice.

Updated October 7, 2026

What the row is asking

Reviewers ask "who gets access, reviews, offboarding." They ask for an access review cadence, and for access reviews for our tenant. They ask "Someone quits Friday. Is their access gone Monday?" They want the people who can still open customer data, how often you look again, and what you do when someone leaves.

MFA sits beside this row. They ask whether MFA is enforced for those people, and sometimes for a config screenshot of MFA enforcement. Answer it in the same reply.

A report does not answer access reviews for our tenant. It can describe a control. It does not name who can open this customer's account, or the date you last looked.

A tenant is this customer's own account in your product, when each customer's data stays separate. Evidence for our tenant means you looked at that account. A general note about the team is a different sentence, and you should say so.

The security questionnaire guide names who can reach production in one overview line. This note is the rest of that answer: who, how often you review the list, what happens when someone leaves, and whether MFA is enforced.

What data each vendor can see is a different row. That row is the companies. This row is the people on your team. How soon you tell the customer about an incident is a different row again.

What reviewers accept

Name the people, or the roles, who can reach production and customer data, and what each one can open. If you have not written that list, say not yet.

If you review that list on a schedule, name how often, who does the review, and the last date. If you do not review it on a schedule yet, say not yet. A cadence you do not keep is not an answer.

Say what you do when someone leaves, and how soon the access is actually removed. If it would not be gone the next working day, do not write Monday.

Say whether MFA is enforced for those people. Not yet is a complete answer. A settings screenshot counts only when you have it.

For this customer's tenant, show a dated list of who could open their account, or say you review production access and have not reviewed that tenant. If you cannot produce the evidence, say not yet.

Write the sentence only when it is true. An access review cadence is a promise to this customer. An honest gap is a complete answer. The answer that fails is a Yes you cannot stand behind when they ask who still has access.

Answers you can paste

Use the line that is true. Replace the brackets. Delete anything that is not true.

Who can open it
The people who can open production and customer data are [names or roles]. They can [read customer records / open the database / sign in to a customer's account]. Other people on the team cannot. We checked this list on [date].

Reviewed on a schedule
We review who can open production and customer data every [month / quarter]. [Name or role] does the review. The last review was [date]. We removed access for [names, or no one]. This is the access review cadence we keep.

Not on a schedule yet
We do not review access on a schedule yet. When someone joins or leaves, [name or role] adds or removes their access to [production / the database / customer accounts]. We will not write an access review cadence until we keep one.

When someone leaves
When someone leaves, [name or role] removes their access to production and customer data [the same day / the next working day]. We also remove them from [the sign-in, the database, and support tools that can open a customer account].

Not yet when someone leaves
We do not yet remove access on a set day when someone leaves. If someone quit on a Friday, we cannot say their access is gone Monday. [Name or role] removes it from [the sign-in, the database, and support tools that can open a customer account] when we do the step.

MFA is enforced
MFA is required for everyone who can open production and customer data. It is enforced in [the sign-in they use]. We can show a settings screenshot from [date].

MFA is not enforced yet
MFA is not enforced yet for the people who can open production and customer data. We will not write that it is on.

Evidence for this tenant
On [date] we reviewed who could open this customer's account. The people were [names or roles]. We removed [names, or no one]. That is the evidence of an access review for this tenant.

No review of this tenant yet
We review who can open production, and that production holds every customer's data. We have not reviewed this customer's tenant on its own. We cannot produce evidence of access reviews for this tenant yet.

What not to write

Do not write an access review cadence you do not keep. The line becomes a promise to this customer.

Do not answer yes to access reviews for our tenant when you have not looked at that customer's account.

Do not say access is gone Monday if you have not removed it by then. Someone quits Friday. Is their access gone Monday? Write the day you actually remove it.

Do not write that MFA is enforced because the tool offers it. Write it only when you require it for the people who can open customer data.

Do not attach a config screenshot of MFA enforcement you do not have.

Do not list the companies on the vendor list as the people who can open customer data. Companies are a different row.

Do not send the contact email as the list of who can open production.

Do not describe a review that only lives in your head. If you have not written down who still has access, say not yet.

Where this answer lives

Keep these sentences in the questionnaire answer you control.

Trust Prep lists companies, not people. 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.

There is no access-review field and no MFA field. The contact email is not a list of who can open production. The page does not fill this row.

The overview line about who can reach production is in the security questionnaire guide.

The vendor list is where you name the companies that handle customer data. Why reviewers ask for that list is in the vendor list guide.

What data each company can see is a different row from who on your team can open it. What to write is in the data access guide.

How soon you tell the customer about an incident is a different row. What to write is in the incident notification guide.

Whether the customer's users can sign in with their company login is a different row from MFA for your team. What to write is in the single sign-on guide.

A log of who did what, whether the customer can read it, and whether an entry can be changed later, is a different row from who can still open the data. What to write is in the audit log guide.

Whether Customer A can see Customer B's data is a different row from who on your team can open this customer's account. This page uses tenant for this customer's account. What to write is in the customer data isolation guide.

What an agent is allowed to do is a different row from who on your team can open production. What to write is in the agent permissions guide.

Optional next step: a living page

The sentences above are enough for the row in front of you.

If you want one link for the companies that handle customer data, Trust Prep is a page you edit when a company changes. The 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. The list names companies, not people.

The page has no access-review field and no MFA field. The contact email is not a list of who can open production. Those sentences stay in the answer you keep.