What Are We Actually Protecting? Understanding the CIA Triad in Real Software
A few years ago, a team fixed a security issue by encrypting everything.
Requests were encrypted.Responses were encrypted.Database fields were encrypted.
Two weeks later, users were seeing other people’s invoices.
Nothing was decrypted incorrectly.Nothing was intercepted.The system was perfectly encrypted.
And completely insecure.
That’s the moment many developers realize: security isn’t just about hiding data.
Before choosing tools, we need to understand what we are protecting in the first place.
That’s where the CIA Triad comes in.
Security has three goals — not one
When people hear security, they often think secrecy. But secrecy is only one part of the story.
Real systems fail in three fundamentally different ways:
Data is exposed.
Data is altered.
Systems stop working.
The CIA Triad simply names these three outcomes:
Confidentiality — who can see it
Integrity — can it be trusted
Availability — can it be used
It’s less a definition and more a lens.Almost every incident you’ve seen fits into one of these.
Confidentiality — keeping the right things private
During an exam, a student covers their answer sheet.
Not because the paper is fragile, but because the answer isn’t meant for the whole room.
Data behaves the same way — it needs boundaries, not just barriers.
Software works the same way.
Confidentiality is not just encryption.
It is making sure information reaches only the intended audience.
A mobile API returning another user’s profile is a confidentiality failure.
So is a service account reading tables it never needed.
“Encryption protects the channel. Authorization protects the data.”
Many systems implement the first and forget the second.
Integrity — knowing the data is still true
Now imagine a bank ledger.Even if nobody else can read it, the bank collapses if numbers silently change. Integrity is about correctness over time.
Has anything been altered — accidentally or intentionally — without detection?
A payment amount modified between client and server is an integrity failure.
An order marked as shipped before payment clears is an integrity failure.
A stale cache granting access after a refund is also an integrity failure.
Notice something important:
none of these require breaking secrecy.
“Leaked data is bad. Incorrect data is dangerous.”
Integrity problems tend to persist longer because systems trust their own state.
Availability — the forgotten pillar
Picture a locked safe that no one can open anymore.
Perfect confidentiality.
Perfect integrity.
Completely useless.
Availability means the system works when needed.
A login system rate-limiting every real user during peak traffic is a failure.
A payment gateway that collapses during a sale is a failure.
An over-protective security rule that blocks legitimate requests is also a failure.
Security that prevents usage is still failure — just quieter.
The tension between them
Here’s the uncomfortable truth: you cannot maximize all three at once.
More verification improves integrity but slows availability.
Stricter access improves confidentiality but harms usability.
Open access improves availability but weakens secrecy.
Engineering is choosing the right imbalance intentionally.
“Security is not perfection. It is prioritization.”
Why developers should care
The CIA Triad is not academic theory.
It is a debugging tool.
When something goes wrong, ask:
Did someone see what they shouldn’t?
Did something change that shouldn’t?
Did something stop working when it should?
You suddenly know what kind of failure you’re dealing with.
Security stops feeling mysterious and starts behaving like any other bug you can track down.
A final thought
Most systems are designed to function.
Secure systems are designed to function under stress, misuse, and surprise.
The CIA Triad gives a simple way to reason about that difference.
Before choosing encryption, authentication, or firewalls,first decide what must stay private, what must stay correct, and what must keep running.Everything else follows from that.