Ein mittelständisches Unternehmen beauftragt einen Softwaredienstleister mit der Entwicklung einer neuen ERP-Schnittstelle. Nach acht Monaten und erheblichen Vorauszahlungen ist das Projekt gescheitert: Die Software läuft nicht stabil, User Stories sind halbfertig, Meilensteine wurden nie vertraglich fixiert. Die Frage, die dem Geschäftsführer jetzt brennend auf den Nägeln brennt, lautet nicht: Was ist schiefgelaufen? Sondern: Welche Rechte habe ich überhaupt?
IT-Projektverträge unterliegen in Deutschland je nach Leistungsgegenstand dem Werkvertragsrecht, dem Dienstvertragsrecht oder einer Kombination aus beiden Regelungsbereichen des BGB. Bei agiler Softwareentwicklung entsteht eine strukturelle Spannung: Agile Methoden wie Scrum oder Kanban setzen auf iterative Anpassung und offene Anforderungen, während das klassische Werkvertragsrecht nach §§ 631 ff. BGB einen definierten Erfolg und eine abnahmefähige Leistung voraussetzt. Diese Spannung rechtlich zu beherrschen ist die zentrale Gestaltungsaufgabe für jedes Unternehmen, das Softwareprojekte vergibt.
Der folgende Beitrag analysiert die maßgeblichen Vertragstypen, die Abnahmeproblematik, typische Haftungsrisiken und die Gestaltungsmöglichkeiten, die dem Mittelstand zur Verfügung stehen – von der Projektstrukturierung bis zur Kündigung aus wichtigem Grund.
Werkvertrag oder Dienstvertrag: Welcher Vertragstyp gilt beim IT-Projekt?
Die Einordnung eines IT-Projektvertrags als Werkvertrag oder Dienstvertrag entscheidet über die gesamte Rechtslage: über Abnahme, Mängelhaftung, Vergütungsfälligkeit und Kündigungsrechte. Das BGB kennt keine eigenständige Kategorie für Softwareverträge, sodass die allgemeinen Vertragstypen heranzuziehen sind.
Schuldet der Auftragnehmer einen bestimmten Erfolg – eine funktionsfähige Software, eine definierte Schnittstelle, ein ablauffähiges System –, liegt ein Werkvertrag nach §§ 631 ff. BGB vor. Der Auftragnehmer trägt dann das Risiko des Gelingens. Vergütung wird erst mit Abnahme fällig (§ 641 BGB). Wird die geschuldete Leistung nicht oder nicht mangelfrei erbracht, stehen dem Auftraggeber Gewährleistungsrechte zu: Nacherfüllung, Selbstvornahme, Minderung, Rücktritt und Schadensersatz.
Schuldet der Auftragnehmer hingegen nur die Erbringung von Tätigkeiten – etwa agile Entwicklungskapazitäten nach Zeit und Aufwand –, liegt ein Dienstvertrag nach §§ 611 ff. BGB vor. Der entscheidende Unterschied: Keine Erfolgshaftung, keine Abnahmepflicht, Vergütung für geleistete Stunden unabhängig vom Projektergebnis. In der Praxis des Mittelstands ist diese Unterscheidung oft nicht klar verhandelt, was im Streitfall erhebliche Konsequenzen hat.
In der Mandatspraxis sehen wir regelmäßig Verträge, die äußerlich als „Werkvertrag" bezeichnet werden, aber inhaltlich eine Dienstleistungsstruktur aufweisen – mit Time-and-Material-Vergütung, offenen Leistungsbeschreibungen und fehlenden Abnahmekriterien. Gerichte ordnen nach dem wirtschaftlichen Kern ein, nicht nach der Vertragsbezeichnung.
Wie verhält sich agile Entwicklung zum klassischen Werkvertragsrecht?
Agile Softwareentwicklung nach Scrum, Kanban oder vergleichbaren Methoden ist strukturell auf kontinuierliche Anpassung ausgelegt: Anforderungen werden in Sprints iterativ konkretisiert, Ergebnisse regelmäßig überprüft und priorisiert. Das klassische Werkvertragsrecht setzt dagegen voraus, dass der geschuldete Erfolg bei Vertragsschluss hinreichend bestimmt oder zumindest bestimmbar ist.
Diese Spannung ist nicht unlösbar. Rechtlich tragfähig ist ein Modell, das beide Ebenen sauber trennt: ein Rahmenvertrag, der Governance, Vergütungsstruktur, Rechteübertragung und Beendigungsrechte regelt, und einzelne Sprintverträge oder Release-Bestellungen, die jeweils einen definierten Leistungsgegenstand mit abnahmefähigen Ergebniskriterien beschreiben. Jeder Sprint kann dann werkvertraglich strukturiert werden, sofern das Sprint-Ziel und die Akzeptanzkriterien (Definition of Done) schriftlich festgehalten sind.
Fehlt diese Struktur, entsteht ein Graubereich: Der Auftraggeber zahlt laufend Entwicklungskosten, hat aber keine durchsetzbaren Abnahmerechte und keine klaren Mängelpositionen. In einem aktuellen Mandat beriet die Kanzlei ein mittelständisches Handelsunternehmen, das im Rahmen eines agilen ERP-Projekts über zwölf Monate Entwicklungsleistungen nach Time-and-Material beauftragt hatte. Ausgangslage: Es existierte kein Rahmenvertrag, keine schriftliche Definition of Done, und Sprintergebnisse wurden per E-Mail „abgenickt". Vorgehen: Wir analysierten den E-Mail-Verkehr auf konkludente Abnahmeerklärungen, bewerteten den Vertragstyp nach wirtschaftlichem Gehalt und strukturierten die Mängelpositionen. Ergebnis: Auf Basis der Vertragsanalyse konnten konkrete Nacherfüllungsansprüche formuliert und ein außergerichtliches Einigungsverfahren eingeleitet werden – ohne belastbare Zahlen zur Schadenssumme zu nennen, da diese von der weiteren Entwicklung abhing.
Abnahme im IT-Projektvertrag: Warum sie oft misslingt
Die Abnahme ist im Werkvertragsrecht der entscheidende Moment: Sie begründet die Vergütungsfälligkeit (§ 641 BGB), startet die Verjährungsfrist für Mängelansprüche und bewirkt grundsätzlich den Übergang der Preisgefahr. Bei IT-Projekten scheitert sie häufig aus zwei Gründen – entweder fehlt ein vereinbartes Abnahmeverfahren, oder die Parteien sind sich uneinig, ob die Leistung überhaupt abnahmefähig ist.
Eine konkludente Abnahme kann eintreten, wenn der Auftraggeber die Software produktiv nutzt, ohne Mängel zu rügen. Die höchstrichterliche Rechtsprechung erkennt dies als Abnahmehandlung an. Das Risiko für den Auftraggeber: Er verliert die Möglichkeit, bekannte Mängel später als Abnahmehindernis geltend zu machen. Geschäftsführer, die ein nicht vollständig funktionierendes System „erst einmal produktiv nehmen", müssen sich bewusst sein, dass dieser Schritt vertragsrechtlich erhebliche Folgen haben kann.
Rechtlich empfehlenswert ist ein formales Abnahmeprotokoll mit vorab definierten Testfällen und einer klaren Regelung, welche Mängelkategorien die Abnahme verhindern (kritische Fehler/Blocker) und welche die Abnahme unter Vorbehalt erlauben. In der Praxis sehen wir solche Regelungen in Großprojekten der Automobilindustrie selbstverständlich, bei mittelständischen Projekten im fünf- bis sechsstelligen Eurobereich hingegen nahezu nie.
Wird keine Abnahme erklärt, bleibt die Vergütung – jedenfalls nach Werkvertragsrecht – im Streit. Die gegenteilige Position des Auftragnehmers, der auf Zahlung besteht, führt regelmäßig zur Klage, bei der dann Gutachter über den Projektstatus entscheiden. Das ist teuer, langwierig und für beide Seiten belastend.
Mängelansprüche und Haftung: Was gilt bei fehlerhafter Software?
Liegt ein Werkvertrag vor und wurde die Software abgenommen, beginnt die Verjährungsfrist für Mängelansprüche. Das BGB sieht für Werkleistungen eine regelmäßige Verjährung vor; für Bauwerke beträgt sie nach § 634a Abs. 1 Nr. 2 BGB fünf Jahre. Software gilt nicht als Bauwerk im Rechtssinne. Für sonstige Werkleistungen gilt die regelmäßige Verjährungsfrist von drei Jahren nach § 195 BGB, die mit dem Schluss des Jahres beginnt, in dem der Anspruch entstanden ist und der Gläubiger Kenntnis erlangt hat.
Macht der Auftraggeber Mängel geltend, hat er primär einen Anspruch auf Nacherfüllung (§ 635 BGB). Der Auftragnehmer kann wählen, ob er nachbessert oder neu herstellt. Schlägt die Nacherfüllung fehl, ist unverhältnismäßig oder wird verweigert, hat der Auftraggeber weitergehende Rechte: Er kann vom Vertrag zurücktreten, die Vergütung mindern oder Schadensersatz verlangen.
Was viele Geschäftsführer unterschätzen: Schadensersatz nach §§ 280, 281, 634 Nr. 4 BGB kann weit über den unmittelbaren Mangel hinausgehen. Betriebsausfälle, Folgeschäden durch fehlerhafte Datenverarbeitung, Kosten für externe Notlösungen – all das kann ersatzfähig sein, wenn die Pflichtverletzung nachgewiesen und ein konkreter Schaden bezifferbar ist. Nach unserer Erfahrung sind die Folgeschäden in IT-Projekten nicht selten erheblich größer als der Vertragswert selbst.
Bei Dienstverträgen gilt eine andere Logik: Da kein Erfolg geschuldet ist, gibt es keine Mängelhaftung im werkvertraglichen Sinne. Der Auftraggeber kann allenfalls Pflichtverletzung (§ 280 BGB) geltend machen, wenn der Auftragnehmer nachweisbar sorgfaltswidrig gehandelt hat. Diese Hürde ist erheblich höher.
Urheberrecht und Rechteübertragung: Wem gehört die Software?
Software ist urheberrechtlich geschützt, wenn sie das Ergebnis einer eigenen geistigen Schöpfung des Entwicklers ist (§ 2 Abs. 1 Nr. 1 UrhG, § 69a UrhG). Das ist bei individuell entwickelter Unternehmenssoftware regelmäßig der Fall. Die rechtliche Konsequenz ist für Auftraggeber bedeutsam: Allein durch Zahlung der Vergütung geht kein Urheberrecht über. Urheberrechte entstehen originär beim Schöpfer.
Auftraggeber erwerben daher nur die Nutzungsrechte, die ihnen vertraglich eingeräumt werden. Fehlt eine klare Rechteeinräumungsklausel, ist oft unklar, ob der Auftraggeber die Software überhaupt verändern, an Dritte weitergeben oder nach Vertragsende weiternutzen darf. In agilen Projekten, bei denen Code laufend in Sprints übergeben wird, sollte die Rechteübertragung sprintsynchron erfolgen – also mit jeder Abnahme eines Sprint-Ergebnisses.
Besondere Probleme entstehen, wenn Open-Source-Komponenten im Projektergebnis enthalten sind. Lizenzbedingungen wie die GPL können den Einsatz der Software erheblich einschränken oder sogar eine Offenlegung des Quellcodes erzwingen. Eine Open-Source-Klausel im Vertrag, die den Auftragnehmer zur Offenlegung aller verwendeten Open-Source-Bestandteile und ihrer Lizenzen verpflichtet, ist daher für Unternehmen, die auf proprietäre Software setzen, unverzichtbar.
Aus Sicht des Mittelstands empfehlen wir darüber hinaus, vertraglich sicherzustellen, dass Quellcode, Entwicklungsdokumentation und alle zur Weiterentwicklung erforderlichen Arbeitsergebnisse an den Auftraggeber herausgegeben werden. Ein Recht zur Weiterentwicklung ist wertlos, wenn der Auftragnehmer Quellcode und Dokumentation zurückbehält.
Haftungsbegrenzungen in IT-Verträgen: Was ist wirksam, was nicht?
Praktisch jeder IT-Projektvertrag enthält Haftungsbegrenzungsklauseln: Caps auf ein Mehrfaches der Jahresvergütung, Ausschluss mittelbarer Schäden und entgangenen Gewinns, Begrenzung auf den Versicherungswert. Diese Klauseln sind für Auftragnehmer wirtschaftlich nachvollziehbar, für Auftraggeber aber oft risikoreich – vor allem wenn Projektvolumen und Haftungscap stark auseinanderfallen.
Wirksam oder nicht – das hängt davon ab, ob die Klausel in Allgemeinen Geschäftsbedingungen (AGB) enthalten ist oder individuell ausgehandelt wurde. AGB-Klauseln unterliegen der Inhaltskontrolle nach §§ 305 ff. BGB, auch im unternehmerischen Verkehr. Klauseln, die die Haftung für grobe Fahrlässigkeit oder Vorsatz vollständig ausschließen, sind nach § 309 Nr. 7 BGB (analog § 307 BGB im B2B) in der Regel unwirksam.
Individuell ausgehandelte Klauseln genießen dagegen größeren Spielraum. Ein Haftungscap auf eine Jahresvergütung kann zwischen Unternehmen wirksam vereinbart werden, wenn er im Kontext der Gesamtrisikoverteilung ausgehandelt wurde. Entscheidend ist, ob eine „echte" Verhandlung stattgefunden hat oder ob der Cap einseitig vorgegeben wurde.
Für Geschäftsführer des Mittelstands empfehlen wir: Prüfen Sie Haftungsklauseln nicht isoliert, sondern im Zusammenhang mit der Versicherungssituation des Auftragnehmers. Eine Berufshaftpflicht des IT-Dienstleisters, die das tatsächliche Projektrisiko abdeckt, ist ein sinnvolles Korrektiv zu niedrigen Haftungscaps. Fordern Sie Nachweis und Deckungsumfang vor Vertragsschluss.
Kündigung und Projektabbruch: Welche Optionen hat der Auftraggeber?
IT-Projekte scheitern. Wenn das Vertrauen in den Auftragnehmer verloren ist, Meilensteine massiv überschritten werden oder das Projektergebnis nicht mehr erreichbar erscheint, stellt sich die Frage: Wie komme ich rechtlich sauber aus dem Vertrag heraus?
Das Werkvertragsrecht gibt dem Auftraggeber ein jederzeitiges Kündigungsrecht nach § 648 BGB. Der Auftragnehmer behält dann jedoch grundsätzlich den Vergütungsanspruch abzüglich ersparter Aufwendungen. Dieses Recht nützt also wenig, wenn der Auftraggeber erhebliche Vorauszahlungen geleistet hat und möglichst viel zurückerlangen möchte.
Vorzuziehen ist – soweit die Voraussetzungen vorliegen – die Kündigung aus wichtigem Grund nach § 648a BGB. Diese setzt voraus, dass dem Auftraggeber die weitere Vertragserfüllung nicht zumutbar ist, etwa weil der Auftragnehmer in Verzug ist, Nacherfüllung endgültig verweigert oder das Projekt erkennbar in eine für den Auftraggeber inakzeptable Richtung läuft. Der entscheidende Unterschied: Bei der Kündigung aus wichtigem Grund entfällt der Vergütungsanspruch des Auftragnehmers für noch nicht erbrachte Leistungen. Bereits geleistete Zahlungen für nicht abnahmefähige Leistungen können – je nach Konstellation – zurückgefordert werden.
Für Dienstverträge gilt § 626 BGB. Eine fristlose Kündigung aus wichtigem Grund ist zulässig, wenn die Fortsetzung des Dienstverhältnisses unter Berücksichtigung aller Umstände und unter Abwägung der Interessen beider Parteien nicht zumutbar ist. Zudem steht dem Auftraggeber eines Dienstvertrags nach § 627 BGB (soweit keine dauernde Dienstverschaffung im Sinne des Dienstvertragsrechts vorliegt) ein besonderes Kündigungsrecht zu, wenn es sich um Dienste handelt, die ein besonderes Vertrauen voraussetzen.
Praktisch bedeutsam ist: Wer kündigen will, sollte das nicht unvorbereitet tun. Projektdokumentation, E-Mail-Verkehr, Protokolle von Statusmeetings, Sprint-Reviews und Mängelrügen müssen vor der Kündigung gesichert und rechtlich ausgewertet werden. Wir beraten regelmäßig Unternehmen, die sich in dieser Situation befinden – die Qualität der verfügbaren Dokumentation entscheidet oft über die Durchsetzbarkeit von Rückforderungsansprüchen.
Vertragsgestaltung für agile IT-Projekte: Sieben zentrale Regelungspunkte
Ein rechtlich belastbarer Vertrag für agile Softwareentwicklung muss die strukturelle Offenheit agiler Methoden mit dem Bestimmtheitserfordernis des Werkvertragsrechts verbinden. Nach unserer Erfahrung aus der Beratungspraxis sind die folgenden Regelungspunkte am kritischsten:
- Vertragstyp und Leistungsstruktur: Rahmenvertrag mit werkvertraglich strukturierten Sprint-Einzelaufträgen; klare Entscheidung über Erfolgs- oder Tätigkeitsschuld je Leistungspaket.
- Definition of Done und Abnahmekriterien: Schriftlich fixierte Akzeptanzkriterien je Sprint; Regelung, welche Mängelklassen die Abnahme verhindern.
- Vergütungsstruktur: Festpreiskomponente für definierte Meilensteine, Time-and-Material-Rahmen für Änderungsanforderungen (Change Requests), klares Change-Request-Verfahren mit Schriftformerfordernis.
- Urheberrecht und Quellcode: Sprintsynchrone Rechteeinräumung; Herausgabepflicht für Quellcode und Dokumentation; Open-Source-Offenlegungspflicht.
- Haftung und Versicherung: Haftungscap im Verhältnis zum Projektrisiko, ausgeschlossene Klauseltypen nach AGB-Recht, Pflicht zum Nachweis einer angemessenen Berufshaftpflicht.
- Projektsteuerung und Eskalation: Vertraglich verankerte Steering-Committee-Struktur, Regelung für den Fall anhaltender Meinungsverschiedenheiten über Anforderungsänderungen.
- Kündigung und Transition: Klare Kündigungsrechte aus wichtigem Grund mit definierten Auslösern; Transition-Pflichten des Auftragnehmers (Wissenstransfer, Übergabedokumentation, Betrieb für Übergangszeit).
Welche dieser Punkte im Einzelfall verhandlungsfähig sind, hängt von der Marktposition des Auftraggebers, der Projektgröße und dem eingesetzten Dienstleister ab. Ein mittelständisches Unternehmen hat in der Regel mehr Verhandlungsspielraum als es annimmt – insbesondere dann, wenn es die vertragsrechtlichen Konsequenzen ungeregelter Punkte präzise benennen kann.
Datenschutz und IT-Sicherheit im IT-Projektvertrag
Jedes IT-Projekt, bei dem personenbezogene Daten verarbeitet werden, berührt den Anwendungsbereich der DSGVO. Wenn der Softwaredienstleister im Rahmen des Projekts Zugriff auf Produktiv- oder Testdaten mit personenbezogenem Inhalt erhält, muss ein Auftragsverarbeitungsvertrag nach Art. 28 DSGVO abgeschlossen werden – und zwar bevor der Zugriff erfolgt, nicht nachträglich.
Verstöße gegen die DSGVO können mit Bußgeldern von bis zu 20 Mio. € oder 4 % des weltweiten Jahresumsatzes geahndet werden (Art. 83 DSGVO). Das ist kein theoretisches Risiko: Aufsichtsbehörden haben in den letzten Jahren gezielt Fälle verfolgt, in denen IT-Projekte ohne ordnungsgemäße Auftragsverarbeitungsvereinbarung durchgeführt wurden.
Neben der Auftragsverarbeitung sind im Projektvertrag technische und organisatorische Maßnahmen (TOMs) des Auftragnehmers zu dokumentieren. Privacy by Design und Privacy by Default (Art. 25 DSGVO) verlangen, dass Datenschutzanforderungen bereits in der Systemarchitektur berücksichtigt werden – nicht erst am Ende des Projekts als Zusatz. Für den Auftraggeber bedeutet das: Datenschutzanforderungen müssen Teil des Anforderungsmanagements und damit Teil der vertraglich geschuldeten Leistung sein.
IT-Sicherheitsanforderungen – insbesondere nach dem aktuell geltenden KRITIS-Regelwerk und dem IT-Sicherheitsgesetz – sind branchenabhängig. Für Unternehmen in regulierten Bereichen (Energie, Finanzen, Gesundheit, Kritische Infrastruktur) gilt ein verschärfter Pflichtenkatalog. Der Projektvertrag sollte die Einhaltung der relevanten Sicherheitsstandards (etwa ISO 27001 oder BSI IT-Grundschutz) als Vertragspflicht des Auftragnehmers verankern.
Streitbeilegung und Gerichtsstandort: Was vereinbaren?
IT-Streitigkeiten sind technisch komplex und sachverhaltsintensiv. Ordentliche Gerichte greifen in aller Regel auf Sachverständigengutachten zurück, was das Verfahren erheblich verlängert und verteuert. Für größere Projekte kann eine Schiedsklausel mit einem auf IT-Recht spezialisierten Schiedsgericht eine sinnvolle Alternative sein – die DIS (Deutsche Institution für Schiedsgerichtsbarkeit) bietet entsprechende Verfahrensordnungen.
Praktisch wichtiger als die Streitbeilegungsklausel ist jedoch oft eine vorgelagerte Eskalationsregelung: Werkzeuge wie Mediation, technische Expertenentscheidung oder Dispute Boards können Konflikte lösen, bevor sie in ein langwieriges Verfahren münden. Das setzt voraus, dass die Vertragsparteien solche Mechanismen bereits bei Vertragsschluss vereinbaren – im laufenden Streit ist die Bereitschaft zur einvernehmlichen Lösung erfahrungsgemäß begrenzt.
Gerichtszuständigkeit und anwendbares Recht sind bei internationalen Projekten gesondert zu prüfen. Bei Verträgen mit ausländischen IT-Dienstleistern – häufig in Osteuropa oder Indien ansässig – gelten nicht automatisch deutsches Recht und deutsche Gerichte. Eine ausdrückliche Rechtswahlklausel zugunsten deutschen Rechts und ein Gerichtsstandort in Deutschland (München oder Berlin) sind Standard-Vereinbarungen, die in keinem grenzüberschreitenden Projektvertrag fehlen sollten.
Die vorstehende Darstellung betrifft die typischen Konstellationen des deutschen IT-Projektvertragsrechts. Ihr konkretes Projekt erfordert die Prüfung der Vertragsunterlagen, der Projektkommunikation und der einschlägigen Rechtsprechung im Detail. Für eine erste Durchsicht Ihrer Unterlagen erreichen Sie uns unter info@brandtfalk.com.
Verwandte Leistungen
Häufige Fragen zum IT-Projektvertrag und agiler Softwareentwicklung
Was ist der Unterschied zwischen Werkvertrag und Dienstvertrag bei einem IT-Projekt?
Bei einem Werkvertrag nach §§ 631 ff. BGB schuldet der Auftragnehmer einen definierten Erfolg – etwa eine funktionsfähige Software. Vergütung wird erst mit Abnahme fällig, und es bestehen Mängelansprüche. Bei einem Dienstvertrag nach §§ 611 ff. BGB schuldet der Auftragnehmer nur die Erbringung von Tätigkeiten, nicht das Ergebnis. Vergütung ist unabhängig vom Projekterfolg fällig; eine Mängelhaftung im werkvertraglichen Sinne entfällt. Die Einordnung hängt nicht von der Vertragsbezeichnung ab, sondern vom wirtschaftlichen Gehalt der vereinbarten Leistung.
Wie lässt sich agile Softwareentwicklung werkvertraglich gestalten?
Agile Methoden und Werkvertragsrecht lassen sich durch eine zweistufige Struktur verbinden: Ein Rahmenvertrag regelt Governance, Vergütung und Rechteübertragung; einzelne Sprints oder Releases werden als werkvertraglich strukturierte Einzelaufträge mit schriftlich fixierten Akzeptanzkriterien (Definition of Done) ausgestaltet. Auf diese Weise ist jeder Sprint abnahmefähig, und Mängelrechte entstehen auf klar definierter Grundlage.
Was passiert, wenn keine formale Abnahme vereinbart wurde?
Fehlt ein formales Abnahmeverfahren, kann eine konkludente Abnahme eintreten – etwa durch produktive Nutzung der Software ohne Mängelrüge. Das hat erhebliche Konsequenzen: Die Verjährungsfrist für Mängelansprüche beginnt, und bekannte Mängel können nicht mehr als Abnahmehindernis geltend gemacht werden. Unternehmen sollten daher auch bei informellen Projektstrukturen darauf achten, Mängel schriftlich und vor Produktivnahme zu rügen.
Wem gehört die im Projekt entwickelte Software?
Das Urheberrecht entsteht originär beim Entwickler. Allein durch Zahlung der Vergütung gehen keine Rechte auf den Auftraggeber über. Nutzungsrechte müssen vertraglich ausdrücklich eingeräumt werden. Für agile Projekte empfiehlt sich eine sprintsynchrone Rechteübertragung, ergänzt um Herausgabepflichten für Quellcode, Entwicklungsdokumentation und Arbeitsergebnisse sowie eine Offenlegungspflicht für enthaltene Open-Source-Komponenten.
Unter welchen Voraussetzungen kann ich ein IT-Projekt aus wichtigem Grund kündigen?
Die Kündigung aus wichtigem Grund nach § 648a BGB (Werkvertrag) setzt voraus, dass dem Auftraggeber die weitere Vertragserfüllung unzumutbar ist – etwa wegen nachhaltigem Verzug, Verweigerung der Nacherfüllung oder erkennbarem Projektversagen. Bei wirksamer Kündigung aus wichtigem Grund entfällt der Vergütungsanspruch des Auftragnehmers für nicht erbrachte Leistungen. Eine sorgfältige Dokumentation vor der Kündigung ist entscheidend für die Durchsetzbarkeit von Rückforderungsansprüchen.
Welche Datenschutzpflichten gelten bei IT-Projekten mit Personendaten?
Erhält der Dienstleister im Rahmen des Projekts Zugriff auf personenbezogene Daten, ist vor dem Zugriff ein Auftragsverarbeitungsvertrag nach Art. 28 DSGVO abzuschließen. Zudem müssen technische und organisatorische Maßnahmen dokumentiert werden; Privacy by Design und Privacy by Default (Art. 25 DSGVO) verlangen die frühzeitige Integration von Datenschutzanforderungen in die Systemarchitektur. Verstöße können mit Bußgeldern von bis zu 20 Mio. € oder 4 % des weltweiten Jahresumsatzes geahndet werden.
Die vorstehende Darstellung betrifft die Regelfälle des IT-Projektvertragsrechts. Ihr konkreter Sachverhalt erfordert die Prüfung Ihrer Vertragsunterlagen, der Projektkommunikation und der im Einzelfall einschlägigen Rechtsprechung. Für eine erste Durchsicht Ihrer Unterlagen erreichen Sie uns unter info@brandtfalk.com.
Dieser Beitrag dient ausschließlich der allgemeinen Information und stellt keine Rechtsberatung im Einzelfall dar. Er ersetzt nicht die anwaltliche Prüfung Ihres konkreten Sachverhalts. Für eine auf Ihre Situation zugeschnittene Beratung wenden Sie sich an info@brandtfalk.com.
Dieser Beitrag ist eine allgemeine Information und stellt keine Rechtsberatung dar. Für eine Prüfung Ihres Falls kontaktieren Sie info@brandtfalk.com.