How to Say "No" Well

Security’s push to avoid being the ‘Department of No’ has overcorrected. In our eagerness to enable, we’ve lost sight of the value of a thoughtful, strategic ‘No.’ This has distracted from a better set of lessons: How to Say “No” Well.

Security is fundamentally a risk management function¹ with a responsibility to counterbalance and pressure test risk-taking decisions.

Saying “No” is a tool, and abandoning it can:

• harm our ability to keep risk to acceptable levels by making security too permissive
• overwhelm our teams with asymmetric work
• remove opportunities to educate and align with partner teams on risk
• optimize for affability over clarity, frustrating both security and the stakeholders we are trying to serve

You still need to avoid Bad Ways of Saying No - prioritize advising on risk, being proactive and explicit, and building consensus - all while being flexible and consistent.

The Department of Yes

The “Security as Department of No” trope is old enough that articles on it carry disclaimers. It evokes a gatekeeping anti-pattern:

Lately, every BSides seems to have a talk on avoiding the “No” and reframing security teams as a “Department of Yes.” These talks impart great lessons from wonderful, thoughtful speakers! But this message risks creating a false premise: that saying “No” is inherently bad and should be avoided at all costs.

The problem? Oversimplifaction. It’s easy to hear that “No” is a failure of communication or alignment, rather than what it often is: a necessary boundary to protect the organization. We don’t hear nearly as much about the value of a well-considered, strategically deployed “No.”

It’s not about whether security should be saying “No”. It’s about whether we’re making the right decisions for the business and presenting them effectively. In these discussions, I often hear shades of toxic positivity, where we prioritize harmony over hard truths, risk acceptance as cargo cult, blindly trusting that risks will manage themselves, and ruinous empathy, where we avoid discomfort at the cost of long-term consequences.

No, Not Like That

Not all “Nos” are created equal. Done poorly, they can damage trust, slow progress, or confuse your audience. Here are the most common pitfalls and how to avoid them:

1. No without context
   A flat “No” without explaining why leaves teams frustrated and unclear about the risks or alternatives. Security’s role is to provide clarity—ensure your “No” includes the reasoning behind it and actionable next steps. Security should not own most risks, so conversations should be advising a business owner about a risk decision, instead of a place for an acceptance or denial. Beware these conversations driving asymmetric work:

   The amount of energy needed to refute under-specified ideas is an order of magnitude bigger than that needed to produce them

2. No too late, or ambiguously
   The later you say “No” in a project’s lifecycle, the more disruptive it becomes. Address risks early, when course corrections are cheaper and less frustrating. Avoid “aggressive passivity,” a disagreement should either turn into a No or you need to disagree and commit.

3. No as a complete sentence
   A “No” should never be a dead end. Offer paved roads—secure, approved paths that help teams achieve their goals safely. Even if a perfect solution doesn’t exist yet, pointing to a timeline or workaround shows partnership and builds goodwill.
4. No too often
   If every interaction ends in a “No,” teams may stop engaging with security altogether. Balance is key—reserve your “pissing people off” budget for significant risks, and enable safe, workable alternatives wherever possible.
5. No too inconsistently
   A “No” from security should follow the principle of least astonishment. Inconsistent decisions undermine trust. Partner teams should be able to anticipate your decision-making based on clear policies, standards, and past behavior. Strive for high autonomy coupled with high trust. .

By avoiding these missteps, you can ensure that your “Nos” aren’t obstacles, rather guardrails that help the organization move forward safely.

No, Better

Instead of shying away from the No, instead invest in getting better at saying it in a constructive way. Your goals are to predict, acknowledge, and abate impact. A good “No” isn’t adversarial; it’s clear, constructive, and backed by evidence. It helps stakeholders understand not just the risks, but the why behind the decision and the paths forward. A strong “No” can protect the company from critical risks while strengthening trust in the security team’s judgment.

The first step is to Earn the No.

This has technical and non-technical components. Technically, offering paved roads and safe alternatives helps you credibly say no to risky practices without gatekeeping. Clear standards, such as around data classification, risk ownership, and policies can help preempt and short circuit disagreements. Stronger, high trust relationships also buy you goodwill to “spend” on necessary Nos.

Having laid the groundwork, you can situationally lean on a variety of Strategies for A Better No.

Start with a shared focus on the business outcomes. You need to be able to agree on those if you expect to agree on anything more granular. Everyone you initially disagree with should be able to center on the business goals as priority. Remember: you have less information on their reality on the ground, and should not expect them to have your context on security risk and priorities.

Take a Pause to establish a shared understanding of the problem. Break down the gap layer by layer: who, what, and how. Is the disagreement primarily about who will do the necessary work? Is it about what data, timelines, or controls are involved? Or is it about the specifics of how the work will be accomplished? If you haven’t clarified “who will do this work,” it’s unreasonable to dive too deep into “how will it be accomplished.”

When disagreeing, make sure you refute the central point, not just a counterargument.

Camille Fournier and Ian Nowland’s new Platform Engineering book offers four variants on “Saying “No” Without Ruining the Relationship”, three of which can be applied to security cleanly.

1. “Not yet, priority call”: in this case, you should be clearly sharing your current priorities that superseded the ask. It’s important to empower the asker with a mix of options and details on how they might help expedite. Highlight how you need to meet existing Commitments and Allotments.
2. “Not yet, technical call”: in this case, you need to take the time to explain the details of why their proposal doesn’t match the current reality of technical capabilities. For example, missing platform primitives. This should come with an explicit timeline when that will change, otherwise the “Not Yet” is functionally a “No.”
3. “No, technical call”: in this final case, your process should resemble the prior one. However, here you must also beware of magical thinking and unsolvable problems.

The first two are fundamentally not disagreements in concept but in timing.

Always remember, If someone isn’t at least a little disappointed, they didn’t hear no. A good ‘No’ is a service, not a roadblock. It protects the business while keeping relationships intact.

Thank you to Ari Kalfus for his invaluable feedback on this post.

---