Que requiert le contrôle A.3.28 ?
Les exigences en matière de sécurité de l'information relatives au traitement des données personnelles doivent être identifiées, spécifiées et approuvées lors du développement ou de l'acquisition d'applications.
Cette commande se trouve à l'intérieur de Contrôles de sécurité partagés L’annexe (A.3) exige une approche structurée pour définir les exigences de sécurité des applications traitant des données personnelles. Ceci s’applique aussi bien aux applications développées en interne qu’à celles acquises auprès de tiers. Le terme clé est « approuvé » : les exigences de sécurité doivent non seulement être identifiées et documentées, mais également faire l’objet d’une validation formelle avant tout développement ou acquisition.
Que dit le guide de mise en œuvre de l'annexe B ?
L’annexe B (section B.3.28) fournit les indications suivantes :
- Chiffrement pour les réseaux non fiables — L’organisation doit s’assurer que les informations personnelles transmises sur des réseaux de transmission de données non sécurisés sont chiffrées avant leur transmission.
- Définition des réseaux non fiables — Les réseaux non fiables peuvent inclure l'internet public et d'autres infrastructures hors du contrôle opérationnel de l'organisation.
- Limites pratiques — Dans certains cas (par exemple, l'échange de courriels), les caractéristiques inhérentes aux systèmes de réseaux de transmission de données non fiables peuvent exiger que certaines données d'en-tête ou de trafic soient exposées pour une transmission efficace.
- Voir aussi A.3.29 : Principes d’architecture et d’ingénierie des systèmes sécurisés pour les exigences connexes
- Voir aussi A.3.30 : Développement externalisé pour les exigences connexes
Ces recommandations portent spécifiquement sur le chiffrement des données en transit, considéré comme une exigence de sécurité de base pour les applications. Cela tient compte du fait que les applications traitant des données personnelles transmettent presque toujours des données sur les réseaux, et que le chiffrement constitue la protection fondamentale contre l'interception. La prise en compte des limitations pratiques (telles que les en-têtes de courriel) témoigne d'une approche pragmatique : la norme reconnaît que toutes les données ne peuvent pas être chiffrées en toutes circonstances.
Comment cela se traduit-il au regard du RGPD ?
La commande A.3.28 correspond à ce qui suit GDPR des articles:
- Article 5(1)(f) — Le principe d’intégrité et de confidentialité, qui exige une sécurité appropriée des données personnelles
- Article 32 (1) a) — L’obligation de mettre en œuvre des mesures techniques et organisationnelles appropriées, y compris le chiffrement des données personnelles
Ces deux articles soutiennent le principe selon lequel les applications traitant des données personnelles doivent intégrer dès leur conception des mesures de sécurité appropriées, et non les ajouter après coup.
Pour la correspondance complète entre le RGPD et la norme ISO 27701, voir Guide de conformité au RGPD.
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 les clauses 6.11.1.2 (sécurisation des services applicatifs sur les réseaux publics) et 6.11.1.3 (protection des transactions des services applicatifs). L'édition 2025 les regroupe dans la clause A.3.28, dont le champ d'application est plus large et couvre l'ensemble des exigences de sécurité des applications, et non plus seulement la sécurité des réseaux publics et des transactions. Voir le Tableau de correspondance de l'annexe F pour la cartographie complète.
Commencer votre essai gratuit
Envie d'explorer ?
Inscrivez-vous pour votre essai gratuit dès aujourd'hui et découvrez toutes les fonctionnalités de conformité qu'ISMS.online a à offrir.
Quelles preuves les auditeurs attendent-ils ?
Lors de l'évaluation de la conformité à la norme A.3.28, les auditeurs recherchent généralement :
- Spécification des exigences de sécurité — Exigences de sécurité documentées pour chaque application traitant des informations personnelles identifiables (IPI), couvrant l'authentification, l'autorisation, le chiffrement, la validation des entrées, la journalisation et le traitement des données.
- Dossiers d'approbation — Preuve que les exigences de sécurité ont été formellement examinées et approuvées par une autorité compétente (par exemple, l'équipe de sécurité, le DPO ou le comité d'examen de l'architecture) avant le développement ou l'acquisition.
- Chiffrement en transit — Preuve que toutes les applications transmettant des informations personnelles identifiables sur des réseaux non sécurisés utilisent TLS 1.2 ou une version supérieure, avec des certificats correctement configurés.
- Évaluation de la sécurité des achats — Pour les applications acquises, la preuve que les exigences de sécurité des données personnelles étaient incluses dans les critères d'acquisition et que le produit sélectionné y répond.
- Tests de sécurité — Preuves que les applications ont été testées conformément à leurs exigences de sécurité, notamment par des tests d'intrusion ou des analyses de code de sécurité.
Quelles sont les commandes associées ?
| Contrôle | Lien familial |
|---|---|
| A.3.27 Cycle de vie du développement sécurisé | Les exigences de sécurité des applications alimentent le processus de développement sécurisé |
| A.3.26 Utilisation de la cryptographie | Les exigences cryptographiques des applications sont régies par la politique de cryptographie. |
| A.3.23 Authentification sécurisée | L'authentification est une exigence de sécurité applicative essentielle |
| A.3.10 Accords avec les fournisseurs | Les applications acquises doivent satisfaire aux exigences de sécurité spécifiées dans les accords avec les fournisseurs. |
| A.3.25 Exploitation forestière | Les exigences de journalisation des applications doivent être définies dans le cadre des spécifications de sécurité. |
À qui s'applique ce contrôle ?
A.3.28 est un contrôle partagé Cela s'applique aussi bien aux responsables du traitement qu'aux sous-traitants de données personnelles. Toute organisation qui développe ou acquiert des applications de traitement de données personnelles doit identifier et approuver les exigences de sécurité avant de poursuivre. Cela concerne les applications web, les applications mobiles, les API, les outils internes, les solutions SaaS et tout autre logiciel traitant des données personnelles.
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 gestion de la sécurité des applications ?
ISMS.en ligne fournit des outils pratiques pour la gestion des exigences de sécurité des applications :
- Modèles d'exigences — Modèles d'exigences de sécurité prédéfinis pour les types d'applications courants, personnalisables selon les besoins spécifiques de votre organisation en matière de traitement des données personnelles.
- Flux de travail d'approbation — Intégrer les exigences de sécurité des achemins dans des processus formels d'examen et d'approbation, avec piste d'audit et suivi des signatures.
- Évaluation des fournisseurs — Évaluez les applications tierces par rapport à vos exigences de sécurité à l'aide de questionnaires structurés et d'un système de notation.
- Évaluations des risques — Effectuez des évaluations des risques au niveau applicatif qui alimentent directement vos exigences de sécurité, en veillant à ce que ces exigences soient proportionnées au risque.
- Gestion des preuves — Stockez les résultats des tests de sécurité, les rapports d'approbation et les preuves de conformité dans un format structuré et prêt pour l'audit, lié à chaque application.
Questions fréquentes
Quelles exigences de sécurité doivent être spécifiées pour les applications de traitement des données personnelles identifiables (PII) ?
Les applications traitant des données personnelles doivent au minimum respecter des exigences relatives à : l’authentification et l’autorisation (qui peut accéder aux données personnelles et à quel niveau), le chiffrement des données au repos et en transit, la validation des entrées et l’encodage des sorties (afin de prévenir les attaques par injection), la gestion des sessions, la journalisation et les pistes d’audit, la gestion des erreurs (afin d’éviter la fuite de données personnelles dans les messages d’erreur), la conservation et la suppression des données, ainsi que la gestion du consentement le cas échéant. Ces exigences doivent être proportionnées à la sensibilité des données personnelles et au profil de risque de l’application.
Comment ce contrôle s'applique-t-il à l'approvisionnement en SaaS ?
Lors de l'acquisition d'applications SaaS traitant des données personnelles, l'organisation doit intégrer les exigences de sécurité des données personnelles dans ses critères d'évaluation. Cela comprend l'évaluation des pratiques de chiffrement du fournisseur, des options d'authentification, de la résidence des données, des contrôles d'accès, des capacités de journalisation et des certifications de conformité. L'évaluation doit être documentée et approuvée avant la décision d'achat. La conformité continue doit être surveillée par le biais des processus de gestion des fournisseurs.A.3.10 Accords avec les fournisseurs).
Que signifie l'expression « réseaux non fiables » ?
Les réseaux non fiables comprennent l'Internet public et toute infrastructure réseau échappant au contrôle opérationnel direct de l'organisation. Cela peut inclure les fournisseurs de services réseau tiers, le Wi-Fi public, les réseaux de données mobiles et les liaisons intersites transitant par des infrastructures publiques. En matière de données personnelles, il est prudent de considérer comme non fiable tout réseau échappant au contrôle physique et logique direct de votre organisation et de chiffrer en conséquence toutes les transmissions de données personnelles.
Les plateformes SaaS peuvent trouver des conseils personnalisés dans notre guide pour les plateformes SaaS.
Documentez ce contrôle dans votre Déclaration d'applicabilité.
