Your software house has just sent over an agreement for an implementation project worth PLN 800,000. It is 47 pages long. You want to sign and get started. Before you do, check whether those 47 pages are missing clauses that could leave you without rights to the code you paid for six months from now.
The statistics are clear: as many as 70% of IT projects do not deliver what was promised to the client before work began. Failure rates range from 5% to 15%, and 17% of IT projects may fail in a way that threatens the company’s existence. At the same time, implementing appropriate project management, including a well-drafted agreement, can reduce the failure rate to 20% or less.
This article is a checklist of 10 clauses your IT implementation agreement should contain. Each addresses a specific financial, legal, or operational risk. I write from the customer’s perspective, because you are spending the money and bear the consequences if the agreement does not protect your interests.
Before you start: terms you need to know
An IT implementation agreement is an unnamed contract: the Polish Civil Code does not regulate it directly. It may combine elements of a contract for work, a services contract, and copyright agreements. This gives the parties flexibility, but requires precise drafting.
| Term | Meaning |
|---|---|
| Contract for work (Civil Code Articles 627 to 646) | The contractor is responsible for achieving a specific result, such as a working system. The customer may withdraw from the contract if the result is not achieved. |
| Services contract (Civil Code Article 750) | The contractor undertakes to exercise due care but does not guarantee a specific outcome. It ends by termination, with effect for the future. |
| Fields of exploitation (Article 50 of the Copyright Act) | Specific ways of using a work, such as installation, modification, or making it available. The agreement covers ONLY fields expressly listed in it (Article 41(2)). |
| SLA (Service Level Agreement) | An agreement on service levels that defines measurable quality parameters, such as availability, response time, and repair time, and the consequences of missing them. |
| Change request | A formal request to change the project scope, describing the impact on schedule and budget. |
| Scope creep | Uncontrolled expansion of project scope without formal approval or a budget adjustment. |
| Source code escrow | Code deposited with an independent third party to protect the customer if the provider becomes insolvent or ceases operations. |
Clause 1: legal classification of the agreement, work or services
This is the foundation on which the entire liability regime depends. In its judgment of 29 November 2006 (case II CSK 267/06), the Supreme Court treated a waterfall implementation agreement as a mixed contract with a dominant element of a contract for work. The customer could withdraw from the entire agreement, including the license, if the business objective, a working system, was not achieved.
The consequences of the classification are significant:
| Criterion | Contract for work | Services contract |
|---|---|---|
| Liability | For failure to achieve the result | For failure to exercise due care |
| Ending the agreement | Withdrawal, with retroactive effect | Termination, with effect for the future |
| Warranty for defects | Yes (Civil Code Article 638) | No |
| Limitation period | 2 years from delivery of the work | 2 years for certain claims |
| Remuneration | Linked to delivery of the work | For activities performed |
What to do: State the legal classification expressly in the preamble or Section 1 of the agreement. If implementation combines a design phase (work) with maintenance (services), separate those parts and assign each its own regime. Do not leave this “open to interpretation,” because a court, not you, will interpret it.
Clause 2: precise implementation scope and change request procedure
Scope is the most common point of dispute in implementation agreements. Without a clear line between what is “in scope” and what counts as a change, scope creep can expand the project uncontrollably, exceed the budget, and delay delivery.
How you describe scope depends on the chosen methodology:
| Element | Waterfall (Fixed Price) | Agile/Scrum (Time & Material) |
|---|---|---|
| Scope description | Detailed functional and technical specification attached to the agreement | General product vision, backlog working rules, and Product Owner responsibilities |
| Change management | Formal change request procedure: request, impact analysis, approval, amendment | Changes managed through the backlog; distinguish scope evolution from changes requiring additional payment |
| Schedule | Sequential phases with milestones and acceptance dates | Sprint length, planning horizon, and planning rules |
What to do:
- Describe the scope in a functional appendix with measurable acceptance criteria for waterfall or a Definition of Done for agile.
- Establish a formal change request procedure: who submits and approves a request, how it affects the schedule and budget, and the required form, written or electronic.
- Specify what is NOT included in scope. A list of exclusions can be as important as a list of features.
Scenario: an e-commerce company orders a system implementation for PLN 500,000. After 8 months of work, it turns out that the agreement does not regulate change requests. The contractor says 40% of the work consists of changes outside scope. The customer says it was all in scope. Without a mechanism to resolve this, the parties reach an impasse and the dispute escalates to court.
Clause 3: a payment model that fits the methodology
The payment model is not just a financial question. It determines how budget risk is allocated between the parties.
| Criterion | Fixed Price | Time & Material | T&M with a cap |
|---|---|---|---|
| Budget | Set in advance | No complete budget at the outset | Maximum budget set in advance |
| Required scope detail | High | Lower | Medium |
| Flexibility for changes | Low | High | Medium |
| Typical methodology | Waterfall | Agile/Scrum | Hybrid projects |
| Budget risk | Greater on the contractor’s side | Greater on the customer’s side | Shared |
What to do:
- Match the payment model to the methodology and level of scope detail.
- For Fixed Price, regulate lump-sum remuneration (Civil Code Article 632): as a rule, the contractor cannot demand an increase even if costs prove higher. Exception: an extraordinary change in circumstances threatens a severe loss.
- For T&M, set a budget cap and rules for reporting hours. Without them, you lose control over spending.
- Link payments to milestones or sprint acceptance. Do not pay for the entire project upfront.
Clause 4: copyright, assignment or license
This is the clause whose omission or defective wording can deprive you of rights to code you paid for. Article 53 of the Copyright Act requires a written form to assign economic copyrights, on pain of invalidity. Clicking “I accept” in an email is not enough.
Common customer mistakes in IP clauses
- Not listing fields of exploitation. A general phrase such as “the contractor assigns copyright” without specifying the fields means the buyer does not acquire the right to use the work in any field.
- General clauses covering “all known fields” without further detail risk a narrow court interpretation. Wording covering “unknown fields of exploitation” directly conflicts with Article 41(4) and is invalid.
- Omitting derivative rights and modifications. Consent to make changes to a program is not enough. The agreement must expressly regulate the right to use adaptations (Article 2) and the right to authorize the exercise of derivative copyright.
- Not specifying remuneration in relation to the fields. If the agreement does not state that remuneration covers all listed fields, the creator may claim separate remuneration (Article 45).
- Gaps in the supply chain. A contractor using B2B subcontractors may not own rights to every part of the code. Rights to a program created by an employee belong to the employer under Article 74(3), but B2B agreements require an express rights assignment.
Key fields of exploitation in IT agreements:
| Group | Examples | Why it matters |
|---|---|---|
| Reproduction | Installation on servers, backups, replication in test environments | Scalability and data security |
| Modification and integration | Adaptation, layout changes, integration with other systems, new modules | Avoiding vendor lock-in and adapting to business needs |
| Distribution | Providing SaaS services and sublicenses to subsidiaries | Ability to use the work commercially |
| Documentation | Reproducing instructions and using the interface in materials | Training users and marketing |
Scenario: a SaaS startup signs an agreement with a software house to build an MVP. The agreement contains no written assignment of copyright, only an email. A year later, the startup seeks an investor. Due diligence reveals that the company does not own the rights to its source code. The investor withdraws from the transaction.
Clause 5: the customer’s duty to cooperate
Civil Code Article 354 § 2 requires the customer to cooperate in performing the obligation. A failure to cooperate may exclude the contractor’s liability for delay and may even justify terminating the agreement for the customer’s fault and claiming the full remuneration.
What to do:
- Describe the customer’s specific duties: providing migration data, access to systems, appointing decision-makers, and participating in acceptance testing.
- Set deadlines for carrying out these duties.
- Specify the consequences of a failure to cooperate, such as extending the schedule by the period of the customer’s delay.
- Set an escalation procedure. If the customer does not respond, the contractor should follow a clear route: notice, escalation to the Steering Committee, then a right to suspend work.
Scenario: a company is implementing a CRM system. The agreement does not specify the customer’s duty to cooperate. The customer does not provide migration data for 3 months. The contractor terminates the agreement because of the customer and demands full payment. The customer is left without a system and without its money.
Clause 6: governance structure, project manager and steering committee
The Project Manager and Steering Committee are not buzzwords from a presentation. They are people with specific decision-making authority who must be named in the agreement. Without a governance structure, decisions are blocked for weeks and conflicts between teams have no resolution mechanism.
What to do:
- Name Project Managers on both sides and describe their authority, including acceptance approval, approval of change requests up to a specified amount, and escalation.
- Set the Steering Committee membership, including people authorized to make strategic decisions on budget, schedule, and scope changes.
- Set the frequency of status meetings and the reporting format.
- Describe the escalation route: Project Manager, Steering Committee, then the parties’ boards. Involve the highest levels only for changes with a major impact on the project.
In agile projects, Scrum ceremonies such as sprint reviews and retrospectives can serve as formal checkpoints. A sprint review allows ongoing acceptance of delivered increments; a retrospective is used to improve collaboration.
Clause 7: acceptance procedure and acceptance testing
Acceptance is when the customer confirms that the contractor has delivered what was promised. Without a clear acceptance procedure with measurable criteria, every acceptance can become a source of conflict.
What to do:
- Define acceptance stages: partial acceptance after each phase or sprint and final acceptance.
- Describe acceptance criteria as measurable requirements. In waterfall, check compliance with the specification; in agile, use Acceptance Criteria for each User Story.
- Set a UAT (User Acceptance Testing) procedure: test plan, test scenarios, execution, results analysis, fixes, retests, acceptance.
- Set deadlines for submitting comments and correcting them.
- Specify the consequences if the customer does not respond, such as deemed acceptance after a stated period.
Clause 8: SLA with measurable parameters and contractual penalties
An SLA without measurable parameters and a link to contractual penalties is a statement of intent, not an obligation. If the agreement covers post-implementation maintenance, you need an SLA that gives you tools to enforce service quality.
Parameters to define:
| Parameter | Description | Example values |
|---|---|---|
| System availability | Percentage of uptime during the billing period | 99% = about 7 hours 12 minutes of downtime per month |
| Response time | Time from incident report to start of action | Depends on the error category |
| Repair time | Time from incident report to restoring full functionality | Depends on the error category |
| Error classification | Incident categories based on impact on system operation | Blocker, Critical, Major, Minor, Trivial |
Contractual penalties: standards and case law:
The Ministry of Digital Affairs’ model clauses provide for 0.1% of remuneration for each day of delay. Public Procurement Chamber (KIO) case law, in a judgment of 22 August 2023, indicates a range of 10% to 30% of gross remuneration as an aggregate penalty cap consistent with proportionality. A cap of 100% of net remuneration was considered abusive.
Civil Code Article 484 § 2 allows a court to moderate (reduce) a contractual penalty if the obligation has been substantially performed or the penalty is grossly excessive. Supreme Court resolution III CZP 16/21 confirms this principle.
What to do:
- Define measurable SLA parameters and link them to specific penalties.
- Set an aggregate cap on contractual penalties. In the private sector, 100% of remuneration is a standard.
- Introduce periodic reporting on availability, incident counts and categories, and average response and repair times.
Clause 9: personal data protection (GDPR) and confidentiality (NDA)
Every implementation agreement under which the contractor processes the customer’s personal data requires a written data processing agreement compliant with GDPR Article 28. Its absence is an independent basis for a fine by the President of UODO. Decisions with penalties reaching nearly PLN 5 million, including the Fortum case, confirm that the authority enforces this obligation.
Two separate documents, two separate purposes:
| Document | Purpose | Form | When to sign |
|---|---|---|---|
| NDA (non-disclosure agreement) | Protects commercial, technical, and strategic information | Written | BEFORE exchanging any confidential information. Do not wait until the main agreement is finalized. |
| DPA (data processing agreement) | Meets GDPR Article 28 requirements when the contractor processes personal data | Written, including electronic form | As an appendix to the main agreement or as a separate document |
GDPR fines can reach EUR 10 million (or 2% of annual turnover) for breaches of controller or processor obligations and EUR 20 million (or 4% of annual turnover) for breaches of fundamental processing principles.
What to do:
- Sign an NDA as a separate document before beginning discussions about the project.
- Prepare a DPA as an appendix to the main agreement, specifying the data scope, processing purpose, processor’s obligations, and rules for subprocessing.
- Verify that the contractor applies appropriate technical and organizational measures (GDPR Article 32).
Clause 10: exit clause, how to leave the agreement without vendor lock-in
Without an agreed exit route, ending the agreement can lead to months of litigation and loss of access to a partly implemented system. An exit clause protects you if the relationship does not go to plan.
An exit clause should include:
- Termination and withdrawal conditions: when either party can end the agreement, for example, material delay, breach of obligations, or insolvency.
- Settlement for partially completed work: how to value and settle what has already been delivered.
- Duty to hand over documentation and source code: the contractor must provide all materials the customer needs to continue the project with another provider.
- Transition period: a period when the current contractor supports the new provider in taking over the system.
- Source code escrow: code deposited with an independent third party under a deposit agreement (Civil Code Article 835). This protects against provider insolvency or cessation of business. Escrow effectiveness depends on the copyright rights granted to the customer in the main agreement.
Scenario: implementation is complete, but the agreement does not regulate exit or handover of code. The company wants to change its maintenance provider. The current contractor refuses to hand over technical documentation because “the agreement does not provide for it.” The company is locked in for years.
How open source affects IP clauses: an easy-to-miss risk
A contractor using open-source components in an implementation project may unintentionally restrict your rights to the entire system. Open-source licenses have different terms, and not all are compatible with a commercial model.
| License | Type | Risk to the customer |
|---|---|---|
| GPL (GNU General Public License) | Strong copyleft | Code built on a GPL component must be made available under the same license. This may prevent the customer from keeping the code closed for commercial use. |
| MIT | Permissive | Low risk; requires retaining attribution and license information. |
| Apache 2.0 | Permissive, with patent protection | Low risk, with additional protection against patent claims. |
EU Regulation 2024/2847 (Cyber Resilience Act) introduces additional security requirements for products with digital elements, which may affect obligations concerning open-source components.
What to do:
- Require the contractor to provide a list of every open-source component used in the project, with its license.
- Check license compatibility with your business model, particularly for GPL.
- Set out the contractor’s liability for breaches of open-source license terms.
Checklist before signing an IT implementation agreement
Before signing, conduct an internal “closing review.” The table below summarizes the 10 clauses and their priority:
| No. | Clause | Priority | Risk if missing |
|---|---|---|---|
| 1 | Legal classification (work or services) | Mandatory | Unfavorable liability regime and loss of the right to withdraw |
| 2 | Implementation scope and change requests | Mandatory | Scope creep, budget overruns, and scope disputes |
| 3 | Payment model | Mandatory | Loss of spending control |
| 4 | Copyright (IP) | Mandatory | No rights to code, blocked development, failed due diligence |
| 5 | Duty to cooperate | Mandatory | Customer liability for delays |
| 6 | Governance (project manager and committee) | Recommended | Blocked decisions and conflicts without a resolution mechanism |
| 7 | Acceptance procedure | Mandatory | Disputes about quality and scope of delivered work |
| 8 | SLA with contractual penalties | Recommended | No tools to enforce maintenance quality |
| 9 | GDPR (DPA) and NDA | Mandatory | UODO fines up to EUR 10 million and disclosure of confidential data |
| 10 | Exit clause | Mandatory | Vendor lock-in, lost investment, and months of disputes |
70% of disputes emerge before signing the agreement and 30% after the contract is concluded. This checklist helps identify issues before they become costly.
IT implementation agreements: how we can help
A poorly drafted IT implementation agreement can generate costs many times greater than the project budget: uncontrolled scope creep, the need to hire a second provider to finish the work, litigation costs, and investment lost in code the company does not own.
A well-drafted agreement costs a fraction of the implementation budget. A poorly drafted one may cost more than the implementation itself.
We combine IT law, copyright, and contract law in a working model tailored to how technology companies deliver projects. We do not create documents “just in case.” We design rules where risk actually arises.
We can help in three scenarios:
- Reviewing an existing agreement: identify gaps and risks in the agreement you received from the provider.
- Negotiation: support you in negotiations with the software house, protecting your interests while keeping the collaboration possible.
- Drafting an agreement from scratch: design an implementation agreement for your business model, chosen methodology, and risk level.
Do you have an implementation agreement on your desk? Contact us. We will tell you what is missing and what it may cost you.
Frequently asked questions
Should an implementation agreement be treated as a contract for work or a services contract, and why does it matter?
It depends on the dominant element. The Supreme Court (case II CSK 267/06) treated a waterfall implementation agreement as a mixed contract with a dominant work element. If classified as a contract for work, the customer has a warranty for defects and may withdraw with retroactive effect if the result was not achieved. If classified as a services contract, the customer may only terminate with effect for the future and has no warranty. State the classification expressly in the agreement instead of leaving it for a court to interpret.
What happens if my agreement does not include a copyright assignment clause?
Assigning economic copyrights requires written form on pain of invalidity (Article 53 of the Copyright Act). If the agreement does not include this clause or was made only electronically, by email, without the required form, you do not acquire rights to the code. This means you cannot modify it, sublicense it, or use it commercially. In investor due diligence, this is one of the most common deal-breakers.
How should I describe the implementation scope to avoid disputes over scope creep?
A functional appendix alone is not enough. You need a formal change request procedure that specifies who submits a change, who approves it, how it affects schedule and budget, and what form the request must take. In agile, change is a natural part of the process, but the agreement must distinguish permissible scope evolution through the backlog from a change requiring additional payment. Also add a list of exclusions stating what is NOT included in the project.
Can I terminate an implementation agreement during a project, and what happens to payments?
You can, but only if the agreement provides for it. Without an exit clause, you have no clear basis for ending the agreement and no rules for settling partially completed work. An exit clause should cover termination and withdrawal conditions, valuing and settling completed work, handover of documentation and source code, and a transition period. Consider source code escrow as additional protection.
What should a good SLA look like, and which parameters and penalties are standard?
An SLA should include measurable parameters: system availability, such as 99% equaling about 7 hours of downtime per month, response time, and repair time by error category (Blocker, Critical, Major, Minor). The Ministry of Digital Affairs’ model clauses provide for 0.1% of remuneration per day of delay. KIO case law indicates an aggregate penalty cap of 10% to 30% of gross remuneration as proportionate. Include periodic performance reports too; without them, you have no data for enforcing penalties.
Should an NDA be a separate document, or is a confidentiality clause in the main agreement enough?
Sign an NDA as a separate document BEFORE exchanging any confidential information. Do not wait until the main agreement is finalized. If negotiations fail, information disclosed during discussions, such as customer data, system architecture, and development plans, remains protected. A confidentiality clause in the main agreement does not protect you during negotiations. In addition, if the contractor processes personal data, you need a separate data processing agreement compliant with GDPR Article 28.
