AI product security · CCN-STIC 2011

ESP-IA evaluation of AI-enabled products

We assess how AI could expose data, manipulate decisions or trigger unauthorised actions in your product. We prepare the documentation and manage the ESP-IA process, from defining the scope to CCN review of the results.

AI-enabled product connected to a user interface, data and external tools, with security evaluation checkpoints.
Request an evaluation

When it applies

AI security beyond conventional testing

ESP-IA applies to products whose security is affected by AI-specific mechanisms: inference, learning, adaptation, context or state, learned representation, or actions mediated by an AI capability. If replacing AI with conventional software leaves essentially the same vulnerability and testing procedure, it generally falls outside ESP-IA's specific scope. It may still require assessment under another applicable methodology, such as LINCE or CICLON.

CCN-STIC 2011 defines the threats (evasion, injection, extraction, membership, inversion, poisoning, disclosure, agency and resource exhaustion) and the human oversight and traceability policies verified through specific security requirements and penetration testing.

End-to-end service

What the ESP-IA evaluation includes

We start from the technical knowledge of your product and take care of structuring the documentation, preparing the test environment with the access your team enables and managing the process through to the CCN result.

Product characterisation

We analyse the product and document its AI architecture: interfaces, models, data, services and tools, and how they relate to each other.

Security Declaration

We write the Security Declaration with the necessary technical detail and manage its validation by CPSTIC.

Evaluation scope

We apply the matrix to the product architecture and capabilities to identify all applicable threats, policies and requirements. Existing controls are tested, they do not remove applicable requirements.

Evaluation environment

We define and set up the test environment: access to the product, logs and the evidence needed to verify each requirement.

AI-specific penetration testing

We perform AI-specific penetration testing, using at least the OWASP AI Testing Guide and state-of-the-art attack techniques as the reference.

Non-conformities and remediation verification

We help interpret findings, prepare documentary corrections and verify the product changes that your team needs to make.

Formal process

From characterisation to evaluation result

We follow the process defined in the CCN-STIC 2011 guide and keep traceability between the declared architecture, the applicable requirements, the tests executed and the result obtained.

  1. 1

    Characterisation and scope

    We describe the architecture and AI capabilities and scope the evaluation and the applicable requirements.

  2. 2

    DS and application

    We draft the Security Declaration, manage its validation by CPSTIC and file the evaluation request with the CCN. Formal evaluation starts when the CCN accepts the application.

  3. 3

    Technical execution

    We verify each applicable requirement and perform additional AI testing. We document the evidence and follow-up for the declared version.

  4. 4

    Closure and remediation

    We document findings and verified corrections in the Technical Evaluation Report. The CCN reviews the report and issues the evaluation result.

Evaluation result

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

What we need from your team

You do not need to have everything prepared before we start. We do need access to the people who know the AI implementation and the ability to prepare an evaluable environment and fix any non-conformities that appear.

  • The final product version available on the market and the configuration to be evaluated
  • Access to the technical team
  • Information about interfaces, third-party AI components and dependencies so we can document the architecture
  • Ability to enable access to the product and its logs for the tests
  • Availability to answer questions, sign the required documents and correct product issues
  • Credentials through a secure channel, never in the Security Declaration or contact form

Documentation and results

What is in place at the end of the process

The technical documentation is complete and verified, and results are sent to the CCN in the technical evaluation report for validation.

Documented security problem

Declared architecture, product characterisation and applicable requirements with their justification.

Verified Security Declaration

A complete Security Declaration, consistent with the product documentation and validated by the CPSTIC team.

Test results

PASS or FAIL results per requirement and traceability of the AI-specific penetration testing executed.

Remediation verification

We coordinate verification of corrections and record the outcomes, including any unresolved findings.

One point of contact throughout the process

We handle the analysis, document preparation, testing and evaluation report. You work directly with the team evaluating your product, with one point of contact throughout the process.

We take care of the ESP-IA evaluation so your team can stay focused on the product.

Frequently asked questions about ESP-IA evaluation

How long does an ESP-IA evaluation take?
The guide does not set a total duration. Effort depends on interfaces, AI components, applicable requirements and configurations. Its three person-day minimum applies only to additional penetration testing, alongside requirement verification and the other stages.
Which products may need an ESP-IA evaluation?
Products whose security is affected by AI-specific capabilities: LLM-based assistants and chatbots, systems that interpret natural-language instructions, features that invoke tools, APIs or external systems, components that learn or are fine-tuned after deployment, or agents that propose or execute actions.
Does ESP-IA replace LINCE or CICLON?
No. ESP-IA evaluates AI-specific security. It does not replace other evaluations or itself grant CPSTIC inclusion. If catalogue inclusion is your goal, we separately review the applicable inclusion route and required certifications or evaluations.
How is it decided which requirements apply to my product?
Through the characterisation questions (C01 to C21) and the applicability matrix in CCN-STIC 2011. The answers describe facts about the product, not vulnerabilities: each rule that is met makes a threat or policy and its security requirements applicable, and they are verified through testing during the evaluation. The guide defines 27 requirements, but each product must meet those selected by the applicable rules and architecture relationships.
Who can run an ESP-IA evaluation?
ESP-IA can only be run by an evaluation laboratory accredited and authorised by the CCN. At CYBSER, we handle preparation, perform the evaluation and produce the Technical Evaluation Report. The CCN validates the Security Declaration, reviews our report and issues the final result.
What happens if a requirement does not pass the tests?
That requirement results in FAIL and the overall verdict cannot be PASS. We analyse the cause with your team, help you interpret the findings and verify the corrections you make. The result depends on testing. A favourable verdict is not guaranteed.

Does your product embed AI and do you want its security evaluated?

We manage the ESP-IA process end to end so your team can stay focused on the product.