It's going to happen. You bring a recommendation to leadership. It's the right thing to do from a security, compliance, or legal perspective. And the answer is no.
Not because they don't care. Because the cost is too high, the timing is wrong, or the business can't absorb the impact right now.
This is normal. And if you're in security or compliance and it's never happened to you, you're either not pushing hard enough or you're not paying attention.
The job is to advise, not to decide
This is the part a lot of security professionals struggle with, especially early in their careers. You see the risk clearly. You know what the right control is. You've done the research, built the business case, and presented it well. And the CEO, the board, or the CTO says: "I understand the risk. We're not doing that right now."
That's their call to make. Not yours.
The role of security, compliance, and legal is to identify risk, quantify it as clearly as possible, recommend a course of action, and explain the potential consequences of not acting. That's the job. The leader's job is to weigh that recommendation against everything else: revenue targets, runway, headcount constraints, customer commitments, product timelines, and a dozen other factors you may not have full visibility into.
When they decide to accept the risk, that's not a failure of your security program. That's risk management working as designed.
Where it gets real
Here are the scenarios I see regularly:
The security tool that costs more than the company can justify. You want a SIEM. It's $40,000 a year. The company has 25 employees and $2M in revenue. Leadership says no. They're not wrong — you can get meaningful visibility with cheaper alternatives and revisit the SIEM when the company grows into it.
The compliance control that slows down engineering. You recommend mandatory code reviews for every pull request with a 24-hour SLA. Engineering leadership pushes back because it'll slow deployment velocity by 30% during a critical product launch. You compromise on mandatory reviews for production-facing changes and self-merge for internal tooling. That's a reasonable trade-off, not a capitulation.
The vendor that doesn't meet your security standards. You flag that a critical vendor has gaps in their security posture. Sales tells you the vendor relationship drives $500K in annual revenue and there's no viable alternative. Leadership decides to continue the relationship with additional monitoring. They've accepted the risk with their eyes open.
The policy that the board won't fund. You recommend a disaster recovery solution that would cut RTO from 48 hours to 4 hours. The cost is $80,000 a year. The board decides the business can tolerate the longer recovery time given the probability of a full outage. That's a calculated decision, not negligence.
The difference between risk acceptance and negligence
This is the line that matters.
Risk acceptance is when leadership understands the risk, understands the potential consequences, and makes a deliberate decision to accept it based on business factors. That decision is documented. The risk stays on the register. It gets reviewed periodically. If circumstances change, the decision gets revisited.
Negligence is when nobody told leadership the risk existed, or when the risk was communicated and leadership ignored it without any deliberation, or when the decision was never documented and everyone pretends the conversation didn't happen.
Your job is to make sure the first scenario happens, not the second.
How to present risk so leaders can actually decide
Most security recommendations fail not because leadership doesn't care, but because the recommendation is presented in a way that doesn't connect to how they think.
Quantify the business impact. "We need endpoint detection" is a security ask. "Without endpoint detection, a single compromised laptop gives an attacker access to our entire cloud environment. Our cyber insurance requires it, and two enterprise prospects asked about it in security questionnaires last quarter" is a business case.
Present options, not ultimatums. Don't bring one recommendation at one price. Bring three: the ideal solution, a middle-ground option, and the minimum viable control. Let leadership choose based on what the business can absorb. You've done your job by making sure every option addresses the risk to some degree.
Be specific about consequences. "This creates risk" is vague. "If we don't address this and a breach occurs involving customer data, we're required to notify affected individuals within 60 days under HIPAA. Our cyber insurance deductible is $50,000. We could face OCR investigation and fines up to $1.5M per violation category" is specific. Leaders make better decisions with specific consequences, not abstract risk scores.
Separate the urgent from the important. Not every recommendation needs to happen this quarter. Prioritize. Tell leadership what needs to happen now, what can wait 6 months, and what's a long-term investment. If everything is urgent, nothing is.
Document everything
This is non-negotiable.
When leadership accepts a risk, document it. The risk, the recommendation, the decision, who made it, and the date. Put it in your risk register. Review it quarterly.
This protects the company and it protects you. If something goes wrong and a regulator or a customer asks "did you know about this risk?" the answer needs to be: "Yes. We identified it, we recommended a mitigation, leadership made a deliberate decision to accept the risk based on these factors, and we documented it here."
That's a defensible position. "We never discussed it" is not.
The vCISO perspective
As a vCISO, I'm in this position constantly. I advise multiple companies. I make recommendations that I believe are right. And sometimes the founder or CEO says no.
My job in that moment is to make sure they understand what they're accepting, document the decision, and move on to the next priority. I don't take it personally. I don't relitigate it every meeting. I don't go around leadership to make it happen anyway.
What I do is revisit it when the context changes. The company closes a bigger customer with stricter security requirements. A competitor gets breached. A regulation takes effect. The risk calculus shifts and sometimes the recommendation that got a no six months ago gets a yes today because the business context changed.
That's how the relationship works. Security advises. Leadership decides. Both sides need to trust the process.
When to push harder
All of that said, there are times when accepting the risk is the wrong call and you need to say so clearly.
If the risk involves potential harm to people — patient safety, physical security, situations where the consequences aren't just financial.
If the risk violates a legal or regulatory requirement. "We've decided not to comply with HIPAA" isn't risk acceptance. That's a legal exposure that leadership may not fully understand.
If the risk is existential — a vulnerability that could result in complete data loss, a breach that would end customer trust permanently, or a gap that would void your cyber insurance coverage.
In these situations, your job is to escalate, be direct, and make sure leadership understands the severity. Put it in writing. If they still say no, you've done your job. The decision is documented and the accountability is clear.
The bottom line
Security is not a veto. Compliance is not a veto. Legal is not a veto. These functions exist to give leadership the information they need to make informed decisions about risk.
Sometimes the right business decision is to accept a security risk. Sometimes the budget isn't there. Sometimes the timing is wrong. Sometimes the trade-off is worth it.
The job is to advise clearly, quantify honestly, present options, document decisions, and revisit when circumstances change. That's what a mature security program looks like. Not one where every recommendation gets approved, but one where every risk gets a deliberate decision.
Farbod Fakhrai is the founder of COM-SEC, a cybersecurity and compliance consulting firm supporting startups and growth-stage companies. [com-sec.com]