Healthcare teams
Start with the HIPAA-compliant workflows control and BAA path sections below. Download the BAA and DPA from trust artifacts — available before sales or procurement calls.
Download BAA / DPA →Trust Center
Security and compliance signals for EDI buyers
For healthcare procurement, enterprise security reviewers, and developers: SignalEDI's Trust Center gives you a self-serve review path for HIPAA-compliant workflows, SOC 2-ready posture, audit logs, RBAC, encryption, tenant separation, and BAA review. Claims stay inspectable — no sales call required to begin document review.
HIPAA-compliant workflowsSOC 2-ready postureAudit logsBAA pathSecurity overview
Key takeaways
- Trust proof stays connected to pricing, healthcare, API, and demo paths.
- Long-form encryption and RBAC write-ups plus a self-serve reviewer checklist sit above artifacts.
- HIPAA-compliant describes our healthcare control posture — there is no official HIPAA vendor certification. SOC 2 uses readiness language until an attestation is published.
Who this page is for
Start here based on your role
Enterprise procurement
Review the controls grid, then open the SLA, DPA, and Security overview from the trust artifacts section. Pair live status with SOC 2-ready posture materials before scheduling implementation calls.
Open trust artifacts →Developer security review
Check RBAC, logging, and encryption posture controls. Review the API authentication model and webhook signing in the developer docs. Sandbox keys are available without a contract.
Developer docs →Controls buyers ask about
Trust signals in a scannable review grid
Each control is described as-shipped posture — not aspirational certification language. Evidence availability is labeled on each card so reviewers know what is self-serve, what requires a review session, and what links directly to a public artifact.
HIPAA-compliant workflows
Healthcare EDI workflows are designed around PHI sensitivity with access boundaries, audit trails, and BAA review paths built in. Workflow design keeps regulated data within scoped contexts and supports the documentation reviewers need before production healthcare use.
How we implement: PHI-scoped operator roles, transaction-level audit trails, and a documented BAA path before production healthcare traffic. We do not claim an official HIPAA vendor certification — HIPAA does not issue one.
What reviewers get: Downloadable BAA template, DPA, and Security overview; healthcare control language on this page for legal/security review.
Evidence: Public download
Audit logs
Critical workflow, account, support, and automation actions are recorded so reviewers have a timestamped evidence trail. Log entries capture actor, action, and outcome — available on request during security diligence review.
How we implement: Platform actions that change accounts, workflows, or automation state write an actor/action/outcome record. Retention length depends on plan tier and any DPA or enterprise agreement.
What reviewers get: Sample log fields and retention posture during a security review session; public Security overview for encryption and access context. Full log exports are not a self-serve download.
Evidence: Available on request
RBAC
Role-based access controls scope operators, admins, and automation to the permissions required for their specific workflow. Roles are assignable per account and separable by function, preventing over-privileged access across operator contexts.
How we implement: Per-account roles separate operators, admins, and automation credentials. Permissions are scoped to workflow functions rather than blanket workspace access.
What reviewers get: Role model overview in Security docs and developer auth docs; sandbox keys for API review without a contract. Role matrices for your tenant are confirmed in diligence review.
Evidence: Available on request
Encryption posture
Data in transit uses TLS for all API, webhook, and dashboard connections. Stored credentials and sensitive artifacts are encrypted at rest. Specific configuration details are available during a security diligence review session.
How we implement: TLS for API, webhook, and dashboard traffic; credentials and sensitive artifacts encrypted at rest. Cipher and key-management detail is shared in review, not as a marketing claim.
What reviewers get: Public Security overview plus configuration detail in a scheduled diligence session.
Evidence: Public overview
Tenant separation
Each customer workspace operates as a separate context — partner data, API keys, transaction records, and account actions are scoped to the tenant. Cross-tenant data access is not a supported operation in normal platform flow.
How we implement: Workspace-scoped data, keys, and actions. Cross-tenant reads are not part of normal product flow; exceptions would require explicit engineering support outside self-serve paths.
What reviewers get: Architecture summary on the Security overview; tenant-boundary walkthrough available in security review.
Evidence: Available in security review
BAA path
Healthcare buyers can initiate BAA review before moving production PHI workflows. The BAA, DPA, and related policy documents are linked in the trust artifacts section below — no sales call required to begin document review.
How we implement: Self-serve document review first; countersignature when your organization requires it before production PHI. No enterprise contract is required to start reading the BAA.
What reviewers get: Downloadable BAA (.docx), DPA, and SLA from the artifacts section on this page.
Evidence: Public download
Logging and traceability
Transaction lifecycle events — submission, validation, routing, acknowledgement, and exception handling — produce a reviewable operational trail. Status is visible per document and per partner, supporting audit and incident investigation.
How we implement: Per-document and per-partner status across submission, validation, routing, acknowledgement, and exceptions. Operators see the trail in-product; incident investigation uses the same lifecycle events.
What reviewers get: Security overview for logging posture; live status page for platform availability; operational trail detail in product demo or diligence session.
Evidence: Linked in artifacts
Compliance roadmap
Controls under active development are labeled as roadmap, not shipped capabilities. SignalEDI maintains an honest posture on what is available today versus planned — reviewers can confirm current status during a security review session.
How we implement: Shipped controls are labeled as available; planned work is labeled roadmap. We do not present roadmap items as attested certifications.
What reviewers get: This page’s evidence labels plus a current-status confirmation in security review. SOC 2 uses readiness language until an attestation is published.
Evidence: Current status on this page
Long-form control
Encryption in transit and at rest — what reviewers should verify
EDI buyers under healthcare and retail mandates need a clear encryption story before production traffic. This section is the public diligence write-up for SignalEDI encryption posture — not a cipher catalog and not a substitute for your own security questionnaire.
In transit
API calls, webhook deliveries, and dashboard sessions use TLS. Reviewers should confirm that partner file transports (AS2, SFTP) and webhook endpoints in their environment also terminate TLS as expected, and that certificate rotation is owned by the connecting systems — SignalEDI does not replace your network edge controls.
At rest
Stored credentials and sensitive artifacts are encrypted at rest. Exact cipher suites, key hierarchy, and rotation cadence are shared in a scheduled diligence session so we do not publish stale marketing claims that drift from production configuration. Plan-tier retention and any DPA commitments still govern how long encrypted artifacts remain available.
What this page does not claim
We do not publish a self-serve key-management whitepaper or claim a third-party encryption certification. Pair this write-up with the Security overview and the downloadable artifacts below when you assemble a vendor packet.
Long-form control
RBAC and operator boundaries for EDI workspaces
Role-based access is how SignalEDI keeps operators, admins, and automation credentials from sharing a single over-privileged login. Use this section when your questionnaire asks how EDI platforms separate day-to-day operators from account administration and API keys.
Role model
Per-account roles separate operators (transaction and exception work), admins (workspace and billing settings), and automation credentials (API and webhook identities). Permissions follow workflow functions rather than blanket workspace access, so a mapping operator does not inherit full admin by default.
Tenant and partner scope
Partner data, API keys, and transaction records stay scoped to the customer workspace. Cross-tenant reads are not part of normal product flow. Within a tenant, partner and document visibility still follows the roles you assign — confirm the matrix for your org during diligence if you need named role-to-permission tables.
Reviewer next steps
Start with the Security overview and developer auth docs. Sandbox keys support API review without a contract. Full role matrices for your tenant are confirmed in a security review session — they are labeled “available on request,” not as a public download.
Diligence checklist
Security reviewer checklist (self-serve first)
Work top to bottom. Items marked self-serve do not require sales. Items marked review session stay honest — we do not invent downloadable artifacts that do not exist yet.
- Download BAA, DPA, and SLA from trust artifacts (self-serve).
- Read encryption and RBAC long-form on this page, then open the Security overview.
- Confirm HIPAA language — HIPAA-compliant workflow posture and BAA path; no “HIPAA certified” claim (HIPAA does not issue vendor certifications).
- Treat SOC 2 as readiness until an attestation is published on this Trust Center.
- Schedule a diligence session only for role matrices, full audit-log exports, and cipher/key-management detail (available on request).
- Optional API path — sandbox keys and webhook signing docs on Developers without a contract.
Trust artifacts
Policies, status, healthcare, and API diligence in one path
Download BAA, DPA, and SLA review copies — or open live status — without a sales call. Full policy text stays on each linked page for diligence.
BAA template
HIPAA Business Associate Agreement for healthcare EDI review before countersignature.
DPA
Data Processing Addendum covering GDPR, UK GDPR, and CCPA/CPRA processor obligations.
SLA
Service Level Agreement with uptime targets, credits, and incident response commitments.
Status page
Live platform availability, incident history, and scheduled maintenance windows.
Trust FAQ
Is SignalEDI HIPAA certified?
No — HIPAA does not operate an official vendor certification program (unlike attested frameworks such as SOC 2 Type II). SignalEDI describes healthcare workflows as HIPAA-compliant: PHI-scoped access, audit logging, encryption posture, and a documented BAA path. Your legal and security review still governs production use.
Why does SignalEDI say HIPAA-compliant?
HIPAA sets security and privacy requirements for covered entities and business associates — it does not issue a "HIPAA certified" badge for software vendors. HIPAA-compliant describes how SignalEDI designs healthcare workflows, documents controls, and supports BAA review. That is accurate posture language, not a third-party attestation we do not claim.
How does the BAA process work?
Healthcare buyers can download and review the BAA from the trust artifacts section of this page without scheduling a sales call. If your organization requires countersignature before production use, initiate via the BAA link — the process does not require an enterprise contract first.
What is the audit log retention period?
Audit log retention specifics depend on your plan tier and any applicable DPA or enterprise agreement. Base platform logging covers critical workflow, account, and automation actions. Contact sales or review the DPA for exact retention commitments relevant to your compliance program.
Where can security reviewers start?
Start with this Trust Center, then review the BAA, DPA, SLA, privacy policy, status page, and developer resources linked from this page. Sandbox keys for API review are available without a contract.
Does trust proof apply to every workflow?
Controls can vary by product area, deployment, and contract. Use the Trust Center as the public diligence starting point and confirm implementation details during security review.
Is SignalEDI SOC 2 certified today?
Not as a published attestation on this page. We describe SOC 2-ready posture — controls and evidence paths that support a future attestation — and will update this Trust Center when an attestation is available to share. Until then, treat SOC 2 language as readiness, not a completed Type I/II report.
What can I download without talking to sales?
BAA, DPA, and SLA review copies, plus live status and the Security overview. Role matrices, full audit-log exports, and cipher/key-management detail remain diligence-session items so we do not over-claim self-serve completeness.
Need a security review path?
Start with public artifacts, then contact sales when your healthcare, API, or procurement team needs implementation-specific detail.
Explore SignalEDI
Continue diligence on connected public paths
Pricing, checkout, solutions, support, partner requirements, and trust artifacts stay linked so buyers do not dead-end on a single page.