Information should only be read, seen, or accessed by people or systems with explicit permission. This applies at rest (files on a disk), in transit (data crossing a network), and in use (data being processed in memory). Confidentiality is not just about encryption — it's about the entire access control model.
An S3 bucket set to public. A database dump posted to a paste site. Overly permissive IAM policies where every Lambda has full S3 access. Credentials hard-coded in source code pushed to a public repo. A helpdesk agent with access to all customer records because nobody scoped their role. The attacker doesn't need to break in if the data is already accessible.
Who can access this, and does the current configuration actually enforce that? Audit it — don't assume.
Data should be exactly what it's supposed to be — not modified in transit, not altered on disk, not corrupted by accident or malice. Integrity means you can trust that what you're reading hasn't been changed since it was written. This applies to files, database records, log entries, software binaries, and configuration files. Integrity also implies non-repudiation — a record of who changed what and when.
An attacker with system access modifies log files to erase their tracks. A supply chain attack tampers with a build artifact before distribution (SolarWinds, XZ Utils). A MITM injects content into an unencrypted download. A malicious insider edits financial records. Without integrity controls, you can't tell the difference between the original and the modified version.
How do we know this data hasn't been modified — and would we detect it if it had been?
The right people need to be able to access the right resources at the right time. A perfectly confidential, perfectly intact database is worthless if it's offline. Availability covers uptime, performance, disaster recovery, and resilience against both attacks (DDoS, ransomware) and accidents (hardware failure, region outage, misconfigured update).
Ransomware encrypts all files AND the backups that weren't air-gapped. A DDoS floods the single load balancer with no scrubbing upstream. A misconfigured BGP update takes down a cloud region. An expired TLS cert blocks all HTTPS traffic. A single database with no replica fails and takes the whole service with it. Availability failures are often the most immediately visible — and the hardest to explain to leadership.
What happens if this goes down? How long until recovery, and have we actually tested it?
Heavy encryption and strict access controls protect confidentiality but can create availability bottlenecks — if the key management server is down, encrypted data becomes inaccessible. A fully locked-down network may be secure but unusable. Every access restriction you add is a trade against someone's ability to get their work done.
Requiring multi-party authorization for every write protects integrity but destroys speed. Strict audit logging and write controls add latency. Read-only replicas protect integrity from writes but create stale-data risks. Change management processes that prevent fast patches improve integrity but hurt response time during incidents.
There is no perfect. Perfect confidentiality (encrypt everything, no one gets access) destroys availability. Perfect availability (everything accessible everywhere, instantly) destroys confidentiality. Context and risk appetite determine the right balance — a payment processor and a public blog have different answers to the same question.
| Attack | CIA Impact | What happens |
|---|---|---|
Ransomware |
C A | Encrypts files, making them unavailable. Many groups now exfiltrate data first and threaten to publish it (double extortion) — attacking A and C simultaneously. |
SQL Injection |
C I | Reads unauthorized data (confidentiality breach) and may modify or delete records (integrity breach). Can also drop entire tables, creating an availability impact. |
DDoS |
A | Overwhelms servers or network links with traffic, denying access to legitimate users. No data is stolen or modified — purely an availability attack. |
Man-in-the-Middle |
C I | Intercepts traffic (confidentiality) and may alter it before forwarding (integrity). TLS prevents both — which is why SSL stripping attacks try to downgrade connections. |
Supply Chain Attack |
I | Tampers with trusted software before distribution (XZ Utils, SolarWinds, npm package hijacking). The software looks legitimate and passes surface-level checks — integrity is the core victim. |
Phishing |
C | Harvests credentials or installs keyloggers, enabling unauthorized access to data. Primarily a confidentiality attack, but stolen admin credentials can enable I and A attacks downstream. |
Log Tampering |
I | An attacker with system access modifies or deletes audit logs to conceal their activity. Integrity controls (immutable logs, SIEM with write-only ingestion) are the mitigation. |
Insider Threat |
C I A | An authorized user abusing their access. Can exfiltrate data (C), modify records (I), or deliberately destroy systems (A). Hardest to detect — the actor looks legitimate by design. |