Why Cryptography Exists: Confidentiality, Integrity, and Regulatory Necessity

Before an SSCP candidate can evaluate a single algorithm or protocol, they need a clear answer to a more basic question: why does an organization encrypt anything at all? Cryptography is not deployed for its own sake -- it exists to satisfy specific, provable security requirements, and understanding those requirements is what lets a practitioner choose the right control instead of just the fashionable one.

The Core Drivers: Confidentiality and Integrity

Cryptography primarily serves two legs of the CIA triad. Confidentiality is the most obvious: encryption renders data unreadable to anyone who lacks the correct key, protecting it whether it sits on a disk, moves across a network, or lives in a backup tape sitting in a warehouse. Integrity is served differently -- through hashing and message authentication codes (MACs) -- by letting a recipient prove that data was not altered in transit or at rest, even if the data itself is not secret. A practitioner has to keep these two purposes distinct: encrypting data does not, by itself, prove it wasn't tampered with, and hashing data does not keep it secret. Many real-world designs combine both (encrypt-then-MAC) precisely because neither property implies the other.

Protecting Regulated and Sensitive Data

A huge share of real-world cryptography deployment is driven by the sensitivity classification of the data itself, most commonly personally identifiable information (PII) and protected health information (PHI). Once data is classified as PII or PHI, most regulatory and contractual frameworks a security professional will encounter expect encryption at rest and in transit as a baseline control, along with strict key management and breach-notification obligations if that encryption ever fails or is bypassed. This is why data classification work always precedes cryptographic control selection: you cannot decide how strongly to protect data until you know what the data actually is and who is accountable for it under law or contract.

Weighing Requirements Against Cost and Performance

Cryptography is never free. Strong encryption and hashing consume CPU cycles, add latency, and complicate operations like search, indexing, and troubleshooting. A mature security program treats the decision to encrypt as a risk-based one: the sensitivity of the data and the regulatory or contractual requirement attached to it are weighed against the operational cost of protecting it. This is why practitioners see selective encryption in real systems -- full-disk encryption everywhere, but field-level encryption reserved for the most sensitive columns in a database, for example.

Key Mechanics

• Cryptography's two primary security goals are confidentiality (encryption) and integrity (hashing/MACs) -- they are not interchangeable.
• Non-repudiation (covered further under 5.2) requires asymmetric cryptography and cannot be achieved with encryption or hashing alone.
• PII and PHI classification typically triggers a baseline expectation of encryption at rest and in transit under most regulatory/contractual frameworks.
• Cryptographic controls carry real performance and operational costs, so deployment should follow a data-classification and risk decision, not be applied uniformly by default.
• Encrypting data protects secrecy; it says nothing about whether the data was altered, which is why integrity controls are evaluated separately.

Exam Tip: The exam will test whether you know that encryption alone does not guarantee integrity. If a scenario describes data that must be both secret AND provably unaltered, look for an answer combining encryption with hashing or a MAC, not encryption alone.

Exam Tip: Watch for scenarios describing PII or PHI with no encryption in place. The exam expects you to recognize that data classification -- not just "we have a firewall" -- is what triggers a cryptographic control requirement.

Exam Tip: Distractors often present "we always encrypt everything" as a security best practice. The better answer usually reflects the actual risk-based/cost-based approach: apply the strongest controls where sensitivity and regulatory requirement demand it, not indiscriminately everywhere.

Diagram

Worked example: A healthcare SaaS company stores patient appointment notes (PHI) in a cloud database and also stores a public list of clinic operating hours. The security team encrypts the appointment-notes column with field-level encryption and applies a keyed hash to detect tampering, satisfying both confidentiality and integrity obligations tied to the PHI classification. The clinic-hours table, which is not sensitive and carries no regulatory requirement, is left unencrypted to avoid unnecessary performance overhead -- an example of requirements-driven, not blanket, cryptographic deployment.