CRA-02 — Ley Europea de Ciberresiliencia

Secure-by-default

Su producto se enviará en 8 semanas. La documentación técnica no menciona nada sobre ciberseguridad. Demuestre que es secure-by-design.

NIVEL DE AMENAZA: VERDE

Usted es el ingeniero jefe de firmware en Kastos IoT. Han pasado cuatro semanas desde el «zero-day» —la vulnerabilidad que permitía eludir la autenticación y que desencadenó la primera respuesta a un incidente de la CRA por parte de Kastos—. Se ha distribuido el parche. Se ha reconstruido la SBOM. La colaboración con el organismo notificado está en marcha. Ahora surge la pregunta más difícil: ¿puede demostrar que el K400 era seguro-by-design? Su tarea: elaborar el expediente de documentación técnica exigido por el artículo 31 de la CRA para la versión 4.0 del firmware del K400. El archivo existente se redactó para la Directiva sobre equipos radioeléctricos. Abarca la EMC y la seguridad RF. No dice nada sobre ciberseguridad.

Kastos IoT — 340 employees, €62M revenue, HQ Rotterdam
El lanzamiento del firmware K400 v4.0 está previsto para dentro de ocho semanas
Expediente técnico actual: conforme a la Directiva RED (EMC y seguridad de RF), sin sección dedicada a la ciberseguridad
La lista de materiales de software (SBOM) se ha vuelto a generar tras el Módulo 1; ahora se ha verificado con respecto a los artefactos de compilación
Se ha iniciado la colaboración con el organismo notificado (BSI Netherlands) para la evaluación de productos de clase I importantes
El 40 % de los instaladores son pequeñas empresas que tienen dificultades con la configuración de SSH

Resumen de la misión

Cómo funciona

Este es un escenario del tipo «elige tu propia aventura». Tomará decisiones reales a las que se enfrenta un ingeniero jefe de firmware a la hora de elaborar un expediente técnico conforme a la CRA, y sus elecciones determinarán su calificación operativa final.

Document Redline Activity

Revisa el expediente técnico existente y señala las secciones que no cumplen los requisitos de la CRA.

Tres Decisiones

Cada decisión se puntúa. Tus elecciones determinan una calificación operativa basada en porcentajes. Las decisiones erróneas tienen consecuencias en cadena.

Risk Assessment Spectrum

Utiliza el control deslizante para determinar el nivel adecuado de detalle para la evaluación de riesgos de ciberseguridad del K400.

Constructor de Cláusulas

Elabore el expediente técnico del anexo VII seleccionando la cláusula adecuada para cada sección obligatoria.

--:--:-- VERDE CRA-02: Seguro por defecto

Reunión informativa para el personal

Tu equipo

Trabajará con estas cuatro personas a lo largo de todo el escenario. Sus prioridades entran en conflicto. Su tarea consiste en encontrar la decisión que sea viable desde el punto de vista jurídico, técnico y comercial.

Tomasz Kowalski

Lead Firmware Engineer

Desarrolla el producto. Conoce todas las dependencias. Le da pánico el papeleo.

Nina Berger

Product Manager

Es el responsable de la fecha de entrega. Se opondrá a cualquier cosa que retrase el lanzamiento.

Sophie Laurent

Director de Asuntos Jurídicos y Regulatorios

Hace que Kastos cumpla con la ley. Se expresa utilizando referencias normativas.

Jan Mulder

Vicepresidente de Ingeniería

El jefe de Tomasz. Cuenta cada sprint. Odia las sorpresas del departamento jurídico.

--:--:-- ÁMBAR CRA-02: Seguro por defecto

Resumen de la situación

Actualización de la situación

El expediente técnico

Lunes, 09:15 CET

Abre el archivo técnico del K400. Se actualizó por última vez para la certificación RED v3.0, hace 18 meses. El archivo abarca las pruebas de compatibilidad electromagnética, las evaluaciones de seguridad en materia de radiofrecuencia y las normas de seguridad eléctrica. En el apartado «Seguridad» hay un único párrafo: «El K400 utiliza cifrado AES-256 para la comunicación en la nube».

El anexo VII del Reglamento sobre la seguridad de los productos (CRA) exige que la documentación técnica incluya: una descripción general del producto, la evaluación de riesgos de ciberseguridad, una descripción de cómo se cumplen los requisitos esenciales, la lista de normas armonizadas aplicadas, la declaración de conformidad de la UE y la SBOM. En su expediente, uno de estos elementos se ha tratado de forma parcial.

Sophie nos ha remitido el calendario de evaluación de BSI Países Bajos: el organismo notificado necesita el expediente técnico en un plazo de seis semanas para completar su revisión antes de la fecha de lanzamiento de la versión 4.0.

OF

OPS FEED — Resumen de la situación

[09:15] DOCUMENTACIÓN — Se ha iniciado la revisión del expediente técnico del K400. Cumplimiento del Anexo VII de la CRA: se ha presentado 1 de las 6 secciones requeridas (parcial).

Tomasz Kowalski — Ingeniero jefe de firmware

Un párrafo sobre el cifrado. Eso es todo. Lo estamos creando desde cero.

--:--:-- ÁMBAR CRA-02: Seguro por defecto

Resumen de la situación

Actividad

Ficha técnica con marcas de revisión

Ronda de práctica — sin puntuación. Tu puntuación se basa en las tres decisiones.

Lunes, 10:30 CET

Antes de empezar a redactar, debe comprender en qué medida la documentación técnica existente no cumple los requisitos. Revise la documentación técnica actual del K400 y marque las secciones que no cumplen los requisitos de la CRA. Haga clic en cada sección problemática para ver las deficiencias de cumplimiento.

--:--:-- ÁMBAR CRA-02: Seguro por defecto

Resumen de la situación

Actualización de la situación

La cuestión de Telnet

Lunes, 14:00 CET

Usted presenta el informe de auditoría de pruebas al equipo. La brecha en la configuración predeterminada secure-by-default es el mayor problema. Nina plantea inmediatamente el problema del instalador.

El K400 lo implementan empresas constructoras, no equipos de TI. En el 40 % de las instalaciones, el instalador es una pequeña empresa con entre 2 y 5 empleados y sin personal de TI específico. Utilizan Telnet porque SSH requiere una gestión de claves que su flujo de trabajo no admite. Desactivar Telnet generará cientos de llamadas al servicio de asistencia y podría retrasar las implementaciones.

Nina Berger — Jefa de producto

En seis meses he recibido 340 solicitudes de asistencia de instaladores que no logran completar la configuración de SSH. No se trata de una cuestión teórica: supone una pérdida de ingresos y retrasos en la entrega de los edificios. Si desactivamos Telnet, debemos ofrecerles una solución que realmente funcione.

SOPHIE LAURENT — Directora de Asuntos Jurídicos y Regulatorios

El CRA exige una configuración predeterminada segura. Telnet es un protocolo no cifrado que transmite las credenciales en texto sin cifrar. El hecho de que venga habilitado de forma predeterminada constituye un claro incumplimiento. La cuestión es cómo abordamos el flujo de trabajo del instalador, no si lo abordamos.

Jan Mulder — Vicepresidente de Ingeniería

No podemos permitirnos perder el 40 % de nuestra red de instaladores. No se trata de un problema de cumplimiento normativo, sino de supervivencia.

--:--:-- ÁMBAR CRA-02: Seguro por defecto

Resumen de la situación

Se requiere una decisión

Valores predeterminados secure-by-default frente al flujo de trabajo del instalador

Actualmente, el K400 se suministra con Telnet habilitado de forma predeterminada. El CRA requiere una configuración predeterminada segura. El 40 % de los instaladores recurre a Telnet porque la gestión de claves SSH resulta demasiado compleja para su flujo de trabajo. ¿Cómo se resuelve esto?

--:--:-- VERDE CRA-02: Seguro por defecto

Resumen de la situación

Actualización de la situación

Outcome: Positive

Asistente de SSH integrado

Su equipo ha desarrollado un asistente de configuración de SSH que se ejecuta en la pantalla integrada del K400 durante el proceso de aprovisionamiento en el primer arranque. Este genera un par de claves en el propio dispositivo, muestra un código QR que el instalador escanea con su teléfono para completar el emparejamiento y almacena la clave de forma segura. Sin Telnet, sin gestión manual de claves.

Las pruebas realizadas con 12 empresas instaladoras revelan que el tiempo medio de configuración aumenta de 4 minutos (Telnet) a 6 minutos (asistente). Dos de estas empresas necesitaron una llamada telefónica de 15 minutos con el servicio de asistencia en el primer intento. A partir de entonces, fueron más rápidas que con Telnet, ya que el código QR eliminó por completo la necesidad de introducir la contraseña.

Nina se muestra cautelosamente optimista: «Si el volumen de llamadas al servicio de asistencia se mantiene por debajo de 50 durante el primer mes, esto funcionará». Sophie documenta la solución como prueba para el expediente técnico.

Regulatory Reference

Anexo I, sección 1, apartado 3, de la CRA — Configuración predeterminada segura

Los productos que incluyan elementos digitales deben ponerse a disposición del público con una configuración «secure-by-default», lo que incluye la posibilidad de restablecer el estado de seguridad original. «Secure-by-default» significa que el producto se comercializa en su estado de uso más seguro: es el usuario quien debe tomar medidas deliberadas para reducir la seguridad, y no al revés. Sustituir un protocolo inseguro por una alternativa segura que se adapte a las necesidades de usabilidad es la solución ideal: elimina las deficiencias de cumplimiento sin crear dificultades para el negocio.

Nina Berger — Product Manager

«Si el número de llamadas al servicio de asistencia se mantiene por debajo de 50 durante el primer mes, esto funciona».

--:--:-- ÁMBAR CRA-02: Seguro por defecto

Resumen de la situación

Actualización de la situación

Outcome: Neutral

Consentimiento físico

Telnet está desactivado de forma predeterminada. Un botón empotrado en el panel del K400 activa Telnet si se mantiene pulsado durante 5 segundos en las primeras 24 horas tras el restablecimiento de fábrica. La pantalla muestra una advertencia: «TELNET ACTIVADO — PROTOCOLO SIN CIFRAR — UTILIZAR ÚNICAMENTE DURANTE LA CONFIGURACIÓN INICIAL».

Sophie analiza el enfoque: «Esto es defendible. La configuración predeterminada es segura. La activación voluntaria requiere acceso físico y consentimiento informado. Sin embargo, el organismo notificado podría preguntarnos por qué no eliminamos por completo el protocolo inseguro; estén preparados para documentar por qué esa «vía de escape» es proporcionada al caso de uso del instalador».

Nina admite: «El 60 % de los instaladores no lo necesitará. El 40 % que sí lo necesite solo tendrá que pulsar un botón. Con eso basta».

Regulatory Reference

La proporcionalidad en el diseño seguro

La CRA no prohíbe todas las funcionalidades inseguras, sino que exige configuraciones predeterminadas seguras y una elección informada por parte del usuario. Ofrecer un mecanismo de activación voluntaria para un protocolo menos seguro puede considerarse conforme si: (1) la configuración predeterminada es segura, (2) el usuario realiza una acción deliberada y documentada para cambiarla, (3) se comunica claramente el riesgo, y (4) el producto puede restablecerse a su estado seguro. La clave está en demostrar la proporcionalidad: el riesgo residual es aceptado por el usuario, no impuesto por el fabricante.

Sophie Laurent — Directora de Asuntos Jurídicos y Regulatorios

«Esto es defendible. La configuración predeterminada es segura. La opción de participación requiere acceso físico y consentimiento informado. Pero prepárate para justificar por qué esa vía de escape es proporcionada al caso de uso del instalador.»

--:--:-- ÁMBAR CRA-02: Seguro por defecto

Resumen de la situación

Actualización de la situación

Outcome: Negative

Solución alternativa para la desactivación automática

El K400 v4.0 se suministra con Telnet habilitado durante las primeras 72 horas tras el arranque. Durante la revisión de BSI Países Bajos, el evaluador pregunta: «¿Así que el producto se suministra en un estado inseguro por diseño?». Tomasz explica el proceso de instalación. El evaluador señala: «La CRA exige una configuración predeterminada segura en el momento de su comercialización. Un periodo de 72 horas en el que el sistema no es seguro no constituye una configuración predeterminada segura-by-default, sino una vulnerabilidad programada».

Este hallazgo retrasa la evaluación de la conformidad en cuatro semanas, mientras Kastos implementa un mecanismo adecuado de «secure-by-default». Se retrasa la fecha de lanzamiento de la versión 4.0. Jan está furioso: «Intentamos ahorrar tres semanas de desarrollo y hemos perdido cuatro».

Regulatory Reference

«Implacable» significa «implacable»

Un producto que se comercializa con una configuración insegura —aunque sea de forma temporal— no cumple el requisito de seguridad por defecto establecido por el Reglamento sobre la seguridad de los productos de consumo (CRA). La normativa evalúa el estado del producto en el momento de su comercialización, no una vez que haya expirado un plazo determinado. El hecho de que «se proteja por sí mismo más adelante» no significa que sea seguro-by-default. Se trata de un producto inseguro por defecto con una corrección diferida. Las autoridades de vigilancia del mercado y los organismos notificados evalúan el funcionamiento del producto tal y como viene de fábrica.

Jan Mulder — Vicepresidente de Ingeniería

«Intentamos ahorrar tres semanas de desarrollo y acabamos perdiendo cuatro».

--:--:-- ÁMBAR CRA-02: Seguro por defecto

Resumen de la situación

Actualización de la situación

La brecha en la evaluación de riesgos

Miércoles, 10:00 CET

Una vez resuelta la cuestión de los valores secure-by-default, se pasa a la evaluación de riesgos. El modelo de amenazas existente, de tres páginas, se redactó antes de que se detectara la vulnerabilidad del Módulo 1. Abarca las amenazas a nivel de red, pero no tiene en cuenta en absoluto la elusión de la autenticación BLE. La CRA exige una evaluación de riesgos que abarque la finalidad prevista del producto, su uso razonablemente previsible y su ciclo de vida, incluyendo el mantenimiento y el fin de la vida útil.

Dispone de tres opciones en cuanto al alcance de la evaluación de riesgos, cada una de ellas con diferentes compensaciones entre coste, tiempo y nivel de detalle.

Threat category	K400 attack surface	Current file	Required
Spoofing	BLE pairing identity	✗ missing	Mutual auth + cert pinning
Tampering	Firmware update package	⚠ partial	Signed updates + secure boot
Repudiation	Door/access audit log	✓ covered	Tamper-evident log
Info Disclosure	Cloud API + BLE provisioning	✓ covered	TLS 1.3 + LE Secure Connections
Denegación de servicio	BLE scan flood + cloud overload	✗ missing	Rate limiting + offline cache
Ampliación de privilegios	Telnet (activado por defecto) + JTAG	✗ missing	Solo SSH + JTAG integrado en la fase de producción
Supply Chain	BLE stack + 23 single-maintainer libs	✗ missing	Component provenance + SBOM

Se han cubierto 3 de las 7 categorías de amenazas de CRA. La vulnerabilidad de elusión de BLE que activó el Módulo 1 se encuentra en el Spoofing una fila que aún no se ha escrito.

SOPHIE LAURENT — Directora de Asuntos Jurídicos y Regulatorios

La sección 1 del Anexo I exige que el fabricante comercialice el producto «sobre la base de una evaluación de los riesgos de ciberseguridad». Dicha evaluación de riesgos debe quedar documentada en el expediente técnico y actualizarse cuando se produzcan cambios significativos. Una nueva versión de firmware tras la detección de una vulnerabilidad crítica se considera un cambio significativo.

OF

OPS FEED — Resumen de la situación

[10:05] CUMPLIMIENTO NORMATIVO — Revisión de la evaluación de riesgos: el documento actual abarca 3 de las 7 categorías de amenazas exigidas por la CRA. Faltan las categorías de BLE, acceso físico, actualización de firmware y cadena de suministro.

--:--:-- ÁMBAR CRA-02: Seguro por defecto

Resumen de la situación

Se requiere una decisión

Ámbito de la evaluación de riesgos

La evaluación de riesgos actual está incompleta. El expediente técnico de la versión 4.0 requiere una evaluación de riesgos de ciberseguridad que abarque todas las categorías exigidas por la CRA. El organismo notificado la necesita en un plazo de seis semanas. ¿Cómo se define el alcance de la evaluación?

--:--:-- VERDE CRA-02: Seguro por defecto

Resumen de la situación

Actualización de la situación

Outcome: Positive

Modelo de amenazas completo

Su equipo dedica tres semanas a elaborar un modelo de amenazas exhaustivo utilizando la metodología STRIDE en todas las interfaces del K400. La evaluación identifica 23 escenarios de amenaza en siete superficies de ataque. Para cada uno de ellos, documenta: la amenaza, las medidas de mitigación existentes, el riesgo residual y el requisito esencial de la CRA al que se corresponde.

La evaluación pone de manifiesto dos problemas de gravedad media que habían pasado desapercibidos: el mecanismo de actualización del firmware no valida las firmas de los paquetes durante la descarga (solo durante la instalación), y la aplicación móvil almacena la clave API en texto sin cifrar en las preferencias compartidas. Ambos problemas se han solucionado antes del lanzamiento de la versión 4.0.

El revisor del organismo notificado comenta: «Esta es una de las evaluaciones de riesgos más exhaustivas que hemos visto. La correspondencia entre STRIDE y los requisitos esenciales de la CRA resulta especialmente útil».

--:--:-- ÁMBAR CRA-02: Seguro por defecto

Actualizaciones de la situación

Actualización de la situación

Outcome: Neutral

Actualización y prueba de penetración

Actualizará el modelo de amenazas existente en el plazo de una semana, añadiendo las categorías de amenazas relacionadas con BLE, el acceso físico, las actualizaciones de firmware y la cadena de suministro. La prueba de penetración externa comenzará la semana siguiente y abarcará las nuevas superficies de ataque.

La prueba de penetración detecta los mismos dos problemas de gravedad media (descarga de firmware sin firmar, clave de API en texto plano), además de un hallazgo de gravedad baja. Usted soluciona los tres antes del lanzamiento de la versión 4.0. La combinación de la evaluación interna y la prueba de penetración externa proporciona pruebas sólidas para el expediente técnico.

Sophie señala: «El organismo notificado valorará la verificación independiente. Las pruebas externas refuerzan el argumento de la conformidad. El único riesgo es el plazo: si los evaluadores de seguridad detectan algún problema crítico, volveremos al ciclo de parches».

Sophie Laurent — Directora de Asuntos Jurídicos y Regulatorios

«El organismo notificado valorará la verificación independiente. Las pruebas externas refuerzan el argumento de la conformidad. El único riesgo es el plazo: si los evaluadores de seguridad detectan algún problema crítico, volveremos al ciclo de parches».

--:--:-- ÁMBAR CRA-02: Seguro por defecto

Resumen de la situación

Actualización de la situación

Outcome: Negative

Parche mínimo

Actualice la evaluación de riesgos con una sola página dedicada a la elusión de la autenticación BLE. El resto del documento permanece sin cambios con respecto a la certificación RED v3.0.

Durante la revisión de BSI Países Bajos, el evaluador pregunta: «Su evaluación de riesgos abarca las amenazas a la red y la elusión de BLE. ¿Qué hay del acceso físico al panel? ¿Y de la integridad de las actualizaciones de firmware? ¿Y de los riesgos de la cadena de suministro para las 312 dependencias de su SBOM? La CRA exige que la evaluación abarque la finalidad prevista y las condiciones de uso razonablemente previsibles».

El evaluador señala oficialmente que la evaluación de riesgos es insuficiente. La evaluación de la conformidad queda en suspenso hasta que se presente una evaluación de riesgos que cumpla con los requisitos. La fecha de lanzamiento de la versión 4.0 es ahora incierta.

Regulatory Reference

Anexo I, sección 1, apartado 2, del CRA — Requisitos de evaluación de riesgos

La CRA exige a los fabricantes que realicen una evaluación de riesgos de ciberseguridad antes de comercializar un producto y que la actualicen cuando se produzcan cambios significativos. La evaluación debe abarcar la finalidad prevista del producto, las condiciones de uso previsibles y todo el ciclo de vida del producto. Una evaluación de riesgos que solo abarque vulnerabilidades conocidas del pasado es retrospectiva; la CRA exige una evaluación prospectiva de las amenazas a las que se enfrentará el producto durante su implementación. Un organismo notificado evaluará si la evaluación de riesgos es proporcionada a la complejidad y al perfil de riesgo del producto.

--:--:-- ÁMBAR CRA-02: Seguro por defecto

Resumen de la situación

Actividad

Profundidad de la evaluación de riesgos

Ronda de práctica — sin puntuación. Tu puntuación se basa en las tres decisiones.

Semana 4

El alcance de la evaluación de riesgos supone un equilibrio entre distintos factores. Deslice el control deslizante para establecer el nivel de detalle de la evaluación de riesgos de ciberseguridad del K400. Cada posición muestra el coste, el plazo, la cobertura y la solidez jurídica frente a la normativa. Encuentre la posición que concilie la exhaustividad con el plazo de seis semanas establecido por el organismo notificado.

Mínimo: corrige únicamente la vulnerabilidad conocida de elusión de BLE Exhaustive — full threat model + external pen test + red team engagement

0% 25% 50% 75% 100%

RISK: LOW

Modelo de amenazas STRIDE completo en las 7 superficies de ataque. 3 semanas, 0 €. Cobertura completa mediante expertos internos. Documentación exhaustiva, pero sin validación independiente.

La CRA exige una evaluación de riesgos proporcionada: lo suficientemente exhaustiva como para abarcar todas las amenazas previsibles, pero sin llegar a ser tan excesiva que retrase innecesariamente la comercialización. El rango del 50 % al 75 % ofrece una cobertura completa con pruebas justificables. Quedarse por debajo del 50 % genera lagunas en el cumplimiento normativo. Superar el 75 % resulta desproporcionado con respecto al perfil de riesgo del producto y hace que no se cumpla el plazo.

--:--:-- ÁMBAR CRA-02: Seguro por defecto

Resumen de la situación

Se requiere una decisión

Fecha límite para la presentación del expediente técnico

El expediente técnico de la versión 4.0 está tomando forma. El organismo notificado lo necesita en dos semanas. Su evaluación de riesgos está completa, la SBOM está actualizada y se han implementado los ajustes secure-by-default. Sin embargo, los resultados de la prueba de penetración no estarán listos hasta dentro de tres semanas, es decir, una semana después de la fecha límite del BSI de los Países Bajos. ¿Qué debe enviar?

--:--:-- VERDE CRA-02: Seguro por defecto

Resumen de la situación

Actualización de la situación

Outcome: Positive

Presentación transparente

BSI Países Bajos acepta la presentación por fases. Comienzan a revisar de inmediato la evaluación de riesgos, la lista de componentes de seguridad (SBOM), la documentación sobre la configuración secure-by-default y las secciones relativas a la arquitectura. Los resultados de las pruebas de penetración llegan tres semanas después y confirman las medidas correctivas. La evaluación de la conformidad se completa según lo previsto: la prórroga de tres semanas se absorbió gracias a que los evaluadores trabajaron en otras secciones de forma paralela.

Jan se siente aliviado: «La fecha de entrega se mantiene. Y no hemos escatimado en el expediente». Sophie añade los comentarios del evaluador a la biblioteca interna de cumplimiento normativo: «Han valorado la transparencia respecto a la prueba de penetración pendiente. Es mejor ser claro sobre lo que aún no se tiene que fingir que sí se tiene».

Jan Mulder — Vicepresidente de Ingeniería

«La fecha de envío se mantiene. Y no hemos escatimado en la calidad del archivo».

--:--:-- ÁMBAR CRA-02: Seguro por defecto

Resumen de la situación

Actualización de la situación

Outcome: Neutral

Antiguo Testamento, nuevo contexto

Usted envía el informe de pruebas de penetración de hace 14 meses. El evaluador de BSI señala: «Esta prueba se llevó a cabo con el firmware v3.0. El alcance excluye el aprovisionamiento BLE, precisamente la superficie de ataque que fue explotada hace cuatro semanas. Se detectó una nueva vulnerabilidad que se corrigió en la versión v3.2. No puedo utilizar un informe de pruebas de penetración anterior a la vulnerabilidad como prueba de conformidad posterior a la misma».

El evaluador solicita los nuevos resultados de las pruebas de penetración antes de continuar. La evaluación de la conformidad no se rechaza, sino que se suspende en la fase de pruebas. Las demás fases siguen adelante. Retraso total: dos semanas más de lo previsto inicialmente.

--:--:-- ÁMBAR CRA-02: Seguro por defecto

Resumen de la situación

Actualización de la situación

Outcome: Negative

Entrega tardía

Se pone todo tres semanas atrás. El expediente técnico está completo cuando se envía: todas las secciones son definitivas y todas las pruebas están actualizadas. Sin embargo, la fecha de entrega de la versión 4.0 se ha retrasado ahora tres semanas.

Jan está frustrado: «Podríamos haber enviado las secciones que estaban listas y haber dejado que las revisaran en paralelo. Ahora hemos perdido tres semanas de ingresos por haber esperado a la perfección». Sophie está de acuerdo: «La presentación por fases, con las lagunas claramente señaladas, es una práctica habitual en los proyectos con organismos notificados. Están acostumbrados a revisar secciones en paralelo. Este ha sido un retraso innecesario».

La evaluación de la conformidad en sí misma solo lleva dos semanas —el expediente estaba completo—. Sin embargo, el plazo total es ahora cinco semanas más largo de lo que habría sido con el enfoque paralelo.

Regulatory Reference

Colaboración con organismos notificados

Las interacciones con los organismos notificados no son exámenes de tipo «aprobado/suspenso», sino evaluaciones colaborativas. Los evaluadores esperan que las presentaciones se realicen por fases y que se trabaje en paralelo en las distintas secciones. La transparencia respecto a los entregables pendientes (como los resultados de las pruebas de penetración) es una práctica habitual y no implica incumplimiento. Esperar a alcanzar la perfección antes de iniciar el proceso supone una pérdida de tiempo que ambas partes podrían aprovechar de forma productiva. El objetivo es demostrar la conformidad, no demostrar que se puede elaborar un documento perfecto en una sola presentación.

Jan Mulder — Vicepresidente de Ingeniería

«Podríamos haber enviado las secciones que estaban listas y dejar que las revisaran en paralelo. Ahora hemos perdido tres semanas de ingresos por haber esperado a que todo fuera perfecto».

--:--:-- VERDE CRA-02: Seguro por defecto

Resumen de la situación

Actividad

Anexo VII — Elaboración del expediente técnico

Ronda de práctica — sin puntuación. Tu puntuación se basa en las tres decisiones.

Semana 6

El expediente técnico debe incluir seis secciones obligatorias, tal y como establece el Anexo VII. Elabore el expediente seleccionando la cláusula correcta para cada sección de entre las opciones disponibles. Las combinaciones incorrectas no superarán la validación: el organismo notificado no aceptará un expediente en el que falten secciones o estas no coincidan.

--:--:-- VERDE CRA-02: Seguro por defecto

Resumen de la situación

Prueba de conocimientos

Antes de ver sus resultados, responda a cuatro preguntas sobre la CRA. Seleccione una respuesta por pregunta.