Cybersecurity terminology is useful only when it helps people make clearer decisions about systems, data and risk. The “2024” in this article’s historical title reflects its original topic period; the concepts below remain useful in 2026, while tools and certifications continue to evolve. A person who can distinguish a vulnerability from a threat, an authentication success from an authorization decision, or an available backup from a usable restore is better equipped to explain what a security control actually does.

This glossary groups related terms so that each concept has context, not just a definition. The aim is an accurate operational vocabulary for IT support, security operations, cloud administration and certification study. It does not replace an organization’s policies or the issuer’s current exam objectives. A learner should test important distinctions against authorized scenarios rather than memorizing isolated acronyms.

Security outcomes: confidentiality, integrity and availability

Confidentiality means information is disclosed only to authorized parties. Integrity means data or systems remain accurate and protected from unauthorized modification. Availability means required services and information are accessible when needed. These CIA properties can conflict: a restrictive security rule may protect confidentiality while unexpectedly preventing authorized users from doing their jobs.

Consider an HR document. Encrypting its storage can help confidentiality, but it does not prove the correct manager can retrieve it, that it has not been modified improperly, or that the service survives an outage. An operational design needs different controls and evidence for each outcome. The CISSP security disciplines provide a broader framework for considering risk, architecture, operations and governance together.

Risk describes the possibility and consequence of an unwanted outcome under relevant uncertainty. It is not the same as a vulnerability count or a scanner score. A business may accept a bounded residual risk after weighing its likelihood, impact, controls and cost. The risk owner should be identifiable, and the acceptance decision should be recorded rather than presumed from a technical team closing a ticket.

Threats, vulnerabilities, exposure and exploits

A threat is a potential source or event capable of causing harm. A vulnerability is a weakness that could be exploited under particular conditions. Exposure concerns whether an asset or pathway can be reached by a relevant threat, while an exploit is a method that takes advantage of a weakness. A service can be vulnerable without being directly exposed to the public internet, and an exposed service can have risks beyond known software vulnerabilities.

CVE identifiers help name publicly disclosed vulnerabilities; CVSS is a scoring framework that characterizes severity. Neither automatically sets the order in which an organization must remediate. Asset criticality, actual exposure, exploit activity, compensating controls and business impact all matter. A medium-scored issue on a publicly reachable payment service may deserve urgent attention relative to a higher-scored but isolated test system.

Attack surface includes exposed entry points and trust relationships that could be misused. It may involve internet endpoints, employee accounts, APIs, dependencies, remote management and service identities. The cloud threat landscape becomes easier to analyze when the actual asset path, authorization boundary and observable failure condition are known instead of treating every threat category as equally likely.

Identity: authentication, authorization and least privilege

Authentication establishes or checks an identity; authorization determines which operations that identity may perform. A successfully signed-in employee may still be denied access to a finance dataset. Confusing the two can lead administrators to reset passwords for what is actually a resource-policy problem, or grant excessive permissions to conceal an authorization error.

Multifactor authentication (MFA) requires evidence from more than one authentication-factor category, such as something known and something possessed. Two passwords are not two independent factors. MFA can reduce some account-takeover risks, but it does not automatically protect against overly broad authorization, stolen active sessions or unsafe application consent. The control must be deployed in the right identity and application context.

Least privilege means assigning only the access needed for an authorized task, for an appropriate duration. It is verified through both allowed and denied operations. Privileged access management adds controls for elevated identities, approval, monitoring, time limits or session recording where appropriate. The identity and access controls subject provides a useful deeper example of how authentication, authorization and role lifecycle interact.

Zero Trust is an approach in which access decisions do not rely solely on being inside a familiar network perimeter. Identity, device context, data sensitivity and ongoing policy evaluation can all matter. It is not one product or a promise that a network can be made trust-free. Security architecture must still define what identities can reach, how requests are evaluated and what evidence is available.

Cryptographic protection and data handling

Encryption transforms data under a key so that properly authorized parties can recover it. Hashing produces a digest for comparison or other security uses and generally is not intended to be reversed to recover the original message. Password storage needs a purpose-built slow password-hashing or key-derivation approach with appropriate salts, not ordinary encryption of every password or a fast unsalted digest.

Data at rest, data in transit and data in use are different states with different risks. TLS can protect appropriate network connections; disk encryption protects particular storage scenarios; application permissions determine what an authorized process may read. One state being protected does not automatically establish confidentiality in the others. Key lifecycle—creation, storage, rotation, revocation and recovery—can be as important as algorithm choice.

Data classification assigns handling requirements based on sensitivity or business need. Data loss prevention (DLP) can detect or restrict specified transfers under supported configurations; it cannot guarantee that every information leak is prevented. A secure design identifies owners, allowed purposes, retention and audit needs rather than assuming that adding a label to a file resolves governance.

Detection: logs, SIEM, EDR and incident response

A log records an event or observation from a system. A SIEM can collect, correlate and analyze security-related records to support detection and investigation. A detection alert is a hypothesis or signal, not necessarily proof of a breach. Analysts must check timestamps, source reliability, expected business activity and alternative explanations before deciding how to respond.

Endpoint detection and response (EDR) focuses on endpoint telemetry and response capabilities. XDR generally combines signals or actions across multiple security domains, although vendors implement it differently. Neither replaces sound identity configuration, patch management or recovery. A Microsoft 365 Defender security case can illustrate the relationship between endpoint alerts, identity activity and application evidence without treating every vendor’s detection semantics as identical.

Incident response is the controlled process of preparation, detection and analysis, containment, eradication, recovery and learning, adapted to the organization’s framework. A suspicious sign-in may justify investigation and a bounded containment step, but not every failed password attempt proves an account takeover. Preserve evidence, identify who can authorize disruptive action and verify that restored service is both usable and safe.

Resilience: backups, RTO and RPO

A backup is a stored copy intended to support recovery under defined conditions. It is not proof that a complete application can be restored. The recovery time objective (RTO) describes the acceptable time to restore service, while the recovery point objective (RPO) describes the acceptable loss of recent data. A successful backup job may still be inconsistent with an organization’s recovery expectations.

Test recovery with synthetic data, a service identity and a known application request. Measure how long restoration takes and which transactions are absent. Replication and high availability can address some component failures but may reproduce deletion or corruption, so they do not replace an appropriately designed restore strategy. The business continuity and disaster recovery process ties the technical plan to real business tolerances.

Cloud and development security

Shared responsibility divides security duties between a cloud provider and its customer under a particular service model. The provider may operate physical infrastructure, while the customer remains responsible for data access, workload configuration and application logic. The boundary differs among infrastructure, platform and software services. An AWS shared-responsibility example helps make that distinction concrete.

Infrastructure as code (IaC) represents infrastructure configuration in reviewed, version-controlled definitions. It can improve repeatability but can also deploy a bad policy repeatedly if testing and approvals are missing. DevSecOps integrates appropriate security activities into software delivery rather than relying on one final penetration test. The goal is to identify risks early and verify that controls remain effective after a deployment.

Supply-chain risk arises from dependencies on software packages, build pipelines, service providers and other external components. A software bill of materials (SBOM) can help inventory included components, but the presence of a list is not proof those components are safe. Version monitoring, provenance, approval and vulnerability response remain important.

For study, build one harmless scenario and explain it using the correct vocabulary: an application is reachable, its user signs in, the database denies an unauthorized query, logs record the attempt, and a restore test confirms recovery from a simulated deletion. Map the event to confidentiality, authorization, monitoring, risk and resilience. That exercise teaches the relationships among terms rather than turning a glossary into a memorization contest.

The CompTIA cybersecurity learning progression can help learners decide how much additional technical depth they need; advanced architecture and operations credentials assume broader responsibility than introductory terminology. The enduring standard is clear communication: say exactly what a control protects, what it does not, and what evidence would show whether it works.