Threat modeling, data classification, and least privilege shape system design
Security isn’t a checklist at the end. It’s an architectural constraint that shapes data flow, access, and system boundaries.
Not all data is equal. Classify it:
The stricter the data, the more architecture changes: encryption, audit logs, access controls, and retention policies.
Ask three questions:
This quickly reveals where to add defenses.
Limit access to the minimum needed. This reduces blast radius when something goes wrong.
Examples:
Q: Why is data classification an architectural decision, not just a security task?
<details> <summary>💡 Reveal Answer</summary>Because classification determines storage location, encryption requirements, access controls, auditing, and retention. These choices affect schema, infrastructure, and integration patterns — core architecture, not just implementation.
</details>Run a 15‑minute threat model:
Full access
Unlock all 12 lessons, templates, and resources for Software Architecture & Decision Patterns. Free.
Scenario: A new feature needs to store user IDs and location data. Legal says GDPR applies.
What architectural changes are required?
Classify the data as confidential/regulated, enforce encryption at rest and in transit, add consent and retention controls, and ensure data deletion workflows exist. This may also require data residency decisions depending on jurisdiction.
| Idea | Remember This |
|---|---|
| Security is architecture | It shapes data flow and boundaries |
| Classification | Determines controls and storage decisions |
| Least privilege | Minimizes damage from breaches |
| Threat modeling | Quick, high‑impact early step |
Next: Observability & Operability