Que requiert le contrôle A.3.29 ?
Les principes d'ingénierie des systèmes sécurisés liés au traitement des informations personnelles identifiables doivent être établis, documentés, maintenus et appliqués à toutes les activités de développement de systèmes d'information.
Cette commande se trouve à l'intérieur de Contrôles de sécurité partagés L’annexe (A.3) va au-delà des projets de développement individuels et exige des principes d’ingénierie à l’échelle de l’organisation qui guident tout le développement du système. A.3.27 Cycle de vie du développement sécurisé couvre le cycle de vie du développement et A.3.28 Sécurité des applications La section A.3.29 couvre les exigences de sécurité des applications, tandis que la section A.3.29 se concentre sur les fondements architecturaux : les modèles de conception, les principes de sécurité et les normes d'ingénierie respectueuses de la vie privée qui éclairent chaque système construit ou modifié au sein de l'organisation.
Que dit le guide de mise en œuvre de l'annexe B ?
L’annexe B (section B.3.29) fournit les indications suivantes :
- Protection de la vie privée dès la conception et protection de la vie privée par défaut — Les systèmes ou composants liés au traitement des données personnelles doivent être conçus conformément aux principes de protection des données dès la conception et par défaut.
- Anticiper et faciliter les contrôles — L’architecture du système doit anticiper et faciliter la mise en œuvre des contrôles pertinents décrits dans B.1 (pour les contrôleurs PII) et B.2 (pour les processeurs PII).
- Minimiser le traitement des données personnelles — La collecte et le traitement des données personnelles dans ces systèmes devraient se limiter à ce qui est nécessaire aux fins identifiées du traitement
- Conception pour suppression Par exemple, une organisation qui traite des données personnelles doit s'assurer de les supprimer après une période déterminée. Le système qui traite ces données doit être conçu de manière à faciliter cette exigence de suppression.
- Voir aussi A.3.30 : Développement externalisé pour les exigences connexes
- Voir aussi A.3.31 : Informations sur les tests pour les exigences connexes
L'exemple de la suppression est particulièrement instructif : si un système n'est pas conçu dès le départ pour permettre la suppression des données, l'ajout ultérieur de cette fonctionnalité peut s'avérer extrêmement coûteux et complexe sur le plan technique. Ce même principe s'applique à la minimisation des données, à la gestion du consentement, à la portabilité des données et à toute autre exigence en matière de protection de la vie privée.
Comment cela se traduit-il au regard du RGPD ?
La commande A.3.29 correspond à ce qui suit GDPR article:
- Article 25 (1) — Protection des données dès la conception et par défaut, exigeant la mise en œuvre de mesures techniques et organisationnelles appropriées visant à appliquer efficacement les principes de protection des données et à intégrer les garanties nécessaires au traitement
A.3.29 fournit un cadre pratique pour satisfaire à l’exigence de l’article 25 selon laquelle la protection des données est prise en compte au niveau architectural et non seulement au niveau applicatif.
Qu’est-ce qui a changé par rapport à la norme ISO 27701:2019 ?
Pour une approche étape par étape, voir le Transition de 2019 à 2025.
Dans l'édition 2019, cette exigence était traitée par la clause 6.11.2.5 (principes d'ingénierie des systèmes sécurisés). L'édition 2025 conserve les exigences fondamentales en A.3.29, les recommandations de mise en œuvre (B.3.29) établissant un lien plus clair avec les principes de protection des données dès la conception et les contrôles spécifiques du contrôleur et du processeur que l'architecture système doit anticiper. Voir le Tableau de correspondance de l'annexe F pour la cartographie complète.
Libérez-vous d'une montagne de feuilles de calcul
Intégrez, développez et faites évoluer votre conformité, sans complications. IO vous offre la résilience et la confiance nécessaires pour croître en toute sécurité.
Quelles preuves les auditeurs attendent-ils ?
Lors de l'évaluation de la conformité à la norme A.3.29, les auditeurs recherchent généralement :
- Principes d'ingénierie documentés — Un ensemble de principes d'ingénierie des systèmes sécurisés documentés qui traitent de la protection des données personnelles, notamment la minimisation des données, la limitation des finalités, la limitation du stockage et la sécurité par défaut
- Archives d'examen architectural — Preuve que les architectures système sont examinées au regard des principes documentés avant que le développement ne puisse commencer.
- Modèles de conception respectueux de la vie privée — Modèles de conception documentés ou architectures de référence que les équipes de développement utilisent comme modèles, intégrant les exigences de protection des données personnelles
- Conception pour le cycle de vie des données — Preuves que les systèmes sont conçus pour prendre en charge l'intégralité du cycle de vie des données personnelles, y compris la collecte, le traitement, le stockage, la suppression et les droits des personnes concernées.
- Respect des principes — Documents attestant que les principes d'ingénierie sont revus et mis à jour périodiquement ou en réponse à des modifications des exigences en matière de protection de la vie privée
Quelles sont les commandes associées ?
| Contrôle | Lien familial |
|---|---|
| A.3.27 Cycle de vie du développement sécurisé | Les processus de développement doivent mettre en œuvre les principes d'ingénierie |
| A.3.28 Exigences de sécurité de l'application | Les exigences de l'application doivent être conformes aux principes architecturaux |
| A.1.2.6 Évaluation de l'impact sur la vie privée | Les analyses d'impact sur la protection des données (AIP) identifient les risques liés à la protection de la vie privée que les principes d'ingénierie doivent prendre en compte. |
| A.1.4.5 Objectifs de minimisation des informations personnelles identifiables | L'architecture système devrait imposer la minimisation des données par défaut. |
| A.1.4.6 Dé-identification et suppression | Les systèmes doivent être architecturalement capables de prendre en charge les exigences de suppression |
À qui s'applique ce contrôle ?
A.3.29 est un contrôle partagé Cela s'applique aussi bien aux responsables du traitement qu'aux sous-traitants des données personnelles. Toute organisation développant des systèmes d'information pour le traitement des données personnelles doit établir et maintenir des principes d'ingénierie. Le contrôle exige l'application de ces principes à « toute activité de développement de système d'information », ce qui signifie qu'il ne s'agit pas de lignes directrices facultatives, mais de normes obligatoires pour tous les travaux de développement.
Gérez toute votre conformité, en un seul endroit
ISMS.online prend en charge plus de 100 normes et réglementations, vous offrant une plate-forme unique pour tous vos besoins de conformité.
Pourquoi nous choisir ISMS.en ligne pour la conformité de l'architecture système sécurisée ?
ISMS.en ligne fournit des outils pratiques pour gérer vos principes d'ingénierie sécurisée :
- Registre des principes — Documentez et tenez à jour vos principes d'ingénierie de sécurité dans un registre central et versionné auquel les équipes de développement peuvent se référer.
- flux de travail d'examen architectural — Créez des processus de revue qui exigent que les conceptions de systèmes soient évaluées par rapport à vos principes d'ingénierie avant le début du développement.
- Intégration DPIA — Intégrer les analyses d'impact sur la protection des données aux décisions d'architecture système, en veillant à ce que les risques pour la protection de la vie privée identifiés dans l'AIPD soient pris en compte dans la conception
- Cartographie de la conformité — Mettez en correspondance vos principes d'ingénierie avec les contrôles de la norme ISO 27701, GDPR Article 25 et autres exigences du cadre de protection de la vie privée
- Réviser la planification — Planifiez des révisions périodiques de vos principes d'ingénierie grâce à des rappels automatisés et un système de contrôle de version.
Questions fréquentes
Quelle est la différence entre le cycle de vie de développement sécurisé A.3.27 et A.3.29 ?
A.3.27 Cycle de vie du développement sécurisé Le point A.3.29 couvre le cycle de vie du développement sécurisé, c'est-à-dire les processus et procédures suivis par les équipes de développement. Le point A.3.29 traite des principes d'ingénierie, c'est-à-dire les normes architecturales et les modèles de conception qui définissent l'architecture des systèmes. A.3.27 Cycle de vie du développement sécurisé comme « comment nous construisons » et A.3.29 comme « ce vers quoi nous construisons ». Les deux fonctionnent ensemble : processus de développement (A.3.27 Cycle de vie du développement sécurisé) devrait faire respecter l’application des principes d’ingénierie (A.3.29).
Quels sont des exemples de principes d'ingénierie de sécurité pour les informations personnelles identifiables (IPI) ?
Voici quelques exemples : collecter uniquement les champs d’informations personnelles nécessaires à la finalité déclarée ; chiffrer par défaut les informations personnelles au repos et en transit ; concevoir des schémas de base de données permettant la suppression granulaire d’enregistrements individuels ; mettre en œuvre la gestion du consentement au niveau des données, et non seulement au niveau de l’interface utilisateur ; consigner tous les événements d’accès aux informations personnelles ; utiliser un contrôle d’accès basé sur les rôles pour limiter l’accès aux informations personnelles au personnel autorisé ; concevoir des API ne renvoyant que les informations personnelles minimales nécessaires à chaque cas d’utilisation ; et intégrer l’automatisation de la conservation des données au système dès son lancement.
À quelle fréquence faut-il réviser les principes d'ingénierie ?
Les principes d'ingénierie doivent être revus au moins une fois par an et systématiquement en cas de modifications importantes de la législation sur la protection des données, des activités de traitement des données personnelles au sein de l'organisation, de l'architecture technologique ou du contexte des menaces. Cette revue doit permettre de vérifier si les principes restent pertinents, efficaces et conformes aux obligations de l'organisation en matière de protection des données. Toute mise à jour doit être communiquée aux équipes de développement et intégrée aux listes de contrôle des revues d'architecture.
Les plateformes SaaS peuvent trouver des conseils personnalisés dans notre guide pour les plateformes SaaS.
