SSDLC Design Doc Example
Use for new features or integrations. This is not a required format, but a guideline/example.
1. What & Why
What changes, for whom, expected impact.
2. Touchpoints (Data & Interfaces)
Describe only what this feature adds/changes.
| Direction | Endpoint / Component | Protocol/Port | AuthN/AuthZ | Data Class (PII/Secrets/Low) | Crosses Trust Boundary? |
|---|---|---|---|---|---|
| Inbound | |||||
| Outbound |
Storage changes (if any)
| Data | Where | At‑rest protection | Retention |
|---|---|---|---|
3. Trust & Privileges
Who can access it. Less detail if open, more detail if closed (e.g. roles required).
4) Risks & Mitigations
Only practical risks. Accepting the risk is also a fine outcome!
| Risk | Scenario | Likelihood | Impact | Mitigation (design/config) | How we’ll verify |
|---|---|---|---|---|---|
| Low/Med/High | Low/Med/High |
5) Observability (security‑relevant)
- Logs: auth events, admin actions, policy decisions, errors (with redaction list)
- Metrics/alerts: e.g. auth failures, rate‑limit exceeds
6) Config & Defaults
- User‑facing options (only ones touched by this feature):
| Option | Default | Secure by default? | Override allowed? |
|---|---|---|---|
| Yes/No | Yes/No |
- Secrets: where stored, access path, rotation