The Power of “Yes, And”: How CISOs Become Business Enablers Without Compromising Security

The views expressed are my own and do not represent those of my employer.

A business leader walks into your office with a new initiative. She wants to move a critical workflow to a SaaS platform your team has never evaluated. She is excited. Her team is ready. The timeline is Q1. And the first thing she hears from the security team is: "No, that's not approved."

She leaves frustrated. She routes around you next time. Six months later, you find out her team deployed the platform anyway. No security review. No data classification. No SSO integration. No audit trail. Because when the answer is always "no," people stop asking.

This is how CISOs lose influence. Not through technical incompetence. Not through bad intentions. Through a consistent pattern of leading with constraints before ever establishing partnership. And the cruel irony is that this posture, which feels like rigorous security leadership, actually produces worse security outcomes than a collaborative approach would.

The Hidden Cost of Always Saying No

Most security leaders believe they are doing their job when they default to no. And sometimes no is the right answer. But the pattern of leading with no creates compounding consequences that make organizations measurably less secure over time.

When business leaders learn to expect resistance from security, they stop bringing security into conversations early. Projects get scoped, vendors get selected, and platforms get provisioned before anyone from your team gets a seat at the table. By the time security is involved, the decision is effectively made. You are no longer shaping the outcome. You are an obstacle standing between the business and something they have already committed to.

The risk decisions do not disappear. They move underground. They happen in email threads you are not on and in vendor meetings you were never invited to. The business continues moving. Security just stops being part of how it moves.

I have watched this play out across multiple industries. A CISO with deep technical expertise and genuinely sound judgment gets bypassed because people have decided it is faster to act first and ask forgiveness later. The security function ends up reacting to risks that were already embedded in production rather than shaping decisions before they became risks. That is a terrible operating position. And it does not reduce risk. It just removes security from the room where risk decisions get made.

💡 Pro Tip Before your next stakeholder meeting, ask yourself one question: does this business leader come to me early in their process, or late? If they consistently arrive after key decisions are made, that is a signal. They have learned that early engagement with security creates friction. The fix is not to lower your standards. It is to change what early engagement feels like.

What "Yes, And" Actually Means in a Security Context

The phrase "Yes, And" comes from improv comedy, where it is the foundational rule that keeps scenes moving. You accept what your scene partner gives you and build on it, rather than blocking it. Applied to security leadership, it is a practical communication shift that changes the entire dynamic of how your function interacts with the business.

"Yes, And" does not mean unconditional approval. It does not mean accepting unmanaged risk or abandoning controls. What it means is that you lead with acknowledgment before you lead with constraints. You establish yourself as a partner in the business's objectives before you introduce the requirements that responsible execution demands.

Here is how the same conversation sounds under each model.

Under the default security posture: "No, that SaaS platform hasn't been approved. We'd need to run a full vendor risk assessment and it's not on our roadmap this quarter."

Under the "Yes, And" posture: "Yes, I can see why your team needs this capability, and I want to help you get there. Here is what we will need to work through together: SSO integration, data classification for what goes into the platform, and a vendor risk assessment. Let me give you a realistic timeline and we can work backward from your Q1 target."

The security requirements are identical. The controls are the same. What changed is whether the business leader leaves feeling like security helped her or blocked her. That perception determines whether she brings security into her next initiative early or routes around you entirely.

This is not a soft skill or a communication trick. It is a strategic decision about how security functions inside your organization. CISOs who get this right are not compromising on standards. They are ensuring that their standards actually get applied, because the business is bringing them into the process early enough to matter.

Applying It to Real Situations

The "Yes, And" framework looks different depending on the situation, but the structure is consistent. Acknowledge the business objective first. Then introduce the security requirements as the path to achieving that objective responsibly.

New SaaS Tool Requests

The no-first response is to reject the tool because it has not been through your approval process. The "Yes, And" response acknowledges the use case and lays out what responsible deployment requires. SSO. Logging. Data classification. A vendor risk review. You still need every one of those things. The difference is that you are presenting those requirements as the path forward rather than as evidence that the answer is no.

Third-Party and Vendor Access

The no-first response is to deny external access to production environments on principle. The "Yes, And" response confirms that vendor access can support operational continuity and defines what responsible access looks like. Time-bound sessions. MFA. Audit trails. Least privilege scoping. You get everything you need from a security standpoint. The vendor gets the access that supports the business. Nobody loses.

New Digital Initiatives

The no-first response is to cite unacceptable risk levels without offering a path forward. The "Yes, And" response confirms that the initiative aligns with strategic priorities and explains what the architecture needs to look like for the risk to remain within acceptable bounds. You are not approving risk. You are defining the conditions under which the business can move forward responsibly. That is exactly the role a CISO should be playing.

🔑 Key Tip When a business leader brings you a request, resist the impulse to start evaluating risk before you finish understanding the objective. Ask two questions first: what business problem is this solving, and what does success look like for their team? Those answers give you the context to frame security requirements as enablers rather than obstacles.

Why This Builds Credibility, Not Weakness

Some security leaders push back on this approach. They worry that leading with "yes" signals they can be pushed around. That if they start accommodating requests, they will lose the authority to draw hard lines when they genuinely need to. I understand that concern. I have had it myself.

In practice, the opposite is true.

When business leaders experience security as a function that helps them achieve their objectives, they become more receptive when security says no. They have evidence that security is not reflexively obstructive. So when security does draw a hard line, they trust that there is a real reason behind it. The rare no carries more weight, not less, because it is embedded in a pattern of collaborative engagement.

The CISO who says yes with conditions ninety percent of the time has vastly more credibility when they say no than the CISO who defaults to no sixty percent of the time and grudging yes the other forty. Trust is built through consistency and track record. When the business learns that early engagement with security produces useful outcomes, they engage early. That means you are shaping decisions before they are made, influencing architecture before it gets deployed, and identifying risks before they get embedded in production. That is exactly where security needs to be.

And when a request comes along where the risk is genuinely unacceptable and there is no responsible path to yes, you still say no. But now you have the relationship equity and the track record to make that no stick. Business leaders are far less likely to route around a security function they trust than one they treat as a veto machine.

💡 Pro Tip Develop your security requirements in advance for the categories of requests you receive most often. New SaaS tools, third-party access, cloud migrations, data integrations. If you already know what conditions you need in order to get to yes in each category, you can respond quickly and constructively rather than appearing to deliberate for weeks. Speed of response matters to business leaders. It signals that you are actually engaged with their reality.

Getting Organizational Support for This Approach

Shifting from a "department of no" posture to a business enablement model is not just about changing how individual conversations go. It requires organizational alignment. Your team needs to operate from the same framework. Your stakeholders need to understand the shift is intentional. And your executive leadership needs to see it reflected in outcomes, not just in communication style.

Start with your own team. If your security analysts, architects, and engineers are conditioned to lead with risk identification and policy enforcement, you need to retrain that instinct. This does not mean deprioritizing risk. It means building the habit of understanding business context before delivering a security judgment. Run through real scenarios in team meetings. Ask: how would we handle this under the "Yes, And" model? What would we need in order to find a path to yes? What does that path look like for the business? Over time, this shapes how your team approaches every stakeholder interaction.

Then work on the stakeholder relationships directly. Identify the business leaders who interact with security most frequently. Have an explicit conversation about how you want the relationship to work. Tell them that your goal is to help them move fast and move securely, and that you want to be involved early enough in their processes to make that possible. Then back it up with consistent behavior. Every time someone brings security in early and walks away with a constructive response, that becomes evidence of a relationship worth investing in. Those interactions compound.

At the executive and board level, frame this as a risk management strategy. CISOs who are seen as business enablers retain seats at the table when strategic decisions get made. They get pulled into planning conversations. They have influence over acquisition decisions and technology investments before those decisions create security problems. That influence translates directly into a stronger security posture for the organization. When your CEO or board asks how security aligns with business objectives, the "Yes, And" posture is the answer you want to be able to demonstrate with examples, not just describe in principle.

Consider creating a lightweight intake process for new technology requests that feels collaborative rather than bureaucratic. A brief intake conversation with a clear timeline and a dedicated security point of contact gives the business a positive experience of early engagement, which reinforces the behavior you are trying to build. Make it easy to bring security in early and people will do it.

🔑 Key Tip Track your engagement pattern as a metric. Are business leaders coming to security before or after key decisions? If they are consistently arriving late, that is not a scheduling problem. It is a relationship problem. Measure it, talk about it internally, and treat early engagement rate as an indicator of how well your security function is perceived. When that number improves, your risk posture is almost certainly improving with it.

Key Points

Defaulting to no does not reduce risk. It removes security from the room where risk decisions get made, and the decisions still happen without you. Leading with yes to the business objective and and to the security requirements keeps security embedded in outcomes that actually matter. The controls do not change. The sequence does, and that sequence determines whether business leaders bring you in early or route around you entirely.

The rare no carries far more weight when it comes from a function that has demonstrated a consistent pattern of finding paths to yes. Credibility is built through track record, not through authority. Business leaders accept constraints more readily from partners they trust than from gatekeepers they have learned to avoid.

Executive and board credibility for the security function depends on security being seen as a business enabler. That perception cannot be declared. It has to be earned through consistent behavior over time, one stakeholder interaction at a time. Start building that track record now.

Pro Tips

Before any conversation where you expect to deliver difficult news, identify what yes would require. Even if the requirements are significant, presenting a path to yes is more productive than presenting a wall. If there is genuinely no responsible path to yes, say so clearly and explain why. But make sure you have actually looked before you conclude it does not exist.

Role-play the "Yes, And" model with your security team before it matters. Pick real recent requests and walk through how the conversation would have gone differently. Build the muscle memory so that when a high-stakes request lands, your team's instinct is to find the path rather than to reach for the policy document.

Pay attention to which business leaders never bring security problems to you. Those are the relationships that need the most work. Reach out proactively. Ask what they are working on. Show up as a resource before they need to ask for one. The leaders who trust security the most are almost always the ones who have had positive experiences with it. Create those experiences deliberately.

Pitfalls to Avoid

Do not confuse "Yes, And" with approval without conditions. The "And" carries the full weight of your security requirements. If you lead with yes and then fail to enforce the conditions, you have not adopted a new framework. You have just lowered your standards. The model only works if the business understands that yes is conditional on requirements being met, and that you will follow through on every one of them.

Avoid trying to apply this framework retroactively to a relationship that is already adversarial. If a business leader has learned to route around security, one good conversation will not undo that pattern. You need consistent behavior over an extended period. Set expectations explicitly, deliver on them reliably, and give the relationship time to rebuild. There are no shortcuts here.

Do not let the "Yes, And" approach become a rationalization for absorbing unacceptable risk. The goal is to find responsible paths to business objectives. When a request represents risk that cannot be managed within the constraints the business is willing to accept, you still need to say so directly and clearly. The framework is a tool for enabling good outcomes. It is not a way to avoid difficult conversations.

💭 Final Thought

Security influence is earned through track record, not through authority. The CISOs who have the most impact inside their organizations are not the ones who say no the most. They are the ones the business trusts enough to bring in early, which means they are actually shaping the decisions that matter. That trust is built one conversation at a time, one stakeholder interaction at a time, through a consistent pattern of finding paths forward rather than building walls. "Yes, And" is not a soft approach to security leadership. It is a harder and more disciplined one, because it requires you to actually solve the problem rather than simply decline to engage with it. Get that right, and security stops being the department of no. It becomes the function that makes the business possible.

If this resonated with you, subscribe to InfoSec Made Easy for practical insights on security leadership and what it actually takes to run a security function. And if you are working through this shift from enforcer to enabler at your organization, drop a comment below. I would genuinely like to hear how it is going.