Open source SOAR for healthcare

Open source SOAR for healthcare starts with containment that protects patient care

A healthcare security lead needs automation that can contain a threat without stopping care. Alerts arrive around the clock, a suspicious workstation on a ward or a infusion pump's management host may not be isolatable without affecting clinical work, and the HIPAA Security Rule expects documented incident procedures whether or not a staff member is available to write them. A self-hosted SOAR build can meet those needs, but only if containment is designed around clinical impact from the start. Generic playbooks that isolate any host showing a high-severity alert will eventually cut off a device a clinician depends on. For a self-hosted build, that means each containment action needs a clinical owner, a documented fallback such as blocking outbound traffic or disabling a single account instead of the whole endpoint, and an approval gate for devices that cannot go offline. Shuffle can orchestrate these steps, Wazuh can supply detection and endpoint telemetry, and a self-hosted identity provider can govern EHR access. The rest of this page covers the requirements behind those choices.

Start by inventorying which devices and systems are clinically critical, and confirm with clinical engineering and biomedical teams which of them can be isolated, for how long, and under whose authority. Vendor support terms for medical devices often limit what endpoint agents or security changes are permitted, so confirm those restrictions in writing before any automated response is scoped. Wazuh's offline installation guide and offline vulnerability repository option may matter for segments with restricted connectivity, and that should be checked against the environment rather than assumed. The HIPAA technical safeguards in 45 CFR 164.312 cover unique user identification, audit controls and person or entity authentication, so the identity and logging design should be settled before playbooks are written. Ask your implementation partner how each playbook records the decision to contain, who approved it, and what clinical notification was sent, because that record is what a breach assessment will examine.

Which HIPAA and related requirements shape healthcare playbooks

This table maps the HIPAA technical safeguards, the business associate flow-down, the incident procedure reference, and two related regimes to specific playbook design choices. Read each row as a requirement, what it means for how a SOAR workflow is built and logged, and what an assessor or regulator will look for. The main takeaway is that every automated action on ePHI systems needs its own audit record, and that isolation steps touching clinical devices need a human gate.

Requirement	What it asks for	What it means for playbook design
45 CFR 164.312(a)(2)(i) unique user identification	Assign a unique name or number to each user and track activity by that identity	Playbook service accounts must be named and scoped, and every automated disable or reset must record the affected individual account, not a shared login
45 CFR 164.312(b) audit controls	Record and examine activity in systems that contain ePHI	Log each automated action, its trigger, inputs, approver and result in the case record so the audit trail includes SOAR activity
45 CFR 164.312(d) person or entity authentication	Verify that a person or entity seeking access is who it claims to be	Confirm that automated responses which change identity or access use authenticated API credentials, and that credential rotation is itself a logged step
45 CFR 164.312(e) transmission security	Guard ePHI sent over networks against unauthorized access	Enrichment and forensic collection moving ePHI or logs must use encrypted channels, and connector configurations should be reviewed as part of change control
45 CFR 164.314(a)(2)(i) business associate contracts	Business associates must comply with the Security Rule, flow terms to subcontractors and report security incidents, including breaches of unsecured PHI	Where a managed SOC or hosting provider runs playbooks touching ePHI, define which notifications the playbook raises to the covered entity and record each one with a timestamp
45 CFR 164.308(a)(6) security incident procedures	Identify, respond to, mitigate and document security incidents	Structure each playbook around identify, contain, mitigate and document stages, with the incident record created at the first trigger rather than reconstructed later
FTC Safeguards Rule, 16 CFR 314.4(c) (where clinics hold financial data)	Require multi-factor authentication for information system access, encryption of customer information, and monitoring and logging of authorized user activity	Playbooks that disable or re-enable accounts for billing or payment systems should verify MFA enrollment status and log authorized user activity in those systems as well
GDPR Articles 32 and 34 (EU patient data)	Appropriate security measures, including MFA and need-to-know access, and communication of personal data breaches to affected people where required	Gate isolation of clinical systems behind a clinical owner's approval, and tie breach notification steps to documented access scope so the team can show who could reach each record

How ransomware containment changes when devices support patient care

General wards and administrative workstations are the closest match to a standard enterprise environment, so they carry the most automation. Shuffle can act on the identity and endpoint signals that ransomware usually produces, such as a sudden spike in file renames or a compromised account authenticating from an unusual location. The main risk is not the containment step itself but the clinician who loses access to the record they need at the bedside. Illustrative example: a nurse's workstation shows encryption activity at 02:00, and the playbook should quarantine that single endpoint, not the whole ward VLAN.

Account disablement: Automate suspension of a compromised user identity in the identity provider after a confirmed high-confidence alert, and route a notice to the user's manager and the on-call security analyst.
Network quarantine of office endpoints: Automate isolation of a single administrative workstation through the endpoint agent or switch policy, leaving shared ward systems reachable.
Blocking indicators: Automate blocking of known malicious domains and file hashes at the proxy, DNS and endpoint layers from threat intelligence feeds.
Escalation for shared devices: Require a human decision before isolating any workstation used for medication administration or handover, since the same device may be the only route to a patient chart.

Confirm with your security and nursing leads which workstations are shared or used at the bedside, and tag them in your asset inventory before any quarantine rule is enabled.

Which open-source platforms fit a healthcare SOAR build

A healthcare SOAR build usually combines an orchestration layer, endpoint and log detection, network sensing and an identity layer that controls access to clinical systems. Each platform below covers one role, and the fit depends on whether the clinical environment allows agents, sensors and inbound connections on the networks involved.

Shuffle as the orchestration layer

Shuffle runs the playbooks that pull alerts from detection tools, enrich them and trigger containment steps. It is licensed under AGPL-3.0 and can run on your own servers with Docker Compose, Docker Swarm or Kubernetes. For healthcare, check how the AGPL-3.0 terms apply if you modify and offer Shuffle to users, and confirm which features sit in the open-source edition versus paid tiers before you design playbooks around them. Playbook approvals for device isolation should be built into the workflow, not left to the analyst's judgment alone.

Wazuh for endpoint and log detection

Wazuh collects telemetry from clinical workstations and servers through agents, applies decoders and rules, and stores alerts in its indexer. Its dashboard includes prebuilt views for HIPAA, which gives your compliance reviewers a starting point rather than a finished report. Wazuh also documents offline installation and an offline vulnerability repository, which matter for networks that cannot reach the internet. Confirm agent support for every medical device OS and vendor-managed endpoint, since many clinical devices cannot run a standard agent.

Security Onion, Suricata and Zeek for network sensing

Suricata inspects traffic for intrusion signatures, and Zeek records structured network metadata that investigators use to reconstruct events. Security Onion bundles both with Elastic and osquery in one platform, which can simplify sensor deployment. Sensor placement is the main constraint in healthcare, because clinical networks often include segments with legacy devices, medical imaging and shared VLANs that cannot be mirrored without disrupting care. Plan sensor placement with clinical engineering before you promise network coverage to the security team.

Keycloak for identity and SSO

Keycloak supports OpenID Connect, SAML 2.0, LDAP and Active Directory federation and clustering, so it can front clinical applications, portals and the Shuffle console with one sign-on. Access to EHR and workflow tools is where the HIPAA unique user identification and person authentication requirements apply, so SSO design should map each clinical role to a named account. Test break-glass access for emergency situations, because a sign-on outage during an incident can block both clinicians and responders.

authentik or ZITADEL as alternatives

authentik is MIT-licensed except its enterprise directory, and ZITADEL is AGPL-3.0 with SAML 2.0, SCIM and passkey support. Either can serve as the identity provider if your team prefers its administration model or its provisioning features over Keycloak. The choice matters most where SCIM provisioning must reach EHR or identity governance tools, because connector support differs between products. Confirm which feature set your edition includes before you commit to a product for clinical sign-on.

EHR connectors and licensing

Most EHR platforms expose APIs, interfaces and SSO options that a SOAR playbook would need to call, such as disabling an account or retrieving an access log. Connector availability, supported interfaces and any vendor license terms for automated access vary by EHR product and contract, so none of these assumptions should be treated as settled. Ask the EHR vendor which APIs and audit logs are available for automation and whether automated actions are permitted under the license. Build the connector only after that answer is in writing.

Deploying Shuffle inside a hospital network without opening inbound ports

Shuffle documents four deployment architectures, and for a hospital the choice comes down to how many sites the platform must survive and whether the backend can be reached from outside the clinical network. A single server running Docker Compose is the simplest starting point for a pilot against one data center or one set of non-clinical segments, but it is a single point of failure, so it should not carry production ransomware playbooks on its own. Docker Swarm or Kubernetes with Helm charts suits multi-site resilience, where the backend, frontend and worker capacity are spread across hosts. The hybrid model is often the strongest fit for a hospital: the backend stays in the organization's own infrastructure, while a local Orborus instance polls for jobs and starts the workers, and Shuffle documents that this local Orborus needs no inbound firewall ports. Confirm with the vendor and your network team exactly which outbound destinations, ports and proxy settings the chosen model requires before any firewall change request is written.

For production, the Shuffle configuration docs recommend an OpenSearch cluster rather than a single node, optional Memcached for a shared cache, and NFS for shared files when several backends run side by side. They also recommend more than one Orborus node so that workflows keep running if one fails, which matters when an isolation playbook must complete during an outage. Ask your implementation partner to show the failover test: stop one Orborus node during a live test workflow, confirm the run completes, and record the result in the change record. Clinical teams should also agree in advance whether a playbook that cannot reach a device, such as an endpoint on a medical device segment, halts, retries or escalates to a person. Key custody is the item most often left out of the runbook. Shuffle encrypts saved app credentials and API keys in OpenSearch with AES-256 using the SHUFFLE_ENCRYPTION_MODIFIER secret, and the docs warn that losing or changing it breaks every saved app authentication. In a hospital this means a restore from backup could leave isolation and ticketing integrations silently broken during an active incident. Store the value in a secured vault with named custodians, record its location in the disaster recovery runbook, and test a restore into a non-production instance to confirm the credentials still authenticate.

How a healthcare SOAR rollout moves from one playbook to clinical scale

The sequence starts with agreed clinical rules and ends with automated containment that clinical engineering has tested and that the organization can change under a documented process. Each phase produces a artifact the next phase depends on, so the rollout expands only when the previous output is accepted.

Agree scope and clinical governance rules
The security team, CMIO or clinical informatics lead, clinical engineering, privacy and the EHR application owner agree which device classes, clinical units and systems are in scope, and which ones are excluded from automated action. The output is a written governance agreement that names who may approve isolation of a device, how long a clinician can be without a device before escalation, and which systems are never isolated automatically. Timing depends on the agreed scope.
Map assets, EHR and directory identities
The team builds an inventory that links endpoints, medical devices, EHR servers, interface engines and directory accounts to their owners, clinical location and business criticality. Identity sources such as Active Directory, the EHR's own user store and any federated sign-on are mapped so that an account action can be traced to the correct user. The output is a reviewed asset and identity map that clinical engineering signs off, along with a list of systems that must not receive automated commands.
Run a detection-only pilot
Shuffle workflows ingest alerts from the chosen detection sources, such as Wazuh, and enrich them with asset and identity context, but take no containment action. Analysts compare the playbook's classification with their own decisions and record false positives, missing context and alerts that needed clinical input. The output is a measured list of playbook changes and a go or no-go decision on automated response, made by the governance group rather than by the integration team alone.
Gate containment in a non-clinical segment
Containment actions such as disabling an account, blocking an address or quarantining an endpoint are enabled first in a segment with no patient-facing devices, such as administrative workstations. Every destructive step requires a named approver in Shuffle before it runs, and each action writes an audit record. The output is evidence that the approval gate, rollback step and audit trail behave as designed under the agreed change process.
Test playbooks with clinical engineering
Clinical engineering and the security team run tabletop and technical tests against representative clinical device classes and the EHR integration path, using test data and scheduled windows agreed in advance. The test confirms what happens to monitoring, interface messages and downstream services when an action fires, and the team checks which steps need a manual alternative. The output is a signed test record that states which playbooks are approved for each clinical unit and which remain manual.
Enable production with documented change control
Approved playbooks move to production in stages, each tied to a clinical unit listed in the governance agreement. Shuffle configuration, app versions and credentials are kept under change control, and the process records who approved each change and when. The output is a production runbook with rollback steps, an on-call escalation path for clinical staff, and a schedule for reviewing playbooks as devices, EHR versions and directory structures change.
Review playbooks and expand scope
After production runs, the team reviews incident records, approval times, false isolations and any patient-care escalations against the governance agreement. Scope expands to additional units only when the review shows the controls working and the governance group accepts the result. The output is a dated review record and an updated scope statement that the next expansion depends on.

What breach assessment support looks like and what it cannot replace

What can a SOAR case record show for a HIPAA breach assessment?

A SOAR case record can show the timeline of an incident, the systems and accounts involved, the alerts that fired, the enrichment gathered and the containment steps taken, each with a timestamp. Shuffle writes execution history for each workflow run, so the sequence of automated and analyst actions is reconstructable. What the record cannot do alone is decide whether ePHI was actually accessed or acquired. That determination needs the access logs, the data inventory and the investigation notes, which the case should link to rather than replace. Confirm with your privacy officer which fields the assessment template requires before designing the playbook output.

Which PHI-related details should a healthcare playbook capture?

A useful playbook records the affected systems and asset owners, the user accounts and devices involved, which EHR or record systems were in the access path, and the data categories the system stores, as recorded in your data inventory. It should also note whether the affected data was encrypted, since 45 CFR 164.312 addresses encryption as a technical safeguard with addressable specifications. Automated enrichment can tag a host as holding ePHI only if your asset inventory carries that label. Treat categories set by the playbook as hypotheses to verify, not as a finding that PHI was identified.

How does a business associate notify a covered entity under 164.314?

Under 45 CFR 164.314(a)(2)(i), the business associate contract must require the business associate to report security incidents, including breaches of unsecured PHI, to the covered entity. The contract terms, not the SOAR platform, set the notification path, so the playbook should route business associate incidents to a named contact and a clock that the contract defines. If your organization is the business associate, the playbook should produce a notification package from the case record and flag the contract's deadline and recipient. Have counsel confirm the exact contract wording before you build the routing.

Is there a HIPAA certification that a SOAR deployment can earn?

No. There is no HIPAA certification. HHS states that no Security Rule standard requires an entity to certify compliance, and that private certifications do not prevent HHS from later finding a violation. Any vendor or consultant claiming a HIPAA certification for a platform or service should be asked to explain what they mean. A self-hosted SOAR deployment can support evidence for the Security Rule standards, but it does not produce a certificate. Independent assessment frameworks such as HITRUST are a separate, voluntary choice.

How does HHS enforce the HIPAA Security Rule?

The HHS Office for Civil Rights enforces the Security Rule through complaints, compliance reviews and audits. A SOAR record does not change who investigates or how, but it can shorten the time your team needs to produce the documentation an investigator requests. Keep the case history, the playbook version that ran and the approval records together so an investigator sees the same account the team gave internally. Confirm the current enforcement posture with counsel, because the Security Rule revision proposed on 6 January 2025 has not been finalized.

Which decisions must stay with the covered entity and its counsel?

The covered entity and its counsel decide whether an incident is a reportable breach, what the risk assessment concluded, who must be notified, and what the notice says. Playbooks can prepare facts for those decisions but should not announce a conclusion. Build the playbook so that the breach determination step is a required human approval with a named owner, and so that the record notes the facts available at the time. Automated steps should never send patient or regulator notices without that approval.

What penalty exposure makes a complete incident record worth the effort?

For penalties assessed on or after 28 January 2026, 45 CFR 102.3 sets the inflation-adjusted HIPAA civil money penalty from $145 to $2,190,294 per violation, with a calendar-year cap of $2,190,294. The exposure depends on the facts, culpability and the penalty tier, so the figure is a ceiling, not an estimate. The practical lesson is that an incomplete record can make it harder to show what was known and when. Ask your counsel how the record should be preserved and retained.

Can our own team build the breach evidence workflow without a partner?

Often yes, if you already run a SOC, have Shuffle experience and have a privacy officer who can define the assessment fields. The work splits into playbook engineering, integration with the EHR and identity systems, approval design and retention setup. Partner help is most useful for the integration and testing work, which is where mistakes happen. Confirm internal capacity for ongoing maintenance, since connectors and playbooks need updating as systems change. A partner can be scoped in writing for specific deliverables, such as the playbooks, the evidence templates or the testing plan.

Which evidence a healthcare auditor or regulator asks for and which component produces it

This table maps the evidence a HIPAA assessor, HHS Office for Civil Rights reviewer or customer security team typically asks for to the component that produces it in a self-hosted SOAR and identity stack. Read each row as a question to answer before an audit, and use the last column to confirm where the record lives and who can change it. The main takeaway is that most evidence is generated as a by-product of automation, but only if logging, retention and approvals are designed in from the start.

Evidence requested	Where it is produced	What to confirm before an assessment
Audit log of automated Shuffle actions	Shuffle workflow execution history, recording each action, input, output and triggering alert	Execution history retention period, whether logs export to the SIEM, and who can delete workflow runs
Approval records for device isolation	Shuffle approval step outputs, linked to the clinical owner's decision and the change ticket	That approvals are captured in the execution record, not only in chat or email
Unique user identification for SOAR and EHR accounts	Keycloak or authentik user records, with one identity per person and no shared service logins	Whether shared accounts exist for break-glass or bridge access and how they are logged
Access reviews for SOAR and EHR accounts	Identity provider role and group exports, reviewed on a documented cycle	Review owner, cadence, and evidence that removed or changed access was actioned
Authentication and session events	Keycloak or authentik event logs for sign-ins, failures, MFA challenges and administrative changes	Event types enabled, log forwarding to Wazuh, and retention matching your HIPAA documentation policy
Alerts and host audit data behind a containment decision	Wazuh alert records and agent telemetry from the affected endpoints	Agent coverage for clinical devices, time synchronization, and whether alerts were preserved before isolation
Credential handling records for connected tools	Shuffle encrypted credential store, with rotation tracked in the secrets platform and change tickets	Encryption key custody, rotation dates, and that the modifier secret is backed up under controlled access
Incident timeline and breach assessment inputs	Shuffle case or workflow timestamps combined with Wazuh and identity logs, reviewed by privacy and legal staff	Clock source consistency across tools, and who makes the breach determination (the assessment is not a tool output)
Change tickets for playbook and app updates	Version-controlled workflow exports and the ticketing system record of each approved change	That production playbooks changed only through tested, approved releases

How identity and EHR integrations change the playbook design

Identity events, not endpoint alerts, should drive a large share of healthcare playbook design, because the French case shows where access control failed. The CNIL fined Hopital Prive de la Loire EUR 500,000 under GDPR Articles 32 and 34 on 3 September 2026. It found that external access to the patient record system lacked a VPN and multi-factor authentication, and that access control ignored the care team's need to know. A SOAR playbook can address both gaps. Start with a trigger on sign-in events from your identity provider, such as Keycloak or another OpenID Connect or SAML source, and flag EHR logins from outside approved networks or from accounts without a recent strong authentication. The playbook can then require an MFA step-up, revoke active sessions through the identity provider API, and open a case for the access owner. Shuffle added SAML single sign-on in version 0.9.16 and OpenID Connect in 1.0.0, with per-tenant SSO enforcement, so confirm which of these your Shuffle deployment uses for its own administrators before relying on it for case handling.

Scope checks are harder because they depend on your EHR's data model. A useful playbook compares the user's role, department and assigned patient list against the care relationship recorded in the EHR audit log, then routes exceptions for human review rather than locking accounts automatically. Confirm with the EHR vendor whether its audit and access APIs expose break-the-glass events, patient-level access logs and role assignments, and whether those interfaces are supported for third-party automation. Do not assume a connector exists. Under 45 CFR 164.312, unique user identification and audit controls apply to systems holding ePHI, so the same playbook also produces the access records a breach assessment will need.

European providers should also check whether NIS2 applies. Annex I of Directive (EU) 2022/2555 lists health as a sector of high criticality, including healthcare providers and manufacturers of certain medical devices, which can bring the incident reporting timelines into the playbook. Regulation (EU) 2025/327 on the European Health Data Space may add data access and handling obligations for electronic health data. Ask your legal and compliance team which of these apply to your entity and which national authority receives reports, then decide which identity events must feed the reporting workflow.

How much does open source SOAR for healthcare cost and how long does it take?

What does open source SOAR for healthcare cost to run?

The software license is not the main cost. Shuffle is licensed under AGPL-3.0 and all features are available in its open-source edition, so the larger spend is people and infrastructure: engineering time to build playbooks and connectors, the servers or cluster that run Shuffle and its OpenSearch database, and the ongoing work to keep integrations working as clinical and identity systems change. Ask any partner to split the quote into one-time build work and recurring operations, support and connector maintenance, and to state which items are yours to pay for directly.

Which cost drivers push the price of a healthcare SOAR project up or down?

Five factors move the price most:

The number of playbooks in scope, especially ransomware containment flows that need clinical sign-off.
The number of integrations, such as EHR, identity provider, endpoint, email and ticketing systems.
Clinical approval steps, which add review meetings and testing time before any device isolation goes live.
High availability design, including an OpenSearch cluster, more than one Orborus node and shared storage.
Connector maintenance, meaning how often the vendors behind each integration change their APIs.

Fewer playbooks, fewer integrations and a clear approval model usually keep the first phase smaller.

What is one-time work and what recurs after go-live in a SOAR project?

One-time work covers requirements, architecture, installation, initial app and connector builds, credential setup, workflow testing and documentation. Recurring work covers patching and upgrades of Shuffle and its dependencies, running the infrastructure, rotating credentials, updating apps when a vendor changes an API, reviewing playbook changes, and handling incidents in the platform itself. Ask the quote to show both lists separately so you can budget the operating cost for the years after the first rollout.

Can our internal team run a self-hosted SOAR platform for clinical systems?

Often yes for a team that already runs containers, identity and a SIEM, but it needs named owners for the platform, for each playbook and for clinical sign-off. Shuffle documents single-server Docker Compose, Docker Swarm, a hybrid model with a local Orborus, and Kubernetes with Helm, so the platform itself is manageable with standard skills. The harder part is keeping playbooks correct when EHR, device and identity systems change. Decide early whether your team, a partner or a retainer will own that work, and write the split into the scope.

What does the work need from clinical and IT staff?

IT staff provide access to source systems, service accounts, network design, change control and testing windows. Clinical and biomedical staff must confirm which devices can be isolated, which cannot be isolated without a care plan, and who approves containment when patient care is at stake. Compliance and privacy staff define what evidence the incident record must hold for the HIPAA Security Rule. Plan these reviews as calendar time, since they often set the pace more than engineering does.

How long does it take to deliver the first healthcare SOAR playbook?

The timeline depends on scope, not on a fixed number. A first playbook that only enriches alerts with read-only lookups is much shorter than a ransomware containment flow that isolates devices, needs clinical approval and must be tested in a non-production environment. No researched duration applies to this work, so ask each partner for a phased plan with a written first milestone, the approval gates included, and the testing evidence that will close it.

How does Shuffle licensing by app runs affect the cost of healthcare playbooks?

Shuffle prices its licensing on app runs, which are actions that actually execute in a workflow. Triggers and skipped actions are not counted, and users, apps and workflows are unlimited. Because ransomware containment and enrichment workflows execute many actions per alert, estimate expected alert volume and automated actions per incident before you choose a tier. Note that the open-source and paid editions have enforced limits since v2.1.1, so confirm which limits apply to your deployment with Shuffle before the build starts.

What should we request in a written quote for healthcare SOAR?

Ask for a written scope that lists each playbook, each integration with its owner, the approval steps for destructive actions, the test environments and test cases, and the hosting model. Request the one-time and recurring costs as separate line items, the connector maintenance terms, the handling of the Shuffle encryption secret and credentials, the high availability design, and the handover documentation. Confirm which items are excluded, what changes require a new quote, and how acceptance is measured.

How DeployOpen scopes and builds healthcare SOAR

DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including healthcare environments. For SOAR, that means agreeing the playbook scope, clinical safety constraints and evidence outputs in writing before any Shuffle workflow is built.

How we scope

Written scope lists the alert sources, playbooks and connected systems covered, such as EHR, identity and endpoint tools.
Clinical isolation rules, who approves device containment and when care teams are notified are agreed before build.
Engagements are fixed-scope, with deliverables and timelines agreed in writing; ongoing support is available as a retainer.

How we build

Shuffle is deployed in the client's own cloud, data center or air-gapped network, with credentials stored under the platform's encryption settings.
Playbooks for containment, enrichment and HIPAA incident records are built as versioned workflows and tested before production use.
Integrations with Wazuh, identity providers and EHR interfaces are configured with least-privilege service accounts and logged actions.

How we hand over

Deliverables include architecture documentation, playbook descriptions, approval gate definitions and runbooks for on-call staff.
Clients receive the incident record and audit trail designs that their own compliance and legal teams review.
Knowledge transfer covers how to update connectors, rotate secrets and test workflows after upgrades.

How we support

Retainers can cover platform upgrades, connector maintenance and periodic review of playbooks against current clinical workflows.
Security testing of the SOAR deployment and its integrations can be scoped separately, including AI and agent components where used.
DeployOpen prepares systems, controls and evidence for compliance assessments; independent auditors issue any audit reports or certifications.

Open source SOAR for healthcare