Control-Map · Verordnung (EU) 2016/679

GDPR

Audit-Pilot buchen Beispielbericht ansehen

3 von 3 Controls für GDPR, die Code belegen kann, mit v1.4.0, plus 2 unterstützend

Code-Nachweis für die Verarbeitungsgrundsätze, Datenschutz durch Technikgestaltung und Sicherheit der Verarbeitung.

Live3
Kommt in v1.4.00
Unterstützend2
Geplant0
Ihre Organisation35

3 mit Code-Nachweis heuteTeilnachweis, bei jedem Pull Request geprüft.
2 mit unterstützendem NachweisToevan erfasst verwandte Nachweise; die Pflicht bleibt organisatorisch.
35 bleiben bei Ihrer OrganisationUnten vollständig aufgelistet, damit nichts angedeutet wird.

Ein Teil der GDPR liegt im Code: wohin personenbezogene Daten fließen, wie sie abgegrenzt und wie sie geschützt sind.

Der GDPR-Blueprint liefert bei jedem Pull Request Code-Nachweise für die Artikel 5, 25 und 32, mit unterstützenden Nachweisen für Löschung und Meldung von Datenpannen. Rechtsgrundlage, Verzeichnis von Verarbeitungstätigkeiten und Betroffenenrechte bleiben bei Ihrem Datenschutzprogramm.

Toevan liefert Nachweise für Controls; es zertifiziert sie nie und behauptet nie, ein Framework sei abgedeckt. Ob die Nachweise genügen, beurteilt Ihr Auditor.

Live3

Code-Nachweis heute, bei jedem Pull Request versiegelt. Immer nur teilweise: Das Control verlangt auch Dinge außerhalb des Codes. Code-Nachweis heute: Regeln im Blueprint GDPR prüfen einen Teil davon bei jedem Pull Request.

Art.5
Grundsätze für die Verarbeitung personenbezogener Daten
Grundprinzipien
Art.25
Datenschutz durch Technikgestaltung und Voreinstellungen
Designanforderungen
Art.32
Sicherheit der Verarbeitung
Sicherheit

Unterstützend2

Toevan erfasst verwandte Nachweise, heute oder in v1.4.0, doch die Pflicht liegt bei der Organisation und gilt deshalb nie als abgedeckt.

Art.17
Recht auf Löschung („Recht auf Vergessenwerden“)
Betroffenenrechte
Unterstützender Nachweis heute: Eine Regel erfasst Nachweise zu dieser Pflicht. Die Pflicht selbst betrifft einen betrieblichen Prozess.
Art.33
Meldung von Datenpannen an die Aufsichtsbehörde
Incident Response
Unterstützender Nachweis heute: Eine Regel erfasst Nachweise zu dieser Pflicht. Die Pflicht selbst betrifft ein regulatorisches Verfahren.

Ihre Organisation35

Richtlinien, Personal, physische Sicherheit, Verträge, regulatorische Verfahren, Betrieb oder externe Prüfung. Diese belegt Ihre Organisation.

Alle 35 Controls anzeigen

Grundprinzipien

Art.6Rechtmäßigkeit der Verarbeitungdie Richtlinien der Organisation
Art.7Bedingungen für die Einwilligungdie Richtlinien der Organisation
Art.8Bedingungen für die Einwilligung eines Kindes in Bezug auf Dienste der Informationsgesellschaftdie Richtlinien der Organisation
Art.9Verarbeitung besonderer Kategorien personenbezogener Datendie Richtlinien der Organisation
Art.10Verarbeitung von Daten über strafrechtliche Verurteilungen und Straftatendie Richtlinien der Organisation
Art.11Verarbeitung, für die keine Identifizierung erforderlich istdie Richtlinien der Organisation

Betroffenenrechte

Art.12Transparente Information, Kommunikation und Modalitäten für die Ausübung der Betroffenenrechteeinen betrieblichen Prozess
Art.13Informationspflicht bei Erhebung von Daten bei der betroffenen Personeinen betrieblichen Prozess
Art.14Informationspflicht, wenn die Daten nicht bei der betroffenen Person erhoben wurdeneinen betrieblichen Prozess
Art.15Auskunftsrecht der betroffenen Personeinen betrieblichen Prozess
Art.16Recht auf Berichtigungeinen betrieblichen Prozess
Art.18Recht auf Einschränkung der Verarbeitungeinen betrieblichen Prozess
Art.19Mitteilungspflicht bei Berichtigung, Löschung oder Einschränkung der Verarbeitungeinen betrieblichen Prozess
Art.20Recht auf Datenübertragbarkeiteinen betrieblichen Prozess
Art.21Widerspruchsrechteinen betrieblichen Prozess
Art.22Automatisierte Entscheidungen im Einzelfall einschließlich Profilingeinen betrieblichen Prozess

Verantwortlicher und Auftragsverarbeiter

Art.24Verantwortung des Verantwortlichendie Richtlinien der Organisation
Art.26Gemeinsam Verantwortlichedie Richtlinien der Organisation
Art.27Vertreter von nicht in der Union niedergelassenen Verantwortlichen oder Auftragsverarbeiterndie Richtlinien der Organisation
Art.28AuftragsverarbeiterVerträge und Lieferanten
Art.29Verarbeitung unter der Aufsicht des Verantwortlichen oder des Auftragsverarbeitersdie Richtlinien der Organisation
Art.30Verzeichnis von Verarbeitungstätigkeitendie Richtlinien der Organisation
Art.31Zusammenarbeit mit der Aufsichtsbehördedie Richtlinien der Organisation
Art.34Benachrichtigung der betroffenen Person bei Datenpannenein regulatorisches Verfahren
Art.36Vorherige Konsultationdie Richtlinien der Organisation
Art.37Benennung eines Datenschutzbeauftragtendie Richtlinien der Organisation
Art.38Stellung des Datenschutzbeauftragtendie Richtlinien der Organisation
Art.39Aufgaben des Datenschutzbeauftragtendie Richtlinien der Organisation

Risikobewertung

Art.35Datenschutz-Folgenabschätzungdie Richtlinien der Organisation

Internationale Übermittlungen

Art.44Allgemeine Grundsätze der Datenübermittlungein regulatorisches Verfahren
Art.45Übermittlung auf Grundlage eines Angemessenheitsbeschlussesein regulatorisches Verfahren
Art.46Übermittlung vorbehaltlich geeigneter Garantienein regulatorisches Verfahren
Art.47Verbindliche interne Datenschutzvorschriftenein regulatorisches Verfahren
Art.48Nach Unionsrecht nicht zulässige Übermittlung oder Offenlegungein regulatorisches Verfahren
Art.49Ausnahmen für bestimmte Fälleein regulatorisches Verfahren

Im Audit nutzen

Code-Nachweise des Zeitraums lesen
Jeder Pull Request trägt versiegelte Code-Ergebnisse zu den Regeln des Blueprints, festgemacht am Commit und an der geltenden Regelsatz-Version.
Stichprobe testen
Prüfen Sie für jeden gezogenen Eintrag das Ergebnis, dann Signatur und Platz in der Kette offline.
$ toevan audit verify --path evidence-clone --pub-key toevan.pub

Wie jeder Fakt erhoben wurde

Jeder Fakt in einem Eintrag und einem Bericht trägt eines von sechs Labels, damit Ihr Auditor weiß, wie weit er sich darauf stützen kann.

Neu berechnet: Toevan hat es selbst aus Code oder Git-Historie berechnet.; Mit denselben Eingaben nachvollziehen und dasselbe Ergebnis erhalten.
Gemeldet + versiegelt: GitHub hat es gemeldet; Toevan hat es beim Ereignis erfasst und signiert.; Verlassen Sie sich darauf, soweit Sie GitHub vertrauen. Jede spätere Änderung ist erkennbar.
Erklärt + versiegelt: Die Organisation hat es erklärt, etwa eine Änderung dessen, was geprüft wird; Toevan hat die Erklärung und ihre Historie signiert.; Sehen Sie, wer was wann erklärt hat, und jede spätere Änderung.
Toevan-Eintrag, nicht versiegelt: In der Datenbank von Toevan gespeichert, aber nicht im Ledger versiegelt, etwa eine Ausnahmegenehmigung heute. Keine Signatur schützt ihn.; Behandeln Sie ihn als Aussage von Toevan und fragen Sie die Organisation nach der Freigabe dahinter.
Übernommen: Aus dem signierten Eintrag eines anderen Systems übernommen, etwa einer Build-Provenienz, und per Commit oder Digest verknüpft. Geplant.; Den Originaleintrag unabhängig prüfen.
Nicht erfasst: Es gab keine verlässliche Quelle. Toevan schließt nichts daraus.; Auf anderem Weg bei der Organisation einholen.

Im Bericht ansehen

Der Beispielbericht zeigt den Nachweis so, wie Ihr Auditor ihn erhält, jeder Fakt mit Label.

Beispielbericht öffnen

Testen Sie die Zuordnung an einem echten Audit.

Bringen Sie ein Repository und ein anstehendes Audit mit. Wir richten den Blueprint ein und führen Ihren Auditor durch die Prüfung.