Objective 3.3Security Architecture· 4 min read

Protecting Data

Compare and contrast concepts and strategies to protect data

What you will learn

Name the three data states and know which tool protects each.
Classify data and match each classification to the protection it warrants.
Separate encryption, tokenisation and masking — the trio most confused here.
Explain data sovereignty and how it constrains where data may be stored.

Protecting everything to the same degree means either spending without reason or under-protecting what deserves more. So this objective starts with classification: what is this data, who owns it, and what happens if it leaks? The control follows the answer.

The three data states

Each state has its own tool, and the question describes the state that failed.

At rest
On disk, in a database, in a backup. Its tool: disk or field encryption.
In transit
Crossing a network. Its tool: TLS or an encrypted tunnel.
In use
In memory while being processed. The hardest of the three, because the program needs it readable in order to work.

Classifications

Public	Publishing it causes no harm. The marketing site, press releases.
Private / Internal	For internal use. A leak is embarrassing, not catastrophic.
Sensitive	A leak harms people or the organisation: employee data, contract details.
Confidential	Restricted to those who need to know.
Critical / Restricted	The highest level: a leak means severe damage or a regulatory breach. It demands the strictest controls.

Data types

Regulated	Governed by a law or standard. The organisation's opinion does not set its protection level.
PII	Data identifying a person: a name with an ID, an address, a national number.
Intellectual property / Trade secret	Whatever derives its value from not being known: a design, a formula, an algorithm.
Financial / Legal	Financial records or legal documents, usually under mandatory retention periods.
Human- vs non-human-readable	Text a person reads versus binary or encoded data. The distinction matters to data loss prevention tooling.

Tokenisation vs encryption

	Tokenisation	Encryption
Mechanism	Replacing the value with a token bearing no mathematical relation to it; the original sits in a separate vault	A reversible mathematical transform with a key
If the database is stolen	The tokens are worthless — no key derives the original from them	The key unlocks it, so its safety is the key's safety
Common use	Card numbers — to shrink compliance scope	General protection at rest and in transit

Encryption, tokenisation, masking — three different things

Encryption is reversible with a key and returns the full value. Tokenisation swaps the value for a substitute and keeps the original elsewhere. Masking hides part and shows the rest irreversibly — like showing a support agent only the last four digits. Ask: must the original be recoverable? Yes, with a key = encryption. Yes, from a vault = tokenisation. Never = masking.

One dimension has nothing to do with technology: data sovereignty. Data falls under the laws of the country it is physically stored in, not those of the organisation's home country. A national regulation may forbid citizens' data leaving; a regulator may require health records to stay inside the border. That makes the data centre's location a legal decision before it is a technical one — and the question describes a regulatory constraint and asks what it does to the design.

Real-world example: a shop and a card payment

An online shop handles cards. The card number travelling from the browser is protected by TLS — that is the in-transit state. On arrival it is immediately swapped for a token, with the original held at the payment provider rather than the shop — that is tokenisation, and its purpose is to take the shop's database out of compliance scope altogether. On the support agent's screen only "•••• 4417" appears — that is masking, and nothing needs to reverse it. The stored financial records are encrypted at rest and stay in an in-country data centre because the regulation requires it. Four different tools for four different needs in one flow.

What matters on the exam

Identify the state first: at rest = disk or field encryption, in transit = TLS, in use = the hardest and often the answer "difficult to protect".
"We never need the value back" points to masking. "We need it later but not here" points to tokenisation.
For regulated data the organisation's opinion does not set the protection level. If the question names a regulation, the constraint is external.
Sovereignty is a question about geography, not encryption. Strong encryption in the wrong country does not cure the violation.

Quick check

Answer in your head first, then reveal.

Which data state is hardest to protect, and why?Reveal the answer
In use: data in memory has to be readable for the program to operate on it, so it cannot simply be encrypted the way it is at rest or in transit.
When do you choose tokenisation over encryption?Reveal the answer
When you would rather not hold the real value at all. The token is worthless if stolen, because it has no mathematical relationship to the original, which sits with another party — so your system leaves compliance scope instead of being secured inside it.
A regulation requires citizens' data to stay in-country. Is strong encryption plus offshore storage enough?Reveal the answer
No. Sovereignty constrains geography, not confidentiality. Data stored outside the border falls under that country's laws however well encrypted, and the violation stands.
How do masking and encryption differ on recovery?Reveal the answer
Encryption is reversible: whoever holds the key recovers the full value. Masking is inherently irreversible — the hidden part never reached the screen, so there is nothing there to recover.

Your next step

Read the lesson, then mark it complete

Sources

Used to verify the facts. The writing is original to Passuit.