CIA Triad, AAA, and Non-Repudiation: Core ISC2 CC Security Concepts

The CIA triad is the classic model that states the three objectives of information security: confidentiality (data is disclosed only to authorized people), integrity (data is accurate and unaltered), and availability (data and systems are usable when needed). Every security control you will ever study - encryption, backups, firewalls, access reviews - exists to protect one or more of these three properties. When the exam asks what a control is for, the safest first move is to map it onto the triad.

The triad matters because it turns vague worry into a checklist. A security team does not ask only whether hackers can steal data; it asks whether data can be read by the wrong people (confidentiality), changed without detection (integrity), or made unreachable (availability). A single incident can hit more than one property at once. Ransomware, for example, encrypts your files so you cannot use them (an availability attack), and modern ransomware gangs also steal the data first and threaten to leak it (a confidentiality attack).

Expect the exam to test the triad in scenario form. A nurse reads the medical chart of a celebrity patient she is not treating: that is a confidentiality breach, even though nothing was changed or taken offline. An attacker alters the payee account number in a payment file: integrity. A flood takes a data center offline: availability. Train yourself to name the property first and the control second; that single habit answers a large share of Domain 1 questions.

Confidentiality means information is accessible only to the people, processes, and systems that are authorized to see it. It is the property most people picture when they hear the word security, and it is what secrecy-focused controls protect: encryption of data at rest and in transit, access controls that check permissions before releasing data, and data classification labels that tell staff how sensitive a document is and how to handle it.

Threats to confidentiality include obvious attacks and quiet failures. Obvious attacks are things like stolen laptops, intercepted network traffic (sniffing), and phishing that captures credentials. Quiet failures include shoulder surfing (someone reading your screen over your shoulder), misaddressed emails, over-broad permissions that let staff browse data they do not need, and improper disposal of paper records or old drives. The exam likes these low-tech examples precisely because candidates fixate on hackers and forget them.

Two related terms are worth pinning down. Least privilege is the principle that a user should receive only the minimum access needed to do their job; it is the day-to-day discipline that keeps confidentiality intact. Need to know is the closely related idea that even among people with the same clearance or role, access to a specific piece of information requires a specific job-related reason. When a question describes data seen by someone who had no business reason to see it - even an insider with a valid account - the answer is a confidentiality violation, often paired with a least-privilege or need-to-know failure.

Integrity means data is accurate, complete, and has not been modified in an unauthorized way - whether by an attacker, a malfunction, or an honest mistake. Integrity also extends to systems: a server has integrity when it runs only the software and configuration it is supposed to run. If confidentiality answers the question who can see it, integrity answers the question can I trust it.

The main integrity mechanism you must recognize is hashing. A hash function takes any input and produces a short fixed-length fingerprint; if even one bit of the input changes, the hash changes completely. By comparing the hash of a file today with the hash recorded earlier, you can detect tampering or corruption. Downloads published with checksums, file integrity monitoring on servers, and digital signatures all rest on hashing.

Know the limit of a bare hash: it proves only that the data is unchanged since the reference hash was taken, not who produced it. Anyone can compute a hash, so an attacker who replaces a download can publish a matching hash for the malicious file, and the comparison will still succeed. A hash therefore verifies integrity; proving origin as well requires a digital signature, in which the hash is signed with the producer's private key (covered under non-repudiation below).

AI systems add a new integrity target: the training data. Data poisoning is the unauthorized insertion or alteration of the data a machine-learning model learns from, so that the trained model makes corrupted decisions. The closely related model poisoning tampers with the model itself rather than its data - for example, a trojaned pre-trained model downloaded from a public repository. Because the harm in both cases is unauthorized modification, both are integrity attacks. A subtle form plants a backdoor: a hidden rule that stays dormant until the attacker presents a chosen trigger, so the model passes routine evaluation and the tampering surfaces only when that trigger is used.

Keep poisoning distinct from the other AI attacks by asking when the attacker acts and what they want:

Training data is protected with the same integrity tool as any other file. Fingerprinting a dataset at the moment it is approved, and comparing those fingerprints whenever the data is used, means any change made after approval is caught before it reaches the model. Hashes cannot tell you the approved data was clean to begin with - poison already present in a scraped public collection passes the check - so that is what data provenance (knowing and documenting where each dataset came from) and data review or sanitization are for. The reference hashes must also be stored where an attacker cannot rewrite them, for the same reason a published checksum can be swapped along with a download. As a general rule, controls built for confidentiality, availability or authentication do not detect change: encryption hides data but does not reveal edits by someone who holds the key, copying data to more places copies any tampering too, and stronger sign-in controls who gets in, not what they change.

Other integrity controls include input validation (rejecting malformed data before it enters a system), version control, and change management processes that ensure modifications are approved and documented.

Integrity failures do not require an attacker. A billing clerk who fat-fingers an extra zero, a failing disk that silently corrupts records, and a buggy script that overwrites a database all destroy integrity. The exam signals integrity with words like modified, altered, tampered, corrupted, and accuracy. One classic scenario: an attacker changes student grades in a university database. Nothing was disclosed and nothing went offline, so confidentiality and availability are intact - the property violated is integrity.

Availability means authorized users can reach the data and systems they need, when they need them. A perfectly confidential system that nobody can log into has failed at its job. Availability controls include redundancy (spare servers, duplicate network links, RAID storage), backups and tested restore procedures, uninterruptible power supplies and generators, disaster recovery sites, and capacity planning. The classic attacks on availability are denial-of-service (DoS) and distributed denial-of-service (DDoS) floods, plus ransomware; the classic non-attack causes are hardware failure, power loss, and natural disasters.

The three properties pull against each other, and the exam expects you to recognize the tension. Stronger confidentiality often costs availability: more login steps, more encryption, and tighter permissions all slow legitimate users down and add ways to be locked out. A hospital is the standard example: emergency clinicians need patient records instantly (availability can be life-or-death), yet the same records are among the most sensitive data anywhere (confidentiality is legally mandated). Real designs balance the triad based on the organization's needs; they do not maximize one property blindly.

Key management shows the same tension. Encrypting backups protects their confidentiality, but if the only copy of the decryption key is held by one person, that key becomes a single point of failure: if the person leaves, is unavailable, or loses the key, the backups cannot be restored and availability is lost. Sound designs keep confidentiality without that risk by storing protected copies of the key (for example key escrow or a secured backup of the key) and by not making any single individual the only route to it.

The triad also sets no fixed priority order. Neither confidentiality nor integrity nor availability always comes first; which one leads depends on the business purpose of each system. A public website's content needs integrity and availability far more than secrecy, a payment ledger puts integrity first, and a file of trade secrets puts confidentiality first. Deciding the priority is a business judgment made system by system.

When a question asks which property a control protects, match it against this table. Backups protect availability (and support integrity recovery); encryption protects confidentiality; hashing protects integrity. Memorize those three pairings - they are near-certain exam material.

Authentication is the process of verifying a claimed identity. It always comes in two steps: first you assert an identity (identification - typing a username), then you prove it (authentication - supplying evidence only the real owner should have). Authentication answers exactly one question: are you really who you say you are? It says nothing about what you may do afterward - that is authorization's job, and confusing the two is the single most common mistake on this sub-domain.

The evidence you present falls into three classic authentication factors:

• Something you know - a password, PIN, or passphrase. Cheap and universal, but guessable, phishable, and reusable.
• Something you have - a smart card, hardware security key, or a phone generating one-time codes. Must be physically possessed or controlled.
• Something you are - a biometric: fingerprint, face, iris, or voice. Bound to your body and hard to share, but not secret and not changeable if compromised.

Multi-factor authentication (MFA) means requiring evidence from two or more different factors. A password plus a one-time code from your phone is MFA (know + have). A password plus a PIN is not MFA - both are things you know, so it is just two instances of a single factor. The exam tests exactly this distinction, so check the factor categories, not the count of prompts. MFA matters because a phished password alone no longer grants access; the attacker would also need your phone or your fingerprint.

Authorization happens after successful authentication and determines what an authenticated identity is permitted to do: which files it can read, which records it can change, which systems it can reach. Authorization is enforced through permissions, access control lists, and role assignments. Two people can authenticate to the same system with equal success and hold completely different rights - a payroll clerk and the CFO both log in, but only one can approve wire transfers.

Accounting (also called auditing) is the recording of what each identity actually did: logins and failed logins, files accessed, records changed, commands run, and when. Accounting produces logs and audit trails. It does not stop bad actions in the moment; its value is detection, investigation, accountability, and evidence. It also underpins non-repudiation, covered next, because a reliable record of who did what makes denial implausible.

Walk through a concrete scenario: you open your banking app. You enter your username and password and approve a push notification on your phone - that is authentication, with two factors. The app then lets you view your own accounts but not anyone else's, and your daily transfer limit is 5,000 - that is authorization. Behind the scenes the bank records your login time, device, and every transfer you make - that is accounting. If a question later arises about a disputed transfer, those logs are what investigators pull. One login, all three A's, in a fixed order: authenticate, then authorize, then account.

Non-repudiation is the assurance that someone cannot later deny having performed an action - sending a message, approving a transaction, signing a document. Repudiate means to deny; non-repudiation removes the ability to deny credibly. It protects both sides of a transaction: the sender cannot claim they never sent the order, and the receiver cannot claim they never received it, because there is verifiable proof.

The primary technical mechanism is the digital signature. A digital signature is created with the signer's private key, which only the signer possesses; anyone can verify the signature with the matching public key. Because no one else could have produced that signature, the signer cannot plausibly deny creating the message - and because the signature is computed over a hash of the content, it simultaneously proves the content was not altered. Digital signatures therefore provide non-repudiation, authentication of origin, and integrity in one mechanism.

Supporting mechanisms include comprehensive audit logs, timestamps, and video or transaction records - accounting data that ties a specific identity to a specific action at a specific time.

Logs are weaker evidence than a signature, for two reasons. First, logs are kept by one party: when a company portal records that a partner signed in with MFA and clicked approve, those records sit on systems the company controls, so the partner can argue they were altered or misattributed. Second, a log entry is not bound to the content itself; it says an account performed an action, not that this exact document was approved. A digital signature made with the partner's own private key avoids both problems, because only the partner holds that key and the signature covers the exact content. That is why the signature is the primary mechanism and logs are supporting evidence.

Non-repudiation also only works when identities are not shared. If five administrators all use one shared admin account, the logs can prove the account acted, but any individual can deny being the person behind the keyboard. Strengthening the shared account does not fix this: adding MFA makes the login harder to steal, write-once (tamper-proof) logging protects the integrity of the records, and session recording shows what was done, but none of them shows which person did it. Only unique, per-person identities make a logged action attributable to one individual, which is why unique accounts per person are a baseline requirement. On the exam, trigger phrases like cannot deny, proof of origin, or disputes sending the email point straight at non-repudiation, and the mechanism answer is almost always the digital signature.

Privacy is the right of individuals to control how their personal information is collected, used, shared, and retained. It overlaps with confidentiality but is not the same thing. Confidentiality is a security property that applies to any sensitive data - trade secrets, source code, military plans. Privacy applies specifically to personal data about people, and it goes beyond keeping that data secret: an organization can hold your data perfectly confidentially and still violate your privacy by collecting more than it needs, using it for purposes you never agreed to, or keeping it forever. Confidentiality is one tool that protects privacy; privacy is the broader obligation.

The core vocabulary term is PII - personally identifiable information: any data that can identify a specific individual, alone or in combination. Examples include names, government ID numbers, addresses, phone numbers, email addresses, biometric records, and combinations like date of birth plus postal code. Health-related personal data is often treated as an especially sensitive category (in the United States, protected health information under HIPAA). Data that cannot be tied to a person is not PII on its own: aggregated statistics such as the number of orders per year or the most popular product, and records kept with no link to any individual. The test is whether the data identifies someone, directly or in combination. Removing names alone is not enough: a staff dataset that keeps each person's job title, office location and start date can often be matched back to one individual, because few people share that exact combination. Such indirect identifiers (quasi-identifiers) in combination still make the data personal. The exam expects you to recognize PII examples and to know that PII demands heightened protection throughout its lifecycle: minimal collection, defined purposes, secure storage, controlled sharing, and secure disposal.

Privacy expectations are increasingly written into law - the European Union's GDPR is the most cited example, and many countries and states have equivalents. At CC depth you do not need legal detail; you need the concepts: organizations must protect the personal data they hold, individuals have rights over their own data, and security professionals implement the controls (encryption, access control, retention limits, disposal) that make those obligations real. When a scenario involves customer or employee personal data, think privacy and PII first, then apply the ordinary confidentiality toolkit.