IT Contracts in Turkey

Software development, licensing, SaaS and cloud, IT outsourcing and systems integration – IT contracts form the legal backbone of every digitalisation effort. Turkish law has no dedicated IT contracts act; the governing rules are the general provisions of the Code of Obligations No. 6098 (in particular the law on contracts for work, services, lease and sale), copyright law (FSEK No. 5846) for the grant of rights, and, alongside them, data protection, e-commerce and, where applicable, sector-specific regulatory law. For foreign customers working with Turkish software houses – Turkey is a growing nearshoring destination – contract design determines the ownership of rights, the quality and the litigation-resilience of the project.

Table of contents

• How are IT contracts classified legally?
• How are software development contracts structured – classic and agile?
• Why is the rights clause the most important part of every IT contract?
• What should be considered in licence agreements for standard software?
• What should be considered in SaaS and cloud contracts?
• How are service levels, warranty and liability regulated?
• How are data protection and data security addressed in the IT contract?
• How are choice of law, forum and arbitration clauses structured?
• How do acceptance and documentation secure the evidence in the project?
• Which points belong in contracts with Turkish IT service providers?
• What lessons can be drawn from failed projects?
• Why is functionality decisive in software contracts? An example from practice
• Conclusion

How are IT contracts classified legally?

Classification determines the applicable statutory rules: bespoke software development is regularly a contract for work ("eser sözleşmesi") with success orientation, acceptance and work-contract defect liability; the permanent grant of software for a one-off fee is treated as akin to a sale or purchase of rights, the time-limited grant as akin to a lease; ongoing operation, maintenance and support services are service or mandate elements. In practice, IT contracts are of mixed type; contract drafting should therefore separate the blocks of performance cleanly – not least because termination, limitation and warranty rules differ by type.

How are software development contracts structured – classic and agile?

In the classic waterfall project, the specification, milestones, acceptance and defect rights can be clearly mapped in work-contract terms. Agile projects require adapted mechanisms: description of the method and roles, prioritisation and change processes, sprint acceptances and a contractually defined "Definition of Done", combined with budget and exit arrangements per phase. Indispensable in both models are: a precise description of the services, the customer's cooperation duties, provisions on source code delivery and documentation, key personnel and subcontractor clauses, and partial termination and migration arrangements in case of failure. In fixed-price projects, change management (change requests) should be subject to written form to avoid creeping scope expansion.

Why is the rights clause the most important part of every IT contract?

Under Turkish copyright law, the rights in developed software remain with the developer absent a valid transfer; the statutory allocation in favour of the employer applies only to the employer's own employees, not to commissioned service providers. Rights clauses must therefore be concluded in writing and identify the transferred economic rights individually; blanket "all rights" formulas do not suffice, and the transfer of rights in future works is invalid – in ongoing development, rolling transfer mechanisms (per acceptance or sprint, for example) must therefore be used. Also to be regulated: the chain of rights to the contractor's subcontractors and freelancers, the treatment of the provider's pre-existing components and development tools (licence rather than transfer), open-source compliance with an audit right, and – as a safeguard – source code escrow for insolvency and termination scenarios.

What should be considered in licence agreements for standard software?

For standard software, the scope and limits of the licence must be defined: simple or exclusive licence, user or device metrics, group and territorial clauses, the licensor's audit rights and their limits. In case of doubt, a grant is deemed a simple licence under the copyright statute; assignments and exclusive licences require written form with individual enumeration. The lawful user is entitled to the statutory minimum rights – backup copy, observation, interoperability decompilation within narrow limits – which cannot be contracted away entirely. In resale models, commercial agency and authorised dealer questions, including possible indemnity claims, must additionally be considered.

What should be considered in SaaS and cloud contracts?

SaaS and cloud models are continuing-obligation usage relationships; availability and control of data are at the centre: service levels with measurement method and credit regime, maintenance windows, support response times, data export formats and migration support at contract end, and provisions on sub-providers and data centre locations. Localisation requirements exist for regulated industries: in the banking and payments sector, the supervisory rules require certain systems and data to be kept in Turkey, and further sector-specific regimes as well as the circular on state information security place limits on cloud use. The data protection dimension – processing on behalf and international transfers under the KVKK – must always be negotiated alongside.

How are service levels, warranty and liability regulated?

The default statutory rules rarely fit IT scenarios; warranty and liability should therefore be ordered contractually: defect classes and response times, priority of cure, price reduction and termination rights, liability caps and the exclusion of indirect damages. The mandatory limits of Turkish law must be observed: exculpation from liability for intent and gross negligence is invalid, and in general terms and conditions surprising and disadvantageous clauses are subject to the content review of the Code of Obligations – one-sided templates of foreign providers do not always hold up before Turkish courts. Contractual penalties are permissible and common but can be judicially reduced if excessive.

How are data protection and data security addressed in the IT contract?

Where the provider processes personal data, it is a data processor for data protection purposes; the contract must regulate security measures, adherence to instructions, subcontractor approvals, notification and support duties in the event of data incidents, and deletion and return duties. Cross-border systems require KVKK-compliant safeguarding of the international transfer – in nearshoring projects in both directions. In addition, confidentiality clauses with contractual penalties and – depending on criticality – security audits, certification evidence and penetration tests belong in the contract; for operators of critical infrastructure, the duties of the Cybersecurity Law No. 7545 come on top.

How are choice of law, forum and arbitration clauses structured?

In international IT contracts the choice of law is in principle free; mandatory Turkish norms – data protection, general-terms review and regulatory localisation requirements, for example – nonetheless prevail. For disputes, arbitration clauses are attractive (ISTAC or ICC, for instance), since awards are enforceable in Turkey under the New York Convention and technical disputes may be better placed before specialised arbitrators; alternatively, the forum should be chosen deliberately with the enforcement perspective – recognition of foreign judgments in Turkey – in mind. The contract language and the authoritative version must be expressly determined; for contracts between Turkish parties, the rules on the mandatory use of the Turkish language in certain contracts must additionally be observed.

How do acceptance and documentation secure the evidence in the project?

IT disputes are rarely decided on questions of law and mostly on facts – and the facts are written by the project itself. The contract should therefore provide a formal acceptance procedure: test criteria and test data, acceptance periods with deemed-acceptance effect where no declaration is made, defect classes with clear allocation rules, and the separation of refusal of acceptance from notice of defects. During the term, steering committee minutes, documented change requests and the ticket history are the later evidentiary basis; in Turkish civil procedure the court-appointed expert plays a central role, which is why technical facts should be documented from the outset in an expert-ready manner – structured, versioned, traceable. Before escalation, judicial evidence preservation ("delil tespiti") can formally record the state of the system; tiered escalation clauses (project management – executive level – mediation – arbitration) filter out solvable conflicts before they blow up the project.

Which points belong in contracts with Turkish IT service providers?

• Rights clause: in writing, rights individually enumerated, rolling transfer per acceptance, chain of rights to freelancers secured
• Source code: delivery or escrow arrangement, documentation duties, open-source declaration
• Performance management: measurable SLAs, change management, key personnel, exit and migration plan
• Risk allocation: liability framework within the mandatory limits, contractual penalties, proof of insurance
• Compliance: KVKK processing on behalf, international transfers, sectoral localisation duties, confidentiality
• Dispute resolution: arbitration or forum clause with a view to enforcement, clear language and choice of law

What lessons can be drawn from failed projects?

The recurring patterns of failed IT projects can be defused contractually: a merely sketchy description of the services produces disputes over what was owed – remedied by prioritised requirement catalogues and a clean change regime. Lacking cooperation by the customer (test data, business unit feedback, decisions) becomes a gateway for the provider's delay defences unless cooperation duties with deadline consequences are agreed. The provider's insolvency or departure without escrow and documentation renders the half-finished system worthless. And the most frequent trap of all: the project continues for years "on call" while the contract reflects the state of the first offer – regular contract reviews upon scope changes keep paper and project in sync. Whoever manages these four points with discipline has largely neutralised the typical causes of dispute.

Why is functionality decisive in software contracts? An example from practice

How central the concept of functionality is in software development contracts is shown by the judgment of the Istanbul Regional Court of Appeal (53rd Civil Chamber, E. 2022/1748, K. 2026/714, judgment of 20 May 2026): in a contract for the development of a website and a mobile app, it is not only the volume of work performed that must be examined, but whether the resulting product achieves the success intended by the contract and has usable economic value; because the first-instance court had not assessed these points, the Court of Appeal set aside its judgment.

The decision demonstrates that a detailed and precise definition of functionality plays a key role in dispute resolution. Module-related "Definition of Done" specifications, acceptance tests, integration criteria and the written-form requirement for change requests concretise the parties' expectations and strengthen the evidence – making it possible to show clearly whether the customer received not merely a technical output but the intended benefit.

We advise our clients concretely at contract level on this point and regulate source code delivery, documentation duties, open-source declarations and acceptance processes in the contract in order to prevent problems arising from unclear functionality definitions. This disciplined approach secures the rights of both sides – customer and contractor alike –, lowers the risk of software project failure and makes it easier to settle disputes before they end up in court.

Conclusion

IT contracts with a Turkish dimension demand the combination of two worlds: the project-related contract mechanics – service description, acceptance, SLA, exit – and the Turkish specifics, above all the strict copyright form requirements for rights clauses, the review of general terms and the data protection and regulatory localisation rules.

Whoever orders these points at contract signing can use the advantages of the Turkish IT location – talent pool, cost level, time zone proximity – without unpleasant surprises. Foreign contract templates should always be localised and never deployed unchecked.

The IP/IT team at GEMS Schindhelm drafts and negotiates software development, licence, SaaS and outsourcing contracts with a Turkish dimension and supports companies in securing rights, compliance and dispute resolution in IT projects.