Auftragsverarbeitungsvertrag

Stand: Oktober 2026, Version 1.0 [PRÜFEN: Datum und Version beim Veröffentlichen setzen]

zwischen dem Kunden von Plenva (Verantwortlicher, im Folgenden „Auftraggeber“)

und

Omar El Hussein, SolidCode – Softwareentwicklung und Beratung (Marke „Plenva“), Ruschkamp 34, 28259 Bremen (Auftragsverarbeiter, im Folgenden „Auftragnehmer“).

Dieser Vertrag wird mit der Registrierung bzw. Buchung von Plenva abgeschlossen und ist Bestandteil des Nutzungsvertrags (AGB). [PRÜFEN: Annahme (Zeitpunkt, Person, Version) in der App nachweisbar speichern. Optional zusätzlich eine unterschriebene PDF-Fassung zum Download anbieten.]

§ 1 Gegenstand und Dauer

1. Der Auftragnehmer verarbeitet personenbezogene Daten im Auftrag des Auftraggebers, um die Software Plenva als Online-Dienst bereitzustellen (Hosting, Speicherung, Verarbeitung, Versand, Support). Gegenstand, Art und Zweck der Verarbeitung, Art der Daten und Kategorien betroffener Personen beschreibt Anlage 1.
2. Der Vertrag gilt, solange der Auftragnehmer personenbezogene Daten für den Auftraggeber verarbeitet, einschließlich der Löschfrist nach § 10.

§ 2 Weisungen

1. Der Auftragnehmer verarbeitet die Daten nur auf dokumentierte Weisung des Auftraggebers, auch bei einer Übermittlung in ein Drittland, es sei denn, er ist durch Unionsrecht oder das Recht eines Mitgliedstaats dazu verpflichtet (Art. 28 Abs. 3 lit. a DSGVO). In diesem Fall teilt er dem Auftraggeber die rechtlichen Anforderungen vor der Verarbeitung mit, sofern das Recht dies nicht verbietet.
2. Weisungen sind der Nutzungsvertrag, dieser AVV und die Einstellungen und Handlungen, die der Auftraggeber und seine Nutzer in Plenva vornehmen, insbesondere Richtlinien des Workspace, Rollen und Rechte, Freigaben, Integrationen, API-Schlüssel, Exporte und Löschungen. Weitere Weisungen erteilt der Auftraggeber in Textform.
3. Hält der Auftragnehmer eine Weisung für rechtswidrig, informiert er den Auftraggeber unverzüglich und darf die Ausführung aussetzen, bis der Auftraggeber sie bestätigt oder ändert.

§ 3 Vertraulichkeit

Der Auftragnehmer setzt nur Personen ein, die zur Vertraulichkeit verpflichtet sind oder einer gesetzlichen Verschwiegenheitspflicht unterliegen (Art. 28 Abs. 3 lit. b DSGVO), und die mit den Datenschutzvorschriften vertraut gemacht wurden.

§ 4 Sicherheit der Verarbeitung

1. Der Auftragnehmer trifft die technischen und organisatorischen Maßnahmen nach Art. 32 DSGVO, die in Anlage 2 beschrieben sind.
2. Die Maßnahmen entsprechen dem Stand der Technik und werden weiterentwickelt. Der Auftragnehmer darf sie durch gleichwertige oder bessere Maßnahmen ersetzen. Das Schutzniveau darf dabei nicht unterschritten werden. Wesentliche Änderungen dokumentiert er.

§ 5 Unterauftragsverarbeiter

1. Der Auftraggeber genehmigt die in Anlage 3 genannten Unterauftragsverarbeiter (allgemeine schriftliche Genehmigung nach Art. 28 Abs. 2 DSGVO).
2. Der Auftragnehmer informiert den Auftraggeber mindestens vier Wochen vorher in Textform (E-Mail an die Administratoren und Hinweis in der App), wenn er einen Unterauftragsverarbeiter hinzuziehen oder ersetzen will. Der Auftraggeber kann innerhalb dieser Frist aus wichtigem datenschutzrechtlichem Grund widersprechen. Können sich die Parteien nicht einigen, kann der Auftraggeber den Nutzungsvertrag zum Zeitpunkt der Änderung kündigen.
3. Der Auftragnehmer verpflichtet jeden Unterauftragsverarbeiter vertraglich auf ein Schutzniveau, das diesem Vertrag entspricht (Art. 28 Abs. 4 DSGVO). Er haftet für dessen Verschulden wie für eigenes.
4. Keine Unterauftragsverarbeitung sind Dienste, die der Auftraggeber selbst verbindet oder deren Nutzung er selbst auslöst. Beispiele sind Kalender, Git-Dienste, Chat-Dienste, Import aus anderen Tools, Webhooks, API-Clients und KI-Assistenten über MCP. Die Daten werden dort auf Weisung des Auftraggebers an Empfänger übermittelt, die er selbst ausgewählt hat und verantwortet.
5. Ebenfalls keine Unterauftragsverarbeitung sind Nebenleistungen wie Telekommunikation oder Postdienste. Der Auftragnehmer trifft auch hierfür angemessene Vorkehrungen zum Schutz der Daten.

§ 6 Übermittlung in Drittländer

Eine Verarbeitung außerhalb der EU bzw. des EWR erfolgt nur, wenn die Voraussetzungen der Art. 44 ff. DSGVO erfüllt sind. Das kann ein Angemessenheitsbeschluss sein (z. B. das EU-U.S. Data Privacy Framework) oder Standardvertragsklauseln mit ergänzenden Maßnahmen. Anlage 3 nennt die betroffenen Unterauftragsverarbeiter.

§ 7 Unterstützung des Auftraggebers

1. Der Auftragnehmer unterstützt den Auftraggeber mit geeigneten Maßnahmen bei der Beantwortung von Anträgen betroffener Personen (Art. 12 bis 22 DSGVO). Plenva stellt dafür Funktionen bereit, darunter Export der Daten einer Person, Berichtigung, Löschung, Anonymisierung beim Ausscheiden („Vergessen“) und Export aller Daten des Workspace. Wendet sich eine betroffene Person direkt an den Auftragnehmer, leitet er die Anfrage unverzüglich an den Auftraggeber weiter.
2. Der Auftragnehmer unterstützt den Auftraggeber bei der Einhaltung der Pflichten aus Art. 32 bis 36 DSGVO, bei Datenschutz-Folgenabschätzungen und bei der Konsultation der Aufsichtsbehörde.
3. Aufwand, der über die in Plenva bereitgestellten Funktionen hinausgeht und nicht durch einen Verstoß des Auftragnehmers veranlasst ist, kann der Auftragnehmer angemessen vergüten lassen. [PRÜFEN: Stundensatz festlegen oder streichen.]

§ 8 Meldung von Verletzungen

Der Auftragnehmer meldet dem Auftraggeber eine Verletzung des Schutzes personenbezogener Daten unverzüglich, möglichst innerhalb von 24 Stunden, nachdem sie ihm bekannt geworden ist (Art. 33 Abs. 2 DSGVO). Die Meldung enthält, soweit bekannt:

• die Art der Verletzung;
• die Kategorien und die ungefähre Zahl der Betroffenen und Datensätze;
• die wahrscheinlichen Folgen;
• die ergriffenen und vorgeschlagenen Maßnahmen;
• eine Kontaktstelle.

Informationen, die noch nicht vorliegen, reicht er unverzüglich nach.

§ 9 Kontrollrechte

1. Der Auftragnehmer stellt dem Auftraggeber alle erforderlichen Informationen zum Nachweis der Pflichten aus Art. 28 DSGVO zur Verfügung und ermöglicht Überprüfungen einschließlich Inspektionen (Art. 28 Abs. 3 lit. h DSGVO).
2. Der Nachweis kann durch Selbstauskünfte, Dokumentation der Maßnahmen (Anlage 2), Testate oder Zertifikate der Unterauftragsverarbeiter (z. B. ISO 27001 des Rechenzentrums) erbracht werden. Vor-Ort-Prüfungen sind nach rechtzeitiger Anmeldung (mindestens 14 Tage) während der üblichen Geschäftszeiten möglich. Sie dürfen den Betrieb nicht unverhältnismäßig stören und die Vertraulichkeit der Daten anderer Kunden nicht gefährden. Prüfer, die nicht beim Auftraggeber beschäftigt sind, müssen zur Verschwiegenheit verpflichtet sein und dürfen nicht im Wettbewerb zum Auftragnehmer stehen.
3. Jede Partei trägt ihre Kosten einer Prüfung selbst. Mehr als eine Vor-Ort-Prüfung pro Jahr setzt einen konkreten Anlass voraus.

§ 10 Löschung und Rückgabe nach Ende des Auftrags

1. Während der Laufzeit kann der Auftraggeber seine Daten jederzeit selbst exportieren und löschen.
2. Nach Ende der Leistungen bzw. nach dem Löschantrag des Auftraggebers löscht der Auftragnehmer alle personenbezogenen Daten des Auftraggebers nach 30 Tagen vollständig aus dem laufenden System. Das gilt auch für das Archiv gestellter Rechnungen. In diesen 30 Tagen kann der Auftraggeber seine Daten exportieren (Rückgabe nach Art. 28 Abs. 3 lit. g DSGVO). Aus Datensicherungen werden die Daten mit deren turnusmäßigem Ablauf entfernt, spätestens nach [PRÜFEN: Frist der Backups, z. B. 30 Tagen].
3. Gesetzliche Aufbewahrungspflichten des Auftraggebers (z. B. § 147 AO) erfüllt der Auftraggeber selbst, indem er die Daten vor der Löschung exportiert.
4. Auf Verlangen bestätigt der Auftragnehmer die Löschung in Textform.

§ 11 Pflichten des Auftraggebers

1. Der Auftraggeber ist für die Rechtmäßigkeit der Verarbeitung verantwortlich. Dazu gehören insbesondere eine Rechtsgrundlage, die Information der betroffenen Personen und bei Beschäftigtendaten gegebenenfalls die Beteiligung des Betriebsrats.
2. Der Auftraggeber vergibt Rollen und Rechte in seinem Workspace angemessen. Das gilt besonders für das Recht „Abwesenheitsgründe sehen“, für Freigaben an Gäste und Externe, für öffentliche Links, für API-Schlüssel und für Integrationen.
3. Er informiert den Auftragnehmer unverzüglich, wenn er Fehler oder Unregelmäßigkeiten feststellt.

§ 12 Haftung, Vorrang, Schlussbestimmungen

1. Für die Haftung gilt Art. 82 DSGVO. Im Übrigen gelten die Haftungsregeln der AGB.
2. Bei Widersprüchen geht dieser AVV den AGB in Fragen des Datenschutzes vor.
3. Änderungen dieses AVV erfolgen nach dem Verfahren der AGB für Vertragsänderungen. Änderungen der Anlagen 2 und 3 richten sich nach § 4 Abs. 2 und § 5 Abs. 2.
4. Es gilt deutsches Recht. Gerichtsstand ist Bremen, soweit gesetzlich zulässig.

Anlage 1 – Gegenstand der Verarbeitung

Art und Zweck: Bereitstellung der SaaS-Plattform Plenva für Arbeit, Notizen und Besprechungen, Zeit und Arbeitszeit, Abwesenheiten, Kunden, Angebote und Rechnungen, Finanzen, Anfragen und Tickets sowie API. Die Verarbeitung umfasst das Erheben, Speichern, Ordnen, Anzeigen, Verknüpfen, Exportieren, Versenden (E-Mail, Webhooks, Chat) und Löschen.

Kategorien betroffener Personen:

• Nutzer des Auftraggebers: Inhaber, Beschäftigte, Freelancer, Mitglieder mit eingeschränktem Platz;
• Gäste und Externe, denen der Auftraggeber Zugang gibt;
• Kunden, Interessenten, Lieferanten und deren Ansprechpartner;
• Personen, die über Formulare, Widgets, E-Mail oder API Anfragen stellen;
• Empfänger geteilter Links, Rechnungen und Berichte;
• Zahlungspflichtige bzw. Zahler auf verbundenen Bankkonten;
• Autoren von Git-Ereignissen.

Kategorien personenbezogener Daten:

• Stamm- und Kontaktdaten: Name, E-Mail, Telefon, Anschrift, Firma, Rolle;
• Zugangs- und Sicherheitsdaten: Sitzungen, IP-Adresse, Browser, Sicherheitsprotokoll, MFA- und Passkey-Daten;
• Inhalte: Aufgaben, Kommentare, Notizen, Besprechungsprotokolle, Wiki, Dateien und Anhänge, Bildschirmfotos und Bildschirmaufnahmen aus Widgets;
• Zeit- und Arbeitszeitdaten: Stunden, Kommen, Pause und Gehen, Arbeitsort (Büro oder Homeoffice), Korrekturen, Gerätesignale (aktiv, inaktiv, gesperrt; nur mit Zustimmung);
• Abwesenheiten, Urlaubskonten und Krankmeldungen einschließlich Nachweisen. Das sind besondere Kategorien nach Art. 9 DSGVO (Gesundheitsdaten).
• Vertrags- und Abrechnungsdaten: Angebote, Rechnungen, Stundensätze, Ausgaben, Belege, USt-IdNr., Steuernummern;
• Bankdaten: IBAN, Name des Zahlers, Betrag, Verwendungszweck, Buchungsdatum;
• Kommunikationsdaten: E-Mails an die Anfragen-Adresse, Kalendertermine, Chat-Meldungen;
• Git-Metadaten: Commit- und Branch-Namen, Autorname und Autor-E-Mail, Titel von Pull/Merge Requests.

Ort der Verarbeitung: Deutschland (Rechenzentrum netcup, Nürnberg). Ausnahmen nennt Anlage 3.

Anlage 2 – Technische und organisatorische Maßnahmen (Art. 32 DSGVO)

Die Maßnahmen sind in der Software umgesetzt bzw. für den Betrieb festgelegt. Punkte mit [PRÜFEN] sind vor Abschluss des ersten AVV umzusetzen bzw. zu bestätigen.

1. Vertraulichkeit

Zutrittskontrolle (Rechenzentrum)

• Server im Rechenzentrum der netcup GmbH in Nürnberg mit Zutrittskontrolle, Videoüberwachung und Besucherregelung nach den Nachweisen des Anbieters [PRÜFEN: Zertifikat, z. B. ISO/IEC 27001, beim Anbieter abrufen und hier benennen].
• Der Auftragnehmer selbst hat keinen physischen Zugang zu den Servern.

Zugangskontrolle (Systeme)

• Administrativer Serverzugang nur über SSH mit Schlüsseln, kein Passwort-Login [PRÜFEN: bestätigen]. Datenbank nicht öffentlich erreichbar [PRÜFEN: bestätigen].
• Anmeldung an Plenva mit Passwort (gespeichert als bcrypt-Hash).
• Zwei-Faktor-Anmeldung per Authenticator-App (TOTP; jeder Code nur einmal gültig), per E-Mail-Code oder per Passkey (WebAuthn). Hinzu kommen einmalig nutzbare Backup-Codes, gespeichert als Hash.
• Workspace-Administratoren können die Zwei-Faktor-Anmeldung für alle Mitglieder verpflichtend machen und die Sitzungsdauer festlegen.
• Server-seitige Sitzungen: Jede Anfrage wird gegen eine aktive Sitzung geprüft. Sitzungen lassen sich einzeln oder alle beenden. Neue Geräte lösen eine Warn-E-Mail aus.
• Begrenzung von Anmeldeversuchen pro Konto und IP-Adresse.
• Erneute Bestätigung der Identität vor sicherheitskritischen Aktionen.
• Links zum Zurücksetzen des Passworts werden nur per E-Mail versendet, nie in einer Antwort der Schnittstelle zurückgegeben.
• Signierte Anmeldetokens (JWT) mit geheimem Schlüssel aus der Serverumgebung; die Anwendung startet ohne gesetzte Geheimnisse nicht.

Zugriffskontrolle (Berechtigungen)

• Mandantentrennung: Jeder Datensatz ist einem Workspace zugeordnet. Jeder Zugriff prüft die Zugehörigkeit zum Workspace, bevor irgendeine Rolle ausgewertet wird. Fremde Datensätze werden wie nicht vorhandene behandelt.
• Rollen im Workspace (z. B. Admin, Mitglied, Buchhaltung) und feingranulare Rechte. Private Notizen und private Boards sehen nur ihre Besitzer.
• Krankmeldungen und Abwesenheitsgründe (Art. 9 DSGVO) sehen nur die betroffene Person und Inhaber des Rechts „Abwesenheitsgründe sehen“. Für alle anderen erscheint nur „abwesend“, ohne einen Status, der auf Krankheit schließen lässt.
• Gäste und Externe haben nur Zugang zu ausdrücklich freigegebenen Inhalten, mit eigenen Sitzungen und E-Mail-Codes. Plätze und Kontingente werden auf dem Server durchgesetzt.
• Öffentliche Datei- und Freigabelinks sind mit HMAC signiert und laufen ab. Dateien werden mit nosniff ausgeliefert und nur sichere Typen inline angezeigt.
• API-Schlüssel werden nur als SHA-256-Hash gespeichert. Sie haben Berechtigungen (Scopes), laufen ab, lassen sich auf Server-Adressen begrenzen und widerrufen. Jeder API- und MCP-Aufruf wird protokolliert.
• Plattform-Team des Auftragnehmers mit getrennten Rollen (Inhaber, Support, Finanzen). Support sieht Teams und Nutzungszahlen, keine Inhalte der Workspaces. Es gibt keine Anmeldung als Nutzer eines Kunden.
• Ausgabe von Fehlern ohne Stacktraces oder interne Details.

Trennungskontrolle

• Logische Mandantentrennung in der Datenbank (siehe oben).
• Entwicklungs- und Testumgebungen laufen getrennt von der Produktion. Test-Sandboxes versenden weder E-Mails noch Webhooks [PRÜFEN: Nutzung von Kopien echter Daten in Sandboxes beenden oder anonymisieren].

Pseudonymisierung und Verschlüsselung

• Transportverschlüsselung: ausschließlich HTTPS/TLS für Website, App, API und Webhooks. E-Mail-Versand per SMTP mit TLS.
• Zugangsschlüssel Dritter, Webhook-Adressen und Geheimnisse der Authenticator-Apps werden mit AES-256-GCM verschlüsselt gespeichert. Der Schlüssel liegt in der Serverumgebung, nicht in der Datenbank.
• Missbrauchssignale bei der Registrierung speichern die IP-Adresse nur als Hash.
• Verschlüsselung der Datenträger bzw. der Datenbank im Ruhezustand: [PRÜFEN: derzeit nicht im Code nachweisbar; Festplattenverschlüsselung des Servers bzw. verschlüsselte Backups umsetzen und hier eintragen].

2. Integrität

Weitergabekontrolle

• Ausgehende Webhooks sind signiert. Eingehende Webhooks (Git, Stripe) werden über Signaturen geprüft (HMAC-SHA256 mit Zeitfenster).
• Kalenderadressen dürfen nur auf öffentliche https-Adressen zeigen; interne Netze sind gesperrt (Schutz vor SSRF).
• CORS-Freigabe nur für festgelegte Herkunftsadressen.
• Der Export aller Daten enthält nie Passwörter, Tokens, Hashes oder Geheimnisse.

Eingabekontrolle

• Sicherheitsprotokoll für Anmeldungen, Fehlversuche und Änderungen an Sicherheit und Richtlinien.
• Änderungsprotokoll für Arbeitszeiten (Korrekturen mit Person und Zeitpunkt), Aktivitätsverlauf an Aufgaben, Versionen von Notizen.
• Gestellte Rechnungen sind festgeschrieben. Das Archiv der versandten Rechnungsdokumente ist durch einen Datenbank-Trigger vor Änderung und Löschung geschützt; Korrekturen erfolgen nur per Storno (GoBD).
• Inhalte, die über API oder MCP angelegt werden, sind mit dem Namen der Verbindung gekennzeichnet. Über MCP können Rechnungen nur als Entwurf angelegt werden.

3. Verfügbarkeit und Belastbarkeit

• Regelmäßige Datensicherung der Datenbank einschließlich aller Dateien [PRÜFEN: Intervall (z. B. täglich), Aufbewahrung (z. B. 30 Tage), Speicherort (getrennter Standort bzw. Anbieter), Verschlüsselung und regelmäßiger Wiederherstellungstest – bisher nicht festgelegt].
• Rechenzentrum mit redundanter Strom- und Netzanbindung nach Angaben von netcup.
• Schutz vor Überlast: Begrenzung von Anfragen und Uploads (z. B. 26 MB pro Datei, Tageskontingent für Widget-Medien) sowie API-Kontingente.
• Datenbankmigrationen werden vor dem Einspielen auf einer Kopie getestet.
• Überwachung der Verfügbarkeit [PRÜFEN: Monitoring bzw. Statusseite einrichten].

4. Verfahren zur regelmäßigen Überprüfung

• Datenschutz durch Technik und datenschutzfreundliche Voreinstellungen, zum Beispiel:

  • private Notizen und Boards als Standard;
  • Kalender beim Verbinden im Modus „Privat“ oder „Geschäftlich“;
  • Widgets senden standardmäßig nur den Seitenpfad;
  • Gerätesignale nur mit Zustimmung.

• Automatische Löschfristen (nächtlicher Lauf), unter anderem:

  • Sitzungen nach 90 Tagen;
  • IP-Adresse und Browser im Sicherheitsprotokoll nach 365 Tagen;
  • IP-Adresse und Browser bei Aufrufen geteilter Links nach 90 Tagen;
  • Gast-Sitzungen nach 90 Tagen;
  • Systemmails nach 30 Tagen;
  • Webhook-Protokolle nach 30 Tagen;
  • Import-Rohdaten nach 30 Tagen;
  • Texte von Pull/Merge Requests nach 180 Tagen;
  • Chat-Texte nach 90 Tagen;
  • ignorierte Anfrage-Mails nach 30 Tagen;
  • Gerätesignale nach 2 Monaten;
  • Notizen im Papierkorb nach 30 Tagen;
  • gelöschte Workspaces nach 30 Tagen.

  Geschäftsdaten des Kunden werden durch diese Regeln nie gelöscht.

• Sicherheitsprüfungen des Codes (zuletzt September 2026) mit Behebung der Befunde. Automatisierte Tests bei jeder Änderung.

• Workspace-Richtlinien: Admins legen Regeln fest, unter anderem für Selbstlöschung, Einladungen, Gäste, Links, MFA, Sitzungsdauer, Export, Integrationen und API-Schlüssel. Die Regeln werden auf dem Server durchgesetzt.

• Verfahren für Datenschutzverletzungen und Betroffenenanfragen [PRÜFEN: kurz schriftlich dokumentieren].

Anlage 3 – Unterauftragsverarbeiter

Keine Unterauftragsverarbeiter im Sinne dieses Vertrags:

• Stripe Payments Europe, Ltd. Stripe verarbeitet nur Vertrags- und Zahlungsdaten des Auftraggebers selbst, für die der Auftragnehmer Verantwortlicher ist.
• Dienste, die der Auftraggeber selbst verbindet (§ 5 Abs. 4): Kalenderanbieter, GitHub/GitLab, Slack/Microsoft Teams/Discord/Google Chat, Jira/Asana/monday.com/ClickUp/Linear/YouTrack/sevDesk/Lexware (Import), eigene Webhook-Empfänger, API-Clients und KI-Assistenten über MCP.