## TL;DR
Say no with the reason, the policy behind it, and what the requester can do instead. "No, because standing prod access violates our policy; here is the JIT process that gives you what you need in 10 minutes" ends the conversation. A bare "denied" starts a war.

## The error
```text
(Communication task; no error.)
```

## Steps
1. State the decision plainly and early: "We cannot grant X." Expected: clear. Burying the no in paragraph three frustrates everyone.
2. Give the reason tied to policy or risk, not personal judgment: "Our policy prohibits standing production access because..." Expected: reasoned. People accept rules they would fight as opinions.
3. Offer the alternative: the approved path that solves their actual need (JIT elevation, a scoped role, a report instead of direct access). Expected: alternative provided. Most requesters want an outcome, not the specific access.
4. Explain the appeal path: who can override and how. Expected: documented. A no without recourse feels arbitrary; a no with a path feels fair.
5. Log the denial with the reason in the ticket. Expected: recorded. Denials need the same documentation as grants.

## When to use
- Denying access requests
- Policy-based refusals

## When not to use
- Approvals
- Security incidents (different tone)

## Compatibility
- Universal communication guidance

## Variants
### Requester escalates to your manager
Your documented reason and alternative make the escalation easy to defend.
### Repeat requester
Point to the previous denial and ask what changed; do not re-litigate from scratch.

## Why it happens
Access denials feel personal because access feels like trust. Reason plus alternative plus appeal path depersonalizes the decision.

## Edge cases
- Never deny with "because security said so" and nothing else; it erodes trust in both teams.
- Track denial reasons; patterns reveal policy gaps or training needs.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_2uzq8mGJlo9jxAU4mZIQjw