CCN-STIC 106: getting your product into CPSTIC

What CCN-STIC 106 covers

CCN-STIC 106 explains how to obtain and maintain inclusion in two CPSTIC Catalogue lists: Qualified Products and Services, and Conformity and Governance. Products approved for nationally classified information follow CCN-STIC 102 instead.

First identify the appropriate list and the functionality to be included. For qualified products, also establish the CCN-STIC 140 family and target ENS category: Medium (MEDIA) or High (ALTA). Holding a certificate is not enough: its scope must cover the applicable requirements.

Which route fits your product?

On-premises security products: Common Criteria or LINCE

These products are deployed on the organisation's own infrastructure rather than delivered from the cloud.

Qualification starts from Common Criteria or LINCE certification. Medium requires at least LINCE. High can use Common Criteria or LINCE subject to the additional conditions in section 4.1.1.2.

The LINCE route to High requires coverage of Medium requirements, appropriate cryptography and at least annual vulnerability analysis and penetration testing by a laboratory accredited under Spain's national IT security evaluation and certification scheme (ENECSTI). The first application must include a signed contract for the following year's maintenance. A complementary STIC evaluation is required when High RFS exceed Medium RFS. High qualification is not automatic.

Where the starting certificate leaves RFS uncovered, a complementary STIC evaluation addresses those Fundamental Security Requirements (RFS).

Cloud security products: CICLON

The October 2026 edition explicitly incorporates CICLON, defined in CCN-STIC 2010. The application includes the Security Target (DS), Service Architecture Document (DAS) and Requirements Justification (JR).

The product must cover the RFS for its main functionality. CICLON evaluation and monitoring cover generic cloud requirements. Its Composite Assurance Percentage (PGC) combines evaluation and monitoring and can determine inclusion, continued listing, category changes or exclusion. Qualification is an ongoing commitment, not just an initial assessment.

Conformity and Governance solutions

This list covers solutions supporting compliance and governance without forming part of the system's security architecture. The guide gives indicative examples including GRC, ENS or GDPR compliance support, and security awareness tools. Eligibility depends on the product's actual role.

Instead of qualification RFS verification, applicants submit a penetration testing report under CCN-STIC 2030 from an ENECSTI-accredited laboratory. Critical vulnerabilities or unremediated exploitable vulnerabilities result in an unfavourable verdict.

Cloud solutions also submit a responsible declaration based on CCN-STIC 2010 Annex B (DAS), evidencing valid ENS certification for the deployment systems. This route has its own badge: it is not Medium or High qualification and does not, solely on that basis, require a full CICLON evaluation.

Documentation to prepare

Qualification uses FOR-CPSTIC-02 (application) and FOR-CPSTIC-01 (responsible declaration). Additional evidence depends on the case:

• On-premises with valid certification: certificate and DS. JR is added where the family's RFS differ from those declared in the DS, and IAD where versions or models differ from the certificate. A versioning policy is optional in this case.
• On-premises awaiting certification: proposed DS, JR and versioning policy, allowing the scope to be reviewed before certification.
• Qualified cloud product: DS and DAS using CCN-STIC 2010 Annexes A and B, plus JR.
• New versions or models: baseline DS and Differential Analysis Report (IAD), signed by the technical manager. The last CCN-accepted IAD may be used as a baseline if explicitly identified.

The revised 106 references templates in Annex A for the Requirements Justification (JR), Annex B for the Differential Analysis Report (IAD) and Annex C for the Secure Use Procedure (PES). These are distinct from guide 2010's annexes. Submitting the PES early avoids leaving it until the final stage.

From application to definitive inclusion

1. Define the scope. Identify the list, main functionality and, for qualification, families and category. If no family fits, identify “Other tools” for CCN review.
2. Submit and resolve application issues. The CCN issues the start notification, COM-INI, identifying the file and starting the procedure's deadline.
3. Have the proposed DS reviewed where applicable. The result of the proposed Security Target review (RRPDS) communicates whether the proposed scope meets catalogue requirements before certification is completed. It does not itself grant qualification.
4. Provide certification or evaluation results. The CCN reviews RFS coverage and cryptography, produces the Technical Inclusion Report (ITI) and communicates its result (RITI). Missing requirements lead to further evidence or tests.
5. Complete the entry and PES. After a favourable RITI, provide the product description, image and any outstanding PES. Inclusion may be provisional for a maximum of six months.
6. Complete definitive inclusion. The CCN reviews the PES, requests corrections where needed and publishes it as a series 1000 guide. Support, evidence and renewals must then be maintained.

This sequence applies to qualified products. Conformity and Governance follows section 5. Where a PES is not applicable, the guide permits definitive inclusion without it.

Procedure deadlines and listing validity are different

These deadlines are procedural conditions, not a delivery promise. Failure to submit the evidence within the deadline leads to closure and a new application against the RFS and authorised algorithms then in force.

Renewals, versions and commercial continuity

On-premises renewal requires continued security support, certification less than five years old, current RFS compliance and no uncorrected critical vulnerabilities. Support is evidenced through manufacturer documentation or identified public evidence. Updated vulnerability analysis may be required.

Cloud renewal requires a complete new application and a new CICLON evaluation. Conformity and Governance also requires the information and evidence of a new inclusion.

For on-premises scope extensions, the CCN reviews the IAD and determines which functions need further testing. Major changes may make this route unsuitable. Cloud does not use this version-extension procedure: CICLON incorporates ongoing monitoring.

Expiry, loss of support, unfavourable evidence or critical vulnerabilities can jeopardise listing. For CICLON, the guide links a critical vulnerability to zero PGC and exclusion. Badges must identify the specific product and list, and must be removed following exclusion.

How CYBSER helps

We manage the CPSTIC inclusion process: defining the scope, preparing the necessary documentation, carrying out the evaluation and monitoring the product during inclusion to keep the latest version in the catalogue. We facilitate the process at every step so your team only has to step in where it really matters.

If you already hold certification or have an open application, we start by reviewing what can be reused and what needs updating.

Source and scope

Based on CCN-STIC 106, October 2026 edition, particularly sections 4–7 of the Spanish edition. Consult the official CCN-STIC 106 guide in English (PDF), the Spanish edition (PDF) and the official application forms before applying. The guide does not establish general transition arrangements for open applications: confirm their treatment with the CCN.