¿Qué requiere el control A.3.29?
Se deberán establecer, documentar, mantener y aplicar principios para la ingeniería de sistemas seguros relacionados con el procesamiento de información de identificación personal (PII) en todas las actividades de desarrollo de sistemas de información.
Este control se encuentra dentro del Controles de seguridad compartidos anexo (A.3) y va más allá de los proyectos de desarrollo individuales para requerir principios de ingeniería a nivel de toda la organización que guíen todo el desarrollo del sistema. Si bien A.3.27 Ciclo de vida de desarrollo seguro abarca el ciclo de vida del desarrollo y A.3.28 Seguridad de las aplicaciones La sección A.3.29 abarca los requisitos de seguridad de las aplicaciones y se centra en los fundamentos arquitectónicos: los patrones de diseño, los principios de seguridad y los estándares de ingeniería que tienen en cuenta la privacidad y que rigen cada sistema construido o modificado dentro de la organización.
¿Qué dice la guía de implementación del Anexo B?
El Anexo B (sección B.3.29) proporciona la siguiente orientación:
- Privacidad desde el diseño y privacidad por defecto — Los sistemas o componentes relacionados con el procesamiento de información de identificación personal deben diseñarse siguiendo los principios de privacidad desde el diseño y privacidad por defecto.
- Anticipe y facilite los controles. — La arquitectura del sistema debe prever y facilitar la implementación de los controles pertinentes descritos en B.1 (para controladores PII) y B.2 (para procesadores PII).
- Minimizar el procesamiento de información de identificación personal — La recopilación y el procesamiento de información de identificación personal en esos sistemas deben limitarse a lo necesario para los fines identificados del procesamiento.
- Diseño para la eliminación — Por ejemplo, una organización que procesa información de identificación personal (PII) debe asegurarse de eliminarla después de un período determinado. El sistema que procesa dicha PII debe diseñarse de manera que facilite este requisito de eliminación.
- Vea también A.3.30: Desarrollo externalizado para requisitos relacionados
- Vea también A.3.31: Información de la prueba para requisitos relacionados
El ejemplo de la eliminación de datos es particularmente ilustrativo: si un sistema no está diseñado para admitir la eliminación de datos desde el principio, incorporar esta funcionalidad posteriormente puede resultar extremadamente costoso y técnicamente complejo. El mismo principio se aplica a la minimización de datos, la gestión del consentimiento, la portabilidad de datos y cualquier otro requisito de privacidad.
¿Cómo se relaciona esto con el RGPD?
El control A.3.29 se corresponde con lo siguiente: GDPR artículo:
- Artículo 25 (1) — Protección de datos desde el diseño y por defecto, que requiere la implementación de medidas técnicas y organizativas apropiadas diseñadas para implementar eficazmente los principios de protección de datos e integrar las salvaguardas necesarias en el tratamiento.
El apartado A.3.29 proporciona un marco práctico para cumplir con el requisito del artículo 25 de que la protección de datos se considere a nivel arquitectónico, y no solo a nivel de aplicación.
¿Qué cambios se produjeron con respecto a la norma ISO 27701:2019?
Para un enfoque paso a paso, consulte el Transición de 2019 a 2025.
En la edición de 2019, este requisito estaba cubierto por la cláusula 6.11.2.5 (principios de ingeniería de sistemas seguros). La edición de 2025 mantiene los requisitos principales como A.3.29, con la guía de implementación en B.3.29 que proporciona una conexión más clara con los principios de privacidad por diseño y los controles específicos del controlador y del procesador que la arquitectura del sistema debe anticipar. Véase la Tabla de correspondencias del Anexo F para el mapeo completo.
Libérate de una montaña de hojas de cálculo
Integre, amplíe y escale su cumplimiento normativo, sin complicaciones. IO le brinda la resiliencia y la confianza para crecer con seguridad.
¿Qué tipo de evidencia esperan los auditores?
Al evaluar el cumplimiento de A.3.29, los auditores generalmente buscarán lo siguiente:
- Principios de ingeniería documentados — Un conjunto de principios documentados de ingeniería de sistemas seguros que abordan la protección de la información de identificación personal (PII), incluyendo la minimización de datos, la limitación de la finalidad, la limitación del almacenamiento y la seguridad por defecto.
- Registros de revisión de arquitectura — Evidencia de que las arquitecturas de los sistemas se revisan conforme a los principios documentados antes de que comience el desarrollo.
- Patrones de diseño que respetan la privacidad — Patrones de diseño documentados o arquitecturas de referencia que los equipos de desarrollo utilizan como plantillas, incorporando los requisitos de protección de la información de identificación personal (PII).
- Diseño para el ciclo de vida de los datos — Evidencia de que los sistemas están diseñados para respaldar el ciclo de vida completo de los datos de información de identificación personal (PII), incluyendo la recopilación, el procesamiento, el almacenamiento, la eliminación y los derechos del interesado.
- Mantenimiento de los principios — Registros que demuestren que los principios de ingeniería se revisan y actualizan periódicamente o en respuesta a cambios en los requisitos de privacidad.
¿Cuáles son los controles relacionados?
| Control | Relación |
|---|---|
| A.3.27 Ciclo de vida de desarrollo seguro | Los procesos de desarrollo deben implementar los principios de ingeniería. |
| A.3.28 Requisitos de seguridad de la aplicación | Los requisitos de la aplicación deben estar alineados con los principios arquitectónicos. |
| A.1.2.6 Evaluación del impacto en la privacidad | Las evaluaciones de impacto en la privacidad (PIA, por sus siglas en inglés) identifican riesgos de privacidad que los principios de ingeniería deben abordar. |
| A.1.4.5 Objetivos de minimización de la información de identificación personal | La arquitectura del sistema debería imponer la minimización de datos por defecto. |
| A.1.4.6 Desidentificación y eliminación | Los sistemas deben ser arquitectónicamente capaces de soportar los requisitos de eliminación. |
¿A quién se aplica este control?
A.3.29 es un control compartido Esto se aplica tanto a los responsables del tratamiento como a los encargados del tratamiento de datos personales. Toda organización que desarrolle sistemas de información para el tratamiento de datos personales debe establecer y mantener principios de ingeniería. El control exige que estos principios se apliquen a «todas las actividades de desarrollo de sistemas de información», lo que significa que no son directrices opcionales, sino normas obligatorias para todo el trabajo de desarrollo.
Gestione todo su cumplimiento, todo en un solo lugar
ISMS.online admite más de 100 estándares y regulaciones, lo que le brinda una única plataforma para todas sus necesidades de cumplimiento.
¿Por qué elegir SGSI.online ¿Para garantizar el cumplimiento de la arquitectura del sistema seguro?
SGSI.online Proporciona herramientas prácticas para gestionar sus principios de ingeniería de seguridad:
- Registro de principios — Documente y mantenga sus principios de ingeniería segura en un registro centralizado y versionado al que puedan consultar los equipos de desarrollo.
- Flujos de trabajo de revisión de arquitectura — Crea flujos de trabajo de revisión que requieran que los diseños del sistema se evalúen según tus principios de ingeniería antes de que comience el desarrollo.
- Integración de la DPIA — Vincular las evaluaciones de impacto en la privacidad con las decisiones de arquitectura del sistema, asegurando que los riesgos de privacidad identificados en la DPIA se aborden en el diseño.
- Mapeo de cumplimiento — Mapea tus principios de ingeniería a los controles de la norma ISO 27701, GDPR Artículo 25 y otros requisitos del marco de privacidad
- Revisar la programación — Programe revisiones periódicas de sus principios de ingeniería con recordatorios automatizados y control de versiones.
Preguntas Frecuentes
¿Cuál es la diferencia entre A.3.27 Ciclo de vida de desarrollo seguro y A.3.29?
A.3.27 Ciclo de vida de desarrollo seguro cubre el ciclo de vida de desarrollo seguro: el proceso y los procedimientos que siguen los equipos de desarrollo. A.3.29 cubre los principios de ingeniería: los estándares arquitectónicos y los patrones de diseño que guían cómo deben ser los sistemas. Piensa en A.3.27 Ciclo de vida de desarrollo seguro como “cómo construimos” y A.3.29 como “hacia dónde construimos”. Ambos trabajan juntos: procesos de desarrollo (A.3.27 Ciclo de vida de desarrollo seguro) debería hacer cumplir la aplicación de los principios de ingeniería (A.3.29).
¿Cuáles son algunos ejemplos de principios de ingeniería de seguridad para la información de identificación personal (PII)?
Algunos ejemplos incluyen: recopilar solo los campos de información personal identificable (PII) necesarios para el propósito indicado; cifrar la PII en reposo y en tránsito de forma predeterminada; diseñar esquemas de bases de datos que admitan la eliminación granular de registros individuales; implementar la gestión del consentimiento en la capa de datos, no solo en la capa de interfaz de usuario; registrar todos los eventos de acceso a la PII; utilizar el control de acceso basado en roles para restringir el acceso a la PII al personal autorizado; diseñar API para devolver solo la PII mínima necesaria para cada caso de uso; e incorporar la automatización de la retención de datos en el sistema desde su lanzamiento.
¿Con qué frecuencia deben revisarse los principios de ingeniería?
Los principios de ingeniería deben revisarse al menos anualmente y siempre que se produzcan cambios significativos en la legislación sobre privacidad, las actividades de procesamiento de información personal de la organización, la infraestructura tecnológica o el panorama de amenazas. La revisión debe evaluar si los principios siguen vigentes, son eficaces y se ajustan a las obligaciones de privacidad de la organización. Cualquier actualización debe comunicarse a los equipos de desarrollo y reflejarse en las listas de verificación de la revisión de la arquitectura.
Las plataformas SaaS pueden encontrar orientación personalizada en nuestra guía para plataformas SaaS.
