We are setting up a self-hosted n8n instance on AWS EKS (queue mode) to handle workflows that may process PHI via an encrypted DNA file. We have put together a plan for HIPAA compliance and wanted to sanity-check it with the community,
Other bits in the setup: Redis, PSQL (or, Amazon RDS as that’s HIPAA-compliant already)
Key measures in planning so far:
Infrastructure Security
EKS in a private VPC, private subnets only.
Network Policies restricting pod-to-pod traffic.
All storage (EBS, Secrets, backups) encrypted with KMS.
TLS enforced at ingress with strong ciphers.
IAM Roles for Service Accounts (least privilege).
n8n Hardening
MFA + strong passwords for all accounts.
Telemetry disabled, API access locked down.
Execution data pruning to avoid PHI in logs/history, via environment variables.
Secrets stored in AWS Secrets Manager.
Custom nodes can be developed, but seems like they will not be required if we are self-hosting will all the necessary security measures?
Workflow Design
De-identify PHI early in the flow.
Avoid logging PHI or persisting in non-essential nodes.
Secure webhooks with tokens/HMAC.
No real PHI in non-prod environments.
Procedural
Signed BAA with AWS.
Written policies for access, incident response, backups, and audits.
Encrypted backups, tested DR plan.
Question:
If we follow all of the above, and ensure all PHI is either processed in a fully HIPAA-compliant environment or de-identified early, would this be sufficient for HIPAA compliance from an n8n deployment perspective?
Any gaps you’d point out, especially from those who’ve gone through HIPAA audits with n8n?
Note: We are not asking for legal advice, just looking for technical and architectural feedback from those with HIPAA experience.
Workflow HLD
The workflow will look something like this, it’s a high-level template at this point
Not legal advice and I am not a HIPAA professional at all (though we work with clients who need this in Los Angeles and other areas). I ran a perplexity AI prompt with your info above and questions and got this. Hope it helps. Me and my team are also diving into HIPAA as well for our clients. The following is from perplexity and is not me specifically:
Technical & Architectural HIPAA Review: n8n on AWS EKS
Your detailed plan demonstrates strong alignment with HIPAA technical safeguards and healthcare security best practices for self-hosted n8n on AWS EKS. Below are key areas of validation, plus a few targeted recommendations and common gaps observed in HIPAA-focused audits involving n8n.
Validation of Your Current Measures
Infrastructure Security
Deployment in a private VPC with private subnets is ideal. Restrictive network policies, encrypted storage, and KMS use meet HIPAA’s required technical safeguards.
TLS enforcement and least-privilege IAM for service accounts address data-in-transit and access control.
Application Hardening
MFA, strong passwords, disabling telemetry, and locking APIs address authentication and minimize data exposure vectors.
Execution data pruning is crucial; ensure that environment variable retention/purge settings are validated and tested, especially after n8n updates.
Storing secrets in AWS Secrets Manager is compliant and highly recommended.
Workflow Design
Early de-identification of PHI and avoidance of logging PHI are core requirements; secure webhooks with tokens/HMAC are best practices and meet security standards.
Prohibiting real PHI in non-prod environments is essential.
Procedural
Signed BAA with AWS, documented security policies, encrypted backups, and routinely tested DR procedures address HIPAA’s administrative and physical safeguard requirements.
Potential Gaps & Recommendations
1. Audit Logging & Monitoring
Ensure all relevant events are logged: n8n must generate audit logs for authentication events, access requests, changes to workflows, and integration activities. Validate that sensitive actions carried out via custom or built-in nodes are tracked.
Centralized log management: Use AWS CloudWatch or a SIEM to aggregate and monitor logs. This supports incident detection and investigation.
Log retention and protection: Set a clear retention policy (minimum six years is common) and protect logs from unauthorized deletion or modification.
2. Database (PSQL/Amazon RDS) Configuration
Enable RDS-level auditing: Use Amazon RDS support for audit logs to capture queries, access, and privilege changes.
Encryption: Confirm all data at rest and in transit (RDS to n8n and internal communications) is encrypted.
3. Redis
Encrypt data-in-transit: Ensure Redis traffic uses TLS. Redis isn’t HIPAA-eligible by default—ensure it is configured for authentication and encryption.
Isolation: Limit access to Redis via security groups/VPC policies.
4. Data Flow & Third-Party Integrations
External Integrations: All third-party API connections/nodes should be HIPAA-compliant and covered by BAAs.
Custom Nodes: If you add custom nodes later, conduct security/code reviews and ensure they follow least privilege principles (especially for PHI handling and logging).
5. PHI Data Minimization & Scrubbing
Review workflow storage: Double-check that no PHI ends up in n8n execution logs, error logs, or workflow histories. n8n updates occasionally alter logging behavior—test after upgrades.
6. Backup & Disaster Recovery
Tested Recovery: Regularly test backup restoration, ensuring data integrity and documentation of DR routines.
Backup encryption: All backups (including EBS snapshots, RDS backups) should be encrypted.
7. User & Role Management
Centralized identity management: If possible, integrate n8n authentication with SSO/IdP for better tracking and easier offboarding.
Periodic access reviews: Audit user access to n8n and cloud resources at least quarterly.
8. Security Patch Management
Patch cadence: n8n and supporting containers/images must be patched promptly for CVEs. Automate vulnerability scans where possible.
9. Incident Response
Practice your IR plan: Simulate security events that might impact n8n (e.g., credential compromise, misconfiguration).
Notification procedures: Ensure incident reporting follows your policy and HIPAA requirements for breach notification.
Summary Table: Common Audit Gaps in n8n HIPAA Deployments
Area
Risk/Gaps
Recommendation
Audit Logging
Insufficient logs, logs not protected
Use CloudWatch/SIEM, clear retention
Redis
No TLS/auth, exposed endpoints
Enable TLS, restrict access
Database/RDS
Unencrypted traffic, no audit logs
Encrypt, enable RDS audit logs
Workflow Logs
PHI leaks due to default settings
Test/prune, verify after upgrades
User Access
Orphaned accounts, poor tracking
Tie to SSO, regular access review
Third-party Integrations
No BAA/insecure APIs
Only use HIPAA-compliant APIs/nodes
Patching
Outdated n8n/images
Regular vulnerability scans, patching
Overall: Your architectural and procedural measures demonstrate a robust approach to HIPAA compliance with n8n on AWS EKS. The most common gaps relate to logging, third-party components (like Redis), and details of workflow configuration (especially logging behaviors). Regular review, testing, and following AWS/n8n updates closely will reduce risk and better withstand audit scrutiny.
If you address the above, you’ll be well-positioned—not just for compliance, but for efficient and scalable operations in a regulated environment. Always coordinate with your compliance team for ongoing monitoring and improvements.
—
Hope that helps, still recommend to talk to legal and other professionals as well.
Just going through this a bit (page 62 is where I believe there is more details on how information should be processed), seems that from part 164 they have some info and details on privacy of PHI and how to address it from a technical standpoint. Once again I’m not a legal or HIPAA professional.
I would just add (sorry if I missed it somewhere):
protection of the public facing services, both request sanity as well as to the level of DDOS protection. In addition, limit the sources that can interact with your system (if it’s only a handful system that should call the webhook/UI Limit it to those).
Use anomaly detection. Both on system infra level as well as user functionality etc level.
Use IaC as a baseline to avoid mistakes and to easily check if you have deviations / configuration drift.
