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.