The CIA triad, explained simply

If you have ever opened a security checklist and felt buried, the CIA triad is the thing that makes it stop feeling random. It is three words: Confidentiality, Integrity, Availability. I am still studying for the Security+ and the eJPT, so I am writing this the way I would explain it to myself in my own notes. The reason this model shows up on day one of almost every cert is that it gives you a way to decide what actually matters before you touch a single tool.

Here is the short version. Every security decision you make is protecting one of three things: keeping secrets secret, keeping data trustworthy, or keeping the system reachable. Once you can name which one is on the line, you stop guessing about where to spend your time.

Confidentiality: only the right people see it

Confidentiality is about keeping data away from people who should not have it. When you read a headline about a password leak or a database of customer emails getting dumped, that is a confidentiality failure. The data was supposed to be private and it ended up somewhere it should not be.

Everyday examples:

• A password leak or a stolen API key.
• An employee who can read salary records they have no business seeing.
• A laptop with an unencrypted drive getting left in a coffee shop.

The controls that defend confidentiality are the ones you already half know:

• Encryption, both at rest (the database on disk) and in transit (HTTPS on the wire).
• Access control, so each account only reaches what it needs.
• Hashing passwords instead of storing them in plain text.

# in transit: confirm the cert and that the connection negotiates TLS
curl -vI https://example.com 2>&1 | grep -i "TLS\|HTTP/"

If a leak would embarrass you or expose someone, you are looking at a confidentiality problem.

Integrity: the data is what it should be

Integrity is about trust. Has the data been changed by someone who should not have changed it, or changed by accident? A tampered invoice is the classic example. If an attacker edits the bank account number on a PDF invoice before it reaches a customer, every byte still arrives, the file still opens, but the information is now a lie. Nothing leaked. The data is just wrong.

Other integrity failures:

• A software download that got modified to include malware.
• A log file an attacker edited to hide their tracks.
• A form that lets a user change the price field in a checkout request.

The controls here are about detecting change:

• Hashing and checksums. If the hash of a file changes, the file changed.
• Digital signatures, which tie a change to a known signer.
• Validation on input, so the server never trusts numbers the browser sends.

# compare a download against a published checksum
sha256sum installer.bin
# then check it matches the value the vendor published

If the question is "can I trust that this number, file, or record is correct," that is integrity.

Availability: the system is actually up

Availability is the simplest to feel and the easiest to forget when you are thinking about attackers. It means the system is there when someone needs it. A DDoS attack, where a flood of traffic knocks a site offline, is a pure availability attack. The attacker may never steal a thing or change a single record. They just make sure nobody else can get in.

Availability also breaks in boring, non-attacker ways:

• A server runs out of disk and the app crashes.
• A bad deploy takes the checkout page down for an afternoon.
• Ransomware encrypts your files so you cannot reach your own data.

The controls:

• Backups you have actually tested by restoring.
• Redundancy, so one failed machine is not the whole story.
• Rate limiting and monitoring so you notice trouble early.

Notice that ransomware hits two corners at once: availability (you cannot get to your files) and often confidentiality (the attacker copied them first). Real incidents rarely stay in one box, and that is fine. The triad is for thinking, not for sorting things into perfect bins.

A small walk-through: a one-person SaaS

Say I run a small SaaS, a paid tool with a login, a database of customer records, and Stripe handling payments. Where do I spend my limited evenings? I walk the three letters.

Confidentiality. The customer data is the asset I would hate to leak. So: hash passwords with a real algorithm, force HTTPS everywhere, encrypt the database at rest, and make sure my admin account is not the same login I use for casual testing. Keep secrets out of the repo.

Integrity. The dangerous spot is anything tied to money or permissions. Never trust the price or the user role coming from the browser. Validate it on the server against what the database says. Log important actions in a way that is hard to quietly edit later.

Availability. I am one person, so I lean on the platform: managed hosting that handles failover, automated backups, and a test restore on the calendar so I know the backup is real and not just a green checkmark. Add basic rate limiting on the login route so one script cannot hammer it.

That walk took five minutes and it gave me a to-do list ordered by what would actually hurt. That is the whole point of the triad. It is a cheap way to turn a vague worry into a short, ranked plan.

Honest wrap

This is fundamentals, and I am writing it as a learner, not as someone who has passed the exam yet. But the triad has already changed how I read my own projects. Before I add a feature, I ask which letter it touches and whether I am protecting it. Most of the time the answer points me straight at the thing I was about to skip.

If you build small websites and want a plain, builder-focused take on the integrity and confidentiality pieces (input validation, secrets, HTTPS done right), I wrote those notes up in Web Security for Builders ($29, aldowebsitellc.xyz/shop/web-security-for-builders). And if you would rather just see what holds up on your own site, the triad is a decent lens to start with.