Or: How I Learned to Stop Worrying and Love Precise Terminology
I've sat through exactly 437 meetings (Nah, I'm lying - Should have been WAY more than 437 meetings!) where someone called themselves a "security expert" and then spent 45 minutes talking about input validation.
I've watched "security audits" that were actually compliance checkbox exercises (and those are way more common than you can imagine).
I've seen "data protection strategies" that wouldn't protect a sandwich from a hungry toddler.
We need to talk.
The software industry has developed a dangerous habit: Using "security", "safety", "compliance" and "data protection" interchangeably, as if they're different flavors of the same thing. They're not. And this linguistic laziness isn't just annoying, it's actively making your systems worse.
The Four Horsemen (That Are Actually Four Different Horses)
Let's get brutally clear about what these terms actually mean:
Security: Keeping the Bad Guys Out
Security is about intentional, adversarial threats. Someone is actively trying to break your system, steal your data, or disrupt your service.
Security answers the question: "How do we prevent malicious actors from doing malicious things?"
Examples of actual security:
- Implementing authentication and authorization
- Encrypting data in transit and at rest
- Defending against SQL injection, XSS, CSRF attacks
- Network segmentation and firewall rules
- Penetration testing and threat modeling
Not security:
- Making sure users can't enter letters in a phone number field (that's safety)
- Having annual "security training" that's really just compliance theater
Safety: Protecting the System from Honest Mistakes
Safety is about unintentional harm caused by legitimate users. It's protecting the system and users from accidents, mistakes, and Murphy's Law. Safety answers the question: "How do we prevent people from accidentally breaking things or hurting themselves?"
Examples of actual safety:
- Input validation and sanitization
- Type checking and schema validation
- Graceful error handling and failsafes
- Rate limiting to prevent accidental DoS
- Confirmation dialogs for destructive actions
- Circuit breakers and chaos engineering
Not safety:
- Blocking known attack patterns (that's security)
- Logging access for audit trails (that's compliance)
Compliance: Proving You Did What You Said You'd Do
Compliance is about satisfying external requirements legal, regulatory, contractual or industry standards.
It's documentation, processes, and evidence. Compliance answers the question: "How do we prove we're following the rules?"
Examples of actual compliance:
- SOC 2, ISO 27001, PCI-DSS certifications
- GDPR, HIPAA, CCPA regulatory requirements
- Audit logs and access trails
- Policy documentation and training records
- Incident response plans and disaster recovery documentation
Not compliance:
- Implementing 2FA because it's a good idea (that's security)
- Writing policies nobody reads or follows (that's theater)
Data Protection: Safeguarding Information Across Its Lifecycle
Data protection is about managing information sensitivity and privacy throughout its entire lifecycle. It crosses all three previous categories but has its own identity.
Data protection answers the question: "How do we ensure data is handled appropriately from creation to deletion?"
Examples of actual data protection:
- Data classification and handling policies
- Encryption at rest and in transit
- Data minimization and retention policies
- Privacy by design
- Right to erasure and data portability
- Anonymization and pseudonymization
Not data protection:
- Having a privacy policy (that's compliance)
- Encrypting because the auditor said so (that's... complicated)
Why This Matters (AKA: How Confusion Kills)
"Who cares about semantics?" you ask. "We're all trying to make things more secure/safe/protected/whatever!"
Here's why you should care:
1. You're Solving the Wrong Problems
When you call input validation a "security control" you might pat yourself on the back thinking you've hardened your system against attackers. You haven't. You've made it safer for users, which is great! But you still have zero defense against credential stuffing, privilege escalation, or supply chain attacks.
I've literally seen teams spend months perfecting their input validation while running everything as root with default passwords. Why? Because the "security team" was actually a "safety team" that didn't know the difference.
2. You're Hiring the Wrong People
Your job posting says "Security Engineer" but describes someone who writes Terraform and sets up compliance dashboards. Actual security engineers, the ones who know how to threat model your API or find race conditions in your authentication flow—scroll right past.
Meanwhile, you hire someone excellent at compliance frameworks who doesn't know what a TOCTOU vulnerability is. Six months later, you're breached, and everyone's confused why your "security expert" didn't prevent it.
3. You're Measuring the Wrong Metrics
"We're 95% compliant!" Great. Are you 95% secure? You have no idea, because compliance and security aren't the same thing.
"We have zero production incidents this month!" Fantastic safety record. But an attacker has had access to your database for six weeks and hasn't caused any incidents yet.
Different objectives require different metrics. Conflating them means you're optimizing for the wrong outcomes.
4. You're Creating a False Sense of Security
This is the dangerous one. When executives hear "we passed our security audit" they think the system is secure.
But what if that audit was actually a compliance checklist, and the compliance was actually just documentation review, and the documentation was written by someone who thought "encryption" meant "password-protected ZIP files"...
You see the problem.
The Real World Is Messy (And That's OK)
Now, before you and me: Yes, I know these concepts overlap at some points. A good authentication system is security AND contributes to compliance AND protects data.
Input validation is safety AND helps prevent security vulnerabilities. I get it.
But here's the thing: overlap doesn't mean equivalence.
A car's seatbelt is both a safety feature and legally required (compliance). But you wouldn't hire a lawyer to design your seatbelt, and you wouldn't hire a mechanical engineer to write your vehicle safety regulations.
They overlap, yes, but they're different disciplines requiring different expertise.
How to Stop Making This Worse
For Managers:
Stop treating "security" as a catch-all bucket. When you're budgeting, hiring, or planning projects, be specific:
- Do you need to prevent attackers? That's security. Hire security engineers. Budget for penetration testing and (if possible) bugbounty campaigns.
- Do you need to prevent user errors? That's safety. Invest in better UX, validation, and testing.
- Do you need to pass an audit? That's compliance. Hire a compliance specialist or consultant.
- Do you need to handle sensitive data properly? That's data protection. You probably need all three above, coordinated, or, depending of your size, a DPO.
Ask better questions: Instead of "How's our security?" try:
- "What attack vectors are we currently vulnerable to?" (security)
- "What's our blast radius if someone makes a mistake?" (safety)
- "What would fail in our next audit?" (compliance)
- "Where is our most sensitive data and how is it protected?" (data protection)
For Technical People:
Stop letting the terminology slide. When someone calls input validation "security" politely correct them. When a "security review" is actually a compliance audit, say so.
Be precise in your documentation and communications. Don't write "security measures" when you mean "safety controls." Future you (and your replacement) will thank you.
Respect the disciplines. You might be a great developer, but that doesn't make you a security expert, compliance specialist, or data protection officer. Know when to bring in actual expertise.
The Challenge
Here's my challenge to you: For the next week, every time you hear or use the word "security" ask yourself: "Is this actually security, or is it safety, compliance, or data protection?"
You'll be shocked how often we're not even speaking the same language.
Because here's the uncomfortable truth: if we can't even agree on what words mean, how are we supposed to build systems that actually work?
The Bottom Line: Your infrastructure isn't secure just because it's compliant. It's not safe just because it's secure. And having good data protection doesn't automatically give you either. These are different problems requiring different solutions, different skills, and different investments.
So the next time someone in a suit tells you they're a "security expert" and starts talking about GDPR documentation or a developer claims input validation is a "security feature" or a manager asks why the "security team" didn't prevent users from accidentally deleting data...
You'll know exactly what's wrong.
And maybe, just maybe, we can start fixing it.
Have war stories about terminology confusion? Disagree violently with my definitions? Think I'm being pedantic? Drop a comment. I promise I'll validate your input safely before responding securely while remaining compliant with community standards and protecting your data.
Top comments (0)