Software, SaaS and
Cloud Contracts

The parties and the performances are determined for software sales, a term license, user-based SaaS, transaction-based fees, freemium, a platform, an API, white label, a managed service, IaaS, PaaS or a hybrid model. Whether revenue arises from licensing, subscription, usage, commission, maintenance, implementation or a data service is examined separately. Whether the customer is a corporate customer or a consumer, whether the service is provided in Türkiye or abroad, and whether it addresses a regulated sector are entered in the obligations matrix. The output is a legal business model map showing the contract set, the user terms, the data role, the intellectual property rights structure, the security annex and the regulatory requirements.

The request for proposal, technical offer, price offer, letter of intent, confidentiality agreement, trial environment and proof-of-concept stage are reviewed before the master contract. Binding and non-binding provisions are distinguished with regard to costs, exclusivity, intellectual property rights, use of data, trial results, confidentiality and the ending of the negotiations. How security, performance or compliance statements given by the supplier will be carried into the master contract is determined. A document hierarchy and an authorized-statement order are established so that pre-contract e-mails and presentations do not turn into a broad commitment.

Requirements analysis, technical architecture, design, coding, testing, installation, data migration, training, go-live, support and maintenance are converted into separate delivery units. Functional and non-functional requirements are written together with performance, security, accessibility, browser or device compatibility and integrations. The project schedule, dependencies, customer contributions, delay, acceptance, defect classes and payment milestones are linked to one another. The source code, repository history, installation scripts, data schema, administration panel and technical documentation are expressly included in the scope of delivery.

In projects that use an agile method, the whole scope may not be fixed at the outset; this does not mean that the criteria for delivery and payment should be left unclear. The product backlog, the sprint goal, the acceptance criteria, team capacity, daily or hourly records, the authority to prioritize and the definition of done are established in the contract. Fixed-fee elements are separated from time-and-materials work. The customer’s product owner role, the feedback period and the effect of a delayed decision on the schedule are determined. At the end of each sprint, the accessibility of the working version, the code repository and the records is verified regularly.

If the technology relationship covers more than one project and subscription, the master services agreement regulates the general legal terms, the order form the commercial parameters, and the statement of work the project performances. The parties, effective date, term, order of precedence and amendment procedure of each document are stated clearly. In the event of a conflict, which document prevails can be set topic by topic; this prevents a data protection or security annex from being rendered ineffective by a lower-ranking order form. The transfer of earlier orders to the new master agreement and the provisions to which terminated work remains subject are determined.

A statement of work should show together the deliverables, excluded work, customer dependencies, technical prerequisites, teams, schedule, price and acceptance criteria. A request for a new feature, integration, performance increase or legislative change should not be added to the project in practice without a change order. A form is created to show the effect of the request on scope, time, fees, resources, security and intellectual property rights. An expedited procedure for urgent security fixes is distinguished from ordinary product requests. Expansion of scope by unauthorized personnel through an e-mail or meeting note is prevented.

Setup, license, subscription, user, transaction, storage, data egress, support, development and third-party fees are shown separately. The source of the usage metric, the time zone, rounding, tax, currency, exchange rate, minimum commitment and overage price are determined. A route for objecting to the provider’s metering records and a retention period are established. Automatic renewal, notice of non-renewal, price index, unilateral increase and package change are regulated expressly. The move from a free trial to the paid period and the invoicing status of suspended accounts are not left unclear.

How the SaaS service is licensed, by user, account, device, transaction, data volume or feature package, is explained. The start of the subscription, the trial period, automatic renewal, usage overage, price change, adding and reducing users, the support plan and the terms of suspension are regulated. The limits on the use of customer data, service telemetry, statistics and derived data are determined. The provider’s authority to develop the product is balanced against the risk of removing an essential function or making an incompatible change. An order of precedence is established among the enterprise master agreement, the order form, the SLA, and the data processing and security annexes.

In infrastructure and platform services, the shared security and operational responsibilities of the provider and the customer are divided according to the service layer. The duties for account, identity, configuration, operating system, application, data, encryption key, backup and network security can be shown in a RACI table. The service region, data residency, capacity, auto-scaling, usage metering, connectivity, backup, recovery and support limits are written down. The cloud provider’s standard terms, the corporate annexes and the reseller contract are reviewed together. A route to administrator authority and access to the data is established in advance for the case of account closure or loss of access.

In system administration, security operations, network, database, application, help desk or DevOps services, the supplier’s authority for access and change is determined. The scope of duties, shifts, response, escalation, remote access, privileged accounts, logging, staff turnover and the use of subcontractors are regulated. The boundary between the customer’s instructions and the supplier’s professional duty of care is explained. The departure of critical personnel, knowledge transfer, service continuity, the return plan and the transfer of operations to the in-house team or a new supplier at the end of the contract are provided for.

A service level is not established merely by writing availability as a percentage. The measurement point, the calendar month, planned maintenance, force majeure, customer-caused outages, the internet backbone and third-party service exclusions are determined. Incident priorities, first response, workaround, permanent resolution, status updates and escalation times are defined separately. Verification of the provider’s own measurement and the delivery of reports are regulated. Whether service credits arise automatically or on request, whether they are the sole remedy, the right to terminate for repeated breach and the effect of a critical outage on broader liability are written expressly.

Acceptance is carried out with an objective test scenario, data set, environment, responsible person, time and result class. User acceptance testing, security testing, performance testing, integration and data accuracy can be separated from one another. The definitions of critical, major and minor defects, and the deficiencies for which acceptance is postponed, are determined. It should be clear whether silence, use or go-live will be treated as automatic acceptance. If there is conditional acceptance, the remaining work, the date of remedy and the effect on payment are tied to the protocol. At delivery, the source code, administrator authority, documentation and the ability to operate independently are also verified.

The transfer of source code or infrastructure to the customer is not a necessary element of every SaaS subscription. The delivery undertaken in the contract is distinguished from the license/access model. In custom development, the independent use and administration authority that was promised is not treated as proven by a screenshot alone.

Conformity of the software with the contractual criteria for function, documentation, security and performance is undertaken. Bug classes, the method of notification, reproduction information, workaround, correction and version delivery are determined. The scope of maintenance is clarified as to bug fixes, legislative updates, minor enhancements, version upgrades and third-party compatibility. Support hours, language, channel and escalation are written down. Reasonable notice, security patches and transition assistance are regulated for the retirement of an old version from support. The effect of customer modification or an unsupported environment on liability is addressed in a measured way.

Critical services, the recovery time objective and the acceptable data loss objective are determined on the basis of business impact. Backup frequency, a separate environment, encryption, restore testing and the storage region are written down. For the disaster recovery plan, not only its existence but also the test frequency, scenario, findings and follow-up of corrections are regulated. Dependence on a single cloud region, a single identity provider or a single critical employee is disclosed. For a major outage, communication, alternative processing, priority customers and the order of return are determined. If the customer has its own export or backup obligation, this is shown expressly.

It is determined whether the license is term-limited or perpetual, exclusive or non-exclusive, transferable or non-transferable, open or closed to sublicensing. Limits by user, device, company, affiliate, geography, server, transaction or capacity are written expressly. Backup copies, testing, disaster recovery, remote working, use by group companies and access by an outsourced service provider are regulated. Reverse engineering, interoperability, bug fixing and statutory exceptions are addressed with regard to mandatory provisions. License audits are tied to a procedure that is proportionate, consistent with information security and does not disrupt business continuity.

Under Law No. 5846, the assignment of economic rights in a computer program, or the grant of authority to use it, should be regulated in writing, with the rights shown separately. Code, libraries, methods, templates and tools that exist before the project are defined as “background rights”; custom developments that arise during the project are defined as a separate class. The customer’s payment of a price may not, by itself, mean that the source code or all economic rights have passed. The rights needed, including adaptation, reproduction, distribution and digital transmission, should be established consistently with the purpose of use. The provider’s right to use its general knowledge and experience is distinguished from customer-specific confidential information and code.

With respect to works not yet created, an undertaking to assign rights is distinguished from a disposition over a completed work within the framework of Articles 48–52 of Law No. 5846. Moral rights are not deemed to have been assigned en bloc as economic rights are; authorship and the authority to exercise economic rights are assessed separately.

That the code was written by an employee, a founder, a freelance developer, an agency, a subcontractor or a foreign team can change the outcome on ownership of rights. A program created by an employee within the scope of their duties and code written by an independent developer to order are not subject to the same assumption. Employment contracts, service contracts, founder agreements and subcontractor commitments are reviewed along the project chain. Economic rights use, confidentiality, open source, third-party code, delivery, collaboration and post-departure obligations are put in writing. The company’s code repository and accounts are not left tied to personal accounts.

A source code escrow arrangement can be established for use if the provider goes bankrupt, ceases operations, stops support, commits a serious SLA breach or fails to perform its contractual delivery obligation. The escrow includes not only the source code but also build instructions, the dependency list, the data schema, infrastructure code, installation scripts, the secure method for administrator keys and documentation. The frequency of deposits and the buildability of the escrow contents are tied to independent verification. The release event, the objection procedure, the use license and the confidentiality limit should be clear. Escrow does not replace regular backups and an exit plan.

The open source components in the code base, their versions, licenses and direct or transitive dependencies are inventoried. Permissive licenses, and copyleft provisions that may result in source code disclosure or distribution under the same license, are assessed according to the manner of use. Offering the software only as SaaS, distributing it, embedding it in a device or delivering it to a customer can produce different results. Notice, copyright notice, license text, source code offer and change disclosure obligations are added to the product process. A software bill of materials, automated scanning and a developer approval process are supported by the contract.

The contract chain for maps, payments, messaging, authentication, analytics, AI APIs, mobile stores, cloud marketplaces and other external services is reviewed. Quota, price, usage policy, data transfer, content restrictions, end of version support, audit, suspension and liability terms are matched with the commitment the main product gives to the customer. An unlimited performance promise is not given for an external service the provider does not control; however, a dependency, alternative, notice and transition plan is established. API keys and store accounts are not left in personal accounts; account ownership and access authority are documented.

Data the customer uploads to the system, user account data, transaction records, performance telemetry, anonymous statistics, feedback and data derived from them are defined separately. Instead of broad ownership-like wording, the authority for access, purpose of use, retention, aggregation, disclosure, model training, export and deletion is written expressly. A claim of anonymization is verified both legally and technically. The provider’s need to measure the service and ensure security does not automatically turn into an authority to use the data for another product or customer. When the contract ends, it is determined which data will be subject to return, deletion or retention for the statutory period.

The roles of data controller, data processor, joint controller under applicable foreign law, or independent controller in the service are determined for each processing activity. In the data processing contract, the subject matter, term, purpose, categories of data and data subjects, instructions, confidentiality, security, sub-processors, data subject requests, breach, audit, deletion and return provisions are established. Telemetry or fraud prevention carried out by the provider for its own purposes is assessed separately. Joint responsibility under Article 12 of the KVKK cannot be managed with a general provision such as “the KVKK will be complied with”; the technical and administrative measures need to be implemented and verified.

The cloud server, support team, sub-processor, remote access, disaster recovery copy and global administration panel are mapped as separate transfer channels. Which of the routes under Article 9 of the KVKK, adequacy, appropriate safeguards or incidental transfer, will be used is determined according to the specific flow. The process of selecting the standard contract according to the correct party type, completing its annexes and notifying the Authority within five business days from signature is managed. A data region commitment should not conceal support access or backup copies. If the GDPR applies, the EU transfer tool and supplementary measures are examined separately.

If the Board’s standard contract model is used, the text outside the optional fields is not changed; signature authority, the Turkish text, the annexes and the notification within five business days of completion of the signatures are followed up. A general data processing annex is not, by itself, treated as an appropriate safeguard for a transfer abroad.

The security annex covers identity and access management, multi-factor authentication, privileged accounts, encryption, key management, secure development, vulnerability scanning, penetration testing, patching, logging, backup, network segregation, personnel, physical security and supply chain controls. The controls are not left to a vague expression such as “industry standard”; the standard to be applied, the scope, the verification and the exception procedure are determined. An ISO certificate does not, by itself, prove service-specific security; the certificate scope and the control report are reviewed. The customer’s own security responsibilities are also shown in the shared responsibility table.

The concepts of incident, security incident, personal data breach, service outage and critical vulnerability are distinguished from one another. The provider’s time for first notice to the customer, the minimum content known, regular updates, technical investigation, mitigation, preservation of records and the root cause report are regulated. Because the statutory notification period may vary by sector and by incident, the contract establishes an early notification mechanism through which the customer can manage its own period. Public statements and communication with regulators are tied to an authority matrix. After the incident is resolved, corrective action, retesting and contractual consequences are addressed separately.

Who the sub-service provider is, which service it provides and where, which data it accesses and which critical function it supports are inventoried. The provider’s right to use subcontractors is regulated through prior notice, objection, equivalent obligations, data transfer, security, audit and termination terms. A change in a critical supplier can be treated as a material contract change. The main provider cannot remove its contractual liability for the acts of a sub-service provider with a general pass-through provision. Dependence on a single point in the chain and the time needed to substitute are entered in the business continuity plan.

The customer’s audit right is established in a proportionate way through layers of an information form, certificate, independent assurance report, remote review and, where necessary, an on-site audit. Frequency, notice, cost, confidentiality, other customers’ data and the time for corrective action are determined. In the event of a serious incident or a regulatory request, the ordinary limits can be relaxed. In sectors such as finance, health, telecommunications or the public sector, the regulator’s information and audit rights are carried into the supply contract. The audit right should give not only the ability to see documents but also the ability to follow the remediation and verification of findings.

The definition of confidential information is established so as to cover source code, architecture, security vulnerabilities, customer data, product roadmap, prices, business plans and access credentials, but not without limit. Exceptions are regulated for information that is lawfully known, independently developed, received from a lawful third-party source, or publicly available. Sharing is limited to persons who need it for their duties and to the extent needed. In the event of a court or authority request, a notice and limited disclosure procedure is established. At the end of the contract, the return and deletion obligation is determined together with the backup and statutory retention exception. Additional controls are applied to personnel who have access to the source code.

For an AI component, it is determined whether the party is the model provider, a person who offers, deploys or merely uses the system. Whether inputs will be used for model training or service development; the right to use outputs, the possibility of similar outputs, human review, records, limits of accuracy and prohibited use are explained. The source of the training data, its license, and its nature as personal data and trade secret are reviewed. The terms for general-purpose models are aligned with the main customer contract. If the EU Artificial Intelligence Act applies, transparency, role, technical record and supply chain information obligations are carried into the contract.

Vendor lock-in can arise from a proprietary data format, high data egress fees, a closed API, a license key, an administrator account, lack of documentation or a contractual obstacle to termination. Portable data, export frequency, a switching interface, assistance, time and fees are regulated at the outset. If the EU Data Act applies, the rules on switching between data processing services, pre-contract information, functional equivalence, data export and gradual switching are examined separately. The technical interoperability obligation is balanced against the protection of intellectual property rights and trade secrets. An exit rehearsal can be carried out during the contract term for critical systems.

The switching obligations under the EU Data Act have applied since September 12, 2025. Until January 12, 2027, a reduced charging regime limited to costs directly connected with switching and not exceeding cost, and thereafter the elimination of switching charges, are assessed separately. The scope and exceptions of these rules are not carried automatically into every contract within Türkiye.

For an application, digital content or subscription offered to an individual user, the rules on pre-contractual information, total price, payment obligation, the right of withdrawal and its exceptions, defective service, automatic renewal, termination and refund are reviewed. Where the withdrawal exception requires the consumer’s express consent and acknowledgment that the right will be lost, it is supported by the interface and a record. The move from a free trial to the paid period is not concealed. A long and unclear route for canceling a subscription is not established. Consumer terms are separated from the corporate customer contract; a choice of foreign law does not automatically remove the consumer’s mandatory protection.

Where a SaaS product is sold through a marketplace, a mobile store, a payment institution or a dealer, the roles are determined for the party to the contract, collection, refund, commission, tax, user support and account closure. The subscription and content rules of the app store are aligned with the main customer terms. The scope of payment data, the PCI obligation, chargeback and fraud processes are regulated. If the product hosts third-party sellers or user content, the obligations under e-commerce and internet law are examined in greater depth within the scope of the separate service page. Being a technical provider does not in every case remove the actual platform role.

The sector legislation of the institution receiving the technology service can directly affect the supplier’s contractual obligations. In banking, payments, capital markets, insurance, health, electronic communications, energy and public systems, the provisions on data residency, outsourcing, audit, incident reporting, business continuity and subcontractors are examined separately. In services to EU financial institutions, DORA’s information and communication technology third-party risk provisions and the contractual elements for critical functions are assessed. Even if the supplier does not take over the customer’s regulatory responsibility, it should provide the information, access and cooperation provisions that make the customer’s compliance possible.

For persons and entities that operate or provide services in cyberspace in Türkiye, the scope of Law No. 7545 on Cybersecurity and its obligations on provision of information, measures, oversight, products and services are examined. Provisions supporting Presidency letters, remediation of vulnerabilities, cooperation, records and oversight processes are added to the contract. If a product with digital elements is offered to the EU market, the scope of the Cyber Resilience Act, the role as manufacturer or other economic operator, and the secure product lifecycle are assessed. A contractual information flow is established for the specific vulnerability and serious incident reports that began to apply to manufacturers on September 11, 2026.

The general application date of the EU Cyber Resilience Act is December 11, 2027; the start of manufacturer reporting is September 11, 2026. The different timeline for supporters of open source software, and the distinction between remote data processing tied to a product and an independent cloud service, are examined separately. Not every SaaS provider is assessed under the same role.

Exclusivity, tying, license audit, non-solicitation of customers or personnel, most-favored customer terms, data access, API restrictions and obstacles to switching are examined from the standpoint of competition law. Legitimate intellectual property protection is distinguished from a provision that unnecessarily restricts the market or the customer’s switch to an alternative supplier. The unilateral terms of a strong platform or technology provider may be assessed in terms of dominant position and unfair commercial practice. In interoperability and data portability requests, security, trade secrets and the rights of third parties are protected. Cooperation agreements are established with governance that will not lead to the exchange of sensitive commercial information.

Direct damage, indirect damage, loss of profit, data loss, service outage, infringement of intellectual property rights, and confidentiality and security incidents are distinguished according to the business model of the contract. The general liability cap, and exceptions such as intellectual property rights, intent, gross negligence, confidentiality, personal data or bodily injury, are regulated with regard to mandatory law. In a third-party claim, notice, control of the defense, cooperation and settlement authority are determined. The protection the supplier can give because of a third-party component is examined separately. The scope, limits and continuation of professional liability and cyber risk insurance should be consistent with the contract.

Under Article 115 of the Turkish Code of Obligations, an advance agreement excluding liability for gross negligence is absolutely void. Provisions on profession, permit and auxiliary persons are examined separately. The review of general terms and conditions and the mandatory limits cannot be avoided by writing a high or low cap into the contract.

The authority to suspend in the event of payment delay, a security threat, unlawful use, license overage or a regulatory requirement is tied to different conditions. For a non-urgent breach, notice and a cure period are given; in a critical security incident, an immediate measure with a limited scope can be applied. If suspension can be limited to the account or function related to the breach, the whole service is not shut down. Access to customer data is not turned into a means of pressure in a payment dispute. The fees during the suspension period, data retention, support and reactivation terms are regulated expressly.

End of term, just cause, repeated SLA breach, legislative change, bankruptcy, change of control and facilitated termination options are distinguished. Before the contract ends, the exit plan, the responsible team, time, fee and technical format are determined. Customer data is delivered in an open, structured and usable format, with the necessary schema and explanations. Transition support to a new provider, parallel running and knowledge transfer are regulated. The deletion date, the backup cycle, statutory retention and confirmation of deletion are explained. The provider’s intellectual property rights are not confused with the customer’s access to its own data and business records.

The electronic formation of the contract, identification of the authorized user, the secure electronic signature, the checkbox, the order flow and record-keeping methods are reviewed. The legal effect of a secure electronic signature under Law No. 5070 and of other electronic approval methods is not treated as the same. Which version of the text was accepted, when and by whom should be shown by an unalterable record. Code repository history, the issue tracking system, support tickets, e-mails, test results, access logs and invoice records are classified with the possibility of a dispute in mind. The access and retention period of records containing personal data and secrets is determined separately.

In disputes over delivery, acceptance, defects, delay, payment, license, source code, data loss, service outage and intellectual property rights, the contract set and the actual technical position are examined together. A working screen is distinguished from a delivery that conforms to the contract and can be used independently. The code repository, administrator accounts, versions, tests, infrastructure, API, database, invoices and correspondence are preserved in accordance with procedure. Where necessary, the preservation of evidence, an interim injunction, an expert examination, discussion of the evidence in court, and an arbitration or litigation strategy are prepared. Uncontrolled intervention that would damage the system or expose third-party data is avoided.

The court with subject-matter jurisdiction is determined according to the contractual claim, the intellectual property right, the consumer transaction and the nature of the parties. For commercial monetary claims, mediation as a condition precedent to litigation and the conditions for interim legal protection are examined. A negotiation process within the contract is not assumed to have stopped the statutory time limits.

In an investment or company transfer, software ownership, employee and independent developer contracts, open source, customer licenses, cloud accounts, security incidents, the KVKK, transfers abroad, material suppliers, SLA liabilities and regulatory scope are examined. In the contracts on which revenue depends, the provisions on change of control, prohibition of assignment, termination, discounts and unlimited liability are identified. That the code is in fact held by the company and that the economic rights have passed to the company are verified separately. The findings are turned into transaction documents, representations and warranties, specific indemnities, a condition to closing, price adjustment and a post-closing corrective plan.

In a contract with a foreign provider or customer, the choice of law, jurisdiction or arbitration, language, tax, payment, currency, sanctions, export controls, intellectual property rights, data transfer and enforcement of decisions are assessed together. An order of precedence is established between the master contract and the local country annexes. English, German and Russian texts are subject to a consistency check against the Turkish legal framework; a word-for-word translation alone is not relied on. The duties of attorneys in more than one country, the technical review team and the regulatory advisor are coordinated in a single file plan. Pre-dispute notice, escalation and executive meeting periods are regulated so as not to prejudice statutory filing time limits.