What should be in a data processing agreement with an automation consultant?

You are about to give an outside consultant access to your CRM, your inbox rules, your practice management system and your Zapier or Make account. They will see client names, emails, invoices and possibly case or patient details. Your NDA covers confidentiality in general terms, but your data protection obligations ask for something more specific: a data processing agreement, or DPA.

The direct answer: if the consultant can see or handle personal data on your behalf, they are almost certainly acting as your processor, and under the GDPR you need a written contract with the terms listed in Article 28. Swiss law asks for less formality but the same substance. This article walks through what the agreement should say and the gaps that matter most in automation work. It is general information, not legal advice; have your lawyer or data protection lead review the final text.

Why an automation consultant is usually a processor

A processor is anyone who handles personal data on your instructions and for your purposes. An automation consultant fits that description even if they never download a file: building and testing a workflow means opening records, reading run logs and checking that the right client ended up in the right place. The EDPB guidelines on controller and processor make clear that access in the course of a service counts as processing; it does not need to be the main point of the service.

You stay the controller. You decide what data the workflows move and why, and you remain responsible for that choice.

An NDA is not a DPA

An NDA says "keep our information secret". A DPA says how personal data may be used, secured, shared with others, reported on if something goes wrong, and returned or deleted at the end. You want both. An NDA alone leaves out most of what Article 28 requires.

What GDPR Article 28 requires the contract to say

Article 28(3) GDPR lists the minimum content. In plain terms, the agreement must describe the processing (subject, duration, nature and purpose, types of personal data, categories of people concerned) and commit the consultant to:

1. Act only on your documented instructions, including on any transfer of data outside the EU.
2. Keep staff bound by confidentiality, including any subcontractors or freelancers they bring in.
3. Apply appropriate security measures under Article 32.
4. Use sub-processors only with your written authorization, specific or general, and pass the same obligations down to them.
5. Help you respond to people exercising their rights, such as access or deletion requests.
6. Help you with security, breach notification and impact assessments; under Article 33(2) a processor must tell you about a personal data breach without undue delay.
7. Delete or return all personal data at the end of the engagement, at your choice.
8. Give you the information needed to show compliance and allow audits or inspections.

The consultant must also tell you immediately if they think one of your instructions breaks data protection law.

You do not have to draft this from scratch. The European Commission published standard contractual clauses between controllers and processors (Implementing Decision 2021/915) that cover Article 28(3) and (4). Many firms use them as the base and fill in the annexes.

What the Swiss FADP adds

Under Article 9 of the revised Federal Act on Data Protection, you may hand processing to a processor by contract if they only process data the way you yourself would be allowed to, and no legal or contractual secrecy obligation forbids it. You must satisfy yourself that the processor can guarantee data security, and the processor may not pass the work to a third party without your prior approval.

The FADP does not prescribe a formal DPA template, but commentators such as this Mondaq overview recommend a written agreement as best practice, often modeled on the GDPR one. Two further Swiss points:

• Breaches: under Article 24(3) FADP, the processor must report any data security breach to you as quickly as possible.
• Professional secrecy: lawyers, doctors and other professions covered by Article 321 of the Swiss Criminal Code (unofficial English translation) have secrecy duties that extend to their auxiliaries. Firms in those professions usually add an explicit clause in which the provider acknowledges the secrecy duty. This is a question for your lawyer, not a box to tick.

The clauses that matter most in automation work

Generic DPA templates are written for software vendors. Automation consulting has its own risk points, and these are where a template often stays vague.

Whose account the work lives in

This is the single most useful question. If the workflows run in your Zapier, Make, n8n or Power Automate account, the platform is your own processor under your own contract with it, and the consultant only works inside it. If the consultant builds in their account and connects your apps to it, the platform becomes their sub-processor, your data sits in an account you do not control, and the DPA must authorize and cover that. The first arrangement is simpler and easier to end cleanly.

Credentials and access

The agreement, or an annex to it, should say how the consultant receives access (a named user on your systems, not a shared password), with which permissions, and when it is removed. Ask for least-privilege access: a consultant building an intake workflow does not need admin rights on your accounting system.

Test data and copies

Automation work produces copies: run history, test records, exports used to check a mapping, screenshots in a support ticket. The DPA should state that the consultant uses dummy or minimal data for testing where possible, keeps no local copies beyond what the work needs, and deletes them at the end. Our guide on whether it is safe to put client data through Zapier explains how long platform logs keep data by default.

Sub-processors

List them by name: any freelancer, any AI tool the consultant uses to write or debug a workflow, any password manager or ticketing system where your data might appear. If the consultant pastes a sample record into an AI assistant to fix a formula, that assistant is processing your data.

Location and transfers

Note where the consultant and every sub-processor are based and where data is stored. For a consultant outside the EU or Switzerland, the agreement needs a transfer mechanism, such as an adequacy decision or standard contractual clauses for international transfers, which are a separate set from the controller-to-processor clauses above.

End of the engagement

Spell out the handover: workflows documented, credentials rotated, consultant users removed, and written confirmation that any copies are deleted. If the consultant leaves without this, your automations may keep running under their login, a problem we cover in what happens to automations when an employee leaves.

A short checklist before you sign

• The agreement names the systems, data types and people concerned (clients, staff, patients, candidates).
• Work happens in your accounts, with named, least-privilege users.
• Sub-processors are listed, and changes need notice with a right to object.
• Breach reporting is prompt, with a named contact on both sides.
• Testing uses minimal or dummy data; local copies are deleted at the end.
• Transfers outside the EU or Switzerland have a stated legal basis.
• Professional secrecy is addressed if you are a law firm, clinic or fiduciary.
• Your lawyer or data protection lead has reviewed it.

A consultant who hesitates to sign a DPA, or who cannot tell you where their tools store your data, has answered an important question for you.

How Flow Mesh helps

Every engagement starts with a first call and an NDA, and a DPA is available on request. Our stack audit is scoped in writing before it starts and gives a verdict on every tool (keep, configure, consolidate or replace); any build is quoted in writing afterwards and done inside your own accounts, so your workflows and data stay under your control. See our FAQ for how engagements run.

Key takeaways

• A consultant who can see personal data while building your automations is usually your processor, so the GDPR requires an Article 28 contract.
• The EU's standard controller-to-processor clauses are a ready-made base; fill in the annexes for your systems.
• The Swiss FADP sets fewer formalities but the same substance: security, no sub-processing without approval, prompt breach reports.
• The most important practical clause is whose account the workflows live in; yours is simpler and safer.
• Professional secrecy for lawyers, doctors and fiduciaries needs its own review with your lawyer.