Every outsourcing arrangement reaches the same awkward point: the provider needs to get into the client's systems in order to work. The CRM, the help desk, the ERP, the billing platform, sometimes email. That conversation usually goes wrong at one extreme or the other. Either it drags on for weeks and the team reaches day one unable to open anything, or it's settled in ten minutes with a shared account on a broad profile that nobody looks at again.
Access isn't a start-up formality. It sets both the risk the client takes on and the speed at which the provider can produce. It's worth designing before signing, not on the Friday before go-live.
The underlying mistake: granting by role, not by task
Permissions are almost always handed out by copying a profile that already exists. "They're the support team, give them the support profile." But that profile was designed for internal employees with years of context, and it usually carries things an outsourced operation doesn't need: exporting the full database, editing master data, voiding transactions, seeing other departments' information. It gets granted because it was at hand, not because it fits.
The alternative isn't distrusting the provider. It's starting from the process: list the tasks the team will carry out and derive from each one the minimum permission it requires. That exercise is half done already if the process was documented before outsourcing, as we set out in what to document before outsourcing a process. If nobody knows exactly what the team does, nobody can decide what it needs to see.
A permission nobody used in three months isn't a spare permission. It's risk surface left open for nothing in return.
What's worth granting
- Named accounts, one per person. They cost more in licences and they save every problem the shared account brings: without named accounts there's no audit, no way to attribute an action, and no way to close access when someone leaves.
- Task-level permissions, reviewable. Starting narrow and widening when the process asks for it leaves a trail of why each permission exists. Starting broad and trimming back never happens.
- Test environments for training. Training agents on live data is the quietest way to expose information. An environment with dummy data solves the learning curve at no risk cost.
- Second factor and a password manager. With it written down who administers them, and charged clearly within the licence model we discussed in tools and licences in BPO.
- Views instead of tables. When the task is to look something up, a scoped view or a read-only integration is usually enough. The full table is rarely required.
What's worth thinking twice about
- Bulk export. This is the permission that turns a small incident into a large leak. If the process requires exporting, it should run through a defined flow, a known destination and a record of who exported what.
- Administrator profiles. Administering the tool and operating it are two different jobs. Mixing them leaves the provider changing the rules it's later measured against.
- The client's corporate email. Sometimes unavoidable for brand experience, but it opens a channel the client doesn't see. If it's granted, it should come with agreed retention and review rules.
- Permanent emergency accounts. The contingency user created "just in case" during transition and still active two years later is a classic audit finding.
The lifecycle matters more than the initial grant
Almost all the attention goes to provisioning, and almost all the risk sits everywhere else. Four moments that need a named owner and a written deadline:
- Provisioning. Who requests it, who approves it on the client side, within how long. With no committed turnaround, the team's ramp slips and the provider is billing people who can't work.
- Change. An agent promoted to supervisor accumulates permissions if nobody removes the previous ones. Internal promotion is the main source of bloated profiles.
- Deprovisioning. The same day the person leaves, not at the monthly cut-off. This is where most operations fail, and it's the easiest to fix: the staffing change simply has to trigger revocation automatically.
- Periodic review. A quarterly recertification where the client confirms user by user that the access is still needed. It takes little time and it's the only way the inventory doesn't decay on its own.
Personal data: the framework, not improvisation
When the operation touches personal data, the access discussion becomes a discussion of responsibilities too. Who decides about the data and who merely processes it on someone else's behalf changes each party's obligations, and that's settled in the contract, not in practice. We cover that point in data controller and processor. What matters here is that the technical design mirrors what the contract says: if the provider may only process data for one purpose, the permission shouldn't let it do more than that. This is general framing and not legal advice; each operation should review it with its own counsel.
Traceability: logging is cheap, reconstructing isn't
The question you need to be able to answer isn't "do we trust the provider?" but "can we reconstruct what happened?". That needs access and sensitive-action logging, an agreed retention period for those logs, and someone who looks at them with some regularity rather than only when there's an incident. A live view of active accounts, reviewed in the same monthly operations meeting, prevents most surprises without adding bureaucracy.
It's worth separating two things that get confused: certifications say a management system exists, not that yesterday's permission was set correctly. That's the nuance we discussed in BPO provider certifications. The real control is the living inventory, not the certificate on the wall.
What to ask a provider
- How do they request, approve and document a new access, and within what time?
- What happens to access on the day an agent leaves the team?
- Do they always use named accounts, or share credentials in any case?
- How do they train new agents without exposing live data?
- What record do they keep of sensitive actions, and for how long?
- Who on the provider side owns the access inventory, and how often do they review it with the client?
How smartBPO works it
We build the access matrix during transition design, not in the week of go-live, and we build it from process tasks: every permission is tied to a specific activity and to an approver on the client side. We work with named accounts, train in dummy-data environments where the system allows it, and a person's exit triggers the revocation request the same day. We keep an inventory of active accounts and bring it to the governance meeting so the client can recertify what's still needed. The calendar for all of this sits inside the plan for the first 90 days, because a pending access is the most common cause of a ramp that slips. We don't promise the absence of incidents: we propose that minimum permission be written down, that the trail exist, and that both parties be able to review it when needed.