Foreign investment • AI governance • Romania

AI due diligence in Romania asks whether a target company’s AI use, data, contracts and public claims support the investment case. It is not a technical demonstration of a model and it is not a generic AI policy review. For a buyer, investor or lender, the question is whether the target has identified the systems it uses, can lawfully operate them, owns or can use the assets it relies on, and has a credible plan for the risks that will remain after closing.

What is AI due diligence in a Romanian transaction?

AI due diligence is a transaction-focused legal and commercial review. It identifies whether the target’s use of AI creates liabilities, restrictions, missing rights or implementation costs that could affect price, risk allocation or post-closing operations.

For a Romanian target, the review should cover the target’s Romanian operations and any AI outputs used in the European Union. The EU AI Act is directly applicable across the EU and operates alongside the GDPR where personal data is processed. A seller’s statement that it uses only a third-party AI tool does not end the inquiry: the target may still be a deployer, customer, controller, employer or regulated business with its own duties.

This guide has a different purpose from our analysis of AI vendor contracts in Romania, which focuses on the agreement with a supplier, and from DPIA vs FRIA in Romania, which focuses on assessment triggers for a deployment. Here, the investor is deciding what must be verified before, at and after a deal.

Start with the target’s actual AI footprint

Do not begin with a broad question such as “Does the company use AI?” Ask what system or model is used, for which decision, with which data, by whom, and whether the target sells, deploys, develops, fine-tunes or merely accesses the tool.

A useful data-room request separates customer-facing products from internal tools. It should identify models, APIs, software providers, hosting and cloud dependencies, integrations, datasets, prompts or knowledge bases, material outputs, users and the decisions influenced by each use case. The inventory should also record planned products or features that have not yet launched but are material to the investment thesis.

Which legal and commercial issues should an investor test?

Click or tap a row to highlight the diligence takeaway. On a small screen, swipe the table sideways.

The European Commission describes the AI Act as a risk-based framework for developers and deployers. It identifies employment, credit scoring and access to essential services among the examples that may be high-risk. See the Commission’s AI Act overview and application timetable.

AI Act review: classify before you value the risk

Do not treat “AI Act compliant” as a sufficient diligence answer. Contractual, sector-specific, data-protection and AI Act obligations must be assessed separately. The investor should identify the system, its intended purpose, the target’s role and the rules that apply now or later. The relevant date can affect both risk allocation and integration planning.

The AI Act’s prohibitions, AI literacy obligations, governance rules, GPAI-model obligations and transparency rules have different application dates from the rules for high-risk systems. The Commission states that Annex III high-risk use cases, including employment and credit-scoring examples, are scheduled to apply from 2 December 2027, while high-risk systems embedded in regulated products have a later date of 2 August 2028. A diligence report should distinguish obligations already applicable from future obligations that could require a funded implementation plan. At the time of publication, the applicable AI Act timetable should be verified against the latest EU legislation and implementation guidance, including the official AI Act Service Desk timeline.

The analysis should also ask whether the target is developing an AI system, placing it on the market, deploying it in its own business, importing it, distributing it or using a third-party service. These labels are not interchangeable with GDPR controller and processor roles. For the contract-facing part of that review, see AI Vendor Contracts in Romania.

GDPR and data review: look beyond the privacy policy

The decisive question is what happens to personal data at each stage of the AI lifecycle. A target may process personal data in training, testing, deployment, monitoring, logs, prompts, support and human review, even where the product is marketed as automated or anonymised.

The review should map the data categories, purposes, retention, recipients, access, transfer mechanisms and contractual roles. Where the use involves profiling, recruitment, credit, insurance, pricing or decisions that may significantly affect individuals, check the actual decision flow and safeguards rather than relying on a generic human-review statement. Article 35 GDPR requires a DPIA where processing is likely to result in a high risk to the rights and freedoms of natural persons; Article 22 has separate rules for certain solely automated decisions.

The European Data Protection Board has also confirmed that the anonymity of an AI model trained with personal data must be assessed case by case. That matters for a target relying on a statement that a model, dataset or output is anonymous. Read EDPB Opinion 28/2024. For the broader framework, see our guide to GDPR compliance when using AI in Romania.

Data, intellectual property and contract rights

AI value is often dependent on rights that sit outside the target’s own code. The investor should trace the legal basis for using data, third-party models, cloud infrastructure, open-source components, output and confidential information.

Review the complete contract suite, not only the signed master agreement. Order forms, online terms, acceptable-use policies, data-processing agreements, security schedules, open-source notices and API terms can all affect the target’s rights. In particular, check whether a provider can use customer or target data for model training, whether the provider can change the model or service unilaterally, and whether the target can export its data and configurations on exit.

Ownership language for AI-generated output should be read carefully. A contractual promise may create a licence or allocation between the parties, but it does not necessarily guarantee exclusivity or copyright protection in every output. The copyright status of AI-generated content may vary depending on the level of human creative input and the applicable jurisdiction. The review should identify the use the target needs to make of the output and whether third-party rights, human authorship requirements, confidentiality or contractual restrictions could limit that use.

What should the investor request in the data room?

1. Request a current AI inventory. Include internal tools, customer-facing products, models, APIs, plugins, fine-tuning, integrations and material planned features.
2. Obtain a use-case map. Record intended purpose, users, affected people, decisions, data inputs, outputs, human review and country of deployment.
3. Collect AI governance records. Ask for role assessments, policies, training records, system documentation, risk logs, testing, monitoring and incident procedures.
4. Review AI Act screening. Identify prohibited practices, potential high-risk systems, transparency obligations, GPAI dependencies and the applicable timetable.
5. Map personal-data processing. Review privacy notices, legal bases, Article 22 analysis, DPIAs, processor arrangements, security controls and transfers.
6. Trace data rights. Check source, licence, consent or other permission for data used in development, testing, fine-tuning and ongoing service delivery.
7. Review the contract stack. Read supplier, customer, cloud, API, DPA, security, outsourcing and change-control documents together.
8. Confirm IP and open-source position. Request code provenance, licences, notices, ownership assignments, third-party claims and output-use restrictions.
9. Test material statements. Compare product marketing, investor materials and customer commitments against the available technical and legal evidence.
10. Assign the deal response. Separate issues requiring price, warranty, indemnity, condition, remediation, disclosure or post-closing integration action.

How should findings affect the transaction documents?

Translate each material finding into an owner, timing and remedy. A diligence report is useful only if the SPA, investment agreement, disclosure process and integration plan reflect the issues that have been identified.

The appropriate response will depend on the transaction structure and the seller’s ability to remediate. A buyer may need targeted warranties concerning data rights, AI-related regulatory compliance, ownership, contract compliance, absence of claims or material incidents. Confirmed gaps may justify a specific indemnity, a pre-closing remediation covenant, a post-closing plan, a condition or a tailored disclosure. The drafting should not assume that a general compliance warranty captures the actual issue.

Post-closing planning is equally important where the buyer will integrate systems, move data, introduce a new group policy, change suppliers or expand the target’s use case. These changes can alter the GDPR and AI Act analysis. If an assessment is required, the timing should be addressed before the relevant processing or deployment begins. Our DPIA vs FRIA guide explains why those two assessment routes must be screened separately.

When does a separate specialist review become necessary?

A focused AI legal review should be coordinated with corporate, technical, information-security, employment and commercial due diligence when the target develops AI products, relies on proprietary datasets, makes regulated-sector decisions, uses AI in recruitment or credit processes, processes sensitive personal data, markets compliance claims, or has important dependencies on a small number of providers. The workstreams should share the same factual inventory, but each should retain its own legal questions and conclusions.

How Atrium Romanian Lawyers can assist

Atrium Romanian Lawyers can coordinate the legal workstream for AI-related due diligence in a Romanian investment, acquisition or internal reorganisation. The review can cover AI Act role and use-case screening, GDPR and data-contract questions, supplier and customer terms, intellectual property, employment and operational governance, and the translation of findings into transaction documents or an integration plan.

AI governance • Romania • Assessment decisions

DPIA vs FRIA in Romania is a question of two different legal tests. A data protection impact assessment (DPIA) addresses risks arising from personal-data processing under the GDPR. A fundamental rights impact assessment (FRIA) under the AI Act applies to specified deployers of certain high-risk AI systems. Your project may require one, both, or neither mandatory assessment.

When do these obligations apply?

The GDPR assessment requirements already apply. Under the AI Act’s consolidated timetable, Chapter III Sections 1–3, including Article 27, apply to Annex III high-risk systems from 2 December 2027. The corresponding date for Article 6(1)/Annex I product systems is 2 August 2028; that does not extend Article 27 to every product system.

Article 111 contains separate transition provisions for existing systems. A project review should record when the system was placed on the market or put into service and whether subsequent design changes affect its treatment. The future FRIA timetable does not postpone GDPR duties. Source: consolidated AI Act, Articles 111 and 113.

DPIA vs FRIA: the differences that change your project

Both assessments examine potential harm to people. A DPIA is not limited to confidentiality or cybersecurity: it also examines other rights and freedoms affected by personal-data processing. FRIA addresses the impact of the specified AI deployment on fundamental rights.

Click or tap a row to reveal its practical takeaway. Keyboard users: Tab to a green label and press Enter or Space. Swipe the table sideways on a small screen.

GDPR Articles 28, 35–36 and 39; AI Act Article 27.

When does an AI project need a DPIA?

AI use alone does not automatically trigger a DPIA. The controller must assess whether the nature, scope, context and purposes of the processing make a high risk to people likely. Article 35 expressly recognises the relevance of new technologies.

The GDPR identifies particular situations, including systematic and extensive automated evaluation underpinning decisions with legal or similarly significant effects, large-scale processing of special-category or criminal-offence data, and large-scale systematic monitoring of publicly accessible areas. Applicable supervisory-authority lists must also be checked.

For a Romanian deployment, the file should therefore address the applicable requirements and guidance of the Romanian data protection authority, ANSPDCP, alongside Article 35. Record the reasons for a negative screening conclusion too. A supplier’s description of a product as “low risk” is not an assessment of your processing.

Where required, the DPIA must describe the processing and purposes, assess necessity and proportionality, evaluate risks to individuals and specify safeguards. This is a substantive project assessment, not simply a signed template. Source: GDPR Article 35.

For the broader data-protection framework, see our guide to GDPR compliance when using AI in Romania.

Who needs a FRIA under the AI Act?

The Article 27 obligation does not cover every business using high-risk AI. It concerns Article 6(2) high-risk systems and specified categories of deployer, with an exclusion for the critical-infrastructure area in Annex III point 2.

• Bodies governed by public law deploying qualifying systems.
• Private entities providing public services deploying qualifying systems. This status requires analysis; it is not synonymous with every company selling services to the public.
• Deployers of qualifying creditworthiness or credit-scoring systems for natural persons under Annex III point 5(b), which excludes systems used to detect financial fraud.
• Deployers of qualifying life and health insurance risk-assessment or pricing systems for natural persons under Annex III point 5(c).

Classification under Article 6 must be checked first, including the conditions of any applicable exception. The exact intended purpose matters. A financial-sector tool is not automatically a creditworthiness system, and a medical product is not automatically within the Article 27 FRIA route. Source: AI Act Articles 6 and 27 and Annex III.

Explore four deployment scenarios

These hypothetical examples explain the screening logic. They assume the stated facts and do not replace an assessment of the actual system, applicable dates or transition rules.

Can one assessment document cover DPIA and FRIA?

A coordinated file can reduce duplicated work, provided each legal requirement remains identifiable. The consolidated Article 27(4) expressly allows relevant DPIA sections to be cross-referenced or incorporated into FRIA where they already meet the corresponding obligations.

Start with a shared description of the system, purposes, data flows, affected people and safeguards. Then keep a requirement map showing which sections satisfy GDPR Article 35 and which satisfy AI Act Article 27. Identify gaps rather than renaming a DPIA “FRIA”. Source: AI Act Article 27(4)–(5).

As a practical drafting approach, include a separate deployment chapter addressing who may be affected beyond the immediate users, how mistakes influence access to opportunities or services, who can intervene, and how complaints lead to corrective action. Avoid treating GDPR as only a privacy checklist: the DPIA itself must consider risks to rights and freedoms.

What the FRIA needs to address

Article 27 requires the deployment process and intended use, duration and frequency, affected people and groups, specific risks of harm, implementation of human oversight, and measures if risks materialise, including governance and complaint mechanisms. Reusing a supplier assessment in similar cases is permitted, but the deployer must check its fit and update changed or outdated elements. Source: AI Act Article 27(1)–(2).

Who prepares, reviews and owns the decision?

The controller remains responsible for the DPIA; the covered deployer remains responsible for FRIA. A consultant, DPO or supplier can contribute without taking over the organisation’s statutory role.

For the DPIA, seek the designated DPO’s advice and preserve their independent advisory and monitoring function. Obtain relevant processor assistance. For the deployment review, involve the business owner, technical team and people responsible for oversight and complaints. A useful internal decision records outstanding conditions, the person accountable for each safeguard and the circumstances requiring a fresh review. Source: GDPR Articles 28(3)(f), 35(2) and 39; AI Act Article 27.

Contractual cooperation should cover the evidence you need to assess the deployment. Our AI vendor contracts guide addresses information rights, changes and supplier responsibilities.

Must the assessment be sent to an authority?

A DPIA and a FRIA follow different authority procedures. Under GDPR Article 36, prior consultation is required where high residual risk remains that cannot be sufficiently mitigated. There is no general GDPR obligation to submit every DPIA for approval.

Article 27(3) provides for notification of FRIA results to the market surveillance authority using the relevant template, subject to the Article 46(1) exception. That notification is not the GDPR prior-consultation procedure and should not be described as automatic permission to deploy. Confirm the competent authority and operational submission arrangements for the specific deployment. GDPR Article 36; AI Act Article 27(3).

A practical assessment file before deployment

1. Define the use case. Identify the system, version, intended purpose, users, affected people and decisions it informs.
2. Map roles separately. Record GDPR controller/processor roles and the relevant AI Act roles.
3. Screen the legal route. Check prohibited practices, AI classification, DPIA triggers and Article 27 deployer coverage.
4. Record timing. Distinguish existing GDPR duties from future AI Act requirements and applicable transition provisions.
5. Collect evidence. Obtain data-flow information, supplier instructions, meaningful performance limitations, oversight arrangements and relevant testing.
6. Assess harms and safeguards. Describe how the actual deployment may affect people and how controls reduce those risks.
7. Map shared sections. Make each DPIA and FRIA requirement traceable, retaining any necessary separate analysis.
8. Resolve escalation. Identify prior consultation, notification, unresolved risks and conditions preventing launch.
9. Assign review triggers. Consider changes in purpose, model, data, affected groups or decision authority, and evidence from incidents or complaints.

How Atrium Romanian Lawyers Assisted an International Manufacturing Group

Anonymised client matter. The description below omits identifying information and focuses on the legal work performed.

A focused consultation can clarify which assessment route applies and what your team needs before making deployment commitments.

An AI vendor contract should do more than grant access to a platform. It should identify the system and intended use, allocate regulatory roles, control the use of business and personal data, preserve evidence, set performance and security obligations, and provide a workable exit if the supplier, model or law changes.

This guide is intended for Romanian companies, foreign groups operating in Romania, technology suppliers, procurement teams and businesses implementing generative or other AI tools. It focuses on contract structure. For the wider regulatory framework, read our EU AI Act guide for foreign companies.

Why does an AI vendor contract need a separate review?

AI services can change after signature. A supplier may replace a model, add a subprocessor, change data-retention settings, modify safety controls or alter the geographic delivery chain. Outputs may also be probabilistic rather than repeatable. These features create risks that are not fully addressed by ordinary clauses on software access, uptime and confidentiality.

The EU AI Act allocates obligations according to the system, risk category and operator role. The GDPR applies in parallel where personal data is processed. The contract cannot transfer away statutory responsibility, but it can secure the information, instructions, evidence and cooperation needed for each party to perform its own obligations.

Start with the AI use, not the vendor’s template

Before redlining the agreement, the customer should record what the system will do, whose decisions it will influence, what data enters the system, who receives the output and whether the tool will be integrated into employment, credit, insurance, education, essential services, biometric or other sensitive workflows. The same product can create different legal exposure when deployed for a different purpose.

AI vendor due diligence before contract negotiation

A customer cannot negotiate intelligently without basic information about the service. The due-diligence request should be proportionate to the use and risk, but it commonly covers:

• the legal entity supplying the service and the entities supporting it;
• the model or models used, hosting locations and material third-party dependencies;
• the intended purpose, known limitations and prohibited uses;
• data sources, retention rules and whether customer data is used for training or improvement;
• security controls, incident history, business continuity and disaster recovery;
• testing, accuracy or performance information relevant to the deployment;
• subcontractors, subprocessors and international data transfers; and
• the supplier’s process for regulatory requests, complaints, audit evidence and system changes.

For high-risk deployments, the customer may require contractual access to sufficient documentation, instructions, logs and compliance information to enable it to perform its own obligations under the AI Act. The scope of access should reflect the parties’ respective roles and may need to protect the supplier’s trade secrets and intellectual-property rights. The European Commission’s AI Act information page and its AI Act Service Desk are useful starting points, but the contract must still reflect the particular system and transaction.

What if the service relies on a general-purpose AI model?

Where the service relies on a general-purpose AI model, the customer should also consider whether contractual information rights are needed regarding the model provider, model updates, transparency documentation and downstream restrictions affecting the deployment. These provisions should be tailored to the customer’s position in the AI value chain and should not imply that the customer is entitled to the provider’s complete technical documentation.

What clauses should an AI vendor agreement contain?

1. Define the system, version and intended purpose

The agreement should identify what is actually being supplied. “AI services” is rarely sufficient. The specification should address the model or service version, functions, interfaces, customer environment, authorised users, territories, dependencies and intended use. If classification or performance depends on a specific configuration, that configuration should be documented.

2. Allocate AI Act and GDPR roles separately

The parties should record their assumed roles under the AI Act and set out who provides instructions, documentation, logs, notices and regulatory cooperation. A separate analysis is required under the GDPR. Depending on the facts, the parties may be controller and processor, independent controllers or, in a narrower class of cases, joint controllers.

Where the supplier processes personal data on the customer’s behalf, Article 28 GDPR terms may be required. See our dedicated guide to the Data Processing Agreement in Romania. The DPA should not be treated as the complete AI contract, and the main agreement should not conflict with it.

3. Control prompts, files, outputs and training use

The contract should distinguish customer content, personal data, telemetry, feedback and output. It should state whether each category may be stored, reviewed by humans, used to improve the service or used to train a shared model. Where “no training” is promised, the clause should explain its scope, including whether safety review, abuse monitoring or service analytics remain permitted.

The European Data Protection Board has emphasised that whether an AI model is anonymous must be assessed case by case. A supplier’s assertion that its model is anonymous should therefore be supported by facts rather than accepted as a label. See the EDPB’s summary of Opinion 28/2024.

4. Make performance, limitations and human oversight usable

Conventional uptime metrics do not measure output quality. Depending on the use, the contract may need agreed tests, documented limitations, error reporting, performance monitoring, bias or drift controls, escalation and human-review requirements. The AI Act’s accuracy requirements should not be treated as a guarantee of error-free outputs. Any contractual accuracy or performance commitment should define the relevant task, dataset, test method, threshold and remedy.

5. Require evidence and audit cooperation

The customer may need records to complete an impact assessment, answer a regulator, investigate a complaint or demonstrate human oversight. The agreement should define which information is available, in what format, how quickly and subject to what confidentiality protections. In practice, enterprise suppliers may satisfy some audit requirements through independent certifications, reports and controlled information-sharing mechanisms rather than unrestricted customer audits. Those materials can support due diligence, but they do not automatically answer system-specific questions.

6. Coordinate security and incident notification

Security clauses should address access controls, encryption where appropriate, vulnerability management, segregation, personnel access, business continuity and incident cooperation. Notification should be triggered by defined events and delivered early enough for the customer to meet its own legal and operational duties. Different events may activate different regimes, so a personal-data breach, an incident affecting the AI system and an ordinary service outage should not be collapsed into one undefined term.

7. Address intellectual property and third-party claims

The contract should distinguish rights in customer inputs, supplier technology, configurations, fine-tuning, documentation, feedback and outputs. It should also allocate responsibility for claims involving training material, output, trademarks, confidential information and third-party components. Broad statements that the customer “owns the output” may be insufficient if the supplier cannot grant exclusivity or if protectability depends on applicable law and human contribution. Ownership language should be assessed together with applicable copyright rules, which may require sufficient human authorship for copyright protection.

8. Control subcontractors, subprocessors and model dependencies

An AI service may depend on model providers, cloud infrastructure, safety services and specialist subprocessors. The contract should identify the relevant chain, require notice of material changes and preserve appropriate objection or termination rights. For personal data, the subprocessor mechanism must align with Article 28 GDPR and any applicable international-transfer safeguards.

9. Regulate model and policy changes

Suppliers often reserve broad rights to modify models, acceptable-use policies and technical features. The customer should seek prior notice of material changes, enough information to reassess the deployment and a remedy when a change materially reduces functionality, alters data use, affects compliance or creates an unacceptable risk.

10. Connect liability to the risks that matter

Liability provisions should be read together with warranties, indemnities, insurance and remedies. A general cap may be commercially unsuitable for confidentiality breaches, unlawful data use, IP claims or deliberate misconduct, while unlimited liability for every model error may be unacceptable to a supplier, particularly where outputs remain subject to human review. The negotiated position should reflect control, foreseeability, fees, insurance and the consequences of the intended use.

11. Preserve suspension, termination and transition rights

The contract should explain what happens if the service becomes prohibited, materially non-compliant, insecure or unsuitable for the agreed purpose. Exit terms should cover data and prompt export, configuration records, transition assistance, continuing access where necessary, deletion, certification and surviving confidentiality or audit duties.

12. Align the whole contract suite

The main agreement, order form, specification, DPA, security schedule, service levels and online policies should be checked together. An order of precedence is important where one document allows training while another prohibits it, or where a linked policy can be changed unilaterally. Our broader contract review checklist explains the commercial clauses that remain relevant alongside the AI-specific controls.

Customer and supplier priorities are not identical

A customer usually seeks transparency, stable functionality, control of its data, evidence for compliance and practical exit rights. A supplier needs a defined intended use, customer cooperation, restrictions against misuse, protection for reusable technology and a liability position proportionate to fees and control. A balanced contract should not hide this tension. It should identify which party can prevent, detect and remedy each risk.

Practical experience: how Atrium approaches an AI contract review

AI vendor contract checklist before signature

1. Document the system, intended use, users and decision context.
2. Complete the AI Act role assessment and determine whether the deployment may involve prohibited, high-risk, transparency or other regulated AI use cases.
3. Map personal data, confidential information and international transfers.
4. Collect the main agreement, order, DPA, security schedule and linked policies.
5. Confirm whether customer data, prompts or outputs may be used for training.
6. Test whether supplier documentation supports the customer’s compliance duties.
7. Define relevant performance measures, limitations and human oversight.
8. Align incident notification with legal and operational deadlines.
9. Review IP ownership, licences, third-party material and claims.
10. Control material changes to models, policies, locations and subcontractors.
11. Model liability for realistic failure scenarios.
12. Plan suspension, export, transition and deletion before deployment begins.

Frequently asked questions

Disclaimer: This article provides general information and does not constitute legal advice. The appropriate contract and compliance analysis depends on the system, intended use, data, parties, operator roles, applicable law and complete contract suite.

AI Notice: AI-assisted content, reviewed and approved by a qualified Romanian lawyer.

A data processing agreement is required when a company engages another party to process personal data on its documented instructions. The label used in the commercial contract is not decisive: the parties must first classify their actual GDPR roles, then align the agreement with the service, security model, subprocessor chain and any international transfers.

When is a data processing agreement required?

The general rule is that a written DPA is required when one party processes personal data on behalf of another party. Article 28 GDPR requires the controller to appoint only processors that provide sufficient guarantees and to govern the processing through a binding contract or other legal act, in writing, including electronically.

The practical starting point is the service, not the supplier’s preferred contract label. Payroll providers, cloud hosting companies, customer-support platforms, outsourced IT administrators, email delivery services and some marketing vendors commonly act as processors because they handle data for purposes defined by their customer. The same vendor may nevertheless be a controller for separate activities, such as its own billing, fraud prevention or legally required records.

Before signing, map each processing activity and ask who decides why the data is processed and who makes the key decisions regarding the means of processing. Certain non-essential practical means may be left to the processor. The European Data Protection Board’s Guidelines 07/2020 on controller and processor concepts are the relevant official interpretative reference.

What must an Article 28 DPA contain?

A compliant DPA must identify the processing and include every mandatory control listed in Article 28(3) GDPR. It should specify the subject matter and duration, nature and purpose, types of personal data, categories of data subjects, and the controller’s rights and obligations. It must then translate the statutory requirements into workable contractual duties.

The European Commission has adopted optional standard contractual clauses for controllers and processors under Article 28. The parties may adopt the 2021/915 standard clauses or negotiate their own Article 28 terms. Where the standard clauses are used, additional clauses should not directly or indirectly contradict them or prejudice the fundamental rights and freedoms of data subjects.

Why a generic security clause is not enough

The security schedule should describe controls that match the actual data, systems and risks. Article 32 GDPR requires appropriate technical and organisational measures, taking account of the state of the art, implementation cost, processing context and risks to individuals. Depending on the service, relevant controls may include encryption, access management, logging, vulnerability management, backups, resilience, testing, staff controls and incident response.

A clause stating only that the supplier will apply “appropriate” or “industry standard” security gives the controller little evidence and may leave important assumptions unresolved. The annex should also distinguish controls included in the standard service from optional configurations that the customer must activate.

How should subprocessors be managed?

A processor cannot appoint a subprocessor without the controller’s prior specific or general written authorisation. Under a general authorisation, the processor must notify intended additions or replacements in time for the controller to object. The processor must impose equivalent data-protection obligations downstream and remains fully liable to the controller for the subprocessor’s performance of those obligations.

The contract should state what information accompanies a change notice, how long the objection window lasts, what constitutes a reasonable objection and what happens if the parties cannot resolve it. A nominal right to object is of limited value if the controller receives only a company name, with no service description, processing location or transfer information.

The European Data Protection Board’s Opinion 22/2024 on processors and subprocessors is an important due-diligence reference. Controllers should be able to identify the entire processing chain, including relevant subprocessors and, where appropriate, further sub-processing layers, and obtain enough information to assess whether sufficient guarantees exist.

Does a DPA cover international data transfers?

No. A DPA regulates processing on behalf of a controller, but the DPA alone does not provide a Chapter V transfer mechanism. If data moves to, or is remotely accessed from, a country outside the European Economic Area, the parties must separately establish whether an adequacy decision or another valid safeguard applies. The relevant Article 28 clauses and transfer safeguards may nevertheless be integrated into a single contractual document.

This distinction is easy to miss because two different EU instruments are commonly called “SCCs”. Commission Decision (EU) 2021/915 concerns standard clauses for the Article 28 controller–processor relationship. Commission Decision (EU) 2021/914 contains standard contractual clauses for transfers to third countries. Where the transfer clauses apply, the parties must select the correct module, complete the annexes and assess the destination-country context and any necessary supplementary measures.

How quickly must a processor report a data breach?

The GDPR requires the processor to notify the controller without undue delay after becoming aware of a personal data breach. The familiar 72-hour period applies to the controller’s notification to the competent supervisory authority where the legal conditions are met; it is not the processor’s default reporting deadline.

The DPA should therefore set a fast contractual notification route that gives the controller time to investigate and decide whether regulatory or data-subject communications are required. It should define the incident contact, initial information, phased updates, evidence preservation, cooperation, remediation and post-incident report. A fixed period can be useful, but it should not dilute the statutory “without undue delay” standard.

For the controller’s incident process, see our practical GDPR data breach guide for Romania.

What should the controller check before signing?

The controller should test both the contract and the processor’s ability to perform it. Article 28 requires sufficient guarantees, so signature alone is not the end of the due-diligence exercise.

1. Confirm the role for each activity. Separate processor functions from any independent or joint-controller processing.
2. Map the data and people involved. Record data categories, data subjects, purposes, systems, locations, retention and sensitive-data elements.
3. Review the mandatory clauses. Check every Article 28 requirement and remove conflicts with the main services agreement.
4. Test the security annex. Align the written controls with the service configuration and the risk level.
5. Identify all relevant subprocessors. Verify functions, locations, change procedure, downstream obligations and transfer safeguards.
6. Plan incidents and rights requests. Agree contacts, response steps, information fields and internal escalation.
7. Set the exit route. Define return, export, deletion, backups, certification and any lawful retention.
8. Retain accountability evidence. Keep the assessment, negotiated terms, approvals, notices and review dates.

Illustrative vendor scenarios

These examples are simplified and do not replace a factual role analysis.

How should the DPA interact with the main services agreement?

The documents should work as one contract set. The services agreement, DPA, security schedule, service levels and subprocessor information should use consistent definitions, liability rules, notice mechanisms, termination rights and order-of-precedence clauses.

Commercial limits on liability require particular attention. A DPA cannot remove statutory obligations or the rights of data subjects, while the allocation of contractual risk between the parties depends on the negotiated agreement and applicable law. Audit rights also need balance: the controller requires meaningful evidence, but the process should protect the processor’s security, confidentiality and other customers.

For a wider commercial review, use our contract review checklist for Romania. Technology businesses may also find our IT and SaaS contract services relevant.

Frequently asked questions

Disclaimer: This article provides general information and does not constitute legal advice. It reflects the law and official guidance available as of the date of publication. The correct analysis depends on the actual processing activities, contractual roles, data flows, security measures and jurisdictions involved.

AI Notice: AI-assisted content, reviewed and approved by a qualified Romanian lawyer.

Online company registration in Romania is available for many founders, including non-residents. The filing can be submitted electronically or through an authorised representative, but a valid electronic signature is only one part of the route. The documents, signing authority, identity checks and ONRC platform requirements must also align.

This guide explains the online filing route for foreign individuals, overseas companies and Romanian founders. It focuses on the relationship between electronic signatures, filing authority, documents and the National Trade Register Office platform. For the broader choice of entity, capital and corporate structure, see our company formation in Romania guide.

Can you register a Romanian company online?

Romania’s National Trade Register Office online portal offers services including company-name reservation and incorporation. Law No. 265/2022 also regulates online company formation and electronic communication with the Trade Register.

Under Article 105 of Law No. 265/2022, the registrar may exceptionally request physical presence if there is a suspicion of identity falsification. The same provision states that physical presence is not required when the incorporation application and supporting documents, including the articles of association, were prepared by a public notary or lawyer. If presence is exceptionally requested during online formation, the remaining stages may still be completed electronically.

What are the steps for remote company formation in Romania?

The legal sequence is straightforward, but the filing route should be chosen before documents are signed. Select each step below to see its practical purpose.

1. Confirm the company structure. Decide the entity type, ownership, administrators, business activities and signing authority. An SRL is common, but it should not be selected automatically when investment, governance or regulated activities require another structure. See our 2026 guide to Romanian limited liability companies.
2. Reserve the company name. Submit alternatives that comply with the Trade Register rules. Our separate guide explains how to register a company name in Romania.
3. Establish the registered office. Every Romanian company needs a valid registered office and supporting title to use the address. For the documents commonly used in an incorporation file, see our foreign-founder document checklist.
4. Prepare, formalise and translate the documents. Coordinate the articles of association, identity or corporate records, declarations, beneficial-owner information, office evidence and powers of attorney. Foreign public documents may require apostille, legalisation or an applicable exemption, depending on the issuing state, bilateral treaties, EU legislation and the nature of the document, followed by an authorised Romanian translation where required.
5. Sign and file through the selected route. If the electronic filing route is used, the signature and submission must satisfy the applicable ONRC technical and procedural requirements. A properly authorised representative may provide an alternative route, provided that the authority granted complies with the requirements applicable to the filing.
6. Complete post-registration onboarding. After incorporation, organise accounting, tax registrations or options, bank onboarding, employment setup and any permits required for the actual activity.

Which documents do foreign founders usually need?

Do founders need a qualified electronic signature?

The signature route should be tested before execution. Romania’s framework includes Law No. 214/2024 on electronic signatures and trust services, while the Trade Register procedure is governed specifically by Law No. 265/2022 and the portal’s filing requirements. The availability of electronic filing depends not only on the legal validity of the electronic signature but also on the technical and procedural requirements imposed by the National Trade Register Office.

Remote identity checks may also involve regulated identification services. The Romanian Authority for Digitalisation publishes information on remote identification by video means, but the availability and acceptance of a particular method still depend on the institution and transaction.

Is a Romanian notary always required?

The correct answer depends on the document, the country where it is issued and the chosen filing route. For foreign founders, the practical question is usually not “Do I need a notary for the company?” but “Which document, if any, needs notarisation, apostille or legalisation, and in which country?”

How long does remote incorporation take?

Under Articles 105 and 107 of Law No. 265/2022, the registrar generally resolves complete applications on documents within one working day and, when the legal requirements are met, orders registration according to the statutory procedure. Procedural exceptions, requests for additional evidence or a need to remedy the file may affect this stage. The one-working-day period should not be advertised as the total time needed by a foreign founder.

If the file is incomplete or does not meet the legal requirements, Article 106 allows a remedy or completion period of up to 15 calendar days. The practical schedule should therefore separate:

• preparation time for the corporate structure and registered office;
• time for foreign documents, apostille or legalisation and translation;
• the Trade Register review of a complete filing;
• time needed to cure any filing defect; and
• post-incorporation bank, accounting, tax and licensing steps.

Is the bank account part of the online incorporation?

Each bank decides what identification, beneficial-owner, source-of-funds and business-model evidence it needs. Some institutions offer remote onboarding in eligible cases; others may request a video identification, additional documents or physical attendance. Founders should compare banking routes early, especially where the ownership chain is international or the activity carries heightened compliance risk. See our guide to opening a Romanian business bank account as a non-resident.

What most often delays a remote filing?

Remote formation checklist for a foreign founder

1. Confirm the Romanian entity, ownership, administrators and business activities.
2. Choose the online filing or legal-representation route before signing documents.
3. Check each foreign document for issue date, apostille or legalisation and Romanian translation.
4. Secure a compliant registered office and align the supporting document with the intended filing.
5. Map the beneficial owners through the complete international ownership chain.
6. Verify the signature and authority of every shareholder, administrator and representative.
7. Submit one consistent, complete file through the National Trade Register Office route.
8. Plan banking, accounting, tax and sector-specific compliance as separate workstreams.

The bottom line

Remote company formation in Romania is a workable route for many foreign founders, but it is not a single universal online form. The successful approach coordinates Romanian incorporation requirements with the founder’s home-country documents, a valid signing or representation route, registered-office evidence and separate post-registration onboarding.

AI Notice: AI-assisted content, reviewed by a qualified Romanian lawyer.

Directors and officers insurance in Romania can protect managers and companies against certain defence costs and civil claims arising from alleged management errors. It does not cancel a director’s legal duties, guarantee payment of every claim or cover intentional misconduct simply because the allegation concerns a management decision.

This guide is written for Romanian subsidiaries, foreign groups, founders, shareholders and board members assessing management-liability protection. It complements our detailed guide to Romanian company director liability, which explains when personal exposure may arise under company, insolvency and tax law.

What is D&O insurance and what does it protect?

D&O insurance is a liability policy designed to respond to covered claims alleging a wrongful act by an insured director or officer in that management capacity. Depending on the wording, it may fund defence costs and pay covered settlements, judgments or other insured loss. The policy may also reimburse the company where it lawfully indemnifies the individual.

The expression “wrongful act” is usually defined broadly in the policy, but the definition is only the entrance to the coverage analysis. The claim must also fall within the insured persons, insured capacity, policy period, territory and jurisdiction. It must not be removed by an exclusion, and all notification, consent and cooperation requirements must be met.

Is D&O insurance mandatory for Romanian directors?

There is no safe basis for saying that one identical D&O policy is compulsory for every Romanian company and every SRL administrator. The answer depends on the company form, appointment framework, applicable special regulation and corporate decisions.

Article 153¹²(4) of Romanian Companies Law no. 31/1990 applies within the governance regime of joint-stock companies (SA) and should not automatically be assumed to create a general insurance obligation for all SRL administrators. For a limited liability company, the articles of association, shareholders’ decision, mandate terms and any sector-specific legislation should be checked separately.

Romanian law refers to professional liability insurance, while modern D&O insurance is a market product developed by insurers. Although D&O insurance frequently serves this purpose in practice, the legal obligation and the insurance wording should not automatically be treated as identical concepts.

Even where insurance is required by the appointment or corporate framework, a policy bearing the label “D&O” does not automatically satisfy every requirement. The insured roles, limit, territory, duration, run-off protection and exclusions must fit the mandate and risk profile.

Which Romanian director-liability claims may engage the policy?

A D&O policy may be relevant when a director faces a civil claim, investigation or other covered proceeding arising from alleged conduct in office. Whether it responds depends on the precise policy, not merely on the legal label attached to the dispute.

How does a D&O claim move from allegation to payment?

The practical sequence begins before liability is established. Many policies are written on a claims-made or claims-made-and-notified basis. A demand, investigation notice, circumstance or written allegation may trigger immediate notification duties even if no court proceedings have started.

1. Preserve the notice. Keep the demand, authority letter, board papers and delivery evidence.
2. Identify every potentially responsive policy. Check local and global programmes, prior-year policies and any run-off cover.
3. Notify within the required form and period. Do not wait for a final claim value or court filing if the wording requires earlier notice.
4. Obtain consent before material defence expenditure or settlement. Emergency-cost provisions should be checked where prior consent is impracticable.
5. Separate insured and uninsured matters. Allocation may be needed between individuals and the company, covered and uncovered allegations, or several policies.
6. Protect privilege and cooperation. Coordinate Romanian counsel, broker and insurer communications without disclosing privileged analysis unnecessarily.

What does D&O insurance usually not cover?

Exclusions differ materially between insurers and negotiated programmes. The most important distinction is between an allegation and a final conduct determination. Some policies advance defence costs while allegations are unresolved, then apply a dishonesty or personal-profit exclusion only after a final, non-appealable determination or admission. Other wording may be less protective.

Does D&O insurance cover insolvency, tax liability or criminal proceedings?

Not automatically. These are precisely the scenarios where the difference between defence-cost protection and payment of the underlying liability becomes important.

Under Article 169 of Romanian Insolvency Law no. 85/2014, the court may order persons who contributed to insolvency through listed conduct to bear part or all of the debtor’s liabilities within the causally connected loss. A policy must be checked for insolvency-practitioner claims, conduct exclusions, prior-circumstance provisions and the point at which dishonesty is established.

Tax debts, administrative fines, criminal fines, confiscation and amounts representing unlawful gain may be excluded from coverage or may be regarded as non-insurable under applicable mandatory law. Nevertheless, some policies may cover defence costs for a covered person during an investigation or proceeding until an exclusion is established. The precise wording and Romanian public-policy rules control the answer.

A policy cannot prevent an investigation, prosecution, disqualification, regulatory order or the consequences of a final judgment. Insurance is financial protection within contractual and legal boundaries, not a transfer of public-law responsibility.

What should a Romanian company check before buying or renewing D&O cover?

The best review starts with the company’s actual management structure and claim scenarios, not with the premium alone. A low limit, broad entity cover or weak notification clause may leave directors exposed even where the policy looks extensive on a summary page.

How should D&O insurance fit with corporate governance?

Insurance works best when the governance system can show who decided, on what information, under which authority and with which conflict controls. The policy does not replace accurate minutes, authority matrices, financial reporting, compliance escalation or timely insolvency analysis.

Companies should align the policy with the articles of association, director appointment or mandate, shareholder resolutions, group indemnity arrangements and any transaction documents. A share purchase agreement may require run-off cover for outgoing directors, while a shareholder agreement may address nomination rights and insurance commitments. Neither document should promise protection that the policy does not deliver.

Change of control is particularly important. Many policies restrict cover for wrongful acts occurring after an acquisition or other control event. Transaction planning should therefore address tail coverage, continuity dates, notice of known circumstances and the allocation of premium and claims responsibility.

The bottom line

D&O insurance in Romania can be an important layer of financial protection, especially where directors manage material contracts, regulated activity, cross-border operations or financial distress. Its value depends on the wording and the company’s ability to recognise and manage a claim.

The practical review should connect four documents: the legal mandate, the corporate indemnity, the D&O policy and the internal claims protocol. If they use different definitions of director, authority, claim or covered loss, the gap may emerge only when protection is needed.

Frequently asked questions

Disclaimer: This article provides general legal and insurance information and does not constitute legal, tax, insolvency, insurance-brokerage or coverage advice. Coverage depends on the policy wording, facts, applicable law and insurer’s assessment.

AI Notice: AI-assisted content, reviewed by a qualified Romanian lawyer.

A share purchase agreement in Romania should do more than record the number of shares and the price. It must connect the buyer’s due diligence findings with the conditions for closing, the seller’s warranties, specific indemnities, price mechanics and the corporate and regulatory steps needed to transfer control safely.

This guide is written for foreign investors, international groups, founders and business owners negotiating the acquisition or sale of a Romanian company. It focuses on private acquisitions of shares or social parts, particularly Romanian limited liability companies (SRLs). Listed-company rules, regulated-sector acquisitions, privatisations and public takeovers require additional analysis.

The article complements our procedural guide to changing shareholders in a Romanian company. That guide covers the Trade Register implementation. This one explains how the commercial acquisition should be investigated, negotiated and protected contractually.

What does a share purchase agreement do in Romania?

A share purchase agreement, commonly called an SPA, is the principal contract under which the seller agrees to transfer and the buyer agrees to acquire shares or social parts in a Romanian company. It identifies the securities, price, conditions, closing process and allocation of risk between the parties.

The agreement operates within Romanian contract law and the mandatory rules applicable to the target’s corporate form. For an SRL, the transfer mechanics must be aligned with Articles 202 and 203 of Company Law no. 31/1990 and the applicable registration formalities before the National Trade Register Office (ONRC).

Why must legal due diligence come before the SPA is finalised?

Due diligence should identify the matters that can change the decision to buy, the valuation, the deal timetable or the contractual protection. A report that merely lists documents does not complete the task. Each material finding should be converted into a transaction response.

The scope normally covers corporate title and governance, financing and security, material contracts, real estate, employment, tax, disputes, permits, regulatory compliance, intellectual property, IT, data protection, environmental matters and beneficial ownership. Sector, size and business model determine the emphasis.

Which clauses matter most in a Romanian share purchase agreement?

The SPA should describe the transaction as one coherent mechanism. Definitions, price, conditions, warranties, disclosure, indemnities, limitations, covenants and closing deliverables must work together. Imported English-law wording should not be used without checking how it operates under the chosen governing law and Romanian mandatory rules.

How should the purchase price be structured?

The price clause should explain both the headline value and the route from that value to the amount paid. A fixed price is not necessarily simple if debt, cash, working capital, leakage, earn-outs, holdbacks or currency conversion remain unresolved.

A buyer should not treat escrow as a substitute for a coherent claims regime. The SPA should state whether recovery is limited to the escrow, whether the buyer may set off, how competing claims are handled and what happens when the escrow expires.

What is the difference between signing and closing?

Signing creates the contractual commitment. Closing completes the agreed transfer and payment once the applicable conditions are satisfied or waived. They may occur on the same day in a simple transaction, but regulatory approvals, third-party consents, financing or restructuring often require a split process.

Which Romanian approvals and filings can affect closing?

The regulatory analysis should begin before the SPA timetable is agreed. A condition drafted after signing cannot restore leverage or time already lost.

Corporate approval and ONRC registration

For an SRL transfer to an outside buyer, Article 202 of Company Law no. 31/1990 applies together with the target’s articles of association. The parties should verify statutory approval thresholds and any pre-emption or consent rights created by the articles of association, as well as pledges and other restrictions. The applicable ONRC registration formalities and the update of the company’s shareholder register should be built into the completion process.

ANAF notification and tax-debt safeguards

The practical scope of Article V of Law no. 239/2025, as amended by Government Emergency Ordinance no. 13/2026, should be verified in light of the transaction structure and current ONRC and ANAF practice. Although the regime was introduced in the context of transfers affecting company control, registration practice during 2026 has raised questions regarding its application to a broader range of SRL share transfers, as discussed in this analysis of emerging ONRC practice. The parties should confirm the current notification, tax-certificate, guarantee and registration requirements before signing and again before filing.

Merger control

An acquisition of sole or joint control may constitute an economic concentration. Under Competition Law no. 21/1996, the Romanian thresholds are generally met where the combined worldwide turnover of the undertakings concerned exceeds EUR 10 million and at least two undertakings concerned each achieved Romanian turnover exceeding EUR 4 million in the previous financial year. The EU Merger Regulation may apply instead where its thresholds are met. Closing before the required clearance can expose the parties to gun-jumping risk.

Investment screening

Romania’s investment-screening regime under Government Emergency Ordinance no. 46/2022 was substantially amended by Government Emergency Ordinance no. 17/2026. The general value threshold is now EUR 5 million, but a transaction below the threshold may still be examined if it may affect security, public order or EU projects or programmes. The rules can apply to EU and non-EU investors, and the filing contribution is EUR 5,000 where an authorisation application is required. Sector, investor, control, value and transaction structure must be screened early.

Sector approvals, lender consents, foreign-subsidy review or contractual change-of-control notices may also be relevant. The SPA should allocate responsibility, information, cooperation, remedies and the long-stop date for each approval.

What should happen at closing?

Closing should be a coordinated exchange, not a loose collection of signatures. The SPA should identify every deliverable, who provides it, its agreed form and whether all actions are deemed simultaneous.

1. Confirm conditions. Record satisfaction or valid waiver of every closing condition.
2. Approve the transfer. Deliver the required shareholder and corporate resolutions.
3. Transfer the shares. Execute the required instruments and update the shareholder register.
4. Pay the consideration. Follow the funds flow, escrow and debt repayment arrangements.
5. Release security. Deliver releases of share pledges, guarantees or target security where agreed.
6. Change governance. Coordinate resignations, appointments, powers of attorney and bank mandates.
7. Deliver control items. Transfer corporate books, credentials, keys, seals and agreed records.
8. Complete filings. Submit ONRC and ANAF documents, together with beneficial-owner filings where required under the applicable transparency rules, within the relevant timetable.

What limitations should apply to seller liability?

Seller limitations often include a de minimis threshold, basket, aggregate cap, time limits, mitigation, exclusion of double recovery and a formal claim procedure. Tax, title, authority, fraud and specific indemnities may have different limits. The commercial result depends on how these provisions interact, not on any one headline cap.

The buyer should also test recoverability. A contractual claim against a seller with no accessible assets may provide little protection. Escrow, holdback, bank security, parent guarantee or warranty and indemnity insurance may be considered depending on transaction size and risk.

A buyer’s pre-signing checklist

1. Define the acquisition perimeter. Confirm percentage, target entities, securities and excluded items.
2. Verify title and authority. Check ownership, encumbrances, approvals and signatory powers.
3. Complete risk-focused due diligence. Prioritise issues that affect value, continuity or closing.
4. Translate findings into protections. Allocate each material issue to remediation, price, condition, warranty, indemnity or withdrawal.
5. Select the price mechanism. Define accounting rules, leakage, debt, cash, working capital and dispute resolution.
6. Screen regulatory approvals. Review merger control, investment screening, sector approvals and third-party consents.
7. Align signing and closing. Specify conditions, conduct rules, long-stop date, termination and closing deliverables.
8. Test recovery. Check caps, time limits, exclusions, seller credit and available security.
9. Plan filings and integration. Prepare ONRC and ANAF filings, beneficial-owner filings where required under the applicable transparency rules, governance steps and day-one actions.

The bottom line

A Romanian SPA should be the final expression of the buyer’s investigation and the parties’ negotiated risk allocation. The strongest agreement is not the longest. It is the one that identifies what is being bought, states how price is calculated, prevents closing before essential approvals, allocates known and unknown risks clearly and gives the parties an executable closing process.

Disclaimer: This article provides general information and does not constitute legal or tax advice. The correct structure, approvals, tax treatment and contractual protections depend on the parties, target, sector and facts of each transaction.

AI Notice: AI-assisted content, reviewed and approved by a qualified Romanian lawyer.