Understand Data Security

A deleted file can still be retrieved: the US Cybersecurity and Infrastructure Security Agency (CISA) warns^[1] that data remains on the media even after a delete or format command is executed. Making that data unrecoverable is media sanitization^[2], one of the data handling examples the ISC2 exam outline^[3] lists under "Understand data security", the first objective of the Security Operations and Incident Response domain. The outline gives that objective two parts: data handling (for example classification, labeling, masking and sanitization) and encryption (for example symmetric, asymmetric, hashing and quantum-resistant cryptography, which the US National Institute of Standards and Technology (NIST) calls post-quantum cryptography). Hashing sits in that list, but it is a one-way cryptographic tool, not encryption.

The outline places neighboring topics under other objectives: asset lifecycle management under understand asset protection, the data handling policy that implements an incident response plan under understand incident response, and confidentiality, integrity and non-repudiation under understand cybersecurity concepts.

Data handling and cryptography

Data handling and cryptography, the two families in the figure below, answer two different questions.

• Data handling asks what protection does this information need, and what happens to it during its life? Classification answers the first half. A security label^[4] represents the security level of an object. Masking^[5] conceals a segment of a payment card number when it is displayed or printed, and truncation removes a segment of the stored number. Retention keeps information in accordance with applicable laws, regulations, policies and operational requirements^[6]. After the retention period, information is disposed of, destroyed or erased^[6]. Media sanitization^[2] renders access to data on the media infeasible for a given level of effort; clear, purge and destroy are the actions that sanitize media.
• Cryptography asks which cryptographic tool delivers the protection? NIST states that all sensitive information requires integrity protection^[7], and that confidentiality protection may be required as well. Symmetric encryption^[8] uses one shared secret key, asymmetric cryptography^[9] uses a public and private key pair, hashing^[10] produces a one-way digest, and post-quantum cryptography replaces quantum-vulnerable algorithms^[11].

In short, classification decides how much protection the data needs; the other data handling activities and the cryptographic tools are the ways that protection is delivered.

Classification informs the handling requirements applied to data. NIST IR 8496^[12] describes data classification as the process an organization uses to characterize its data assets with persistent labels so that cybersecurity and privacy protection requirements can be applied to them at scale. In practice, the organization's classification policy defines categories linked to handling requirements: who may receive the data, where it may be stored, whether it must be encrypted and how it is disposed of. Category names vary by organization; "public, internal, confidential" is a common illustration, not a standard set.

The categories are chosen by protection need, meaning the harm that unauthorized disclosure, alteration or loss would cause. That is why customer records and a public press release end up with different sharing, storage and disposal rules even when they sit on the same file server. Attributes that say nothing about that harm, such as the purchase price of the device holding the data, play no part in the decision.

Labels carry the classification

A security label^[4] is a piece of information that represents the security level of an object. It comes in two broad forms:

• A human-readable form, which NIST Special Publication 800-53 Revision 5 (SP 800-53r5) calls a security marking^[13], such as a "Confidential" banner on a document or a sticker on a backup tape, so that people apply the right process-based handling.
• A machine-readable form, an identifier attached to the data (for example, as metadata), so that systems can recognize the level and apply rules automatically.

A label communicates; it does not protect. Access controls, encryption and other safeguards do the protecting, and the label tells people and systems which safeguards the data needs. For the same reason, an "encrypted" indicator is not a classification label: it describes one safeguard that happens to be applied, not the security level the data requires.

The Traffic Light Protocol (TLP) markings, such as TLP:AMBER, also mark information, but they set sharing boundaries for potentially sensitive information and are not a formal classification scheme. For related study, see Understand Security Operations.

The takeaway: classify by protection need, label so the level is visible to people and systems, and rely on separate safeguards to enforce it.

Masking and truncation both reduce how much of a sensitive value is exposed, but they act in different places: masking changes what is shown, and truncation changes what is stored. The payment card industry's standards body draws that line in its FAQ on masking and truncation^[5]: masking conceals a segment of a card number when it is displayed or printed, while truncation removes a segment of the stored number.

Display masking

Picture a support agent who needs to confirm which card a customer is calling about. In this example, assume the last four digits are enough, so the screen shows something like **** **** **** 1234 while the full number stays in the payment system. NIST's de-identification report^[14] describes masking in the same spirit, as removing a field or replacing it with a value such as asterisks. NIST's control catalog describes the same technique: under control SI-19 of SP 800-53r5^[6], masking transforms a value that directly identifies a person into a repeating character such as XXXXXX or 999999.

Two consequences follow from the full value still existing. First, the PCI FAQ notes that a number masked on screen may still be stored in full, and that stored copy needs its own protection. Second, masking is not something storage encryption can do for you: an authorized application decrypts the data before it displays it, so encrypting the database has no say over how many digits appear on screen.

Truncation

Truncation deletes part of the stored value itself, keeping only the segment the business still needs. According to the PCI FAQ^[5], the truncated digits are removed and cannot be retrieved within the system; there is no "un-truncation", only recreating the full number from another source. Choose truncation when the organization no longer needs the complete value.

Encryption is not a substitute here either. Encrypting the full number protects it, but it keeps a recoverable form of the complete value, which is exactly what a requirement to stop retaining the full value rules out.

Technique	Where it acts	Is the full value still recoverable in the system?
Display masking	What is shown or printed	Possibly: any stored full value still needs protection there
Truncation	What is stored	No: the removed digits are gone from that stored value
Encryption	What is stored or transmitted	Yes: anyone holding the appropriate decryption key can decrypt it

The takeaway: mask when people do not need to see the whole value, and truncate when the organization does not need to keep it.

Data may reach the point where it no longer needs to be kept, and data handling includes deciding in advance when that point comes and what happens then. SP 800-53r5 control SI-12, Information Management and Retention^[6], requires managing and retaining information in accordance with applicable laws, executive orders, directives, regulations, policies, standards, guidelines and operational requirements. Its discussion adds that retention requirements cover the full life cycle of information, in some cases extending beyond the disposal of the system that held it.

Retention is a requirement, not a storage question

Retention periods come from business, legal and regulatory requirements, plus preservation obligations such as keeping records that an investigation needs. Free disk space is not a retention policy: having room to keep something says nothing about whether the organization needs it or is allowed to keep it. For personal information, NIST advises organizations to minimize the use, collection and retention^[15] of personally identifiable information (PII) to what is strictly necessary, because the likelihood of harm from a breach drops when less PII is held.

Disposal follows the retention period

When the retention period ends, SI-12's information disposal enhancement calls for disposing of, destroying or erasing the information, and states that disposal applies to originals as well as copies and archived records. Until then, every retained copy, backups included, still needs protection appropriate to its classification for as long as it exists.

The takeaway: keep data for as long as a requirement says, protect every retained copy, and dispose of it deliberately when the requirement ends.

Sanitization is what makes data on retired or reused storage unrecoverable, and the first thing to know is that ordinary deletion does not do it. CISA warns^[1] that when you delete files or format a device, the data remains on the media and can be retrieved, even after the trash is emptied. A "file deleted" confirmation shows that the file's entry was removed, not that the contents are gone.

NIST Special Publication 800-88 Revision 2 (SP 800-88r2), Guidelines for Media Sanitization^[16], defines sanitization as a process that renders access to target data on the media infeasible for a given level of effort. Target data simply means the information you need to make unrecoverable. "A given level of effort" is the important phrase: one party might try simple reads through the device's normal interface, while a well-funded one might apply state-of-the-art laboratory techniques. NIST's three sanitization methods^[2], clear, purge and destroy, differ in which of those efforts they defeat and in whether the media survives.

In SP 800-88r2, user-addressable locations are the storage locations reachable through the device's normal read and write interface, degaussing erases a magnetic recording by applying a magnetic field, and cryptographic erase sanitizes the keys that protect encrypted data.

Method	Recovery effort it defeats	Media afterwards	Example techniques
Clear	Simple, non-invasive recovery through the normal interface	Typically still usable	Overwriting all user-addressable locations; a factory reset where rewriting is not supported
Purge	State-of-the-art laboratory recovery	Potentially reusable	Dedicated device sanitize commands, cryptographic erase, degaussing of suitable magnetic media
Destroy	State-of-the-art laboratory recovery	Unusable for storage	Shred, disintegrate, pulverize, incinerate, melt

Choosing the method

NIST asks organizations to categorize the information being disposed of, assess the media it is recorded on, assess the risk to confidentiality and decide what will happen to the media next, and only then choose the method. The figure below starts from reuse, a key decision in SP 800-88r2^[16]: destroying media not intended for reuse can be the simplest, most cost-effective method. Most media support some clear technique, but not all have a reliable purge technique^[16]. For moderate sensitivity data, the owner of the information storage media may choose to accept the risk of applying clear^[16] techniques to that media. If additional assurance is needed^[16], use purge or destroy.

• Clear is limited to its defined threat. If a requirement demands resistance to laboratory recovery, clear falls short, because it only protects against simple recovery through the normal interface. NIST also advises using purge instead of clear when possible.
• Purge and destroy reach the same recovery bar; the difference is reuse. If the same media must be used again, destroying it defeats that goal, so purge it when a reliable purge technique^[16] is available for that media. When none is available, the methods left are clear and destroy: the owner of the information storage media may accept the risk of clear^[16] for moderate sensitivity data, and destroy is the method when that risk is not accepted. Whether a given purge technique actually leaves a device usable depends on the technique and the device.
• Destroy suits media that will not be reused, or that has failed or become obsolete so the other methods cannot be applied. Damage alone does not qualify: NIST notes that bending, cutting or drilling a hole may only partly damage the media and leave portions readable in a laboratory, so a snapped connector is no proof of destruction.

The takeaway: deletion removes references, clear defeats simple recovery, purge defeats laboratory recovery while keeping reuse possible, and destroy defeats laboratory recovery by ending the media's use.

A sanitization technique must make access to the target data infeasible at the required level of effort, so the storage technology narrows the choice.

Degaussing is for magnetic media

Degaussing erases magnetic recordings with a strong magnetic field. SP 800-88r2^[16] lists it as a physical purge technique for magnetic tapes and magnetic hard disk drives, warns that it should not be used for non-magnetic media such as flash storage and solid-state drives (SSDs), and notes that many existing degaussers lack the force for modern magnetic media that need a stronger field to erase (high-coercivity media). An SSD stores data electronically in flash memory cells rather than magnetically, so degaussing it does not sanitize the data.

Overwriting can miss flash cells

Overwriting through the normal read and write interface suits many magnetic drives, but NIST explains that flash-based devices contain spare cells and perform wear leveling (spreading writes across cells to extend the device's life), so the normal interface cannot address every location where sensitive data was stored. For such devices NIST points to dedicated, standardized device sanitize commands, which reach past that interface, or to cryptographic erase.

Cryptographic erase

Cryptographic erase (CE)^[17] is a purge technique that sanitizes the keys protecting encrypted target data instead of overwriting the data itself; without those keys, the remaining encrypted data (ciphertext) cannot be decrypted. Because only keys are erased, NIST notes it can sanitize much faster than other techniques, and for cloud or other logical storage, where the data owner cannot reach the physical media, it may be the only viable purge option. Its preconditions matter:

• Suitable encryption must have protected the target data in the first place. Areas of the device that were never encrypted, and unencrypted (plaintext) copies held elsewhere, need separate sanitization.
• Every usable copy of the keys must be eliminated. NIST says CE should not be trusted on media whose keys were backed up or escrowed unless the organization is confident about how and where those copies are held, because a surviving key copy is a recovery path.
• Removing an application password is not cryptographic erase if the encryption keys themselves remain recoverable, since the cryptographic means of reading the data still exists.

The takeaway: use the organization's approved technique for the specific media type, and never carry a magnetic-disk procedure such as degaussing or a single overwrite over to every device.

Running a sanitization tool does not finish the job; the organization needs evidence that it worked before the media is reused or leaves its control. SP 800-88r2^[16] separates two checks whose names are easy to swap:

• Sanitization verification determines whether the technique completed successfully, for example by checking a tool's completion status, errors and the health of the media, or by inspecting the remnants of a destruction process.
• Sanitization validation decides whether the target data was effectively sanitized, so the result meets the requirement, and ends in approving the sanitization as effective or rejecting it.

A failed or uncertain result means the media is not released yet. NIST says a rejected result requires repeating sanitization with a different technique or escalating to a more secure method. After an accepted result, NIST recommends completing a certificate of sanitization for each sanitized item, per the organization's policies, as the record of what was done.

A disposal request, or a ticket marked "sent for wiping", documents what someone intended to happen. It is not evidence of what actually happened on the media, which is what verification and validation supply.

The takeaway: verification checks the operation, validation judges the outcome, and only an accepted, documented result lets the media go.

Encryption is the reversible tool of cryptography: what goes in can come back out for someone who holds the right key. NIST defines encryption^[18] as the cryptographic transformation of data (plaintext) into a form (ciphertext) that conceals the data's original meaning; when the transformation is reversible, the reverse process, decryption, restores the original. Encryption combines an algorithm (the mathematical procedure), a key (the value that controls the operation) and the data. Widely used algorithms are public standards, so protection depends on keeping the secret keys secret: a symmetric key (one secret shared by both sides) and the private key of a public and private key pair; NIST Special Publication 800-175B Revision 1 (SP 800-175Br1)^[7] compares keys to the combination of a safe, NIST's own analogy, which offers no security once an adversary learns it.

That reversibility is what separates encryption from hashing, covered later on this page. If an authorized person must read a confidential document again, store it encrypted; a hash of it would keep only a fixed-length digest from which the document cannot be recovered.

Confidentiality and integrity

1. When confidentiality protection is required, encryption provides that confidentiality^[7].
2. When a symmetric key is already shared between the entities, symmetric encryption alone is sufficient^[7]. Otherwise, hybrid cryptography uses an asymmetric-key system (a public and private key pair) to establish a symmetric key^[7], which then encrypts the data.
3. All sensitive information requires integrity protection^[7], and confidentiality protection may be required as well. When someone must verify who signed, use a digital signature, which only the party with access to the private key^[7] can generate. Otherwise, a message authentication code (MAC), computed with a symmetric key shared among a community of users^[7], lets any entity that knows the key^[7] verify the data's integrity. A hash function alone gives some assurance of data integrity^[7] and is not recommended unless the risk of an adversary altering the data and computing a new hash value is very low.

The takeaway: encryption protects confidentiality while keeping the data usable later, symmetric keys and private decryption keys must stay secret, and all sensitive information requires integrity protection^[7], encrypted or not.

Symmetric encryption is the workhorse for protecting large amounts of data. A symmetric-key algorithm^[8] uses the same secret key for an operation and its complement, such as encryption and decryption; NIST also calls it a secret-key algorithm. The Advanced Encryption Standard (AES) is an example.

Symmetric encryption is efficient, but sharing its key needs care. Symmetric algorithms are efficient, and NIST notes that asymmetric algorithms are much slower than symmetric ones^[7] and are not used to process large amounts of data. Symmetric encryption is therefore the tool for bulk work such as encrypting whole disks, databases and network traffic. But every party who needs to read the data must first obtain the same key over some secure route and then protect it, and anyone else who obtains the key can decrypt everything it protects.

That is why a symmetric key must never be handled like a public key. Publishing an unprotected symmetric key, emailing it alongside the data or storing it next to the ciphertext hands the decryption secret to whoever finds it. Getting the key safely to the right parties is the hard part, and it is the problem asymmetric cryptography, covered next, helps solve.

The takeaway: one shared secret, efficient enough for bulk data, and only as safe as the way the key is distributed and stored.

Asymmetric cryptography (also called public-key cryptography) removes the need to share a secret in advance. Each party has a key pair^[9]: a public key that can be given to anyone and a private key that only its owner holds. The two keys are mathematically related, yet it is computationally infeasible to derive the private key from the public one. NIST's definition already names the two jobs: one key encrypts or digitally signs the data, and the other decrypts it or verifies the signature.

Which key is used depends on the job. The public key goes to the step anyone may perform (encrypting to someone, or checking a signature), and the private key to the step only the owner may perform (decrypting, or signing):

• For confidentiality, the sender encrypts with the recipient's public key, and only the recipient's private key can decrypt. Encrypting with the sender's own public key would make the sender's private key the only decryption key, so the intended recipient could not read the message.
• For a digital signature, the signer creates the signature with the signer's own private key, and anyone can check it with the signer's public key. A properly implemented digital signature^[19] provides origin authentication, data integrity and signatory non-repudiation, as long as the private key is held only by the signer and the public key really belongs to them. A signature made with anyone else's private key, the recipient's for example, would attribute the message to the wrong key holder.

The figure below traces both jobs: only the recipient's private key decrypts, and only the signer's private key signs.

Signing does not hide anything. A signed message stays readable unless it is also encrypted, so a signature answers "who sent this, and was it changed?" but not "who can read this?". Non-repudiation is, in NIST's glossary, protection against an individual who falsely denies having performed a certain action^[20], and a digital signature supports it by letting a third party determine whether a message was actually signed by a given entity.

The takeaway: encrypt with the recipient's public key, sign with your own private key, and verify with the signer's public key.

Hybrid systems use symmetric and asymmetric cryptography together, each for its own job. SP 800-175Br1^[7] explains that asymmetric algorithms are too slow for large amounts of data, and that key-establishment methods combine symmetric and asymmetric algorithms to achieve better efficiency than asymmetric algorithms alone while needing fewer keys than symmetric algorithms alone. Key establishment^[21] is the general name for any procedure that results in secret keying material shared between parties.

Sending a confidential file to a partner shows the pattern, traced step by step in the figure below:

1. The sender's software creates a fresh, random symmetric key.
2. It encrypts the file with that symmetric key, which is efficient for bulk data compared with asymmetric encryption.
3. It encrypts only the small symmetric key with the partner's public key.
4. It sends the encrypted file and the protected key together.
5. The partner's private key recovers the symmetric key, which then decrypts the file.

Secure web connections follow the same division of labor through Transport Layer Security (TLS), a protocol designed to prevent eavesdropping, tampering and message forgery between client and server applications. In TLS 1.3, RFC 8446^[22] describes a handshake protocol that authenticates the parties and establishes shared keying material, and a record protocol that uses those parameters to protect the traffic. Encrypting every byte asymmetrically just because a key pair is available would throw away the performance advantage that is the reason for the hybrid design. The two types are complementary, not competing choices.

The takeaway: asymmetric techniques establish or protect the key, and symmetric encryption protects the data.

Strong algorithms do not help if keys are mishandled, so this section covers the two duties that come with any key: keeping it safe and, for public keys, knowing whose it is. Key management^[23] is the handling of keys across their whole life cycle, including generation, storage, establishment, use and destruction.

Secret and private decryption keys need confidentiality and availability

Key management includes protecting confidentiality and availability. Symmetric keys and private decryption keys must stay secret, because a disclosed decryption key undoes the encryption for anyone who holds it. Keys must also stay available to authorized users: SP 800-175Br1^[7] notes that some keys need to be backed up or archived so operations can resume if a key is lost, with a recovery capability usable only by authorized entities, and warns that if a key needed to recover data is lost, the data is lost unless the key can be recovered.

Backups are where this catches people out. A backup of encrypted data is a recovery plan only if a usable decryption key will also be available when the backup is restored; a perfect copy of ciphertext with no key is unreadable. This is the mirror image of cryptographic erase from Matching the sanitization technique to the media: deliberately destroying every key copy sanitizes data precisely because ciphertext without its key cannot be read.

Public keys need a trusted owner

A public key does not need to be secret, but it does need to be authentic. If an attacker can substitute their own public key for your partner's, you will encrypt files the attacker can read and accept the attacker's signatures as your partner's. A public key certificate^[24] addresses this: it contains the owner's public key and identifying information and is digitally signed by a certification authority (CA), a trusted party, thereby binding the public key to its owner. A name typed into an unverified email next to a key proves nothing about who owns that key; trust comes from a certificate you can validate or from another authenticated channel.

The takeaway: protect symmetric and private keys against disclosure, protect needed keys against loss, and accept a public key only when its owner is vouched for.

Hashing is the one-way tool of cryptography: it detects change but never gives the original back. A cryptographic hash function^[10] maps input of any length to a fixed-length output, called the hash value or digest. Approved hash functions are designed so that it is computationally infeasible to find an input that produces a given digest (one-way) or two different inputs that produce the same digest (collision-resistant). The same input with the same function always gives the same digest, and NIST likens a hash value to a fingerprint of the file or message because it depends on the entire contents.

Because a digest cannot be turned back into the data, storing only its digest instead of an archive is the wrong way to preserve it for later reading.

Comparing against a trusted reference

To check whether a file changed, calculate its hash now and compare it with a reference hash from a trusted source. With a secure hash and a trusted reference, a match provides strong evidence that the file is identical to the one the reference was calculated from. A mismatch shows only that the data differs, not why: corruption in transfer and deliberate tampering look the same. Everything rests on the reference being trustworthy. If an attacker who can replace a download can also replace the hash published beside it on the same compromised site, the two will match perfectly. A reference protected by a digital signature closes that gap, because an adversary who does not know the private key cannot generate a valid signature^[7]. A hash function used alone, without a secret key or digital signature, gives some assurance of data integrity^[7]. SP 800-175Br1^[7] does not recommend a hash function alone, without a secret key or digital signature, unless the risk of an adversary altering the data and computing a new hash value is very low, as when data is provided by a trusted source and the hash value is used only to detect changes from a degraded transmission medium.

Adding a secret: keyed MACs

A plain hash involves no secret, so anyone can calculate one and it cannot show who produced it. A message authentication code (MAC)^[25] is a cryptographic checksum calculated with a symmetric key, so only holders of that key can produce a valid one; it supports both integrity and source authentication between those key holders. HMAC is the common form, a MAC that uses a cryptographic key together with a hash function^[26]. NIST's glossary lists MAC^[27] as the abbreviation for message authentication code and also for mandatory access control and media access control. Mandatory access control^[28] is an access control policy that is uniformly enforced across all subjects and objects within a system. A media access control (MAC) address^[29] is an address assigned to a network interface.

NIST states that message authentication codes (MACs) provide authenticity and integrity protection but not non-repudiation. Every party that shares the MAC key can create valid MACs, so a valid MAC shows the message came from one of the key holders, not which one. When one particular signer must be provably identified, the tool is a digital signature made with a private key only that signer holds.

Tool	Secret involved	Shows the data is unchanged	Shows who produced it
Plain hash	None	Yes, against a trusted reference	No
Keyed MAC (such as HMAC)	Shared symmetric key	Yes	Only that it was one of the key holders
Digital signature	Signer's private key	Yes	Yes, the single private-key holder

The takeaway: hash to detect change, add a shared key (a MAC) to authenticate between key holders, and use a digital signature when one specific signer must be proven.

Quantum computing changes which cryptographic tools can be trusted for the long term, and it affects them unevenly. A quantum computer uses quantum-mechanical effects to solve certain mathematical problems that are impractical for conventional computers. NIST explains that much of today's asymmetric cryptography relies on problems such as factoring very large numbers, and that a sufficiently capable machine, which experts call a cryptographically relevant quantum computer, could solve them^[30] in days or hours instead of the billions of years a conventional computer would need. No one knows when such a machine will exist; NIST cites expert estimates ranging from a few years to a few decades.

What is and is not at risk

The threat is concentrated on asymmetric cryptography. NIST's report on post-quantum cryptography^[31] states that large-scale quantum computers would break many of the public-key cryptosystems in use today, naming the families behind them: RSA, elliptic-curve cryptography and Diffie-Hellman key exchange, used for key establishment and digital signatures. Symmetric encryption and hashing are much less affected; the same report says that doubling the key size would be sufficient to preserve symmetric security, and NIST's PQC FAQ^[32] says current applications can continue to use AES with 128-, 192- or 256-bit keys. The concern is about future machines, not a claim that today's encryption has already been broken.

A bigger key of the same asymmetric kind is not the answer. NIST's draft transition plan, NIST IR 8547^[11], schedules RSA and elliptic-curve signature schemes to be disallowed after 2035 even at their higher security strengths, because the vulnerable mathematical problem stays the same whatever the key size.

Post-quantum algorithms run on ordinary computers

Post-quantum cryptography (PQC), also called quantum-resistant cryptography, aims for cryptographic systems that are secure against both quantum and classical computers^[31] and that work with existing communications protocols and networks. In August 2024 NIST published its first three PQC standards^[33]: FIPS 203 (ML-KEM) for key encapsulation, a form of key establishment, and FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) for digital signatures. NIST states they can and should be put into use now.

PQC needs neither a quantum computer nor special hardware. The US National Security Agency (NSA^[34]) describes quantum-resistant algorithms as implemented on existing platforms, deriving their security from mathematical complexity. That is the line between PQC and quantum cryptography: quantum key distribution (QKD), for example, uses the physics of quantum systems and special-purpose equipment such as dedicated fiber links. Confusing the two produces the false belief that adopting PQC requires quantum hardware.

Harvest now, decrypt later

An adversary does not need a quantum computer today to benefit from one later. In the threat NIST calls harvest now, decrypt later^[30], an adversary captures encrypted data now and keeps it until a future quantum computer can break the protection. NIST IR 8547^[11] calls this one of the main reasons the transition is urgent, especially for data with long-term sensitivity such as government secrets or medical records. Prioritizing migration only by whether ciphertext can be broken today misses the point; the deciding question is how long the data must stay confidential.

Preparation starts with an inventory

Before vulnerable algorithms can be replaced, organizations must identify where they are used^[33]. A joint CISA, NSA and NIST factsheet, Quantum-Readiness: Migration to Post-Quantum Cryptography^[35], recommends a quantum-readiness roadmap, a cryptographic inventory, an assessment of the supply chain and engagement with technology vendors about their PQC plans, because much of an organization's cryptography lives inside products and services it buys. Replacing only the most visible encryption tool leaves the dependent systems and suppliers outside the plan. As a study recommendation, support the inventory and the approved migration steps rather than choosing replacement algorithms on your own.

The takeaway: quantum computing threatens today's asymmetric schemes, PQC runs on ordinary computers, long-lived secrets make the threat current, and the transition starts with knowing where cryptography is used.

Public external AI services make data handling an everyday decision, because submitting prompts and uploaded files sends data outside the organization. The ISC2 exam outline's AI security integration^[3] for this domain describes identifying the risks of data leakage when employees interact with public AI services, and applying proper data handling (classification, masking and sanitization) and encryption to protect the organization. NIST's Generative AI Profile^[36] likewise lists data privacy among generative AI risks, including leakage and unauthorized disclosure of personal or other sensitive information.

Check classification and policy before submitting

Start with the data, then check the tool and its permitted use. Before using a public AI service for a work task, check the data's classification and what the handling policy permits for that classification. Customer records, unreleased financial results or source code labeled confidential are disclosed to an external party when submitted to an external AI service. Where policy allows the task, use the organization's approved tools and send less: remove details the task does not need, or mask identifiers as described in Masking and truncation.

A personal account does not change the picture. Using a personal AI account for confidential work, on the grounds that it is separate from the corporate account, still sends organizational information to an external service, outside whatever agreements and controls the organization has in place.

An encrypted connection is not permission

Public AI services are reached over an encrypted connection, typically TLS, which RFC 8446^[22] describes as designed to prevent eavesdropping, tampering and message forgery between client and server. That protects the prompt in transit, but RFC 8446 also states that data sent over the channel is visible to the endpoints, and the AI service is an endpoint: it must read the content to process it. A padlock icon therefore confirms a protected channel to that service. It says nothing about whether the service is an authorized recipient or whether the intended use is permitted; those are classification and policy questions, answered separately.

The takeaway: classification and policy decide whether data may go to an AI service at all, and encryption in transit protects the channel but does not authorize disclosure.