---
name: "Modèle de registre des sous-traitants ultérieurs RGPD"
version: "1.0"
updated: "2026-07-24"
source: "https://www.orbiqhq.com/fr/modeles/modele-registre-sous-traitants-ulterieurs-rgpd"
license: "Utilisation et adaptation libres au sein de votre organisation. Attribution appréciée. Ne constitue pas un conseil juridique."
legal_basis:
  - "https://eur-lex.europa.eu/eli/reg/2016/679/oj"            # RGPD — art. 28(2), 28(3)(d), 28(4), 30(2), chapitre V
  - "https://eur-lex.europa.eu/eli/dec_impl/2021/914/oj"       # CCT pour les transferts vers des pays tiers
  - "https://www.edpb.europa.eu/documents/opinion-of-the-board-art-64/opinion-222024-on-certain-obligations-following-from-the_en"  # Avis 22/2024 du CEPD
---

# Modèle de registre des sous-traitants ultérieurs RGPD (lisible par machine)

Objet : maintenir la liste de sous-traitants ultérieurs qu'un sous-traitant doit tenir au titre
de l'article 28(2) du RGPD et de l'avis 22/2024 du CEPD — chaque sous-traitant ultérieur de la
chaîne avec identité, service, catégories de données, lieu de traitement, mécanisme de transfert
et garanties de sécurité — avec le journal des modifications (la piste de preuve des
notifications de l'article 28(2)) et le journal de diligence raisonnable (le dossier continu des
« garanties suffisantes » de l'article 28(1)). Ce fichier est autonome : un agent peut créer des
enregistrements du registre, générer la liste publique de sous-traitants ultérieurs, piloter les
notifications de changement et tenir le calendrier de diligence raisonnable à partir des
définitions ci-dessous.

Règles structurelles :
1. UN enregistrement de registre par sous-traitant ultérieur, Y COMPRIS les sous-traitants de
   rang inférieur plus bas dans la chaîne (avis 22/2024 du CEPD : le responsable du traitement
   doit pouvoir identifier chaque acteur de la chaîne). L'appartenance à la chaîne s'exprime avec
   `engaged_by` + `chain_tier`, jamais par omission.
2. Le registre est la SOURCE ; la page publique de sous-traitants ultérieurs / la liste du Trust
   Center est une projection des enregistrements dont `status` est dans {active, announced}. Les
   enregistrements ne sont jamais supprimés — un retrait bascule `status` sur `removed` et
   conserve l'historique.
3. Un nouvel engagement suit la séquence : enregistrement de diligence raisonnable (approuvé) →
   enregistrement du registre avec `status: announced` → enregistrement du journal des
   modifications avec notification envoyée → `status: active` seulement après expiration de
   `objection_deadline` sans opposition non résolue.
4. Ce registre n'est PAS un registre des activités de traitement (RGPD art. 30 — voir
   gdpr-ropa-template.md) et n'est PAS la notification de changement elle-même (voir
   gdpr-subprocessor-change-notice.md). Les trois fichiers se relient entre eux via
   `subprocessor_name` et `notice_ref`.

Notes juridictionnelles : le UK GDPR reprend l'article 28 tel quel (l'ICO attend une date limite
d'opposition explicite). La Norvège applique le RGPD via l'accord sur l'EEE
(personopplysningsloven, Datatilsynet). Les transferts EEE→Royaume-Uni reposent sur les décisions
d'adéquation britanniques renouvelées (prorogées en 2025, expiration 2031-12-27) ; un traitement
interne à l'EEE, Norvège comprise, ne nécessite aucun mécanisme de transfert. En France, la CNIL
(guide du sous-traitant + clausier type) attend que le responsable du traitement puisse identifier
à tout moment chaque sous-traitant ultérieur de la chaîne, le sous-traitant fournissant et
actualisant cette information en continu.

---

## 1. Registre des sous-traitants ultérieurs — un enregistrement par sous-traitant ultérieur de la chaîne

| # | Champ | Type | Définition / règle |
|---|---|---|---|
| 1 | `subprocessor_name` | texte, unique | CLÉ PRIMAIRE — dénomination sociale |
| 2 | `registered_address` | texte | Adresse du siège (CEPD 22/2024 : identité + adresse pour chaque acteur de la chaîne) |
| 3 | `country_of_establishment` | texte (ISO 3166-1 alpha-2) | Pays d'établissement de l'entité |
| 4 | `contact` | texte (e-mail/URL) | Contact vie privée/DPO du sous-traitant ultérieur |
| 5 | `service_description` | texte | Ce que fait le sous-traitant ultérieur et quel produit/service il soutient |
| 6 | `data_categories` | liste | Catégories de données personnelles traitées (p. ex. données de contact, données d'usage, contenus clients) |
| 7 | `special_categories` | enum : `yes` / `no` | Catégories particulières de l'art. 9 concernées ? Si `yes`, la diligence raisonnable et le niveau de détail de la notification augmentent |
| 8 | `processing_locations` | liste de pays | Là où les données sont effectivement traitées (pas le siège) |
| 9 | `transfer_mechanism` | enum | `none_eea_only` / `adequacy_decision` / `sccs_2021_914_plus_tia` / `binding_corporate_rules` / `other_art46_safeguard` / `art49_derogation_exceptional` |
| 10 | `transfer_detail` | texte | Quelle décision d'adéquation, ou module de CCT + date de TIA. Requis sauf si le mécanisme est `none_eea_only` |
| 11 | `security_guarantees` | texte | Certifications (ISO/IEC 27001, SOC 2) ou synthèse des TOM étayant l'art. 28(1) |
| 12 | `engaged_by` | texte | Parent dans la chaîne : `us` pour les sous-traitants ultérieurs directs, sinon le nom du (sous-)traitant qui engage |
| 13 | `chain_tier` | enum : `tier1` / `tier2` / `tier3_or_deeper` | Profondeur dans la chaîne de sous-traitance ultérieure |
| 14 | `flowdown_contract_date` | date (ISO 8601) | Date du contrat de répercussion de l'art. 28(4) imposant les mêmes obligations |
| 15 | `status` | enum | `announced` (délai d'opposition ouvert) / `active` / `offboarding` / `removed` |
| 16 | `effective_date` | date | Début effectif du traitement. Pour les enregistrements `announced`, elle DOIT être postérieure à `objection_deadline` |
| 17 | `last_verified` | date | Dernière revérification de diligence raisonnable (jointure vers le journal de diligence raisonnable) |
| 18 | `notice_ref` | texte | Dernier enregistrement du journal des modifications couvrant ce sous-traitant ultérieur |

## 2. Journal des modifications — un enregistrement par changement

| # | Champ | Type | Définition / règle |
|---|---|---|---|
| 1 | `notice_ref` | texte, unique | CLÉ PRIMAIRE, p. ex. `SUB-2026-002` |
| 2 | `notice_sent` | date | Date d'envoi de la notification aux responsables du traitement (en « push », pas une simple mise à jour de page) |
| 3 | `subprocessor_name` | texte | FK → registre |
| 4 | `change_type` | enum | `addition` / `replacement` / `removal` / `material_change` |
| 5 | `summary` | texte | Ce qui a changé, en termes lisibles par un responsable du traitement |
| 6 | `channels` | liste | p. ex. `email_subscribers`, `trust_center_update` — au moins un canal actif (push) requis |
| 7 | `controllers_scope` | texte | Quels responsables du traitement ont été notifiés (tous / segment) |
| 8 | `objection_deadline` | date | Date limite explicite ; la fenêtre est contractuelle (~15 jours typique, 30–60 négociés, 90 rares) |
| 9 | `objections_received` | entier | Nombre d'oppositions |
| 10 | `outcome` | enum | `window_open` / `no_objection_effective` / `workaround_agreed` / `objection_upheld_not_engaged` / `contract_terminated_by_controller` / `withdrawn` |
| 11 | `effective_date` | date | Date de prise d'effet du changement |
| 12 | `register_updated` | date | Date de mise à jour du registre/de la liste publique (doit être ≤ `notice_sent`) |
| 13 | `evidence_link` | texte | Document de notification archivé / journal d'envoi |

## 3. Journal de diligence raisonnable — un enregistrement par évaluation

| # | Champ | Type | Définition / règle |
|---|---|---|---|
| 1 | `subprocessor_name` | texte | FK → registre |
| 2 | `assessment_date` | date | Date de réalisation de l'évaluation |
| 3 | `assessor` | texte (rôle) | p. ex. DPO, responsable sécurité |
| 4 | `guarantees_reviewed` | texte | Ce qui a été examiné : certificats, rapports d'audit, TOM, historique de violations |
| 5 | `certifications_verified` | liste | p. ex. `ISO/IEC 27001:2022`, `SOC 2 Type II` — vérifier le périmètre + la validité, pas les logos |
| 6 | `toms_ref` | texte | Référence des mesures techniques et organisationnelles revues |
| 7 | `tia_date` | date ou `n/a` | Date de l'analyse d'impact des transferts — REQUISE quand `transfer_mechanism` = `sccs_2021_914_plus_tia` |
| 8 | `subsubprocessors_disclosed` | enum : `yes` / `no` | Le sous-traitant ultérieur a-t-il divulgué sa propre chaîne (le CEPD 22/2024 attend la visibilité de toute la chaîne) |
| 9 | `result` | enum | `approved` / `approved_with_conditions` / `rejected` |
| 10 | `conditions` | texte | Suites à donner, p. ex. option de routage en région UE, surveillance du statut DPF |
| 11 | `next_review_due` | date | La revérification est continue, pas ponctuelle |

---

## Indications de workflow pour agents

- Pour PUBLIER la liste publique : sélectionner les enregistrements du registre dont `status` est
  dans {`active`, `announced`}, projeter les champs 1, 3, 5, 6, 8, 9, 15, 16, et trier par
  `subprocessor_name`. Les enregistrements annoncés doivent afficher la date limite d'opposition.
- Pour AJOUTER un sous-traitant ultérieur : créer un enregistrement de diligence raisonnable ; si
  `result` != `rejected`, créer l'enregistrement du registre avec `status: announced`, générer la
  notification à partir de gdpr-subprocessor-change-notice.md, créer l'enregistrement du journal
  des modifications, et programmer la bascule de statut pour `objection_deadline + 1 jour`, sous
  condition que `objections_received` soit résolu.
- Pour VÉRIFIER la santé du registre : chaque enregistrement `active` doit avoir (a) un
  `last_verified` dans la cadence de revue, (b) une `flowdown_contract_date`, (c) un
  `transfer_detail` renseigné sauf si `transfer_mechanism` = `none_eea_only`, et (d) un
  `notice_ref` résoluble.
- Réserve DPF : les enregistrements s'appuyant sur le Data Privacy Framework UE–États-Unis
  doivent être marqués pour surveillance — le Tribunal de l'UE a rejeté le recours Latombe
  (2025-09-03), mais le pourvoi est pendant devant la CJUE ; les CCT + TIA restent l'option par
  défaut la plus résiliente pour les sous-traitants ultérieurs américains.

## Enregistrements d'exemple (fictifs — Aurora Software GmbH, SaaS B2B berlinois)

```yaml
- subprocessor_name: "Helvetia Cloud AG"
  registered_address: "Werdstrasse 2, 8004 Zürich, Switzerland"
  country_of_establishment: "CH"
  contact: "privacy@helvetiacloud.example"
  service_description: "Hébergement de production et stockage pour la plateforme Aurora (région UE)"
  data_categories: ["données de compte", "données d'usage", "contenus clients"]
  special_categories: "no"
  processing_locations: ["DE"]
  transfer_mechanism: "adequacy_decision"
  transfer_detail: "Adéquation Suisse (décision 2000/518/CE, confirmée lors du réexamen de 2024)"
  security_guarantees: "ISO/IEC 27001:2022, SOC 2 Type II"
  engaged_by: "us"
  chain_tier: "tier1"
  flowdown_contract_date: "2024-03-11"
  status: "active"
  effective_date: "2024-04-01"
  last_verified: "2026-05-14"
  notice_ref: "SUB-2024-001"

- subprocessor_name: "Frankfurt DC Ops GmbH"
  registered_address: "Hanauer Landstraße 300, Frankfurt, Germany"
  country_of_establishment: "DE"
  contact: "security@fdcops.example"
  service_description: "Exploitation de centre de données engagée par Helvetia Cloud AG"
  data_categories: ["contenus clients (chiffrés au repos)"]
  special_categories: "no"
  processing_locations: ["DE"]
  transfer_mechanism: "none_eea_only"
  transfer_detail: "—"
  security_guarantees: "ISO/IEC 27001:2022, ISO 22301"
  engaged_by: "Helvetia Cloud AG"
  chain_tier: "tier2"
  flowdown_contract_date: "2024-03-11"
  status: "active"
  effective_date: "2024-04-01"
  last_verified: "2026-05-14"
  notice_ref: "SUB-2024-001"
```