Your first enterprise DPA is a product conversation.

Start with your role: controller or processor

Data protection law splits responsibility between two roles. A controller decides why and how personal data is used. A processor handles personal data on the controller’s behalf and on its instructions. Most B2B software companies are processors for the data their customers load into the product.

Few companies hold only one role. You are usually a controller for your own account data, billing, marketing and product analytics. You may also want to use customer data to improve your models or benchmark performance. If you decide that purpose yourself, you are likely acting as a controller for that activity, and a processor-only DPA will not cover it.

Settle these roles before you redline anything. They decide which template applies, which obligations sit with you and what you must say in your privacy notice. US state privacy laws use similar ideas under different names, such as “service provider” and “contractor” in California and “processor” in most other states.

Follow the data before you touch the contract

Draw a simple data-flow diagram. Show what personal data comes in, from whom, where it is stored, which systems copy it and who can see it. Include the less obvious places: logs, backups, analytics tools, error trackers, support tickets and any AI model provider you call.

This map is the foundation for every later answer. It tells you which vendors are subprocessors, where transfers happen and what deletion really involves. It also stops the common pattern where legal says one thing, engineering knows another and the customer discovers the gap.

• Categories of personal data and of people affected, such as employees or end customers
• Hosting regions for production, backups and disaster recovery
• Every third party that stores or can access customer data
• Who on your team has access, and how that access is controlled and logged
• How long each copy is kept, and how it is deleted

What a GDPR DPA must contain

Article 28 of the GDPR sets the minimum content of a contract between a controller and a processor. The UK GDPR has the same provision. The contract must describe the subject matter and duration of the processing, its nature and purpose, the types of personal data, the categories of people concerned, and the controller’s obligations and rights.

It must then include a fixed list of processor commitments. A good template covers each one clearly. If an item is missing, expect the buyer’s counsel to add it.

• Process personal data only on the controller’s documented instructions, including on international transfers
• Ensure that staff authorised to process the data are bound by confidentiality
• Take the security measures required by Article 32
• Engage another processor only with the controller’s prior authorisation, and pass the same obligations down to it
• Help the controller respond to people exercising their rights
• Help the controller with security, breach notification, impact assessments and consultation with regulators
• Delete or return all personal data at the end of the services, unless the law requires storage
• Make available the information needed to show compliance, and allow for audits and inspections
• Tell the controller immediately if an instruction would, in your view, break data protection law

Subprocessors: the clause that touches your roadmap

A subprocessor is a vendor you engage that processes your customer’s personal data, such as your cloud host, an email delivery service or an AI model provider. Under Article 28 you need the customer’s authorisation to use them. Most suppliers seek a general authorisation, backed by a published list and advance notice of changes.

The notice period and the customer’s right to object matter in practice. If you promise 30 days’ notice, you cannot switch to a new model provider next week. Agree a notice period your product team can live with, and build a simple process for updating the list.

The GDPR also makes you responsible to the customer if your subprocessor fails to meet its data protection obligations. Check that your own vendor contracts give you terms at least as protective as those you are offering.

International transfers need their own analysis

Signing a DPA does not settle international transfers. Under the GDPR, personal data sent outside the European Economic Area needs a legal basis, such as an adequacy decision or an approved safeguard. Remote access by an engineer in another country can count as a transfer, not only hosting.

The most common safeguard is the Standard Contractual Clauses, or SCCs: model terms adopted by the European Commission in 2021. For US recipients, certification under the EU–US Data Privacy Framework is an alternative; the EU General Court dismissed a challenge to it in September 2025, though further appeals remain possible. The UK has its own tools, the International Data Transfer Agreement and a UK Addendum to the EU SCCs.

Where you rely on SCCs, buyers often ask for a transfer impact assessment, or TIA. A TIA is a documented review of whether the law in the destination country could undermine the protection the clauses promise. Other regimes, such as China’s PIPL, Saudi Arabia’s PDPL and India’s DPDP Act, have their own transfer rules, so check each market separately.

What the questionnaire will ask

Enterprise security and privacy questionnaires vary in length, but they return to the same themes. Many draw on frameworks such as ISO/IEC 27001 or SOC 2 reports, and a current certificate or report can shorten the process considerably. Expect detailed questions in these areas.

Answer from the system as it is today, not from your roadmap. If a control is planned, say so and give a date. Inaccurate answers can become contractual representations, and correcting them later costs more trust than a candid “not yet”.

• Security certifications, penetration testing and vulnerability management
• Encryption in transit and at rest, and key management
• Access controls, single sign-on, multi-factor authentication and access reviews
• Hosting regions, data residency options and subprocessors
• Incident response, breach notification timelines and named contacts
• Retention, deletion and backup policies
• Whether customer data is used to train or improve AI models
• Business continuity, disaster recovery and employee screening

Make deletion and breach response executable

Deletion is where promises most often outrun reality. Before committing to a deadline, test what happens to backups, logs, support records, search indexes, analytics tools and data held by subprocessors. A realistic clause might commit to deleting live data within a set period and letting backups expire on their normal cycle.

Breach clauses need the same care. Under the GDPR a controller must usually notify the regulator within 72 hours of becoming aware of a breach, and a processor must tell the controller without undue delay. Buyers often ask for 24 or 48 hours. Agree a timeline your on-call process can meet, and decide in advance who sends the notice.

Build a reusable evidence pack

After the second or third enterprise deal, the questions repeat. Collect the answers in one maintained set: your own DPA template, a subprocessor list, a security overview, a data-flow diagram, your retention schedule, incident contacts and transfer documents. Keep a record of when each item was last reviewed.

Prepare a clear position on AI and data residency, because buyers now ask about both early. State whether customer data is used for model training, what your AI vendors’ terms say, and where processing happens. Ground every answer in the actual system and supplier contracts.