How IT Leaders Build Business Support for Cybersecurity Priorities

Stop talking about risk in the abstract and tie it to a customer promise. That one shift got us real support for a security priority.

At Simply Noted we handle customer addresses and message lists, since we write and mail notes on behalf of businesses in real estate, insurance and nonprofits. A few years back I was resisting a slower, more locked down process for how those lists get uploaded, because it added a step and sales hated extra steps. Then our team asked a simple question: what happens to the customer if this list gets into the wrong hands? Suddenly it wasn't a security chore, it was the thing a client trusts us with.

We kept the extra step, but made it painless with a template and a checklist. Deals didn't slow down, and a couple of larger clients even mentioned the process when they signed. When you frame it as protecting revenue instead of slowing it, leaders stop treating it as a cost.

Revenue teams often see cybersecurity as friction because it arrives late, after commitments are sold. The better operating model places security at the planning table with pricing, fulfillment, and customer success. I encourage leaders to identify controls that preserve optionality, that let them enter a market, retain an account, or ship without an emergency exception.

One decision that changed the discussion was refusing to treat a customer security questionnaire as paperwork. Leadership analyzed repeated questions across prospects and found a pattern of stalled deals. Standardizing evidence and ownership shortened sales cycles while reducing exposure. Prioritize security work that removes recurring commercial hesitation and drains time across engineering, legal, and leadership.

The conversation that improved support for security work was when I stopped debating tools and asked the owner one question: what happens to payroll and customer trust if the systems that run scheduling and billing are locked for a week. In the Army signals platoon I learned that radios and networks are not nice to have. They are how the mission moves. Later, coaching operators who always put revenue delivery first, I saw the same pattern: security gets postponed until someone names the cost of downtime in dollars and days.

I ask them to put a simple number on the table, such as one week of lost bookings or one month of rework if customer data is exposed, then compare that to the cost of the next security step. When the risk has a unit, leaders fund it. When it stays abstract, delivery always wins. My job is not to invent fear. It is to make the tradeoff visible so cybersecurity stops competing with revenue as if those were separate worlds.

I help business leaders prioritise cybersecurity by treating it as applied risk management and not a separate technology agenda item. My starting point isn't "Which security tool do we need?" It's "What must this business be able to keep doing, and what could stop it?"

This approach materially changes most exec/board conversations. Revenue, delivery and security aren't independent priorities when the same systems underpin all three. By translating technical exposure into business consequences (ie: interrupted services, lost productive time, compromised client information and the ability to recover) we are then able prioritise work by the risk and business impact, with implementation tasks set to minimise operational disruption.

I also work hard to make any trade-offs explicit - what needs attention now, what can be staged, and what exposure remains if deferrals are needed. Exec teams need a practical decision-making process, not a frightening vulnerability report or an open-ended request for greater budget.

One internal decision that put this approach into practice was structuring Microsolve's SecureStart advisory service as a staged pathway to SMB1001 Gold certification, rather than presenting security uplift as one large, undifferentiated project. It provides a defined destination, manageable steps, visible milestones and predictable advisory costs. Technical implementation is scoped separately, keeping those investment decisions transparent.

The value of that approach is reflected in feedback from Sierra Marketing CEO Marion Di Benedetto "certification initially felt overwhelming, but breaking the work into practical steps and explaining it in plain language made it accessible and manageable." That is exactly the shift I aim for - moving business owners and exec teams from uncertainty about a technical problem to support for an achievable business plan.

My guiding principle is simple. Security should protect the organisation's ability to earn revenue and deliver on its promises and not be presented as an alternative to doing either.

I stopped arguing about risk and started writing it down. Every client gets a cyber risk analysis with the managing director, and twice a year a short written email listing where their open risks are. That one email changed how owners see us: we went from the annoying IT provider to the people who give useful advice. Two of our newer clients had already been hit by ransomware, one with three months of standstill, and that is the conversation that moves budgets.

Putting it in terms of liability risk, especially now that we pay for cybersecurity insurance, definitely helps to convince anyone who might be reluctant to take security concerns seriously. It lets us compare numbers to numbers, which makes the decisions much easier and clearer. If we can generate X more revenue at the cost of a Y increase in insurance premiums, all we have to do is math.

Security gets support when it's part of delivery instead of a separate queue. We treat security work like feature work: every feature ticket has to meet the same security bar, whether that's access control, infrastructure changes, scripting, or third-party libraries. Platform security is the baseline and isn't up for negotiation, and feature security gets reviewed as part of the feature itself. Framed that way, leaders aren't choosing between security and revenue on every ticket.

For risks that do compete for time, the job is making the tradeoff visible ahead of time. If a remediation isn't implemented because of budget, timing, or business resistance, that risk gets documented, communicated to leadership, and revisited regularly. When leaders understand what isn't getting done and why, they make a real decision instead of getting surprised later.

The decision that built the most support was going through SOC 2 for our own platform. It forced security into how we build, and committing to documentation at each step paid off when we put together our audit evidence. Work we'd already documented didn't need to be reconstructed, which turned what's usually a slow audit into an efficient one. That's a result business leaders understand.

The last piece is ownership. A security finding with no one accountable for fixing it stays a recommendation. Assign an owner, define what done looks like, and protect time in the sprint to do the work.

---

Deleted by user

We asked our leadership team to consider which incident could cause the greatest loss of trust, even without an immediate financial impact. The answer was a preventable exposure of personal information. This shifted our focus from short-term targets to the long-term trust needed to retain customers and partners. It also helped us recognize that protecting information is essential to maintaining strong relationships.

We then made privacy safeguards part of launch readiness rather than leaving them until the final review. We gave teams a clear checklist and a defined path to raise concerns when changes created uncertainty. This helped us include security in our regular processes. It also reduced last-minute debates by making trust a requirement for every launch rather than an optional improvement.

I translate every security item into the thing the owner already tracks: booked jobs, leads, and days the team can't deliver. A phishing breach is a week of frozen invoicing and an apology email to every contact. That gets a yes faster than a threat report ever will.

My ranking is simple. First, anything that can stop revenue today: the email domain, the website login, the ad account, the CRM. Second, anything that exposes contact data. Third, everything else waits. A small business can't fund a twelve-item roadmap, so I pick the two items that protect income and put a date on each.

The decision that gets the most support is a small one. I ask who can currently log into the Google Ads account, the website admin, and the email domain, and what happens if one of those people leaves angry. Owners usually go quiet, because the honest answer is that nobody knows. Turning on multi-factor login and adding a second admin takes an afternoon, and it costs almost nothing next to losing an ad account mid-campaign.

Adoption is already broad. McKinsey reports 78% of businesses use AI in at least one function, so the tools touching company data keep multiplying. Every new one is another login someone has to own.

Cybersecurity becomes a leadership priority when it is treated as protection for trust, not merely protection for systems. Trust affects whether clients share information, whether employees act confidently, and whether partners believe commitments will be honored. Those are commercial concerns, even when the underlying issue is technical.

One conversation that produced stronger support focused on the cost of uncertainty after an incident. The team considered how long it would take to determine what information was affected, who needed to be contacted, and which records could still be relied upon. That made the value of preparation immediately clear. Leaders supported the priority because it reduced confusion at the exact moment when clarity would matter most.

Business leaders do not need another risk register. I have found they need to see the point at which a deferred weakness becomes embedded in a launch, customer workflow, or data model. Priorities are easier to fund when remediation is weighed against changing assumptions customers and engineers already rely on.

A product organization planned self-service role management, but viewed authorization testing as final verification. The decision improved when the team modeled one failure, a manager granting access beyond intended scope. That scenario affected trust, support workload, and the feature's credibility. Authorization design entered the delivery plan early, preserving release confidence and preventing a last-minute scramble.

I start by translating security work into terms that leadership understands, like revenue at risk or customer trust. For example, instead of giving a vulnerability count, I'll use "this gap could stall our largest client's renewal".

My approach has 3 parts: First, I rank work by business impact and not by risk scores, as a medium-rated flaw on a system that handles customer payments outranks a critical-rated one on an internal test system. Second, instead of giving a long list of things, I give like a short list, usually three items, each with owner, effort estimate, and what happens if it slips. Third, I look for fixes within our existing resources.

Leasers shouldn't choose between security and delivery. Show them how the security priority protects the delivery goals, then offer the version that costs them the least.

I have found that cybersecurity becomes easier to fund when it is treated as a partner-management discipline. Agencies and clients exchange access, files, approvals, and sensitive commercial context across many touchpoints. Every unclear boundary creates friction, especially when multiple organizations share responsibility for a deadline.

A constructive decision was to define a minimum security readiness standard before adding a new external collaborator to a recurring workflow. It covered ownership, approved communication channels, access duration, and exit procedures. The standard did not complicate partnership building. It made expectations clearer from the outset and prevented difficult conversations later. Leaders backed it because mature partners value predictability, and predictable operating conditions support retention far more effectively than reactive cleanup after trust has been damaged.

In application security, I have found that it is difficult to gain support for security work if the conversation focuses only on vulnerability severity. Business leaders also need to understand what the issue means to the organization. I try to explain factors such as whether the application is internet-facing, how exploitable the issue is, what data or business function could be affected, and what controls are already in place.

One approach that has helped is discussing the available options instead of presenting security as simply blocking delivery. If an issue cannot be fully remediated immediately, we can evaluate whether temporary controls can reduce the risk while a permanent fix is planned. Any remaining risk should have clear business ownership and a review date.

I have found that these conversations become more productive when leaders can see both the security risk and the delivery impact. It allows security priorities to be based on actual business risk rather than severity scores alone.

Two things have helped us at Streamrise get security work prioritised against delivery: describing the risk as one plain sentence about customers, and refusing to count a fix as done until it is in production.

The case. On 9 September, during an unrelated audit of customer compensation, we found an SQL injection in our customer API. The endpoints behind order history and balance history built database queries by pasting user input straight into the SQL, and they were reachable with an ordinary customer login. The conversation with the business side did not need any security vocabulary. It was one sentence: "Any customer could read other customers' orders and balances." The decision to fix it was made the same day, and the code was corrected the same day.

The lesson came afterwards. The corrected code sat outside production for 15 days. It only reached the live servers on 24 September, together with fixes for about 25 similar places found by a follow-up audit. For those two weeks we had, in practice, a known and documented vulnerability that everyone believed was closed, because the ticket said "fixed".

What changed in how we argue for security work: 1. Translate the risk into who can see or do what. "Customer A can read customer B's balance" wins a priority discussion that "unsanitised input in the query builder" loses. 2. Track security fixes to the deploy, not to the commit. The status that matters is "live on production since", with a date. 3. When one hole is found, budget for the audit that follows. The first finding is rarely alone; ours became about 25. 4. Use the fact that existing safe helpers were already in the codebase. Fixing it right was cheap; the expensive part was the delay.

If you need one line for leadership: a security fix that is not deployed is a known vulnerability with paperwork. Asking "when did it reach production?" in every status review costs nothing and would have saved us those 15 days.

I compare security work with a delivery deadline by naming the workflow an incident could interrupt and the recovery it would require. A risk score on its own loses to a dated release. Leaders can weigh a narrow preventive change against the cost of accepting a credible failure path.

A phishing email led one account to authorize a rogue OAuth app. Through the API, the app created an admin user, wrote fake leads, changed the stage of a live deal and sent phishing mail from our domain. Recovery took a working week. We deleted the rogue admin, revoked third-party apps on the affected account and ended its active sessions. We also regenerated API credentials and restored the data. The API usage dashboard gave us the only durable signal; no security alert caught the activity. A leader looking only at an abstract security score wouldn't see the disruption to the CRM and the work of restoring it.

After the incident, we decided to put internal services on a different domain from the one we use for bulk mail. A compromised sender can hurt that domain's reputation, and services sharing it inherit the fallout. The domain was delisted the following month. The decision gives me a specific way to discuss support for a security priority: show the business workflow at risk and the smallest change that contains the failure path. When a release competes for time, put the possible recovery work beside its deadline and ask leaders which exposure they are prepared to carry.

I help leaders make the trade-off concrete by linking security requirements to the controls, owners, and evidence behind them, then prioritizing based on exposure. At QuickTrust, our compliance platform maps framework requirements and customer security questions to a company's policies and controls. For example, if a gap affects a live product or customer-facing process, that work takes priority over a documentation-only change, which can wait for the next review cycle. This gives teams a clear reason to support the security work while keeping lower-risk delivery work moving.

I try to explain what could go wrong for the customer before I talk about the security rating.

For one subscription-management release at a major consumer streaming platform, we wanted account-ownership checks and tests before expanding self-service billing. A signed-in user should only be able to change their own subscription. Logging in wasn't the whole check.

What helped was walking through an unauthorized cancellation. The customer had paid, but could lose access. Then support would have to work out what happened and fix it. That was a much clearer reason to do the work than a severity label.

We settled on a smaller launch. The ownership checks and tests for attempts to change another account's subscription had to pass before release. Other cleanup got an owner and a review date.

The scope mattered. Product could see what was still going to ship, and engineering had a clear condition to meet. Asking people to support "better security" leaves too much open. This gave them an actual decision.

Be specific about what has to be safe before you ship.

The conversation that changed everything for me was when I stopped talking about security in security language and started talking about it in money language. I learned this the hard way at MyTona, where I spent about eight years building backend systems for mobile games with around 50 million users.

Our product team wanted to ship a new social feature before the holiday season. I kept saying we needed to fix an authentication vulnerability first. They kept pushing back because "no one has exploited it yet." So I changed my approach. Instead of explaining the technical risk, I pulled the numbers: our average revenue per user was about $0.12 per day, we had something like 3 million daily actives on that game, and the vulnerability could expose session tokens for roughly 40 percent of those users. I put it on one slide. "If this gets exploited during the holiday push, we lose $144,000 per day in revenue from affected users who churn, plus whatever the breach notification costs." That conversation took maybe 15 minutes. The fix was prioritized that sprint.

At Softline Solutions now, where we manage cloud infrastructure for about 1,500 corporate accounts on Google Cloud Platform, I use this same framework with clients all the time. We built what I call a "risk-to-revenue" translation layer in our quarterly reviews. Every security finding gets mapped to potential business impact in dollars, not just severity ratings. A "critical" vulnerability means nothing to a CFO. "$340,000 in potential regulatory fines plus two weeks of remediation downtime" gets their attention immediately.

The one decision that improved support most was making security metrics part of the same dashboard as business KPIs. When leadership sees uptime, revenue, and security posture on the same screen, security stops being a separate conversation that competes for attention. It becomes part of how the business runs. We saw security budget approval time drop from an average of three weeks to about four days after we made that change.

I try to turn a disagreement about security and delivery into a staged decision with observable evidence. At Market Brew, one such decision was how much access to give the AI system managing our internal engineering agent fleet.

We started with read-only access. After a few weeks of observing its decisions, I was confident enough to expand its authority to manage the fleet doing the work. Routine agent-managed backups and improvements in recovery also increased my confidence in handling accidental overwrites. That is my account of this internal workflow, not a claim that backups eliminate every security risk.

The useful decision was to begin with a narrower operating scope, learn from actual behavior, and then reconsider the access boundary. It gave me a way to evaluate the security concern alongside the delivery benefit, instead of choosing between permanent restriction and immediate full access.

My advice is to make the decision specific: which system, which actions, what evidence supports expanding its authority, and how will you recover if a change goes wrong? This example concerns our internal agent fleet, separate from the customer-facing Market Brew MCP connection.

To get business leaders to prioritize cybersecurity over short-term revenue goals, I tie the defense directly to operational delivery. When you frame email security not as IT overhead but as protecting the primary channel generating sales, the budget conversation flips completely.

The turning point usually happens around deliverability and domain spoofing. In my work with email authentication at Valimail, the most effective discussion isn't about abstract breach risks. It's showing executives what happens when spoofed domains cause genuine customer communications and marketing outreach to land in spam or get blocked by receiving mailboxes entirely.

Treating protocols like DMARC and SPF as deliverability enablers rather than pure compliance burdens aligns security directly with business outcomes. Once leadership sees that broken authentication directly stalls revenue pipelines, enforcement stops being viewed as a roadblock.

1. I don't ask leaders to choose between security and money. Rather, I show them where their existing interests already intersect with their desired security. At RankAISearch, most of our risk comes from third-party plugins, scripts and API keys used for our automation. The same automation is used to generate and update pages on a site in order to get pages loaded, indexed and cited by AI search engines. If a site gets hacked or stuffed with spam, it can get flagged by Google and result in lost leads. Most of the numbers leaders are already tracking in Google Search Console or Bing Webmaster Tools relate to security risk as well. Thus, I connect each needed security action to corresponding numbers that leaders already care about. And I ask for very small change(s) that can be written down and verified a week later. Since the smallest change(s) with clear before-and-after situations are always approved, there's never a need to agree to implement a large set of "harden everything" actions.

2. An audit of our own site uncovered hidden "missing headings" of text in our published pages, added by an SEO plugin that none of us had even realized was modifying content. The fact that this was happening and nobody had noticed was far more compelling than any document outlining the "proper" way to "harden" a site. We decided to begin to schedule and document audits of all 3rd party plugins and scripts in use on our site and to remove them if we weren't using them. I've also set automation scripts up to run with the minimum amount of access required to complete their functions. Again, I have to stress that this is all based on the findings of one audit on one site. However, the cheapest thing any site could do right now is to view the HTML source of their own home page and ask the simple question, "Do I know why I put every single line of that there?" If the answer is "no," then that is the place to start.

Security reporting fails because it measures activity rather than exposure. A leader may see training, patched devices, or closed tickets, yet not know whether payroll, customer communications, or order fulfillment can continue after an account compromise. Metrics should answer what business capability is protected and where the point of failure sits.

I encourage a short monthly review built around exceptions, not a long technical dashboard. Identify the critical workflow, its owner, its recovery method, and the unresolved condition that could interrupt it. One useful decision requires a risk owner to select a remediation date or explicit acceptance. That distinguishes known risk from neglected risk.

Security loses budget fights when it is argued in technical language. It wins when it is argued in business language: what stops working, what a day of it costs, and what clients would think if they knew. So the conversation I have with owners skips the threat catalog and goes straight to exposure they can picture.

The version that lands hardest right now is the AI conversation. Most leadership teams picture their security risk as somebody breaking in. When I walk an owner through the AI tools the team adopted on their own, with client information sitting in personal accounts outside company control, the priority changes on the spot. It stops being an IT expense competing with revenue and becomes protection for the client trust the revenue depends on. The decision that follows is small and funded the same day: inventory the tools, move the work into company owned accounts, and write one plain rule for what never gets pasted in. Prioritization gets easy when the risk has a face and the first fix has a price an owner can say yes to in one meeting.