The business refuses to block the sanctioned cloud storage everyone uploads to - what do you change instead?
answer
- carriers substitute, read access does not
- concede the destination, take the scope
- each repository has an owner who can refuse
- value of one identity is the metric
- start with the repositories worth taking
basics
~20 sAttack the dependency an operator cannot substitute: how much one standing identity may read and how easily the estate reveals what is worth taking. The carrier stays open; the value of any single compromised or trusted account falls.
solid answer
~50 sAccept the constraint honestly - a revenue-bearing destination is not yours to close, and carriers are substitutable anyway, so closing it would buy minutes. The substitutable thing is the carrier; the non-substitutable thing is read access. Two changes carry most of the value: retire standing broad-read groups in favour of time-bounded, owner-approved access to the repositories that actually hold the objective, and constrain estate-wide content search so one identity cannot enumerate everything it nominally may read. Both cost real friction, and neither is engineering's to decide alone: each repository has an owner who can refuse. So scope it: start with the handful of repositories whose loss would be worst, get those owners to accept the friction, and be explicit with the executive about what you are buying - not a promise that nothing leaves, but a large reduction in what any one account is worth.
go deeper
Understand that some outward paths cannot be closed because the business depends on them, and that the alternative is limiting what any one person is allowed to read.
Explain why closing one carrier buys little: the operator substitutes another permitted path, while read access is the step that has no substitute.
Sequence the work by value - the repositories a targeted actor would want first - and be able to describe the time-bounded, owner-approved access model that replaces standing broad read.
Own the negotiation and the promise. Know who can veto each change, spend a finite friction budget where it reduces the value of a single identity most, and report that value rather than an assurance you cannot honour.
## The constraint is real, so start by conceding it A sanctioned cloud storage destination that the whole company uploads to is load-bearing. Customers receive deliverables through it; suppliers deliver through it; a business owner will refuse to break it, and they will be right to. An answer that begins 'block the destination' fails on contact with the organisation and, worse, would not have worked: carriers are substitutable, so the operator moves to a sharing link, a sync path or an export, and the company has paid a permanent cost for a delay measured in minutes. The principal-level move is to identify what the operator *cannot* substitute and spend the organisation's limited appetite for friction there. ## What cannot be substituted Read access. Every step before the transfer - enumerating, searching, deciding, staging - depends on one identity being permitted to see a large corpus. Halve the corpus a single account can reach and you have not slowed the upload at all; you have made the account worth less, forced the operator to obtain more of them, and lengthened the time they must remain present, which is the budget that actually binds them. Two concrete changes: **1. Retire standing broad-read entitlements.** The typical document estate accumulates groups that grant read across whole business units to anyone who ever needed one folder. Replacing those with time-bounded, owner-approved access to specific repositories is the highest-value change available, and the most painful, because it touches everybody's daily work. **2. Constrain estate-wide content search.** A platform-provided search across everything an identity may read converts vague intent into a ranked candidate list in seconds. Scoping search to the repositories a person actually works in removes that free step. It is also a visible productivity loss, so it needs an owner who will defend it. ## Why this is an organisational problem, not an engineering one None of it is technically hard. All of it is politically hard: - **Each repository has an owner** who can veto a change to its permissions and whose team's throughput pays for it. - **Nobody has curated the estate.** A decade of folders exists with unclear ownership, and the first thing a re-permissioning effort discovers is that no one can say who should have access. - **Friction has a constituency.** People who lose estate-wide search will say so loudly; the risk you removed is invisible by construction. - **The budget is finite.** You get a limited number of changes that inconvenience everyone; spending one on a destination block leaves nothing for the change that matters. So scope it by value, not by coverage: identify the repositories whose loss would be worst - the ones a targeted operator is actually after - and negotiate those owners individually. Estate-wide re-permissioning as a single programme is how this effort dies. ## What you promise, and what you refuse to promise Be precise with the executive. You cannot promise that data will not leave; the paths outward are the paths the business runs on, and a person entitled to a document can always send it. What you can promise is a measurable reduction in the *value of a single identity*: how many repositories one compromised or trusted account reaches, and how long its access lives before someone must re-approve it. Those are the numbers to report, and they are the ones that move when the work lands. ## The insider case is the honest test of the plan An insider entitled to the content defeats every control on the outbound path by definition, because copying is their job. If your plan only makes sense against an intruder, you have built for the easier adversary. Read scope and access lifetime are the two levers that still mean something when the actor is supposed to be there - which is another way of saying they are the right ones. ## Wrong answers at this level Proposing an exception process for the sanctioned destination and calling it done; promising an executive that nothing can leave; treating re-permissioning as a project to be run centrally without owner negotiation; or spending the organisation's entire friction budget on the carrier because it is the part engineering fully controls.
- What do you actually report to the executive as evidence this worked?The value of a single identity: how many repositories one account can read, how many people retain estate-wide read, and how long an access grant lives before re-approval. Those numbers move when the work lands, and none of them requires promising that nothing will ever leave - a promise you cannot keep while the business needs the destination open.
- A repository owner refuses to narrow access because it slows their team. What now?Take the refusal seriously and make it explicit rather than routing around it. Document what one compromised account in that repository would reach, offer a smaller change such as time-bounded access for the outer ring of members, and if they still refuse, record the acceptance with them as the owner. Their throughput is a real cost; the decision is theirs to own, not yours to force.
- Why not run re-permissioning as one estate-wide programme?Because it dies in discovery. A decade-old document estate has folders whose owner nobody can name, and a programme that must resolve all of them before delivering anything delivers nothing. Sequencing by value - the repositories a targeted operator would want - produces a real reduction early and earns the credibility to continue.
saying these in an interview costs you the question
- Proposes blocking a revenue-bearing destination
- Promises an executive that data cannot leave
- Treats re-permissioning as purely an engineering task
- Ignores that each repository owner can refuse
- Builds only against an intruder, not an entitled insider