IT contracts · Software procurement · Business continuity

Your company is about to commit to software that will run a critical part of its business. The supplier offers source-code escrow. Before signing, establish what will be deposited, how you can obtain it and whether another team will have the rights and materials needed to keep the application running.

This guide is for foreign companies procuring software from Romanian developers, Romanian businesses licensing critical systems and suppliers negotiating a proportionate escrow commitment. Cross-border projects require a separate check of governing law, insolvency rules and the locations of the rights-holder, provider and deposited materials.

What does source-code escrow protect in a Romanian software transaction?

Escrow creates a contractual route to specified materials when an agreed release condition is established. It should connect custody of those materials to a usable continuity plan. The customer, supplier and independent escrow provider commonly have separate obligations concerning deposit, confidentiality, verification and release.

For procurement, ask what the company expects to achieve after release. Maintaining an installed application, recreating a hosted environment and replacing a cloud service are different tasks. A deposit suitable for the first task may be inadequate for the others. Providers such as Escode distinguish software escrow, SaaS escrow and technical verification; their service descriptions are commercial examples, rather than Romanian legal requirements.

Where Romanian law governs, the Romanian Civil Code supplies the general contractual framework. Articles 1169 and 1170 address contractual freedom within legal limits and good faith in negotiation, conclusion and performance. Where the arrangement qualifies as an unnamed contract, Article 1168 applies the general contract rules and, where insufficient, the rules for the closest analogous contract. Classification depends on the obligations, not the title. A code deposit alone does not create a security interest, insurance cover or an assignment of copyright.

The financial decision comes before failure. Management may accept a long licence term or a substantial implementation payment because it believes escrow reduces dependence on the supplier. That belief should be supported by a defined deposit schedule, a rights analysis and a recovery exercise. Ask the technical team what it could actually do with the materials, and ask counsel whether the contracts permit that use.

When should escrow be negotiated?

Negotiate it while the software scope, licence and payment schedule can still change. Raising escrow after deployment may leave the supplier with little incentive to provide additional rights or verification work without a new charge.

Useful decision points include signing a custom-development agreement, licensing a specialist application, renewing a system that has become operationally essential, or acquiring a business dependent on proprietary software. The company should identify the beneficiary precisely. A licence granted to the Romanian subsidiary may not cover its foreign parent, affiliated companies or a future purchaser. Align any rights for affiliates, successors and replacement contractors with authorised-user restrictions, assignment, change-of-control and confidentiality clauses. A share sale and an asset transfer can raise different questions.

Compare escrow with other available controls. Direct delivery of source code with adequate rights, customer-controlled repositories, tested backups, independent hosting, documented interfaces and contractual transition support can address different dependencies. The appropriate combination depends on the delivery model. A criticality assessment should record replacement lead time, available alternatives and what happens to orders, payroll or customer service while the application is unavailable.

Does receiving the source code give the customer ownership?

Physical access to code and copyright ownership are separate questions. The licence or assignment must define what the customer may do, including what a replacement contractor may do on its behalf.

Chapter IX of Romania’s Copyright Law no. 8/1996 governs computer programs. In the republished and amended text, Article 74 covers exclusive rights; Article 76(1)(b) restricts onward transfer of use rights unless otherwise agreed, and Article 76(2) separates those rights from copyright ownership. Articles 77 and 78 cover necessary lawful-use acts and specified backup, study and testing permissions.

The EU framework in Directive 2009/24/EC on the legal protection of computer programs also distinguishes restricted acts and specific exceptions. These limited exceptions do not promise delivery of a complete source-code package or resolve every third-party permission.

Negotiate express permissions for access, copying, compilation, deployment, maintenance and necessary modifications, including controlled access by a replacement contractor. Article 40(6) requires the assignor’s express consent for onward assignment by a non-exclusive assignee. Article 40(8) dispenses with that consent where the assignee is a legal person undergoing a transformation through one of the methods provided by law. Engaging a contractor is not necessarily a transfer of the licence; define whose behalf it acts on and its permitted activities. Identify beneficiary entities, duration and continuing rights. Our guide to software licence agreements for Romania explains the wider issues. The Romanian Copyright Office (ORDA) provides official copyright information.

Check the supplier’s chain of rights

Article 75 generally allocates economic rights in employee-created programs to the employer when created in the course of duties or under its instructions, unless otherwise agreed. Do not extend that employment rule automatically to freelancers or subcontractors. For assignments, Article 42 specifies required contractual content; Article 43 concerns written proof.

Request evidence of ownership or sufficient permissions for employee and contractor contributions, reused modules, documentation and third-party components. Review assigned rights, permitted uses, duration, territorial scope and remuneration where applicable. A warranty should be supported by the relevant records. Check whether the supplier can authorise deposit, disclosure and the customer’s planned recovery, including contractor access. Paying development invoices alone does not settle those questions.

What should the deposit contain?

The schedule should describe the materials needed for the agreed recovery task and identify the relevant production version. A generic promise to deposit “the source code” leaves important questions unanswered. Reconcile the production version, accepted deliverable and maintained release with the version covered by the licence, and define how they stay aligned.

Identify the application and its dependencies

Specify repositories, release identifiers, modules, build scripts, toolchain versions, configuration templates and documentation. Record third-party libraries and the permissions needed to obtain and use them. An essential commercial component may require a separate licence that the supplier cannot transfer through escrow. An open-source component may carry licence obligations that continue after release.

Capture operational know-how

Source files may omit the knowledge needed to operate them. Decide whether architecture documents, runbooks, deployment procedures, database migration instructions and maintenance manuals belong in the recovery package. Document work that currently depends on an individual developer’s memory. Test whether a replacement team can follow those instructions without undocumented assistance.

Separate recovery materials from live secrets and personal data

Ask the engineers to define a secure access and recovery process. Credentials, encryption keys and certificates may require protected custody, rotation or customer-controlled accounts rather than inclusion in an ordinary archive. Configuration examples should avoid unnecessary production secrets. Test environments should use appropriate test data. A usable package needs to reflect the actual security model without casually duplicating sensitive live information.

Require updates and evidence of receipt

Set the initial deposit deadline, update events, responsibility for uploads and proof of receipt. Link updates to production releases or other agreed milestones, and decide what happens when an update fails verification. If a supplier delivers a new version while the deposit still contains an earlier version, management needs a documented correction process. A custody receipt may evidence delivery without proving completeness, integrity, production-version conformity, compilation or sufficient legal rights. Establish what the contracted verification covers and what remains for legal or technical review.

What should verification prove before you rely on escrow?

Choose the test that matches the promised recovery and require a report of its limits. File existence, successful compilation and an independent deployment are different levels of assurance.

An inventory check may establish that specified files are present. A build test asks whether the deposit produces the agreed application. A recovery test asks whether an independent team can deploy and run it in the intended environment using the authorised materials. EscrowTech’s description of verification levels illustrates why the scope must be selected expressly; verification should not be assumed to follow automatically from storage.

Agree who supplies the environment, who performs the test, which functions must work and how discrepancies are reported. Require remediation and retesting where appropriate. If the exercise depended on undocumented help from the original developer, record that dependency. The customer should know whether the test demonstrated recovery without undocumented supplier assistance, and whether it ran in the intended recovery environment or only inside the supplier’s own environment.

Which release conditions and procedures need legal review?

A release trigger must be specific enough to establish, and its procedure must fit the company’s operational needs. Define the triggering conduct, required evidence, recipients, notice method, cure opportunity and the consequences of an objection.

Possible negotiated events include permanent cessation of a relevant business activity, a defined failure to provide maintenance, or specified insolvency developments. Their legal effect is case-dependent. A disputed support ticket, a late deposit update and total service abandonment should not be treated as equivalent without the agreed wording. Separate the right to request release from the provider’s authority to release.

Define the escrow provider’s decision role. Its service may involve custody, document checks or a contractual assessment of a release request; the agreement should identify which tasks it undertakes. Does it assess facts, follow an agreed certification process or wait for a court or arbitral decision after an objection? Who pays the dispute and verification costs? What temporary access or other relief can lawfully be sought while a dispute is pending? A long objection mechanism may defeat the intended continuity timetable even when the substantive trigger is well drafted.

Why insolvency needs separate analysis

Under Article 123(1) of Law no. 85/2014 on insolvency proceedings, ongoing contracts are maintained when proceedings open. Clauses providing for termination, loss of the benefit of the term, debtor-adverse modification or acceleration because proceedings open are treated as unwritten, subject to statutory exceptions.

To maximise the debtor’s estate, the judicial administrator or liquidator may exercise the statutory power to denounce a qualifying contract (denunțare) within the three-month limitation period from opening, provided it has not been fully or substantially performed by all parties. This insolvency mechanism differs from ordinary contractual termination. Under Article 123(1), a counterparty may send a notice requesting denunciation within those first three months. If the administrator or liquidator does not respond within 30 days of receipt, Article 123(1)(a) treats the contract as denounced when that period expires. Article 123(4) permits a damages action against the debtor before the insolvency judge, with payment governed by statutory rules.

Article 123(3) separately provides that the debtor loses the benefit of the term if, within the first three months, the counterparty notifies the judicial administrator of its intention concerning denunciation or early maturity. This is distinct from deemed denunciation following an unanswered notice. Review the notice’s wording, recipient and delivery date; neither effect by itself establishes an escrow release condition.

Assess the licence, maintenance agreement, deposit obligations and provider agreement separately. Identify which rights have already been granted and which depend on future performance. A claim for compensation may leave the customer needing another continuity solution. Neither every software agreement nor every released licence automatically has the same fate.

A trigger based on opening proceedings and one based on an actual maintenance failure require separate analyses. Do not assume that changing the trigger’s label avoids mandatory rules. Review its timing, evidence, contract structure and the debtor’s obligations. This discussion does not decide whether a particular release clause is valid.

Separate contractual governing law from insolvency law

For projects within their scope, the Rome I Regulation addresses the law applicable to contractual obligations. Article 7 of Regulation (EU) 2015/848 on insolvency proceedings generally points to the law of the state opening the proceedings for their effects, subject to the Regulation’s exceptions. Article 7(2)(e) expressly addresses effects on ongoing contracts to which the debtor is a party. A governing-law clause does not alone settle the insolvency analysis. Identify each party, proceeding and relevant rights before relying on a foreign provider’s template.

How should the software agreement and escrow terms fit together?

Use one consistent contract package with a clear order of precedence. A generous release clause is of limited value if the software licence separately prohibits the intended maintenance or ends the necessary rights at the critical moment.

Allocate ongoing fees, update work, verification, retesting, release and dispute costs. Check the provider’s liability limits and whether they are commercially acceptable for the custody task. Agree advance notice, cooperation, continued custody during transition and transfer to a replacement provider. Define treatment of unpaid fees and when materials may be returned or deleted. Someone should own these obligations after signature; a negotiated clause can lose practical value when nobody tracks deposits.

Review standard terms and liability exclusions

Where Romanian law applies, Article 1203 requires express written acceptance of the specified unusual standard terms. These include liability limitations benefiting their proposer, governing-law provisions, arbitration clauses and departures from court-jurisdiction rules. Check whether the terms are standard clauses included without negotiation, how they were incorporated and whether the required acceptance occurred. Article 1355(1) prohibits excluding or limiting liability for material damage caused intentionally or through gross negligence. Assess the actual wording, loss and applicable mandatory rules. A contractual cap is not automatically effective in every circumstance.

Define confidentiality, authorised recipients and permitted recovery uses for code and operational knowledge. Cover the replacement contractor’s security duties and what happens to copies after its engagement ends. Deposit and release should each have an access-control process.

Our commercial contract review checklist provides the wider framework for payment, liability, termination and dispute provisions.

Does a hosted application require more than source-code escrow?

Yes, where continued operation depends on hosting, data or services outside the code package. The recovery design should identify infrastructure, backups, deployment automation, integrations, domains and authorised access.

Ask who controls each cloud account and whether the customer can lawfully recreate the service elsewhere. Source code may compile successfully but still depend on a proprietary API, unavailable commercial library or supplier-managed database. Data export should be defined by format, frequency and completeness, and should be tested against the intended replacement system. Escrow should fit the broader transition plan rather than become the sole promise that the service will continue.

First identify whether the deposit or recovery service contains personal data at all. Logs, backups, test datasets and configuration files may contain it. Determine what is necessary and who decides the purposes and means of each processing operation.

Where the arrangement processes personal data, apply the General Data Protection Regulation to the actual roles and operations. Article 28 requirements matter where a party processes data on behalf of a controller; Article 32 addresses security. An escrow label alone does not determine the parties’ roles. Check any international transfer separately. The Romanian data protection authority (ANSPDCP) publishes official information, and our data processing agreement guide explains the contractual classification.

Apply data minimisation and storage limitation to the actual package. Agree retention, secure return or deletion, access controls and incident notification responsibilities. Check whether hosting, remote access or disclosure takes place outside the EEA and, where relevant, apply the GDPR rules governing international transfers. Article 28 applies to the actual controller-processor relationship, rather than automatically to every escrow provider.

Illustrative scenario: the code is released, but recovery stalls

A foreign-owned retailer is negotiating a specialist inventory application with a Romanian developer. The proposal includes escrow, and procurement initially treats that as sufficient continuity protection. The deposit schedule identifies source files but leaves the production version, commercial dependencies and deployment documentation unclear.

In the hypothetical failure scenario, the customer obtains the deposited materials under an established release route. Its replacement team then discovers that the package references a component requiring a separate licence and that the deployment process relied on undocumented supplier assistance. The company still has work to do before restoring the system.

Before signature, a coordinated review would ask the supplier to define the recovery package, identify third-party permissions and agree a suitable independent test. Counsel would align the release procedure and maintenance permissions with the software licence. Procurement would clarify fees, correction obligations and payment milestones; the technical team would document the environment and recovery dependencies.

The resulting work product can be a negotiated deposit schedule, a rights matrix, a verification plan and a list of unresolved conditions for management’s decision. This scenario is hypothetical. It does not describe an Atrium client or promise that escrow will prevent downtime.

What should the company send for a preliminary escrow review?

Send the complete proposed contract package and explain the commercial decision that is approaching. A short description should identify the software, the contracting entities, deployment model and signing or payment date.

• Collect the software agreement, licence, statement of work and maintenance schedule.
• Include the escrow agreement, beneficiary enrolment and provider terms.
• Identify the proposed deposit schedule, production version and update obligations.
• Provide the verification proposal or report and unresolved technical findings.
• Summarise contributor agreements, third-party components, rights and hosting dependencies.
• Describe the intended replacement-team access and recovery timetable.
• Record the relevant milestone payments, recurring charges and internal decision date.

Keep sensitive code, credentials and production data out of an initial public enquiry. Agree an appropriate transfer channel for the document review. The commercial lead, technical lead and legal contact should each identify what they can verify, including uncertainties that remain with the supplier.

How Atrium can assist with the transaction

A defined escrow and continuity review can examine the software licence, escrow terms and provider arrangement together, identify conflicting obligations, map release and dispute procedures and prepare proposed amendments. The mandate can cover negotiation of beneficiary rights, deposit obligations, confidentiality, third-party permissions, fees, liability and exit arrangements.

Technical verification remains work for appropriately qualified engineers or an agreed verification provider. Legal advice can frame what the test should evidence contractually, but cannot establish that code compiles or that a system is secure. Where insolvency or foreign-law issues are material, the scope should include the relevant specialist advice.

For an initial document review, the scope and fee are agreed in writing before work begins. A fixed or capped fee can be discussed once the document set, jurisdictions and requested deliverables are known. Negotiation, technical testing, provider charges and disputes should be scoped separately where they fall outside that engagement.

Review the continuity arrangement before signing

Tell Atrium which software your company will depend on, what the supplier has proposed and when you need to commit. A focused review can identify the rights, deposit requirements and unresolved contractual points that should inform that decision.

AI-assisted content.