complianceboe-a-2022-7191cybersecurity-compliancegap-analysisspanish-enterprisesrisk-management

ENS compliance under Royal Decree 311/2022: a gap analysis playbook for private suppliers

Geert WarmenbolApril 29, 2026

ENS compliance under Royal Decree 311/2022: a gap analysis playbook for private suppliers

TL;DR

BOE-A-2022-7191 is the publication identifier for Royal Decree 311/2022, which updates Spain's Esquema Nacional de Seguridad (ENS). It applies to all Spanish public sector entities and to private companies that supply services or systems to public administrations — cloud providers, managed service providers, critical infrastructure operators, and their subcontractors.
The most expensive mistake private suppliers make is categorizing their systems as Basic when the data they process warrants Medium. Self-assessment is only permissible for Basic. Medium and High require independent certification by an ENAC-accredited body. Wrong categorization means your compliance program is built on the wrong control set.
The three ENS gap areas Vulnox finds most consistently in private supplier environments: outdated or missing security plans that do not reflect current architecture, incident reporting procedures that have never been tested against CCN-CERT notification requirements, and cloud configurations — particularly logging and access segmentation — that do not meet Annex II technical requirements. (Vulnox assessment data, 2024–2025)
ISO 27001 certification does not satisfy the ENS Medium or High certification requirement. The frameworks overlap significantly in control domains, but ENS has mandatory categorization methodology, Spanish-authority incident reporting obligations, and ENAC-accredited audit requirements that ISO 27001 does not cover.
The April 2024 transition deadline for Royal Decree 311/2022 has passed. Suppliers still operating under the 2010 ENS version are out of compliance. The 2022 update introduced explicit cloud security and supply chain controls that did not exist in the prior version — these are not incremental changes.

How ENS compliance becomes your problem six weeks before contract renewal

A 90-person managed services company in Valencia has been providing IT infrastructure support to a regional autonomous community for three years. The contract is up for renewal. Procurement sends over the updated vendor requirements. Line four reads: ENS certification at Medium level, ENAC-accredited, valid certificate required before contract execution. The company has solid internal security practices. Their ISO 27001 certification is current. Nobody has ever mentioned ENS to them. The contract renewal is in eight weeks.

Turning point:

This is not a hypothetical — Vulnox has seen this sequence play out in engagements with private suppliers who had no idea ENS applied to them until a procurement team made it a contract condition. The ISO 27001 work was real and it helps, but it does not substitute for ENS Medium certification. The categorization has to happen, the security plan has to be in ENS format, and the audit has to be conducted by an accredited body. Eight weeks is not enough time to do this properly. The companies that navigate it well are the ones that identified the ENS requirement 12 to 18 months before their contract came up for renewal — not the ones scrambling to find an ENAC-accredited auditor after procurement asked.

The assumption that produces the wrong starting point

Common belief

The standard assumption when private companies first encounter ENS is that categorization is a formality — that you pick a level, map to it, and get audited. Most assume Basic is the safe default: less work, self-assessment permissible, two-year cycle. The logic is that Basic is a lower bar, so it is easier to achieve and safer to claim.

What we found

In Vulnox gap analysis engagements with private ENS suppliers conducted in 2024 and 2025, undercategorization was the single most common pre-engagement finding. Organizations that had conducted their own pre-assessment arrived at Basic in cases where Vulnox's formal categorization methodology produced Medium. The trigger in every case was the confidentiality dimension applied to personal data of public service beneficiaries — a data type these companies were handling but not counting as the relevant input for categorization. (Vulnox assessment data, 2024–2025)

This produces the wrong answer in most real supplier scenarios. Categorization is not a default — it is a mandatory formal process applying five security dimensions (confidentiality, integrity, availability, authenticity, and traceability) to each system in scope. The level is determined by the highest severity rating across those dimensions, not by what feels manageable. A managed services company handling personal data of public service users, or a cloud provider storing government documents, will almost always reach Medium when the categorization is done honestly. Claiming Basic when Medium is correct is not a planning shortcut — it is a compliance failure that invalidates the entire self-assessment.

The numbers behind the compliance gap

April 2024

The deadline by which all entities in scope were required to achieve full compliance with Royal Decree 311/2022. Suppliers still operating under certification issued under the 2010 ENS version after this date are non-compliant regardless of how recently that certificate was issued. The 2022 update introduced new mandatory control areas — cloud security, supply chain risk — that the 2010 version did not address. (Royal Decree 311/2022, Official State Gazette)

3–6 months

Typical timeline from gap analysis kickoff to ENS Medium certification for organizations with reasonably mature existing practices, per Lazarus Alliance ENS audit data. Organizations starting without security documentation or formal risk management processes should plan for nine to twelve months. (Lazarus Alliance ENS audit program data, published 2025)

2 years

Maximum self-assessment cycle for Basic category systems under the Declaration of Conformity pathway. Medium and High systems require mandatory ENAC-accredited independent audits with no self-assessment option. Organizations that miss the renewal window for Medium or High certificates have no grace period — the certificate lapses and contract eligibility is affected immediately. (Royal Decree 311/2022, Article 34 and Annex III)

What the gap analysis actually uncovers

Assessment base: Based on ENS gap analysis and certification readiness engagements conducted by Vulnox in 2024 and 2025, covering private sector suppliers to Spanish public administrations in managed services, cloud infrastructure, and professional services sectors, ranging from 50 to 400 employees.

Security plans that describe systems that no longer exist

The Plan de Seguridad is a core ENS documentation artifact. It must describe the system architecture, the controls implemented, the residual risks, and the responsible parties. In Vulnox assessments of private ENS suppliers in 2024 and 2025, the majority of incoming security plans described the system as it existed at the time of the previous assessment — often two to three years prior. Cloud migration, service expansion, infrastructure changes, and new integrations had been implemented without updating the plan. Stage 1 documentary audits flag this immediately. A security plan that does not match the live system is not a documentation gap — it is an audit failure point that delays certification and requires a full plan revision before Stage 2 can proceed. (Vulnox assessment data, 2024–2025)

Incident reporting procedures with no tested path to CCN-CERT

ENS mandates incident reporting to the competent authority — for most private suppliers, this means CCN-CERT, the National Cryptologic Centre's incident response capability. In every Vulnox engagement where we tested incident response procedures against ENS reporting requirements, the procedures specified what to report internally but had no documented workflow for external notification to CCN-CERT, no designated responsible person, and no record of the notification having ever been tested. This is not a gap that surfaces in a table-top exercise unless the exercise explicitly includes the CCN-CERT notification step. Auditors check for this specifically because it is a regulatory obligation with defined timeframes, not a best-practice recommendation. (Vulnox assessment data, 2024–2025)

Cloud logging configurations that fail Annex II traceability requirements

Royal Decree 311/2022 added explicit cloud security requirements that the 2010 version did not contain. Annex II's traceability dimension requires that audit logs capture sufficient detail to reconstruct events and support incident investigation. In Vulnox cloud configuration reviews conducted as part of ENS gap analyses, the most common failure is log retention periods that do not meet the timeframes needed for the system's category level, combined with missing logging on privileged access events and administrative API calls. These are not hard to fix, but they are consistently absent in environments where the cloud infrastructure was deployed before the 2022 update and was never reviewed against the revised requirements. (Vulnox assessment data, 2024–2025)

How ENS categorization actually works — and why it determines everything downstream

Every other compliance decision in an ENS program flows from the categorization. The security measures you need to implement, whether you can self-assess or need an accredited auditor, how often you need to re-certify, and what your security plan must contain — all of it is determined by whether your system is Basic, Medium, or High.

Categorization applies five security dimensions to each information system in scope: confidentiality, integrity, availability, authenticity, and traceability. Each dimension is scored on a three-point scale corresponding to the potential impact of a failure: low (Basic), medium (Medium), or high (High). The final category of the system is the highest score across all five dimensions. You cannot average them down or negotiate the result.

The most common categorization error in private supplier environments is treating the five dimensions as abstract compliance questions rather than as a formal risk analysis. Teams that answer 'what level of impact would a breach have?' without reference to the specific data types, user populations, and downstream consequences of their particular system will systematically undercategorize. The correct input for the confidentiality dimension, for example, is not 'do we handle sensitive data?' — it is 'what is the specific type of data, who are the affected individuals, and what would be the consequence to those individuals of unauthorized disclosure?' For a managed services provider processing health data of public healthcare users, that answer reaches High confidentiality, which floors the entire system categorization at High regardless of what the other dimensions score.

Medium and High systems cannot be self-assessed. The Declaration of Conformity pathway — a biennial self-assessment — applies only to Basic. Medium and High require a two-stage audit by a certification body accredited by ENAC (Entidad Nacional de Acreditación): a Stage 1 documentary review followed by a Stage 2 on-site technical audit. Achieving certification under the wrong category, then having it corrected during an audit, is not recoverable in a short timeframe.

Example

One private cloud hosting provider Vulnox assessed in 2024 had self-certified as Basic for three consecutive cycles under the 2010 ENS version. Their categorization rationale cited availability as the primary dimension and scored it Low because their SLA recovery time was under 24 hours. What they had not applied to the categorization was the confidentiality dimension for personal data of the public service users whose records were hosted on their platform. When Vulnox ran the formal categorization methodology, the system reached Medium on confidentiality, which immediately moved the entire system to Medium — requiring an ENAC-accredited audit they had never undergone and a security plan format they had never produced.

The CCN (Centro Criptológico Nacional) publishes a suite of Technical Security Instructions (Instrucciones Técnicas de Seguridad, ITS) that provide implementation guidance for specific ENS requirements — including one dedicated to auditing (ITS de Auditoría), one for incident notification, and one for the security status report. These are not optional guidance documents — they are referenced directly in Royal Decree 311/2022 and define the procedural requirements that auditors check. Organizations that read the decree without reading the supporting ITS documents will have gaps in their security plan that are visible at Stage 1.

What clients say before the gap analysis versus what is actually going on

'We're ISO 27001 certified. We assumed that covered ENS. Nobody told us these were different things until the procurement team asked for our ENS certificate number. Now we have four months before the contract needs to be signed.'
Root cause:
ISO 27001 certification addresses a significant proportion of the control domains in ENS Annex II, but it does not satisfy the ENS certification requirement for Medium or High category systems. The two frameworks have different audit processes, different certification bodies, and different regulatory obligations. ENS requires categorization using a specific Spanish methodology, a security plan in ENS format, and an audit by an ENAC-accredited body — none of which are produced by an ISO 27001 audit. The ISO 27001 work reduces the gap analysis workload, particularly on technical controls, but the ISMS documentation it produces does not substitute for an ENS security plan. The four-month timeline is tight but potentially achievable for an organization with mature existing controls, provided the gap analysis starts immediately and the security plan is drafted in parallel with any remediation.
'We did our own gap analysis and we think we're 80% there. We just need someone to sign off on the last 20%.'
Root cause:
Self-assessed gap analyses for ENS consistently miss the same areas: categorization accuracy, security plan format compliance, and the supporting documentation artifacts that auditors check specifically — ITS references, CCN-CERT notification procedures, residual risk acceptance records. The '80% there' figure almost always reflects technical control coverage, not documentation completeness. In Vulnox's experience, organizations arriving with self-assessed gap analysis results are typically 80% on technical controls and 40–50% on the documentation and process artifacts that determine whether Stage 1 passes. The 'last 20%' is usually the harder half.
'We got ENS certified two years ago and our auditor was happy. But that was under the 2010 version. Now procurement is asking for 311/2022 compliance and we don't know what changed.'
Root cause:
Royal Decree 311/2022 introduced control areas that the 2010 version did not contain — most significantly, explicit cloud security requirements and supply chain risk management obligations. An organization certified under the 2010 ENS version that has since migrated infrastructure to cloud or onboarded new technology suppliers has likely introduced control gaps relative to 311/2022 that their prior certification never covered. The transition deadline was April 2024. Recertification under 311/2022 is not a paperwork exercise for these organizations — it requires a fresh categorization, a security plan revision, and an audit against the new control set.

The gap analysis workflow, step by step

Step 1
Establish ENS applicability and contract trigger
Output:
Written confirmation of ENS applicability, the category floor set by the contracting authority, and the certification deadline.
Purpose:
Confirm that ENS applies to your organization and identify which specific contract or service relationship creates the obligation. Review the contract terms for ENS language, the category specified by the public entity, and any deadline for certification.
Step 2
Define system scope
Output:
A scoped system inventory with boundary documentation. Each system listed is a categorization input.
Purpose:
Identify every information system that processes, stores, or transmits data on behalf of the public entity. This includes infrastructure, applications, cloud services, and third-party integrations. Scope creep in this step is expensive — define tightly and document the rationale for any exclusion.
Step 3
Run formal categorization for each in-scope system
Output:
A formal categorization document for each system, with dimension scores, rationale, and the resulting system category (Basic, Medium, or High).
Purpose:
Apply the five ENS security dimensions — confidentiality, integrity, availability, authenticity, traceability — to each system using the scoring methodology in Royal Decree 311/2022 Annex I. Do not self-assess the impact levels without referencing the specific data types, user populations, and downstream consequences for each dimension.
Step 4
Map existing controls to ENS Annex II requirements for the determined category level
Output:
A control gap matrix showing implemented, partially implemented, and missing controls, with evidence status for each.
Purpose:
For each control requirement in Annex II applicable to your category, document whether the control exists, whether it is implemented as required, and whether audit evidence exists. Controls that exist but are not documented do not count for Stage 1.
Step 5
Identify and review the applicable Technical Security Instructions (ITS)
Output:
A checklist of ITS requirements applicable to your system category, with current compliance status for each.
Purpose:
The ITS documents published by CCN define procedural requirements that supplement the Annex II controls. The ITS on auditing, incident notification, and the security status report are directly referenced in the decree and are checked at Stage 1. Organizations that gap-analyze against Annex II alone without reading the ITS will miss procedural requirements.
Step 6
Produce or update the security plan (Plan de Seguridad)
Output:
A complete, current security plan in ENS format, reviewed against the Annex II control set and ITS requirements.
Purpose:
The security plan is the primary Stage 1 audit artifact. It must describe the system architecture as it currently exists, the controls implemented, the risk assessment and residual risks, the responsible parties, and the improvement roadmap. A plan that does not match the live system will fail Stage 1.
Step 7
Test incident reporting procedures against CCN-CERT notification requirements
Output:
A tested incident reporting procedure with documented CCN-CERT notification workflow, responsible person, and timeframe commitments.
Purpose:
Run a tabletop scenario that explicitly includes the external notification step to CCN-CERT. Confirm that a designated responsible person knows the notification procedure, that the contact information is current, and that the timeframe obligations are documented in the procedure.
Step 8
Remediate gaps by priority: documentation before technical controls
Output:
A prioritized remediation plan distinguishing Stage 1 documentation gaps from Stage 2 technical control gaps, with owners and deadlines for each.
Purpose:
Stage 1 is a documentary audit. Non-conformities at Stage 1 delay Stage 2. Prioritize security plan completion, ITS compliance, and evidence documentation before spending time on technical control remediation. Technical gaps that are documented with a remediation plan and timeline are generally handled at Stage 2 — undocumented gaps in the security plan are Stage 1 blockers.
Step 9
Select an ENAC-accredited certification body and schedule Stage 1
Output:
A confirmed Stage 1 audit date with an ENAC-accredited certification body, with all documentation artifacts submitted in advance of the audit window.
Purpose:
Medium and High systems require audit by a body accredited by ENAC. Confirm the body's accreditation scope covers your system category. Schedule Stage 1 only after the security plan is complete and internally reviewed — submitting incomplete documentation extends the timeline.

What organizations miss until an auditor finds it

Supply chain controls for subcontractors and technology providers

Royal Decree 311/2022 introduced explicit supply chain risk requirements that did not exist in the 2010 version. Organizations that have mapped their own controls but have not extended the analysis to their technology suppliers — cloud infrastructure providers, managed detection services, software vendors with access to in-scope systems — have a control gap that auditors specifically look for. ENS does not require your suppliers to be ENS-certified, but it does require that you have assessed their security posture and that the assessment is documented. For cloud providers serving public sector workloads, ENS High certification (which AWS, Microsoft Azure, and Google Cloud have each achieved for their Spanish infrastructure) is the simplest way to satisfy this requirement for that layer.

The security status report requirement

The Technical Security Instruction on the Security Status Report (ITS de Informe del Estado de la Seguridad) requires in-scope entities to submit periodic security status reports to the relevant competent authority. Many private suppliers discover this obligation only during Stage 1 review. The report format, submission frequency, and competent authority vary depending on the type of public administration being served. Organizations that have focused their compliance program entirely on achieving certification have often not established the ongoing reporting workflow that the ITS requires.

What 'continuous monitoring' actually requires in ENS context

ENS references continuous monitoring as an operational requirement, but the practical implication is often misread. Teams treat it as a SIEM deployment question — if logs are being collected, monitoring is covered. The ENS requirement is broader: it encompasses regular review of security measures against the current risk environment, updating the security plan when significant changes occur, and maintaining evidence that the controls documented in the plan are actually operating. An organization that deployed a SIEM three years ago and has not reviewed its security plan since the cloud migration is not meeting the continuous monitoring requirement, regardless of how many alerts the SIEM is generating.

What to do in the right sequence to avoid the common failure modes

Commonly skipped:

Step 3 — testing the CCN-CERT notification workflow — is the most commonly skipped because it feels bureaucratic relative to technical control work. Auditors check it specifically because it is a regulatory obligation with defined timeframes. Organizations that have never run this test will fail it when the auditor asks for evidence.

1Security lead or compliance owner
Before starting any control mapping, run the formal categorization. Use the five-dimension methodology in Annex I, applied to specific data types and user populations — not abstract impact estimates. If the result is Medium or High, plan for an ENAC-accredited audit and a 4–12 month timeline from gap analysis to certification. If you start control mapping against Basic and later discover the correct category is Medium, you will rebuild the work.
Expected outcome
A defensible system category that matches the actual data sensitivity and operational profile of the system, documented with rationale for each dimension score.
2Security lead with technical input from system owners
Produce or update the security plan to reflect the system as it currently exists. This means current architecture diagrams, current control implementations, current risk assessment output, and current residual risk acceptance records. A plan written for the previous architecture is a Stage 1 failure.
Expected outcome
A security plan that an auditor can verify against the live system without finding discrepancies.
3Security lead or incident response owner
Test the incident reporting procedure with a tabletop scenario that explicitly includes the external CCN-CERT notification step. Designate and document the responsible person. Confirm that the contact details for CCN-CERT are current and embedded in the procedure. Record the test and its outcome as evidence.
Expected outcome
An incident reporting procedure with a documented, tested external notification pathway and a named responsible person.
4Cloud or infrastructure team
Review log retention periods and logging coverage against the traceability requirements for your system category. Confirm that privileged access events and administrative API calls are logged, that logs are retained for the required period, and that log integrity is protected. If the cloud provider holds ENS High certification, map their certified control coverage to your Annex II requirements and document what is inherited versus what you are responsible for implementing.
Expected outcome
Log configuration that satisfies Annex II traceability requirements, with documented evidence of coverage and retention.

Pro tip

One thing that saves significant time in practice

If your organization uses a major cloud provider for the in-scope infrastructure, check whether they hold ENS High certification before you begin mapping cloud-layer controls. AWS, Microsoft Azure, and Google Cloud have each achieved ENS High certification for their Spanish infrastructure. That certification documents which ENS Annex II controls the provider has implemented at the infrastructure layer — confidentiality, integrity, availability, authenticity, and traceability measures at the platform level. You can inherit those controls into your gap analysis and focus your remediation effort on the application layer and operational controls that the provider's certification does not cover. Organizations that do not check this first spend time remediating cloud controls that are already covered, while leaving application-layer and procedural gaps unaddressed.

What is coming that will change this calculus

Spain's NIS2 transposition is the single biggest development for ENS-adjacent compliance programs. The draft Law on Cybersecurity Coordination and Governance — approved by the Council of Ministers in January 2025 and pending parliamentary process as of early 2026 — will substantially expand the scope of mandatory cybersecurity requirements beyond the public sector and its direct suppliers. Organizations in energy, transport, healthcare, digital infrastructure, and financial services will be classified as essential or important entities under the incoming law, with risk management, incident reporting, and governance obligations that overlap significantly with ENS requirements.

For private companies currently in scope for ENS only because of a specific public sector contract, NIS2 transposition may make ENS-equivalent requirements mandatory on their own, regardless of public sector relationships. The practical implication is that organizations building ENS compliance programs today should design them with NIS2 compatibility in mind — the control domains, incident reporting infrastructure, and governance documentation they are building for ENS will carry forward into NIS2 obligations rather than being rebuilt from scratch.

The open question that nobody in the Spanish compliance market has settled yet is how the CCN will update the ENS ITS documents to address AI-assisted attacks and AI-powered service delivery. The current ENS technical security instructions were written for a pre-generative-AI threat landscape. Public administrations are beginning to deploy AI-assisted services, and the suppliers who build and operate those services will be in scope for ENS requirements that do not yet have specific AI security guidance. The CCN has historically been responsive in updating guidance documents, but the pace of AI deployment in public services is outrunning the regulatory update cycle.

My actual view on where organizations waste time

This is an opinion. The single biggest waste of time in ENS compliance programs is the sequence error: organizations start mapping Annex II controls before they have finished categorization, and then they do both wrong because they were running in parallel. Categorization determines which controls apply and at what level. If you have not finished categorization, your control mapping is provisional at best and wrong at worst. I have seen organizations spend eight weeks building a control gap matrix against Medium requirements and then discover during a pre-audit review that two of their in-scope systems should be categorized as High, which requires a materially different control set in several dimensions. The restart cost is significant. The fix is straightforward: categorization first, every time, with no parallel workstreams until the categorization document is finalized and internally approved.

What to do this week

Find the contract that triggers your ENS obligation and read the specific language. Note whether a category level is specified by the contracting authority, the certification deadline, and whether your current certification — if you have one — was issued under Royal Decree 311/2022 or the 2010 version. If it is under the 2010 version and you have not recertified, that is your immediate problem. If you do not have a current categorization document that applies the five-dimension methodology to your in-scope systems, produce one before you do anything else. Everything downstream from categorization — control selection, security plan scope, audit format, timeline — is determined by that document. Starting without it is how organizations end up rebuilding their compliance program six weeks before a contract deadline.

Frequently Asked Questions

Does BOE-A-2022-7191 (Royal Decree 311/2022) apply to private companies?

Yes, but with a specific trigger. The ENS applies to private companies when they provide services or supply information systems to Spanish public administrations. Cloud providers, managed service providers, critical infrastructure operators, and their subcontractors are all in scope. A private company that has no contractual relationship with a public entity is generally not subject to ENS, though NIS2 transposition in Spain will expand the scope further for operators in critical sectors.

What is the difference between ENS Basic, Medium, and High certification?

The three levels reflect the potential impact of a security failure on the confidentiality, integrity, and availability of the information system. Basic systems handle low-sensitivity data and permit a self-assessment Declaration of Conformity every two years. Medium and High systems require mandatory independent certification by an ENAC-accredited body. The level is determined by a formal categorization process using the five security dimensions — confidentiality, integrity, availability, authenticity, and traceability — applied to each system in scope. Most private suppliers serving regional government or handling personal data of public service users land at Medium.

What are the most common ENS gaps Vulnox finds in private supplier environments?

The three most consistent findings are: first, systems categorized as Basic when the actual data sensitivity warrants Medium, meaning the organization is self-assessing against the wrong control set; second, missing or outdated security plans (Plan de Seguridad) that do not reflect the current system architecture; and third, incident reporting procedures that exist on paper but have never been tested and do not reference the ENS Technical Security Instruction on incident notification. Cloud configuration gaps, particularly around access segmentation and logging retention, are a close fourth. (Vulnox assessment data, 2024–2025)

How long does ENS Medium certification take for a private company starting from scratch?

Based on Vulnox gap analysis engagements with private suppliers in scope for ENS Medium, the realistic timeline from initial gap analysis to certification is four to eight months for organizations with reasonably mature existing security practices. Organizations with no prior security documentation or formal risk management processes should plan for nine to twelve months. The Stage 1 documentary audit is typically the bottleneck — not because the controls are absent, but because the required documentation artifacts (security plan, risk assessment, operational procedures) need to be produced and internally validated before submission.

How does ENS under Royal Decree 311/2022 relate to ISO 27001?

The frameworks share significant control domain overlap — access control, risk management, incident response, business continuity — but they are not equivalent and do not substitute for each other in Spanish public sector procurement. ISO 27001 certification does not satisfy the ENS certification requirement for Medium or High category systems. ENS has Spain-specific technical security instructions, mandatory categorization methodology, and incident reporting obligations to Spanish authorities (CCN-CERT) that ISO 27001 does not address. Organizations holding ISO 27001 certification can expect to cover a meaningful portion of ENS Annex II controls, but will still need to complete the categorization process, produce an ENS-format security plan, and undergo an ENAC-accredited audit.

What happens if a private supplier fails an ENS audit or lets certification lapse?

The immediate practical consequence is loss of eligibility to continue supplying the relevant public administration under the contract that triggered the ENS requirement. Procurement frameworks in Spain increasingly specify valid ENS certification as a contract condition, not just a preference. Certificate lapse without timely renewal can trigger contract termination clauses. For Medium and High systems, certificates are valid for a defined period and require renewal audits — organizations that treat certification as a one-time event rather than an ongoing program typically encounter lapse issues at the two-year mark.

What changed between Royal Decree 3/2010 and Royal Decree 311/2022 that private suppliers need to know?

The 2022 update raised the bar in three ways that directly affect private suppliers: mandatory certification (not just self-assessment) became required for Medium and High category systems; cloud security and supply chain risk became explicit control areas with dedicated requirements; and the transition deadline for full compliance with the new decree was April 2024, meaning any supplier still operating under the 2010 framework is now out of compliance. Organizations that were ENS-certified under the 2010 version needed to recertify under 311/2022 — this is not a minor update but a substantive control revision.

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.