ESP-IA methodology

CCN-STIC 2011: a guide to the ESP-IA methodology

What gets evaluated in an AI-enabled product, which documents are needed and how the result is reached. We explain the CCN methodology so you can understand the process before starting an evaluation.

Version 1.0 · October 2026 · CYBSER's explanation, not a replacement for the official guide.

Read official guide (PDF, Spanish) View ESP-IA evaluation service

What CCN-STIC 2011 is

CCN-STIC 2011 is the guide that defines the AI Product Security Evaluation Methodology (ESP-IA). The CCN developed it in response to the threats specific to products that embed AI capabilities: evasion, poisoning, model extraction, prompt injection, information disclosure or misuse of tools and actions.

The guide sets out who takes part, which evidence is required before the process starts, how the product's security problem is determined and which stages make up the evaluation up to the Technical Evaluation Report (ITE).

What it means for your product

The evaluation covers a specific version and configuration, not all AI used by your company. Security Functional Requirements (SFRs, RFS in the Spanish guide) are security properties verified through testing. Which ones apply depends on the product's capabilities and connections.

Quick read

What it is

The CCN guide defining how the AI-specific security of a product is evaluated.

Who it applies to

Manufacturers seeking to evaluate the AI-specific security of their product. Using AI does not, by itself, make this evaluation mandatory.

What it clarifies

Actors, minimum evidence, characterisation questions, applicable SFRs and the PASS / FAIL verdict logic.

When to read it

When your product uses AI and you want to understand what an evaluation may require before scoping the project.

Actors involved

  • Applicant or manufacturer: files the evaluation request and designs, develops and maintains the product.
  • Evaluation laboratory: entity accredited and authorised by the CCN to run ESP-IA evaluations.
  • CCN: validates the Security Declaration, authorises laboratories, reviews the ITE and issues the evaluation result.

Minimum required evidence

  • The Security Declaration (DS) per Annex A, a private document that includes the product architecture.
  • Answers to the characterisation questions and the resulting security problem.
  • The product in its final market version and its user and configuration guides.
  • An accessible evaluation environment with the access, observation and evidence means needed to verify each applicable SFR.
  • Credentials delivered through a secure channel, never inside the DS.

From product to security problem

  • The manufacturer describes the architecture: interfaces, AI models, data, services and tools, and how they relate.
  • It answers the characterisation questions (C01 to C21) about its AI capabilities.
  • The applicability matrix determines which rules are met and, with them, the applicable threats, policies and SFRs.
  • Answers describe facts about the product, not vulnerabilities: an applicable SFR marks a property to be verified.
  • Existing controls do not remove applicable SFRs: their implementation is documented and tested.
  • For direct injection, C01 and C03 must be YES and the input interface must reach the model interpreting instructions. All satisfied rules apply cumulatively.

Threats and policies covered

  • Manipulating behaviour: evasion (T.EVASION), prompt injection (T.INJECTION) and poisoning (T.POISONING).
  • Access to information: model extraction (T.EXTRACTION), training data membership inference (T.MEMBERSHIP), model inversion (T.INVERSION) and information disclosure (T.DISCLOSURE).
  • Actions and resources: misuse of AI agency (T.AGENCY) and resource exhaustion (T.EXHAUSTION).
  • P.OVERSIGHT: human validation and intervention for critical or irreversible actions.
  • P.TRACEABILITY: logging and later reconstruction of the AI's relevant activity.
  • ESP-IA defines 27 SFRs: 22 derived from threats and 5 from policies. Only those selected by the applicability matrix are required for the product.

The evaluation process

Before testing, the applicant must engage an authorised laboratory, prepare the DS and environment, obtain favourable DS validation from CPSTIC and submit the application. Formal evaluation starts when the CCN accepts it.

  • Stage 1: analysis of the Security Declaration and of the applicability matrix applied to it.
  • Stage 2: access to and configuration of the test environment for the declared version.
  • Stage 3: verification of each applicable SFR through functional, adversarial or penetration testing.
  • Stage 4: additional penetration testing, with a minimum of three person-days, using at least the OWASP AI Testing Guide.
  • Stage 5: generation of the Technical Evaluation Report (ITE) per Annex B.

Three person-days is the minimum effort for additional penetration testing, not the total project duration. All applicable SFRs must also be verified. Effort depends on architecture, interfaces, AI components and configurations.

Evaluation result

Each applicable SFR gets a PASS or FAIL result. The overall verdict is PASS only if all applicable SFRs pass, no non-conformity is recorded and the additional penetration testing does not identify AI-specific vulnerabilities that compromise the product's security. The laboratory records the verdict in the ITE and the CCN reviews the report and issues the final result.

Before starting an ESP-IA evaluation

You do not need to arrive with a completed Security Declaration or interpret the matrix on your own. At CYBSER, we prepare the documentation using information from your team. These are the points we review together:

1. AI capabilities and scope

Identify which product capabilities depend on AI and how interfaces, models, data and tools relate to each other.

2. Product characterisation

We work through C01–C21 with your team and determine the applicable SFRs before finalising the Security Declaration.

3. Product access and evidence

We agree on product access and the evidence needed for testing, such as logs or persistent state where relevant. Your team enables the access that only the manufacturer can provide.

4. Alignment with the qualification route

If CPSTIC inclusion is the objective, review its requirements separately. ESP-IA does not replace the inclusion procedure or guarantee a catalogue entry.

How CYBSER helps

We handle product characterisation, prepare the Security Declaration and determine the applicable SFRs. We perform the tests and produce the Technical Evaluation Report for review by the CCN. Your team supplies the technical information, access and product changes only the manufacturer can provide.

We take care of the process so your team can stay focused on the product.

View ESP-IA evaluation View more CCN-STIC guides

Consult the official guide

You can consult the Spanish-language official CCN guide here. This explanation is based on version 1.0, October 2026, reviewed on 9 October 2026.

Consult CCN-STIC 2011 →

Frequently asked questions about CCN-STIC 2011

What does ESP-IA actually evaluate?
Vulnerabilities whose exploitation depends on AI-specific mechanisms, such as inference, learning, context or AI-mediated actions. If replacing AI with conventional software leaves essentially the same vulnerability and testing procedure, it generally falls outside ESP-IA's specific scope.
How are the requirements that apply to my product determined?
The manufacturer describes the architecture and answers C01–C21. Rules combine those answers and, where required, relationships between components to determine applicable threats, policies and Security Functional Requirements (SFRs, RFS in the Spanish guide). All satisfied rules apply. A YES alone is not always sufficient.
Does ESP-IA replace LINCE or CICLON?
No. ESP-IA focuses on AI-specific security. CCN-STIC 2011 does not itself grant CPSTIC inclusion or establish a universal combination with LINCE or CICLON. Any required catalogue inclusion, certification or additional evaluation must be assessed separately.
What result does the manufacturer get at the end of the evaluation?
Each applicable SFR receives a PASS or FAIL result and the laboratory issues a Technical Evaluation Report (ITE). The overall verdict is PASS only if all applicable SFRs pass, no non-conformity is recorded and the penetration testing does not reveal AI-specific vulnerabilities that compromise the product's security. The CCN reviews the ITE and issues the final result.

Want to check whether your AI product is ready for an ESP-IA evaluation?

We review architecture, characterisation, applicable SFRs and the test environment before the evaluation starts.