> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Classeur de preuves de conformité

> Générez un dossier de preuves en un clic pour SOC 2, ISO 27001, GDPR ou HIPAA — un classeur signé, prêt à télécharger, que votre auditeur ou l'équipe achats d'un client peut lire directement.

# Classeur de preuves de conformité

Le classeur de preuves transforme les données de conformité que votre espace de travail produit déjà — journaux d'audit, revues d'accès, registres de consentement, paramètres de rétention, compteurs d'incidents — en un dossier de preuves unique aligné sur un référentiel public, avec un seul téléchargement à remettre à un auditeur ou à la revue de sécurité d'un client.

Choisissez un référentiel, générez, téléchargez. Quatre référentiels sont pris en charge :

| Référentiel                               | Demande typique                                                                                                  |
| ----------------------------------------- | ---------------------------------------------------------------------------------------------------------------- |
| **SOC 2** (AICPA Trust Services Criteria) | Questionnaires de sécurité fournisseur et revues de préparation SOC 2                                            |
| **ISO 27001**                             | Preuves de contrôles de l'Annexe A pour certification ou attestations contractuelles                             |
| **GDPR**                                  | Historique des demandes des personnes concernées, compteurs d'incidents, posture de consentement et de rétention |
| **HIPAA**                                 | Journalisation des accès aux PHI, posture BAA, rétention configurée                                              |

Chaque génération est enregistrée dans votre journal d'audit, seuls les rôles propriétaire ou administrateur de l'espace de travail peuvent en générer une, et le téléchargement est un lien signé qui expire après 24 heures.

## Générer un classeur depuis le tableau de bord

1. Ouvrez **Paramètres → Conformité → Classeur**.
2. Choisissez le référentiel et le format de sortie — un **PDF** rendu pour les humains, ou un **ZIP** de fichiers par contrôle pour importer dans un outil GRC.
3. Sélectionnez **Générer**. La génération s'exécute en arrière-plan ; la page montre la tâche passer de *En attente* → *Génération* → *Terminée*.
4. Une fois terminée, utilisez le lien **Télécharger** sur la ligne de la tâche. Le lien est valable 24 heures ; s'il expire, régénérez ou ouvrez la tâche pour obtenir un nouveau lien.

Si une requête est déjà en cours pour le même référentiel, le tableau de bord affiche à nouveau cette tâche au lieu de mettre en file un doublon — les clics répétés sont sans risque.

Si la vérification d'intégrité d'audit de la plateforme a signalé quelque chose lors de la construction du dossier, le classeur s'ouvre avec une **bannière d'alerte de falsification** en haut. Traitez un classeur signalé comme falsifié comme un signal à examiner avant de le remettre à un tiers.

## Générer depuis l'API

```bash theme={null}
curl -X POST https://api.orbit.devotel.com/api/v1/compliance/binder/generate \
  -H "X-API-Key: dv_live_sk_..." \
  -H "Content-Type: application/json" \
  -d '{"orgId": "org_...", "framework": "soc2", "format": "pdf"}'
```

La réponse est `202` avec un identifiant de tâche :

```json theme={null}
{
  "data": { "jobId": "binder_...", "status": "pending", "dedup": false }
}
```

Interrogez la tâche jusqu'à son achèvement :

```bash theme={null}
curl https://api.orbit.devotel.com/api/v1/compliance/binder/binder_... \
  -H "X-API-Key: dv_live_sk_..."
```

Une tâche terminée porte `download_url` (lien signé de 24 heures), `download_sha256` pour la vérification du fichier, `download_size_bytes`, et `tamper_alert`. Listez les générations passées avec `GET /api/v1/compliance/binder?page=1`. Le catalogue des référentiels (noms, texte de périmètre, nombres de contrôles) est à `GET /api/v1/compliance/binder/frameworks`.

| Point de terminaison                       | Usage                                                   |
| ------------------------------------------ | ------------------------------------------------------- |
| `GET /api/v1/compliance/binder/frameworks` | Catalogue des référentiels pour le sélecteur            |
| `POST /api/v1/compliance/binder/generate`  | Mettre en file une génération (`202`)                   |
| `GET /api/v1/compliance/binder/:jobId`     | Statut, URL de téléchargement signée, somme de contrôle |
| `GET /api/v1/compliance/binder?page=`      | Historique des générations                              |

## SOC 2 — couverture des Trust Services Criteria

Le dossier SOC 2 parcourt les Common Criteria de l'AICPA **CC1.0 à CC9.0**, une section par catégorie. Chaque section associe le récit de politique de la plateforme à des lignes de preuve comptées à partir de la chaîne d'audit de votre propre espace de travail :

| Contrôle  | Catégorie                               | Exemples de lignes de preuve                                                                           |
| --------- | --------------------------------------- | ------------------------------------------------------------------------------------------------------ |
| **CC1.0** | Environnement de contrôle               | Âge de l'espace de travail en jours ; événements de changement de rôle sur les 12 derniers mois        |
| **CC2.0** | Communication et information            | Incidents enregistrés, triés ou résolus sur 12 mois                                                    |
| **CC3.0** | Évaluation des risques                  | Version actuelle du registre de risques de référence                                                   |
| **CC4.0** | Activités de surveillance               | Événements d'authentification sur 90 jours                                                             |
| **CC5.0** | Activités de contrôle                   | Déploiements en production sur 90 jours                                                                |
| **CC6.0** | Contrôles d'accès logiques et physiques | Date de la dernière revue d'accès ; revues d'accès achevées en 12 mois                                 |
| **CC7.0** | Opérations système                      | Dernière sauvegarde vérifiée ; posture de rétention des sauvegardes à 30 jours ; incidents sur 12 mois |
| **CC8.0** | Gestion des changements                 | Exécutions de build sur 90 jours ; posture de verrouillage des migrations                              |
| **CC9.0** | Atténuation des risques                 | Posture de chiffrement au repos et en transit ; liste publiée des sous-traitants                       |

Si la pré-vérification d'intégrité a échoué pendant la génération, l'alerte de falsification n'est pas une note de bas de page — elle s'affiche comme une bannière encadrée avant CC1.0, de sorte que la première chose que lit l'auditeur est que la relecture de la chaîne a trouvé des problèmes. Cet emplacement est délibéré : un lecteur doit voir la réserve avant toute ligne de preuve.

## ISO 27001 — correspondance des contrôles de l'Annexe A

Le dossier ISO/IEC 27001:2022 couvre les quatre catégories de contrôles de l'Annexe A plus deux clauses numérotées individuellement que les équipes achats demandent le plus souvent. Les lignes se répartissent en deux classes — **fixées par la plateforme** (identiques pour chaque espace de travail, héritant de la posture propre à la plateforme) et **dérivées de l'espace de travail** (comptées à partir des données de votre tenant au moment de la génération) :

| Correspondance Annexe A | Section                                           | Lignes fixées par la plateforme                                                                          | Lignes dérivées de l'espace de travail                                |
| ----------------------- | ------------------------------------------------- | -------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------- |
| **A.5**                 | Contrôles organisationnels                        | Ensemble de politiques documentées ; cadence annuelle de revue du SMSI                                   | Référence de tenant hachée                                            |
| **A.6**                 | Contrôles liés aux personnes                      | Vérification des antécédents, sensibilisation à la sécurité, SLA de sortie de 24 heures                  | —                                                                     |
| **A.7**                 | Contrôles physiques                               | Région de production (Google Cloud europe-west1) ; attestation d'hébergement                             | —                                                                     |
| **A.8**                 | Contrôles technologiques                          | Posture de chiffrement (CMEK + TLS 1.2+) ; chaîne d'audit inviolable                                     | Nombre de clés API actives ; compteur agrégé de registres de contacts |
| **A.5.19**              | Relations avec les fournisseurs                   | URL de la liste des sous-traitants ; délai de préavis de changement de 30 jours                          | —                                                                     |
| **A.5.30**              | Préparation des TIC pour la continuité d'activité | Cadence quotidienne de sauvegarde ; tests de restauration trimestriels ; référence du runbook de reprise | —                                                                     |

Les contrôles liés aux personnes et physiques n'ont pas de lignes dérivées de l'espace de travail parce que le tenant ne les opère pas — le classeur énonce la posture de la plateforme et le dit clairement, plutôt que d'insinuer une piste de preuves qu'il ne peut pas produire.

## GDPR — preuves article par article

Le dossier GDPR cartographie les articles qu'une autorité de contrôle, un DPO ou l'équipe vie privée d'un client demande. Les compteurs qu'il assemble proviennent des mêmes surfaces que vous opérez au quotidien :

| Article     | Sujet                                                 | Lignes de preuve que le classeur assemble                                                                           | Surface du quotidien                                                        |
| ----------- | ----------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------- |
| **Art. 6**  | Base légale du traitement                             | Bases légales prises en charge dans vos registres de consentement                                                   | [Gestion du consentement](/compliance/consent-management)                   |
| **Art. 15** | Droit d'accès (DSAR)                                  | Totaux DSAR par statut ; durée médiane de traitement face à la limite légale de 30 jours                            | [DSAR](/compliance/dsar)                                                    |
| **Art. 17** | Droit à l'effacement                                  | Demandes d'effacement par statut (exécutées, en attente/en cours, annulées) ; la fenêtre de rétractation de 7 jours | [DSAR](/compliance/dsar)                                                    |
| **Art. 28** | Sous-traitants                                        | Liste publiée des sous-traitants ; délai de préavis de changement de 30 jours                                       | [Accord de traitement des données](/compliance/data-processing-agreement)   |
| **Art. 30** | Registre des activités de traitement                  | Catégories de personnes concernées et de données personnelles ; la rétention des messages par défaut de 365 jours   | [Registre de confidentialité (ROPA + DPIA)](/compliance/privacy-register)   |
| **Art. 32** | Sécurité du traitement                                | Posture de chiffrement ; pseudonymisation des sujets de la chaîne d'audit ; exercices de reprise trimestriels       | [Juridique](/legal/index)                                                   |
| **Art. 33** | Notification des violations                           | Événements de violation notifiables sur 12 mois ; le SLA de notification de 72 heures                               | [Registre des incidents de violation](/compliance/breach-incident-register) |
| **Art. 35** | Analyse d'impact relative à la protection des données | Contact du DPO ; disponibilité du modèle de DPIA                                                                    | [Registre de confidentialité (ROPA + DPIA)](/compliance/privacy-register)   |

La posture de consentement entre dans l'Art. 6 sous forme agrégée (quelles bases légales apparaissent dans vos [registres de consentement](/compliance/consent-management)) — jamais sous forme de lignes d'octroi individuelles, car le classeur est destiné à des parties qui ne doivent pas recevoir les identifiants de vos contacts. L'historique DSAR et les compteurs d'effacement agrègent la [file DSAR](/compliance/dsar) par statut ; le [registre de confidentialité](/compliance/privacy-register) détient les catégories d'Art. 30 et la posture DPIA d'Art. 35 que les Art. 30 et Art. 35 reformulent en lignes de preuve.

## HIPAA — sauvegardes et posture BAA

Le dossier HIPAA parcourt les sauvegardes de la Security Rule (45 CFR §§ 164.302–318) ainsi que la Breach Notification Rule, et lit la configuration HIPAA de votre espace de travail depuis les mêmes réglages que la référence [Contrôles HIPAA](/compliance/hipaa) décrit :

| Section                         | Sauvegarde                           | Lignes de preuve                                                                                                                                                   |
| ------------------------------- | ------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **§ 164.308**                   | Sauvegardes administratives          | Mode HIPAA activé/désactivé ; date d'exécution du BAA ; contact du responsable de la sécurité                                                                      |
| **§ 164.310**                   | Sauvegardes physiques                | Région de production ; posture de sécurité des postes de travail                                                                                                   |
| **§ 164.312**                   | Sauvegardes techniques               | Événements d'accès aux PHI sur 90 jours ; posture de chiffrement ; déclaration d'intégrité de la chaîne d'audit                                                    |
| **§ 164.314**                   | Exigences organisationnelles (BAA)   | Si un BAA du tenant est enregistré ; événements liés au BAA sur 12 mois                                                                                            |
| **§ 164.316**                   | Documentation                        | Votre fenêtre de rétention des PHI configurée (ou la valeur par défaut de la plateforme de 365 jours si non définie) ; la posture du journal d'audit en ajout seul |
| **Notification des violations** | Règle de notification des violations | Événements de violation de PHI sur 12 mois ; le SLA de notification de 60 jours                                                                                    |

La date du BAA et la fenêtre de rétention affichées dans le classeur sont les valeurs définies dans **Paramètres → Conformité → HIPAA**. Mettez-les à jour avant de générer — le [guide de démarrage HIPAA](/guides/hipaa-onboarding) ordonne l'exécution du BAA, l'activation du mode HIPAA, la restriction des rôles et la rétention dans l'ordre attendu par le dossier.

## Lecture du dossier

Chaque classeur, quel que soit le référentiel, se compose des trois mêmes couches :

1. **Récit statique par contrôle** — la politique de la plateforme pour ce contrôle, énoncée une fois. Ce texte est identique d'un espace de travail à l'autre à dessein : il décrit le comportement de la plateforme, et seul un changement de comportement de la plateforme (pas une régénération sur des données inchangées) le modifie.
2. **Lignes de preuve du tenant par contrôle** — compteurs agrégés et posture qui diffèrent par espace de travail : volume du journal d'audit, répartition des rôles de l'équipe, compteurs de statuts DSAR et d'effacement, nombres de clés API actives, incidents répertoriés, rétention configurée. Un contrôle sans rien d'applicable aujourd'hui affiche « Aucune preuve propre au tenant enregistrée pour ce contrôle » plutôt qu'un tableau vide.
3. **Résumé d'intégrité dans l'en-tête** — combien de lignes de la chaîne d'audit ont été relues et vérifiées pendant la construction du dossier. Une rupture de chaîne ne bloque pas la génération ; elle fait basculer le classeur sur la bannière d'alerte de falsification pour que le lecteur le sache d'emblée.

Les preuves sont rédigées par construction : compteurs agrégés et références hachées uniquement, jamais de numéros de téléphone, d'adresses e-mail, de noms de clients, de corps de messages, de clés API ou de secrets de webhook. Un classeur peut être transmis en toute sécurité à l'équipe achats d'un client.

Deux générations sur les mêmes données produisent une sortie identique à l'octet près, et les dossiers terminés portent une somme de contrôle SHA-256 — un auditeur peut donc vérifier que le fichier reçu est bien le fichier que vous avez généré, et une régénération des mois plus tard reste comparable ligne par ligne.

## Runbook opérationnel

**Importer dans un outil GRC.** Générez avec `format: "zip"`. Le ZIP contient un `00_README.md` (le résumé d'intégrité et les métadonnées de génération) plus un fichier Markdown par contrôle — `01_CC1_0.md`, `02_CC2_0.md`, … (SOC 2), `01_A_5.md`, … (ISO 27001), les identifiants d'articles pour GDPR, et les identifiants de sections pour HIPAA. Chaque fichier porte le récit du contrôle et un tableau `| Evidence | Value |`, qui est la forme que les plateformes de conformité (importateurs de classe SecureFrame, de classe Drata) analysent lors d'un dépôt de dossier.

**Comparer deux générations.** La sortie étant déterministe, comparer deux ZIP isole exactement ce qui a changé : une liste de fichiers identique avec des sommes de contrôle identiques signifie « aucun changement pertinent pour la conformité » ; un fichier de contrôle modifié ramène le delta à un seul contrôle ; un `00_README.md` différent avec des fichiers de contrôle identiques signifie que seul le nombre de lignes de la chaîne d'audit a bougé. Régénérez à une cadence fixe et conservez chaque SHA-256 de la réponse de statut de la tâche pour que la comparaison soit une égalité de sommes de contrôle, pas une lecture manuelle.

**Traiter un signalement de falsification.** Ouvrez le classeur signalé et notez le nombre de problèmes dans la bannière. Vérifiez si une génération ultérieure efface le signalement — l'alerte couvre une fenêtre de relecture glissante de 12 mois, donc un problème résolu s'efface une fois qu'il en sort. Si le signalement persiste, gardez le classeur en interne et contactez [security@devotel.io](mailto:security@devotel.io) avant de l'acheminer vers un auditeur ; le fichier reste une preuve de *votre* chronologie, mais il ne devrait jamais être remis sans que la réserve ait été discutée d'abord.

## Exemple concret — questionnaire fournisseur SOC 2

Le portail achats d'un client liste une question par catégorie des Trust Services Criteria et accepte une pièce jointe facultative. Le classeur répond à l'emplacement de pièce jointe que le questionnaire laisse ouvert :

1. **Paramètres → Conformité → Classeur**, choisissez **SOC 2**, format **PDF**, sélectionnez **Générer**.
2. Attendez *Terminée* et téléchargez le dossier.
3. Lisez d'abord le résumé d'intégrité dans l'en-tête. Si la bannière est présente, résolvez-la (runbook ci-dessus) avant de continuer.
4. Faites correspondre les catégories du questionnaire aux sections du classeur une à une : « Gouvernance » → CC1.0, « Personnes » → CC2.0/CC6.0, « Gestion des changements » → CC8.0, et ainsi de suite de CC1.0 à CC9.0.
5. Joignez le PDF. Lorsqu'une question exige un chiffre — « quand a eu lieu votre dernière revue d'accès ? » — la réponse est la ligne de preuve, citée textuellement (`Last access review: 2026-07-31T…`).
6. Enregistrez le `download_sha256` de la tâche dans le champ de notes du questionnaire. Le client peut re-hacher la pièce jointe et confirmer que le document reçu est celui que vous avez généré.

## Exemple concret — dossier de réponse à une autorité GDPR

Une autorité de contrôle demande en une seule réponse la documentation des activités de traitement, le traitement des demandes des personnes concernées et la posture en matière de violations :

1. Mettez à jour les surfaces sources : les statuts de la [file DSAR](/compliance/dsar), les entrées du [registre de confidentialité](/compliance/privacy-register), et le [registre des incidents de violation](/compliance/breach-incident-register).
2. Générez **GDPR** en **ZIP** — l'ingestion du système de gestion des dossiers de l'autorité analyse généralement mieux des fichiers par article qu'un PDF unique.
3. Le chapitre Art. 30 répond à « ce que vous traitez » ; les chapitres Art. 15 et Art. 17 répondent à « comment vous traitez les demandes » avec des médianes de traitement face aux 30 jours légaux ; le chapitre Art. 33 répond à « comment vous le sauriez et notifieriez » avec le compteur de violations sur 12 mois et le SLA de 72 heures.
4. Citez le compteur Art. 33 avec sa fenêtre (« violations notifiables sur les 12 derniers mois ») — le classeur rapporte des compteurs glissants, pas des totaux historiques.
5. Joignez le ZIP et conservez le SHA-256 avec votre dossier. Si l'autorité revient pour un suivi, régénérez une fois la fenêtre déplacée et comparez les deux ZIP (runbook ci-dessus) pour énumérer exactement ce qui a changé.

## Limites

* **L'URL signée expire après 24 heures.** Le lien de téléchargement de la ligne de tâche cesse de fonctionner après un jour ; ouvrez la tâche pour un nouveau lien ou régénérez — l'historique conserve l'enregistrement de la tâche dans les deux cas.
* **Rôle propriétaire ou administrateur requis.** La génération (et la lecture du statut de la tâche) est réservée aux propriétaires et administrateurs de l'espace de travail, y compris via les clés API ; les super-administrateurs Devotel peuvent aussi générer contre un espace de travail, par exemple sur une demande de support.
* **Chaque action est journalisée.** La mise en file écrit une entrée `compliance.binder_generated` dans votre journal d'audit avec le référentiel, le format et le rôle demandeur ; l'achèvement écrit une seconde entrée. Les générations échouées arrivent dans l'historique avec le message d'erreur.
* **Les fenêtres sont glissantes.** Les compteurs de preuves couvrent des fenêtres glissantes (90 jours ou 12 mois, selon le contrôle), pas des totaux historiques ; deux classeurs générés à quelques semaines d'écart diffèrent légitimement.
* **La rédaction ne peut pas être levée.** Le classeur ne contient jamais de données à caractère personnel ni de secrets ; si un auditeur a besoin des données par sujet derrière un agrégat, dirigez-le vers la surface sous-jacente ([DSAR](/compliance/dsar), [journal d'audit](/guides/audit-log)) plutôt que vers le classeur.

## Audit et contrôle d'accès

* La génération exige le rôle **propriétaire** ou **administrateur** de l'espace de travail ; les clés API suivent le même filtrage par rôle.
* Chaque génération écrit une entrée `compliance.binder_generated` dans votre journal d'audit avec le référentiel, le format et le rôle demandeur ; l'achèvement écrit une seconde entrée.
* Les générations échouées arrivent dans l'historique avec un message d'erreur au lieu de disparaître silencieusement.

## Références associées

* [DSAR](/compliance/dsar) — la file dont les lignes GDPR Art. 15 et Art. 17 se comptent
* [Registre de confidentialité (ROPA + DPIA)](/compliance/privacy-register) — source des catégories Art. 30 et de la posture Art. 35
* [Contrôles HIPAA](/compliance/hipaa) et [démarrage HIPAA](/guides/hipaa-onboarding) — la configuration que le dossier HIPAA relit
* [Marketplace des plugins de conformité](/compliance/plugin-marketplace) — parcourez les dossiers de preuves et les bundles d'activation en un seul endroit
* [Juridique](/legal/index)