Ask a software company who owns security and you will usually get one name. Ask what that person works on and you get two entirely different job descriptions blended together.
Product security is about the thing customers buy. Threat modelling, secure design review, dependency and supply chain risk in what you ship, the vulnerability disclosure process, the security properties your product actually offers.
Corporate security is about the company that builds it. Employee laptops, identity and access, the SOC 2, vendor review, phishing, the security questionnaire queue.
They share vocabulary and almost nothing else.
The two customers, and why that framing settles most arguments
Every recurring argument about who owns what dissolves once you ask who the customer is.
Product security's customer is the product organization. Its output is judgment delivered early enough to change a design, and its success measure is coverage of the decisions that mattered, not the count of findings. It fails silently, because a design flaw shipped looks identical to a design flaw prevented until a customer finds it.
Corporate security's customer is the business, and increasingly the business's customers. Its output is evidence and unblocked deals. Its success measure is queue latency and audit outcomes. It fails loudly, because a missed questionnaire has a person waiting on it.
Loud failure crowds out silent failure whenever both sit with one person. That is the whole mechanism, and it is not a character flaw in whoever holds the role. It is what a rational person does when one of their two jobs has someone waiting and the other does not.
Why merging them starves one side
The two programs have different clocks, and one of those clocks is external.
Corporate security work is driven by audits, customer questionnaires, and renewal dates. Every one of those has somebody outside the company waiting. Product security work is driven by the roadmap, and its deadlines are internal and negotiable.
Put both under one person with one budget and the external deadlines win every time. Not because the person is making a mistake, but because they are responding correctly to the incentives in front of them. Six months later the company has an excellent evidence library and no threat model for the feature that shipped last quarter.
I have seen this play out often enough to treat it as the default outcome of the merged structure rather than an occasional failure of it.
Why the obvious answer is wrong
The obvious objection is that a small company cannot afford two functions. That is often true, and it is not an argument for merging them. It is an argument for choosing which one to staff and being explicit that the other is deferred.
The failure is not having one person do both. It is having one person do both without anyone naming which one is being deprioritized, so the trade-off happens silently and nobody notices until a customer's penetration test finds something a threat model would have caught.
The discriminating variables
Who is the customer of each program?
The test: for a given piece of security work, who is unhappy if it does not happen? If the answer is a customer's security reviewer, it is corporate. If the answer is a product manager or an end user, it is product. Work that cannot be classified this way is usually work nobody has asked for.
Which one currently has the deadlines?
The test: list the security deadlines in the next quarter and mark each one internal or external. If they are all external, product security is currently unstaffed regardless of the org chart.
Does the product make security claims?
The test: does your marketing, documentation, or contract assert security properties? Encryption, isolation, access control, data residency. Every asserted property is a product security obligation, and the moment a claim appears in a contract it becomes a legal exposure rather than an engineering preference.
Where does the skill actually sit?
The test: who reviewed the design of the last security-relevant feature? If the honest answer is that nobody did, that is the gap, and it is not one that a compliance hire fills.
What product security actually contains
Naming the work, because "product security" is used loosely enough that two people using the phrase often mean different things.
Design-time review. Somebody with security judgment looks at a feature before it is built, specifically at the parts that touch authentication, authorization, data boundaries, or tenancy. This is the highest-value activity in the whole category and the first one dropped when the person is also holding a queue.
Authorization model integrity. In multi-tenant software this is the risk. Not injection, not dependencies. Whether tenant A can reach tenant B's data through some path nobody drew. It needs someone who understands the domain model, which is why it rarely outsources well.
Dependency and supply chain risk in what ships. Distinct from corporate patching, because the exposure transfers to your customers and appears in their third-party risk reviews rather than yours.
Vulnerability disclosure. A public path for researchers, a triage process with a clock, and a decision about whether you pay. Companies without this do not receive fewer reports, they receive them on social media.
Security claims integrity. Making sure what marketing, documentation, and contracts assert about the product is actually true, and stays true after a refactor. This is the one that turns into legal exposure, and it is nobody's job by default.
How the split usually gets made
Three structures, in rough order of how common they are at software companies.
One person, both jobs, corporate wins. The default and the one this piece is warning about. Works while the company is small enough that features are simple; degrades silently as the product grows.
Product security inside engineering, corporate security separate. The structure that works best in my experience. Product security reports into engineering, which is where the context and the credibility are, and is measured on design review coverage rather than on findings. Corporate security sits with operations or compliance and owns the external queue. Neither is the other's boss.
Both under a single head of security with two teams. Works at scale, needs enough headcount that neither team is one person, and needs the leader to actively protect product security's time from the queue. Below roughly forty engineers this collapses back into structure one regardless of the org chart.
The failure mode common to all three is the same: whoever owns product security also being the person who answers questionnaires. If that is true in your organization, the structure on paper does not matter.
Decision table
| Situation | Structure | Owner |
|---|---|---|
| Pre-revenue, no enterprise buyers | One person, product security prioritized | Engineering |
| Enterprise motion, no security claims in product | One person, corporate prioritized | Security or operations |
| Product makes explicit security claims | Two roles, even if one is fractional | Product security under engineering |
| Security product company | Product security is a product function | Product organization |
| Regulated buyers plus a technical product | Two roles, non-negotiable | Separate reporting lines |
Splitting the budget before splitting the team
Even at one person, split the money. It costs nothing and it does most of the work.
Two lines in the security budget, product and corporate, each with its own tooling and its own share of the person's time, written down as a percentage. Then review the actual split quarterly against the plan.
Two things happen. The drift becomes visible, because the review asks a question nobody was asking. And when the company does grow into two roles, the budget history already exists, which turns a contested reorganization into a formality.
It also changes procurement. A scanning tool for the product pipeline and a scanning tool for the corporate estate are different purchases with different buyers, and organizations that fund them from one line habitually buy one tool and use it badly for both.
What changes the answer
A security incident in the product. Reprioritizes everything toward product security for a period, correctly. The discipline afterward is to keep some of that resourcing rather than letting it drain back to the queue once the immediate pressure passes.
A large enterprise customer with a penetration testing right. Contractual testing rights convert product security from an internal concern into an external deadline, which changes the incentive structure described above and is one of the few clean ways to get product security funded.
Under fifteen engineers. Both jobs are part of one person's week and formal separation is overhead. The useful version at that size is a written statement of which one is deferred this quarter, revisited every quarter.
The early warning that product security has been starved
Four signals, in the order they usually appear.
No design review happened this quarter. Not "reviews found nothing". None occurred. This is the first thing to go and the last thing anyone notices, because its absence produces no artifact.
The vulnerability disclosure inbox has a backlog. Researchers are patient once and not twice. A backlog here becomes a public disclosure, and the public version arrives on someone else's schedule.
Someone in sales made a security claim nobody verified. Usually discovered during a customer's technical review, which is the most expensive possible moment.
A customer's penetration test found something structural. Not a missing header. An authorization path or a tenancy boundary. That finding is proof a design review did not happen, and it arrives with a customer attached to it.
If two of those four are true, the trade-off already happened and nobody recorded it. Say so out loud rather than fixing it quietly, because the structural version of this problem returns next quarter unless somebody with budget authority hears about it.
The conversation to have with engineering leadership
This is not a security decision to make alone, and framing it as one is how it fails.
The pitch to an engineering leader is not that product security needs protecting. It is that design-time security review is an engineering practice, like code review or testing, and it belongs to them in the same way. Security supplies the judgment and the standard; engineering owns whether it happens.
That framing works because it is true and because it moves the resourcing argument into a budget larger than yours. It also changes the metric. Once engineering owns the practice, the number to watch is what share of security-relevant designs got reviewed, which is a coverage metric an engineering organization already knows how to run.
The version that does not work is asking for headcount inside the security budget to review engineering's work. That request competes with tooling, lands as overhead, and gets deferred every planning cycle.
What to do Monday
Take the last twenty security tasks your team completed and sort them into two columns: product and corporate.
If one column is nearly empty, you already know which program is unstaffed. Say so out loud in the next leadership meeting, because the silent version of that trade-off is the expensive one.