The hardest part of security isn't knowing which controls exist. It's deciding how much is enough for a given system. Spend too little and you're exposed; spend too much and you've burned effort on protection nobody needed. The way out is to let the data decide.

Build to your most sensitive data#

The rule is this: build to the tier of the most sensitive data a system touches, not the average. A service that is mostly public marketing content but also stores one table of customer PII is a PII system, and it should be protected like one. Averaging your sensitivity gives you a number that protects nothing fully.

A few principles travel with that rule:

• Use proven, boring controls. Custom security is risk; standard security is hygiene. Never invent your own cryptography. The exciting, clever approach is almost always the wrong one here.
• Compliance is a byproduct of good engineering, not a substitute for it. If you engineer well, passing an audit is mostly paperwork. If you chase the certificate first, you get theater.
• "We'll add security later" is a refusal, not a plan. Later never comes with the budget or the architecture you'd have needed.
• The most secure data is data you never collected. Minimizing collection and retention removes whole categories of risk. You can't leak what you don't hold.

Data sensitivity tiers#

Classify what you store into four tiers:

• T1 Public: marketing pages, public documentation, open-source code. No confidentiality concern.
• T2 Internal: business data, non-PII analytics, internal tools. Embarrassing if leaked, not catastrophic.
• T3 Confidential: customer PII, financial information, application secrets. Real harm if exposed.
• T4 Regulated: protected health information under HIPAA, cardholder data under PCI, government-controlled data. Legal and regulatory consequences attach.

The baseline every system above T1 needs#

Once a system rises above purely public data, it earns a standard baseline. None of this is exotic; all of it is table stakes.

• TLS everywhere, with no plaintext transport.
• Secrets in a managed secret store, never committed in code or config.
• Authentication via a managed identity provider or a standard, well-reviewed auth mechanism.
• Databases on private networks, never exposed directly to the internet.
• Audit logging for authentication events.
• Dependency scanning, with critical vulnerabilities triaged within about 7 days.
• Backups that you have actually tested restoring, not just taking.
• Multi-factor authentication for production admin access.
• Least-privilege access that gets audited rather than granted and forgotten.

What T3 adds#

Confidential data raises the floor:

• Encryption at rest for PII.
• Access logging specifically for reads of PII, so you know who looked at what.
• Quarterly access reviews to catch permission drift.
• A documented and enforced retention policy, so data doesn't accumulate forever.
• An incident response plan that includes user notification.

What T4 adds#

Regulated data brings the heavy machinery, much of it organizational rather than purely technical:

• A formal compliance program: SOC 2, HIPAA, or PCI as appropriate.
• Data processing agreements or business associate agreements with every sub-processor, signed before you integrate them.
• Awareness of regulatory notification clocks, which start ticking the moment you detect a breach.
• An annual penetration test by an outside party.
• Annual security awareness training for the team.
• A vendor security review process for anything that touches the regulated data.

Choosing a compliance framework#

Pick the framework that matches your context rather than collecting all of them:

• SOC 2 for B2B SaaS selling to other businesses.
• HIPAA when you handle protected health information.
• PCI-DSS when you handle cardholder data, though the smarter move is to choose architectures that scope you out of PCI entirely by never touching raw card numbers.
• GDPR or CCPA when you serve users in the EU or California.

Traps to avoid#

The failures I see most often aren't sophisticated attacks. They're self-inflicted:

• Add-security-later, which we've already named as a refusal.
• Compliance theater, where the paperwork exists but the controls don't actually run.
• Custom crypto, which is almost always a downgrade from the standard library.
• Long-lived production credentials that never rotate and end up in someone's shell history.
• Over-collecting data you don't need, expanding your blast radius for no benefit.

And the single most common privacy failure of all: PII drifting into logs. It happens quietly, a debug line here, a request dump there, and suddenly your low-sensitivity logging system is holding high-sensitivity data it was never designed to protect. Guard your log pipeline as carefully as your database.

Right-sizing security isn't about doing the maximum everywhere. It's about doing exactly what the data demands, with controls boring enough to trust.