Matricúlate
Secure by Design ya no puede ser un eslogan: cuando la seguridad entra en la arquitectura del producto
La convergencia —sin equivalencia— entre el enfoque de ENISA y la protección de datos desde el diseño del artículo 25 del RGPD
Durante años hemos repetido que la seguridad debe incorporarse desde el diseño. La expresión aparece en normas, metodologías de desarrollo, políticas corporativas, estándares técnicos y programas de ciberseguridad hasta el punto de haberse convertido, en ocasiones, en una fórmula casi automática. Algo semejante ha ocurrido en protección de datos con la obligación de aplicar la protección de datos desde el diseño y por defecto. El problema, sin embargo, nunca ha sido aceptar intelectualmente estas ideas, sino conseguir que influyan de verdad en las decisiones que determinan cómo se construye un producto, qué datos utiliza, cómo se configura, quién puede acceder a ellos, durante cuánto tiempo se mantienen determinadas funciones y qué ocurre cuando el producto cambia, se actualiza o llega al final de su vida útil.
El ENISA Secure by Design and Default Playbook. A Practical Guide to Secure by Design and Default Principles for SMEs, versión 1.0, publicado el 30 de julio de 2026, resulta especialmente interesante porque intenta resolver precisamente esa distancia entre el principio y su aplicación. ENISA no propone una nueva teoría de la seguridad de producto ni pretende sustituir los marcos ya consolidados de ingeniería segura. Su aportación consiste, más bien, en traducir principios conocidos en decisiones y prácticas que puedan incorporarse al ciclo de vida del producto, con especial atención a las limitaciones de las pequeñas y medianas empresas.
La importancia del documento reside en que desplaza el centro de gravedad de la seguridad. La cuestión deja de ser únicamente cómo comprobar, al final del desarrollo, si un producto presenta vulnerabilidades o configuraciones inadecuadas. La pregunta pasa a ser otra: cómo hacer que la seguridad influya cuando todavía estamos definiendo la arquitectura, las relaciones de confianza, los privilegios, los mecanismos de autenticación, los componentes, las dependencias, la configuración inicial y las condiciones de mantenimiento.
Ese cambio puede parecer metodológico, pero en realidad es bastante más profundo. Supone pasar de una seguridad predominantemente reactiva a una seguridad integrada en la ingeniería del producto.
Figura 1: “La seguridad deja de ser una revisión final y pasa a acompañar cada decisión del ciclo de vida del producto.”
De la consigna a la arquitectura
ENISA articula su propuesta alrededor de una visión de ciclo de vida que comprende la definición de requisitos, el diseño, la implementación, la verificación, el despliegue y el mantenimiento y retirada del producto. El documento advierte expresamente de que estas fases no deben entenderse como una secuencia rígida. Pueden solaparse, repetirse y revisitarse cuando cambian las circunstancias del producto o de su entorno.
Esta precisión es especialmente relevante porque la seguridad de un producto no permanece inalterada simplemente porque una versión determinada haya superado satisfactoriamente una evaluación antes de ser liberada. Una nueva dependencia puede introducir vulnerabilidades inexistentes en el momento del diseño; una modificación del sistema de autenticación puede alterar determinadas rutas de ataque; un cambio de proveedor puede modificar los supuestos sobre los que se apoyaba el análisis de riesgos; y una vulnerabilidad descubierta durante la operación puede obligar a revisar decisiones arquitectónicas que parecían razonables meses antes.
La seguridad, por tanto, no puede limitarse a una etapa del proyecto. Debe mantenerse como una actividad que acompaña al producto durante toda su existencia.
En esta lógica, la gestión del riesgo desempeña un papel central. ENISA la utiliza para establecer qué necesita protección, frente a qué amenazas, en qué contexto y con qué consecuencias previsibles. Esa información debe traducirse después en requisitos, decisiones de arquitectura, configuraciones, pruebas y mecanismos de mantenimiento. El riesgo proporciona así el contexto que justifica las decisiones; la ingeniería determina cómo materializarlas; y el ciclo de vida obliga a revisar su validez cuando cambian las condiciones que les dieron origen.
En este punto comienza a resultar inevitable mirar hacia el artículo 25 del RGPD, porque la lógica que contiene es, en algunos aspectos, sorprendentemente cercana.
Dos marcos distintos que se encuentran en el diseño
El artículo 25.1 del RGPD exige al responsable del tratamiento aplicar medidas técnicas y organizativas apropiadas tanto en el momento de determinar los medios del tratamiento como durante el propio tratamiento, teniendo en cuenta el estado de la técnica, el coste de la aplicación, la naturaleza, el alcance, el contexto y los fines del tratamiento, así como los riesgos de diversa probabilidad y gravedad para los derechos y libertades de las personas físicas.
La ubicación temporal de la obligación es importante. El RGPD no espera a que el sistema esté plenamente construido para exigir protección. Sitúa la obligación en el momento en que se decide cómo va a funcionar el tratamiento y la mantiene durante su desarrollo y operación.
Las Directrices 4/2019 del Comité Europeo de Protección de Datos refuerzan esta interpretación. La protección de datos desde el diseño no consiste simplemente en incorporar determinadas medidas técnicas, sino en integrar efectivamente los principios de protección de datos en el tratamiento y establecer las garantías necesarias para proteger los derechos y libertades de las personas.
Esta precisión impide una identificación automática entre Secure by Design y Data Protection by Design.
No son equivalentes.
La seguridad desde el diseño trata de construir productos capaces de resistir amenazas, limitar la exposición, contener compromisos y mantener determinadas propiedades de seguridad a lo largo de su ciclo de vida. La protección de datos desde el diseño, por su parte, obliga a incorporar una perspectiva mucho más amplia: licitud, lealtad, transparencia, limitación de la finalidad, minimización, exactitud, limitación del plazo de conservación, integridad y confidencialidad, además de las garantías necesarias para hacer efectivos los derechos de las personas.
La diferencia puede apreciarse con facilidad. Un sistema puede estar perfectamente cifrado, contar con autenticación multifactor, mantener un excelente modelo de gestión de vulnerabilidades y disponer de una arquitectura resistente frente a ataques, y aun así recoger más datos de los necesarios, conservarlos durante demasiado tiempo o utilizarlos para finalidades incompatibles con las que justificaron su recogida.
Desde una perspectiva estrictamente técnica, podríamos estar ante un producto muy seguro. Desde la perspectiva del artículo 25 del RGPD, seguiríamos teniendo un problema.
La convergencia existe, pero no debe confundirse con identidad.
El contexto regulatorio del Cyber Resilience Act
El playbook de ENISA tampoco debe leerse como una publicación aislada. Forma parte de un contexto regulatorio europeo mucho más amplio, marcado por la aprobación del Reglamento (UE) 2024/2847, conocido como Cyber Resilience Act.
El CRA establece requisitos horizontales de ciberseguridad para productos con elementos digitales y consolida una idea que atraviesa todo el documento de ENISA: la ciberseguridad debe considerarse desde el diseño y mantenerse durante el ciclo de vida del producto. Esto afecta no solo a las medidas incorporadas inicialmente, sino también a la gestión de vulnerabilidades, las actualizaciones, la documentación técnica y la capacidad de responder a problemas descubiertos después de la comercialización.
El CRA declara, además, que sus disposiciones se aplican sin perjuicio del RGPD. Esta coexistencia resulta particularmente importante, porque confirma que la seguridad de producto y la protección de datos deben coordinarse, pero no se sustituyen mutuamente.
Un fabricante puede tener obligaciones específicas de ciberseguridad derivadas del CRA y, al mismo tiempo, desarrollar un producto que será utilizado posteriormente por responsables del tratamiento sometidos al artículo 25 del RGPD. Esto genera un espacio de interdependencia evidente entre el diseño técnico del producto y la capacidad jurídica de sus usuarios para cumplir correctamente sus obligaciones.
Cuando las decisiones arquitectónicas tienen consecuencias jurídicas
El documento de ENISA permite observar esta convergencia con bastante claridad al analizar sus principios de seguridad desde el diseño.
Uno de los primeros es el relativo a las fronteras de confianza y el modelado de amenazas. La idea parte de un presupuesto sencillo: la confianza no debería darse por supuesta, sino hacerse explícita. Allí donde los datos, las identidades o los procesos atraviesan entornos con diferentes niveles de confianza, la arquitectura debe determinar qué mecanismos de autenticación, autorización, cifrado, aislamiento o validación son necesarios.
El modelado de amenazas obliga después a preguntarse qué puede salir mal en esas fronteras y qué consecuencias podría tener. ENISA propone una aproximación deliberadamente manejable para organizaciones pequeñas, apoyándose en las preguntas clásicas de Shostack: qué estamos construyendo, qué puede salir mal, qué vamos a hacer al respecto y si hemos hecho un trabajo suficientemente bueno.
Lo relevante no es la complejidad formal del modelo, sino que sus resultados influyan realmente en el diseño. Un análisis de amenazas que termina archivado sin modificar requisitos, configuraciones, controles o decisiones arquitectónicas tiene un valor limitado. En cambio, un análisis sencillo que consigue que una interfaz administrativa deje de estar expuesta a Internet, que se modifique un sistema de actualización o que una dependencia crítica reciba un tratamiento diferente está cumpliendo plenamente su función.
Algo parecido ocurre con el mínimo privilegio. El principio exige que usuarios, servicios, componentes y procesos dispongan únicamente de los permisos necesarios para realizar sus funciones. Su función no es solo prevenir accesos indebidos, sino también limitar las consecuencias cuando una cuenta, un proceso o un componente resulta comprometido.
Desde la perspectiva del RGPD, esta decisión puede contribuir a materializar varias exigencias: limitación de accesos internos, separación de funciones, confidencialidad, trazabilidad y reducción de la exposición de datos personales. Sin embargo, no debe presentarse como una garantía suficiente por sí misma. Una arquitectura de permisos perfectamente segregada no garantiza necesariamente que los datos puedan localizarse, rectificarse o suprimirse de forma efectiva si no existe, además, una adecuada gobernanza de la información.
Esta distinción resulta importante porque evita convertir medidas técnicas concretas en equivalentes automáticos de cumplimiento jurídico.
Identidad, autenticación y gobernanza de la información
ENISA dedica también una atención específica a la arquitectura robusta de identidad y autenticación. La identidad de usuarios, administradores, dispositivos, servicios y componentes no debería resolverse mediante mecanismos fragmentados que se añaden conforme aparecen nuevas necesidades, sino como una dimensión estructural del producto.
Esto obliga a responder desde el diseño a preguntas fundamentales: quién puede crear una identidad, quién puede modificarla, qué fuente se considera autorizada, qué mecanismos de autenticación se utilizan, cómo se asignan privilegios, cómo se revocan y qué ocurre cuando una identidad deja de ser válida.
En sistemas que tratan datos personales, estas decisiones tienen consecuencias jurídicas evidentes. Una arquitectura deficiente de identidad puede generar accesos excesivos, dificultar la separación de funciones, impedir una trazabilidad adecuada o complicar la localización y gestión de la información asociada a una persona concreta.
La arquitectura de seguridad se convierte así en una condición material para que determinadas obligaciones de protección de datos puedan aplicarse de manera efectiva.
Minimizar la superficie de ataque y minimizar los datos
Otro de los principios centrales de ENISA es la minimización de la superficie de ataque. Todo servicio innecesario, toda interfaz que no necesita permanecer expuesta, todo puerto abierto, toda biblioteca que ya no se utiliza y todo componente adicional aumenta potencialmente la capacidad de un atacante para interactuar con el sistema.
La recomendación consiste en reducir esa superficie y mantener únicamente aquello que resulta necesario para cumplir la función prevista.
La comparación con la minimización de datos es útil siempre que se mantenga la diferencia entre sus objetos.
En seguridad, reducimos componentes, servicios e interfaces para disminuir exposición técnica. En protección de datos, el artículo 25.2 del RGPD exige que, por defecto, únicamente sean objeto de tratamiento los datos personales necesarios para cada finalidad específica. Esta exigencia alcanza no solo la cantidad de datos tratados, sino también la extensión del tratamiento, su accesibilidad y el período de conservación.
La similitud metodológica es clara: aquello que no es necesario no debería formar parte del sistema por defecto.
Pero el contenido de la obligación es diferente.
Un producto puede minimizar correctamente su superficie de ataque y, sin embargo, tratar de forma predeterminada más datos de los necesarios. Puede deshabilitar servicios superfluos y mantener, al mismo tiempo, una recogida excesiva de telemetría, una conservación indefinida o una accesibilidad demasiado amplia.
Por eso Secure by Default y Data Protection by Default no son sinónimos, aunque puedan operar sobre una misma configuración técnica.
Una configuración inicial que reduzca la exposición del producto puede contribuir también a la protección de datos, pero solo existirá adecuación al artículo 25.2 cuando esa configuración limite efectivamente el tratamiento de datos personales a aquello que resulta necesario para cada finalidad.
La seguridad no se conserva sola
ENISA agrupa una segunda familia de principios bajo la idea de integridad operativa. En ella incluye la gestión del ciclo de vida, el diseño centrado en el usuario, la programación segura y la verificación, el registro y la monitorización, la gestión de cambios, la respuesta ante incidentes, la gestión de vulnerabilidades y parches y los controles de cadena de suministro.
Esta parte del documento introduce una enseñanza especialmente relevante: una buena arquitectura inicial no garantiza que la postura de seguridad permanezca estable con el paso del tiempo.
Los sistemas cambian, las amenazas evolucionan, las dependencias se actualizan, aparecen vulnerabilidades, los productos se despliegan en contextos inicialmente no previstos y las decisiones de configuración pueden degradarse.
La protección de datos desde el diseño plantea una exigencia temporal comparable. El artículo 25 no agota sus efectos en la fase de concepción. Las medidas deben seguir siendo apropiadas durante el propio tratamiento y su eficacia debe revisarse a medida que cambian los riesgos, los fines, las tecnologías o las condiciones de operación.
Un sistema que fue correctamente diseñado puede dejar de cumplir adecuadamente si los accesos se amplían sin justificación, las finalidades se extienden, la retención aumenta, las medidas dejan de revisarse o se introducen nuevas funcionalidades sin volver a analizar sus consecuencias.
Por eso, tanto en seguridad como en protección de datos, diseñar correctamente no consiste en tomar buenas decisiones una vez. Consiste también en mantener su validez.
El fabricante no es automáticamente el responsable del tratamiento
La relación entre el enfoque de ENISA y el artículo 25 del RGPD exige también mantener clara la distribución de responsabilidades.
El artículo 25 dirige su obligación directamente al responsable del tratamiento. El fabricante de un producto tecnológico no se convierte automáticamente en responsable por el mero hecho de diseñar o comercializar ese producto.
El considerando 78 del RGPD no modifica esa distribución de responsabilidades. Lo que hace es reconocer que los productores de productos, servicios y aplicaciones basados en el tratamiento de datos personales deberían ser alentados a tener en cuenta el derecho a la protección de datos cuando los desarrollan y diseñan, de modo que responsables y encargados puedan cumplir sus obligaciones.
La diferencia es importante.
El considerando 78 no crea una obligación autónoma equivalente al artículo 25 para todos los fabricantes, pero sí reconoce una realidad difícil de ignorar: la capacidad real de un responsable para cumplir el RGPD depende, en muchos casos, de decisiones técnicas adoptadas por terceros mucho antes de que ese responsable configure su tratamiento concreto.
Si un producto no permite restringir adecuadamente accesos, limitar períodos de conservación, eliminar datos, controlar privilegios o mantener una trazabilidad suficiente, el margen del responsable para aplicar posteriormente la protección de datos desde el diseño puede quedar severamente condicionado.
La arquitectura del producto delimita, en parte, el espacio real de cumplimiento jurídico.
Figura 2. «Un sistema puede ser seguro y, aun así, no cumplir el artículo 25.”
Del control tardío a la ingeniería
Una de las ideas más interesantes del playbook de ENISA es precisamente este desplazamiento temporal.
En un enfoque tradicional, el producto puede desarrollarse primero y someterse después a pruebas de seguridad destinadas a identificar vulnerabilidades que deben corregirse antes de la liberación. Ese trabajo sigue siendo indispensable, pero no puede ser el lugar donde pretendemos crear la seguridad.
Cuando la verificación detecta una vulnerabilidad concreta, la corrección puede ser relativamente sencilla. Cuando descubre que el problema se encuentra en una decisión arquitectónica fundamental, el coste y la complejidad pueden ser mucho mayores.
Secure by Design intenta evitar esa situación situando determinadas preguntas mucho antes.
La misma lógica puede aplicarse a la protección de datos.
La intervención del DPD o del equipo de privacidad no debería producirse únicamente cuando el producto está prácticamente terminado y las decisiones centrales ya han sido tomadas. Si cuestiones como la necesidad de los datos, las finalidades, los accesos, la conservación, la configuración inicial, la separación de funciones o la posibilidad de ejercer derechos aparecen demasiado tarde, la organización puede descubrir que cumplir correctamente exige modificar elementos estructurales del sistema.
En ese sentido, la protección de datos desde el diseño implica algo más exigente que revisar un producto antes de su puesta en producción. Implica participar cuando todavía es posible influir en cómo se va a construir.
La verificación no desaparece, pero cambia de función. Deja de ser el lugar donde esperamos crear la seguridad o la protección de datos y pasa a ser el momento en el que comprobamos si las decisiones que adoptamos anteriormente funcionan realmente.
Figura 3: “La arquitectura condiciona lo que después puede cumplirse y demostrarse.”
La cuestión decisiva empieza entonces a ser la evidencia
El playbook de ENISA da un paso adicional al traducir estos principios en 22 playbooks operativos que incluyen objetivos, acciones, evidencia mínima y criterios de liberación.
Esta estructura introduce una pregunta que probablemente sea todavía más importante que la formulación de los principios: cómo demostrar que realmente han sido aplicados.
No basta con afirmar que un producto ha sido desarrollado de forma segura. La organización debe poder mostrar qué decisiones adoptó, qué controles implantó, qué pruebas realizó, qué resultados obtuvo, qué excepciones aceptó y por qué consideró razonable liberar una determinada versión.
La cuestión resulta igualmente familiar desde el RGPD, porque la protección de datos desde el diseño debe interpretarse dentro de la lógica de responsabilidad proactiva. No se trata únicamente de seleccionar medidas apropiadas, sino de poder sostener que esas medidas existen, son adecuadas para los riesgos y continúan siendo eficaces.
Aquí comienza otro problema, distinto aunque estrechamente relacionado con el primero: el paso de la seguridad declarada a la seguridad demostrable.
Ese será el objeto del segundo artículo de esta serie.
Una convergencia que no exige confundir los marcos
Poner en relación el playbook de ENISA y el artículo 25 del RGPD no obliga a considerar que la seguridad desde el diseño y la protección de datos desde el diseño persigan la misma finalidad ni que distribuyan de igual manera las responsabilidades.
Lo relevante es reconocer el terreno en el que ambas terminan encontrándose.
Las garantías jurídicas y técnicas solo pueden ser realmente efectivas cuando influyen en las decisiones que determinan la arquitectura, la configuración y el ciclo de vida del producto.
La ciberseguridad necesita que el producto sea capaz de resistir amenazas, limitar compromisos y mantener sus propiedades de protección durante el tiempo.
La protección de datos necesita, además, que el propio tratamiento esté concebido de forma compatible con sus principios y con los derechos y libertades de las personas.
Cuando un producto trata datos personales, ambas perspectivas dejan inevitablemente de poder diseñarse de espaldas una a la otra.
Secure by Design y Data Protection by Design no imponen la misma finalidad ni distribuyen del mismo modo las responsabilidades, pero convergen en una premisa decisiva: las garantías jurídicas y técnicas solo pueden ser efectivas si se incorporan a las decisiones que definen la arquitectura, la configuración y el ciclo de vida del producto. La seguridad y la protección de datos no empiezan cuando el sistema está terminado; empiezan cuando todavía es posible decidir cómo debe funcionar.
Serie: De la seguridad declarada a la seguridad demostrable
I. Secure by Design ya no puede ser un eslogan: cuando la seguridad entra en la arquitectura del producto
II. De los principios al “go/no-go”: los 22 playbooks de ENISA y la nueva definición de producto terminado
III. De la evidencia documental a la evidencia procesable: el futuro de la demostrabilidad de la seguridad
Referencias esenciales
ENISA, Secure by Design and Default Playbook. A Practical Guide to Secure by Design and Default Principles for SMEs, versión 1.0, 30 de julio de 2026. ENISA_Secure_By_Design_and_Defa…
Reglamento (UE) 2016/679 del Parlamento Europeo y del Consejo, de 27 de abril de 2016, especialmente artículo 25 y considerando 78.
Comité Europeo de Protección de Datos, Directrices 4/2019 relativas al artículo 25. Protección de datos desde el diseño y por defecto, versión 2.0, adoptada el 20 de octubre de 2020.
Reglamento (UE) 2024/2847 del Parlamento Europeo y del Consejo, de 23 de octubre de 2024, relativo a los requisitos horizontales de ciberseguridad para los productos con elementos digitales (Cyber Resilience Act).
Autor y responsable editorial: Leocadio Marrero Trujillo.
El enfoque, la arquitectura, los criterios de análisis y las conclusiones de este artículo han sido definidos y validados por el autor. Durante su elaboración se han utilizado herramientas de inteligencia artificial generativa como apoyo para la estructuración, reformulación, edición y creación de determinados elementos gráficos.
El contenido ha sido sometido a revisión humana sustantiva, comprobación de fuentes y validación jurídica y técnica. El autor ha aprobado la versión definitiva y asume íntegramente la responsabilidad editorial sobre su contenido