Security Basics for Product Managers: What You Need to Know (But Don't Need to Implement)

📚 Table of Contents

1. The Breach That Wasn’t in the News
2. Why Security Is a Product Problem (Not Just an Engineering Problem)
3. The Security Basics Every PM Should Know
4. Common Vulnerabilities and Their Product Impact
5. Compliance for PMs: GDPR, SOC 2, and Beyond
6. Security vs. User Experience: The Trade-offs
7. Building Security into Your Roadmap
8. Questions to Ask Your Security and Engineering Teams
9. When Security Becomes a Blocker (And How to Handle It)
10. Your Security Conversation Starter Pack
11. The Bottom Line

The Breach That Wasn’t in the News

In 2023, I worked with a company that had a security incident. It didn’t make the news. They paid a ransom. Their customers never found out.

Here’s what happened:

The product decision: “Let’s add a feature where users can export their data to CSV.”

The implementation: Engineers built it quickly. They didn’t implement rate limiting.

The vulnerability: An attacker discovered they could make unlimited requests to the export endpoint.

The attack: The attacker wrote a script that requested exports for millions of records, overwhelming the database.

The extortion: “Pay us $50,000 or we’ll publish your customer data.”

The aftermath: The company paid. Fixed the vulnerability. Never told customers.

The PM reflection: This wasn’t an engineering failure. It was a product failure. The feature spec didn’t include security requirements. The acceptance criteria didn’t mention rate limiting. The risk assessment never happened.

Security is a product responsibility. You don’t need to implement it. But you need to specify it.

Why Security Is a Product Problem (Not Just an Engineering Problem)

The Product Manager’s Security Responsibilities

The Cost of Security Failures

The Naked Truth

Engineers implement security.
Product managers define what security means for the product.

If your feature spec says nothing about security, you’ve made a decision: security isn’t a priority for this feature.

The Security Basics Every PM Should Know

1. Authentication vs. Authorization

Authentication (AuthN): Who are you?

• Login process
• Password verification
• Multi-factor authentication
• Single sign-on (SSO)

Authorization (AuthZ): What can you do?

• Permissions
• Roles
• Access control
• Data visibility

Product questions:

• “How do we verify who users are?”
• “What can each user role access?”
• “Do we need different permissions for different user types?”

2. Encryption

In transit: Data encrypted while moving

• HTTPS (TLS/SSL)
• Encrypted APIs
• VPNs for internal traffic

At rest: Data encrypted while stored

• Database encryption
• File storage encryption
• Backup encryption

Product questions:

• “Is all user data encrypted at rest?”
• “Are our API calls encrypted?”
• “Who has access to encryption keys?”

3. The Principle of Least Privilege

What it means: Users and systems should have the minimum access necessary to do their jobs.

Example:

• Customer support should see user data, not billing data
• Marketing should see campaign analytics, not user PII
• Developers should have production read access, not write access

Product questions:

• “Who can access what data in our system?”
• “Can we reduce access without breaking workflows?”
• “Do we audit who accessed what?”

4. Defense in Depth

What it means: Multiple layers of security, not one barrier.

Example:

Layer 1: Network security (firewalls, VPNs)
Layer 2: Application security (authentication, input validation)
Layer 3: Data security (encryption, access controls)
Layer 4: Monitoring (logs, alerts, anomaly detection)

Product questions:

• “If one layer fails, what protects us?”
• “Do we have multiple security checkpoints?”

Common Vulnerabilities and Their Product Impact

OWASP Top 10 (Simplified for PMs)

The Product Translation

When you hear: “We have an injection vulnerability.” You should ask: “What data is at risk? What’s the fix timeline? Who’s affected?”

When you hear: “We need to implement MFA.” You should ask: “What’s the UX impact? What’s the rollout plan? How do we handle recovery?”

Compliance for PMs: GDPR, SOC 2, and Beyond

The Compliance Landscape

What Compliance Means for Your Product

GDPR Product Requirements:

• Consent management (users can grant/revoke consent)
• Data export (users can download their data)
• Data deletion (users can request deletion)
• Privacy policy accessible
• Cookie consent banner
• Data processing agreements with vendors

SOC 2 Product Requirements:

• Audit logging (who did what, when)
• Access controls (role-based permissions)
• Encryption (data at rest and in transit)
• Change management (documented releases)
• Incident response (documented process)

The Compliance Product Backlog

Create features that enable compliance:

• User consent management UI
• Data export functionality
• Data deletion workflow
• Audit log viewer
• Role-based access control admin

These aren’t “security features.” These are product features required for compliance.

Security vs. User Experience: The Trade-offs

The Classic Tensions

The Trade-off Framework

┌─────────────────────────────────────────────────────────────┐
│ SECURITY vs. UX DECISION MATRIX                         │
├─────────────────────────────────────────────────────────────┤
│                                                         │
│  HIGH SECURITY, LOW UX:                                 │
│  - MFA every login                                       │
│  - 8-character complex passwords                         │
│  - 15-minute session timeout                            │
│  → Use for: Admin access, financial operations          │
│                                                         │
│  BALANCED:                                              │
│  - MFA on new devices                                   │
│  - Reasonable password rules                            │
│  - 8-hour session timeout                               │
│  → Use for: Standard user accounts                      │
│                                                         │
│  LOW SECURITY, HIGH UX:                                 │
│  - No MFA                                                │
│  - Simple passwords                                      │
│  - 30-day sessions                                       │
│  → Use for: Low-risk, public content                    │
│                                                         │
└─────────────────────────────────────────────────────────────┘

Making the Trade-off

The decision process:

1. What’s the risk level of this feature/data?
2. What’s the acceptable UX friction for this risk?
3. What security measures are minimum requirements?
4. How can we minimize UX impact while meeting security needs?

Building Security into Your Roadmap

The Security Roadmap Allocation

Recommended allocation: 10-20% of capacity for security work.

Security in Feature Specs

Add a security section to every feature spec:

## Security Requirements

### Authentication
- Who can access this feature?
- Do we need additional verification?

### Authorization
- What permissions are required?
- Can users access each other's data?

### Data Protection
- What data does this feature access?
- Is sensitive data encrypted?
- What data retention applies?

### Compliance
- Does this touch GDPR-regulated data?
- Are we creating audit logs?

### Risk Assessment
- What's the worst-case scenario?
- What mitigations are we implementing?

Questions to Ask Your Security and Engineering Teams

About Current Security Posture

• “What are our top 3 security risks right now?”
• “When was our last security audit or penetration test?”
• “What compliance requirements do we have?”
• “What’s our incident response process?”

About Specific Features

• “What could go wrong with this feature from a security perspective?”
• “What data does this feature touch? Is it sensitive?”
• “Do we have proper authorization checks?”
• “What happens if someone tries to abuse this feature?”

About Security Investment

• “What security work should be on the roadmap that isn’t?”
• “What’s the risk of delaying this security work?”
• “What resources do we need to improve our security posture?”

When Security Becomes a Blocker (And How to Handle It)

The Scenario

Engineering says: “We can’t ship this feature. Security review found vulnerabilities.”

Your job: Understand the risk, make the trade-off decision.

The Decision Framework

Ask these questions:

1. What’s the vulnerability? (Get specific, not “it’s insecure”)
2. What’s the exploit scenario? (How would an attacker actually use this?)
3. What’s the impact if exploited? (Data loss? Money? Reputation?)
4. What’s the likelihood? (Easy to exploit? Requires skill? Inside job?)
5. What’s the fix? (How long? What trade-offs?)
6. What’s the workaround? (Can we ship with mitigations?)

The Risk Matrix

Your Security Conversation Starter Pack

The Monthly Security Review

Add to your recurring meetings:

Monthly Security Review (30 minutes)
├── Recent incidents or near-misses
├── New security requirements from features
├── Compliance status
├── Security roadmap items
└── Questions or concerns

The Security-Conscious Feature Template

## Feature: [Name]

### User Story
[Standard user story]

### Acceptance Criteria
[Standard criteria]

### Security Requirements
- **Authentication:** [Who can access?]
- **Authorization:** [What can they do?]
- **Data touched:** [What data?]
- **Encryption:** [What needs encryption?]
- **Rate limiting:** [What limits?]
- **Audit logging:** [What to log?]

### Risk Assessment
- **Worst case scenario:** [What's the worst that could happen?]
- **Mitigations:** [What are we doing to prevent it?]

The Bottom Line

Security is not someone else’s problem. It’s your problem.

As a PM, you own:

1. Security requirements in feature specs
2. Risk trade-off decisions
3. Security roadmap allocation
4. Compliance feature delivery
5. Stakeholder communication about security

You don’t own:

• Implementation details
• Vulnerability scanning
• Penetration testing
• Incident response technical work

The shift: When you see security as a product concern, you build better products. Products that protect users. Products that earn trust.

Start today: Add a security section to your next feature spec. Ask about security risks in your next planning session. Make security visible in your roadmap.

What security concern keeps you up at night? What security question do you wish you could answer?

Related Reading:

• API Design for Product Managers
• Production Incidents: The PM’s Playbook
• Cloud Costs for Product Managers