Security Earns Its Budget by Speaking the Language of Revenue

Patrick McKinney's Path Across Coinbase, Dropbox, and Salesforce Reveals How AI Has Rewritten the Playbook

A security leader who frames the work as risk reduction speaks a language the rest of the executive team tolerates without ever really adopting it. The leaders who get funded frame it as revenue-enabled, retention-protected, and headcount avoided, which turns a cost center into a line item the CFO defends. Patrick McKinney has led that approach in security for nearly two decades, and the version he runs today looks very different from the one he started with, as the ground beneath it has shifted significantly.

Patrick is the VP of Security at Invisible Technologies, a company whose product is AI automation itself. Before he landed there, he built security and compliance functions from nothing, starting in the public sector at Salesforce, where he helped earn FedRAMP authorization across offices in San Francisco and Dublin. From there, he joined Dropbox as a founding member of the risk and governance team, building its first SOX and GDPR programs in anticipation of the company's IPO. He later on stood up the first line-of-defense compliance engineering team at Coinbase.

Patrick joined our CEO, Stephen Koza, for our 10th official episode of TechPod Talks to walk us through the lessons and insights woven throughout, as well as what didn’t make the cut. The playbook he refined through experience across many positions, and more specifically across three major brand-name companies, began to break down when he arrived at a company whose product was AI automation. However, the piece he did keep turned out to be the one security leaders underweight the most today. 

Continue reading to learn more about how Patrick decided where AI belongs in a security org, how he vets the vendors selling into that moment, and why he ties every dollar of security spend to something a revenue leader cares about.

The First Question a CTO Should Ask Is When Security Stops Being Their Job

Many technology leaders inherit security by default, either keeping it themselves or handing it off to the IT team until the load becomes unsustainable. Patrick, however, watches for a different signal, analyzing how much time his DevOps, SRE, and QA teams actually spend on security work. Once that accounts for 10% of their time, it signals that a CTO should start thinking about someone else to own it directly. The same logic applies to a head of IT running lean, once security starts pulling meaningful time away from the core job of running an efficient team.

That said, bringing in a new dedicated owner does not mean hiring a CISO on day one. A security generalist can stand up compliance engineering, privacy, and a base layer of controls, getting a company to what Patrick calls a "1.0 level," with the program maturing from there. Patrick has worked with plenty of C-suite leaders, and even the world-class CTOs among them will admit the workload eventually outgrew them before they brought in that generalist.

The deeper decision underneath the threshold is a tradeoff. A CTO weighing this call is really deciding when the risk of a part-time owner exceeds the cost of a dedicated one, and the leaders who read that signal early avoid the scramble that comes with reading it late. Patrick treats security ownership as a maturity milestone every scaling company reaches, best planned deliberately before pressure forces the decision.

The Playbook That Repeated Until It Didn’t 

Patrick's career gave him a repeatable sequence, and he is direct about how well it traveled across his expansive career. The key idea is to design security into a system before the building starts, because retrofitting controls onto a shipped product is slower and more expensive every time.

"Phase two never adds security. So always do it in phase one."

The pattern held from Salesforce to Dropbox to Coinbase with real consistency as each authorization, audit, or program buildout followed a version of the same script he had learned to run. By the time he reached Dropbox, he was already carrying the playbook forward from Salesforce, spinning up a small team to engineer compliance principles into the product and automate manual processes that could not be built in directly. The regulatory specifics changed from enterprise software to file sharing to fintech, but the underlying sequence of thinking security early and building it in stayed stable enough to lean on.

Invisible is where the script stopped fitting cleanly, because the product is AI automation and the security questions that come with it have fewer settled answers. What carried across sits below any specific control or framework, in the discipline of surfacing risk before it becomes an incident. Patrick runs that discipline today through monthly risk meetings that bring his CTO and chief legal officer into the same room to identify problems while they are still forecasts. 

Concretely, bad news does not improve with age, so he escalates early, with metrics to back it up, and that habit has survived every change in industry, company stage, and technology base.

How to Decide Where AI Belongs in a Security Org

The prevailing narrative says enterprises are burning tokens on AI with no return to show for it, and Patrick agrees that the failure is real while pinpointing its cause. Companies chase too many use cases at once, pick the wrong ones, and skip quality controls, resulting in spend without value. His own investments start from the opposite posture, calculating where AI creates advantage before committing to it.

His agentic SOC platform is the clearest example, and the decision ran on economics a CFO would recognize. Standing up an in-house team to monitor security around the clock, every day of the year, would have cost roughly five times as much as the AI-native platform, which reframes the buy as a headcount-efficiency decision more than a technology upgrade. Patrick paired the platform with the vendor's human-managed detection layer so that people monitor the system while the AI performs its parsing, and his team runs quality-control tests quarterly to confirm that the AI surfaces the same findings as the primary logs.

The line he draws between automated and human work is a deliberate governance decision, because AI is not always correct and security demands accuracy. Repeatable, known, solvable problems get automated so the AI can supercharge the team, while anything requiring judgment keeps a human in the loop. His example is precise and familiar to any engineering leader now. A tool that finds a vulnerability and cuts a pull request to fix it still needs human review of that pull request, because closing the vulnerability means little if the fix quietly breaks something else. As he stated: 

"AI should be supercharging humans, not necessarily just replacing jobs one to one."

Patrick builds his team lean and organically, meeting the needs of the business without over-hiring or reaching for new tooling to automate the complex, repeatable work that manual processes could never handle. The result is a security function in which headcount grows more slowly than workload, which is the metric that lets him win the budget conversation.

Why the Judgment Layer Stays Human Even as AI Absorbs the Work

The job-loss narrative around AI has softened, and Patrick lands where the evidence now points. AI can take on a large share of routine work, freeing people to spend more of their time on higher-value contributions.

The reason the judgment layer stays human comes down to a capability AI structurally lacks. It is trained on data from the present and the past, which makes it useful for modeling but limited for forecasting, while the foresight that keeps security and engineering resilient depends on anticipating what has not yet happened. Patrick frames the human contribution as the perpetual question of what comes next, the search for the vulnerability nobody has found and the failure mode nobody has modeled, work that depends on judgment rather than historical data. Stephen frames this as the judgment layer, and Patrick's read on it is direct, stating that AI returns what he calls a “zero-EQ, high-IQ answer,” while a human still has to weigh the tradeoff and own the decision.

Accountability, at the end of the day, makes the point concrete for any leader. Someone has to decide whether to address a vulnerability or accept the risk, whether to pick option A or option B, and that decision needs someone to be held responsible for it. 

Patrick notes that the EU already prohibits AI from making the call on whether to hire or fire, and the same principle extends across the high-stakes decisions a security organization makes daily. The relationship layer reinforces it because a leader's intuition for how the company works and what customers are signaling comes from years of accumulated context.

The Vendor Test That Goes Deeper Than Just the Security Checkbox

The market is full of Series A and Series B companies building genuinely impressive security tooling, and it is equally full of polished demos engineered to wow a buyer under conditions that never match real life. Patrick evaluates vendors with a weighted scorecard built around a few core questions:

• Stack fit: Does it work with what's already in place, since a GCP shop isn't buying Azure-native tooling no matter how good the demo looks?
• Provable value: Can the vendor prove the claim in numbers finance can act on, like two senior engineers now doing the work of six, rather than vague marketing language like "enhances workflow throughput by five times"?
• Security culture beyond the badge: What does the SOC 2 actually represent once you look past it?
• Reputation: What do people who've worked with the vendor say firsthand?

In terms of value, specificity is what separates a real signal from marketing language. A vendor demonstrating that two senior engineers can now do the work of six gives Patrick something concrete to act on, and proof lets him operate those engineers with more leverage while sparing four future hires. That kind of case wins the room because Patrick is selling it to the CISO, the CTO, and finance in a single package.

The diligence a compliance checkbox can't capture is what Patrick weighs most heavily. A SOC 2 from a five-person company and a SOC 2 from Salesforce are the same certificate representing very different realities, so he reads past the badge to the auditor, the control scope, and the systems actually in place. He asks for procedural and guideline documentation and checks the dates on it, treating recently written documentation as a signal that a company is performing compliance for his benefit, and documentation approved months or years earlier by legal and security as a signal that the company is actually living it. 

He weighs reputation the same way, which is how EverOps first earned his trust, when he saw the caliber of the team's work at Coinbase and chose to bring them into Invisible without starting the vetting from zero.

Fundamentals Are the Hedge Against an AI Kill Switch

The question of what AI does to entry-level talent has a clear answer in Patrick's approach, shaped by a father who taught him never to rely fully on technology. Learn the fundamentals first, because a leader who understands why systems are built the way they are makes better decisions than one who only knows how to operate the tool on top of them.

The reasoning is a resilience argument any security leader appreciates. If the AI ever hits its own kill switch and the power stays on, the people who know how to write the code and run the systems by hand keep the business alive, which makes fundamental knowledge a genuine fail-safe. Patrick applies it to how his people should learn, understanding why different programming languages exist and why systems are architected the way they are, then building on that foundation with AI as an accelerant. He holds himself to a standard at forty-one, pairing continuous education in the fundamentals with continuous education in AI tooling, treating both as non-negotiable.

Vibe coding is where he draws a hard line, and his verdict is unambiguous.

"AI is not writing quality code. And if anybody says that it does, they're 100% wrong."

It introduces vulnerabilities and quality issues that a leader who relies on it blindly will inherit, and pointing a vulnerability scanner at the output does not close the gap, since a scanner catches what it catches whether a human or an AI wrote the code. But a human who understands the fundamentals has to stay in the loop regardless. The craft is shifting into something new, and the leaders who keep their teams grounded in why things work will navigate that shift better than the ones who let the tooling paper over the gap.

How to Apply These Frameworks This Quarter

The conversation maps onto decisions engineering and security leaders are making right now. A few concrete places to start might be:

• Tie security spend to revenue language: Reframe your next proposal in terms of revenue enabled, retention protected, and headcount avoided, and bring proof. The case that wins the CFO is expressed in saved time and money, and slower hiring, not in workflow-throughput multipliers.
• Draw your automate-versus-human line explicitly: Automate the repeatable, solvable work. Keep human review for anything where a wrong call carries real consequences. A tool that cuts a fix still needs a person to confirm it hasn't broken anything else.
• Vet vendors past the SOC 2 badge: Score tools on stack fit and demonstrated value first, then read the control scope, the auditor, and the dates on process documentation. Demos are built to wow, so make vendors prove the numbers against your environment.
• Set your security-ownership threshold: Once your DevOps, SRE, or QA teams are spending more than 10% of their time on security, start planning for a dedicated owner before the backlog forces the decision.

How EverOps Supports the Discipline Behind AI Investment

Patrick's conversation frequently circled back to the same discipline: deliberately deciding where AI belongs and where human judgment has to stay in the loop. The security orgs getting positive returns are the ones tying every investment to a business outcome, drawing the automate-versus-human line on purpose, and vetting the tooling past the marketing. AI raises the stakes on every one of those calls, since spend applied without that discipline rarely delivers the value leaders expect.

Here at EverOps, we offer an AI Opportunity Assessment that identifies and prioritizes AI use cases genuinely worth a team's time, evaluating data readiness and technical infrastructure before a single line of code is written. For organizations ready to move past assessment, our strategy consulting and embedded operations engagements will bring the hands-on delivery support that turns a roadmap into production-ready results.

If your team is working through any of the questions Patrick raises here, reach out to our team today to start the conversation.

Keep Up With TechPod Talks

Patrick McKinney joined EverOps’ CEO Stephen Koza for Episode 10 of TechPod Talks. Subscribe to listen to the full conversation on Apple Podcasts, Spotify, YouTube, or the EverOps Podcast Page now. 

Follow Patrick on LinkedIn and the EverOps page for more from the series.

Frequently Asked Questions

What topics does Episode 10 cover? 

Episode 10 features a candid conversation with Patrick McKinney on tying security spend to revenue and retention, when a CTO should hand security to a dedicated owner, how to decide where AI belongs in a security org, vetting vendors past the SOC 2 checkbox, why the judgment layer stays human, and why fundamentals matter as AI absorbs routine work.

Who is Patrick McKinney? 

Patrick McKinney is the VP of Security at Invisible Technologies, an AI automation company. He has spent nearly two decades building security and compliance functions from the ground up, starting in the public sector before serving as an early security technical program manager at Salesforce, joining Dropbox as a founding member of its risk and governance team, and standing up the first line-of-defense compliance engineering team at Coinbase.

When should a company hire its first dedicated security leader? 

Patrick uses a practical threshold that keeps the decision from slipping. Once a company's DevOps, SRE, or QA teams are spending more than 10% of their time on security, it is time for a CTO to plan for a dedicated owner. That first hire does not have to be a CISO, since a security generalist can establish compliance engineering, privacy, and a base layer of controls, with the program maturing in stages from there.

How should security leaders evaluate AI vendors? 

Patrick uses a weighted scorecard that starts with technical stack fit, then weights heavily toward demonstrated value expressed in terms finance will recognize, such as engineers doing more with the same headcount. He vets security culture beyond the SOC 2 certificate by examining the auditor, the control scope, and the dates on process documentation, since demos and checkboxes reveal less than how a company actually operates.

How does this episode connect to EverOps' work? 

EverOps helps technology and security leaders navigate the same questions Patrick covers in this episode, including AI adoption strategy, build-versus-buy decisions, and the operational structure that supports security investments as they become business value. Services like AI Opportunity Assessment, strategy consulting, and embedded operations map directly to the challenges Patrick describes.