Asset-Inventar für DSGVO Artikel 32 — Nachweis in Jira

DSGVO Art. 32 verlangt, die Geräte zu sichern, die personenbezogene Daten verarbeiten. So führt und belegt ihr euer Asset-Inventar direkt in Jira.

Die DSGVO verlangt in Artikel 32 — „Sicherheit der Verarbeitung", personenbezogene Daten mit geeigneten technischen Maßnahmen zu schützen. Was man nicht sieht, kann man nicht schützen: Wenn ein Laptop oder Server personenbezogene Daten verarbeitet, müsst ihr wissen, dass er existiert, wo er steht und dass ihn jemand überprüft hat. Genau das ist ein Asset-Inventar — und für Teams auf Atlassian gehört es nach Jira, nicht in eine Tabelle.

Diese Anleitung zeigt, wie das Asset-Inventar auf Artikel 32 einzahlt, welche Nachweise ein Datenschutz-Auditor tatsächlich sehen will und wie ihr sie direkt in Jira Service Management Assets erzeugt.

HINWEIS: Das Asset-Inventar ist eine Sicherheitsmaßnahme, die Artikel 32 unterstützt. Kein Tool „macht euch DSGVO-konform" — Compliance ist ein Programm. Dieser Artikel zeigt, wie ihr einen Baustein davon sauber umsetzt.

Wie das Asset-Inventar auf Artikel 32 einzahlt

Artikel 32 fordert nicht wörtlich „führt ein Asset-Inventar", verlangt aber ein dem Risiko angemessenes Schutzniveau — einschließlich der Fähigkeit, Vertraulichkeit und Integrität der Verarbeitungssysteme dauerhaft sicherzustellen. In der Praxis lesen Datenschutzbeauftragte und Auditoren das so:

  • Verarbeitende Assets kennen — welche Geräte und Systeme personenbezogene Daten anfassen.
  • Sie kontrollieren — zugewiesene Eigentümer, bekannte Standorte, verifizierter Zustand.
  • Es belegen können — Aufzeichnungen, die zeigen, dass das Inventar real ist und gepflegt wird, keine Einmal-Liste.

Das ist dieselbe Maßnahme, die ISO 27001 · A.5.9 formalisiert (Inventar der Informationen und zugehörigen Werte) — weshalb ein Inventar nach ISO-Muster zugleich als Nachweis für DSGVO Art. 32 taugt.

Was Auditoren sehen wollen

Berührt ein Datenschutz-Audit die Asset-Sicherheit, sind die Fragen immer dieselben:

  • Gibt es ein aktuelles Inventar der Assets, die personenbezogene Daten verarbeiten?
  • Hat jedes Asset einen Eigentümer?
  • Könnt ihr zeigen, dass das Inventar regelmäßig verifiziert wird — mit Datum und Person?
  • Könnt ihr die Aufzeichnung für die Audit-Akte exportieren?

An den letzten beiden scheitert eine statische Tabelle: Sie kann nicht belegen, wer was wann geprüft hat. (SOC-2-Prüfer bohren an genau dieser Lücke noch härter — siehe was SOC 2 verlangt.)

Die Nachweise in Jira erzeugen

Lebt eure CMDB bereits in Jira Service Management Assets, existiert das Inventar — was meist fehlt, ist der Verifizierungsnachweis. Scannix ergänzt genau diese Schicht:

  • Audit-Scope auf die Assets legen, die personenbezogene Daten verarbeiten — per Schema, Objekttyp oder Assets Query Language.
  • Physisch verifizieren durch Scannen von QR-Codes und Barcodes mit einer kostenlosen iPhone-App (offline-fähig, mit Doppelscan-Schutz).
  • Zeitstempel pro Person — jede Verifizierung ist zugeordnet und datiert.
  • CSV-Export zum direkten Anhängen an die Art.-32-Nachweisakte.

Scannix-Audit-Report in Jira mit gescannten und fehlenden Assets samt Zeitstempeln pro Person

Verifizierte Assets mit Prüfer und Zeitstempel, exportbereit

Da Scannix auf Atlassian Forge läuft, bleiben eure Asset-Daten in eurer Atlassian-Site — relevant, weil Artikel 32 auch danach fragt, wo Verarbeitungsdaten liegen.

Die komplette Schritt-für-Schritt-Einrichtung eines Audits zeigt der Leitfaden zu physischen Asset-Audits in Jira.

Wiederholbar machen

Artikel 32 erwartet fortlaufende Sicherheit, keinen Schnappschuss. Mit Jira Automation plant ihr die Asset-Verifizierung in festem Rhythmus (z. B. quartalsweise) — das Inventar bleibt aktuell, und jeder Zyklus hinterlässt seinen eigenen zeitgestempelten Nachweis. Genau das „über die Zeit gepflegt"-Signal, nach dem Auditoren suchen.

FAQ

Verlangt die DSGVO wirklich ein Asset-Inventar?

Nicht mit diesen Worten. Artikel 32 verlangt dem Risiko angemessene Sicherheitsmaßnahmen — und die Assets zu kennen und zu kontrollieren, die personenbezogene Daten verarbeiten, ist ein Standardweg dorthin. Die Maßnahme deckt sich direkt mit ISO 27001 · A.5.9.

Welche Nachweise sollte ich aufbewahren?

Ein aktuelles Inventar mit Eigentümern, dazu Aufzeichnungen, wer welches Asset wann verifiziert hat, und eine exportierbare Kopie für die Audit-Akte. Die zeitgestempelten, personenbezogen zugeordneten Einträge sind genau der Teil, den eine Tabelle nicht liefern kann.

Wo liegen meine Asset-Daten bei Scannix?

In eurer eigenen Atlassian-Site. Scannix läuft auf Atlassian Forge; Asset- und Audit-Daten bleiben in Atlassian und werden in keine externe Datenbank kopiert.

Kann Scannix die Verifizierung automatisch nach Zeitplan ausführen?

Ja. Jira Automation kann Audits in beliebigem Rhythmus anlegen, starten und schließen — das Inventar bleibt aktuell, und jeder Zyklus erzeugt seinen eigenen zeitgestempelten Nachweis.

Wie dokumentiere ich die Asset-Verifizierung für ein Datenschutz-Audit?

Scoped ein Audit auf die Assets, die personenbezogene Daten verarbeiten, verifiziert sie per Scan und exportiert den Nachweis — pro Asset, pro Person, mit Zeitstempel — als CSV für die Audit-Akte.

Wie oft müssen Assets nach Artikel 32 verifiziert werden?

Die DSGVO nennt kein festes Intervall — der Rhythmus muss dem Risiko angemessen sein. Quartalsweise oder halbjährliche Verifizierung ist gängige Praxis; entscheidend ist, einen Rhythmus zu definieren und dessen Einhaltung zeigen zu können — genau das dokumentieren geplante Audits automatisch.

Macht eure Jira-CMDB zum Art.-32-Nachweis

Schluss mit der separaten Tabelle, die ihr im Audit nicht verteidigen könnt. Verifiziert die Assets, die personenbezogene Daten verarbeiten, dort, wo sie ohnehin leben — in Jira — und exportiert den zeitgestempelten, personenbezogen zugeordneten Nachweis, nach dem Auditoren fragen.

👉 So erzeugt Scannix Asset-Audit-Nachweise