The feature is two weeks from launch. The engineering team is in final testing. The marketing brief is done. And then the InfoSec lead sends a message that the PM has learned to dread:
"I saw the feature in the staging environment. We need to talk before this ships. There are some security concerns."
Security concerns at T-minus two weeks. Two weeks that will now stretch to six or eight. The authentication flow needs a review. The data encryption at rest isn't meeting the standard. The API endpoint is unauthenticated in a way that creates exposure. Three items, each individually fixable — but together, they represent weeks of engineering rework that nobody budgeted for.
The PM's instinct is to be frustrated. The InfoSec team's instinct — entirely reasonably — is to wonder why they're seeing this feature for the first time two weeks before launch.
The dynamic is identical to the Legal engagement problem, with one important difference: security vulnerabilities in shipped products have consequences that legal compliance issues usually don't. A late-flagged GDPR provision might delay a launch. A late-flagged authentication vulnerability might become a breach six months after launch that damages customer trust, triggers regulatory investigation, and generates the kind of news coverage that defines a company's narrative for years.
Why the PM-InfoSec Relationship Breaks
The adversarial pattern between Product and InfoSec is one of the most entrenched in technology organizations, and it's generated by structural incentives that PMs rarely examine.
InfoSec's incentive structure: InfoSec teams are measured on the absence of security incidents. Every incident represents a failure. Their professional orientation is toward risk identification and mitigation. Their default posture is skepticism — every new feature represents new attack surface, new data exposure, new integration risk. This is not obstruction — it's their job.
Product's incentive structure: Product teams are measured on shipping. Velocity, adoption, revenue impact, customer satisfaction. Security reviews add time and often require rework that delays the metrics Product is measured on. From the PM's incentive perspective, security review is friction between the current state (feature built) and the desired state (feature shipped).
The collision: When these two incentive structures meet at T-minus two weeks, the outcome is always bad. InfoSec has a mandate to block insecure launches. Product has pressure to ship on time. Neither is wrong; neither can fully accommodate the other. The feature either ships with known security gaps or launches late.
The solution isn't to get InfoSec to approve faster. It's to engage InfoSec early enough that they can shape security-by-design rather than review-and-block.
Security by Design: The Early Engagement Model
Security by design means security requirements are incorporated into how the feature is built from the earliest design phase — not reviewed after the fact.
This requires three things:
1. InfoSec involvement at specification time
When the feature spec is written, include InfoSec in the review. The specific questions to answer before engineering starts:
- What category of data does this feature collect, store, or transmit?
- Who has access to that data and under what conditions?
- What authentication and authorization controls are needed?
- Are there external integrations that extend the attack surface?
- What is the threat model for this feature?
A 30-minute InfoSec spec review, before a line of code is written, consistently finds issues that would otherwise be discovered at T-minus two weeks. The fix cost at spec time: hours. The fix cost at T-minus two weeks: weeks.
2. Security acceptance criteria in the spec
Just as a product spec includes acceptance criteria for functionality, it should include security acceptance criteria. Not written by the PM — written by InfoSec, based on their spec review.
Security acceptance criteria:
- All user inputs sanitized against SQL injection and XSS attack patterns
- API endpoints authenticated via the standard OAuth 2.0 flow
- PII stored encrypted at rest using AES-256
- Session tokens expire after 24 hours of inactivity
- Security logging enabled on authentication events
When security requirements are in the spec, engineering builds to them from day one. When they're discovered in a T-minus two weeks review, engineering has to retrofit them into code they wrote assuming different constraints.
3. Security in the definition of done
Add security review to the formal definition of done for any feature handling sensitive data. This creates an organizational norm that security review is part of shipping, not a gate after shipping.
The Threat Modeling Conversation
One of the most valuable things a PM can do with InfoSec is run a threat modeling conversation at the start of a major initiative. This doesn't require the PM to be a security expert — it requires them to ask the right questions and listen carefully.
The four threat modeling questions:
Question 1: "What's the worst thing that could happen with this feature?"
Ask InfoSec to describe the adverse scenario — the attack vector, the damage, the customer impact. Not to be alarming — to understand what they're protecting against. A PM who understands that the worst case is "an attacker could exfiltrate all user emails through this unauthenticated endpoint" makes very different design decisions than one who vaguely knows "security is important."
Question 2: "What does a malicious actor look like for this feature?"
Not all security threats are external hackers. Sometimes the threat model includes:
- Insider threats (employees accessing data they shouldn't)
- Privilege escalation (users accessing features intended for different roles)
- Third-party risk (integration partners with access to sensitive data)
Understanding who the threat actors are focuses the security design on the right risks.
Question 3: "What security controls exist in adjacent features that we can leverage?"
Re-implementing security controls from scratch is expensive and error-prone. InfoSec often knows about existing authentication libraries, encryption utilities, and logging infrastructure that can be reused — reducing both the implementation cost and the security review burden.
Question 4: "What's the minimum security bar for an MVP, and what needs to be added before scale?"
This is the question that unlocks the most practical security-product collaboration. InfoSec teams who are asked "what must we have on day one" vs. "what should we eventually have" can often unblock launches that would otherwise stall — because they can sign off on a launch that meets the day-one bar while planning for scale-security additions.
Reframing Security as a Product Feature
The PM who genuinely understands their customer base knows that for a significant and growing segment of buyers — particularly enterprise, healthcare, financial services, and government — security is a feature. Asking about security certifications, requesting penetration testing reports, requiring SOC 2 compliance: these are standard enterprise sales conversations, and the answers affect deal conversion.
The enterprise security feature checklist:
| Feature | Enterprise Expectation | PM-InfoSec Collaboration Required |
|---|---|---|
| SSO/SAML | Mandatory for most enterprise accounts | 2-3 sprint-weeks, requires InfoSec design input |
| Role-based access control | Mandatory for multi-user accounts | Needs InfoSec threat model for privilege escalation |
| Audit logging | Required for compliance-sensitive accounts | InfoSec defines what events must be logged |
| Data residency | Required for EU customers (GDPR) | Requires infrastructure + InfoSec coordination |
| SOC 2 Type II | Required for contracts above ~$50K ARR | Requires ongoing InfoSec + engineering partnership |
When the PM frames the security roadmap in terms of enterprise deal conversion and average contract value impact, the conversation with leadership changes. Security isn't a cost center or a blocker — it's a revenue enabler for enterprise deals that are currently blocked on security certification.
This framing also changes the InfoSec team's organizational position. A security team whose work is framed as "enabling enterprise revenue" gets more organizational support than one framed as "creating compliance overhead."
Building the Working Relationship
Beyond the process changes, the PM-InfoSec relationship requires genuine investment:
Learn the basics. A PM doesn't need to be a security engineer. But a PM who understands the difference between authentication and authorization, who knows what an SQL injection attack is, who can explain what TLS encryption does — is a PM that InfoSec respects as a collaborative partner rather than a requestor who needs hand-holding.
Include InfoSec in product planning. Invite the InfoSec lead to one quarterly roadmap planning session. Not to review for security issues — to share what's coming 6 months out so they can plan their review capacity. InfoSec teams that know big launches are coming 6 months in advance can resource appropriately. InfoSec teams who find out 2 weeks before launch are always resource-constrained.
Celebrate security wins publicly. When the product passes a penetration test or achieves a security certification, represent InfoSec's contribution to leadership explicitly: "Achieving SOC 2 Type II was a significant organizational effort led by [InfoSec lead]. It's directly enabling the three enterprise conversations we have with $100K+ prospects."
The Prodinja Angle
The PM-InfoSec relationship suffers from the same structural problem as the PM-Legal relationship: security is discovered too late to be designed, only to be bolted on. Prodinja tracks initiative development milestones and surfaces security review touchpoints proactively — before designs are finalized, before engineering commits, and before launch prep begins. For PMs managing multiple initiatives, it's the difference between security review being a scheduled input and security review being a surprise blocker.
For the full stakeholder engagement framework, see the Complete Guide to Stakeholder Management.
Key Takeaways
- InfoSec doesn't block features — late engagement blocks features. The fix cost for security issues grows exponentially with each phase of development.
- Security by design requires InfoSec at spec time, security acceptance criteria in the spec, and security in the definition of done.
- The four threat modeling questions unlock practical security collaboration: worst case, threat actor identity, existing controls to leverage, and day-one vs. scale security bars.
- Security is an enterprise revenue feature. SOC 2, SAML SSO, audit logging, and data residency have direct deal-conversion impact. Frame the security roadmap in those terms.
- Build the working relationship between initiatives — basic security literacy, including InfoSec in planning, celebrating security wins — changes the dynamic from adversarial to collaborative.