Define specification, testing and acceptance
A development or integration brief needs outputs, interfaces, environments and test criteria. Distinguish configuration from new code and customer requirements from optional enhancements. Milestones should reflect the actual technical sequence, including migration, user testing and launch.
Acceptance should identify defects, review periods and the process for correction. Changes to requirements affect price and timing and need authorised variations. In SaaS, onboarding and service performance may matter more than one final acceptance event. The document should follow the architecture and delivery model, not a single generic IT label. For a development project, describe what the customer must be able to do at acceptance and which files, licences and access are needed afterwards. For SaaS, focus on permitted use, data export, renewal and what happens if service stops. A services agreement can supply the commercial framework, but technical schedules must still define the system. Review public data-use wording separately through website terms and privacy.
Fees and cost components
Professional work, authority fees and third-party charges should be identified separately in the written quote.
Technology contract scope
Complexity depends on model, systems, schedules and negotiations. A licence review differs from drafting a full development, data and service-level pack.
Technical and privacy input
Security assessment, component licensing, data mapping and regulated-sector requirements may add work. Legal drafting should identify where specialist verification is needed.
Implementation dependencies
Software, cloud, testing and migration charges are commercial costs distinct from legal advice. Translation, cross-border or additional vendor negotiation may also require separate scope.
Documents and information to prepare
The receiving authority and adviser confirm the final requirements for your matter.
Architecture and technical brief
Provide specifications, interfaces, hosting, migration and acceptance criteria. Explain business-critical functions and what the customer must supply for successful delivery.
Commercial document set
Send proposal, licence terms, statements of work, support policies and pricing. Include cloud or platform terms incorporated into the vendor’s offer.
Rights and component information
Identify existing code, open-source libraries, third-party licences and ownership of final outputs. Provide source-access and continuity requirements rather than assuming ownership is universal.
Data and resilience plan
List personal data, access, locations, subcontractors, backup and incident procedures. Explain export, recovery and replacement-supplier needs to inform privacy and exit terms.
Check code ownership and third-party licences
Separate ownership of bespoke work from licences to background tools, libraries, platforms and third-party software. Determine whether the customer needs source code, deployment rights, modification or continued use after termination. Payment does not necessarily acquire every underlying component.
Open-source terms and licensed assets require appropriate technical and legal review. A supplier should identify material restrictions and ownership exceptions rather than promise entirely original code without evidence. If escrow or continuity rights are considered, define what is deposited, when it is updated and the conditions for access.
Agree security, data roles and service continuity
Map hosting, personal data, support access, subcontractors and international flows. Applicable federal, DIFC or ADGM data rules need separate assessment. Contractual security requirements should identify responsibilities, reporting and incident response without claiming absolute protection against every breach.
Service levels need a measurement method, exclusions and a practical remedy. Consider backups, recovery, planned maintenance and dependencies on cloud platforms. Allocate responsibility for updates and vulnerabilities. A service credit may address one performance metric but does not automatically solve data loss or a business-critical outage.
Plan export, source access and supplier exit
Plan export of data, credentials, documentation and configurations. Identify formats and time needed for another provider to take over. A customer can own records yet remain operationally locked in if export or access is not practical.
Termination should address ongoing subscriptions, third-party licences, transition assistance and retained data. Avoid relying on a promise to deliver all source code where the product is a licensed platform. Review the agreement when the system expands or integrates new vendors; the risk allocation may need to change with the architecture.
The detailed process
- 01
Identify the technology model
Separate licence, development, integration and ongoing support. Map the technical brief and document set so the legal review addresses the system actually being delivered.
- 02
Allocate delivery and rights
Coordinate scope, acceptance, changes, IP and licence permissions. Confirm which outputs and access the customer needs and what the supplier can lawfully provide.
- 03
Review security and continuity
Assess data roles, service levels, recovery and vendor dependencies. Align obligations with technical evidence and identify specialist privacy or security work.
- 04
Prepare implementation and exit
Keep the agreed schedules, approvals and versions together. Assign performance reporting and renewal dates and verify that export and handover can be carried out in practice.
Read further context
Further context for this guide
The review should involve the technical and business owners. They can explain what will be delivered, how it is tested, which data is handled and what happens if the vendor stops supporting the system. Legal terms can then allocate those realities rather than promise generic uptime or ownership that the technology cannot provide.
See the illustrated process
Information technology assessment path
Identify the technology model
Separate licence, development, integration and ongoing support. Map the technical brief and document set so the legal review addresses the system actually being delivered.
Allocate delivery and rights
Coordinate scope, acceptance, changes, IP and licence permissions. Confirm which outputs and access the customer needs and what the supplier can lawfully provide.
Review security and continuity
Assess data roles, service levels, recovery and vendor dependencies. Align obligations with technical evidence and identify specialist privacy or security work.
Prepare implementation and exit
Keep the agreed schedules, approvals and versions together. Assign performance reporting and renewal dates and verify that export and handover can be carried out in practice.
This is an illustrative sequence. The actual route, formalities and responsible parties depend on your facts and the receiving authority.
View the options and comparison table
Use the comparison and preparation tools
Compare: Identify the appropriate workstream
Connect the business decision with its legal workstream. Select a comparison item below to inspect the distinctions and conditions described in this guide.
Explore the questions to ask; selection does not confirm eligibility or recommend an outcome.
Licensed software
- Focus
- Licence review
- Distinction
- Usage limits, renewals and third-party rights.
The appropriate workstream depends on the actual business model, parties and jurisdiction.
Bespoke development
- Focus
- Development and acceptance terms
- Distinction
- Scope, source rights, testing and changes.
The appropriate workstream depends on the actual business model, parties and jurisdiction.
Hosted or managed technology
- Focus
- SaaS or managed-service terms
- Distinction
- Security, service levels, data and exit continuity.
The appropriate workstream depends on the actual business model, parties and jurisdiction.
Information technology: process and supporting evidence
The process and the record checklist are separate parts of preparation. Mark only the records you have gathered; the indicator reflects your selections and is not an assessment of legal readiness.
Decisions, approvals and implementation
Identify the technology model
Separate licence, development, integration and ongoing support. Map the technical brief and document set so the legal review addresses the system actually being delivered.
Allocate delivery and rights
Coordinate scope, acceptance, changes, IP and licence permissions. Confirm which outputs and access the customer needs and what the supplier can lawfully provide.
Review security and continuity
Assess data roles, service levels, recovery and vendor dependencies. Align obligations with technical evidence and identify specialist privacy or security work.
Prepare implementation and exit
Keep the agreed schedules, approvals and versions together. Assign performance reporting and renewal dates and verify that export and handover can be carried out in practice.
Commercial, ownership and operational evidence
0 of 4 listed records marked as gathered.
Selections stay on this page and are not saved or sent.
What to gather
Provide specifications, interfaces, hosting, migration and acceptance criteria. Explain business-critical functions and what the customer must supply for successful delivery.
What to gather
Send proposal, licence terms, statements of work, support policies and pricing. Include cloud or platform terms incorporated into the vendor’s offer.
What to gather
Identify existing code, open-source libraries, third-party licences and ownership of final outputs. Provide source-access and continuity requirements rather than assuming ownership is universal.
What to gather
List personal data, access, locations, subcontractors, backup and incident procedures. Explain export, recovery and replacement-supplier needs to inform privacy and exit terms.
The adviser and receiving authority confirm the final requirements, validity and acceptance of the evidence.
Points to check before proceeding
Ownership promised without component review
A system may contain third-party and open-source parts. Define usable rights and exceptions rather than equating payment with unrestricted ownership.
Uptime stated without measurement
A percentage is unclear without period, method and exclusions. Align service metrics, reports and remedies with the technology and business impact.
Exit data exists but cannot be used
A nominal export right may not provide a workable replacement system. Assess format, documentation, credentials and transition support before the vendor relationship ends.
Your questions, answered
Do we own software commissioned from a developer?
Ownership and use depend on the agreement, applicable IP rules and third-party components. Specify bespoke outputs, background tools, licences and source access rather than assume payment transfers everything.
Is SaaS the same as buying software?
Usually the customer receives access under ongoing service and licence terms. Hosting, renewals, data and exit are central; the customer may not acquire the platform or source code.
Should every contract include source-code escrow?
It depends on the system and continuity risk. Escrow needs defined deposits, updates and release triggers and may be unsuitable for some hosted or third-party platforms.
Does a service credit cover all outage loss?
Not automatically. Its purpose and interaction with other rights need review under the agreement and law. Data loss, security and business interruption may require separate treatment.
Can the supplier use subcontractors?
Define permissions and responsibility, especially where subcontractors access confidential information or personal data. Map locations and support roles and assess relevant processing arrangements.
What is needed for a workable exit?
Data formats, credentials, documentation, licences and transition cooperation should be identified. Verify that the technical process supports the contractual promise before a critical dependency develops.
Official sources and legal framework
- UAE Civil Transactions Law — Federal Decree-Law 25/2025 ↗
Current federal civil-law framework; commencement 1 June 2026 and repeal of 5/1985. Specific interpretation depends on the transaction and its dates.
- TDRA — electronic transactions and trust services guidance ↗
Federal Decree-Law 46/2021 and its 28/2023 Executive Regulation; electronic execution and qualified trust services require appropriate verification.
- UAE Government — data protection laws ↗
Federal personal-data framework 45/2021 alongside separate financial-free-zone regimes and scope exclusions.
- DIFC — legal database ↗
DIFC has its own contract, companies, employment, IP and data laws; check enacted amendments rather than consultations.
- ADGM — legal framework ↗
ADGM has its own civil/commercial framework based on English common law.
- Ministry of Economy and Tourism — current laws index ↗
Current companies, competition, commercial, agency, consumer and IP framework, including 2026 regulations; verify relevant enacted instruments for a particular matter.
- Federal Personal Data Protection Law — Decree-Law 45/2021 ↗
Federal controller/processor scope and exclusions; a software contract or privacy notice does not by itself establish compliance with processing obligations.
Information reviewed 12 October 2026. These are general-information guides. Confirm current requirements with the applicable authority and a licensed adviser before acting.