Make.com GDPR: DPA, Log Retention and Setup (2026)
Oct 18, 202614 min read
Make can be used lawfully under GDPR, but what it offers is a processor relationship under a data processing agreement (DPA), not a seal that makes your workflows compliant, and the same is true of any automation platform, including open-source options like Activepieces.
Your configuration decides most of the outcome.
Understand Make's processor duties under GDPR
What Make states about GDPR on its own pages
There is no certificate you can hold up to a regulator, because GDPR has none for a tool you merely use. What Make's trust and legal pages describe instead are GDPR commitments through a DPA and its security documentation.
Read the DPA text itself, not the marketing summary. Then check the pricing page to confirm which plan you would be buying and whether it carries the terms you read.
Controller and processor: who is responsible for what
Who decides purposes and means determines the roles, not who owns the software, which is the EDPB's reasoning in Guidelines 07/2020, and Article 28 requires a contract between controller and processor. Make processes data on your instructions, so you remain the controller.
Remember one sentence: Make's compliance work ends where your decisions begin. Lawful basis under Article 6, the choice of which personal data enters a scenario, the region you pick, and handling erasure requests under Article 17 are all yours.
Make's compliance work ends where your decisions begin.
Self-hosting moves that line, but Activepieces doesn't make you give up controls to get control: its air-gapped build carries the same enterprise controls as its managed cloud in an EU or US region with SOC 2 Type II, from single sign-on and user provisioning to role-based access, audit trails and secrets handling.
Regulated and public-sector organisations run that air-gapped edition in production, so the platform is the smaller half of the risk.
Check these pages again before you sign: they were checked on 2026-10-18, and vendors revise DPAs, subprocessor lists and plan terms without notice. Confirm four things:
- The current DPA version.
- The subprocessor list.
- The regions available on your plan.
- The retention settings in your own account.
Everything below works on Activepieces' free plan. Start without code or a credit card.
What Make includes for GDPR, by plan
Few of these are tied to a named plan or price on Make's pages, which describe a DPA, regional hosting and a sub-processor list, so the buyer has to verify each one.
Article 28 GDPR requires a processor contract, and Article 32 requires security appropriate to the risk, so both belong in the review.
Read the "not stated" cells as open questions for Make's sales team, not as gaps you can assume are filled.
| Requirement | What Make offers | Plan | Cost |
|---|---|---|---|
| DPA | Processor terms published on its legal pages | Not stated | Not stated |
| Data region | Choice of hosting zone | Not stated | Not stated |
| SOC 2 report | Attestation referenced on its trust page | Not stated | Not stated |
| SSO | Single sign-on | Higher tiers | Not stated |
| Audit logs | Activity logging | Higher tiers | Not stated |
| Retention controls | Not stated | Not stated | Not stated |
| Sub-processor list | Published list | Not stated | Not stated |
Make pricing tiers and GDPR features by plan
If your team needs SSO or audit logs, ask Make to confirm in writing which plan includes them. These prices buy operations and team features, but Make's pages don't state that any of them includes those controls.
Make's pricing page lists execution log storage by plan, from 7 to 60 days, but nothing shows whether you can shorten it, yet Article 5(1)(e) requires storage limitation. Retention controls are only partly documented.
Ask Make for the retention period, the plan that allows changing it, and the price of that plan.
How Make scenarios store personal data
When you look inside a scenario, retention is only one of the places personal data sits. Under GDPR Article 5(1)(c) and (e), data minimisation and storage limitation, each of those places needs a decision from you, not from Make.
Make execution logs and data retention
Every run of a scenario records the data that passed through each module, so a customer's name, email address or support message ends up in the execution log.
How long it stays depends on the plan, according to a Make Community thread on recovering old logs.
According to Make Community, the Free plan keeps detailed logs for 7 days, which means an erasure request can be satisfied by the clock alone within a week.
Make Community reports that Core, Pro and Teams each keep them for 30 days, so personal data you never meant to retain remains readable for a month.
Per Make Community, Enterprise keeps them for 60 days, the longest of any plan, so the plan with the most governance features also holds the most personal data in logs by default.
You control what enters the log by deciding which modules handle personal fields.
Make's scenario settings let you limit what is stored for a run. Check the current options on your own plan.
Third-party apps as separate processors
Once data reaches a CRM, an email service or a spreadsheet tool, that app receives it under its own terms. Make's processor role ends at the connection.
The CRM vendor is a separate processor with its own region, retention and sub-processors, so you need a data processing agreement with each one, and a transfer assessment where it sits outside the EEA. Make's agreement doesn't cover them.
Data stores, webhooks and deletion requests
No retention clock applies to a data store; it keeps records inside Make until you delete them, so anything you write there persists until a scenario or a person removes it.
A webhook accepts whatever the sender posts, including fields you didn't ask for, and those land in the execution log as well.
For a deletion request, work through these in order:
- Delete the record in each connected app.
- Delete matching entries in any data store.
- Note the log retention window for your plan, since logged copies expire on their own schedule.
Make's limitations for regulated teams
Whatever its DPA says, a strict DPO can reject Make, because a hosted processor puts personal data inside a chain of sub-processors, transfers and logs that you can't audit yourself.
The DPA is a contract, and a contract doesn't change where the data physically sits or who can be compelled to disclose it.
Start with Make's published sub-processor list, because that is where the objection begins. The table below shows who touches the data and which questions a cautious reviewer would put to each entity.
| Entity | Location | Role | Transfer issue a strict DPO would raise |
|---|---|---|---|
| Amazon Web Services (AWS) | United States | Cloud hosting for the platform | Data leaves the EEA, so you need a valid mechanism (standard contractual clauses or the EU-US Data Privacy Framework) and a transfer impact assessment. |
| AWS | Germany | Cloud hosting for the platform | Data stays in the EEA, but the provider is US-headquartered, so reviewers ask about foreign government access. |
| AWS | Ireland | Cloud hosting for the platform | Same concern as Germany; regional hosting doesn't remove the parent-company question. |
| Chameleon | San Francisco, United States | In-app product guidance within the Make interface | A US recipient of user-level data, which needs its own transfer basis and a clear statement of what it receives. |
Second come the logs. Execution history records what moved through each scenario, so names, emails and payloads can persist there long after the workflow ran.
Third, every connected app adds a further processor relationship that Make's own paperwork can't cover. A DPO who adds these together can reasonably conclude that only self-hosting keeps the chain short enough to defend.
Easier to see it running than to read about it: set it up free, no card.
Why configuration causes more GDPR failures
Under GDPR Article 28, a signed DPA plus correct setup is accepted practice. Most failures sit on the customer's side, because Make's published terms cover its role as processor and not how you configure it.
The stakes are real. IBM's 2025 breach-cost study puts the average breach at $6.24m in Benelux, $4.14m in the UK, $4.03m in Germany, $3.73m in France and $3.44m in Italy, giving security leaders the business case they need to justify substantial prevention investment.
Audit these five mistakes in your own account first.
- Wrong region: running EU personal data in US1 instead of EU1 or EU2
- Unlimited log retention
- Personal data pasted into scenario names
- Connected apps with no DPA
- No deletion path
Three of these deserve a closer look, because a signed DPA covers them least.
Each connected app is a separate processor needing its own DPA, and Make's DPA binds Make, not the CRM or email tool a scenario writes to. One missing agreement breaks your chain even if Make's paperwork is flawless.
Names and emails that passed through a scenario stay in its execution logs. Retention is set by plan and by your settings, so check Make's pages and shorten it. Otherwise personal data outlives its purpose, which Article 5(1)(e) forbids.
You have one month to respond to an Article 17 request, which means processing backlogs consume your response deadline. If nobody knows where a person's data sits across logs, connected apps and data stores, you'll miss that deadline however good the platform is.
The objection wins outright where policy forbids any hosted processor. No DPA changes that, and self-hosting is then the only route. It would fail if Make's DPA or sub-processor list lacked the controls above.
When self-hosting or another platform fits, including Activepieces
Stay on Make if its DPA and sub-processor list hold up and your team can maintain the configuration. Move to another hosted vendor or to self-hosting only when residency, control or audit requirements exceed what a processor relationship can give you.
Options compared on residency, control and effort
The table below sets the three realistic routes side by side, so you can see where responsibility shifts from the vendor to your own team.
Read it as a map of who carries the burden. The cells state what each route can offer, and any row you adopt still needs checking against that vendor's own trust and pricing pages.
| Make with DPA | Another hosted vendor | Self-hosting (Activepieces) | |
|---|---|---|---|
| Who hosts | Make | The vendor | You |
| Region control | Set by your plan and zone choice | Varies by vendor | Wherever you deploy |
| Certifications stated | Listed on Make's trust pages | Varies by vendor | Activepieces states SOC 2 Type II for its own services; your environment's certifications are your own |
| Audit logs | Per plan | Varies by vendor | Available in Activepieces |
| SSO | Per plan | Varies by vendor | SSO and SCIM available in Activepieces |
| Air-gap | No | No | Yes |
| Cost basis | Subscription | Subscription | Infrastructure and staff time, plus any enterprise licence |
What the table shows is that hosting moves residency from a contractual promise to a technical fact, and the price is operational work. Staying on Make is the Its running cost is documented, and it remains defensible when the DPA is sound.
Self-hosted approach for data control
If the data stays inside your network, no third-party processor ever receives it. Activepieces has an MIT-licensed core, so a security team can read the code that would sit inside that network before it approves anything, rather than relying on a vendor's description of it.
Teams that can't accept any external processing can run it air-gapped. Those who would rather not operate it can use the managed cloud in an EU or US region.
Expect a review to lean on what the platform states: SOC 2 Type II, SSO and SCIM, custom role-based access control and audit logs. Those matter in a review because they let you show who can edit a flow and who ran it.
The air-gapped build is not a cut-down edition: the enterprise list there, including release management, matches the managed cloud pinned to an EU or US region, and MoneyGram and Moneypenny run Activepieces in production.
A security team that rules out every hosted processor therefore gives up none of those controls, though Activepieces makes no HIPAA certification, BAA or ISO certificate claim here, so don't assume one.
Self-hosting also moves the burden to you: patching, backups, retention and the security of every connected app become your responsibility.
The enterprise directories (packages/ee/) sit under a separate commercial licence from the MIT core, so confirm which parts you would run, and ask for the security documents and enterprise pricing at https://www.activepieces.com/sales before you commit.
Verify Make's security through six questions
Treat Make the same way: on Monday, work through six requests, starting with the signed DPA, and file the answers where an auditor can find them, so delays on one request compress your timeline for others.
Each maps to an obligation that falls on you as controller, which is where most audit findings land.
- Get the signed DPA. Article 28 GDPR requires a written processor contract, so an unsigned or unlocated DPA is a finding on its own.
- Confirm the region (EU1, EU2 or US1) for your organisation in the account settings. If your data sits in US1, you need a documented transfer basis under Chapter V.
- Read the sub-processor list in Make's trust centre. Your records of processing must reflect those parties, so note who they are and where they operate.
- Set execution retention. Stored execution data can hold personal data long after a scenario has run, which conflicts with storage limitation in Article 5(1)(e).
- Test the deletion path. Create a record, delete it at the source, then check that it's gone from execution logs and from connected apps. Article 17 requests fail in this chain, not in the contract, which means the weakness is operational, not legal.
- Confirm the SSO plan. Check which plan includes it, and whether leavers lose access through your identity provider or only by hand. Article 32 expects access control you can demonstrate.
Is Make.com GDPR compliant? Make can be used in a GDPR-compliant way, but that covers its conduct as a processor only. Your lawful basis, retention settings and connected apps remain your responsibility as controller.
Does Make store data in the EU? It can, if your organisation is on an EU region. Check the zone shown in your account rather than assuming, and remember that connected apps store data wherever their own vendors do.
Do I need a DPA with Make? Yes. Article 28 requires a binding contract whenever a processor handles personal data for you, so obtain the signed copy and keep it with your processing records.
Can I use Make with special-category data? Only after a documented assessment. Article 9 data, such as health records, needs a valid condition and a stricter review of retention, sub-processors and access. If that review fails, keep that data out of the scenarios.
