Internal access controls are the part you cannot verify

Every privacy claim so far in this series has been about outsiders - what a breach would expose, what a third party sees, which law applies. There is a separate question that has nothing to do with attackers or subprocessors: which employees of the company you uploaded to are able to open your file, and what stops them doing so out of curiosity rather than necessity.

Why this is a genuinely different threat

Encryption in transit and at rest is designed to defeat someone who does not already have a legitimate key. An employee with production database or storage access is not that person - they have the key by virtue of their job, and the technical controls that stop an outside attacker do nothing to stop them from opening a file they happen to have access to. This is not a hypothetical category of risk; access misuse by employees is a documented category in security incident reporting across the industry, distinct from external breaches and usually caused by insufficient internal controls rather than sophisticated attacks.

What "access control" actually means in practice

The baseline is role-based access: only staff whose job requires it - a support engineer investigating a specific reported bug, an infrastructure engineer maintaining the storage system - can reach stored images at all, and that access is scoped as narrowly as the task allows. A well-run system logs every access to sensitive data, so that if a file is opened, there is a record of who opened it and when, reviewable after the fact even if it cannot be prevented in the moment. The stronger version restricts broad production access to a small number of people even within engineering, and requires a specific, auditable reason - a support ticket, an incident - before anyone can open a particular file rather than browsing storage freely.

None of this is visible from outside the company. A privacy policy can assert "only authorised personnel" without saying how many people that is, how authorisation is granted, or whether access is logged, and there is genuinely no way for a user to verify the claim directly - which is exactly why the wording is worth reading closely rather than taken as reassurance on its own.

Why this control degrades as a company grows

A five-person team has an easy version of this problem: almost by necessity, almost everyone can see almost everything, because there is no headcount to specialise access control into its own role. That is a real limitation, not a scandal, and it is worth distinguishing from a larger company that has the headcount to scope access tightly and chooses not to. As a service grows, the honest expectation shifts: broad access that was a byproduct of being small should narrow as the team does, support tooling should move from "open the database" to "open the one record tied to this ticket," and the absence of that narrowing over time is itself a signal worth noticing, separate from whatever the policy currently claims.

What a policy that has actually thought about this says

Look for specifics rather than a blanket assurance: a stated number or role for who can access uploads, a mention of audit logging, a description of when support staff are permitted to view a user's file - usually only with the user's own request or explicit consent, rather than by default. Rate Cock publishes exactly this: access is role-limited, logged, and support staff can only view a specific upload when a user has opened a ticket referencing it, which is the level of specificity this question deserves. The same standard is worth applying anywhere a photo sits on someone else's server, including the internal handling behind a recorded measurement and how a human reviewer's own access is scoped and logged - a person doing the reviewing is, after all, exactly the kind of internal access this question is about, just made explicit rather than incidental. Comparing tools on this axis is harder than comparing them on score, precisely because the answer is not visible in the product. It sits alongside who can see an upload once it has passed through server logging and what a breach would actually expose as one of three questions a policy answers, half-answers, or skips.