Confidentiality, Integrity, Availability — Practically

The triad earns its keep as a *classifier*, not a definition. When something goes wrong, naming which of the three broke tells you who to call, what to check, and whether the damage is reversible. Consider one customer database and three incidents that look nothing alike.

A confidentiality failure is a copy escaping: a public object-storage bucket, a debug endpoint returning full rows, a GET /users/124 that answers for a user who is not you. Copies are irreversible. Once data is out, no amount of remediation puts it back, which is why confidentiality controls must be preventive and why the response is notification rather than repair.

An integrity failure is a write that should not have happened: an unauthorized UPDATE, a tampered webhook that marks an unpaid order as paid, a poisoned cache entry. Integrity failures are often *reversible* if you have audit logs and backups — and completely unrecoverable if you do not, because you cannot even tell which rows are wrong. This is why integrity work is mostly about being able to answer "which records changed, by whom, and when".

An availability failure is legitimate users unable to work: a flood of requests, a decompression bomb exhausting memory, a certificate expiring at 02:00, a rate limiter misconfigured to block real customers. It is a security property even when nothing was stolen, and it is the one most likely to be caused by your own defenses.

Authenticity asks whether a message really came from who it claims. A webhook that says "payment succeeded" is a claim, not a fact, until a signature proves the sender held the shared secret — see Secure Webhooks. Authenticity is what Digital Signatures provide and what makes a spoofed request different from a tampered one.

Accountability — and its stronger relative, non-repudiation — asks whether you can say afterwards who did what. In practice this means an audit log the actor cannot edit, with enough context to answer questions nobody thought to ask at write time. Non-repudiation in the strict cryptographic sense (a signature only one party could produce) is rare in application systems and worth reserving for cases that genuinely need it, such as signed approvals for high-value transactions.

Privacy is distinct from confidentiality and often confused with it. Confidentiality asks whether an unauthorized party can read the data. Privacy asks whether *collecting, retaining, combining or exporting* it is appropriate at all — a question that survives even a perfectly access-controlled system. A support tool where every agent can read every message is confidential against outsiders and a privacy failure inside. Sensitive Data Classification is where the two meet.

The triad is not a set of goals you maximise independently; the properties trade against each other, and pretending otherwise produces controls that get switched off. Aggressive rate limiting protects availability against abuse and destroys availability for a legitimate customer doing a bulk import. Strict fail-closed authorization protects confidentiality and integrity and takes the whole product down when the policy service is unreachable — see Fail Open vs Fail Closed.

Encrypting a column protects confidentiality and removes your ability to index or search it, which pushes teams toward decrypting more rows than needed. Long log retention supports accountability and creates a new confidentiality liability, because logs are a copy of the data with weaker access control than the database it came from.

The engineering skill is naming the trade explicitly and choosing per asset rather than globally. Availability usually wins for a public content endpoint; integrity usually wins for a ledger; confidentiality usually wins for health records. A system that applies one answer everywhere is misconfigured somewhere by construction.