Ein mittelständisches Unternehmen beauftragt einen Softwaredienstleister mit der Entwicklung einer neuen Branchenplattform. Nach zwölf Monaten, mehreren Sprint-Zyklen und erheblichem Budget-Einsatz steht die Frage im Raum: Ist das Ergebnis abnahmefähig – und wer trägt das Risiko, wenn der Scope sich während der Entwicklung verändert hat? Diese Konstellation beschäftigt Geschäftsführer im deutschen Mittelstand mit wachsender Regelmäßigkeit.
Der IT-Projektvertrag unterliegt im deutschen Recht grundsätzlich dem Werkvertragsrecht des BGB, soweit ein funktionsfähiges Gesamtergebnis geschuldet ist. Agile Entwicklungsmethoden wie Scrum oder Kanban verändern diese rechtliche Ausgangslage nicht automatisch – sie schaffen jedoch erheblichen Gestaltungsbedarf, weil Leistungsumfang, Abnahme und Vergütung flexibel definiert werden müssen. Ohne vertragliche Klarheit drohen Mängelansprüche, Zahlungsverweigerung und Haftungsrisiken für die Geschäftsführung.
Dieser Beitrag analysiert die rechtliche Einordnung agiler IT-Projektverträge, zeigt die typischen Konfliktfelder auf und gibt Geschäftsführern im Mittelstand eine strukturierte Orientierung für Vertragsgestaltung und Streitvermeidung.
Werkvertrag, Dienstvertrag oder Mischform – wie ordnet das BGB IT-Projekte ein?
Die Vertragstypen-Frage ist die Weichenstellung für alle nachfolgenden Rechte und Pflichten. Das BGB kennt keinen eigenen IT-Vertragstyp; maßgeblich ist, was die Parteien inhaltlich vereinbaren.
Schuldet der Auftragnehmer ein konkretes, abnahmefähiges Werk – etwa eine lauffähige Softwareanwendung mit definierten Funktionalitäten –, ist Werkvertragsrecht (§§ 631 ff. BGB) anwendbar. Der Auftragnehmer trägt dann das Herstellungsrisiko: Er muss das versprochene Ergebnis liefern, unabhängig vom Aufwand. Scheitert er, hat der Auftraggeber Anspruch auf Nacherfüllung, Minderung oder Rücktritt – und unter Umständen auf Schadensersatz. Die Abnahme (§ 640 BGB) ist dabei der entscheidende Moment: Sie begründet die Vergütungspflicht und den Übergang der Mängelgefahr.
Schuldet der Auftragnehmer hingegen nur die sorgfältige Erbringung einer Tätigkeit – etwa fortlaufende Beratung, Konzeption oder Softwarepflege –, liegt ein Dienstvertrag (§§ 611 ff. BGB) vor. Der Aufwand ist vergütungspflichtig, unabhängig davon, ob ein bestimmtes Ergebnis erreicht wird. In der Mandatspraxis sehen wir häufig, dass Auftraggeber einen Werkvertrag erwarten, während der Auftragnehmer intern von einem Dienstvertrag ausgeht – ein klassischer Konflikt, der oft erst in der Krise sichtbar wird.
Gerade bei agilen IT-Projekten entstehen regelmäßig Mischformen: Einzelne Sprints werden nach Aufwand abgerechnet (dienstvertraglich), das Gesamtergebnis eines Release soll aber abnahmefähig sein (werkvertraglich). Diese Hybridstruktur ist rechtlich zulässig, erfordert aber eine klare vertragliche Regelung. Fehlt sie, wird im Streitfall nach dem Schwerpunkt des Vertrags entschieden – mit erheblicher Rechtsunsicherheit für beide Seiten.
Welche besonderen Risiken entstehen bei agiler Entwicklung ohne klare Vertragsstruktur?
Agile Methoden bringen einen iterativen, inkrementellen Entwicklungsprozess mit sich, der mit dem klassischen Lasten- und Pflichtenheft nur bedingt kompatibel ist. Genau hier liegen die Hauptrisiken für Auftraggeber im Mittelstand.
Erstens: das Scope-Creep-Problem. Werden Anforderungen (User Stories, Epics) im Projektverlauf fortlaufend angepasst, entsteht schnell Uneinigkeit darüber, was der ursprüngliche Vertragsgegenstand war und was als Zusatzleistung vergütet werden muss. Ohne Change-Management-Klauseln und ein dokumentiertes Änderungsprotokoll ist die Grenze zwischen vertragsgemäßer Leistung und Zusatzauftrag kaum zu bestimmen.
Zweitens: die fehlende Abnahme-Struktur. Im klassischen Werkvertrag gibt es eine finale Abnahme. Bei agiler Entwicklung wird in kurzen Zyklen (Sprints von typischerweise zwei bis vier Wochen) iteriert. Die Frage, ob jeder Sprint-Review eine Teilabnahme darstellt, ist rechtlich komplex. Wird sie bejaht, können Mängelrechte für ältere Sprints bereits verjähren, bevor das Gesamtsystem fertiggestellt ist. Wird sie verneint, riskiert der Auftragnehmer, erst am Projektende Vergütungsansprüche geltend machen zu können – was seine Liquidität belastet.
Drittens: die Vergütungsunsicherheit. Reine Time-and-Material-Ansätze sichern den Auftragnehmer, belasten aber den Auftraggeber mit dem Kostenrisiko. Feste Budgets bei variablem Scope widersprechen der agilen Logik. Nach unserer Erfahrung in der Beratung mittelständischer Auftraggeber führt dieser Widerspruch ohne vertragliche Auffangmechanismen regelmäßig zu Eskalationen nach zwei bis drei Projektquartalen.
Viertens: Urheberrechtliche Fragen bleiben in agilen IT-Projekten oft ungeklärt. Software ist nach dem deutschen Urhebergesetz als Werk geschützt. Wer während eines iterativen Entwicklungsprozesses welche Nutzungsrechte zu welchem Zeitpunkt erhält, muss explizit geregelt sein – andernfalls verbleiben Rechte im Zweifel beim schöpfenden Entwickler.
Abnahme und Mängelrecht – was gilt konkret bei agiler Software?
Die Abnahme ist im werkvertraglichen IT-Projekt das Schlüsselinstitut. Sie hat mehrere Rechtswirkungen, die für Geschäftsführer im Mittelstand von unmittelbarer Bedeutung sind.
Mit der Abnahme wird die vereinbarte Vergütung fällig (§ 641 BGB). Zugleich beginnt die Verjährungsfrist für Mängelansprüche. Im Werkvertragsrecht beträgt die Regelverjährung für Mängelansprüche nach § 634a BGB grundsätzlich zwei Jahre bei beweglichen Sachen und Arbeiten daran; bei Bauwerken gelten fünf Jahre. Software wird von der Rechtsprechung überwiegend nicht als Bauwerk eingestuft, sodass in der Regel die kürzere Frist greift – was für Auftraggeber bedeutet: Mängel müssen früh identifiziert und gerügt werden.
Darüber hinaus geht mit der Abnahme die Beweislast für Mängel auf den Auftraggeber über. Vor der Abnahme muss der Auftragnehmer beweisen, dass seine Leistung vertragsgemäß ist; nach der Abnahme muss der Auftraggeber den Mangel nachweisen. Diese Umkehr hat in der Praxis erhebliche Konsequenzen.
Bei agiler Entwicklung stellt sich die Frage, ob der Auftraggeber durch aktive Teilnahme an Sprint-Reviews, durch Feedback und durch fortlaufende Nutzung von Inkrementen konkludent – also stillschweigend – eine Abnahme erklärt. Nach unserer Einschätzung ist diese Gefahr real: Wer ein Software-Inkrement produktiv nutzt, ohne ausdrücklich einen Vorbehalt zu erklären, riskiert, dass dies als Billigung gewertet wird. Vertragliche Regelungen zur ausdrücklichen Abnahme-Erforderlichkeit und zur Bedeutung von Sprint-Reviews sind daher zwingend erforderlich.
Liegt ein Mangel vor, hat der Auftraggeber zunächst einen Anspruch auf Nacherfüllung (§ 635 BGB). Erst wenn die Nacherfüllung scheitert oder verweigert wird, bestehen weitergehende Rechte wie Minderung (§ 638 BGB) oder Rücktritt (§ 634 Nr. 3 BGB). Der Rücktritt von einem längerlaufenden IT-Entwicklungsvertrag ist rechtlich und tatsächlich komplex – insbesondere wenn Teilergebnisse bereits genutzt werden.
Wie sollte ein IT-Projektvertrag für agile Entwicklung strukturiert sein?
Ein rechtssicher gestalteter agiler IT-Projektvertrag kombiniert werkvertragliche Ergebnisverantwortung mit der notwendigen Flexibilität agiler Methoden. Die wesentlichen Regelungsbausteine lassen sich in einer strukturierten Entscheidungsmatrix darstellen:
Konstellation A – Festes Produkt, iterative Umsetzung: Instrument → Werkvertrag mit definierten Releases als Abnahmemeilensteine → Vergütung je Milestone → rechtliche Folge: klare Fälligkeits- und Mängelhaftungsstruktur.
Konstellation B – Explorative Entwicklung, unklarer Scope: Instrument → Rahmenvertrag mit Einzelabrufen (Dienstvertrag pro Sprint, Werkvertrag für definierte Releases) → Time-and-Material-Vergütung mit Budget-Cap → rechtliche Folge: Auftraggeber trägt Kostenrisiko, Auftragnehmer das Herstellungsrisiko nur für definierte Deliverables.
Konstellation C – Langfristige Entwicklungspartnerschaft: Instrument → Rahmendienstleistungsvertrag mit werkvertraglichen Leistungsscheinen → jährliche Budgetplanung mit Change-Control-Prozedur → rechtliche Folge: Kontinuität und Flexibilität, aber erhöhter Dokumentationsaufwand.
Unabhängig von der Grundstruktur sollten folgende Klauseln in keinem agilen IT-Projektvertrag fehlen: eine präzise Definition der Abnahme-Kriterien (Definition of Done), ein Change-Request-Prozess mit Schriftformerfordernis, eine ausdrückliche Regelung zur Nutzungsrechteübertragung an erstellter Software (§§ 69a ff. UrhG), eine Klausel zur Behandlung von Sprint-Reviews (kein Abnahme-Surrogat), eine Regelung zu Eskalationsstufen und Streitbeilegung sowie eine Regelung zur Vertraulichkeit und zum Datenschutz nach Maßgabe der DSGVO.
Besonders die Nutzungsrechteübertragung wird in der Praxis häufig vernachlässigt. Software als Werk des Urheberrechts erfordert eine ausdrückliche Einräumung der Nutzungsrechte (§ 31 UrhG). Ohne vertragliche Regelung verbleiben die Rechte beim schöpfenden Entwickler – auch wenn dieser für die Erstellung bezahlt wurde. Im Streitfall kann dies zur faktischen Abhängigkeit des Auftraggebers vom Auftragnehmer führen.
Haftung der Geschäftsführung – welche persönlichen Risiken entstehen?
Für Geschäftsführer im Mittelstand ist die Frage der persönlichen Haftung bei fehlgeschlagenen IT-Projekten keine abstrakte. Der Fremdgeschäftsführer einer GmbH und der geschäftsführende Gesellschafter unterliegen der Sorgfaltspflicht des § 43 GmbHG. Vertragsschlüsse ohne hinreichende rechtliche Prüfung, insbesondere bei erheblichem Investitionsvolumen, können als Pflichtverletzung gewertet werden.
Konkret: Genehmigt ein Geschäftsführer ein IT-Projekt ohne angemessene Prüfung der Vertragsunterlagen und entsteht der Gesellschaft durch einen nachteiligen Vertrag ein erheblicher Schaden, kann die Gesellschaft – oder im Insolvenzfall der Insolvenzverwalter – ihn persönlich in Regress nehmen. Die Beweislastumkehr des § 43 Abs. 2 GmbHG wirkt dabei zu Lasten des Geschäftsführers: Er muss nachweisen, dass er seine Pflichten nicht verletzt hat.
In der Mandatspraxis beraten wir regelmäßig Unternehmen, bei denen IT-Projekte mit einem Gesamtbudget im sechsstelligen Bereich und darüber begonnen wurden, ohne dass der Vertrag systematisch geprüft wurde. Die typischen Streitpunkte: fehlende Abnahme-Protokolle, mündlich vereinbarte Scope-Änderungen ohne schriftliche Dokumentation, und Vergütungsstreitigkeiten über den Umfang der Time-and-Material-Abrechnung. Das Ergebnis sind nicht selten langwierige und kostenintensive Auseinandersetzungen.
Der Grundsatz der unternehmerischen Sorgfalt gebietet daher die anwaltliche Vorprüfung von IT-Projekten oberhalb einer intern festzulegenden Wesentlichkeitsschwelle. Dies gilt besonders, wenn der Vertrag durch den Auftragnehmer vorformuliert ist – in diesem Fall unterliegen AGB-Klauseln der Inhaltskontrolle nach §§ 305 ff. BGB, was erhebliche Überraschungs- und Transparenzfallen enthält.
Was gilt bei Streit – Eskalation, Mediation, gerichtliches Verfahren?
Scheitert ein IT-Projekt oder entsteht Streit über Mängel und Vergütung, stehen Auftraggeber und Auftragnehmer vor der Frage, auf welchem Weg der Konflikt gelöst werden kann. Die Wahl des Streitbeilegungswegs beeinflusst Kosten, Zeitaufwand und Geschäftsbeziehung erheblich.
Im Regelfall empfiehlt sich eine gestufte Eskalationsklausel im Vertrag: Zunächst interne Eskalation auf Managementebene, dann Mediation durch einen technisch versierten Mediator, und erst danach das staatliche Gericht oder ein Schiedsverfahren. Dieser Ansatz erhält die Chance auf eine einvernehmliche Lösung und vermeidet die typischen Nachteile eines IT-Gerichtsverfahrens: erhebliche Kosten für Sachverständigengutachten, lange Verfahrensdauer und technische Komplexität.
Wird der ordentliche Rechtsweg beschritten, sind IT-Streitigkeiten häufig am Landgericht am Sitz des Beklagten anhängig zu machen. Die sachliche Zuständigkeit richtet sich nach dem Streitwert: Bei einem Streitwert von mehr als 5.000 € ist das Landgericht zuständig, was Anwaltspflicht auf beiden Seiten bedeutet. Für grenzüberschreitende IT-Projekte mit ausländischen Dienstleistern gelten zusätzliche Fragen der internationalen Zuständigkeit und des anwendbaren Rechts – Bereiche, in denen sorgfältige Rechtswahl- und Gerichtsstandsklauseln im Vertrag unverzichtbar sind.
Schiedsgerichtsbarkeit, insbesondere nach der DIS-Schiedsgerichtsordnung, bietet für technisch komplexe IT-Streitigkeiten Vorteile: Vertraulichkeit, Auswahl technisch versierter Schiedsrichter und internationale Vollstreckbarkeit. Der Nachteil liegt in den regelmäßig höheren Verfahrenskosten für kleinere Streitwerte. Ob Schiedsklausel sinnvoll ist, hängt daher von Projektvolumen und Internationalität ab.
Wichtig: Mängelrügen und Nacherfüllungsverlangen müssen schriftlich und mit konkreter Fehlerbeschreibung erfolgen. Eine pauschale Rüge – „die Software funktioniert nicht" – genügt nicht. Die genaue Beschreibung des Defizits, idealerweise mit Testprotokollen und Fehlerlogs, ist Voraussetzung für eine wirksame Mängelgeltendmachung und für die gerichtliche Beweisführung.
Welche Besonderheiten gelten bei SaaS und Cloud-basierten Entwicklungsplattformen?
Ein wachsender Anteil agiler IT-Projekte nutzt Cloud-Infrastrukturen und SaaS-Tools (Software as a Service) sowohl als Entwicklungsumgebung als auch als Zielbetriebsplattform. Dies schafft eine zusätzliche rechtliche Ebene, die in der Vertragsgestaltung nicht übersehen werden darf.
Wird die entwickelte Software als SaaS betrieben, verändert sich das Vertragsmodell fundamental: Der Auftraggeber erhält keine Software im klassischen Sinne, sondern ein zeitgebundenes Nutzungsrecht an einem gehosteten Dienst. Das bedeutet, dass Abnahme, Mängelrecht und Nutzungsrechte anders strukturiert sein müssen als im klassischen Werkvertrag. Insbesondere stellt sich die Frage der Verfügbarkeit (Service Level Agreements, SLAs), der Datenspeicherung nach deutschem und europäischem Datenschutzrecht sowie der Exit-Strategie bei Vertragskündigung.
DSGVO-Compliance ist bei Cloud-basierten IT-Projekten kein optionaler Zusatz, sondern rechtliche Pflicht. Werden personenbezogene Daten verarbeitet – und das ist bei nahezu jeder Unternehmensanwendung der Fall –, muss ein Auftragsverarbeitungsvertrag (AVV) nach Art. 28 DSGVO geschlossen werden. Fehlt dieser, drohen Bußgelder von bis zu 20 Millionen Euro oder vier Prozent des weltweiten Jahresumsatzes (Art. 83 DSGVO), je nachdem, welcher Betrag höher ist. In der Praxis sehen wir häufig, dass AVVs erst nachträglich und unter Zeitdruck abgeschlossen werden – ein unnötiges Risiko, das durch frühzeitige Vertragsgestaltung vermieden werden kann.
Zusätzlich ist die Frage des Datentransfers in Drittstaaten zu beachten. Viele international tätige Cloud-Anbieter verarbeiten Daten außerhalb des Europäischen Wirtschaftsraums. Hier sind geeignete Garantien nach Art. 46 DSGVO – etwa Standardvertragsklauseln – erforderlich, deren Wirksamkeit nach dem Schrems-II-Urteil des EuGH einer individuellen Risikoabwägung bedarf.
Praktische Handlungsempfehlungen für Geschäftsführer
Aus der rechtlichen Analyse ergeben sich für Geschäftsführer im Mittelstand konkrete Handlungsschritte, die das Risikoprofil agiler IT-Projekte wesentlich verbessern.
Vor Vertragsschluss: Klären Sie die Vertragstyp-Frage bewusst – Werkvertrag, Dienstvertrag oder Hybrid? Definieren Sie Abnahme-Kriterien (Definition of Done) so konkret, dass ein Dritter objektiv feststellen kann, ob sie erfüllt sind. Regeln Sie die Nutzungsrechteübertragung ausdrücklich und vollständig. Nehmen Sie Change-Control-Prozesse in den Vertrag auf – jede Scope-Änderung muss schriftlich vereinbart und vergütungsseitig erfasst werden. Prüfen Sie AGB des Auftragnehmers auf überraschende oder unangemessene Klauseln nach §§ 305 ff. BGB.
Während des Projekts: Führen Sie ein lückenloses Dokumentationsregime – Sprint-Protokolle, Abnahme-Erklärungen, Change Requests, E-Mail-Verkehr zu wesentlichen Entscheidungen. Erklären Sie Abnahmen niemals stillschweigend durch Nutzung, sondern ausdrücklich und schriftlich. Rügen Sie erkannte Mängel zeitnah, konkret und schriftlich.
Bei Eskalation: Sichern Sie Beweise früh – Testprotokolle, Fehlerberichte, Kommunikation. Schalten Sie anwaltliche Unterstützung nicht erst bei drohender Klage ein, sondern sobald sich ein ernsthafter Konflikt abzeichnet. Die frühzeitige anwaltliche Bewertung der Vertragsposition entscheidet oft darüber, ob eine einvernehmliche Lösung noch möglich ist.
Aus der Mandatspraxis: In einem aktuellen Mandat beriet die Kanzlei ein mittelständisches Handelsunternehmen, das eine Eigenentwicklung einer ERP-Integration mit einem IT-Dienstleister beauftragt hatte. Ausgangslage: Nach mehreren Sprints und einer erheblichen Budgetüberschreitung verweigerte das Unternehmen die Abnahme des Gesamtsystems mit der Begründung, wesentliche Schnittstellen seien nicht funktionsfähig. Der Auftragnehmer berief sich darauf, durch die aktive Nutzung des Systems in der Testumgebung habe der Auftraggeber konkludent abgenommen. Vorgehen: Die Kanzlei analysierte den Vertrag und die Sprint-Dokumentation und identifizierte, dass die Abnahme-Regelung kein Schriftformerfordernis enthielt und die Nutzung der Testumgebung vertraglich nicht von der Abnahme getrennt war. Auf dieser Grundlage wurde ein strukturiertes Verhandlungskonzept entwickelt, das die offenen Mängelrügen präzise konkretisierte und auf die fehlende ausdrückliche Abnahme-Erklärung abstellte. Ergebnis: Das Verfahren konnte durch eine außergerichtliche Einigung mit Nachbesserungsplan und angepasster Vergütungsstruktur gelöst werden – ohne gerichtliche Auseinandersetzung. Die Einzelheiten des wirtschaftlichen Ergebnisses unterliegen der Vertraulichkeit.
Vertragsgestaltung im Licht der Rechtsprechungsentwicklung
Die deutsche Rechtsprechung hat sich in den vergangenen Jahren zunehmend mit agilen IT-Verträgen befasst. Eine gefestigte höchstrichterliche Linie zu allen Fragen agiler Entwicklungsverträge existiert noch nicht; die Instanzrechtsprechung entwickelt sich jedoch erkennbar in Richtung einer differenzierten Betrachtung von Teilabnahmen und iterativen Leistungserbringungen.
Beachtenswert ist die allgemeine werkvertragliche Rechtsprechung des BGH zur Abnahme, insbesondere zur konkludenten Abnahme durch Inbetriebnahme. Diese Grundsätze werden von Instanzgerichten auf IT-Projekte übertragen, auch wenn die spezifischen Bedingungen agiler Entwicklung dabei nicht immer ausreichend berücksichtigt werden. Nach unserer Einschätzung ist es wahrscheinlich, dass sich die höchstrichterliche Rechtsprechung mittelfristig stärker mit agilen Vertragsstrukturen befassen wird – bis dahin besteht erhöhter Regelungsbedarf auf Vertragsebene.
Für Geschäftsführer bedeutet dies: Wer auf eine klärende höchstrichterliche Entscheidung wartet, bevor er seinen IT-Projektvertrag anpasst, handelt auf eigenes Risiko. Die sichere Gestaltungsoption liegt in einer klaren vertraglichen Regelung, die die rechtlichen Unklarheiten antizipiert – nicht in der Hoffnung auf eine günstige Gerichtsentscheidung.
Interessant ist in diesem Zusammenhang auch die europäische Dimension: Der European Interoperability Framework und die im Entstehen begriffenen Standards für öffentliche IT-Vergaben beeinflussen zunehmend auch privatwirtschaftliche Best-Practice-Standards. Der EU Cyber Resilience Act, der Anforderungen an die Sicherheit digitaler Produkte stellt, wird künftig ebenfalls Vertragsgestaltungen in der Softwareentwicklung beeinflussen – insbesondere was Sicherheitsupdates, Schwachstellenmanagement und Dokumentationspflichten angeht. Auftraggeber, die heute Verträge für Entwicklungsprojekte mit einer Laufzeit von drei bis fünf Jahren schließen, sollten diese regulatorische Entwicklung in der Vertragsgestaltung berücksichtigen.
Verwandte Leistungen
Häufige Fragen zum IT-Projektvertrag und agiler Softwareentwicklung
Welcher Vertragstyp gilt für agile IT-Projekte nach deutschem Recht?
Das hängt vom Leistungsinhalt ab. Schuldet der Auftragnehmer ein konkretes, abnahmefähiges Ergebnis, gilt Werkvertragsrecht nach §§ 631 ff. BGB. Schuldet er nur sorgfältige Tätigkeit, gilt Dienstvertragsrecht nach §§ 611 ff. BGB. Bei agiler Entwicklung entstehen häufig Mischformen, die einer ausdrücklichen vertraglichen Regelung bedürfen, um Rechtsunsicherheit zu vermeiden.
Was passiert rechtlich, wenn kein schriftlicher IT-Projektvertrag besteht?
Ein IT-Projektvertrag ist grundsätzlich auch ohne Schriftform wirksam; mündliche Vereinbarungen sind bindend. Fehlt eine schriftliche Dokumentation, ist im Streitfall jedoch schwer nachweisbar, was konkret vereinbart war – insbesondere bei Scope-Änderungen, Abnahme-Kriterien und Vergütungsvereinbarungen. Dies führt regelmäßig zu erheblichen Beweisschwierigkeiten und Prozessrisiken.
Wann beginnt die Verjährungsfrist für Mängelansprüche bei Software?
Die Verjährung beginnt mit der Abnahme des Werks. Bei Software, die nicht als Bauwerk eingestuft wird, gilt in der Regel die zweijährige Verjährungsfrist des § 634a BGB. Entscheidend ist daher der Abnahme-Zeitpunkt – und ob eine wirksame Abnahme überhaupt erklärt wurde, was bei agilen Projekten ohne klare Abnahme-Regelung unklar sein kann.
Wer ist Inhaber der Urheberrechte an der entwickelten Software?
Urheberrechte an Software entstehen beim schöpfenden Entwickler (§ 69a UrhG). Ohne ausdrückliche vertragliche Nutzungsrechte-Übertragung nach § 31 UrhG verbleiben die Rechte beim Auftragnehmer, auch wenn der Auftraggeber die Entwicklung bezahlt hat. Eine vollständige, schriftliche Rechteübertragung für alle bekannten Nutzungsarten ist daher unverzichtbarer Bestandteil jedes IT-Projektvertrags.
Welche DSGVO-Pflichten bestehen bei Cloud-basierten IT-Projekten?
Werden personenbezogene Daten verarbeitet, ist ein Auftragsverarbeitungsvertrag nach Art. 28 DSGVO mit dem Cloud-Anbieter zwingend erforderlich. Zudem müssen Datentransfers in Drittstaaten durch geeignete Garantien abgesichert sein. Verstöße können Bußgelder von bis zu 20 Millionen Euro oder vier Prozent des weltweiten Jahresumsatzes nach Art. 83 DSGVO nach sich ziehen.
Kann ein Auftraggeber ein IT-Projekt ohne Abnahme kündigen?
Ja – der Auftraggeber kann einen Werkvertrag jederzeit kündigen (§ 648 BGB). Er muss dann aber die vereinbarte Vergütung abzüglich ersparter Aufwendungen zahlen. Bei einem Dienstvertrag gilt die ordentliche Kündigung nach den vereinbarten Fristen. Die Kündigung aus wichtigem Grund (§ 314 BGB) setzt voraus, dass dem anderen Teil die Fortsetzung unzumutbar ist – was bei gravierenden Pflichtverletzungen des Auftragnehmers in Betracht kommt.
Die vorstehende Darstellung betrifft die wesentlichen Regelfälle des deutschen IT-Vertragsrechts. Ihr konkretes Projekt erfordert die individuelle Prüfung Ihrer Vertragsunterlagen, der vereinbarten Leistungsbeschreibungen und der einschlägigen Abnahme-Dokumentation. 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.