Say no to a risky feature by describing the specific harm in terms the requester cares about, offering at least two safer alternatives, and making the final decision visible. A flat refusal teaches people to stop asking you. A reshaped yes keeps you in the conversation early, where your input is cheapest.
Start by checking you are right
Before objecting, test your own reasoning. Can you describe what would happen, to whom, and how likely it is? "This feels insecure" is not an argument. "Any logged in user could read another customer's invoices by changing a number in the URL" is one.
If you cannot state the harm concretely, ask a question instead of making a claim. Often the answer shows the risk is smaller than you feared, or larger.
Translate the risk
Product and business colleagues weigh revenue, deadlines, customer trust and legal exposure. Speak in those terms.
- Instead of "this violates least privilege," say "if one support login is stolen, an attacker sees every customer account."
- Instead of "we have no encryption at rest here," say "a lost backup would force us to notify customers."
Keep the language plain and the scenario short. One realistic story beats a list of ten theoretical ones.
Offer options, not a wall
Bring at least two alternatives to the meeting.
- Ship with a limit: launch to a small group, cap the data exposed, or turn it off by default.
- Ship with a control: add review, rate limits, logging or approval for the risky action.
- Ship later: name the one piece of work that makes it safe and give a realistic date.
- Do not ship: only when the harm is severe and the benefit does not justify any version of it.
Putting the options side by side moves the discussion from "you versus us" to "which tradeoff do we pick."
Make the decision and the owner visible
If the business accepts a risk you raised, that is a legitimate outcome. Write it down: the risk, the option chosen, who accepted it, and a review date. A short note in the ticket or a line in a risk register is enough. This protects the team and gives the next person context. See how to set up a security exception process for a lightweight format.
Do not agree quietly and then complain later. Either the decision is recorded or it is not a decision.
Know your real stop points
Some risks are not yours to trade away. If a feature would break a legal obligation or expose regulated data without protection, escalate to whoever owns that obligation rather than negotiating alone. Decide ahead of time, with your manager, which categories those are, so you are not inventing the rule in the middle of an argument.
Quick check
What if the requester just wants it shipped by Friday?
Offer the smallest safe version that can ship by Friday, such as a limited release with logging. If none exists, state the cost of the delay and the cost of the risk, and let the accountable owner decide on the record.
Is it ever right to refuse outright?
Yes, when the harm is severe and no version reduces it to an acceptable level, or when the feature would breach a legal or contractual duty. Say why, and escalate if needed.
Last reviewed: 19 October 2026.
