When Security Becomes a Crisis

Timeline:

Week 1: Feature spec approved. "Store user email, show in dashboard"

Week 3: Security team asked to review. "Wait, is email encrypted? Who can access it? How long do we keep it?"

PM: "Uh... we're storing it in the database?"

Security: "That's not a security answer. We need an incident response plan. We need retention policies. We need audit logs."

Engineering: "Nobody spec'd that. We'll need to add it."

Result: 2 weeks of rework. Feature delayed. Security and PM frustrated with each other.

Framework: Security-by-Design (Not Security Theater)

Security Theater vs. Security-by-Design

SECURITY THEATER:
- PM: "Make it secure"
- Engineering: Add SSL (TLS) ✓
- Security: "Are we SOC2 compliant?"
- Reality: Users feel safe. But no actual risk mitigation.

SECURITY-BY-DESIGN:
- PM: "Email is PII. Encrypt at rest. Only owner can access. 90-day retention. Audit log. Incident playbook."
- Engineering: Implements all of it during build.
- Security: Reviews spec, says "good, ship it."
- Reality: Actual risk mitigation. Users are safe.

Four Security Dimensions

DIMENSION 1: DATA CLASSIFICATION
- What data are we collecting?
- How sensitive is it? (Public, Internal, Confidential, Restricted)

DIMENSION 2: PROTECTION
- How do we protect it? (Encryption, access control, audit logs)
- Who can access it? (Only owner, team, public)

DIMENSION 3: RETENTION & DELETION
- How long do we keep it? (30 days, 1 year, indefinite)
- How do we delete it? (Soft-delete, hard-delete, secure wipe)

DIMENSION 4: COMPLIANCE & INCIDENTS
- What regulations apply? (GDPR, CCPA, HIPAA, etc.)
- What's the incident response plan? (Who to notify, timeline, recovery)

Data Sensitivity Levels

PUBLIC (No protection required):
- Feature name: "AI Search"
- Documentation: "How to use feature"
- Public metrics: "1M users"

INTERNAL (Encrypted, limited access):
- Team discussions
- Product roadmap
- Internal metrics

CONFIDENTIAL (Highly protected):
- User email
- Company billing info
- Customer API keys

RESTRICTED (Highest protection):
- User password (never stored in plain text)
- Payment card data (PCI compliance)
- Biometric data

Real-World Example: Security Requirements in PRD

Scenario: Customer Data Export Feature

BAD PRD (No Security Spec):

FEATURE: Export Customer Data

BEHAVIOR:
- User clicks "Export"
- System generates CSV with all user data
- File downloads

Missing from PRD:

  • Who can export? (Any user? Admin only?)
  • What data in export? (Emails? Payment history? Internal notes?)
  • Where does the file go? (User's computer? Email?)
  • How long is it readable? (Encrypted? Plain text?)
  • Who can see it? (Just the user? Anyone with access to their computer?)

Result:

  • Security discovers mid-build: "This needs encryption!"
  • Feature reworked
  • Delayed launch

GOOD PRD (Security Spec Included):

FEATURE: Customer Data Export

BEHAVIOR:
- User clicks "Export"
- System generates CSV with: name, email, purchase history (NOT payment cards)
- File is encrypted (AES-256)
- File downloads to user's computer
- File is password-protected (user sets password)

ACCESS CONTROL:
- Only account owner can export their own data
- Admin can export customer data (with audit log)
- Exported data can't be re-uploaded (one-way export)

DATA CLASSIFICATION:
- Export contains: Emails (Confidential), Purchase history (Internal)
- Does NOT contain: Payment card info, password hashes, API keys

ENCRYPTION:
- At rest: AES-256 encryption
- In transit: HTTPS/TLS 1.2+ only
- File password: User-generated, minimum 12 characters

RETENTION:
- CSV file encrypted on user's device (not stored on our servers)
- User responsible for managing file
- If user deletes account: Previous exports remain on user's device (unrecoverable by us)

COMPLIANCE:
- GDPR: "Right to data portability" satisfied (user gets export)
- GDPR: "Right to erasure" satisfied (separate delete action, not export)
- CCPA: "Consumer right to know" satisfied (export shows all data we have)

INCIDENT RESPONSE:
- If export is leaked publicly: No credit card data at risk (cards not in export)
- If user loses password: User's export unrecoverable (we don't have master key)
- If server is breached: Exports encrypted, passwords hashed (no exposure)

TESTING:
- [ ] Verify file is encrypted (use file tool to confirm)
- [ ] Verify password-protection works (try opening without password = fail)
- [ ] Test with 1GB export (ensure performance)
- [ ] Verify non-owner can't download another user's export

Result:

  • Security review: "Good spec, approved."
  • Engineering: "Clear requirements, no rework."
  • Launch on time.

Anti-Pattern: "Security Will Handle It"

The Problem:

  • PM: "It's a feature, not a security thing"
  • Engineering: Builds without security in mind
  • Security, week 3: "This isn't secure."
  • Rework begins

The Fix:

  • Security is PM's job (in the PRD)
  • Security team helps design, but PM owns the spec
  • "What data? Who accesses? How long? What if breached?"

Actionable Steps

Step 1: Data Inventory

Before writing PRD:

What data will this feature collect/display/store?

Email address? → Classified: Confidential (PII)
Usage behavior? → Classified: Internal
Payment info? → Classified: Restricted (PCI)
User location? → Classified: Internal (privacy concern)

Step 2: Create Security Section in PRD

## Security & Privacy

DATA COLLECTED:
- User email (PII, Confidential)
- Usage timestamp (Internal)
- Feature interactions (Internal)

DATA STORAGE:
- Email: Encrypted at rest (AES-256)
- Usage: Plaintext (non-PII, lower risk)

DATA ACCESS:
- Owner: Can view their own data
- Admins: Can access (with audit log)
- Third parties: None (data stays in-house)

DATA RETENTION:
- User data: Until account deleted
- Audit logs: 90 days
- Backups: 30-day retention

INCIDENT RESPONSE:
- If breach detected: Notify affected users within 24 hours
- If payment data exposed: Notify within 30 days (PCI requirement)
- Post-incident: Security audit + public postmortem

Step 3: Involve Security Early

Don't wait for week 3:

EMAIL: Security Review Request

Hi [Security Lead],

We're speccing a new data export feature. Want to ensure we handle it securely.

Key questions:
1. What's the right encryption approach for user-generated exports?
2. Any compliance rules we should include? (GDPR, CCPA)
3. What should our incident response plan include?

Quick 30-min sync this week?

Step 4: Document Threat Models

THREAT: Unauthorized access to user email

Likelihood: Low (encryption + access controls prevent it)
Impact: High (email is PII)

Mitigation:
- Encryption: AES-256 at rest
- Access control: Only owner + admin (audit logged)
- Detection: Monthly audit of access logs

Response:
- If unauthorized access detected: Notify user within 24h
- Disable affected account
- Forensic investigation

Testing:
- [ ] Try accessing another user's email (should fail)
- [ ] Verify encryption (decrypt without key = fail)

Step 5: Make Security Testable

Before launch:

SECURITY TEST CHECKLIST:

[✓] Encryption: Can I read the database directly and see emails? (No, encrypted)
[✓] Access control: Can I access another user's data? (No, auth prevents it)
[✓] Audit log: Are access attempts logged? (Yes)
[✓] Incident response: Do we have runbook? (Yes, linked)
[✓] Compliance: GDPR export ready? (Yes, export contains all PII)
[✓] Retention: Do we delete data after 30 days? (Yes, automated)

PMSynapse Connection

Security planning is manual. PMSynapse's Security Checklist auto-generates requirements: "You're storing user email. Here's your security spec: Classify as PII (Confidential), encrypt at rest (AES-256), restrict access to owner, create audit log, set 90-day retention, add incident playbook." By automating security req spec, PMSynapse prevents week-3 security surprises.

Key Takeaways

  • Security in the PRD prevents rework. 30 minutes upfront saves 2 weeks of mid-build fixes.

  • Data classification drives security decisions. PII gets encryption. Public data doesn't.

  • Encryption + access control + audit logs = security. Not just "use SSL."

  • Incident response is a spec item. "What if we're breached?" should have an answer before launch.

  • Security is PM's job. Don't defer to security team; involve them, but own the spec.

Writing Security Requirements Into Your PRD (Before InfoSec Asks)

Article Type

SPOKE Article — Links back to pillar: /prd-writing-masterclass-ai-era

Target Word Count

2,500–3,500 words

Writing Guidance

Reference PRD Section 5.3.1 security-by-design prompts concept and Section 8 Data Privacy requirements. Provide a security requirements template for PRDs. Soft-pitch: PMSynapse embeds security considerations into the requirement-writing workflow from Day 1.

Required Structure

1. The Hook (Empathy & Pain)

Open with an extremely relatable, specific scenario from PM life that connects to this topic. Use one of the PRD personas (Priya the Junior PM, Marcus the Mid-Level PM, Anika the VP of Product, or Raj the Freelance PM) where appropriate.

2. The Trap (Why Standard Advice Fails)

Explain why generic advice or common frameworks don't address the real complexity of this problem. Be specific about what breaks down in practice.

3. The Mental Model Shift

Introduce a new framework, perspective, or reframe that changes how the reader thinks about this topic. This should be genuinely insightful, not recycled advice.

4. Actionable Steps (3-5)

Provide concrete actions the reader can take tomorrow morning. Each step should be specific enough to execute without further research.

5. The Prodinja Angle (Soft-Pitch)

Conclude with how PMSynapse's autonomous PM Shadow capability connects to this topic. Keep it natural — no hard sell.

6. Key Takeaways

3-5 bullet points summarizing the article's core insights.

Internal Linking Requirements

  • Link to parent pillar: /blog/prd-writing-masterclass-ai-era
  • Link to 3-5 related spoke articles within the same pillar cluster
  • Link to at least 1 article from a different pillar cluster for cross-pollination

SEO Checklist

  • Primary keyword appears in H1, first paragraph, and at least 2 H2s
  • Meta title under 60 characters
  • Meta description under 155 characters and includes primary keyword
  • At least 3 external citations/references
  • All images have descriptive alt text
  • Table or framework visual included