The Security Investment Playbook, Part 1: Core, Context, Commodity

Early in my time at PayPal, I was sitting in a strategy meeting with Sri Shivananda, who was then the company's CTO. We were debating where to invest engineering resources: what to build, what to buy, what to ignore. The conversation kept circling until Sri introduced a framework that fundamentally changed how I think about security investment: Core, Context, Commodity.

It was deceptively simple. And it's been one of the most useful strategic lenses I've used ever since, not just for technology decisions, but for how I lead security teams and allocate their energy.

I want to share it here because I think every security leader needs this framework, especially right now, when budgets are tight and the pressure to "do more with less" is relentless.

The Framework

Every business function and investment falls into one of three buckets:

Core is the secret sauce. These are the capabilities that directly differentiate the business in the market. It's what customers pay for. This is where a company should innovate, take risks, and invest heavily to win.

Context is mission-critical but not differentiating. You must do these things exceptionally well to stay in business, but they don't by themselves drive competitive advantage. If you fail at Context, you lose the business. If you succeed, you stay in the game. The goal here is effectiveness and competence, without over-engineering.

Commodity covers standardized capabilities like payroll processing, basic network connectivity, standard antivirus. These are problems the market has already solved. The goal is efficiency: get the necessary protection at the lowest complexity and cost.

Where Security Actually Sits

Here's the part that stings a little, but it's important to be honest about: in most companies, security is a Context function.

This is not a minimization of our importance. Quite the opposite. We are the foundation that allows the Core to exist. If we fail, trust erodes, and the core business suffers. But we are not the product being sold. We are not the reason customers open their wallets.

What does this mean in practice? It means we must be effective and competent, but we must be careful not to over-engineer solutions that don't directly enable the business to move forward. We are here to enable the Core, not to distract from it.

I know this is uncomfortable for many security leaders. We often feel, rightly, that what we do is critically important. It is. But understanding our strategic position relative to the business isn't about diminishing our value. It's about deploying our value where it matters most.

And here's the thing that took me years to internalize: Context is not a lesser category. It's a different kind of power.

Think about what happens when Context functions fail. When finance gets it wrong, the company restates earnings and the stock craters. When legal gets it wrong, the company faces existential liability. When security gets it wrong, customer trust evaporates overnight and the Core product becomes worthless. Nobody remembers your innovative feature roadmap the week after a major breach.

Context functions are the load-bearing walls of the business. You don't notice them when they're doing their job. But remove one and the whole structure comes down. The fact that security drives trust in the product doesn't mean it shows up on the feature list. But it underpins every transaction customers make. They just don't think about it until it breaks.

The security leaders who struggle most with this framework are usually the ones who are trying to justify their existence by acting like a Core function, running science experiments and building impressive, complex, highly visible programs that look like innovation but are really just expensive ways of doing Context work. I've been that person. I've run those science experiments, built things that made my team look cutting-edge but didn't actually move the needle on protecting the business any better than a simpler approach would have.

Once I accepted that my job was to be the best Context function in the company, not to compete with the product team for the spotlight, everything got clearer. My budget conversations got easier because I could articulate exactly what we were protecting and why. My team got more focused because they understood the mission. And paradoxically, we got more respect from the business, because leaders trust people who understand their role and execute it with discipline.

The Nuance: Your "Internal Core"

Here's where the framework gets interesting for security teams. While security may be a Context function for the broader business, every security organization has its own Internal Core.

Your Internal Core is protecting your specific company.

That requires deep, bespoke knowledge of your specific technology stack, your unique data flows, your organization's culture, and the promises you've made to customers. This is where your team needs to be world-class. This is where your engineers should be spending their innovation energy, solving problems that only exist in your environment.

Everything else? You need to ruthlessly commoditize it.

There's a dangerous trap in security engineering, what I call the "Not Invented Here" syndrome, where we feel the need to build bespoke solutions for standard problems. Why build your own vulnerability scanner? Why architect a custom identity governance tool from scratch? Why write your own threat intelligence feeds?

When you do this, you're gold-plating a commodity. You're spending your best people's time and creativity on problems the market has already solved, and solving them worse than a dedicated vendor would, because it's not your core business.

The Hidden Cost of Going It Alone

Commoditization isn't just about saving money or engineering time. There's a less obvious cost to building everything yourself: you cut yourself off from critical intelligence.

Vendors and partners do their specific thing for a living. A top-tier identity vendor sees the threat landscape across thousands of customers. A specialized MDR provider sees attack patterns across the entire Fortune 500. When you insist on building your own isolated version of these tools, you become an island. You lose the global perspective that only comes from operating at scale across many environments.

I've seen security teams spend months building an internal tool that a vendor could have provided in weeks, and the vendor's version came with threat intelligence from across their entire customer base. That's not just a time savings. It's a strategic advantage the internal tool could never provide.

Putting the Framework to Work

When I share this framework with my teams, I ask them to look at every project in their backlog through this lens:

Is this Core? Does this solve a problem unique to our company that no vendor can solve for us? If yes, innovate relentlessly. Pour your best thinking into it. This is where you earn your keep.

Is this Commodity? Is this a standard industry problem that the market has already solved? If yes, why are you building it? Can you automate it, buy it, or leverage a partner? Every hour your team spends on commodity work is an hour stolen from the problems only they can solve.

Are you listening? Are you extracting maximum value and insight from your partners, or are you trying to figure it out alone? Your vendors see "what good looks like" at scale because they see it every day. That perspective is part of what you're paying for. Use it.

The goal is to focus your team's brilliance on the hard stuff that only you can do, and let the market handle the rest.

The Vendor Relationship Shift

This framework also changes how you think about vendor relationships. Instead of treating vendors as interchangeable suppliers competing on price, you start treating the right partners as extensions of your team.

When a vendor specializes in a capability you've classified as Commodity, they're not just selling you software. They're bringing the accumulated insight from serving hundreds of organizations with the same problem. You're not just buying a tool. You're buying perspective.

That shift, from procurement to partnership, is one of the most underrated strategic moves a security leader can make. It requires trust, which requires investment in the relationship. But the payoff is significant: you get better outcomes in the commodity space, and you free your team to focus on what genuinely differentiates your security program.

Where Your Value Actually Lives

Here's the mental model I keep coming back to: your security team doesn't add value by writing the code for a scanner. You add value by taking the output of a world-class scanner and contextualizing it for your company. You interpret the signal based on your deep knowledge of your business, your technology, your risk appetite, and your customers.

That interpretation, that contextualization, is something no vendor can do for you. It requires institutional knowledge, business relationships, and strategic judgment that only your team possesses. That's your Core. Protect it by not wasting it on commodity work.

The Core, Context, Commodity framework isn't just a budgeting tool. It's a leadership philosophy about where to direct attention, talent, and energy. In a field where the to-do list is always infinite and the resources are always finite, that clarity is worth its weight in gold.