Most confidentiality incidents in translation workflows are not breaches. They are people with legitimate credentials opening files they had no business reason to see. Controlling that requires two boundaries, not one: inside your own organisation, permissions scoped to the matter or project rather than the account, so a translated document is visible only to the people already on that work; and inside the vendor's, a documented answer on which staff can reach customer content, under what approval, and for how long. Both boundaries need an access log — a record of who opened a file, not merely a record of which jobs ran.
This guide covers how permission models differ, what to log, how offboarding actually fails, and the specific questions that separate a scoped platform from a shared inbox with a translate button.
The Boundary Everyone Forgets Is the Internal One
Security review concentrates on the vendor because that is where the contract is. But the population with routine access to a translated document is almost always larger inside the client than inside the vendor.
A typical pattern: one licence is bought, a shared account is created so the team can use it, and every document anyone translates lands in a single workspace history. Six months later that history holds the disposal of a subsidiary, an internal investigation, a redundancy consultation and a term sheet, all readable by anyone with the shared password — including people who joined afterwards and people who left and were never removed, because a shared credential has no leaver process.
Nothing was breached. The control simply never existed. Any assessment that reviews the vendor's ISO certificate and not your own workspace configuration has looked at the smaller risk carefully and the larger one not at all.
Role Separation Starts With Who Submits
Before permissions, decide who does what. Three roles cover most legal and finance teams, and they should not be the same person by default.
Submitter uploads documents and receives output. Usually the fee earner, analyst or paralegal on the matter.
Reviewer checks the translation against the source and signs off. This should be someone who can read both languages and who was not the submitter, for the same reason a maker-checker split exists in payments.
Administrator manages users, licences, glossaries and retention settings. Administration is a platform function, not a document function, and an administrator does not need to read matter content to do the job.
The separation that matters most is the third one: an admin who can add users should not automatically be able to open every document ever submitted. Ask whether the platform treats those as distinct permissions or bundles them, because bundling is common and is the single most consequential default in the product.
Matter-Level and Project-Level Scoping
Law firms already think in matters; banks think in deals, deal codes and restricted lists. A translation platform should be able to inherit that structure rather than flatten it.
The workable model is a container — call it a matter, project or workspace — that carries its own membership list. A document submitted into it is visible to that membership and to nobody else. Adding a colleague is an explicit act, recorded, and removing them takes effect immediately for documents already in the container.
Two properties distinguish a real implementation from a cosmetic one. Membership must be enforced server-side rather than as a UI filter — if a direct document URL or an API call with the right identifier returns the file to a non-member, there is no scoping. And containers must be creatable at the speed of work; if opening a new matter requires an admin ticket, users will keep dropping documents into whatever container already exists, which is how everything ends up in one. Volume workflows have the same requirement — see batch translation.
Account-Wide and Document-Scoped Models Are Different Products
Under the surface, permission models fall into two families, and the difference determines what a compromised session costs you.
An account-wide model grants access at the tenant or user level. Anyone with a valid session can, in principle, reach the account's documents; the interface may organise them into folders, but folders are presentation. Blast radius equals the whole account.
A document-scoped model attaches an access control list to each document. A session grants you nothing by itself; each request is authorised against the object. Blast radius equals the set of documents that user was explicitly granted.
The test is simple and worth running during a trial. Log in as user A, submit a document, copy its identifier. Log in as user B in the same tenant, who was never granted access, and request that identifier directly through the API or the URL. A 403 means the model is real. A returned file means folders were decoration. IT teams trade exactly this kind of evaluation note in a discussion of document translation services.
Vendor-Side Access Should Be Described, Not Denied
On the vendor's side, the honest answer is never "nobody can see your data." Systems need operators. What distinguishes a well-run platform is that access is exceptional, approved and time-bound.
Ask for the shape rather than a reassurance. Is engineering access to production standing or break-glass? If break-glass, who approves, how long does a grant last, does it expire automatically, and is the customer notified? Does support tooling display document content, or only metadata and job status — and if support needs content to diagnose a rendering fault, is that a customer-initiated share rather than an internal reach-in?
Then ask how tenant isolation is enforced at the storage layer, and whether any internal tooling can query across tenants. Cross-tenant query capability is where a support convenience becomes a confidentiality problem. Controls of this kind are exactly what an ISO/IEC 27001 scope statement and a SOC 2 Type II report should evidence, provided the scope covers the translation service itself.
Log Access, Not Only Processing
Most platforms log processing: job submitted, job completed, document translated. That answers a billing question. It does not answer the question that arrives with an investigation, which is who opened this file.
An access log worth having records, per event: identity, timestamp, action (view, download, re-download, share, delete), the document identifier, the matter or project, and the source — session, API key or integration. Failed authorisation attempts belong in the same log, because a pattern of denials from one account is a signal that nothing else produces.
Three properties make it usable. It must be exportable, so it can be joined to your SIEM rather than read through someone else's dashboard. It must be immutable to tenant administrators, or an insider incident cannot be investigated with the log the insider could edit. And it must be retained longer than the documents themselves, since the question is usually asked after the file is gone. GDPR Article 32 speaks to the security of processing in general terms; the access record is how you demonstrate it in particular.
Offboarding Fails Quietly
Leaver processes handle email and the network. They routinely miss the tools a team adopted on a card, and translation platforms are a classic example: procured departmentally, integrated with nothing, invisible to identity management.
Three fixes, in order of value. First, put the platform behind SSO so a disabled directory account disables platform access on the same day, and use SCIM provisioning where available so membership changes propagate without a ticket. Second, abolish shared credentials, which cannot be offboarded at all — one named account per person, always. Third, own the orphans: API keys and service accounts created by someone who has left, still valid, attached to no human.
Then close the loop on internal movers rather than only leavers. Someone moving from corporate to litigation should lose access to their previous matters, and a conflict or ethical wall raised mid-matter has to be enforceable inside the translation platform too — which is only possible if scoping was per-matter from the start. Firms handling foreign contract review hit this constraint early.
A Configuration Review Worth Repeating
Once a quarter, in under an hour, answer five questions with evidence rather than memory.
Who has an active account, and does that list reconcile against the directory? Which accounts have not been used in ninety days? How many documents sit outside any matter or project container? Which API keys exist, who owns each one, and when was each last rotated? And can you produce, for one document chosen at random, a complete list of everyone who has opened it?
The last question is the real test. If you can answer it in minutes, the controls are working. If answering requires a support request to the vendor, they are not — the record exists but not where you can use it. Bluente's own view is that this list should be self-service and exportable, because the moment a firm needs it is rarely the moment it wants to open a ticket. The same scoping discipline carries through to contract translation workflows.
Sources and Further Reading
Regulation (EU) 2016/679 — GDPR, official text, including Article 32
Document translation services — system administrators comparing tenancy, SSO and access-log behaviour across tools
Related Reading
Last reviewed 24 August 2026 by the Bluente document engineering team, who build and test the pipeline described here. We update these guides when the underlying standards, regulations or file formats change.
Scope the matter, not the account. See how Bluente handles enterprise access.