It's 2:00 AM on a Sunday. A bank's IT operations team is midway through an approved maintenance window. A critical patch needs to be applied to the core banking middleware — a vulnerability flagged by the vendor as high severity, with a working proof-of-concept exploit already circulating in threat intelligence feeds.
The problem: applying the patch requires a full system restart. And the bank's File Integrity Monitoring tool can't run during the restart sequence without triggering a cascade of false-positive alerts that would wake up the entire security team.
The team lead makes a call: disable the FIM tool for 90 minutes, apply the patch, restart, re-enable. The maintenance window closes on time. Nobody is alerted. The change management record notes: "FIM temporarily suspended during patch cycle."
Six months later, an auditor reviewing the change records flags it. Not because anything went wrong. But because for 90 minutes, the bank had no way to detect if something had.
This is the CIA triad working — and in tension — at the same time.
“The CIA triad doesn't fail because people don't understand the definition. It fails because organisations don't plan for what happens when the pillars pull in opposite directions.”
What the CIA Triad Actually Is
The CIA triad stands for Confidentiality, Integrity, and Availability. It's the foundational framework for information security — the three properties that any well-secured system must protect, in balance, simultaneously.
If you've studied for any security certification, you've seen it. If you work in GRC or IT, you use it as a diagnostic lens whether you explicitly name it or not. When a breach happens, the first questions are always some version of: Was data exposed? Was it altered? Was the system taken down? That's the CIA triad.
What most explanations of it skip is the part that makes it actually useful: the three pillars don't always cooperate. Protecting one often comes at a cost to another. Understanding those tensions is what separates someone who can recite the definition from someone who can apply it.
Click any corner to jump to that section · Hover for definition
Confidentiality: Only the Right Eyes See It
Confidentiality means that information is accessible only to those who are authorised to access it. Not just protected from attackers — protected from anyone without a legitimate need to see it, including well-intentioned insiders.
The controls that enforce confidentiality include:
- Encryption — data rendered unreadable without the correct key, both in transit and at rest
- Access controls and identity management — role-based permissions that limit what each user can see and do
- Data classification — understanding what data is sensitive, so you know what actually needs protecting
- Authentication mechanisms — passwords, MFA, certificates that verify identity before granting access
In banking, confidentiality is most visibly applied to customer financial data, transaction records, and internal credit assessments. The failure mode isn't always a dramatic breach — it's often a misconfigured cloud storage bucket, an over-permissioned service account, or a report emailed to the wrong distribution list.
In PCI DSS assessments, one of the most common confidentiality findings isn't technical — it's access control scope. Service accounts with read access to entire CHD environments when they only need access to one table. The vulnerability isn't the encryption failing. It's the permissions being far broader than any business need requires.
Integrity: The Data Says What It Should Say
Integrity means that data is accurate, complete, and has not been modified without authorisation — whether maliciously or accidentally. It covers both data at rest and in transit.
The controls that enforce integrity include:
- File integrity monitoring (FIM) — tracks cryptographic hashes of files and alerts when they change unexpectedly
- Checksums and digital signatures — verify that data hasn't been tampered with between origin and destination
- Audit logs — immutable records of who changed what, and when
- Input validation — preventing malformed or malicious data from entering a system in the first place
- Change management processes — ensuring system changes are authorised, documented, and reviewed
Integrity failures are often quieter than confidentiality breaches — the data is still there, the system is still running, but something is slightly wrong. That's what makes them dangerous. A fraudster who can silently modify transaction records doesn't need to steal anything. They just need to make the numbers say something different.
Organisations often focus integrity controls on external threats — firewalls, intrusion detection — while leaving internal modification pathways under-monitored. Many integrity failures originate from insiders with legitimate access who modify data without going through change control. Audit logging only helps if someone is actually reviewing the logs.
Availability: It Works When You Need It To
Availability means that authorised users can access systems and data when they need to. An information security failure doesn't have to involve theft or corruption — if the system is simply unreachable, the impact can be just as severe.
The controls that enforce availability include:
- Redundancy and failover — duplicate systems that take over when a primary system fails
- Backups and disaster recovery plans — tested procedures for restoring service after a catastrophic failure
- DDoS protection — filtering malicious traffic before it can overwhelm systems
- Patching and vulnerability management — keeping systems updated so they aren't taken down by known exploits
- Business continuity planning (BCP) — ensuring critical operations can continue even when technical systems fail
In financial services, availability failures carry direct revenue and regulatory consequences. A payment processor offline for four hours during business hours isn't just a technical incident — it's potential regulatory notification, customer compensation, and reputational damage.
Availability is the pillar most likely to be deprioritised in budget cycles until something goes catastrophic. In ISO 27001 gap assessments, A.5.30 (ICT readiness for business continuity) and A.8.14 (redundancy) are among the controls most frequently rated as partially implemented — because "we have backups" and "we have tested backups that actually restore in under 4 hours" are very different things.
Do You Have the Triad Right?
3 questions. No tricks. Test your understanding before we go deeper.
A hospital database is accessed by an unauthorised third-party contractor who reads patient records but changes nothing. Which pillar has been violated?
During a ransomware attack, a bank's online banking portal goes offline for 18 hours. Customer data is never exfiltrated. Which pillar failed?
An insider at a payment processor subtly alters transaction amounts in a financial database — rounding down each transaction by $0.01 and routing the difference to an external account. Which pillar has been attacked?
When the Three Pillars Fight Each Other
This is where the CIA triad becomes genuinely useful — and where most explanations stop short.
The three pillars are not independent. Strengthening one often weakens another. Good security design is not about maximising all three simultaneously — it's about making conscious, documented tradeoffs based on the specific risk context.
Confidentiality vs. Availability
The most common tension in practice. Every authentication control you add to protect confidentiality adds friction that reduces availability — from the user's perspective and from the system's.
End-to-end encryption for all data in transit increases confidentiality but adds latency. Strict MFA on every transaction is better for confidentiality but worse for the experience of a customer trying to make a payment quickly. Network segmentation protects confidentiality by restricting lateral movement but increases complexity, which can reduce resilience.
In banking, this tension shows up most clearly in high-volume transaction environments. A financial institution processing millions of transactions per second must apply cryptographic integrity checks to every one — but each check adds compute overhead that directly affects throughput. There is no free lunch.
Integrity vs. Availability
The scenario at the start of this article is a live example of this tension. The FIM tool was disabled — temporarily sacrificing the ability to detect integrity violations — in order to complete a patch without triggering alert noise that would have extended the maintenance window and reduced availability.
The decision wasn't wrong. But it needed to be documented, reviewed, and compensated for — perhaps by manually reviewing all system files after the window closed, or by having a second team member verify the patch integrity independently.
Confidentiality vs. Integrity
Some integrity mechanisms — like detailed audit logs that capture exactly what data was accessed, by whom, and what changed — can inadvertently reduce confidentiality by recording sensitive data in log files that are less tightly controlled than the primary system.
Log files containing PII, transaction amounts, or authentication tokens in plain text are a real and documented finding in payment system assessments. The integrity mechanism (logging everything) creates a confidentiality exposure (the log itself is a sensitive data store).
Real Incidents, Analyzed
Theory is useful. Incidents are better. Here are three well-documented cases — each one a case study in exactly which pillar failed, and why.
Attackers gained access to Bangladesh Bank's SWIFT terminal and submitted 35 fraudulent transfer requests totalling $951 million. Five transfers worth $101 million cleared before the fraud was detected. $81 million was never recovered. Which pillar failed: Integrity — the attackers didn't steal credentials to view data or take the system offline. They modified the data. Fraudulent SWIFT messages were injected into the messaging system that looked legitimate to every automated check downstream. The attackers also deleted the SWIFT message logs to cover their tracks — destroying the integrity of the audit trail itself. A second integrity failure, layered on top of the first.
Which pillar: Integrity
Integrity controls on financial transaction systems are not optional. SWIFT CSCF Control 2.9 (Transaction Business Controls) exists specifically because of this incident. Anomaly detection — watching for transactions that fall outside established behavioural patterns — is the integrity control that should have caught this.
The NotPetya wiper malware hit Maersk — one of the world's largest shipping companies. Within hours, 45,000 PCs and 4,000 servers across 130 countries were wiped. The company estimated losses of $300 million. For 10 days, global shipping operations ran on paper and phone calls. Which pillar failed: Availability — this was a catastrophic, near-total availability failure. NotPetya didn't steal data. It didn't selectively alter records. It destroyed the systems entirely. Maersk's backups survived — but recovery still took 10 days because restoring 45,000 machines across a global network takes time even when the restore image is available.
Which pillar: Availability
Availability planning must account not just for whether backups exist, but how long complete restoration actually takes. An availability control that takes longer to invoke than the business impact can absorb is a partial control at best.
Attackers compromised the SolarWinds Orion build pipeline and inserted malicious code into a legitimate software update. The update was signed and distributed through official channels to approximately 18,000 customers — including multiple US government agencies and major financial institutions. The compromise went undetected for over nine months. Which pillar failed: Both Integrity and Confidentiality — simultaneously, at the supply chain level. The integrity failure was the tampered software update. The confidentiality failure followed automatically: attackers had persistent, trusted access to customer networks for months. The SolarWinds update was legitimately signed. The checksums matched. Standard integrity controls passed because the attack happened upstream of where those controls were applied.
Which pillar: Integrity + Confidentiality
Supply chain integrity is one of the hardest problems in modern security. This is why SWIFT CSCF Control 6.2 (Software Integrity) specifically addresses the integrity of SWIFT-related software — and why simply trusting a vendor's update without independent verification is no longer an acceptable control posture for critical financial infrastructure.
The CIA Triad Mapped to Real Frameworks
Every major security and compliance framework is built on top of the CIA triad. Here's how they map.
| Pillar | ISO 27001 Annex A | PCI DSS v4.0.1 | SWIFT CSCF v2025 |
|---|---|---|---|
| Confidentiality | A.5.12 — Classification of information | Req 3 — Protect stored account data | 1.1 — SWIFT Environment Protection |
| Confidentiality | A.5.15 — Access control policy | Req 4 — Protect cardholder data in transit | 2.6 — Confidentiality and integrity of sessions |
| Confidentiality | A.8.24 — Use of cryptography | Req 7 — Restrict access to system components | 6.1 — Logical access controls |
| Integrity | A.8.7 — Protection against malware | Req 6 — Develop and maintain secure systems | 2.7 — Vulnerability scanning |
| Integrity | A.8.9 — Configuration management | Req 10 — Log and monitor all access | 2.9 — Transaction business controls |
| Integrity | A.8.20 — Network security controls | Req 11 — Test security of systems regularly | 4.1 — Cyber incident response |
| Availability | A.8.13 — Information backup | Req 12.3 — Manage risk with targeted risk analysis | 2.2 — Security updates |
| Availability | A.8.14 — Redundancy of information processing | Req 6.3 — Identify and manage system components | 2.3 — System hardening |
| Availability | A.5.30 — ICT readiness for business continuity | Req 12.10 — Implement an incident response plan | 6.2 — Software integrity |
What Would You Prioritise?
No right or wrong answer — but every choice has a consequence.
A bank's security team discovers a critical patch must be applied to the core banking middleware. Applying it requires taking the system offline for 4 hours on a weekday. Delaying the patch leaves a known vulnerability unpatched. Which do you prioritise?
A financial institution is implementing end-to-end encryption for all customer data in transit. The chosen algorithm will add ~300ms of latency to every transaction. The business team objects. What does the CIA Triad tell you to do?
What This Means For You
The CIA triad is not a definition to memorise for an exam and forget. It's a diagnostic tool you use every time you design a control, review an architecture decision, or investigate why something went wrong.
When a security incident happens, ask three questions immediately:
- Was data exposed to someone who shouldn't have seen it? (Confidentiality)
- Was data created, modified, or deleted without authorisation? (Integrity)
- Were legitimate users unable to access what they needed? (Availability)
The answer tells you where the failure occurred. The framework mapping above tells you which controls should have prevented it. The tradeoffs section tells you why it might have been a documented risk decision, not a failure at all.
If you work in banking, payments, or financial services compliance, every framework you're assessed against — ISO 27001, PCI DSS, SWIFT CSP — expresses its requirements in these three terms. Understanding the triad at this level means you can read any new control and immediately understand what it's protecting, which pillar it serves, and what it trades off against. That's not exam knowledge. That's the way practitioners think.
The CIA triad wasn't invented by one person — it evolved. The concept of confidentiality in computing first appeared in a 1976 US Air Force study. Integrity was formalised in a 1987 paper by David Clark and David Wilson. Availability came into focus after the 1988 Morris Worm took down a significant portion of the early internet. The three were commonly grouped together by the late 1990s. Researcher Donn Parker later proposed a six-element 'Parkerian Hexad' expanding on the triad — but the core three remain the industry standard.
Yes — but it's worth understanding its limits. The triad gives you a clean diagnostic lens: when something goes wrong, you can quickly identify which pillar failed. What it doesn't do well is account for non-repudiation, privacy obligations under GDPR, or supply-chain integrity across third parties. For those, you need frameworks like ISO 27001, NIST CSF, or SWIFT CSCF sitting on top of the triad.
ISO 27001 is built on the CIA triad. The standard defines information security as 'the preservation of confidentiality, integrity and availability of information.' Every one of the 93 Annex A controls in ISO 27001:2022 ultimately serves one or more pillars of the triad. Access controls protect confidentiality. Audit logging protects integrity. Business continuity planning protects availability.
The Parkerian Hexad expands the triad by adding three elements: possession (physical control over data regardless of confidentiality), authenticity (verifying the origin of data), and utility (whether data is in a usable form). Most organisations still operate primarily against the three-pillar triad — the hexad is more relevant in academic and legal contexts.
Yes — this is one of the most practical aspects of the triad and one most introductory articles ignore. Stronger confidentiality controls (encryption, MFA, strict access restrictions) often reduce availability by adding friction. Integrity checking (file integrity monitoring, checksums) consumes system resources, which can affect availability under load. Good security design means making documented, deliberate tradeoffs — not pretending the tension doesn't exist.