Practice area
IT contracts that hold up in a dispute
An IT contract is decisive not when it is signed but when something goes wrong. What counts then is what is owed, who has to cooperate, and when acceptance took place.
We draft and review contracts on software, IT projects and operations, on the supplier side as well as the customer side. Knowing both perspectives shortens the negotiation, because you know what the other side cannot give up. The firm is based in Hannover and works throughout Germany, on site as readily as by video call.
What we draft
Bespoke development, rollouts, migrations. Here the description of the work, the arrangement on cooperation and the acceptance procedure decide who carries a delay. We map agile work through increments with their own acceptance rather than a fixed price on a specification that will be rewritten anyway.
Ongoing operation, maintenance, support and availability. Service levels are worth only as much as their measurement: who measures, when an incident counts and what follows a breach all belong in the contract. Plus the questions that get expensive at the end, meaning data return, formats and deadlines.
Where cooperation goes beyond a single order, a framework agreement carries the recurring terms and the individual call-offs stay short. What matters is precedence, meaning which provision prevails where framework and call-off conflict.
Review of standard terms is strict, and an ineffective clause falls away entirely rather than being reduced to what is permitted. On licences we also check the terms of the open source components in use, because they can affect your own product.
Where mistakes get expensive
- Description of the workWhat is not described is not owed. Relying on a quotation as an annex leads to arguments about which version was meant.
- AcceptanceAcceptance reverses the burden of proof and starts time running. Implied acceptance through use is the most common point of dispute.
- Liability and indemnitiesA limitation drawn too widely falls away. One drawn too narrowly makes the project unsellable. The work lies in between.
- Rights in resultsWho owns what the project produces, and what may the supplier reuse? Without an arrangement the licence is narrower than expected.
- ExitData return, formats, transition support. Nobody enjoys drafting these clauses and everybody needs them.
- Use of AIConfidentiality of the data fed in and the origin of the code produced. Both belong in the contract before they show up in the project.
Individual questions in IT contracts
IT projects and rollouts
Who bears a delay is decided in three places: the statement of work, the duties to cooperate and the acceptance procedure. We model agile work through stages with their own acceptance, because a fixed price on a specification rarely survives contact with reality.
SaaS and ongoing operation
Service levels are worth only as much as their measurement. The contract has to say when an incident counts, what happens if the level is missed and how the data comes back at the end. Exit clauses are the ones nobody enjoys drafting and everybody eventually needs.
Defects in software
Whether a deviation is a defect depends on the agreed quality. Without an agreement the ordinary use decides, and that is fertile ground for dispute. More important than the classification is usually the period within which the defect was notified.
Standard terms and licences
Review of standard terms is strict, and an ineffective clause falls away entirely rather than being reduced to the permissible level. With software the terms of the open source components come on top, and they can reach into your own product.
Public sector clients
The public sector uses the standard EVB-IT contract templates, and choosing the right contract type decides more than which forms are filled in. Bidders should know the room for manoeuvre before the tender is submitted.
Legal opinions
Some questions call not for representation but for a defensible answer a decision can rest on. An opinion sets out the state of the debate, places it in context and names the uncertainty that remains.
Contract on the table, deadline in your neck?
You will hear what is missing and what to strike, before you sign.
Have the contract reviewedTopics in this practice area
- AI and the liability of company managementIntroducing AI is a business judgement under uncertainty. German company law requires preparation, supervision and review of the results.
- AI for developersAI in software development: licence risks in generated code, trade secrets in prompts, liability and the role under the AI Act.
- Choosing an AI toolThe questions to ask before procuring an AI tool: role, data, rights, records and the points that belong in the contract.
- Consortium and grant agreementsHorizon Europe: what has to be settled before acceding to the grant agreement, how far the ethics requirements reach and where the AI Act applies.
- EVB-IT contractsEVB-IT in German public IT procurement: contract types, what can be negotiated, and what suppliers and contracting authorities need to watch.
- Germany StackThe Deutschland-Stack as a shared foundation for public sector digitisation: status, core components and what it means for suppliers and authorities.
- IT project agreementsSecuring IT projects contractually: description of services, cooperation duties, change procedure, acceptance, milestones and exit scenarios.
- Joint controllershipIt arises from jointly determining purposes and means, without a contract and without intent. How far it reaches and what the arrangement has to settle.
- Legal opinionsLegal opinions for IT projects: the legal position written up systematically, with an assessment of the risk and a roadmap for implementation.
- Liability for AI outputWho answers for damage caused by AI, how the AI Act works as a protective statute, what the reformed product liability changes, and where insurance stops.
- Player contracts in esportsPay, practice obligations, rights in streams and recordings, transfers and buyouts: what belongs in a player contract and what makes it vulnerable.
- Professional secrecy and IT providersOutsourcing by professionals bound to secrecy: why the processing agreement does not cover confidentiality and which providers are ruled out as a result.
- SaaS agreementsDrafting and reviewing SaaS agreements: contract type, availability and service levels, data return and exit, price adjustment and liability.
- Software defectsEnforcing or defending claims over software defects: acceptance, notification duties, cure, price reduction, rescission and damages.
- Standard terms and contract draftingReview and drafting of sales, service and works contracts, framework agreements and standard terms for consumers and business dealings.
- Transcription assistantsDeploying AI meeting notes lawfully: criminal law, employee data protection, works council participation and the usage policy to go with it.
Frequently asked questions
Is a SaaS contract a lease or a services contract?
Under the case law of the Federal Court of Justice, merely making software available for use over the network points towards lease law. As soon as operation, maintenance and further development are added, a mixed contract arises. The classification determines remedies for defects and notice periods, and therefore belongs at the start of the drafting.
Our IT project has stalled. What is the first step?
Reading the contract, not the code. What matters is what is owed as performance, who owes which cooperation, and whether acceptance was declared. Only then can one say whether cure, reduction or termination is the right route.
Can we effectively limit our liability in our standard terms?
Only within limits. Towards consumers the boundaries are narrow, but even in business dealings a clause drawn too widely often falls away entirely rather than being reduced to what is permitted. You then face unlimited statutory liability. A reviewed clause is not a formality.
How does a contract for work fit agile development?
Badly, if it describes a fixed scope that nobody knows at the outset. Two routes are common: a services contract with time-based billing and clear steering, or a contract for work per increment with its own acceptance. What does not work is a fixed price on a specification that will be rewritten anyway.
Why do our contracts say so much about cooperation?
Because that is where most projects fail. Missing test data, interfaces that are not released and decisions left for three weeks delay a project just as much as poor code. Without named duties to cooperate, the supplier carries a delay that arose on the customer's side.
Should we require the source code?
If the software is built for you individually and your business depends on it, yes. In other cases escrow with a third party is the usual middle ground, with clearly defined events that trigger release. Without any arrangement, a supplier insolvency leaves you with a program nobody can maintain.
Our supplier uses AI. Does that need regulating?
Yes, in two directions. Feeding your data into a model can breach confidentiality obligations, and code from an assistant raises questions of origin and licence. Both belong in the contract before they show up in the project.