Security & Privacy Plan

Purpose

A Security & Privacy Plan is the master security document for a project. It brings together threat modeling, data classification, encryption strategy, access control policy, privacy obligations, and incident response into a single coherent plan. Where other documents (threat model, auth design, compliance checklist) go deep on specific dimensions, the Security & Privacy Plan provides the governance layer: what is the security posture we are committing to, and how is it enforced?

Security that isn’t documented doesn’t exist as a policy—it exists only in the minds of the engineers who designed it. When those engineers rotate off the project, the security controls rotate with them. The Security & Privacy Plan makes security intent explicit and transferable.

Privacy is inseparable from security in modern software. Collecting user data without a documented retention policy, sharing data with third parties without a consent framework, or storing PII without a data classification scheme are all security problems with regulatory consequences. The plan must address both dimensions together.

A Security & Privacy Plan is not a compliance checklist. Compliance means meeting minimum requirements; security means managing risk. The plan’s job is risk management—understanding the threat landscape, prioritizing controls based on actual risk, and documenting the explicit trade-offs where the team has accepted residual risk.

Who needs this document

What separates a good version from a bad one

Criterion 1: Data classification is explicit and drives control requirements

✓ Strong: “Data classification tiers: (1) Public — no controls required. (2) Internal — encrypted at rest, accessible to all employees. (3) Confidential — encrypted at rest and in transit, access requires explicit IAM role, logged. (4) Restricted (PII/PHI) — encrypted at rest (AES-256) and in transit (TLS 1.3+), access requires explicit per-user grant, every read and write is audit-logged, 90-day retention limit.”

✗ Weak: “All user data is protected with industry-standard security.” (No classification, no differential control requirements, no retention policy. This statement means nothing and protects nothing.)

Criterion 2: Encryption requirements specify algorithms and key management

✓ Strong: “Encryption at rest: AES-256-GCM for all Restricted data. Keys managed via AWS KMS with automatic rotation every 90 days. Encryption in transit: TLS 1.3 minimum; TLS 1.0/1.1 disabled at load balancer level. Database connections: mutual TLS. API communication: TLS 1.3 with HSTS max-age=63072000.”

✗ Weak: “All data is encrypted at rest and in transit.” (Which algorithm? Which key length? Where are keys stored? What is the rotation policy? Vague encryption claims are common in data breaches—everything was “encrypted” but the keys were in a plaintext environment variable.)

Criterion 3: Incident response has concrete triggers and owners

✓ Strong: “Incident triggers: (1) Any data exfiltration of > 1 user record triggers P0 incident. (2) Auth service downtime > 5 minutes is a P1 incident. (3) Any failed login rate > 100/min triggers automated account lockout and security team alert. Incident commander: on-call SRE. Legal notification required within 72 hours of confirmed PII breach (per GDPR Art. 33). Public notification: 72 hours after legal notification if > 500 affected users.”

✗ Weak: “Security incidents will be handled by the security team.” (No trigger criteria, no timeline, no named role, no regulatory compliance hook. This is a policy that cannot be acted upon.)

Criterion 4: Third-party data sharing is enumerated

✓ Strong: “Third-party data sharing: (1) Stripe — receives: email, billing address, last-4 of card. Basis: payment processing contract. DPA signed. (2) SendGrid — receives: email address only. Basis: transactional email. DPA signed. (3) Sentry — receives: stack traces, user ID (no PII). Scrubbing rules in sentry.config.js remove email and IP before transmission. No other third parties receive user data.”

✗ Weak: “We may share data with trusted service providers.” (Every SaaS tool in the tech stack is a data processor. Enumerate them. Unexamined third-party sharing is how PII ends up in analytics vendor dashboards without consent.)

Common mistakes

Treating compliance as a security plan. “We’re SOC 2 compliant” is not a security plan. Compliance certifications audit against a specific control framework at a point in time. A security plan addresses your specific threat landscape, which may include risks outside the compliance scope.

No explicit residual risk acceptance. Every security plan involves accepting some residual risk. When the team decides not to implement a control (too expensive, low risk), document that decision and who accepted the risk. Without this, future engineers don’t know whether a missing control is an oversight or a deliberate choice.

Security plan written in isolation from engineering. Security plans written by a security team without engineering involvement produce documents that don’t map to how the system actually works. The plan must be reviewed by the engineers who implement and operate it.

Not updating the plan after significant features. Adding payments, a new third-party integration, or a new data type changes the security posture. The plan should be reviewed and updated before such features launch, not after.

How to use this document

When to create it

Write the Security & Privacy Plan before the first production deployment with any user data. For pre-launch development, a lightweight plan covering data classification and basic access controls is sufficient. Expand it as the system grows.

Who owns it

The security lead or, for smaller teams, the tech lead with input from legal. Engineering owns the implementation; security/legal own the policy. Both must agree on the plan before launch.

How AI agents should reference it

get_standard_docs(type="web_app", features=["auth"])
→ security_privacy in documents[]
→ auth_design in documents[]
→ agent reads security plan before implementing any authentication, data storage, or API endpoint
→ agent applies data classification when generating data models
→ agent verifies proposed encryption matches specified algorithm and key management approach

The prompt_snippet — “Ensure the project has a security and privacy plan covering threat model, data classification, encryption, access controls, and incident response” — tells the agent to verify all five dimensions are addressed.

How it connects to other documents

The Security & Privacy Plan is the parent of the Threat Model (which provides the threat analysis that informs the plan), Authentication Design (which implements the access control decisions made in the plan), PII Classification Specification (which applies the data classification policy to specific fields), and all compliance checklists (GDPR, HIPAA, SOC 2) which verify the plan meets specific regulatory requirements.

Recommended Reading

• Security Engineering by Ross Anderson — Comprehensive reference covering security architecture, threat modeling, and control design across all layers of a system.
• The Web Application Hacker’s Handbook by Dafydd Stuttard & Marcus Pinto — Practical coverage of web security vulnerabilities that the Security & Privacy Plan’s threat model should address.
• NIST Cybersecurity Framework (nist.gov/cyberframework) — The US federal standard for security risk management; directly applicable to the structure of a Security & Privacy Plan.