An executive says insider risk is covered because 'we trust our staff'. How do you answer?

## Why this is a judgment question, not a technical one The technical content here is settled: scope is the only knob. What makes it a lead's question is that the person who can approve a scope change also owns the budget, the delivery schedule and the goodwill of the team whose daily work gets slower. You are not looking for the right control; you are looking for the largest reduction in worst case that this person will actually agree to. ## Do not fight the trust claim The instinct is to argue that staff cannot be trusted. It is a losing move for three reasons: it is usually false, it insults the team, and it concedes the executive's framing that the subject is honesty. The move that works is to accept the claim and show that it answers a smaller question than they think. > "I agree, and I am not proposing anything that assumes otherwise. Two of the three ways this hurts us do not involve anyone being dishonest." From there the argument writes itself: the careless export of a customer table into a personal spreadsheet service to hit a deadline; the platform engineer whose session is held by somebody else. Trust is true and irrelevant in both. ## Say what screening actually buys If background checks are cited, be precise rather than dismissive. They are a point-in-time filter aimed at the deliberate subtype, and people's circumstances change after they are hired. That makes screening a reasonable hiring practice and a poor bound on loss. Being fair about what it does buy is what keeps you credible for the rest of the conversation. ## Convert the argument into a decision An executive can refuse an argument indefinitely; they have to do something with a decision. Bring three things. 1. **A short list of capabilities whose loss you would not accept.** Not every permission — two or three. Typically: bulk read of the customer store, and the ability of a role to grant roles. Long lists get deferred wholesale. 2. **The price in friction, stated honestly.** Bounding a platform role means someone waits for an approval during an outage, or a report takes an extra day. If you do not name that cost, the people who feel it will name it for you, later, and your proposal will die on the floor. 3. **A named owner per decision.** "Who decides whether the analytics role can export whole tables" is answerable; "should we do least privilege" is not. ## Concede properly Sometimes the honest answer is that bounding a capability costs more than the loss it prevents. Say so yourself, before someone else does — a security lead who has never recommended accepting a risk is not believed on the ones they refuse to accept. Where a scope cut is genuinely uneconomic, the correct outcome is documented risk acceptance: what is unbounded, whose signature is on it, and the trigger that reopens it — a new data store entering that role's reach, an acquisition, a customer contract that demands otherwise. Then stop raising it. Relitigating a settled acceptance every quarter costs you the credibility you will need when the trigger actually fires. ## What a strong answer sounds like in the room A lead who handles this well does four things in about two minutes: agrees about the staff, splits the category into three, points at the two subtypes trust does not reach, and puts one small, priced, owner-attached change on the table. A weak answer either lectures about human nature or produces a programme-sized proposal that nobody can approve. ## The failure modes to avoid - **Moralising.** Any sentence that implies the team might be dishonest loses the room and the argument. - **Overreach.** Proposing to remove all standing scope everywhere guarantees refusal and burns the one meeting you had. - **Silence after refusal.** If you walk away without a written acceptance, the risk is still there and now nobody owns it — including, when it lands, you.