How security automation supports HIPAA security incident procedures
A covered entity or business associate that runs thin on staff and tooling still has to meet 45 CFR 164.308(a)(6), which requires policies and procedures to address security incidents. Automation can identify, triage, contain and document incidents, and it can write the record as the work happens instead of reconstructing it afterward. It does not make an organization compliant on its own. The rule still requires a written process, people who own it, and evidence that the process runs. The required implementation specification, response and reporting, asks for three things: identifying and responding to suspected or known incidents, mitigating harmful effects of known incidents to the extent practicable, and documenting incidents and their outcomes. Automation can carry out much of that work, but the decisions about scope and mitigation stay with people.
The definition matters for scope. Under 45 CFR 164.304, a *security incident* is the attempted or successful unauthorized access, use, disclosure, modification or destruction of information, or interference with system operations in an information system. The word attempted means failed logins, blocked scans and rejected sessions fall inside the definition, so alert volume will be far higher than the number of confirmed events. Playbooks should separate suspected from known incidents and record the decision that moved an alert between them. For practical reference, NIST SP 800-66 Rev. 2 (section 5.1.6) lists four key activities: set goals for incident response, build a response team or equivalent mechanism, write policies for responding to and reporting incidents, and feed post-incident analysis back into updates. Those activities give a useful checklist for what a SOAR case record should hold.
Two points set expectations. First, there is no HIPAA certification. HHS states that no Security Rule standard requires certifying compliance and does not endorse private certifications, so any vendor or partner claim of certified HIPAA status should be questioned. Second, the HHS Office for Civil Rights enforces the rule through complaint investigations, compliance reviews and audits, and it may examine how an organization handled incidents. The January 2025 proposed rule would add a requirement for written incident response plans tested at least once every 12 months, but it is not final as of October 2026, so confirm its status with counsel before building it into a control. Ask your implementation partner to show the case record, approval points and retention settings that would be produced for an OCR review.
Mapping the incident procedure requirements to automated functions
This table maps each HIPAA incident procedure requirement to the automated workflow it needs and the Shuffle, Wazuh or identity configuration that produces it. Read each row as a question to answer with your own environment: what does the workflow do, and what record does it leave behind for an auditor or OCR investigator?
| Requirement | What the automated workflow must do | How to configure it |
|---|---|---|
| 164.308(a)(6)(i) policies and procedures | Keep a written security incident procedure that names triggers, owners and the playbooks that implement each step, and version it with the workflows. | Store the policy and playbook index in version control. Tag each Shuffle workflow with the policy section it implements and export workflow JSON on every change. |
| 164.308(a)(6)(ii) identify and respond | Ingest alerts from Wazuh, classify suspected versus known incidents and open a case with timestamps for each action. | Forward Wazuh alerts to Shuffle through a webhook or indexer query trigger. Use a Shuffle branch on rule level and group to route alerts to a triage playbook. |
| 164.308(a)(6)(ii) mitigate to the extent practicable | Run containment steps such as disabling an account or isolating a host only where the playbook has an approval gate, and log who approved each step. | Use Shuffle user input actions for approval. Call identity provider APIs to suspend sessions, and record the outcome in the case. Confirm that each action is reversible before enabling it. |
| 164.308(a)(6)(ii) document incidents and outcomes | Write each incident record with the facts, actions taken, affected systems, outcome and the decision on whether PHI was involved. | Have the final Shuffle step write to your case system or an append-only store. Keep Wazuh alert IDs and Shuffle execution IDs in the record so the trail can be traced. |
| 164.304 security incident definition | Treat attempted as well as successful unauthorized access, use, disclosure, modification or destruction, and interference with system operations as in scope for the workflow. | Include failed authentication bursts, blocked access attempts and configuration changes in Wazuh rule sets. Tune Shuffle filters so attempts are recorded even when no containment runs. |
| 164.314(a)(2)(i)(C) business associate reporting | Capture reports from business associates, including breaches of unsecured PHI, into the same incident record and track the notice to the covered entity. | Create a Shuffle intake workflow with a form or API endpoint for partner reports. Store contract notice deadlines as fields so the case shows when the notice was received. |
| NIST SP 800-66 Rev. 2 post-incident analysis | Trigger a lessons-learned task after closure and feed recurring causes into rule and playbook updates. | Add a closure step that creates a review task and records changed Wazuh rules or Shuffle workflow versions. Confirm the review cadence with your compliance lead. |
| Proposed 12-month response plan test (90 FR 898) | Not required today. Proposed rule text would require a written plan reviewed and tested at least every 12 months, so schedule tabletop runs of the playbooks now to keep evidence ready. | Run a scheduled Shuffle test workflow against a non-production Wazuh agent and record the result. Check the Federal Register for any final rule before treating this as a requirement. |
Which open-source platforms fit each step of the incident workflow
An incident record under 45 CFR 164.308(a)(6) depends on detection, enrichment, response and documentation working together. The platforms below each cover one step, and the Shuffle playbooks are where those steps are tied into a single, timestamped record.
Wazuh for endpoint and log detection
Wazuh combines agents on endpoints, a server that applies decoders and rules, and an indexer that stores alerts. Its core repository is GPL-2.0, and the dashboard includes a prebuilt HIPAA compliance view. Check that agents cover every system that stores or transmits ePHI, including Linux, Windows and macOS hosts, and that the retention period on the indexer matches your documentation obligations. Confirm which alert fields the HIPAA view reports, since that view supports review rather than a compliance determination.
Suricata and Zeek for network detection
Suricata raises network intrusion alerts under GPL-2.0, while Zeek produces structured connection and protocol logs under a BSD-style license. Together they show what crossed the boundary around ePHI systems and support scoping after an alert. Placement matters: sensors must see traffic to clinical systems, remote access and cloud egress, and encrypted traffic limits what inspection can show. Confirm sensor coverage with your network team before relying on these sources in playbooks.
Shuffle as the SOAR layer
Shuffle is the AGPL-3.0 platform that runs the playbooks, calling Wazuh, network tools and identity systems through apps and recording each action. It can run as a single Docker Compose server, in Docker Swarm, in a hybrid with a local Orborus worker, or on Kubernetes with Helm. Licensing is based on app runs, so estimate how many executed actions your playbooks will produce per month. Ask a partner how the workflow history will be exported as the record of the incident.
MISP or OpenCTI for enrichment
MISP and OpenCTI hold indicators, actor profiles and sharing rules that Shuffle queries when an alert arrives, so an analyst can see whether an address or file hash is already known. MISP is AGPL-3.0, and OpenCTI ships a Community Edition under Apache-2.0 alongside an Enterprise Edition under its own license. Check what the shared intelligence reveals about your patient data before sending indicators to any external community, and confirm which edition includes the features your playbooks need.
Keycloak, authentik or ZITADEL for identity
Playbooks that disable accounts, force reauthentication or check a login need a central identity provider that gives each person a unique user identity and enforces MFA. Keycloak is Apache-2.0, authentik is MIT outside its enterprise directory, and ZITADEL is AGPL-3.0 with passkey support. Confirm that your identity provider can issue the authentication events Shuffle needs through OpenID Connect or SAML, and that shared or service accounts cannot bypass it.
OpenBao for app credentials
Shuffle stores credentials for connected tools, such as EDR and identity APIs, encrypted in OpenSearch using a secret named by SHUFFLE_ENCRYPTION_MODIFIER. Losing or changing that value breaks every saved app authentication, so it must be backed up and access to it restricted. OpenBao, licensed under MPL-2.0, is one option for holding such secrets and for rotating the tokens that playbooks use. Confirm with your partner how the modifier is stored, rotated and restored during a recovery test.
Confirm the Vault license before choosing
HashiCorp Vault from version 1.15.0 is licensed under the Business Source License 1.1 with IBM named as licensor, which the Open Source Initiative does not list as open source. Teams that assumed Vault was open source should confirm the license terms with their legal team and the vendor before adding it to the architecture. This matters most when the secrets platform will be a long-term dependency of the incident workflow.
How automated playbooks produce the incident record as the work happens
The incident record HIPAA asks for under 45 CFR 164.308(a)(6) should be a byproduct of the playbook run, not a document written afterward. In a self-hosted setup, a case system (for example, a self-hosted case manager that Shuffle writes to through its API) receives the alert, and every step from detection through closure adds a timestamped entry. A typical flow runs from detection in the SIEM or intrusion detection source, through enrichment (asset owner, user, prior alerts, threat intelligence lookups), to a containment decision, then a notification step to the covered entity or business associate contact, and finally closure with post-incident notes. Each Shuffle workflow execution is itself a logged run, so the record can show which workflow ran, which app actions executed, and what they returned. Confirm with your vendor and in a test environment exactly which execution fields are retained, for how long, and whether they can be exported to your case system and your log archive, because retention is a configuration choice you own.
Automation does not decide what is a security incident. Under 45 CFR 164.304, the definition covers attempted as well as successful unauthorized access, use, disclosure, modification or destruction of information, and interference with system operations. Your workforce, privacy and security officers must set the triage criteria that playbooks encode, and the playbook should label an alert as a suspected incident for human review rather than closing it on its own. Write the approval gates into the workflow: a destructive containment step, such as isolating an endpoint that supports clinical care, should record who approved it, when and on what evidence. Keep the decision on whether an event is reportable to the covered entity or business associate with the people accountable under your incident response plan, and treat the automated notification as a record of that decision, not as the decision itself.
Before go-live, test the record end to end. Run a tabletop-style scenario in a non-production tenant and check that the case contains the alert source, the enrichment output, each approval, the containment action with its result, the notification sent and the post-incident note. Ask your implementation partner how workflow versions are tracked, so you can show which logic handled a given incident months later. Plan for the mitigation duty as well: the record should show what was done to reduce harm to the extent practicable, not only that an alert was processed. Document any playbook step you chose not to automate and why, since an auditor or the HHS Office for Civil Rights will ask how your procedures were applied in practice.
Evidence auditors and OCR ask for after an incident
This table maps each piece of evidence an auditor or OCR investigator is likely to request after a security incident to the component that produces it in a self-hosted stack, and what to confirm about retention. Read each row as a question to put to your implementation partner: where the record lives, who can change it, and how long it is kept. The main takeaway is that the HIPAA incident record is only as good as the logs and approvals behind it, so retention and access to the SOAR itself need explicit decisions.
| Evidence | Produced by | What to confirm about retention |
|---|---|---|
| Incident logs and timestamps | Wazuh alerts and archived events in the Wazuh indexer, plus network sensor logs where deployed | Index retention period, whether archives are kept separately from hot storage, and clock synchronization across sources |
| Alert and triage decisions | Case system record linked to the originating Wazuh alert, with analyst notes and classification fields | Whether case edits are versioned, and how long closed cases and their attachments remain readable |
| Containment and mitigation actions | Shuffle execution history for each workflow run, showing actions taken on endpoints, accounts or firewalls | Retention of execution history in the OpenSearch store and whether it is exported to a longer-term archive |
| Approvals for destructive actions | Approval step records in the Shuffle workflow or the case system, with approver identity and timestamp | Whether approval records can be altered by workflow editors, and where the approval evidence is stored |
| Business associate notices | Case record and correspondence log referencing the contract, sent through the agreed channel | Which notice templates and contact records are kept, and how long business associate contracts require records to be held |
| Post-incident analysis and plan updates | Lessons-learned entries in the case system and version history of playbooks and the written response plan | Where the written plan and its review dates are stored, and who signs off on changes |
| Access and audit records for the SOAR itself | Identity provider logs for SSO sign-ins, Shuffle user and role change records, and credential access records for connected apps | Retention of identity provider logs and Shuffle audit data, and whether they are forwarded to the central log store |
| Credential and key handling for connected tools | Secrets store audit logs for app credentials, plus the Shuffle encryption key record kept outside the platform | Who can read the encryption key, how key rotation is logged, and how long secrets audit logs are held |
How the work differs for covered entities and business associates
A covered entity, meaning a health plan, health care clearinghouse or covered health care provider, must identify and respond to suspected or known security incidents across its own systems that hold electronic protected health information. Under 45 CFR 164.304, a security incident includes attempted unauthorized access, use, disclosure, modification or destruction, and interference with system operations. Automation therefore has to triage far more than confirmed breaches.
- Attempts count: Repeated failed logins to an EHR or patient portal, blocked scans and malware detections can all meet the definition, so the playbook should record them even when no harm occurred.
- Mitigation to the extent practicable: Disabling an account or isolating an endpoint should follow a documented decision path. The playbook should record why each containment step was or was not taken.
- Notification paths: Duties to individuals, regulators and others are set outside the Security Rule text reviewed here. Confirm with counsel which obligations apply, then make sure the case record holds the affected systems, record counts and timestamps those obligations need.
- Hosting boundaries: A single-server Shuffle deployment on Docker Compose or a Kubernetes deployment with Helm charts can both run these workflows. Confirm that the orchestration host sits under the same access controls as the ePHI systems it touches.
Check that every alert source feeding the playbooks maps to a system listed in the entity's own risk analysis.
A business associate has a narrower but contractual duty. Under 45 CFR 164.314(a)(2)(i)(C), business associate contracts must require the business associate to report security incidents it becomes aware of to the covered entity, including breaches of unsecured PHI under 164.410. The trigger is awareness, and the reporting terms live in each contract, so automation has to track both.
- Awareness starts the clock: Because the duty depends on when the business associate becomes aware, the playbook should timestamp first detection, triage and each escalation step.
- Routing per customer: A business associate serving several covered entities needs routing that sends each notice to the right contact, using the right record set for that customer.
- Contract terms to confirm: Reporting windows, required content, formats and who decides breach status vary by agreement. Those terms are not stated in this section, so review each contract before building the notification step.
- Subcontractor flow-down: If subcontractors handle ePHI, confirm that the same reporting duties flow down to them and that they can send alerts into the business associate's workflow.
- Credential custody: If the business associate runs Shuffle for customers, saved app credentials are encrypted in OpenSearch with AES-256 using the SHUFFLE_ENCRYPTION_MODIFIER secret. Losing or changing that secret breaks all saved app authentications, so back it up under the same custody rules as the customer data.
Before go-live, compare each contract's reporting clause with the notification step and its link to 164.410.
Both roles must document security incidents and their outcomes under 45 CFR 164.308(a)(6)(ii). The documentation requirement applies whether the incident is minor or major, so the case record is the core evidence. Automated playbooks can capture much of that record as the work happens, but the compliance lead still has to review it.
- Outcome fields in the case: Each case should hold detection source, triage decision, mitigation steps, owner and final outcome, so documentation does not depend on memory after the event.
- Lessons learned: NIST SP 800-66 Rev. 2 lists post-incident analysis as a key activity feeding updates to policies and procedures. Keep playbook versions and the change that followed each incident so an auditor can sample the trail.
- Testing cadence: A January 2025 proposed rule would require written incident response plans reviewed and tested at least once every 12 months. It was proposed, not final, as of October 2026, so confirm its status before treating the 12-month cycle as a requirement.
- Compliance dashboards: The Wazuh dashboard includes prebuilt HIPAA views. Those views help monitor the environment but do not replace the incident record.
Ask whether the case system can export records in a form the compliance lead can review without engineering help.
What tooling alone does not satisfy
A SOAR platform can produce the incident record as work happens, but the Security Rule still expects written policies, documented risk decisions, identity design and trained people. The cards below cover the gaps that sit outside the tool and the ones a reviewer will ask about first.
Written incident policies and response team
Section 164.308(a)(6) requires written policies and procedures that address security incidents, and the response and reporting specification asks for identification, mitigation and documentation. A playbook is not a policy. Check that a named response team, its authority to isolate systems, and its reporting path to the privacy and security officials are written down, approved and tied to the playbooks Shuffle runs. Confirm who approves automated containment actions before they are built.
Risk analysis and addressable decisions
Addressable implementation specifications require a documented assessment of whether each measure is reasonable and appropriate. If it is not adopted, the entity must document why and implement an equivalent alternative. Automation choices such as which logs feed the SOAR, how long evidence is kept, or whether containment runs without a human gate all need that record. Ask your partner to map each automated step to the specification it supports and to keep the justification with the playbook version.
Identity design behind unique user identification
The technical safeguards in 164.312 require unique user identification and person or entity authentication for systems that hold ePHI. A SOAR platform inherits these weaknesses. Shared service accounts in Shuffle, unmanaged app credentials or analysts logging in with generic accounts will make the incident record unreliable. Check how analysts authenticate to the SOAR (for example through an OpenID Connect provider), who is accountable for each automated action, and how the credential encryption key is backed up.
Staffing, on-call coverage and training
A playbook runs only when someone owns it. Automation reduces triage load but does not decide severity, approve a notification to affected individuals, or handle a case no playbook anticipated. Document who is on call, who maintains each playbook after a connected tool changes, and how analysts are trained on the incident procedure and on the tool. Ask for training records and a drill schedule as evidence, and confirm the staffing model with your own leadership before the design is fixed.
Proposed rule is not final
HHS proposed a major Security Rule revision in January 2025 that would require written incident response plans reviewed and tested every 12 months. As of October 2026 it has not been finalized, and the latest Unified Agenda projects final action for July 2027. Design the process to meet current requirements and to make a yearly review and test easy to add later, but do not treat the proposal as a current obligation. Confirm the status in the Federal Register before any audit or board report.
No tool certifies HIPAA compliance
HHS states that no Security Rule standard requires certification and that it does not endorse or recognize private certifications, which do not prevent a later finding of violation. No platform, open-source or commercial, makes a deployment HIPAA compliant. Evidence is what your organization can show OCR during a complaint investigation, compliance review or audit: policies, risk analysis, playbook versions, case records and training. Treat any vendor badge as a claim to verify, not as proof.
Questions buyers ask about HIPAA incident automation
Can open-source tools meet the HIPAA security incident procedure requirement?
Yes, the rule does not name products. Section 164.308(a)(6) requires written policies and procedures to identify and respond to suspected or known security incidents, mitigate harmful effects to the extent practicable, and document incidents and their outcomes. Open-source tools can produce that record, but the policies, the response team and the decisions about what counts as an incident remain the covered entity's responsibility. Wazuh can supply alerts and endpoint evidence, and Shuffle can run the triage, enrichment and documentation steps. Confirm that each tool's logging, retention and access controls meet your own risk analysis before you rely on it for the record.
Is there a HIPAA certification for security incident automation?
No. HHS states that no Security Rule standard requires an entity to certify compliance, and it does not endorse or recognize private certifications. Any vendor or partner claiming a HIPAA certification for a tool or service should be treated with caution. What you can ask for instead is evidence: documented playbooks, incident records, test results and the risk analysis that ties them together. Independent auditors and OCR review that evidence, and DeployOpen prepares systems, controls and evidence for assessments without issuing audit reports or certifications.
What drives the cost of a self-hosted HIPAA incident automation build?
Cost follows the work, not the license. The main components are platform setup on your infrastructure, playbook design and build, integrations with your identity provider, EHR, endpoint and logging tools, testing, and staff time for review and approvals. Shuffle's open-source edition includes all features, but its paid tiers differ in limits and support, and licensing is priced on app runs, meaning actions that actually execute in a workflow. Each alert that triggers several enrichment steps consumes more runs, so ask any quote to state the expected run volume, the edition assumed and whether worker infrastructure is included. Request a fixed-scope written proposal listing one-time and recurring items separately.
How long does an implementation take and what changes the timeline?
DeployOpen does not publish durations, and a timeline should follow from a written scope. The main variables are how many alert sources and systems are connected, how many playbooks are in scope, whether the environment is air-gapped, and how many approvals and change-control steps your organization requires for automated actions. Integrations with clinical systems usually take longer than cloud tools because they need testing windows. Ask the implementation partner to split the timeline into platform setup, playbook build, integration testing and handover, and to state which items depend on your teams.
What does the client need to provide before the work starts?
The partner needs your written incident response policy, the list of systems that store or transmit ePHI, current alert sources, identity provider details, a named owner for incident decisions and access to test environments. Business associate contracts should also be reviewed, because they must require reporting of security incidents to the covered entity under 45 CFR 164.314(a)(2)(i)(C). Shuffle stores saved app credentials encrypted with AES-256 using the SHUFFLE_ENCRYPTION_MODIFIER secret, so the client must decide who holds that secret and how it is backed up, since losing it breaks every saved app authentication. Agree on these inputs in the scope document.
Can our own team build and run this without a partner?
Yes, if you have engineers who can operate Docker or Kubernetes, manage an OpenSearch cluster, write Shuffle workflows and maintain connectors as vendor APIs change. Shuffle documents single-server, Docker Swarm, hybrid and Kubernetes deployments, and recommends several Orborus nodes and an OpenSearch cluster for high availability. The harder part is ongoing work: keeping playbooks tested, reviewing each change, and producing the incident documentation on schedule. Estimate the staff time for those tasks before deciding. A partner can take the build, the testing and the documentation, and retainers cover upgrades and continuous support.
How would the proposed 12-month incident response plan test change the work?
It would change the workload if finalized as proposed. The January 2025 proposed rule (90 FR 898) would require written security incident response plans to be reviewed and tested at least once every 12 months. It was not final as of October 2026, and the latest Unified Agenda lists it under Long-Term Actions with final action projected for July 2027. Until then, treat it as planning input. In practice, build the playbooks so each one has a test record, a version history and an owner, which makes an annual review straightforward if the requirement is adopted. Confirm the final text before committing budget to a fixed test cycle.
What do OCR audits look at for incident response?
OCR reviews compliance through complaint investigations, compliance reviews and audits. Its 2024 to 2025 HIPAA audits review 50 covered entities' and business associates' compliance with Security Rule provisions most relevant to hacking and ransomware. For incident procedures, expect reviewers to ask for the written policy, evidence that incidents were identified and responded to, records of mitigation and documentation of outcomes, and how post-incident analysis updated the procedures, as described in NIST SP 800-66 Rev. 2. Automated records help only if they are complete, retained and linked to a human decision. Ask your partner to show sample incident records before go-live.
How to phase the rollout without a big-bang cutover
Roll out HIPAA incident automation in stages rather than switching every alert source to Shuffle at once. Start with an inventory of alert sources and of the systems that hold ePHI, because the incident record under 45 CFR 164.308(a)(6) is only as complete as the list of places an incident can start. Map each source, such as Wazuh alerts from endpoints and servers, firewall syslog, identity provider sign-in events and EHR audit logs, to the ePHI systems it protects, and record which ones your team cannot yet see. That inventory becomes the scope document for the first phase and the baseline you will test against later.
Next, build one or two high-volume playbooks, typically the ones that handle the alerts your analysts already triage most often, such as a malware alert on a workstation or a failed-login spike on an EHR account. Keep the first playbooks read-only: they should gather context, open a case and write each step to the record, without isolating hosts or disabling accounts. Add enrichment next, then approval gates for any containment step that could affect patient care or access to ePHI, such as isolating a clinical device or revoking a clinician's access. Confirm with your clinical and operations leads which actions need a human decision before they run, and write those decisions into the playbook logic. Each stage should go live only after it has run in parallel with the manual process long enough for your team to compare results.
Before the procedure is treated as operational, run a tabletop exercise against the written incident response procedure, using the playbooks as they actually behave. Walk through a scenario that involves an ePHI system, check that the automated record captures identification, mitigation and documentation, and confirm who is notified if a business associate reports an incident. Plan for high availability early, because Shuffle's documentation recommends more than one Orborus node so workflows keep running if one fails, and an OpenSearch cluster for the document store. Confirm the sizing, hosting and the cost of these components with your implementation partner, and agree the scope, deliverables and timelines in writing before the first phase begins.
How DeployOpen scopes, builds and supports HIPAA incident automation
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including the Shuffle playbooks that produce HIPAA incident records. Engagements start from a written scope that sets out which alert sources, playbooks and evidence fields are covered before any build work begins.
How we scope
- Inventory the alert sources, including Wazuh detections, identity events and business associate reports, that feed the incident workflow
- Agree in writing which incident types, playbooks and evidence fields the fixed-scope engagement covers
- Confirm where ePHI sits, which systems are in the workflow and who approves containment steps
How we build
- Deploy Shuffle on the client's infrastructure, including its OpenSearch document store and worker nodes
- Build playbooks that enrich alerts, log each step with timestamps and record decisions in the incident file
- Test workflows against agreed scenarios in a non-production environment before any production change
How we hand over
- Document each playbook, its triggers, approval gates and the evidence it writes to the record
- Provide the runbook covering credential storage, encryption secret custody and backup of the Shuffle environment
- Walk the incident response team through the workflows and the documentation they must keep current
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover
- Review playbooks when connected tools change, when Shuffle or Wazuh releases ship, and after real incidents
- Confirm with your compliance and legal advisers which records your policies require, since DeployOpen prepares evidence but does not issue audits or certifications
