Data Security: Classification, Masking, Sanitization, and Encryption Basics

Data classification is the process of sorting data into categories by its sensitivity and value, so the organization knows how strongly each piece must be protected. The core logic is simple: not all data deserves the same defenses. Encrypting the cafeteria menu wastes money; leaving customer financial records unencrypted invites disaster. Classification tells you which is which, and the assigned class then dictates the handling rules - who may access the data, whether it must be encrypted, where it may be stored, how it must travel, and how it must eventually be destroyed.

Commercial organizations typically use a scheme like public, internal, confidential, restricted (names vary - you may see "sensitive" or "highly confidential"). Public data can be released to anyone without harm. Internal data is for employees but would cause only minor harm if exposed. Confidential data - customer records, contracts, financials - would cause real damage. Restricted data - trade secrets, regulated personal data - would cause severe damage and gets the tightest controls. Government schemes use levels such as unclassified, confidential, secret, and top secret, tied to the degree of national-security damage disclosure would cause.

Labeling is how a classification becomes visible and enforceable: marking the asset itself with its class, whether as a header or footer on a document, a metadata tag on a file or email, or a physical sticker on a drive. Classification is the decision (which class this data belongs to); labeling is the marking that carries that decision with the data wherever it goes. The distinction matters because people and automated tools can only act on what they can see. Data loss prevention (DLP) tools and email gateways read metadata labels and can block, encrypt or quarantine a file tagged confidential before it leaves the organization; a class recorded only in a spreadsheet or asset register is invisible to those tools when the file is attached to an email. An unlabeled confidential file is a control failure waiting to happen, because the people and systems handling it have no way to know the rules that apply.

For the exam, remember the direction of causation: classification comes first, protection follows. A question describing an organization deciding "which data needs the strongest controls" is describing classification, and the answer to "what determines the level of protection data receives?" is its classification.

Classification and public generative AI

Putting classified data into a public generative AI service is data leakage: the data leaves the organization's control and reaches a third party, which is a loss of confidentiality. Public AI providers may store prompts and uploaded files, have staff review them, or use them to train future models, depending on their terms. Once confidential data is submitted, the organization can no longer enforce its handling rules on it.

Classification is what makes this risk manageable. AI-use rules are written per classification level, for example: public data may be used in any AI tool, internal data only in approved enterprise tools, and confidential or restricted data in none. Those rules cannot be applied until the scheme exists and data carries its labels, so classifying and labeling come first. Labels then allow enforcement without banning the service outright: DLP can block labeled files from being uploaded to public AI sites and use content inspection (sensitive-information patterns) to catch sensitive text being pasted into them, while still letting staff use the tool for public or unlabeled low-risk content.

Data must be protected in each of the three states it can occupy, and the CC exam expects you to recognize all three from a description.

Data at rest is data being stored: on a disk, in a database, on a backup tape, on a USB drive in a drawer. Its main threats are theft of the media and unauthorized access to the storage system. The classic protection is encryption of the stored data (disk or database encryption), plus access controls on the systems that hold it.

Data in transit (also called data in motion) is data moving across a network: a web request, an email, a file transfer between sites. Its main threat is interception - an eavesdropper capturing traffic as it passes. The classic protection is encrypting the connection, for example with TLS, so intercepted traffic is unreadable.

Data in use is data being actively processed in memory by an application. It is the hardest state to protect, because a CPU generally must work on data in readable form. Protections lean on securing the endpoint itself: access controls, hardened systems, and limiting who can run what on the machine processing the data.

Recognition is all the exam asks. "An attacker stole a laptop; the files were unreadable" is encryption protecting data at rest. "Traffic between the browser and the server is encrypted" is data in transit. "Sensitive values are exposed only in application memory while being processed" is data in use. A complete data security program addresses all three states, because attackers will simply target whichever state is left unprotected.

Data masking obscures sensitive data by replacing some or all of it with substitute characters, so a person or system can work with the record without seeing the sensitive values. The everyday example is a payment receipt showing your card number as ****-****-****-4321: enough to confirm which card was used, useless to a thief who finds the receipt. Masking is likewise used to show only the last digits of a national identification number, to hide portions of a birth date, or to blank out salary fields for staff who do not need them.

Masking has two broad uses, and they work differently:

• Dynamic (display) masking. The production data stays intact; the system masks fields at display time for users whose role does not require the full value. A call-center agent can verify the last four digits of a card without ever seeing the whole number, which shrinks both insider risk and the impact of a shoulder-surfer.
• Static masking for test and development. A copy of production data has its sensitive fields permanently replaced with substitute values before it is handed to developers or testers. The substitutes keep the realistic format - a card number still looks like a 16-digit card number, a name still looks like a name - so applications and tests behave normally, but no real customer record ever reaches the non-production environment. The point is that the copy contains no real data at all - controls that merely restrict or encrypt real data leave it in the hands of everyone who works on the copy, and transforms that destroy the format (such as hashing) break the applications being tested.

Keep masking distinct from its neighbors, because the exam will line them up as answer choices. Masking is not encryption: encryption transforms data reversibly with a key, and an authorized holder of the key recovers the original. Masking simply withholds or replaces characters in what is shown; there is no key and, for the viewer, no way back to the original. And masking is not sanitization: the real data still exists in the production system, protected and intact - display masking only controls what is revealed, and static masking changes only the copy.

When a question says "show only the last four digits," the answer is masking.

Sanitization (sometimes called media sanitization or secure data destruction) is the process of removing data from storage media so thoroughly that it cannot be recovered, even with forensic tools. It is the mandatory final step of the data life cycle: before a disk is reused, resold, donated, or discarded, the data on it must be truly gone - a discarded drive full of "deleted" customer records is a breach in waiting.

The critical exam fact: deleting is not sanitizing. When you delete a file - even when you empty the recycle bin or quick-format a drive - the operating system typically removes only the pointer to the data and marks the space as free. The bits remain on the media until they happen to be overwritten, and widely available recovery tools can bring them back. The same is true of formatting in its quick form. Any answer choice that treats deletion or a quick format as secure destruction is wrong.

The recognized sanitization methods are:

• Overwriting (wiping). Software writes patterns of new data over every addressable location on the media, one or more passes, so the original bits are gone. The media remains usable afterward. Overwriting works reliably on magnetic hard disks; on SSDs and other flash media it is unreliable, because the drive's controller remaps writes for wear levelling and keeps spare blocks the operating system cannot address, so an overwrite of every visible sector can miss copies of the old data.
• Degaussing. A powerful magnetic field scrambles the magnetic domains on magnetic media such as hard disk drives and tapes, destroying the data - and usually the drive itself. Degaussing does nothing to non-magnetic media like SSDs and optical discs.
• Cryptographic erase. On a self-encrypting drive, every block is already encrypted with a key held inside the drive. Destroying (and replacing) that internal key leaves every block - including remapped and spare ones - unreadable ciphertext, in seconds, and the drive can be reused. NIST's media sanitization guidance (SP 800-88) recognizes it as a purge technique. It is only as good as the encryption: it relies on all data having been encrypted under that key.
• Physical destruction. Shredding, pulverizing, incinerating, or otherwise destroying the media itself. This is the most certain method and the required end for media that held the most sensitive data.

Match the method to the media, the sensitivity and whether the media will be reused:

Overwrite magnetic drives that will be reused, crypto-erase self-encrypting SSDs that will be reused, degauss magnetic media being retired, and physically destroy anything where residual risk is unacceptable.

Encryption transforms readable plaintext into unreadable ciphertext using an algorithm and a key, so that only someone holding the correct key can reverse the process and recover the plaintext. It is the primary technical control for confidentiality, and the CC exam splits it into two families by how keys work.

Symmetric encryption uses a single shared secret key: the same key encrypts and decrypts. If you encrypt a file with a symmetric key, anyone who is to decrypt it must have that identical key. The dominant modern example is AES (Advanced Encryption Standard), the algorithm behind most disk encryption, wireless security, and bulk data protection. Symmetric algorithms are computationally fast and efficient, which makes them the workhorse for encrypting large volumes of data - whole disks, databases, and the flow of traffic in an established secure session.

The weakness is key distribution. Before two parties can communicate, they must both possess the same secret key, and getting that key from one to the other securely is exactly the problem encryption was supposed to solve - you cannot email the key in the clear alongside the data it protects. The problem compounds with scale: every pair of communicating parties needs its own shared secret, so a large population needs an unmanageable number of keys.

Anchor the recognition cues: one key, shared secret, fast, bulk data, AES - all point to symmetric. And note what encryption does not give you by itself: it protects confidentiality, but it does not prove that data is unaltered or who sent it. Those jobs belong to hashing and to asymmetric techniques, coming next.

Asymmetric encryption (public key cryptography) uses a mathematically related pair of keys: a public key, which can be shared with anyone, and a private key, which is never shared. What one key of the pair encrypts, only the other can decrypt. The classic example algorithm is RSA.

The elegance is what it does to key distribution. To receive confidential messages, you publish your public key openly. Anyone can use it to encrypt a message to you, but only your private key can decrypt it - so no secret ever has to travel. The distribution problem that cripples symmetric cryptography at scale simply disappears: each party needs one key pair, not a shared secret with every correspondent.

The private key also enables digital signatures. The sender hashes the message and signs that hash with the sender's own private key; the recipient recomputes the hash and verifies the signature with the sender's public key. Because only the sender holds the private key, a valid signature proves the message came from them and was not altered. Compare a shared-key integrity check (a keyed hash both parties compute with the same secret): it detects tampering, but either key holder could have produced it, so it cannot prove which of them did.

That difference is non-repudiation: the signer cannot credibly deny having signed. Keep three neighbouring ideas apart:

A permission only says who was allowed to act; a signature proves who actually did.

The trade-off is performance: asymmetric operations are far slower and more computationally expensive than symmetric ones, making them impractical for encrypting large volumes of data. RSA in particular can only encrypt a value smaller than its key size, so it is suited to small values such as keys, not to files. Real systems therefore combine the two - a hybrid approach. The bulk data is encrypted with a fresh symmetric key (for example AES), and that symmetric key is protected with the recipient's public key, so only the recipient's private key can unwrap it. The direction matters: confidentiality always comes from encrypting with the recipient's public key, because whatever a private key encrypts, anyone holding the matching public key can decrypt. Secure web connections follow the same idea: asymmetric cryptography authenticates the server and establishes a shared session key, and that symmetric key then encrypts the traffic at high speed. For the exam: two keys, public and private, RSA, solves key exchange, enables signatures, slower - all point to asymmetric.

Hashing is a one-way function that takes input of any size and produces a fixed-length output called a hash (or digest). It is not encryption, because it cannot be reversed - there is no key and no way to recover the original data from the hash. A common example algorithm is SHA-256, which always produces a 256-bit digest whether you hash one sentence or an entire disk image.

What hashing provides is integrity. The same input always produces the same hash, and changing even a single bit of the input produces a completely different hash. So to verify that a file has not been altered, compare its current hash with the hash recorded earlier: a match means the data is unchanged; a mismatch means it was modified or corrupted. This is how download verification, file integrity monitoring, and digital signature schemes detect tampering. Hashing is also how systems store passwords - keeping the hash instead of the password, then hashing each login attempt and comparing - precisely because the stored value cannot be reversed into the password.

Hashing provides no confidentiality: it does not hide data, because the data itself is not transformed into something recoverable - the hash is a fingerprint, not a container. A useful hash function must also be collision resistant, meaning it should be infeasible to find two different inputs that produce the same hash.

This three-way distinction is the single most reliable trap in CC cryptography questions. "One shared key" is symmetric, "key pair" is asymmetric, "one-way, no key, verifies integrity" is hashing - and hashing is never the answer to a question about keeping data secret.

The refreshed CC outline adds one forward-looking term: quantum-resistant cryptography, also called post-quantum cryptography (PQC). A sufficiently powerful quantum computer could break the mathematical problems that today's asymmetric algorithms such as RSA depend on, which would undermine the key exchange and digital signatures that secure most modern communication. Quantum-resistant algorithms are new cryptographic algorithms designed to run on ordinary computers but resist attack by quantum computers. Standards bodies have been selecting and publishing such algorithms, and organizations are beginning long migrations toward them. NIST published its first post-quantum standards in 2024 (FIPS 203 for key establishment and FIPS 204 and 205 for digital signatures).

Not all cryptography is equally exposed. Public-key algorithms such as RSA and elliptic-curve cryptography would be broken outright by a large quantum computer. Symmetric ciphers and hashes are only modestly weakened - a quantum search attack roughly halves their effective strength - so AES-256 and SHA-256 remain strong. In a typical system, then, the component to replace is the key exchange and signatures, not the bulk cipher.

The threat that makes this urgent today is "harvest now, decrypt later": adversaries record encrypted traffic now, intending to decrypt it once quantum capability arrives. That turns migration into a prioritization question driven by secrecy lifetime - how long the data must stay confidential. Data that must remain secret for decades (health records, state secrets, long-lived intellectual property) is already at risk if its key exchange is recorded today, so those flows migrate first; data that is worthless in a week can wait.

Now apply the whole lesson to one scenario. A hospital is retiring a file server that held patient records. The records were classified restricted, stored encrypted with AES, and transmitted to clinics over TLS. Support staff viewing appointment lists saw patient IDs masked to the last three digits. Before disposal, an administrator deletes all files and quick-formats the drives, then sends the server to a recycler.

Almost everything here was right: classification drove strong handling, AES protected data at rest, TLS protected data in transit, masking limited what support staff could see. The failure is the last step - deletion and quick formatting are not sanitization, so recoverable patient data just left the building. For restricted data on magnetic drives, the drives should have been overwritten and then degaussed or physically destroyed, with the destruction documented.

Exam questions build exactly these composites: each control names its concept, and the wrong step is the one where a look-alike term was treated as the real thing - deletion as destruction, masking as encryption, hashing as secrecy.