Security, plainly.

Is Enmantle HIPAA compliant?

Enmantle is built to support HIPAA obligations: encryption in transit and at rest, role-based access control, passkey (WebAuthn) identity, audit logging, and de-identified AI processing. Enmantle signs a Business Associate Agreement with every agency customer before protected health information is loaded. No software vendor can be "HIPAA certified"; there is no such certification, so we describe the controls instead.

HIPAA places obligations on covered entities (your agency) and on their business associates (Enmantle, and in turn our hosting providers). Our Business Associate Agreement sets out what we do with protected health information (PHI), how we protect it, how we report incidents, and what happens to the data when the contract ends. Ask for the current BAA and this page's questionnaire answers at hello@enmantle.com.

Where is the data hosted?

The Enmantle platform runs on Heroku (a Salesforce company) in Heroku's United States region, on the Common Runtime with Heroku Postgres (PostgreSQL 17, Essential tier). Uploaded documents and photos are stored in Amazon S3 in the United States. No customer data is stored or processed outside the United States.

A plain statement about the hosting layer. Heroku offers HIPAA-covered infrastructure only on its Shield tier (Shield Private Spaces, Shield dynos and Shield Postgres). Enmantle's production environment is on Heroku's Common Runtime, which Salesforce does not cover under a Business Associate Agreement. That means Enmantle's own controls, not the hosting provider's contract, carry the HIPAA obligations for infrastructure: the database is encrypted at rest, staff identifiers are additionally encrypted at the field level inside the application, access to production is restricted to named engineers and logged, and no PHI leaves the platform for AI processing without de-identification. We are evaluating a move to a BAA-covered hosting tier; this page will state the date and the provider when that happens.

How is data encrypted?

In transit, every connection uses TLS 1.2 or newer, with HTTP Strict Transport Security on the public site. At rest, Heroku Postgres encrypts the database volume, and the application encrypts staff personal identifiers (for example government identifiers and bank details used for payroll) a second time with AES-256-GCM before they are written, so a database read alone does not expose them.

Encryption keys for the field-level layer are held as environment secrets on the platform, separate from the database, and are never written to logs. Backups inherit the database's encryption.

Who can see what?

Access is role-based. Each agency workspace is isolated; users are created by the agency's own administrators (there is no public sign-up), and every user holds a role such as Super Admin, Admin, Manager or Staff. Custom access roles narrow a role further, down to specific modules. Sign-in supports passkeys (Face ID, fingerprint or a security key) through WebAuthn, and administrators can require them.

Direct support professionals see the clients and shifts assigned to them. Managers see their locations. Super Admins see the whole workspace, including the audit log. Enmantle staff access a customer workspace only for support, with the customer's knowledge, and that access is logged like any other.

What is logged?

The platform keeps an audit log of sign-ins, record changes and administrative actions, with who, what and when. Super Admins can review it inside the product; it is read-only. Time-entry corrections keep their own change history with the requester, approver and reason.

An export of the audit log is on the roadmap; today it is reviewed in-app. Retention follows the agency's obligations for the underlying records, which for EVV and care documentation are typically multi-year; see the privacy policy.

How is AI used, and does PHI leave the platform?

Three narrow uses, each designed so that identifiable health information does not leave the platform: voice notes are transcribed to text (audio is discarded after transcription); incident narratives are de-identified inside the platform before an AI model helps tidy the wording; and receipts and certificates are read by optical character recognition. The AI never invents content; the staff member remains the author of record.

The models are accessed through commercial APIs (OpenAI for transcription, Anthropic for drafting help, Google Cloud Vision for document reading) whose terms exclude use of API content for model training. Agencies can turn AI drafting off in their workspace settings.

Who are the subprocessors?

Heroku (Salesforce) for hosting and the database, Amazon Web Services for file storage, OpenAI, Anthropic and Google Cloud for the AI uses above, and Resend for transactional email. The website separately uses Microsoft Clarity, Formspree, Cal.com and Google Fonts. The full table, with what each vendor receives, is on the subprocessors page.

We add a subprocessor only after reviewing its security terms, and we update that page with the date of any change.

Who owns the data, and how do we get it out?

The agency owns its data. Records can be exported as CSV on request at any time, with no export fees and no lock-in on termination. On termination we provide a full export and then delete the agency's data, subject to the retention obligations that apply to EVV and care records.

This is the same commitment made on the pricing page and in the Help Center; if you find the three disagreeing, tell us.

Are there backups, and how are they tested?

Heroku Postgres keeps continuous physical backups of the production database, and a nightly logical backup is scheduled in addition. Backups are encrypted like the database and can be restored to a fresh database for testing without touching production.

What happens in a security incident?

We investigate, contain, and notify affected agencies without unreasonable delay and within the timelines HIPAA sets for business associates (no later than 60 days after discovery, and in practice far sooner), with what happened, what data was involved, and what we are doing about it. Agencies then meet their own notification duties with our help.

To report a vulnerability or a suspected incident, email hello@enmantle.com with "Security" in the subject line, as published in /.well-known/security.txt. Please do not include PHI in the report; we will arrange a secure channel if details are needed. We do not currently run a bug-bounty programme, and we do not take legal action against good-faith research that respects users' data.

Has Enmantle completed a SOC 2 audit?

No. Enmantle has not completed a SOC 2 or ISO 27001 audit. We publish this page, the subprocessor list and the privacy policy instead, and we answer security questionnaires directly. If a certification becomes a condition of a contract, we will say so here when we start it.