Intercom alternative for HIPAA and healthcare support

Intercom offers HIPAA support on its Expert plan. This page explains how self-hosting Chatwoot or Zammad keeps protected health information in your environment and what the HIPAA Security Rule still requires of you.

Book a callTalk to us
On this page

Can a self-hosted Intercom alternative support HIPAA compliance for healthcare support teams?

Self-hosting Chatwoot or Zammad moves control of where patient-related messages live into your own environment, but it does not make your support desk HIPAA compliant on its own. The HIPAA Security Rule (45 CFR Part 164 Subpart C) applies to covered entities (health plans, health care clearinghouses and covered health care providers) and to their business associates, for all electronic protected health information (ePHI) they create, receive, maintain or transmit. Once a chat widget or inbox holds ePHI, the organization running it carries the safeguards, whichever software it chooses.

Two points shape the decision. First, there is no HIPAA certification. HHS states that no Security Rule standard requires certifying compliance, and private certifications do not stop HHS from later finding a violation, so any vendor claim of "HIPAA certified" should be treated with caution. Second, Intercom lists HIPAA support on its Expert plan. Confirm in your own contract whether that covers the specific products, channels and data your support team would use, and whether Intercom will sign a business associate agreement that meets the terms in 45 CFR 164.314(a)(2)(i).

If you self-host, the business associate contract question shifts. Your hosting provider, managed database operator or any support partner with access to ePHI may become a business associate, and each needs a contract with the flow-down and incident reporting terms that the rule requires. The Security Rule also expects documented risk analysis, unique user identification, automatic logoff, encryption and audit controls for every system that touches ePHI, and these must be designed and evidenced by your team. Ask your implementation partner for a written scope that names which of these controls they configure, which they only document, and which remain with your staff.

What the HIPAA Security Rule requires of a support tool

The Security Rule applies to covered entities and their business associates for every electronic protected health information record a support tool touches. The cards below cover who is in scope, how the safeguards are organized, which specifications are required and which are addressable, and what a vendor contract must say before a self-hosted tool is put in front of patients or their records.

Who the rule covers

The Security Rule binds covered entities, meaning health plans, health care clearinghouses and covered health care providers, and their business associates, for all electronic protected health information they create, receive, maintain or transmit. A support inbox that holds appointment questions, billing messages or clinical attachments is in scope even when the tool is only used by front-desk staff. Map every channel, including the chat widget, email and attachments, to the ePHI it may carry before choosing a deployment.

Eighteen standards across three safeguard types

Appendix A to Subpart C groups 18 standards into administrative, physical and technical safeguards, with 36 implementation specifications under them. For a support tool, the administrative controls cover access management and incident response, the physical controls cover the servers and backups, and the technical controls cover the application itself. Build a single matrix that names the owner and evidence for each specification so the support tool is not documented in isolation from the rest of the environment.

Fourteen required and twenty-two addressable

Of the 36 implementation specifications, 14 are required and 22 are addressable. Addressable does not mean optional: the entity must assess whether each one is reasonable and appropriate, implement it if so, and otherwise document why it was not implemented and what alternative control was used. Record that decision for each addressable item that touches the support tool, such as encryption at rest or automatic logoff, so the reasoning survives staff changes.

Seven technical safeguard specifications

The five technical safeguard standards in 45 CFR 164.312 contain seven implementation specifications. Unique user identification and emergency access procedures are required. Automatic logoff and both encryption specifications for data at rest and in transit are addressable. For a self-hosted Chatwoot or Zammad deployment, this means individual agent accounts with no shared logins, a tested break-glass path to the database and application, session timeouts for shared workstations, and documented encryption choices for the PostgreSQL database, Redis and attachments.

Business associate contract terms

Under 45 CFR 164.314(a)(2)(i), a business associate contract must require the vendor to comply with the Security Rule, flow the same terms down to any subcontractor that handles ePHI, and report security incidents, including breaches of unsecured PHI. Self-hosting shifts operations into your environment, but it does not remove the need for these terms if a vendor, integrator or hosting provider can reach ePHI during implementation, support or backups. Ask your counsel to confirm which parties in your deployment need an agreement.

No certification, only enforcement

HHS states that no Security Rule standard requires an entity to certify compliance, and that private certifications do not stop HHS from later finding a violation. Be cautious with any vendor or integrator that offers a HIPAA certificate as proof of readiness. The HHS Office for Civil Rights enforces the rule through complaints, compliance reviews and audits, so your evidence should be your own risk analysis, configuration records and access logs, which you should be able to produce on request.

Chatwoot or Zammad: which fits a healthcare support workflow

Chatwoot is the closer match when support starts with a website chat widget and messages arrive through email and other channels in one inbox. Its core code is released under the MIT Expat license, but the content of the enterprise/ directory is licensed separately under the license file in that directory, and third-party components keep their own licenses. Your legal team should review both before deployment. The Community Edition is listed at $0, while Premium Support at $19 per agent per month adds Captain AI, voice calls, custom branding, agent capacity, roles and permissions and priority support. Single sign-on with SAML and SLA policies is listed only in the Enterprise Edition at $99 per agent per month, so an SSO requirement changes the cost calculation.

  • Channels: The website live chat widget, email, and the social and messaging channels listed in the README are in one inbox, so confirm which of them your patient-facing workflow actually needs.
  • Licensing: The MIT Expat core and the separately licensed enterprise/ directory mean the license you deploy depends on which features you enable.
  • Paid tiers: Premium at $19 and Enterprise at $99 per agent per month are the listed prices, and they recur per agent.
  • Database and cache: Chatwoot supports only PostgreSQL and recommends Redis 7.0 or higher, so both services need backup, patching and monitoring.
  • Sizing: The requirements page recommends 4 cores and 4 GB of RAM for up to 10,000 conversations a day.

Confirm with Chatwoot which features your intake process depends on, especially SSO, SLA policies and audit logging, in the edition you plan to run.

Where Intercom's HIPAA support leaves the data and the risk with you

A vendor-hosted HIPAA offering moves infrastructure operation to the vendor, but it does not move the HIPAA obligations. Under 45 CFR 164.302, the Security Rule applies to covered entities and their business associates for all electronic protected health information they create, receive, maintain or transmit. If Intercom handles conversations that contain PHI on your behalf, the relationship has to be documented in a business associate contract under 45 CFR 164.314(a)(2)(i), which requires the vendor to comply with the Security Rule, flow the same terms down to any subcontractor that touches ePHI, and report security incidents to you. Request Intercom's signed BAA in writing and confirm which products, plans and features it covers, since a Expert plan listing does not by itself tell you that the Messenger, inbox, help center and any AI features are in scope.

Asking for a BAA is the start, not the end. Ask Intercom for its security documentation and for evidence of how it applies the Security Rule's administrative, physical and technical safeguards, including its data retention, subprocessor list, encryption settings and breach notification timelines. Note that HHS states there is no HIPAA certification, so any vendor badge or report is an input to your own risk assessment rather than proof of compliance. Keep the written answers in your compliance file, because the HHS Office for Civil Rights enforces the rule through complaints, compliance reviews and audits.

Under a vendor-hosted model, you still own the controls that sit inside your organization: unique user identification for every agent, role-based access so only the care or support team with a need to know sees a patient's conversation, automatic logoff, audit logging of who viewed or exported a record, and a documented emergency access procedure. Your incident response plan must also cover how you learn of a vendor incident and how you report a breach of unsecured PHI. If you move to self-hosted Chatwoot or Zammad, the vendor's contract obligations are replaced by controls you operate, so the same list becomes your own implementation and evidence work, and the cost of that work is covered in the cost section of this page.

How to deploy a self-hosted support platform under HIPAA safeguards

This sequence moves the support platform into an environment the organization controls, with each HIPAA Security Rule safeguard assigned to a named configuration or contract before any patient data is loaded.

  1. Scope which ePHI enters the inbox

    Compliance and support leads list the message types, attachments and channels that could carry electronic protected health information, such as website chat, email and uploaded records. They decide which of these are blocked, redacted or allowed, and document the decision. The step is done when the scope is signed off and every channel that will be connected to the platform has an owner and a stated purpose.

  2. Place the platform in a controlled environment

    The infrastructure team deploys Chatwoot or Zammad in the organization's own cloud account, data center or private network, with the database, Redis, file storage and any search index in the same boundary. Confirm in writing with any hosting or managed infrastructure provider that they will be bound by a business associate contract before they can touch ePHI. The step is done when a network diagram shows no ePHI path to a third-party service that has not signed that contract.

  3. Configure encryption in transit and at rest

    The platform team enforces TLS on the public widget, the admin interface and the reverse proxy, which Zammad supports through Nginx or Apache. They enable encryption for the PostgreSQL volumes, backup targets and attachment storage, and document the key management approach. Encryption is an addressable specification in the HIPAA technical safeguards, so the written decision on how it is implemented is the evidence. The step is done when a test scan confirms no plaintext listener and the key owner is named.

  4. Enforce unique user IDs through SAML or OIDC

    The identity team connects the platform to the organization's identity provider using SAML or OpenID Connect, which Zammad supports, and disables local accounts except for a break-glass administrator. Each agent gets one identity, and shared logins are removed. Unique user identification is a required implementation specification, so the export of active users matched against the directory is the check. The step is done when every agent signs in through the identity provider and no shared accounts remain.

  5. Set emergency access and automatic logoff

    The security team writes an emergency access procedure that names who can reach ePHI during an outage, where the credentials are held, and how access is revoked afterward. They then configure session timeouts so inactive agent sessions end automatically. Emergency access is required and automatic logoff is addressable, so both need a documented setting and a test. The step is done when a timed test shows an idle session closes and the emergency procedure has been walked through once by the people who would use it.

  6. Restrict database, attachment and logging access

    The platform team limits database and attachment storage access to the service accounts that need it, and removes administrator rights from agents who only answer tickets. They turn on audit logging for logins, role changes, exports and attachment downloads, and send those logs to a store that administrators cannot edit. Confirm that Elasticsearch, if used for attachment search, sits inside the same restricted boundary. The step is done when a test agent cannot read the database directly and each export or download appears in the log.

  7. Migrate history into a new instance and verify it

    Zammad includes migrators for Zendesk and Freshdesk, but migrations run all or nothing, work only on a new instance and accept one source system per migration. Zendesk CSV exports omit ticket comments and descriptions, so the team should use a JSON or XML export or the API and verify that comments and attachments arrived. Confirm the Zendesk API token is created by a full administrator and that differential runs are not supported. The step is done when a sample of tickets is checked against the source record field by field.

  8. Test restore and incident response before go-live

    The operations team restores a backup to a separate environment and confirms that conversations, attachments and user mappings return intact. The compliance lead runs a tabletop exercise on an ePHI disclosure, including the business associate reporting duty and the path to the covered entity's breach process. Keep the restore record and exercise notes as evidence. The step is done when the restore test passes, the tabletop has a written action list and the incident contacts are current.

Evidence a regulator or auditor will ask you for

OCR does not hand out a HIPAA certificate. It judges whether your documented safeguards exist, operate and are reviewed, so the evidence below is what you will need to produce after a complaint, compliance review or audit. Each card covers one record set you should be able to pull from a self-hosted Chatwoot or Zammad environment.

Risk analysis documentation

The Security Rule expects a current, accurate assessment of the risks to ePHI in every system that touches it, including the support tool. For a self-hosted helpdesk, record where conversation content, attachments and contact data are stored, which staff and integrations can reach them, and how the database, Redis cache, search index and backups are protected. Date each review and record the decisions taken. Confirm that the support tool sits inside the scope of your enterprise-wide risk analysis, not in a separate tool register.

Access reviews and unique user IDs

Each agent needs a unique user identity, and the technical safeguards require unique user identification as a required specification. Keep a dated record of who holds agent, administrator and inbox-manager roles in Chatwoot or Zammad, and review it on a schedule. Check that departing staff are removed from the helpdesk and from any single sign-on provider the tool uses. Confirm that SAML or OpenID Connect login is enforced for staff accounts where your policy requires it.

Audit logs and activity records

You will need to show who viewed or changed a patient-related conversation and when. Confirm which events each product records, such as conversation views, assignments, exports and admin changes, and where those logs are stored and how long they are kept. Ship them to a log store you control, and test that you can retrieve a specific conversation's history for a given date range. Do not assume the default retention matches your policy until you have checked it.

Encryption configuration records

Encryption in transit and at rest are both addressable specifications, so you must either implement them or document why an equivalent measure fits your environment. Keep records of TLS certificates and cipher settings on the widget, inbox and admin endpoints, disk or volume encryption on the PostgreSQL and file storage hosts, and encryption of backup copies. Store the key management procedure next to these records.

Backup and restore test records

A backup that has never been restored is weak evidence. Keep the backup schedule, the location and encryption of each copy, and dated restore tests that rebuild the database, attachments and search index. Record how long a restore took and what data was missing. For Chatwoot, PostgreSQL and file storage must be restored together so that conversations and attachments stay consistent. Zammad's search index can be rebuilt, but record that step too.

Incident response and business associate records

Keep a written incident response plan, incident logs and the steps taken to determine whether an event was a breach of unsecured PHI. Business associate contracts under 45 CFR 164.314 must require the vendor to comply with the Security Rule, flow terms down to subcontractors that handle ePHI and report security incidents to you. Keep signed agreements for each hosting provider, managed service partner and implementation firm that can reach the environment. The support tool itself is generally not a business associate of yours when you run it on infrastructure you control, but confirm this with counsel for your own setup.

Questions healthcare teams ask before self-hosting a support tool

Is Chatwoot or Zammad HIPAA certified?

Neither is HIPAA certified, and no certification exists for HIPAA. HHS states in its 2003 FAQ that no Security Rule standard requires an entity to certify compliance, and that private certifications do not stop HHS from later finding a violation. What matters is whether your organization, with its hosting provider and any business associates, implements the Security Rule safeguards in 45 CFR Part 164 Subpart C for the ePHI the tool handles. The HHS Office for Civil Rights enforces the rule through complaints, compliance reviews and audits. Ask any vendor for documentation of their own security practices, but do not accept a 'HIPAA certified' label as proof of compliance for your deployment.

What does a self-hosted Chatwoot or Zammad deployment cost?

Software cost is zero for the Community Edition of Chatwoot and for self-hosted Zammad, which has no license fee. The recurring costs are infrastructure, staff time and optional support. Chatwoot's published requirements recommend at least 4 CPU cores and 4 GB of RAM for up to 10,000 conversations a day, and 8 cores and 8 GB for up to 20,000, plus at least 1 GB of swap, so hosting size follows your volume. Chatwoot's self-hosted plans list Premium Support at $19 per agent per month and Enterprise Edition at $99 per agent per month. Zammad's self-hosted support subscriptions are Business at 2,999 EUR per year, Enterprise at 5,999 EUR per year and Corporation at 9,999 EUR per year, according to its pricing page. Assessment, configuration and migration are one-time costs, and their size depends on your scope, not on the product's list price. Ask any implementation partner for a written scope that separates these components.

How long does a self-hosted healthcare support deployment take?

The duration depends on your scope, so confirm it in a written scope before work starts. The main drivers are the number of channels and inboxes, how many systems hold ePHI that the tool must connect to, the migration source and volume, and how much documentation and evidence your compliance team needs. Zammad's built-in migrators work only on a new instance and handle one source system per migration, and Zendesk migrations need an API token from a full administrator and are subject to rate limits set by the Zendesk plan. Those constraints alone can shape the schedule. DeployOpen fixes scope, deliverables and timelines in writing before work starts, so ask for the timeline as part of that written scope rather than relying on a general estimate.

Can our IT team run Chatwoot or Zammad without outside help?

A team with Linux, PostgreSQL and Redis operations experience can run either tool, but it needs those skills on an ongoing basis. Chatwoot requires Ruby 3.2 or later, recommends Node.js 20.x, supports only PostgreSQL as its database, recommends Redis 7.0 or higher, and lists Ubuntu 20.04 as its only officially supported Linux distribution. Zammad stores content in PostgreSQL 15 or newer, requires Redis 7 or newer, and uses Elasticsearch for search and reporting, which it describes as optional but strongly recommended. Multi-instance Zammad deployments need Memcached. Check whether your staff can handle upgrades, backups, patching and monitoring for each component, and whether your on-call rota covers them. If not, a retainer for ongoing support and upgrades is one option to price against internal headcount.

What does our organization need to provide for a HIPAA-aligned deployment?

Your organization carries most of the compliance work, because the Security Rule applies to covered entities and their business associates for all ePHI they create, receive, maintain or transmit. Expect to provide the following:

  • A business associate agreement with any vendor, host or partner that can access ePHI, which must require Security Rule compliance and flow the same terms down to subcontractors, as described in 45 CFR 164.314.
  • A data map showing which conversations, attachments and contact records contain ePHI and where they are stored.
  • An access design that gives each person a unique user identity and limits access to the minimum their role needs, with a documented emergency access procedure.
  • Decisions on encryption, automatic logoff and audit logging, which the technical safeguards in 45 CFR 164.312 treat as addressable or required.

NIST SP 800-66 Rev. 2 offers a practical reference for mapping these controls to the Security Rule.

Does self-hosting remove our HIPAA obligations?

No. Self-hosting moves where the data lives, but the Security Rule still applies to your organization for every ePHI it creates, receives, maintains or transmits. Keeping the tool inside your own environment gives you control over storage, network paths and access, which simplifies some risk decisions. It does not replace risk analysis, workforce training, incident response, audit logging or the business associate terms you need with anyone who touches the data. Penalties are assessed per violation under the inflation-adjusted HIPAA civil money penalty table, which ranges from $145 to $2,190,294 per violation for penalties assessed on or after 28 January 2026, with a calendar-year cap of $2,190,294 according to 45 CFR 102.3. Treat the tool as one part of your overall risk program.

What should we check before choosing between Chatwoot and Zammad for healthcare?

Start with the channels your patients and staff actually use, because that decides whether the tool needs live chat and social channels or mainly email and tickets. Chatwoot covers website live chat, email, several messaging channels and a help center portal in one inbox. Zammad centers on email and ticketing with SAML and OpenID Connect login, which often fits identity models already in place. Check the licenses too: Chatwoot's code is MIT-licensed except the enterprise/ directory, which has its own license, and Zammad is licensed under AGPLv3. Confirm which features you need, such as SSO with SAML or SLA policies, since some sit in paid self-hosted tiers. Then test both against a sample of your real workflows in a non-production environment, and document the results for your compliance file.

How DeployOpen deploys a healthcare support platform under HIPAA safeguards

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own cloud accounts, data centers or air-gapped networks. For a healthcare support platform, that means the chat, inbox and help center stay where the organization controls access to any protected health information, with the HIPAA Security Rule safeguards built into the design from the start.

How we scope

  • Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
  • Scope maps which channels, patient-facing data and staff roles touch ePHI, and where each one is hosted.
  • We confirm with your compliance lead which business associate terms and vendor contracts apply to the deployment.

How we build

  • We install Chatwoot or Zammad with PostgreSQL, Redis and the reverse proxy inside your environment.
  • We configure unique user identification, automatic logoff, encryption in transit and at rest, and role-based access.
  • We test access controls, audit logging and backups against the scoped safeguards before any live traffic is routed.

How we hand over

  • You receive documentation covering architecture, configuration, access procedures and the evidence each safeguard produces.
  • We provide runbooks for emergency access, incident reporting and restoring from backup, and walk through them with your team.
  • Handover includes a record of what DeployOpen configured, so your assessors and auditors can review it independently.

How we support

  • Ongoing support, upgrades and continuous testing are available as retainers after handover.
  • Upgrades to Chatwoot or Zammad releases are planned, tested in a staging copy and then applied on your schedule.
  • DeployOpen prepares systems, controls and evidence for compliance assessments, while independent auditors and certification bodies issue any reports.

Sources and further reading

Related

Talk to our team.

Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.

  • 30-minute call: free, with no obligation.
  • NDA on request: we can sign before you share details.
  • Clear next steps: a scope and plan after the call.
Book a callhello@deployopen.com