Is Make HIPAA Compliant?
You're mid-build on a healthcare app, you need to wire up some automation, and Make looks perfect: cheap, flexible, a polished security page full of badges. So you ask the obvious question. Is Make HIPAA compliant?
No. Make, formerly Integromat, will not sign a Business Associate Agreement, and HIPAA requires one from any vendor that touches PHI on your behalf. That single fact settles it, no matter how good the encryption looks.
This post covers why: the real certifications Make holds and what they actually prove, why a security audit is not the same as HIPAA eligibility, the PHI quietly sitting in Make's execution logs, and what to use instead if you need to automate workflows that handle patient data.
Is Make HIPAA compliant?
No. Make (formerly Integromat) is not HIPAA compliant because it will not sign a Business Associate Agreement, which HIPAA requires from any vendor that processes PHI, and its execution logs retain the data each scenario processes for 30 days with no BAA covering it. Its SOC 2 and ISO 27001 certifications attest to security but are not the legal instrument HIPAA requires. For PHI workflows, switch to a BAA-signing platform like Keragon, Microsoft Power Automate, or Workato, or build core automation natively on a HIPAA-ready platform like Specode.
Key Takeaways:
- Make won't sign a BAA, so it can't legally handle PHI. HIPAA requires a Business Associate Agreement from any vendor that processes patient data, and Make doesn't sign one. No level of security maturity substitutes for that signature.
- Security certifications are not HIPAA compliance. Make's SOC 2 and ISO 27001 certifications are real, independently audited security controls. They are not the legal agreement HIPAA requires, and a SOC 2 audit was never designed to verify HIPAA compliance.
- Make's execution logs are the hidden PHI risk. Every scenario run is logged for 30 days by default, including the data each module processed and the payloads from failed steps. Any PHI in those logs sits there uncovered by a BAA, which is itself a HIPAA violation.
- Compliant alternatives exist, or you can skip the middleware. Keragon, Microsoft Power Automate, and Workato all sign BAAs and support healthcare workflows. If you're building on Specode, core clinical-event automation is native, so there's no separate automation tool to vet.
Make's security certifications are real, and they are not the question
Make's security page is genuinely reassuring, and that's exactly the trap. Give the certifications their due before you draw the line.
Make holds real security credentials. SOC 2 Type II and SOC 3 audits, GDPR adherence across the platform, ISO 27001 certification for its Enterprise platform specifically, AES-256 encryption at rest with AWS KMS handling the keys, TLS 1.2 and 1.3 in transit. (If you're still typing "is Integromat HIPAA compliant" into Google, that's the same platform under its old name, and the answer doesn't change.) By any reasonable measure, this is a mature security posture.
Look closer at each one. SOC 2 Type II and SOC 3 are AICPA attestations: an independent auditor confirms the security controls operate as described. ISO 27001 certifies an information-security management system. Encryption is encryption. All real maturity signals, and none of them the legal instrument HIPAA requires.
A vendor can run excellent, independently audited security and still not be HIPAA compliant. A SOC 2 audit was never built to verify HIPAA compliance; the two answer different questions. Security certification tells you the controls work. HIPAA asks who is legally accountable when PHI flows through a vendor's systems, and that accountability comes from one signed document. That makes the real question simple, and it's the one the next section answers: will Make sign a BAA?
The same wall shows up across other strong-security tools. Is Airtable HIPAA Compliant? is the same story: it clears its audits and still isn't HIPAA compliant, for the identical reason.
Why SOC 2 doesn't equal HIPAA: the BAA requirement
One requirement decides this, and it's the one thing Make's security page can't give you: a signature on a BAA.
HIPAA needs a signed BAA, and Make won't sign one
HIPAA requires a signed BAA from any vendor that creates, receives, maintains, or transmits ePHI on a covered entity's behalf. (Our BAA explainer has the full definition if you want it.)
Make's answer is no, and it's still no as of June 2026. A Make community champion confirmed in November 2025 that the company is gathering demand for HIPAA but won't sign individual BAAs, with HIPAA logged as an open feature request rather than a delivered one. There's no Make HIPAA BAA to sign today.
"It's just passing through" is not how HIPAA works
Founders assume the conduit exception saves them: Make only moves data between two systems that are already compliant, so why would it need its own BAA? Because that exception is narrow. It covers transmission-only services, like an ISP, where storage is temporary and incidental to moving the data.
The moment a service stores or processes ePHI, it's a business associate, even if it never decrypts a byte. Holland & Hart's health-law team makes the point that the exception is routinely misapplied, and when in doubt you sign a BAA. The same logic runs through every PHI-handling vendor in your chain, which is why HIPAA compliant payment processing turns on the same question.
That's the core of the Make healthcare automation HIPAA problem: Make becomes a business associate the instant PHI enters a scenario, and it won't sign the agreement that role requires.
Where the PHI actually sits: Make's execution logs
This is where the conduit theory falls apart. Make stores what it processes. Every scenario run is logged, and that history holds:
- the data bundles each module passed along
- every module's input and output
- the full payload from any step that failed
By default it stays in your execution history for 30 days. So PHI that flows through a Make scenario gets written into those logs, where it sits for a month with no BAA covering it, readable to anyone with account access.
The implication is blunt: maintaining ePHI in a service that won't sign a BAA is itself a HIPAA violation, no matter how clean the vendor's certifications look. Make users have already flagged this, asking for a way to purge personal data from execution logs on their own schedule. The control isn't there yet.
HIPAA-compliant alternatives to Make for healthcare automation
There's no setting that makes Make compliant. The fix is a different tool, and choosing one comes down to a single yes/no question: will it sign a BAA?
The one question that filters every option
A HIPAA-fit automation tool clears one bar: it signs a BAA and supports HIPAA-aligned controls like encryption, role-based access, and audit logging. Anything that won't sign a BAA is out for PHI work, and that includes both Make and Zapier.
The platforms that sign a BAA
Three platforms sign a BAA and are genuinely built for healthcare work. The two that don't are in the table for contrast.
Keragon is the cleanest HIPAA compliant Make alternative for most healthcare teams. It's purpose-built for the industry and signs a BAA on every paid plan, with entry pricing around $99/mo (confirm current rates). Power Automate makes sense if your team already lives in Microsoft 365, where the BAA comes through Microsoft's Product Terms; pricing depends on your enterprise agreement. Workato is the enterprise pick when you're moving real volume or need a native HL7 connector, with pricing handled through their sales team.
If you're weighing Keragon vs Make healthcare automation specifically, the matrix makes the call: same category of tool, but only one will sign the agreement HIPAA requires.
One caveat for engineering-led teams: n8n, self-hosted, can be made HIPAA-compliant if you run it inside HIPAA-audited hosting and own the compliance configuration yourself. That's a genuine option if you've got the DevOps muscle to run and document it, but for a founder who just wants working automation, it's more project than purchase.
If you're building on Specode, this is already handled
If you're building your app on Specode, this whole question mostly disappears for core workflows. The platform's workflow engine handles clinical-event automation natively: appointment scheduling, patient intake and onboarding, notifications and messaging, outbound SMS through the Twilio skill, and custom workflows you define in plain language. The automation lives inside the same HIPAA-ready stack as the rest of your app, so for core workflows there's no separate tool to vet and no second BAA to chase.
How Specode can help
You came here asking is Make.com HIPAA compliant. Where Specode fits now depends on where you are.
Still choosing your stack? Build on Specode. The core automation is native and the platform is HIPAA-ready out of the box, so there's no middleware to bolt on for core workflows.
Specode's scan, fix, verify loop for HIPAA compliance: connect code, scan for gaps, fix in AI Coder, re-verify, then human readiness review before shipping.
Already built on Make? Run the free Specode Vibe Code Audit on your code. The agent flags the HIPAA gaps and helps you fix them in the AI Coder, with a team review before you go live. A scan won't replace a formal HIPAA audit, but it's the fastest way to see where you stand.
Frequently asked questions
No. Make doesn't sign Business Associate Agreements, so it can't be used for workflows that handle PHI, regardless of its SOC 2 or ISO 27001 certifications.
No, and that's still true in 2026. Make is gathering demand for HIPAA but won't sign individual BAAs, and lists HIPAA as an open feature request.
No. Without a BAA, any PHI in a Make scenario is unprotected, including the data sitting in execution logs, and using Make this way is a HIPAA violation.
No. SOC 2 attests to security controls; it isn't the legal BAA HIPAA requires. Security maturity and HIPAA eligibility are two different things.
Keragon (purpose-built, BAA on all paid plans), Microsoft Power Automate (BAA via Microsoft Product Terms), or Workato (enterprise BAA). If you're building on Specode, core automation is already native.
