Carte des contrôles · Règlement (UE) 2016/679

GDPR

Réserver un pilote d’audit Voir un exemple de rapport

3 contrôles GDPR sur 3 que le code peut prouver, avec v1.4.0, plus 2 en appui

Preuve issue du code pour les principes de traitement, la protection des données dès la conception et la sécurité du traitement.

Actif3
Prévu pour v1.4.00
En appui2
Prévu0
Votre organisation35

3 avec preuve issue du code aujourd’huiPreuve partielle, vérifiée à chaque pull request.
2 avec preuve d’appuiToevan enregistre des preuves connexes ; l’obligation reste organisationnelle.
35 restent à votre organisationListés en entier ci-dessous, pour que rien ne soit sous-entendu.

Une partie du GDPR vit dans le code : où circulent les données personnelles, comment elles sont délimitées et comment elles sont protégées.

Le blueprint GDPR apporte une preuve issue du code pour les Articles 5, 25 et 32 à chaque pull request, avec une preuve d’appui pour l’effacement et la notification des violations. La base juridique, le registre des traitements et les droits des personnes concernées restent à votre programme de protection des données.

Toevan apporte des preuves pour des contrôles ; il ne les certifie jamais et ne prétend pas qu’un référentiel est couvert. Que les preuves suffisent relève du jugement de votre auditeur.

Actif3

Preuve issue du code dès aujourd’hui, scellée à chaque pull request. Toujours partielle : le contrôle exige aussi des éléments hors du code. Preuve issue du code dès aujourd’hui : les règles du blueprint GDPR vérifient une partie de ce point à chaque pull request.

Art.5
Principes relatifs au traitement des données personnelles
Principes fondamentaux
Art.25
Protection des données dès la conception et par défaut
Exigences de conception
Art.32
Sécurité du traitement
Sécurité

En appui2

Toevan enregistre des preuves connexes, aujourd’hui ou dans v1.4.0, mais l’obligation relève de l’organisation : elle n’est donc jamais comptée comme couverte.

Art.17
Droit à l’effacement (« droit à l’oubli »)
Droits des personnes concernées
Preuve d’appui dès aujourd’hui : une règle enregistre des preuves liées à cette obligation. L’obligation elle-même relève d’un processus opérationnel.
Art.33
Notification d’une violation de données à l’autorité de contrôle
Réponse aux incidents
Preuve d’appui dès aujourd’hui : une règle enregistre des preuves liées à cette obligation. L’obligation elle-même relève d’une procédure réglementaire.

Votre organisation35

Politique, personnes, sécurité physique, contrats, procédure réglementaire, exploitation ou audit externe. Votre organisation en apporte la preuve.

Afficher les 35 contrôles

Principes fondamentaux

Art.6Licéité du traitementde la politique de l’organisation
Art.7Conditions applicables au consentementde la politique de l’organisation
Art.8Conditions applicables au consentement des enfants pour les services de la société de l’informationde la politique de l’organisation
Art.9Traitement de catégories particulières de données personnellesde la politique de l’organisation
Art.10Traitement des données relatives aux condamnations pénales et aux infractionsde la politique de l’organisation
Art.11Traitement ne nécessitant pas l’identificationde la politique de l’organisation

Droits des personnes concernées

Art.12Transparence des informations, de la communication et des modalités d’exercice des droits de la personne concernéed’un processus opérationnel
Art.13Informations à fournir lorsque les données sont collectées auprès de la personne concernéed’un processus opérationnel
Art.14Informations à fournir lorsque les données n’ont pas été collectées auprès de la personne concernéed’un processus opérationnel
Art.15Droit d’accès de la personne concernéed’un processus opérationnel
Art.16Droit de rectificationd’un processus opérationnel
Art.18Droit à la limitation du traitementd’un processus opérationnel
Art.19Obligation de notification en cas de rectification, d’effacement ou de limitation du traitementd’un processus opérationnel
Art.20Droit à la portabilité des donnéesd’un processus opérationnel
Art.21Droit d’oppositiond’un processus opérationnel
Art.22Décision individuelle automatisée, y compris le profilaged’un processus opérationnel

Responsable du traitement et sous-traitant

Art.24Responsabilité du responsable du traitementde la politique de l’organisation
Art.26Responsables conjoints du traitementde la politique de l’organisation
Art.27Représentants des responsables ou sous-traitants non établis dans l’Unionde la politique de l’organisation
Art.28Sous-traitantdes contrats et des fournisseurs
Art.29Traitement sous l’autorité du responsable ou du sous-traitantde la politique de l’organisation
Art.30Registre des activités de traitementde la politique de l’organisation
Art.31Coopération avec l’autorité de contrôlede la politique de l’organisation
Art.34Communication d’une violation de données à la personne concernéed’une procédure réglementaire
Art.36Consultation préalablede la politique de l’organisation
Art.37Désignation du délégué à la protection des donnéesde la politique de l’organisation
Art.38Fonction du délégué à la protection des donnéesde la politique de l’organisation
Art.39Missions du délégué à la protection des donnéesde la politique de l’organisation

Évaluation des risques

Art.35Analyse d’impact relative à la protection des donnéesde la politique de l’organisation

Transferts internationaux

Art.44Principe général applicable aux transfertsd’une procédure réglementaire
Art.45Transferts fondés sur une décision d’adéquationd’une procédure réglementaire
Art.46Transferts moyennant des garanties appropriéesd’une procédure réglementaire
Art.47Règles d’entreprise contraignantesd’une procédure réglementaire
Art.48Transferts ou divulgations non autorisés par le droit de l’Uniond’une procédure réglementaire
Art.49Dérogations pour des situations particulièresd’une procédure réglementaire

L’utiliser dans un audit

Lisez les preuves issues du code pour la période
Chaque pull request porte des résultats de code scellés par rapport aux règles du blueprint, rattachés au commit et à la version du jeu de règles en vigueur.
Testez un échantillon
Pour chaque enregistrement échantillonné, vérifiez ses résultats, puis sa signature et sa place dans la chaîne, hors ligne.
$ toevan audit verify --path evidence-clone --pub-key toevan.pub

Comment chaque fait a été obtenu

Chaque fait d’un enregistrement et d’un rapport porte l’une de six étiquettes, pour que votre auditeur sache dans quelle mesure s’y fier.

Recalculé: Toevan l’a calculé lui-même à partir du code ou de l’historique git.; Le refaire à partir des mêmes entrées et obtenir le même résultat.
Rapporté + scellé: GitHub l’a rapporté ; Toevan l’a capturé au moment de l’événement et signé.; S’y fier dans la mesure où vous vous fiez à GitHub. Toute modification ultérieure est détectable.
Déclaré + scellé: L’organisation l’a déclaré, par exemple un changement de ce qui est vérifié ; Toevan a signé la déclaration et son historique.; Voir qui a déclaré quoi, quand, et chaque modification ultérieure.
Enregistrement Toevan, non scellé: Conservé dans la base de données de Toevan mais non scellé dans le registre, comme une dérogation aujourd’hui. Aucune signature ne le protège.; Le considérer comme une déclaration de Toevan et demander à l’organisation l’approbation qui la fonde.
Consommé: Repris de l’enregistrement signé d’un autre système, comme une provenance de build, et relié par commit ou empreinte. Prévu.; Vérifier l’enregistrement d’origine de façon indépendante.
Non capturé: Aucune source fiable n’était disponible. Toevan ne le déduit pas.; L’obtenir auprès de l’organisation par d’autres moyens.

Le voir dans un rapport

L’exemple de rapport de preuves de changement montre les preuves telles que votre auditeur les reçoit, chaque fait étant étiqueté.

Ouvrir l’exemple de rapport

Testez la correspondance sur un vrai audit.

Apportez un dépôt et un audit à venir. Nous configurons le blueprint et guidons votre auditeur dans la vérification.