Understand Cybersecurity Concepts

A payroll clerk emails the salary spreadsheet to the wrong person. A week later someone quietly changes one salary figure in it, and on payday the payroll system will not load. All three events are security failures, but each breaks a different property, and naming the property that broke is the skill behind objective 1.1 of the ISC2 Certified in Cybersecurity (CC) exam outline^[1]. The objective lists six topics: confidentiality, integrity, availability, authentication, authorization and accounting (AAA), non-repudiation, and privacy. Split AAA into its three parts and you have eight concepts.

This page sorts those eight concepts onto two sides. The grouping is a study aid used throughout this page, not an official ISC2 category:

• The information side asks what happened to the information: was it disclosed to the wrong people (confidentiality), improperly changed or destroyed (integrity), out of reach when needed (availability), or, when it is information about a person, collected, used or kept inappropriately (privacy).
• The actor side asks about whoever acted on the information: did they prove who they are (authentication), were they allowed to do it (authorization), is there a record of what they did (accounting), and can they credibly deny it later (non-repudiation).

The figure below shows the two sides and the four concepts on each, with the question each concept answers.

ISC2 also states that the outline applies these principles to AI systems: data integrity is vital for preventing model poisoning, privacy must be protected when handling AI training data, and AI-generated actions and access must remain traceable^[1].

Within the Security Principles domain, this page covers the eight concepts themselves. The same domain of the CC exam outline^[1] lists risk management concepts as objective 1.2 and technical, administrative and physical cybersecurity controls as objective 1.4.

The takeaway: each of the eight concepts has its own definition, so naming the concept behind an event means matching the event to that definition, such as unauthorized disclosure for confidentiality or disruption of access for availability, two of the losses defined in FIPS 199^[2], the NIST standard for rating the impact of losing each property.

This section defines the three information properties using the definitions that the NIST glossary^[3] takes from US federal law, 44 U.S.C. § 3552. NIST calls them security objectives; together they are widely known as the CIA triad.

Property	NIST definition	What a loss of it means
Confidentiality	Preserving authorized restrictions on information access and disclosure, including means for protecting personal privacy and proprietary information[3]	Unauthorized disclosure of information
Integrity	Guarding against improper information modification or destruction[4]	Unauthorized modification or destruction of information
Availability	Ensuring timely and reliable access to and use of information[5]	Disruption of access to or use of information or an information system

The right-hand column uses the wording of the impact-rating standard FIPS 199^[2], which defines each kind of loss in exactly those terms.

Confidentiality: who may see it

Confidentiality is about disclosure, not damage. If an employee sends a sensitive file to the wrong recipient, confidentiality is lost as soon as the wrong person can read it, even though the file is still accurate and still usable. That is why a misdirected but unmodified file is a confidentiality failure and not an integrity failure: nothing in it was altered. The definition covers proprietary business information, such as pricing or product plans, as well as personal information.

Integrity: is it still correct

Integrity is about improper change or destruction, and the motive does not matter. A clerk who mistypes a payment amount and an attacker who edits it on purpose both damage integrity, because the record no longer reflects what it should. The clerk's mistake still fits the FIPS 199^[2] wording, unauthorized modification: the clerk may edit the record, but nobody authorized that wrong amount. The definition's word improper draws the line: an authorized, controlled update, such as an approved salary change entered through the normal process, is compatible with integrity; a value nobody approved is not, whoever typed it. An altered payment amount is an integrity problem rather than a confidentiality problem, because the issue is whether the record is accurate, not who was able to see it.

The 44 U.S.C. § 3552 integrity definition also includes ensuring information non-repudiation and authenticity^[4], while the CC outline lists non-repudiation as a topic of its own. The two are consistent: trusting data includes trusting where it came from. On its own, non-repudiation is protection against an individual who falsely denies having performed a certain action^[6].

Availability: can authorized users get to it in time

Availability means authorized users can reach and use information when they need it. A service that still holds accurate, secret records but cannot answer legitimate requests has an availability problem. A common deliberate cause is denial of service^[7], which NIST defines as the prevention of authorized access to resources or the delaying of time-critical operations; failures of supporting infrastructure, such as a power or network outage, cause the same kind of loss without any attacker. A failed service is not a confidentiality problem just because users cannot see the data: confidentiality keeps unauthorized people out, while availability keeps authorized people able to get in.

The takeaway: FIPS 199^[2] defines a different kind of loss for each property. If the wrong people could see it, that is confidentiality. If it is no longer correct or complete, that is integrity. If the right people cannot use it in time, that is availability.

This section explains why confidentiality, integrity and availability are not equally important for every kind of information, and how a NIST standard expresses the difference. FIPS 199^[2] has an organization rate the potential impact of losing each property separately, judged by the effect on its operations, its assets or individuals:

Impact level	Meaning in FIPS 199
Low	The loss could be expected to have a limited adverse effect
Moderate	The loss could be expected to have a serious adverse effect
High	The loss could be expected to have a severe or catastrophic adverse effect

The standard's own examples show how differently the three ratings can come out for different information:

Information (FIPS 199 example)	Confidentiality	Integrity	Availability
Public information on an organization's web server	Not applicable	Moderate	Moderate
Extremely sensitive investigative information at a law enforcement organization	High	Moderate	Moderate
Routine administrative information at a financial organization	Low	Low	Low

The first row is FIPS 199's example of an organization managing public information on its web server. Disclosure causes no harm when the information is already meant to be public, so FIPS 199 marks confidentiality as not applicable, a value it allows only for confidentiality. Integrity and availability still matter: if someone alters the published content or takes the site offline, the organization and the people relying on it are harmed.

The organization therefore chooses safeguards according to the consequences of losing each property for the mission that information supports. A public information service may still need real protection against tampering and outages (Moderate in the FIPS 199 example) while confidentiality does not apply. Prioritizing secrecy for every information asset is a mistake, because it ignores the different business effects of modification and unavailability.

The takeaway: the most important property is the one whose loss would hurt the mission most, and that differs from one kind of information to the next.

This section applies the integrity property to AI systems, a link the CC outline makes explicitly. The plain idea first: an AI model learns from its training data, so anyone who can secretly change that data can change what the model learns.

NIST's taxonomy of attacks on machine learning, NIST AI 100-2^[8], calls attacks during the training stage poisoning attacks and separates two kinds by what the attacker controls:

• Data poisoning^[9]: the attacker controls part of the training data, by inserting or modifying training samples.
• Model poisoning^[10]: the attacker controls the model itself and its parameters.

The CC outline's phrase data integrity is vital for preventing model poisoning^[1] uses the term broadly, as NIST uses poisoning for adversarial attacks during the training stage^[8]; of NIST's two kinds, data integrity helps prevent data poisoning, since model poisoning targets the model's parameters, not its training data. Inserting or modifying training samples without authorization is improper modification of information, which is the integrity definition from the confidentiality, integrity and availability section above.

NIST AI 100-2 also sorts poisoning by what the attacker wants the trained model to do: availability poisoning degrades the model on all inputs, while targeted and backdoor poisoning cause wrong results on a small set of chosen inputs^[8]. That classification describes the attacker's goal for the finished model, not what happened to the training data. The training data itself was improperly modified; what it lost is trustworthiness. That is why silently manipulated training data is an integrity problem first, and availability is the wrong property to name for it.

Among the mitigations NIST lists are protecting training data with access controls, data sanitization and validation, and mechanisms for dataset provenance and integrity attestation^[8]. Data sanitization here means cleaning the training set to remove poisoned samples before training. Provenance^[11] means a record of the data's origin and changes, and integrity attestation means verifiable evidence that the data has not been altered, which NIST AI 100-2 suggests providing with cryptographic techniques^[8]. At entry level the expected behavior is simpler: never treat data as trustworthy just because you can access it, and if you suspect training data has been manipulated, report it for investigation through the organization's process instead of quietly using or correcting it.

The takeaway: for AI, the integrity question is whether the data a model learned from is the data the organization intended it to learn from.

This section walks through AAA as three separate functions, using a simplified example of a subject accessing a system. A subject (called the entity or actor elsewhere on this page) is whatever asks for access: a person using an account, a running process, or a device.

The three parts answer three different questions, and none of them can stand in for another:

Part	Question	Typical output
Authentication	Is this subject who it claims to be?	A verified identity
Authorization	What is this verified subject permitted to do?	A permit or deny decision
Accounting	What did the subject actually do, and when?	A record of activity

Authentication: proving a claimed identity

Authentication is verifying the identity of a user, process, or device, often as a prerequisite to allowing access to resources^[12]. It starts with a claim and ends with evidence. Typing a username identifies who you claim to be; proving that you control an authenticator^[13] linked to that username (a secret or device, such as a password or key, that the account owner controls) supplies the evidence for the claim. That evidence takes the forms NIST SP 800-12^[14] lists as the common means of proving identity, including something the individual knows (a password or PIN), something the individual possesses (a smart card or token) and something the individual is (a fingerprint or face). These three forms are the authentication factors, and multi-factor authentication (MFA)^[15] is authentication using two or more different factors. Checking identity evidence is authentication and nothing more; deciding what that identity may do is the next decision.

Authorization: deciding what is permitted

Authorization is the decision to permit or deny a subject access to system objects^[16], based on the access privileges granted to that user, program or process. A payroll clerk can log in successfully and still be refused permission to edit a payroll record, because identity verification and permission to perform a particular operation are separate decisions. If an authenticated user genuinely needs editing rights, the fix is a change to that user's permissions through the authorization process. Resetting the user's password does nothing for the problem: it replaces the authenticator, and the permissions stay exactly as they were.

Accounting: recording what happened

Accounting records what a subject did and which resources it used. Its main product is an audit trail^[17], a chronological record that lets someone reconstruct the sequence of activities around an event. NIST SP 800-12^[14] describes an audit trail as a record of individuals who have accessed a system and what operations they performed during a given period, and lists time stamps among the audit controls, which is how a record shows when something happened. A report of completed file accesses is accounting output: it does not verify anyone's identity, it records the accesses and operations observed.

Because NIST describes authentication as often a prerequisite to allowing access to resources^[12], the request in the figure below is authenticated before it is authorized, and accounting records the activity in an audit trail.

The takeaway: authentication settles who, authorization settles what is allowed, and accounting records what was done. Passing one step never substitutes for another.

This section explains what turns accounting records into usable evidence: accountability. Despite the similar words, accountability is the goal and accounting is the record-keeping that serves it. NIST defines accountability as the security goal that generates the requirement for actions of an entity to be traced uniquely to that entity^[18], and notes that it supports non-repudiation, deterrence, fault isolation, intrusion detection and prevention, and after-action recovery and legal action.

Two important conditions support attributing a record to one entity:

• Distinguishable identities. NIST SP 800-12^[14] states that user accountability requires linking activities on a system to specific individuals, and that organizations ensure each user's actions can be uniquely traced to that user. A shared team login does not by itself provide individual attribution. If the log records only the shared account, not which team member was using it, that log alone cannot prove individual responsibility.
• Protected records. The same NIST section says organizations create, protect and retain audit records. A log that can be altered or deleted without detection is weak evidence, because the record itself may have lost its integrity.

Automated and AI actors

The CC outline ties AAA and non-repudiation to AI so that AI-generated actions and access remain traceable^[1]. An AI agent that opens tickets, edits records or sends messages is an actor like any other. The organization needs to establish the identity it acts under, limit what that identity is authorized to do, and keep an attributable record of what it did. Automation changes who or what performs an operation; it does not remove the need to account for it.

An AI result being accurate does not show that the action behind it was authorized: the quality of an output and the decision to permit an action are different questions.

The takeaway: records support accountability by helping trace actions uniquely to the responsible person or automated actor, and the records themselves need protection.

This section covers the last actor-side question: can someone credibly deny an action they took? Non-repudiation is protection against an individual who falsely denies having performed a certain action^[6], such as creating information, sending a message, approving information or receiving a message. The issue is evidence: something must connect the entity to the specific act in dispute. Confidentiality does not help with that; keeping an approval secret says nothing about who made it.

How a digital signature supplies the evidence

A digital signature has a signer and can be verified by a recipient; if a dispute arises, a third party may judge the evidence.

• Prerequisites: the signer holds a private key^[19], the secret half of a key pair that is not made public, and the matching public key is reliably associated with the signer. A public key certificate^[20], signed by a trusted certification authority, is the usual way that association is made: it binds the public key to its owner.
• Trigger: the signer applies the private key to the message, producing a signature that travels or is stored with the message.
• Consequence: anyone can check the signature with the signer's public key. If it verifies, NIST SP 800-12^[14] explains, the verifier has confidence that the data was not modified after being signed and that the owner of the public key was the signer.

NIST sums it up: a properly implemented digital signature^[21] provides origin authentication, data integrity and signatory non-repudiation. Origin authentication describes the message: data origin authentication^[22] is the corroboration that the source of data received is as claimed, unlike AAA authentication, which verifies an entity asking for access. A digital signature does not provide confidentiality. The signed message stays readable to anyone who receives it unless it is also encrypted separately. In the words of FIPS 186-5^[19], the private key is used to compute a digital signature that may be verified using the corresponding public key; the figure below shows both steps.

Why a hash, a MAC or encryption is not enough

Several mechanisms look similar to a signature but cannot settle a dispute about who approved something:

Mechanism	What it can show	Supports non-repudiation?
Plain (unkeyed) hash	A hash function[23] turns data into a fixed-length value, called a hash value or message digest[24]; comparing that value with a trusted reference shows whether the data changed	No. Anyone can compute a hash, so a matching value identifies no creator or approver
Message authentication code (MAC)	A cryptographic checksum computed with a shared secret key that detects accidental and intentional changes	No. NIST notes that MACs provide authenticity and integrity protection but not non-repudiation protection[25], because both parties hold the same key and either could have produced it
Encryption alone	Keeps content unreadable to anyone without the appropriate decryption key	No. It protects readability, not evidence of who approved the content
Digital signature	Origin authentication, data integrity and signatory non-repudiation	Yes, provided the private key is protected and bound to the right signer

Here MAC means message authentication code, not mandatory access control^[26], an access control policy that shares the abbreviation MAC.

A hash comparison also has a precondition of its own: the reference value must be trustworthy. If someone can replace both the data and the stored hash, a match does not establish that the original data is unchanged.

The private key is what the evidence rests on

A signature proves that the signing was done with a particular private key. NIST's FIPS 186-5 wording is that integrity and origin are verified as having originated from a specific entity in possession of the private key^[6]. If the key is compromised, which the NIST glossary describes as the unauthorized disclosure, modification, substitution, or use of sensitive data such as keys^[27], other people can produce signatures that verify perfectly and appear to come from the legitimate holder. Verification alone cannot tell you which person used a compromised key, so a valid signature is not conclusive personal attribution once the key may have been misused.

The takeaway: non-repudiation comes from a digital signature made with a private key that only its owner controls, plus a trustworthy link from the public key to that owner.

Privacy, the fourth information-side concept, builds on security without being settled by it: the NIST Privacy Framework states that while managing cybersecurity risk contributes to managing privacy risk, it is not sufficient, as privacy risks can also arise by means unrelated to cybersecurity incidents^[28]. Privacy concerns the gathering and use of data about an individual^[29], which is a different question from who may see that data. Start with an example from the NIST Privacy Framework^[28]: smart electricity meters can collect and share highly granular data about household electricity use, which can reveal how people behave inside their homes. The meters can be operating exactly as intended, with no breach and no attacker, and the processing can still leave people feeling surveilled. Nothing failed in security terms, yet there is a privacy problem.

Privacy, in one NIST glossary definition, is freedom from intrusion into the private life or affairs of an individual when that intrusion results from undue or illegal gathering and use of data about that individual^[29]. NIST SP 800-122 states the relationship directly: privacy is much broader than just protecting the confidentiality of PII^[30].

Where privacy and security overlap

The NIST Privacy Framework^[28] draws the relationship as two overlapping sets of risk, redrawn in the figure below. Cybersecurity risks arise from a loss of confidentiality, integrity or availability. Privacy risks arise from data processing itself, meaning any operation on the data such as collection, retention, use or sharing. The overlap, which NIST calls cybersecurity-related privacy events, covers cases such as data theft by external attackers or unauthorized use of data by employees. Encryption and access control work inside that overlap. They do not by themselves establish an appropriate processing purpose, so encrypting customer records does not by itself make a new use of those records appropriate.

What counts as personal information

Personal information (also called personal data, and in US federal guidance personally identifiable information, or PII) is information that can be used to distinguish or trace an individual's identity, either alone or when combined with other information that is linked or linkable to a specific individual^[31]. Some fields identify a person directly, such as a name or a national identification number. Others identify indirectly. NIST SP 800-122^[30] lists IP addresses and other persistent device identifiers that consistently link to a particular person as examples of personal information, and notes that ZIP code combined with date of birth can indirectly identify individuals or significantly narrow a large dataset.

Removing names alone therefore does not necessarily remove the privacy concern. De-identification^[32] means removing the association between identifying data and the person, and NIST SP 800-122 describes a de-identified record as one from which enough personal information has been removed that there is no reasonable basis to believe the rest can identify someone. A dataset with names deleted but location, device identifiers and birth dates intact may still fail that bar.

The takeaway: privacy asks whether information about people is handled appropriately, and information about people includes far more than names.

This section covers the principles that decide whether a particular handling of personal information is appropriate, the part of privacy that security controls cannot settle. NIST describes the fair information practice principles (FIPPs)^[33] as principles developed worldwide since the 1970s that guide organizations in handling personal data, and NIST SP 800-122^[30] calls them the principles underlying most privacy laws and privacy best practices.

A plan to train an AI model on an encrypted customer database that the team can already read for support work is still a handling of personal data, and the FIPPs provide guidance on exactly that handling^[33]. Access and encryption answer security questions; the five principles below guide the privacy review of whether the project may go ahead as planned. They are a selection, not the complete FIPPs: the Organisation for Economic Co-operation and Development (OECD) list quoted in NIST SP 800-122^[30] also includes data quality and security safeguards, among others, and NIST treats storage limitation as part of its minimization principle.

Data minimization: only what the purpose needs

NIST's minimization principle limits the creation, collection, use, processing, storage, maintenance, dissemination or disclosure of personal information to what is directly relevant and necessary to accomplish a legally authorized purpose^[34]. For the AI project, the question is whether each personal field is actually needed for the model, not whether it happens to be available. Keeping every available field in an encrypted training set protects the stored copy but does not justify collecting fields the purpose does not need. NIST SP 800-122^[30] adds a security benefit: the likelihood of harm from a breach is greatly reduced when an organization minimizes the personal information it uses, collects and stores.

Purpose limitation: no incompatible reuse

Purpose limitation (NIST's name is purpose specification and use limitation^[35]) means telling individuals the specific purpose for which their information is collected, and then restricting its use to purposes explained in the notice and compatible with the original purpose, or otherwise legally authorized. Records collected to provide customer support and then reused to train an AI model or to profile customers are being put to a new purpose, which needs a privacy review. Existing database access answers the authorization question from the AAA section (may this person read the records?), not the purpose question (may the organization use them this way?).

Storage limitation: no retention without a continuing purpose

Storage limitation means keeping identifiable personal information no longer than its purpose requires. It is the retention half of NIST's minimization principle, which says to maintain personal information only for as long as is necessary to accomplish the purpose^[34]. Retention is bounded from the other side as well: legal obligations can require keeping certain records, and NIST SP 800-122^[30] states that disposal must follow approved records retention schedules and any litigation holds. A secure, inexpensive archive still needs a justified retention period. Low storage cost is not a purpose.

Transparency: explaining the practices

Transparency^[36] means conveying an organization's policies and practices for personal information and giving clear and accessible notice about its collection, use, storage and disclosure. A privacy notice is the usual vehicle. A notice explains processing; it is neither a security mechanism nor blanket permission. Publishing a notice that describes a practice does not make the practice appropriate, because purpose limitation above still requires the use to be compatible with the original purpose or otherwise legally authorized.

Access and amendment: individual rights to see and correct data

NIST's access and amendment^[37] principle requires giving individuals appropriate access to their personal information and an appropriate opportunity to correct or amend it. The OECD version quoted in NIST SP 800-122^[30] goes further: individuals may challenge data about them and, if the challenge is successful, have it erased, rectified, completed or amended. Rights such as deletion, objection or restricted processing therefore depend on the applicable rules and the circumstances. A practitioner who receives such a request routes it to the organization's privacy process, which works out which right applies and whether a retention obligation limits it. Deleting records immediately in response to every request skips exactly that check.

The five principles side by side

Each of the five principles reduces to one check on how personal information is handled:

Principle	What it checks	Practice that fails the check
Data minimization	Is each personal field needed for the purpose?	Encrypting every available field instead of dropping unneeded ones
Purpose limitation	Is this use compatible with why the data was collected?	Treating existing access rights as approval for a new use
Storage limitation	Is there still a purpose for keeping it?	Keeping records forever because storage is cheap
Transparency	Do people know how their information is handled?	Treating a published notice as permission for any processing
Access and amendment	Can people see and correct their information?	Deleting immediately on every request without checking the right

The takeaway: these principles test the purpose and handling of personal information, which is why they apply even when every security control is working.

Many scenarios seem to fit two concepts; the one that applies is the one whose definition the event meets, so a misdirected file is unauthorized disclosure of information^[2], a loss of confidentiality, not of integrity.

Information-side scenarios: confidentiality, integrity, availability and privacy

Scenario	Correct conclusion	Wrong conclusion	Why it is wrong	Topic
A sensitive file goes to the wrong recipient, unchanged	Confidentiality	Integrity	Nothing was altered; the problem is disclosure	Confidentiality, integrity and availability
A payment amount is altered, by mistake or on purpose	Integrity	Confidentiality	The problem is accuracy of the record, not who saw it	Confidentiality, integrity and availability
Records are accurate and secret, but the service cannot answer requests	Availability	Confidentiality	Blocking legitimate use is not protection against disclosure	Confidentiality, integrity and availability
Setting priorities for a public information website	Integrity and availability first	Confidentiality first	Disclosing already-public content causes no harm	Setting priorities among the three properties
AI training data is silently manipulated	Integrity	Availability	The data stayed accessible; its trustworthiness is what was lost	Integrity of AI training data and poisoning
Encrypted customer records are reused for a new purpose	Privacy (purpose limitation)	Confidentiality is enough	Encryption does not establish an appropriate purpose	Fair information practice principles
A dataset has names removed	May still be personal information	Non-personal data	Other fields or combinations can still identify people	Privacy and personal information

Actor-side scenarios: authentication, authorization, accounting and non-repudiation

Scenario	Correct conclusion	Wrong conclusion	Why it is wrong	Topic
A system checks a password or other authenticator	Authentication	Authorization	Authorization decides permitted access, not identity	AAA
A logged-in user cannot edit a record they need	Authorization (change permissions)	Reset the password	A new authenticator leaves the permissions unchanged	AAA
A report lists completed file accesses	Accounting	Authentication	The report records operations; it verifies no identity	AAA
A shared team login with detailed logging	Accountability is not achieved	The logs prove who did it	The log records the shared account, not the person	Accountability for people and automated actors
An AI agent changes records	AAA applies to the agent	An accurate result proves it was authorized	Output quality is not an access decision	Accountability for people and automated actors
An approver denies approving a payment	Non-repudiation	Confidentiality	Secrecy proves nothing about who approved	Non-repudiation and digital signatures
Proof is needed of who approved a document	Digital signature	Encryption alone, or a plain hash	Neither identifies a signer	Non-repudiation and digital signatures
A signature verifies, but the signing key may have been compromised	Attribution is not conclusive	A valid signature proves the person signed	Anyone holding the key can produce a valid signature	Non-repudiation and digital signatures

The takeaway: a control that serves one concept does not automatically serve another, as NIST notes for two pairs. For personally identifiable information (PII), privacy is much broader than just protecting the confidentiality of PII^[30]; for message authentication codes (MACs), MACs provide authenticity and integrity protection but not non-repudiation protection^[25].