Common Criteria: Claims, Evidence, and Evaluation

1. Why This Framework Exists And What It Proves

You may have felt this before: a security standard sounds important, but the moment you look at it, it feels buried under forms, roles, lab reports, and strange terms. It can make you wonder if the whole thing is mostly bureaucratic theatre — something smart people talk about to sound serious, while everyone else quietly nods along. That feeling is normal.

The good news is that Common Criteria is not trying to impress you. It is trying to answer a very simple question: can this product be trusted to do the security job it claims to do? Not “does it sound secure?” Not “does the vendor say it is secure?” The real question is whether there is enough evidence to believe the claim.

Think of it like buying a used car in Colombo. You do not trust it because the seller smiles confidently. You trust it because someone checks the engine, the brakes, and the paperwork. Common Criteria works the same way. It is a system for turning a vague claim into a checked claim.

The anchor idea is this: Common Criteria is not about perfection. It is about evidence.

By the end of this course, you will be able to explain why the framework exists, what it is actually proving, and why the process is so formal. You will be able to see past the jargon and describe the logic of an evaluation from the ground up.

That matters because once you see this clearly, the rest of the framework stops looking like a maze. It starts looking like a machine built for one job: separating a promise from a proven claim.

2. The Core Idea Trust Evidence And Defined Claims

If Section 1 gave you the big reason this framework exists, this section gives you the engine underneath it.

Common Criteria is built on three simple ideas:

1. Trust is not a feeling.
2. Evidence is what turns a claim into something you can examine.
3. A claim has to be defined clearly before anyone can test it.

That is the whole shape of it. The rest is detail.

Trust Is Not The Same As Belief

You already know this from normal life.

You trust a friend to show up because they usually do. You trust a restaurant because it has been clean every time you went. You trust a delivery rider because they are on time more often than not.

But trust is not magic. It is a shortcut your mind uses when you have seen enough consistent behavior.

“So trust is really just confidence built from repeated proof.”

That is the first key idea here.

In security, this matters because a product can sound trustworthy without actually being checked. A polished brochure does not prove anything. A confident sales pitch does not prove anything. Even a lot of technical language does not prove anything by itself.

Trust only becomes meaningful when it rests on something testable.

That is why Common Criteria does not start with vibes. It starts with a claim.

A Claim Is Only Useful If It Is Specific

Imagine someone says, “This system is secure.”

That sounds reassuring, but it is too broad to test.

Secure against what? Against hackers on the internet? Against insiders with access? Against data theft? Against tampering? Against wrong settings?

If the claim is vague, then the evaluation is vague too. And if the evaluation is vague, the result is not very useful.

This is the same reason a campaign goal that says “improve performance” is too loose to act on. You can talk about it all day, but you cannot measure it clearly until you define what success means. Security works the same way.

A claim must draw a boundary. It must say what the product is supposed to do, what it is not supposed to do, and under which conditions it is being judged.

“Ah. So the framework is not just asking if something is good. It is asking what exactly it promised to do.”

Yes. That is the core move.

Evidence Is What Makes The Claim Testable

Once a claim is defined, the next question is simple:

What proof supports it?

Evidence is anything that helps answer the question, “Can we believe this claim?”

That might include design documents, test results, configuration details, descriptions of how the product is built, or proof that certain security rules are actually enforced.

Think of evidence like the items on a table after a repair job. If someone says a laptop was fixed, you do not just accept the sentence. You look at what changed, what was tested, and whether the problem really disappeared.

Evidence is not the same as opinion. It is not the same as confidence. It is not the same as a brand name.

Evidence is the bridge between “we say” and “we can show.”

Remember the idea from Section 1: Common Criteria is about proving a security claim, not decorating it. This is the mechanism behind that idea. The framework makes a product stand in front of its own claim and answer for it.

Why The Claim Must Be Defined Before The Evidence

This order matters a lot.

You might think you can collect evidence first and sort out the claim later. But that usually creates confusion.

If you do not know what you are trying to prove, then you cannot tell which evidence matters. You end up with piles of paper, lots of technical detail, and no clear answer.

It is like trying to grade an essay without a question prompt. You can read every sentence, but you still do not know what success was supposed to look like.

So Common Criteria forces clarity early.

First define the promise. Then gather the proof. Then judge whether the proof matches the promise.

That is the logic under all the formal language.

The Three Ideas Fit Together Like A Lock

You can think of these three ideas as parts of one lock:

• The claim is the shape of the key.
• The evidence is the metal that must fit that shape.
• Trust is what you get if the key really turns the lock.

If the key is badly cut, the lock cannot be tested properly. If the metal is weak, the key does not deserve trust. If the key fits and turns, then you have something stronger than a guess.

That is what the framework is doing all the time. It is not trying to make security sound grand. It is trying to make security checkable.

“This is why the process feels so exact. It has to be exact, or the trust means nothing.”

Exactly.

What The Evaluation Is Really Looking For

At this point, you can strip away a lot of noise.

Common Criteria is not mainly asking:

• Is the product popular?
• Is the vendor well known?
• Does the product look advanced?
• Does it have many features?

It is asking something narrower and more serious:

Does the evidence support the security claim, for the exact product, in the exact scope that was defined?

That scope matters because security is never infinite. A product may protect one thing well and fail at another. It may be strong in one environment and weak in another. It may be designed to block one kind of attack but not all attacks.

This is why the framework feels demanding. It refuses to let anyone hide behind broad words.

The Big Shift In Thinking

Once you see this clearly, the whole framework changes shape in your mind.

You stop seeing Common Criteria as a pile of formal paperwork. You start seeing it as a disciplined way to answer three questions:

• What is the product claiming?
• What evidence supports that claim?
• Is the claim justified within the stated limits?

That is the real heart of it.

And now, when you meet the more formal parts later, they will feel less like strange bureaucracy and more like controlled ways of protecting those three ideas.

Trust, evidence, and defined claims are the base layer. Everything else in the evaluation sits on top of them.

3. How An Evaluation Gets Assembled And Judged

By now, you already have the core idea: Common Criteria is about checking whether a security claim is supported by evidence.

Now comes the next question, and it is the one that makes the whole process feel less mysterious:

How does an evaluation actually get built out of that idea?

This is where the framework stops being a single sentence and becomes a working system.

“So this is where the pieces start locking together.”

Yes. And once you see how they connect, the formality starts making sense.

The Evaluation Is Built Around A Target

An evaluation is not for “security in general.” It is for a specific product and a specific claim about that product.

That means the first thing an evaluation needs is a clear target. Not a vague product family. Not a general brand. A clearly bounded thing that can be examined.

Think back to Section 2. A claim only works if it has edges. The evaluation needs those edges too, because everything that follows depends on them.

If the target is not defined clearly, then the rest of the process starts drifting.

• The tests may not match the claim.
• The evidence may be incomplete.
• The result may sound official but not actually mean much.

That is why formal language appears so early. It is not decoration. It is a fence.

The evaluation begins by saying, “This exact thing is what we are judging.”

The Product Description Is The Map

Once the target is set, the evaluation needs a map of what the product actually is.

Not a marketing summary. A working description of the product’s important parts, its boundaries, and the security behavior that matters.

This is where the process becomes more like building a case in court than writing a brochure. The evaluator needs to know what exists, how it is supposed to behave, and where the claim is supposed to apply.

“So the description is not just paperwork. It is the map that tells everyone what counts.”

Exactly.

Without that map, nobody can tell whether a test result is relevant. A result only matters if it belongs to the thing being evaluated.

This is why a formal evaluation feels strict. It keeps the team from quietly changing the object under review while pretending the claim stayed the same.

The Claim Becomes A Set Of Security Needs

Now we get to a very important shift.

A claim is not just a sentence anymore. It gets broken into specific security needs.

That means the evaluator asks questions like:

• What does the product have to protect?
• Who or what is it protecting against?
• What security actions must it perform?
• Under what conditions does the protection need to hold?

This is a major step because broad promises are not testable, but specific needs are.

Remember the idea from Section 2: vague claims are hard to judge. This is the same principle, just deeper. The framework turns a broad promise into smaller, testable pieces.

You can think of it like taking one big job description and splitting it into concrete responsibilities. If a system says it protects login access, that can be unpacked into specific behaviors: rejecting bad passwords, handling retries, limiting exposure, keeping records, and so on.

Now the evaluation has something real to examine.

Evidence Must Match The Need

This is where a lot of people get surprised.

Not all evidence is useful in the same way. Evidence has to match the exact need it is supposed to support.

If the claim is about secure access control, then evidence about the product’s logo, speed, or user interface does not answer that question. If the claim is about how secrets are stored, then a nice-looking admin panel does not prove anything.

The evaluator is always asking: does this evidence support this specific need?

That is the filter.

This is also why Common Criteria can feel slow from the outside. The process is not trying to collect the most evidence. It is trying to collect the right evidence.

That difference matters.

A huge pile of unrelated material can still leave the real question unanswered. But a smaller set of precise evidence can be enough if it lines up tightly with the claim.

Testing Is Only One Kind Of Evidence

A lot of people think evaluation means only testing. That is too narrow.

Testing matters, but it is only one way of supporting a claim. There are also design descriptions, implementation details, configuration rules, and checks that show the product behaves consistently with the claim.

Think of it like this:

• Testing tells you what happened when the product was challenged.
• Design evidence tells you why it is supposed to behave that way.
• Configuration evidence tells you what conditions must be in place for the claim to remain true.
• Documentation evidence tells you whether the whole picture stays consistent.

“So the evaluation is not just asking, ‘Did it pass a test?’ It is asking, ‘Does the whole story hold together?’”

Yes. That is a much better way to think about it.

The Evaluator Is Checking Consistency, Not Just Performance

This is one of the biggest mental shifts in the course.

An evaluation is not mainly a race to see whether the product “works.” Most products work in some sense. The real question is whether the security story is internally consistent.

That means:

• the claim matches the product description,
• the evidence matches the claim,
• the test results match the design,
• and the conditions for trust are all clearly stated.

If one piece does not fit, the whole picture weakens.

It is a bit like a bridge. A bridge does not become safe because one part looks strong. It is safe only if the supports, joints, materials, and load limits all fit together.

Common Criteria does something similar. It checks whether the security claim is supported across the whole structure, not just in one impressive place.

Why The Process Feels So Formal

Now the formality starts to make sense.

The framework is formal because it needs to keep the claim stable while evidence is gathered and checked. If people use loose language, the claim drifts. If the scope keeps changing, the evidence becomes unreliable. If the requirements are vague, the result becomes hard to defend.

Formality is not there to make the process look important. It is there because the process is fragile if the language is loose.

Precision protects trust.

That is the reason behind all the careful definitions, records, and structured language.

A Simple Way To Hold The Whole Process In Your Mind

At this point, you can hold the evaluation as a chain:

1. A product makes a security claim.
2. The claim is narrowed into specific security needs.
3. The product description defines the thing being judged.
4. Evidence is gathered to support those needs.
5. The evaluator checks whether the evidence really matches the claim.
6. The result is only meaningful if the whole chain stays aligned.

That is the process in plain language.

But there is an even better way to remember it, because all of these parts are doing one job together.

The Framework Has A Name

That system has a name. It is called the SCOPE framework:

1. S — Subject: define the exact product or target being judged
2. C — Claim: state what security promise is being made
3. O — Outline: describe the product clearly enough to know what counts
4. P — Proof: gather evidence that supports the claim
5. E — Examine: check that the evidence really fits the claim and the scope

Now the pieces you have been building are easier to carry in your head.

SCOPE is not five separate tricks. It is one connected system.

• If the Subject is vague, the Claim becomes weak.
• If the Outline is incomplete, the Proof may miss the real issue.
• If the Proof does not match the claim, the Examine stage exposes the gap.

You can see the dependency now.

This is the real shape of the framework.

“Wait. So the formal process is really just protecting one chain from breaking.”

Yes — and once you see that, the whole thing becomes much easier to understand.

The Surprising Part Is How Human It Is

Here is the part people do not expect: the process is not mostly about machines or documents. It is about preventing human ambiguity.

People naturally use broad words. People naturally assume others mean the same thing they mean. People naturally skip the hard part where a claim is made precise enough to test.

Common Criteria exists because security cannot depend on assumptions like that. It forces a shared picture. It makes everyone point to the same thing. It asks for proof that can be examined, not just discussed.

That is why the process feels demanding, but also why it is useful.

A Real-World Check You Can Now Do In Your Head

A vendor says a security appliance is certified because it blocks unauthorized access. You might now catch yourself asking:

What exact product is this? What is the actual claim? What security need does that claim cover? What evidence supports it? Does the evidence match the scope?

That is the thinking pattern of someone who understands the system.

If you were sitting in Colombo reviewing a procurement document and you saw a tool described as “secure,” you would now know to ask what that word really means in the evaluation. Not because you memorized jargon, but because you understand the chain underneath it.

That is the shift.

What You Now Have

You now have a way to see the whole evaluation before the details arrive.

You know that the process is built from:

• a specific subject,
• a specific claim,
• a clear outline of the product,
• supporting proof,
• and a careful examination of fit.

And you know why it has to be that way: because trust only matters when the claim stays precise enough to test.

That is the system, not just the procedure.

In the next section, this will become even easier to hold, because you will see how the formal roles and documents keep this chain from slipping.

4. What It Means In Practice And How To Think About It Confidently

Think back to the moment from the start of this course. A security standard looked heavy, full of forms and strict language, and it was easy to feel like the real meaning was hidden behind the paperwork. That feeling made sense then. It looks different now.

Because now you can see what the paperwork is doing. It is not there to create mystery. It is there to keep a claim, a product description, and the evidence lined up so the result stays honest. That is the whole game. Common Criteria is a way of making a security promise answerable.

“So the formal process is not the point. The point is making the claim testable.”
Exactly.

You now think like someone who can hear the difference between a vague promise and a checked claim. When you see words like secure, trusted, or certified, you do not stop at the label. You ask what was claimed, what was proved, and what scope was actually judged. That is a real shift in how you read security language.

Here is what you can do now that you could not do at the beginning:

• You can separate the claim from the proof.
• You can see why scope matters before evidence matters.
• You can tell when a document is being precise and when it is hiding behind broad words.
• You can explain why the process feels strict without treating it like pointless bureaucracy.

That is not just better knowledge. That is a different way of seeing.

Remember the chain from earlier: Subject, Claim, Outline, Proof, Examine. It is not a memorized list. It is a way to keep your head clear when security language gets dense. If one part is weak, the whole evaluation weakens. If the chain holds, the trust has a reason to exist.

You now have the core pattern in your hands. You can walk into a discussion about Common Criteria and immediately ask the right questions without getting lost in the jargon.

And that matters beyond this topic, too. Any time someone asks you to trust a system because it looks official, you now know how to look underneath the surface. You are no longer just hearing security language. You are checking the logic inside it.

That is the difference.

“I can see what this is doing now.”

Yes. And once you can see that, the framework stops feeling like a wall of ceremony and starts feeling like a method you can actually think with.

You now know how to read it, question it, and explain it. That is a strong place to end.