Les mesures d’application de l’ICO contre les organisations britanniques ont fortement augmenté en 2024 et 2025, avec des amendes totalisant plus de 12 millions de livres sterling sur ces deux années pour des manquements aux mesures de sécurité techniques. Le schéma dans les avis d’application de l’ICO est cohérent : les organisations qui ont subi une violation et n’ont pas pu démontrer qu’elles avaient mis en place des contrôles techniques appropriés ont fait face aux conséquences les plus sévères. Pour les développeurs, c’est une préoccupation professionnelle directe. Les décisions que vous prenez concernant le chiffrement, la journalisation, le contrôle d’accès et la conservation des données sont les contrôles techniques qui déterminent si une organisation peut se défendre devant l’ICO.

Ce guide est rédigé pour les développeurs et les équipes d’ingénierie, et non pour les services juridiques ou de conformité. Il traduit les exigences du RGPD britannique en décisions techniques concrètes : quoi implémenter, comment l’implémenter et pourquoi chaque mesure existe.

En résumé

  • L’Article 32 du RGPD britannique exige des “mesures techniques appropriées” proportionnelles au risque. Pour la plupart des applications traitant des données personnelles, cela signifie le chiffrement au repos et en transit, la pseudonymisation lorsque c’est possible, des contrôles d’accès et une capacité documentée de détection des violations.
  • Les erreurs les plus courantes des développeurs qui créent une exposition au RGPD : journaliser des données personnelles dans la sortie de débogage, supprimer de manière logique des enregistrements qui devraient être supprimés définitivement pour le droit à l’effacement, et ne pas mettre en place des DPA avec chaque service tiers qui touche aux données personnelles.
  • La minimisation des données est une décision de conception prise au niveau du champ. Si vous n’avez pas de raison documentée pour collecter et stocker un champ, ne le collectez pas.
  • Le droit à l’effacement requiert une suppression réelle, en cascade à travers tous les systèmes, y compris les sauvegardes et les sous-traitants tiers. Les suppressions logiques ne satisfont pas l’obligation.

RGPD britannique vs RGPD européen : ce qui change pour les développeurs

Après le Brexit, le Royaume-Uni a conservé le cadre du RGPD de l’UE en tant que “UK GDPR” via le European Union (Withdrawal) Act 2018. Pour les développeurs, les exigences techniques sont identiques. Les différences sont administratives : l’autorité de contrôle au Royaume-Uni est l’Information Commissioner’s Office (ICO), et non une autorité nationale de protection des données de l’UE, et les transferts transfrontaliers entre le Royaume-Uni et l’UE sont régis par la décision d’adéquation britannique (actuellement maintenue par l’UE, bien que périodiquement réexaminée).

La conséquence pratique est que si vous créez des logiciels conformes aux exigences techniques du RGPD de l’UE, ils satisfont les exigences techniques du RGPD britannique. L’inverse est également vrai. Les divergences se produisent dans les procédures de notification, les mécanismes de transfert et les orientations d’application spécifiques de l’ICO, qui diffèrent parfois en emphase des orientations de l’EDPB.

Article 32 : ce qu’il exige réellement

L’Article 32 du RGPD britannique exige des responsables du traitement et des sous-traitants qu’ils mettent en place des “mesures techniques et organisationnelles appropriées” pour garantir un niveau de sécurité adapté au risque, en tenant compte de l’état de l’art, des coûts de mise en oeuvre et de la nature, de la portée, du contexte et des finalités du traitement.

Ce libellé est délibérément flexible. Ce qu’il signifie en pratique dépend de votre profil de risque, mais l’Article 32(1) donne quatre exemples spécifiques :

  1. Pseudonymisation et chiffrement des données personnelles
  2. Capacité à assurer en permanence la confidentialité, l’intégrité, la disponibilité et la résilience des systèmes de traitement
  3. Capacité à rétablir la disponibilité des données personnelles et l’accès à celles-ci dans des délais appropriés en cas d’incident physique ou technique
  4. Un processus pour tester, évaluer et apprécier régulièrement l’efficacité des mesures de sécurité

“L’état de l’art” ne signifie pas que vous devez implémenter la solution la plus coûteuse ou la plus récente. Cela signifie que vous ne pouvez pas justifier l’utilisation d’une approche faible (comme MD5 pour le hachage des mots de passe) lorsque de meilleures approches (comme Argon2) sont bien établies, largement disponibles et pas beaucoup plus coûteuses à implémenter.

Chiffrement au repos

Mots de passe. Ne stockez jamais les mots de passe en clair et n’utilisez jamais MD5 ou SHA-1 pour le hachage des mots de passe. Les deux sont totalement inadaptés. Utilisez bcrypt avec un facteur de travail d’au moins 12, ou Argon2id avec des paramètres calibrés pour prendre au moins 100 ms sur votre matériel serveur. Argon2id est la recommandation actuelle d’OWASP et est préférable pour les nouvelles implémentations.

1# Argon2id avec libsodium (exemple Node.js)
2const hash = await argon2.hash(password, {
3  type: argon2.argon2id,
4  memoryCost: 65536,   // 64 MB
5  timeCost: 3,
6  parallelism: 1
7});

Chiffrement de la base de données. Activez le chiffrement au repos au niveau de la base de données. Toutes les bases de données principales et les services gérés (PostgreSQL, MySQL, MongoDB Atlas, AWS RDS, Azure SQL) le prennent en charge. Le chiffrement transparent des données (TDE) protège les données sur le disque, mais ne protège pas contre un utilisateur de base de données compromis disposant d’un accès aux requêtes. Pour les champs très sensibles (numéros de sécurité sociale, dossiers médicaux, numéros de comptes financiers), envisagez un chiffrement au niveau des champs d’application en utilisant AES-256-GCM avec un service de gestion des clés (AWS KMS, Azure Key Vault, HashiCorp Vault). La clé doit être stockée séparément des données qu’elle chiffre.

Gestion des clés. Ne codez pas en dur les clés de chiffrement dans le code de l’application et ne les stockez pas dans la même base de données que les données qu’elles protègent. Utilisez des variables d’environnement pour le développement et un service de gestion des clés géré pour la production. Faites tourner les clés périodiquement et assurez-vous que votre application peut gérer la rotation des clés sans temps d’arrêt.

Ce qu’il ne faut pas faire. Ne stockez pas de données personnelles en clair dans les fichiers journaux, les fichiers temporaires ou les caches d’application où le chiffrement peut ne pas s’appliquer. Vérifiez chaque chemin de code qui gère des données personnelles et assurez-vous qu’il ne conserve pas par inadvertance des copies non chiffrées.

Chiffrement en transit

Configuration TLS. Imposez TLS 1.2 comme minimum, avec TLS 1.3 comme valeur par défaut là où c’est supporté. Désactivez complètement SSLv3, TLS 1.0 et TLS 1.1. Sur nginx :

1ssl_protocols TLSv1.2 TLSv1.3;
2ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
3ssl_prefer_server_ciphers off;

HSTS. Définissez l’en-tête Strict-Transport-Security avec une valeur max-age longue et includeSubDomains. Un max-age d’au moins 31536000 (un an) est la norme. Soumettez à la liste de préchargement HSTS si votre déploiement le permet.

1Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Contenu mixte. Servir une ressource (images, scripts, feuilles de style, appels API) en HTTP depuis une page HTTPS crée une vulnérabilité de contenu mixte et compromet la sécurité du transport. Configurez votre politique de sécurité du contenu pour bloquer le contenu mixte et vérifiez votre page pour tout chargement de ressource non HTTPS.

Services internes. Le chiffrement en transit s’applique également aux communications internes service à service ainsi qu’au trafic côté utilisateur. Les connexions de base de données, les connexions de files de messages et les appels de microservices doivent tous utiliser TLS. De nombreux développeurs chiffrent correctement la couche côté utilisateur et négligent le réseau interne.

Minimisation des données dans le code

La minimisation des données n’est pas une abstraction juridique. C’est une décision de conception prise champ par champ. Avant de collecter tout élément de données personnelles, demandez-vous : l’application a-t-elle réellement besoin de cela pour fonctionner ? Si vous ne pouvez pas répondre à cette question avec un cas d’usage spécifique, ne le collectez pas.

En pratique, cela signifie :

  • Supprimer les champs de formulaire qui sont optionnels et dont l’objectif est vague (ex. “date de naissance” sur une inscription à une newsletter où vous n’avez pas d’exigence de vérification d’âge)
  • Auditer régulièrement votre schéma de base de données et supprimer les colonnes qui contiennent des données personnelles sans utilisation active
  • Définir des périodes de conservation au niveau du schéma lorsque c’est possible, en utilisant des tâches planifiées pour purger automatiquement les enregistrements expirés
  • Éviter de collecter des données personnelles très sensibles (informations de santé, détails financiers, opinions politiques) sauf si votre application en a réellement besoin, car l’évaluation des risques de l’Article 32 évolue avec la sensibilité des données traitées

Le principe de responsabilité de l’ICO exige que vous puissiez démontrer que vous avez pris en compte la minimisation des données. Les décisions de conception documentées dans votre architecture ou dans les notes de sprint satisfont à cette exigence. Les décisions non documentées ne le font pas.

Pseudonymisation

La pseudonymisation remplace les informations directement identifiantes par un jeton ou un identifiant qui ne peut pas identifier la personne sans accès à une clé ou une table de correspondance conservée séparément. L’Article 32 la liste explicitement comme mesure technique recommandée, et l’Article 89 prévoit des obligations réduites pour le traitement de données pseudonymisées à des fins de recherche.

Pour l’analyse et le suivi du comportement, un schéma courant consiste à hacher les identifiants d’utilisateurs avec un sel spécifique au site en utilisant SHA-256 avant de les passer à votre système d’analyse :

1import hmac, hashlib
2
3def pseudonymise(user_id: str, site_secret: str) -> str:
4    return hmac.new(
5        site_secret.encode(),
6        user_id.encode(),
7        hashlib.sha256
8    ).hexdigest()

Le sel doit être stocké séparément des données analytiques. Sans lui, le hachage ne peut pas être inversé pour identifier la personne. Cela signifie que votre système d’analyse ne contient que des identifiants pseudonymisés, ce qui réduit le profil de risque d’une violation de ce système.

La pseudonymisation n’est pas l’anonymisation. Si vous détenez la clé de correspondance, l’ICO traite les données pseudonymisées comme des données personnelles. L’anonymisation complète, où la ré-identification n’est pas possible même avec des informations supplémentaires raisonnablement disponibles, retire les données du champ d’application du RGPD. Obtenir une véritable anonymisation est difficile en pratique ; la plupart des implémentations produisent des données pseudonymisées, qui relèvent toujours du RGPD mais avec un risque réduit.

Droit à l’effacement : mise en oeuvre correcte

Le droit à l’effacement (Article 17) est l’une des obligations RGPD les plus techniquement exigeantes à mettre en oeuvre correctement. Les exigences sont spécifiques :

Suppression définitive, pas logique. Définir un indicateur is_deleted et le filtrer des requêtes ne satisfait pas le droit à l’effacement. Les données doivent être réellement supprimées de la base de données. Construisez une fonctionnalité de suppression définitive pour chaque entité qui contient des données personnelles.

Suppressions en cascade. Supprimer l’enregistrement utilisateur n’est pas suffisant si des données personnelles sont également conservées dans des tables liées (commandes, adresses, journaux d’activité, préférences, fichiers téléchargés). Cartographiez chaque table qui contient des données personnelles liées à un identifiant utilisateur et assurez-vous que la suppression se fait correctement en cascade, ou implémentez un travail de suppression explicite qui supprime toutes les données associées de manière atomique.

Sous-traitants tiers. Si vous avez envoyé des données personnelles à un service tiers (plateforme de marketing par e-mail, CRM, outil d’analyse, processeur de paiement), votre obligation d’effacement s’étend à l’instruction à ce sous-traitant de supprimer les données. Cela nécessite :

  • Un inventaire documenté de chaque service tiers qui reçoit des données personnelles
  • Un mécanisme de suppression confirmé pour chacun (appel API, ticket de support, traitement automatisé des demandes des personnes concernées)
  • La preuve que la suppression a été effectuée

Sauvegardes. Les sauvegardes sont le problème d’effacement le plus souvent négligé. Si vous effectuez des sauvegardes quotidiennes de la base de données avec une période de rétention de 90 jours, une demande de suppression satisfaite dans la base de données en direct ne sera pas satisfaite dans les sauvegardes avant qu’elles n’expirent. La position de l’ICO est que les sauvegardes restaurées après un effacement ne doivent pas réintroduire les données personnelles supprimées. Les approches pratiques comprennent : exclure les enregistrements supprimés des exports de sauvegarde lorsque c’est possible, mettre en oeuvre des processus de purge spécifiques aux sauvegardes, ou utiliser le chiffrement au niveau des champs et supprimer la clé (rendant les données illisibles, ce qui se rapproche du standard de l’effacement).

Exemptions. Le droit à l’effacement n’est pas absolu. Vous pouvez conserver les données nécessaires aux demandes légales, à la conformité statutaire (par exemple, les registres financiers en vertu du Companies Act) ou aux finalités d’intérêt public. Documentez l’exemption et communiquez-la à la personne concernée lorsque vous refusez ou n’exécutez que partiellement une demande d’effacement.

Détection des violations et exigence de notification dans les 72 heures

L’Article 33 du RGPD britannique exige que vous notifia l’ICO dans les 72 heures suivant la prise de connaissance d’une violation de données personnelles susceptible d’engendrer un risque pour les personnes. Ce n’est pas 72 heures après que la violation s’est produite. C’est 72 heures à compter du moment où vous en avez pris connaissance. Cette distinction crée une incitation directe à développer une capacité de détection des violations, car l’horloge commence à tourner lorsque vous la découvrez.

Ce qu’il faut journaliser pour la détection des violations. Votre architecture de journalisation doit capturer :

  • Les événements d’authentification : connexions réussies et échouées, défis MFA, réinitialisations de mot de passe
  • Les échecs d’autorisation : les requêtes refusées en raison de vérifications d’autorisation
  • L’accès aux données : qui a accédé à quelles données personnelles et quand, en particulier les exports en masse ou les volumes de requêtes inhabituels
  • Les modifications de configuration : changements dans les permissions des utilisateurs, les clés de chiffrement ou les paramètres de conservation des données
  • Les schémas anormaux : accès depuis des adresses IP inhabituelles ou à des heures inhabituelles, lectures en grande quantité de tables de données personnelles

Ce qu’il ne faut pas journaliser. Ne journalisez pas les valeurs de données personnelles dans vos journaux d’application. Les journaux de débogage qui enregistrent des corps de requête complets, des requêtes de base de données avec des valeurs de paramètres substituées, ou des données de formulaire saisies par l’utilisateur créent des référentiels de données personnelles secondaires difficiles à gérer et qui relèvent eux-mêmes du RGPD. Journalisez des identifiants (ID d’utilisateur, ID de session, ID de requête) plutôt que des valeurs.

1# Incorrect : journalise l'adresse e-mail réelle
2logger.debug(f"Login attempt for user {request.form['email']}")
3
4# Correct : journalise uniquement un identifiant
5logger.debug(f"Login attempt, user_id={user.id}, request_id={request_id}")

Planification de la réponse aux violations. La journalisation permet la détection, mais vous avez besoin d’un processus documenté pour ce qui se passe lorsque vous détectez une violation. Qui est notifié en interne ? Qui prend la décision de notification à l’ICO ? Quelles informations la notification à l’ICO doit-elle contenir ? Construisez ce processus avant d’en avoir besoin.

Conformité des API tierces

Responsable du traitement vs sous-traitant. Si vous utilisez un service tiers qui traite des données personnelles en votre nom (un fournisseur d’e-mails transactionnels, un fournisseur d’infrastructure cloud, un processeur de paiement), il est un sous-traitant et vous êtes le responsable du traitement. Vous êtes responsable de leur conformité au RGPD britannique dans ce contexte.

Accords de traitement des données. Vous devez avoir un Accord de traitement des données (DPA) écrit en place avec chaque service tiers qui traite des données personnelles en votre nom. La plupart des grands fournisseurs SaaS (AWS, Mailchimp, Stripe, Twilio, SendGrid) proposent des DPA standard. Signez-les et conservez-les. Si un fournisseur ne peut pas produire un DPA, vous ne pouvez légalement pas l’utiliser pour traiter des données personnelles en vertu du RGPD britannique.

Sous-traitants secondaires. Votre DPA avec un sous-traitant doit lister ses sous-traitants secondaires (les services qu’il utilise à son tour pour traiter vos données). Par exemple, votre fournisseur d’e-mails transactionnels peut utiliser l’infrastructure AWS. Vous n’êtes pas obligé d’avoir un DPA direct avec les sous-traitants secondaires, mais vous devez être conscient de qui ils sont et où les données sont traitées géographiquement à des fins de conformité aux transferts.

Mécanismes de transfert. Si un service tiers traite des données en dehors du Royaume-Uni ou de l’UE, vous avez besoin d’un mécanisme de transfert légal en place. Pour les transferts depuis le Royaume-Uni, ce sont actuellement des mécanismes spécifiques au Royaume-Uni (accords de transfert international de données du Royaume-Uni, ou recours aux décisions d’adéquation du Royaume-Uni lorsqu’elles sont disponibles). Vérifiez les options de résidence des données et la documentation de transfert de chaque service.

Contrôle d’accès

Principe du moindre privilège. Les utilisateurs de la base de données utilisés par votre application doivent disposer des autorisations minimales requises : lecture et écriture sur des tables spécifiques, pas d’accès administratif. Créez des identifiants de base de données séparés pour les services à lecture intensive (rapports, analyses) et les services à écriture intensive (application côté utilisateur). Cela limite le rayon d’action d’un identifiant compromis.

Contrôle d’accès basé sur les rôles. Implémentez RBAC dans votre application et examinez régulièrement les attributions de rôles. Les rôles ont tendance à accumuler des permissions au fil du temps ; un audit périodique par rapport aux besoins réels de chaque rôle détecte l’escalade des privilèges.

Journaux d’audit pour l’accès aux données. Pour les données sensibles, implémentez une journalisation d’audit au niveau de la couche application qui enregistre quel utilisateur authentifié a accédé à quel enregistrement de données personnelles et quand. Cela est séparé de vos journaux d’erreurs d’application et doit être inviolable (en écriture seule ou en ajout uniquement, avec un accès restreint depuis le code de l’application).

Liste de contrôle pour les développeurs : 10 contrôles techniques à implémenter

  1. Hachage des mots de passe. Utilisez bcrypt (facteur de coût 12+) ou Argon2id. Supprimez immédiatement tout hachage de mot de passe MD5 ou SHA-1.
  2. Chiffrement au repos. Activez TDE au niveau de la base de données et implémentez le chiffrement au niveau des champs AES-256-GCM pour les données personnelles très sensibles avec des clés dans un KMS géré.
  3. Configuration TLS. Imposez TLS 1.2 minimum, TLS 1.3 par défaut, HSTS avec max-age d’un an, pas de contenu mixte.
  4. Audit de minimisation des données. Examinez chaque champ de votre schéma de base de données qui contient des données personnelles. Supprimez ou cessez de collecter tout champ sans cas d’usage documenté et actif.
  5. Mise en oeuvre de la suppression définitive. Créez une suppression en cascade vérifiée pour toutes les données personnelles liées à un utilisateur. Testez que la suppression supprime réellement les enregistrements et ne se contente pas de les marquer.
  6. Inventaire des DPA tiers. Répertoriez chaque SaaS ou service cloud qui reçoit des données personnelles. Confirmez l’existence d’un DPA signé pour chacun. Supprimez tout service qui ne peut pas en fournir un.
  7. Hygiène de journalisation. Auditez vos journaux d’application pour détecter les données personnelles. Supprimez les valeurs de données personnelles des sorties de journaux à chaque niveau de journalisation. Journalisez uniquement des identifiants.
  8. Journalisation pour la détection des violations. Implémentez une journalisation structurée pour les événements d’authentification, les échecs d’autorisation et l’accès aux données en masse. Configurez des alertes pour les schémas anormaux.
  9. Révision du contrôle d’accès. Auditez les identifiants de base de données et les rôles d’application par rapport au principe du moindre privilège. Supprimez l’accès administratif des utilisateurs de base de données de l’application.
  10. Pseudonymisation pour les analyses. Remplacez les identifiants directs d’utilisateurs dans les analyses et les appels de suivi tiers par des valeurs hachées HMAC utilisant un secret spécifique au site.

Points clés

  • Les exigences techniques du RGPD britannique sont identiques à celles du RGPD de l’UE. Après le Brexit, l’ICO les applique et vous devez suivre les orientations spécifiques de l’ICO pour les notifications et les transferts.
  • L’Article 32 exige des mesures techniques appropriées proportionnelles à votre risque. Pour la plupart des applications, cela signifie un chiffrement fort, des contrôles d’accès, la pseudonymisation et une détection documentée des violations.
  • La minimisation des données est une décision au niveau du champ prise par les développeurs, pas une abstraction juridique. Si vous ne pouvez pas justifier la collecte d’un champ, ne le collectez pas.
  • Le droit à l’effacement nécessite une suppression réelle en cascade à travers tous les systèmes, y compris les sauvegardes et les sous-traitants tiers. Un indicateur de suppression logique ne satisfait pas l’obligation.
  • Ne journalisez pas les valeurs de données personnelles. Journalisez des identifiants. Vos fichiers journaux sont eux-mêmes un référentiel de données personnelles et l’un des vecteurs de violation les plus souvent négligés.
  • Disposez d’un DPA signé avec chaque service tiers qui touche aux données personnelles. Si un fournisseur ne peut pas en produire un, vous ne pouvez légalement pas l’utiliser à cette fin.

Foire aux questions (FAQ)

Le RGPD britannique s’applique-t-il si tous mes utilisateurs sont en dehors du Royaume-Uni ? Le RGPD britannique s’applique si vous êtes établi au Royaume-Uni, indépendamment de l’emplacement de vos utilisateurs. Il s’applique également aux organisations en dehors du Royaume-Uni qui offrent des biens ou des services à des personnes au Royaume-Uni ou surveillent le comportement de personnes au Royaume-Uni. Si vous êtes un développeur basé au Royaume-Uni qui travaille pour un public non britannique, le RGPD britannique s’applique à vos activités de traitement.

Le chiffrement est-il obligatoire en vertu du RGPD britannique ? Le chiffrement est explicitement mentionné dans l’Article 32(1)(a) comme mesure recommandée. Ce n’est pas une exigence absolument obligatoire, car le règlement exige des mesures “appropriées au risque”. En pratique, pour toute application traitant des données personnelles sur Internet, il serait très difficile de justifier auprès de l’ICO le fait de ne pas chiffrer les données en transit et au repos. Traitez-le comme requis.

Qu’est-ce qui constitue une violation de données personnelles nécessitant une notification à l’ICO ? Une violation de données personnelles est toute destruction accidentelle ou illicite, toute perte, toute altération, toute divulgation non autorisée ou tout accès non autorisé à des données personnelles. Cela comprend un compartiment S3 mal configuré qui a exposé des enregistrements publiquement, une attaque de phishing qui a donné à un attaquant accès à votre compte e-mail contenant des données clients, et la suppression accidentelle d’enregistrements sans sauvegarde. Toutes les violations ne nécessitent pas une notification à l’ICO : seulement celles susceptibles d’engendrer un risque pour les personnes. Les violations à haut risque nécessitent également une notification directe aux personnes concernées.

Combien de temps devons-nous conserver les données personnelles ? Le RGPD britannique ne spécifie pas de périodes de conservation. Vous devez conserver les données uniquement aussi longtemps que nécessaire pour la finalité pour laquelle elles ont été collectées. Définissez des périodes de conservation pour chaque catégorie de données que vous détenez, documentez-les dans votre avis de confidentialité et implémentez une purge automatisée. Les registres financiers sont généralement conservés six ans en vertu du Companies Act. Les enregistrements de consentement marketing doivent être conservés jusqu’au retrait ou à l’expiration du consentement.

Avons-nous besoin d’un délégué à la protection des données ? Un DPO est obligatoire pour les autorités publiques, les organisations qui traitent des données personnelles sensibles à grande échelle et les organisations qui effectuent une surveillance systématique à grande échelle. Pour la plupart des sociétés de logiciels britanniques, un DPO n’est pas obligatoire mais est conseillé si vous traitez des volumes significatifs de données personnelles. L’ICO fournit des orientations spécifiques sur ce seuil sur son site Web.

Quelle est l’amende maximale pour non-conformité au RGPD britannique ? L’ICO peut émettre des amendes allant jusqu’à 17,5 millions de livres sterling ou 4 % du chiffre d’affaires annuel mondial (le montant le plus élevé étant retenu) pour les infractions les plus graves. Des amendes de niveau inférieur allant jusqu’à 8,7 millions de livres sterling ou 2 % du chiffre d’affaires mondial s’appliquent aux violations moins graves. En pratique, la plupart des amendes de l’ICO sont bien inférieures au maximum et sont calibrées en fonction de la gravité de la violation, de la coopération de l’organisation et des mesures prises pour remédier au problème.