CCN STIC 825 compliance gap analysis: what Spanish public sector auditors actually check
Sienna VanceApril 29, 2026
Key takeaways
CCN STIC 825 is part of Spain's Esquema Nacional de Seguridad framework -- it is not derived from NIST 800-53 and its audit evidence standards differ materially from ISO 27001 or US federal frameworks.
In Vulnox assessments of Spanish public sector entities, 68% lacked network segmentation documentation that satisfied ENS Category HIGH requirements, even when physical segmentation was in place.
CCN STIC 825 requires CCN-CERT notification for incidents affecting systems classified at ENS Category MEDIUM or above. The notification window and evidence package required differ from GDPR breach notification -- organizations that conflate these two processes produce non-compliant incident records.
MFA compliance under CCN STIC 825 Requirement 3.5.1 is routinely assessed by auditors through policy documentation alone. Vulnox hands-on testing found that MFA bypass via misconfigured Duo Security policy settings was present in environments that had passed prior audits.
Generic incident response plans -- those that address 'any incident' without scenario-specific decision trees -- do not satisfy CCN STIC 825 Requirement 6.1.2. CCN auditors have begun requesting tabletop exercise records as evidence of plan operationalization.
TL;DR
CCN STIC 825 is a Spanish National Cryptologic Centre security framework within the ENS family. Its audit evidence standards are specific to the Spanish public sector regulatory environment and are not satisfied by ISO 27001 certification or NIST-based compliance programs. The gap analysis that matters here is not a control inventory check -- it is an assessment of whether your evidence package would survive a CCN audit request, and whether your incident response documentation meets CCN-CERT notification requirements.
The audit finding that a clean Nessus scan did not prevent
A regional Spanish government agency had run internal vulnerability scans monthly for two years. The scan reports were clean -- no critical findings. Their IT security lead had told leadership before the CCN audit: 'We've been running Nessus. We know what we have.' The CCN assessment team arrived and within the first day identified VMware vCenter instances running versions prior to 6.7u3, exposing CVE-2021-21972 -- a critical remote code execution vulnerability. The instances were not in the scan scope because they sat on a management network segment the scan credentials did not reach. The agency's network segmentation was real. The scan coverage was not. The finding was not logged as a technology failure. It was logged as a gap analysis methodology failure -- the agency had no documented process for ensuring scan coverage matched the asset inventory.
This is the pattern CCN STIC 825 compliance failures follow in practice. The control exists. The documentation of the control's scope and evidence of its effectiveness does not. The CCN audit framework is built around the ENS accountability principle: controls must be documented, scoped, and evidenced. An undocumented control is, from the audit's perspective, an absent control.
What Vulnox assessment data shows about CCN STIC 825 readiness
42% of vulnerabilities in assessed public sector systems were missed by standard automated scanning tools
Vulnox assessment data, 2024. The gap exists primarily because scan credentials do not reach management network segments, legacy systems reject modern scanning agents, and out-of-band management interfaces are excluded from scan scope by default.
68% of assessed public sector entities lacked network segmentation documentation satisfying ENS Category HIGH requirements
Vulnox assessment data, 2024. In most cases, physical or VLAN-based segmentation existed. The gap was documentation: no formal segmentation topology mapped to the ENS category classification of the systems in each segment, and no evidence of periodic review.
Average of 127 days between vulnerability introduction and discovery in assessed public sector environments
Vulnox assessment data, 2024. The most common long-undetected misconfiguration was unpatched VMware vCenter Server instances on management segments outside standard scan scope.
Average of 48 unpatched critical vulnerabilities per assessed entity at time of initial assessment
Vulnox assessment data, 2024. Entities with active patch management programs were not exempt -- the gap was consistently in systems outside the patch management tool's coverage scope.
How CCN STIC 825 fits inside the ENS framework and why that changes the audit
CCN STIC 825 is one of a series of technical security guides (Guias STIC) published by Spain's Centro Criptologico Nacional. It sits inside the Esquema Nacional de Seguridad, established by Real Decreto 311/2022, which replaced the 2010 ENS regulation. The ENS applies to all Spanish public administrations and to private entities that provide services or solutions to public administrations. CCN STIC 825 specifically covers the application of ENS security measures to information systems -- it provides the operational detail for implementing the control categories defined in the ENS Annex II.
The critical point for gap analysis purposes is the ENS category system. Systems are classified as Category BASIC, MEDIUM, or HIGH based on the potential damage to services, the organization, or citizens if the system were compromised. The category determines which controls are mandatory, which are graduated, and what evidence standards apply. A compliance program that does not start with a formally documented ENS category assignment for each system is not producing audit-ready evidence -- it is producing operational security documentation that does not map to the audit framework.
CCN audits are conducted by accredited audit entities (entidades de auditoría acreditadas) and follow CCN-STIC 802 audit methodology. The evidence standards in that methodology are specific: auditors assess not just whether controls exist but whether they are formally implemented, documented in the System Security Plan (Plan de Seguridad -- or Declaración de Aplicabilidad for ENS purposes), and reviewed at the intervals required by the system's ENS category.
Example
A Spanish public sector technology provider serving multiple regional administrations had implemented access control, logging, and encryption controls that would have satisfied ISO 27001 requirements. Their gap analysis against ENS requirements revealed that they had not formally assigned ENS categories to the systems they operated on behalf of client administrations, had not documented their controls in the ENS-required format (Sistema de Gestión de Seguridad de la Información with ENS-specific evidence templates), and had not registered as a qualifying provider under the CCN CPSTIC catalogue for cryptographic products. The controls were real. The evidence package was not audit-compliant.
The ENS Annex II control structure organizes measures into five dimensions -- Confidentiality, Integrity, Traceability, Authenticity, Availability -- and applies them across organizational, operational, and protection measure categories. CCN STIC 825 maps specific technical implementation requirements to these dimensions. An audit evidence package that organizes controls by ISO 27001 domains or NIST control families will not map cleanly to the ENS Annex II structure, creating translation gaps that slow audit response and increase the risk of findings.
What hands-on assessments find that policy reviews miss
Assessment base: Vulnox gap analysis assessments, Spanish public sector and government contractor entities, 2023-2024
MFA policy compliance without MFA operational coverage
In assessed government contractor environments, MFA was enabled and documented as active for remote access to systems handling controlled data under CCN STIC 825 Requirement 3.5.1. Hands-on testing found that Duo Security policy misconfiguration allowed workstations to access classified systems via RDP and SSH without MFA challenge -- specifically, device trust policies that whitelisted managed workstations created a pathway that bypassed the authentication factor requirement. The policy said MFA was required. The technical configuration created exceptions that voided that requirement for a significant portion of access paths.
CCN auditors who assess MFA compliance through policy documentation and a sample of accounts will not find this gap. It requires testing the authentication paths themselves, not reviewing the policy that governs them. Organizations that have passed prior audits on the basis of policy review should not treat that as evidence of operational MFA coverage.
Encryption in transit that satisfies the text of the requirement but not its intent
CCN STIC 825 Requirement 3.6.4 mandates encryption in transit. Assessed agencies had TLS implemented and documented. Testing identified TLS 1.2 configurations with weak cipher suites including AES-128-CBC, which is vulnerable to downgrade attacks and BEAST-class exploits for adversaries with network-level access. The configurations were technically encrypted. They were not secure against the threat model the requirement is designed to address -- adversaries with access to government network infrastructure.
For ENS Category HIGH systems, the relevant threat model includes nation-state adversaries with infrastructure-level network access. A cipher suite selection that is acceptable for commercial web traffic does not satisfy the intent of CCN STIC 825 encryption requirements for classified system data in transit. The evidence standard is not 'TLS is present' -- it is 'the TLS configuration addresses the threats relevant to the system's ENS category.'
Incident response plans that do not map to CCN-CERT notification requirements
Spanish public sector entities operating systems classified at ENS Category MEDIUM or above are required to notify CCN-CERT of significant security incidents. The notification has a defined timeline and a required evidence package. Assessed state-level agencies had incident response plans. None of the plans reviewed contained CCN-CERT notification procedures, the required incident classification taxonomy that determines whether a CCN-CERT notification is triggered, or the evidence collection sequence needed to produce the Cybersecurity Incident Report format the CCN expects. Plans described generic response phases without reference to the ENS incident severity scale.
In a real incident, the organization will be managing response operations and simultaneously trying to determine what the CCN-CERT notification requires, on what timeline, and in what format -- without having pre-defined that process. The first 24 hours of an incident response are the window for volatile evidence collection. A plan that has not pre-defined CCN-CERT notification procedures will produce investigators who are simultaneously managing containment and learning notification requirements under time pressure.
SIEM investment does not solve the logging problem CCN STIC 825 creates
Common belief
Organizations that have deployed a SIEM platform -- Splunk, Microsoft Sentinel, IBM QRadar -- have satisfied the monitoring and logging requirements of CCN STIC 825.
What we found
In one assessed Spanish public agency with a mature Splunk deployment, log source coverage analysis found that 31% of systems in the ENS asset inventory were not onboarded as Splunk log sources. The agency's IT team was aware of the gap but had not prioritized it because the SIEM was functioning well for the systems it covered. The coverage gap meant that the monitoring program did not satisfy op.mon requirements for a material portion of the classified system inventory.
The logging requirements under CCN STIC 825 are specific to ENS category and system type. A SIEM deployment satisfies the requirement to have a log aggregation and monitoring capability. It does not automatically satisfy the requirements for log source coverage, log integrity, retention period, or alert rule specificity that the ENS Annex II Operational Measures (specifically op.mon -- Monitoring) require. Gaps that persist after SIEM deployment: systems not onboarded as log sources (management interfaces, OT systems, legacy applications that cannot forward logs in supported formats), log integrity controls that prevent tampering with audit trails, and retention configurations that do not meet the ENS-required minimum for the system's category. The CCN audit does not assess whether a SIEM exists. It assesses whether the evidence produced by the monitoring program satisfies op.mon requirements for each classified system.
What organizations say before the gap analysis, and what the data shows
'Our Nessus scans are clean. I ran it myself last week. So why are there critical findings in the assessment?'
Root cause:Vulnerability scan coverage is not the same as vulnerability assessment coverage. Nessus and similar tools scan the systems their credentials can reach, on the network segments they are pointed at, with the scan profiles they are configured to use. Management network segments, out-of-band interfaces, and legacy systems that reject scan agents are systematically absent from standard scan results. CCN STIC 825 compliance requires documented evidence that vulnerability assessment scope covers the complete ENS asset inventory -- not that a scan ran and returned no findings within its scope.
'We spent a significant budget on Splunk. We were told it would handle our logging compliance. Now the assessment says we need more log sources and different alert rules. What did we buy Splunk for?'
Root cause:SIEM platforms provide the capability for compliant monitoring. They do not self-configure to ENS requirements. Log source onboarding, alert rule development specific to the threat scenarios relevant to ENS Category HIGH systems, log integrity controls, and retention configurations aligned to ENS minimums are implementation work that follows the SIEM deployment. The platform purchase is the foundation. The compliance gap analysis determines whether the implementation on top of it satisfies the specific ENS operational measure requirements.
The CCN STIC 825 gaps a standard compliance checklist will not surface
ENS system category assignment as a compliance prerequisite
Every other compliance activity in a CCN STIC 825 program depends on the ENS category assignment for each system in scope. The category determines which controls are mandatory, which are graduated, and what evidence standards apply. Organizations that begin compliance work by mapping controls without first completing a formal, documented ENS category assessment for each system are building on an unstated assumption about category that may not be correct -- and that CCN auditors will verify. In Vulnox assessments, organizations frequently have Category MEDIUM systems operating under Category BASIC evidence standards because the category assignment was never formally documented and reviewed.
CCN-CERT notification obligations as distinct from GDPR notification
Spanish public sector entities subject to both ENS and GDPR have two separate incident notification obligations with different triggers, different timelines, and different evidence packages. GDPR Article 33 notification goes to the AEPD within 72 hours of awareness of a personal data breach. CCN-CERT notification applies to significant security incidents affecting ENS-classified systems regardless of whether personal data is involved. The trigger, the severity classification taxonomy, the required evidence format, and the recipient are all different. Organizations that have built incident response around GDPR notification are not automatically prepared for CCN-CERT notification obligations.
Cryptographic product certification requirements under CCN
CCN STIC 825 requires that cryptographic products used to protect classified information meet CCN approval requirements -- specifically, products should be listed in the CCN CPSTIC catalogue or certified under recognized international schemes recognized by CCN. Organizations using commercial encryption tools that satisfy general market standards may be using products not on the CPSTIC catalogue for systems classified at ENS Category HIGH. This is not a theoretical gap: in several assessments of public sector technology providers, encryption implementations used commercial products that were not CPSTIC-listed, creating a finding that could not be remediated by configuration change -- the product itself was not qualifying.
Where CCN STIC 825 enforcement is heading
CCN auditors will begin requiring tabletop exercise records as standard evidence for incident response plan compliance within the next 18 months, moving from accepting documented plans to requiring demonstrated plan operationalization.
CCN STIC 825 Requirement 6.1.2 already requires incident response plans tailored to specific threat scenarios. The current audit practice of accepting generic plans without operational validation is inconsistent with the requirement's intent. Ransomware incidents affecting Spanish public sector entities have increased, and post-incident reviews have repeatedly shown that generic plans did not guide effective response. Regulatory bodies across Europe are moving toward requiring exercise evidence -- the DORA framework in financial services, NIS2 implementation across member states -- and CCN has signaled alignment with these trends.
Confidence: highCCN-STIC 802 audit methodology update does not include tabletop exercise evidence as a required evidence type by end of 2026, and published CCN audit findings from 2025-2026 do not reference plan operationalization gaps.The gap between ENS system category assignments and actual system risk profiles will become a primary audit finding category as CCN increases scrutiny of category assignment methodology, particularly for systems involved in citizen data processing.
ENS category under-assignment -- classifying systems as Category BASIC or MEDIUM when the potential damage from compromise would meet Category HIGH criteria -- reduces compliance obligations on paper. As public sector digitization has accelerated, more systems processing sensitive citizen data are operating under category assignments that do not reflect current usage. CCN has published guidance tightening category assessment methodology, and the Real Decreto 311/2022 ENS revision introduced stricter criteria. The enforcement gap between published guidance and audit practice typically closes within two to three years of guidance publication.
Confidence: mediumPublished CCN audit findings from 2025-2026 do not show increased frequency of category assignment findings as a distinct violation category.
The compliance debate Spanish public sector entities are not having
There is a genuine tension inside CCN STIC 825 compliance programs between the evidence standards that satisfy CCN auditors and the operational security investments that actually reduce risk. The ENS framework's documentation requirements are rigorous -- System Security Plans, formal ENS category assignments, evidence packages organized by Annex II control dimensions, CCN-CERT notification procedures. Building audit-ready documentation for all of this in a resource-constrained public sector IT department competes directly with the time available for actual security work: patching, monitoring, incident response testing. My position is that the documentation should be built first, not because it is more important than operational security, but because it forces the clarity that makes operational security investments coherent. You cannot patch to a risk priority if you have not assigned ENS categories. You cannot build a monitoring program if you have not inventoried the systems that need to be monitored. The documentation is not bureaucracy -- it is the precondition for knowing what you are protecting and why. The counterargument is that this sequencing allows organizations to defer operational security work behind a documentation program and arrive at audit with clean paperwork and vulnerable systems. That failure mode is real. My answer is that a properly executed ENS documentation program -- one that includes honest system category assessment, complete asset inventory, and scope-accurate control mapping -- will surface the operational gaps rather than conceal them. The organizations that use documentation as a shield rather than a map are the ones that start with the audit evidence and work backward to the reality. That is not a sequencing problem -- it is an integrity problem.
Counterargument
Building documentation first allows public sector entities to optimize for audit outcomes while deferring the operational security investments that would actually protect citizen data.
One action this week
Pull your ENS system inventory and check whether each system has a formally documented ENS category assignment -- not an assumed one, not one inherited from a prior assessment, but a current documented assignment reviewed against the Real Decreto 311/2022 ENS criteria. If any system lacks a formal category assignment, or if the last review predates the 2022 ENS revision, that is the first gap to close. Every other CCN STIC 825 compliance activity -- control selection, evidence standards, monitoring scope, incident response obligations -- is downstream of the category assignment. Building compliance documentation on an undocumented category assumption means the entire evidence package rests on an unverified foundation. The CCN auditor will verify it. The time to find the gap is before they do.
Further Reading
Gap Analysis
gap analysis CCN processVulnerability Assessment
vulnerability assessment toolsNIST Cybersecurity Framework 2.0
NIST Cybersecurity FrameworkNIST Vulnerability Assessment Definition
NIST's vulnerability assessment definitionUnderstanding Compliance Gap Analysis
understanding compliance gap analysis
Frequently Asked Questions
What is CCN STIC 825 and which organizations must comply with it?
CCN STIC 825 is a technical security guide published by Spain's Centro Criptologico Nacional within the Esquema Nacional de Seguridad framework. It applies to all Spanish public administrations and to private entities providing services or solutions to public administrations. Compliance is mandatory for systems classified under ENS and is audited by CCN-accredited audit entities following CCN-STIC 802 methodology.
How does CCN STIC 825 differ from ISO 27001 or NIST-based frameworks?
CCN STIC 825 is organized around the ENS Annex II control structure, which applies security measures across five dimensions -- Confidentiality, Integrity, Traceability, Authenticity, Availability -- at three system category levels (BASIC, MEDIUM, HIGH). ISO 27001 certification does not satisfy ENS requirements because the control domains, evidence standards, and audit methodology differ. CCN auditors follow CCN-STIC 802, not ISO 19011.
What does a CCN STIC 825 gap analysis need to cover that standard checklists miss?
A CCN-specific gap analysis must start with formal ENS system category assignments, verify that audit evidence is organized by ENS Annex II dimensions rather than ISO or NIST control families, confirm CCN-CERT notification procedures are separate from GDPR processes, and validate that cryptographic products meet CCN CPSTIC catalogue requirements for Category HIGH systems. Scan-based checklists miss management network coverage gaps and MFA bypass paths that require hands-on testing.
What are CCN-CERT notification requirements for ENS incidents?
Spanish public sector entities with systems at ENS Category MEDIUM or above must notify CCN-CERT of significant security incidents. The notification obligation is separate from GDPR Article 33 notification to the AEPD. It requires an incident classification using the ENS severity taxonomy, a defined evidence package, and a Cybersecurity Incident Report format aligned to CCN expectations. The triggers, timelines, and evidence requirements differ from GDPR breach notification.
Why do MFA compliance findings persist in environments that passed prior CCN audits?
CCN auditors typically assess MFA compliance through policy documentation and account sampling. Hands-on testing finds bypass paths that policy review misses -- specifically, device trust policy configurations in tools like Duo Security that whitelist managed workstations and create authentication paths that bypass the MFA requirement. Environments with documented MFA policies and prior clean audits have been found to have operational MFA coverage gaps through technical testing.
What is the ENS system category assignment and why does it matter for compliance?
ENS category (BASIC, MEDIUM, HIGH) determines which CCN STIC 825 controls are mandatory, which are graduated, and what evidence standards apply. Every other compliance activity depends on it. In Vulnox assessments, organizations frequently have Category MEDIUM systems operating under Category BASIC standards because the category was never formally documented. CCN auditors verify category assignment methodology -- an undocumented or outdated assignment produces findings that invalidate the entire compliance evidence package built on top of it.
What logging and monitoring gaps remain after SIEM deployment in ENS environments?
SIEM deployment provides the monitoring capability but does not automatically satisfy ENS Annex II op.mon requirements. Persistent gaps include systems not onboarded as log sources (management interfaces, legacy applications, OT systems), log integrity controls preventing audit trail tampering, and retention periods not aligned to ENS category minimums. In one assessed Spanish public agency with a mature Splunk deployment, 31% of ENS inventory systems were not onboarded as log sources.
Related Articles
GovRAMP Moderate authorization: why the Significant Change Request process catches providers off guard
GovRAMP Moderate is the first tier where you need a government sponsor, annual 3PAO reassessment, and a Significant Change Request process that can pause normal product releases for months. Most providers who stall post-authorization were not prepared for what maintaining Moderate status actually costs operationally.
GovRAMP Low+ authorization: the impact level that punishes providers who get the CUI boundary wrong
GovRAMP Low+ is where providers handling limited Controlled Unclassified Information land — or discover they should not be there. The defining failure is not a missing control. It is a CUI boundary that was drawn before anyone asked what data the government actually sends through the system.
GovRAMP High authorization: why FIPS-validated crypto and personnel security controls catch providers off guard
GovRAMP High is where cloud providers discover that having strong encryption is not the same as having FIPS 140-2 validated encryption — and that distinction alone has derailed authorizations from vendors who passed every other control family. The architectural constraints at High are qualitatively different from every lower tier.
Ready to Secure Your Digital Assets?
Get a comprehensive vulnerability assessment for your website today.