CICLON methodology

CCN-STIC 2010: cloud product evaluation methodology

CCN-STIC 2010 defines the CICLON methodology for cloud products: actors, minimum evidence, preparation, evaluation phase, monitoring phase and calculation of the Composite Assurance Percentage (PGC).

What CCN-STIC 2010 is

CCN-STIC 2010 is the guide that defines the Cloud Product Evaluation Methodology (CICLON). It exists to evaluate cloud-deployed services, where more traditional methodologies do not fit because they rely on physical access to the product or on a static version throughout the process.

This is where the required documentation, each actor's role, the structure of the initial evaluation and the later monitoring obligations are defined in practical terms.

What it regulates inside CICLON

It regulates the full process: evaluation preparation, Security Target analysis, service-architecture review, access to the environment, functional tests, cryptographic analysis, penetration testing, continuous monitoring and PGC calculation.

Quick answer

What it is

The CCN guide that defines how cloud products are evaluated and monitored under CICLON.

Who should read it

Manufacturers and applicants evaluating a SaaS, PaaS or IaaS product for the Spanish public sector.

What it clarifies

Minimum evidence, actors, evaluation stages, monitoring logic and PGC calculation.

When it becomes useful

When you are preparing the evaluation of your cloud product and need a clear view of the process.

Actors involved

  • Applicant: formally submits the cloud product evaluation request.
  • Manufacturer: designs, develops and maintains the product under evaluation.
  • Evaluation laboratory: executes the evaluation as an accredited and authorised entity.
  • CCN: validates the issued reports and the resulting assurance percentage.

Minimum required evidence

  • Security Target.
  • Favourable Security Target validation by CPSTIC.
  • Service Architecture Document.
  • Software Bill of Materials in CycloneDX format.
  • ENS certification, or an equivalent certification recognised under ENECSTI, for the cloud provider.
  • Accessible evaluation environment and technical support throughout the process.

Evaluation preparation

  • Select an ENECSTI-accredited laboratory authorised by CCN.
  • Agree scope, effort and environment based on the Security Target, the architecture document and the SBOM.
  • Prepare the request, evidence, environment and laboratory engagement.
  • Provide ENS or equivalent certification and favourable Security Target validation.
  • Pass CCN review of the request before the evaluation file is opened.

What changes compared with other routes

CICLON does not assume a static product. The guide separates an initial evaluation from periodic monitoring, because cloud services evolve over time. The result is not just a report, but a PGC that changes as the monitored product changes.

Evaluation phase

  • Stage 1: Security Target analysis.
  • Stage 2: Service Architecture Document analysis.
  • Stage 3: access to and configuration of the test environment.
  • Stage 4: functional testing for direct and indirect checks.
  • Stage 5: cryptographic analysis of communications.
  • Stage 6: TOE penetration testing under CCN-ITC-003.
  • Stage 7: calculation of the Evaluation Assurance Percentage (PGE).
  • Stage 8: generation of the Technical Evaluation Report (ETR).

Monitoring phase

  • SBOM analysis to detect known public vulnerabilities.
  • Verification that integration components remain evaluated under CICLON.
  • Review of certifications applicable to the cloud provider.
  • Calculation of the Monitoring Assurance Percentage (PGM).
  • Calculation of the Composite Assurance Percentage (PGC).
  • Generation of the Monitoring Technical Report (MTR).

What the laboratory really reviews

The work is not limited to testing the service. The methodology requires review of the Security Target, the architecture declared in the DAS, SBOM traceability, real access to the environment and the robustness of communications, in addition to functional testing and penetration testing.

Evaluation result

The final verdict is expressed through the Composite Assurance Percentage (PGC), which integrates evaluation and monitoring. If non-conformities appear during the process, the verdict becomes FAIL and the PGC is 0. The vendor must resolve the non-conformities, and the laboratory verifies against the corrected version that the identified issues have been resolved.

Before starting CICLON

1. Cloud route confirmed

Confirm that the product should follow CICLON rather than LINCE.

2. Service and scope defined

Delimit the TOE, operational environment, flows and relevant dependencies.

3. Evidence prepared

Have the Security Target, architecture document, SBOM, the cloud provider certification and test environment ready.

4. Monitoring capability

Make sure the service can update the libraries and integrations it relies on when an issue appears.

How CYBSER helps

We prepare the Security Target, support the DAS, review the documentation and carry out the evaluation end to end.

We handle the full process so your team can stay focused on the product.

Assess CICLON fit See more CCN-STIC guides

View the official guide

If you need to review the full document or confirm a specific point in the methodology, you can consult the official CCN guide here.

View CCN-STIC 2010 →

Frequently asked questions about CCN-STIC 2010

Does CCN-STIC 2010 replace LINCE for cloud products?
Yes. The guide itself explains that traditional methodologies such as LINCE, CC or EUCC do not fit cloud environments because they rely on physical access to the product or on a static version throughout the evaluation.
What minimum evidence does CICLON require before evaluation starts?
At a minimum it requires the Security Target, its validation by CPSTIC, the Service Architecture Document, a CycloneDX SBOM file, ENS or an equivalent certification, and an evaluation environment accessible to the laboratory.
Does CICLON end with the initial evaluation?
No. The methodology combines an initial evaluation phase and a periodic monitoring phase. The final result is expressed through the Composite Assurance Percentage (PGC), which is updated through monitoring iterations.
What makes CICLON different from other routes?
It is designed for cloud-deployed products. The guide introduces service-architecture review, cryptographic analysis of communications and continuous monitoring of dependencies, integrations and cloud-provider certifications.

Do you need to review whether your cloud product is ready for CICLON?

We review scope, evidence, architecture and monitoring before the evaluation starts.