the door with no incident behind it

Every other guide here looks inward. Employees, contractors, service accounts, vendors, acquisitions, indexes. All of it about who can reach your data.

If you sell software, there is a second question, and your customers own it: who at your company can see theirs?

Specifically, the button. The one in your internal tooling that lets a support engineer log in as a customer user, see what they see, and fix the thing they are complaining about. Almost every business software company has one. It is genuinely useful, it makes support much better, and at many companies it is gated by a job title and nothing else.

the argument, and where it does not hold

You would expect a list of breaches where that button was the way in. There is no public incident that names a log-in-as-customer feature as the mechanism.

What is documented is the layer underneath it.

Okta, in autumn 2023, had a service account in its support case management system whose credentials had been saved into an employee’s personal Google profile on a managed laptop. In Okta’s own write-up, that account could view and update customer support cases. The first disclosed figure was files belonging to 134 customers, with session tokens from support uploads used against five of them. Okta found out because a customer handed it an attacker’s address. Weeks later, Okta revised the scope: the attacker had also run a report containing the names and email addresses of all its customer support system users. The first estimate was low, and the correction went one way.

Mailchimp, in January 2023, said social engineering of employees and contractors gave an attacker access to an internal tool used for support and account administration, and 133 accounts were viewed.

Robinhood, in November 2021, told the SEC that an intruder had socially engineered a customer support employee by phone, reached customer support systems, and obtained a list of email addresses for about five million people.

Three incidents, all in support tooling, none of them the impersonation button.

So the argument needs amending, and the amendment is the interesting part. The impersonation button is under-governed precisely because nothing has forced a control onto it. No incident, so no framework named it, so no questionnaire asks about it, so no customer can see it. It is the privileged path that has never had to justify itself.

the good version exists and is priced for somebody else

The pattern for governing this is settled. It just costs money.

Microsoft’s Customer Lockbox requires an engineer to raise a request and the customer to approve it, and the access expires: up to four hours of access, with an unapproved request lapsing after twelve, and the engineer’s actions recorded in the customer’s own audit log. It sits on Microsoft’s top enterprise tiers or comes as an add-on.

That is the familiar shape by now, and the SSO tax guide names it: the control that matters sits one tier above where you live.

But there is a version scaled for a company your size, and somebody has already shipped it. Zendesk’s assume-account feature is off by default, the customer decides how long access lasts, and Zendesk’s documentation states that it reserves the right to assume an agent role without prior notice in emergencies.

Read that last clause again. It is more honest than what most companies publish, which is nothing. You know exactly what Zendesk can do and when, because it wrote it down.

That is the bar: somebody writing down what their staff can do, and when. You do not need Microsoft’s approval workflow to clear it.

three levels of support access

1. 1the job titleAnyone in support can log in as any customer. Nothing tells the customer.
2. 2written downOff by default, time-limited, logged per customer, and published so customers know the rules.
3. 3approved by the customerEach session requested and approved, expiring, in the customer's own log. Usually an enterprise tier.

the frameworks do not cover you here

People often assume otherwise.

Your SOC 2 report attests to controls you selected. If you did not write a control about staff access to customer tenants, the auditor did not test one, and the report is accurate. The SOC 2 guide makes this argument in general, and it lands here specifically.

European data protection law gets close and stops. As a processor, under Article 28 of the GDPR, you have to make sure the people with access are committed to confidentiality, that nobody processes personal data except on the controller’s instructions, and that sub-processors are authorised.

None of that requires you to log each access, to seek approval, or to tell the customer who read their data.

So there is no external pressure on this at all. Whatever you do about it is a decision you made, and that is unusual enough in this field to notice.

the check, thirty minutes, on your own product

Who can impersonate a customer user today? Name humans. If the answer is a role, expand it.

Is it gated by anything other than a job title? A reason field, an approval, a ticket reference, anything.

Is it time-boxed? Does the session end on a timer, or whenever the engineer closes the tab? Only the timer is a control.

Does the customer know? Consent is a bigger ask. The question here is whether anything anywhere tells them it happened. For most companies the answer is no, and most customers assume yes.

Does the log record which customer? Many internal tools log that an admin signed in, and leave out whose account they entered. Only the second record answers a question.

Could you answer, from a query and without relying on memory, who at your company opened customer X’s account on 12 March? That is the super admin guide’s question pointed at your own product, and the answer decides whether you could ever respond properly to a customer who asks.

Then the wider one, which is where the real finding usually is. How many people can read customer data without impersonating anybody? The production read replica. The analytics tool pointed at it. Application logs that contain request payloads. The error tracker with its stack traces and variable dumps. The support inbox.

Impersonation is the governed-looking door in a wall with several other openings, and counting only the door is how a company concludes it is fine.

The error tracker deserves a line of its own, because people forget it entirely. It exists to capture the state of the program at the moment something broke, which means it captures whatever was in memory, which in a business application is somebody’s data. Nobody provisions access to it deliberately. Every engineer has it, it is often outside your single sign-on, and it may be the least reviewed system in your company that routinely holds customer records.

the inversion

Then turn it around.

Take three vendors holding your data and ask them four questions. Can your staff view or impersonate our accounts? Do we approve first? Is it time-limited? Can we see the log?

Every one of those is answerable, and we know it, because two vendors named in this guide publish their answers.

Many vendors will answer the first question and go quiet on the other three. You will recognise that silence, because it is the one you would have produced before reading this.

That cuts the way it should. The question your customers have never asked you is the same one you have never asked anybody, and the first company in any relationship to publish an honest answer gets an advantage that costs nothing to produce.

One practical note for whoever handles your enterprise sales: a page saying who at your company can see customer data, under what conditions, and what gets logged, answers a questionnaire item before it is asked. That is a side effect, and it is the reason a founder will approve the afternoon.

what this guide cannot establish

Two limits, stated because this guide has been assertive.

There is no public incident where impersonation was the mechanism, so the case for governing it rests on the structure, without a body count behind it. That is a weaker argument, and it is the honest one.

And there is no data on how often buyers ask about this. If your security questionnaires do ask, the wording would be worth seeing.