Does self-hosted e-signature help with HIPAA compliance?
A covered entity or business associate that wants to collect consent forms, patient intake and vendor agreements electronically needs to know one thing first: HIPAA has no certification, so no signing platform can make an organization compliant by label alone. The HHS FAQ from 2003 states that no Security Rule standard requires an entity to certify compliance and that HHS does not recognize private certifications. The Security Rule applies to electronic protected health information (ePHI) wherever it flows, and a signing workflow that carries patient names, diagnoses or treatment details is in scope. Self-hosting changes one important question: whether a signing vendor must be engaged as a business associate and whether ePHI leaves infrastructure the provider controls. It does not, on its own, satisfy the safeguards.
The Security Rule covers covered entities (health plans, health care clearinghouses and covered health care providers) and business associates, as set out in 45 CFR 164.302. Its standards sit in Appendix A to Subpart C: 18 standards across administrative (164.308), physical (164.310) and technical (164.312) safeguards, with 36 implementation specifications. Of those specifications, 14 are required and 22 are addressable. Addressable does not mean optional. For each one, the entity must assess whether it is reasonable and appropriate for its environment, document the decision if it is not adopted, and implement an equivalent alternative if one is reasonable. For a signing service, that means deciding which controls, such as session timeouts for staff signing consoles or encryption settings on the PostgreSQL database behind Documenso or DocuSeal, are required and which are addressable and how each decision is recorded. NIST SP 800-66 Rev. 2 offers sample questions for each standard, which is a practical starting checklist.
Which HIPAA Security Rule safeguards apply to a signing service
This table maps the Security Rule standards that touch a self-hosted signing service to what the platform must do and how to configure Documenso or DocuSeal for each. Read each row as a question to answer in your own risk analysis, then record the decision and the evidence you keep. The main takeaway is that most of the work sits in access control, audit logging and transmission settings, and in the addressable specifications you must document.
| Safeguard | What the signing service must do | How to configure Documenso or DocuSeal |
|---|---|---|
| Access control (164.312(a)(1)) | Limit access to signed documents and templates to people who need them, and give each user a unique identifier. | Create named accounts per user, restrict team and template visibility, and confirm which roles can download completed PDFs. |
| Automatic logoff and encryption at rest (164.312(a)(2)) | Terminate idle sessions and protect stored ePHI, including signed PDFs and attachments in the database and file storage. | Set session timeouts in the platform and enable disk or volume encryption on the database and document storage hosts. Confirm the edition's session settings. |
| Audit controls (164.312(b)) | Record and review activity on documents that contain ePHI, including who viewed, sent, signed or downloaded them. | Export audit trails and send platform logs to a central log store. Confirm which events each edition records before you rely on them. |
| Integrity controls (164.312(c)(1)) | Protect signed documents from improper alteration and show that a completed record has not changed. | Use PDF signature verification and sealed completed documents. Confirm the signing certificate setup described in the platform's signing guidance. |
| Transmission security (164.312(e)(1)) | Guard ePHI sent to signers and returned from them over networks, including signer invitation links and downloads. | Serve the platform only over HTTPS with a current certificate, disable plain HTTP, and confirm SMTP connections use TLS. Keep signer links expiring and single-purpose. |
| Person or entity authentication (164.312(d)) | Verify that the person signing or viewing is who they claim to be, at a level matched to the document's risk. | Choose the identity method per template, such as email link plus one-time code. SSO with SAML is a Pro feature in DocuSeal. Confirm edition support before you design the flow. |
| Security incident procedures (164.308(a)(6)) | Identify, respond to and document suspected security incidents affecting the signing platform. | Define alert sources from platform and host logs, assign responders, and write a procedure that names who revokes signer links and rotates credentials. |
| Contingency plan (164.308(a)(7)) | Back up signing data and restore it so pending signatures and records remain available. | Back up the PostgreSQL or MySQL database and document storage together, and test a restore. Document recovery steps in the contingency plan. |
| Business associate contracts (164.308(b), 164.314(a)) | A self-hosted platform you run does not usually create a vendor business associate relationship, but any hosting provider or support firm that can access ePHI may need one. | Map every party with access to the hosting, database or support sessions. Confirm with counsel which of them requires a business associate agreement. |
| Policies and documentation (164.316) | Maintain written policies and procedures for the signing service, keep them current, and retain documentation for six years. | Write the configuration baseline, access review procedure and retention rules. Record every addressable specification decision under 164.306(d), with the reason and any equivalent measure. |
Documenso or DocuSeal for a HIPAA signing workflow
Both platforms are open source and can run in infrastructure you control, which keeps signed ePHI off a vendor's multi-tenant service. The differences that matter for HIPAA are the database, the deployment model, how signing certificates are handled, and which access controls sit in paid editions. Settle those before you design the access model, because the edition you buy determines which controls you can enforce.
Licensing and source access
Documenso is licensed under AGPL-3.0, and DocuSeal is distributed under AGPLv3 with Section 7(b) additional terms. Both let you read, run and modify the code, which lets your security team review how signed documents, audit records and signer links are handled. Have counsel confirm what the Section 7(b) terms require for your deployment, especially if you modify the code or expose it to outside users. Ask each vendor to confirm which features are gated by commercial licensing.
Database and data residency
Documenso uses PostgreSQL, so the database holds document metadata, signer details and audit records alongside the stored files. DocuSeal runs on SQLite by default, which suits a pilot but is usually the wrong choice for a production store of ePHI. Its DATABASE_URL setting allows PostgreSQL or MySQL instead. Confirm where backups, replicas and log stores live, and that each one is encrypted and covered by your business associate agreements where applicable.
Deployment model and hardening
Documenso supports Docker, Docker Compose, Railway, Kubernetes and manual installation, and publishes official images on Docker Hub and GitHub Container Registry. DocuSeal ships as the docuseal/docuseal Docker image. Choose the model your security team can patch, monitor and restore inside the covered environment. Pin image versions, scan them, and record the release you tested. Documenso v2.20.0 was published on October 8, 2026, and DocuSeal 3.3.2 on October 12, 2026, so confirm the current release before you build.
Signing certificate options
Documenso needs a signing certificate to apply digital signatures. The documented options include a self-signed .p12 certificate generated with OpenSSL and signing through Google Cloud KMS. A self-signed certificate proves the document was not altered after signing, but it does not establish the signer's identity. Key custody is the control to design: decide who can access the private key, where it is stored, and how rotation and revocation are logged. Confirm with the vendor how DocuSeal handles PDF signing keys and signature verification.
Edition gates on access controls
SSO with SAML and bulk send sit in DocuSeal's Pro edition, and its free on-premises edition has no SSO, bulk send or embedded signing. Documenso lists embedded signing in its Teams and Platform plans, and its Enterprise plan covers self-hosted setups. If your access model depends on SSO with multi-factor authentication through your identity provider, or on per-user role separation, that control may depend on the paid tier. Get written confirmation from each vendor of which edition supplies each control you need before you finalize the design.
Audit trail and access review
The HIPAA Security Rule requires audit controls that record and examine activity in systems containing ePHI. Test whether each platform logs document creation, views, downloads, sends, voids, template changes and administrator actions, with user identity and timestamp. Confirm the log is protected from editing by application administrators and can be forwarded to your central log store. Also confirm whether you can export the trail for a specific document during an investigation, and how long it is retained.
Transport and signer link controls
Signer invitations contain links that open documents containing ePHI, so transmission security matters at both the web tier and email delivery. Require TLS on every endpoint, including the reverse proxy and any webhook targets. Set expiration and single-use behavior for signing links, and confirm each platform's defaults. Verify how invitation emails travel, because a message that leaves your network through an outside relay may need its own business associate agreement.
Who can see signed documents and how to restrict it
Start by mapping who can see each signed document before any signing workflow goes live. In a self-hosted Documenso or DocuSeal deployment, the access questions split into three groups: which internal users hold roles that can open documents, who owns each template and the documents generated from it, and which people outside the organization can open a document through a signer link. Decide these answers per workflow, such as consent forms or vendor agreements, because a signed consent form can contain ePHI while a generic NDA may not. Under 45 CFR 164.312(a)(1), access to systems holding ePHI must be limited to people or software granted access rights. The minimum necessary principle is not a separate Security Rule standard, but it is the practical test your auditor will apply to every role you grant, so give each role the narrowest set of templates and documents it needs.
Signer links deserve different treatment from authenticated user access. A signer link lets an unauthenticated person view and act on one document, so treat it as a credential. Confirm in your chosen version whether links expire, whether they can be revoked after sending, whether the signer must verify identity or a one-time code before viewing, and whether delivery events are logged. Set the shortest lifetime your signing process allows and tie each link to a single recipient. Keep a record of which address received which link and when, because that record is the evidence you will need if a signer disputes receipt or someone forwards a link.
Verify every access behavior in the exact release you deploy rather than assuming it from marketing pages or this guide. Build a test matrix with at least one internal user per role, a template owner, a document owner, an outside signer and a user from another team. For each, record what they can list, open, download, edit, resend and delete, then check that the same restrictions hold for API tokens and webhook payloads. Repeat the test after every upgrade, because permission models change between releases. Document the results as access control evidence for your HIPAA risk analysis, and confirm the feature list with the vendor before you rely on any role or expiry setting in a compliance file.
How to configure encryption, audit logging and retention
This sequence takes a self-hosted signing service from an empty environment to one where signer links and invitations travel over encrypted channels, stored documents and records are encrypted, audit events leave the signing host for central review, and retention and restore are settled and tested. Each step ends with a check you can record as evidence for your risk analysis and compliance file.
Deploy the signing service inside your boundary
Your infrastructure team deploys Documenso or DocuSeal in your own cloud account, data center or enclave, using the official container images and a PostgreSQL database (DocuSeal can also use MySQL or SQLite, but a managed relational database with its own backup policy is the more typical choice for production). Record the hosting location, the network segment, the administrative accounts and the people who can reach the database host. The step is done when the service runs from a reviewed configuration file kept under version control and no signing data is written to a vendor-hosted tenant.
Enforce TLS on signing and invitation paths
Your platform engineers place the public signing domain behind a reverse proxy or load balancer that accepts only current TLS versions and holds a certificate issued by your certificate authority. Your messaging team configures the SMTP relay used for signer invitations and reminders to require STARTTLS or implicit TLS, and confirms that the relay refuses plaintext sessions. Verify with an external TLS scan and a test invitation captured at the relay. The step closes when both the browser path and the mail path show encrypted sessions, which supports your review of 45 CFR 164.312(e)(1) on transmission security.
Encrypt stored documents and database volumes
Your storage and database administrators enable encryption at rest on the database volumes, object storage or file system that holds uploaded PDFs, completed envelopes and signing certificate material, using keys managed by your key management service. Confirm which files the platform writes to disk, where the signing certificate is held, and who holds the key-encryption keys. Restrict access to those keys to a small named group, separate from application administrators. The step is done when a test read of raw storage returns ciphertext and the key access list has been reviewed and signed off.
Enable audit logs and forward them centrally
Your security engineers turn on the platform's audit and activity logging, then forward application, reverse proxy, database and administrative events to a central log store that the signing team cannot edit. Define which events must be captured: document creation, views, sends, signatures, downloads, template changes, user and role changes, and login failures. Map the output to 45 CFR 164.312(b), which requires audit controls that record and examine activity in systems containing ePHI. The step is complete when a test action appears in the central store with a timestamp and a user identity, and an alert reaches the on-call queue.
Set retention periods from your own policy
Your privacy officer, compliance lead and legal counsel decide how long signed forms, consent records, audit events and invitation metadata must be kept, and when each category is deleted or archived. Retention periods come from your organization's legal and policy review, not from a platform default, and they may differ between a signed consent form and its audit trail. Configure the database and storage lifecycle rules to match, and document the schedule in your records policy. The step is done when the approved schedule is signed, each data category has a configured rule, and a test record shows the expected expiry or archive action.
Restore from backup and prove it works
Your operations team takes encrypted backups of the database and document storage on the schedule your recovery requirements set, then restores them into an isolated environment. Confirm that a restored envelope still opens, its audit history is intact, its signatures validate with the PDF verification tools, and the encryption keys needed to read it are available to the recovery team. Record the restore time and any gaps. The step closes when a documented restore test passes and the results are filed with your contingency plan, which supports the backup and disaster recovery specifications in the Security Rule's administrative safeguards.
Confirm the configuration with your auditors
Your compliance lead gathers the configuration files, TLS scan results, key access lists, log samples, retention schedule and restore test record into one evidence folder mapped to the Security Rule standards you are relying on. Ask your independent assessor or counsel to review the mapping, since DeployOpen prepares evidence but does not issue audit reports or attestations, and no HIPAA certification exists. The step is done when the reviewer's questions are logged and resolved, and the evidence folder is versioned so that each later change to the platform has a traceable record.
Why self-hosting changes the business associate agreement question
A SaaS signing provider that receives ePHI in signed documents, audit records or signer details will usually be treated as a business associate, which means the covered entity needs a business associate agreement with that vendor before the documents go through it. Self-hosting changes the starting point. When Documenso or DocuSeal runs on infrastructure the covered entity or its contracted operator controls, the signing vendor that wrote the software is not handling ePHI on its own systems, so the question becomes who actually touches the data path. That shift is a decision to document, not a conclusion to assume.
The data path still has several third parties, and each one needs its own check. The cloud host or data center that runs the containers and PostgreSQL database may hold ePHI on its hardware and will generally need a BAA if it can access that data, or a contractual arrangement that limits its access. The email provider that sends signer invitations and completion notices will see document links and sometimes document titles, so its terms and BAA position matter. Support access by the software vendor, your integrator or your own staff also needs written rules, including whether a support engineer can open a database or log file that contains ePHI. Counsel should confirm which of these parties creates, receives, maintains or transmits ePHI for your organization.
Before relying on self-hosting to narrow the BAA scope, ask counsel and your integrator to produce a short data flow map for each signing workflow. It should list every system that stores signed PDFs, form data, signer emails, audit events and backups, and every party with administrative or support access to them. Confirm the hosting agreement, the email relay terms and any remote support procedure in writing. Self-hosting reduces the number of vendor relationships that must be managed, but it does not remove the covered entity's own obligations under the Security Rule, and it does not mean that no BAA is needed anywhere in the chain.
What auditors and OCR ask for from a signing system
Does HIPAA certify a signing platform as compliant?
No. There is no HIPAA certification, and HHS states that no Security Rule standard requires an entity to certify compliance and that it does not endorse or recognize private certifications. Any certificate a vendor shows you does not prevent OCR from later finding a violation. What an auditor or OCR will examine is your own evidence: the risk analysis, the configuration of the signing service, its logs, and your policies. Independent auditors can assess that evidence, but DeployOpen prepares systems, controls and evidence for assessment and does not issue audit reports, attestations or certifications.
Why does OCR audit ransomware and hacking controls first?
OCR's 2024 to 2025 HIPAA audits review 50 covered entities and business associates on the Security Rule provisions most relevant to hacking and ransomware. Enforcement also runs through complaint investigations and compliance reviews, so a signing service holding ePHI can be examined at any time. For planning, expect reviewers to ask how you limit access, log activity and recover data after an incident, not only whether the software was installed. Confirm the current audit protocol with HHS OCR before you map your evidence.
Who can see signed documents, and where is the access control matrix?
Your access control matrix lists each role, such as administrator, sender, signer, auditor and support staff, with the documents, templates and audit records each role can open. The signing platform produces the account, role and team settings that enforce it, so you must export and review them. Include who can download completed PDFs and who can view the signing certificate and audit trail. Confirm in the vendor documentation which roles exist in the edition you choose, since some features such as SSO are edition-dependent.
What audit log samples should we show an assessor?
Show samples of logged events covering document creation, sending, viewing, signing, download, template changes, user role changes and administrator logins, with user, timestamp and object for each. Under 45 CFR 164.312(b), audit controls must record and examine activity in systems containing ePHI, so the log must also be stored, protected from alteration and reviewed on a schedule you define. The platform generates the events and the database holds them, but your review procedure and retention of the logs are your responsibility. Confirm which events the chosen edition writes to the log before you promise coverage.
What transmission configuration proves signer links are encrypted?
Provide the TLS configuration for the public signing URL, the mail relay settings used for signer invitations, and the database connection settings, showing that ePHI moves only over encrypted channels. Under 45 CFR 164.312(e)(1), technical measures must guard against unauthorized access to ePHI sent over an electronic communications network. Evidence includes the certificate source, supported protocol versions, redirect rules from HTTP, and whether the email relay requires encrypted transport. Your reverse proxy and load balancer often terminate TLS, so include them in the evidence set.
What backup and restore test do auditors expect for a signing service?
Auditors expect a documented backup schedule, a sample restore test with its date and result, and proof that restored documents and their audit trails match the originals. Documenso uses PostgreSQL, and DocuSeal can run on SQLite by default or on PostgreSQL or MySQL, so the backup scope must include the database, uploaded files and any signing certificate material. The restore test is the evidence that matters, so run it and record it. Ask your implementation partner to document the procedure and the recovery time you commit to internally.
Which retention schedule and policy documents apply to signed records?
Your retention schedule states how long signed consent forms, intake records, agreements and their audit trails are kept, and when they are destroyed. HIPAA sets documentation rules under sections 164.316 and 164.316-related requirements, and state law or your own contracts often set longer periods. The signing platform supports the retention you configure through document storage and deletion settings, but it does not decide the period for you. Include policies, workforce training records and vendor agreements in the same evidence set, and have counsel confirm the period for each document type.
Do we need a business associate agreement if we self-host?
A business associate agreement is needed with a vendor that creates, receives, maintains or transmits ePHI on your behalf. When you run an open-source signing service inside infrastructure you control, the software publisher does not receive the ePHI, so no BAA with that publisher is needed for the software itself. Cloud providers hosting your servers are a separate question, and your legal team should confirm whether they need a BAA. Any implementation partner that accesses ePHI during the engagement may need one, so define that access in writing before work starts.
What the signing platform alone does not satisfy
A self-hosted signing service covers part of the Security Rule, mainly technical safeguards for signer links and stored documents. The cards below cover what the software cannot do for you, and who in your organization owns each gap.
Risk analysis and risk management
The Security Rule expects a documented, accurate analysis of where ePHI lives and moves, followed by risk management that reduces those risks to a reasonable level. For the signing service, this means mapping every place a signed consent form, intake packet or vendor agreement is stored, cached, emailed or exported. Owner: the privacy and security officer, with system owners signing off. Check that the analysis covers the database, object storage, backups, mail relay and any EHR connector.
Workforce training and access reviews
Staff who send, countersign or administer envelopes need training on minimum necessary access, handling of signer data and recognizing phishing that imitates a signing invitation. The platform can enforce roles, but it cannot decide who should hold them. Owner: HR and compliance, with the signing platform administrators. Confirm that training is documented, that it is repeated when roles change, and that administrator accounts are reviewed on a schedule you set.
Incident response and breach notification
When a signing server is compromised, misdirected or misconfigured so that documents reach the wrong recipient, you need a runbook that names who decides, who contacts counsel and how breach notification is assessed. The platform's audit log is evidence for this process, not the process itself. Owner: the security operations lead and legal counsel. Test the runbook with a tabletop exercise that includes a misaddressed signing link.
Contingency planning and tested restores
Signed documents may be the only copy of a consent or agreement, so backups of the PostgreSQL or MySQL database and the document store must be recoverable within a time you define. Contingency planning also covers what happens if the signing service is unavailable during patient intake. Owner: the infrastructure team, with business owners of each signing workflow. Ask for documented restore tests, not only backup job logs.
Physical safeguards at the hosting site
The Security Rule's physical standards cover facility access, workstation use and device disposal. If the service runs in a colocation facility or a cloud region, you must review the provider's controls and your own procedures for staff who enter that environment. Owner: facilities or cloud governance, with the security officer. Request the provider's physical security documentation and confirm how decommissioned disks holding signed PDFs are wiped.
Key and signing certificate management
Documenso needs a signing certificate to digitally sign documents, and the documented options include a self-signed .p12 file or signing through Google Cloud KMS. Who generates, stores, rotates and revokes that certificate, and where the database credentials and TLS keys live, decides whether your signatures can be trusted. Owner: the PKI or security engineering team. Document the rotation schedule and the procedure if a key is exposed.
How much work and cost does HIPAA-ready self-hosted signing take?
What does self-hosted HIPAA-ready e-signature cost compared with SaaS?
The cost splits into one-time work and recurring spend, and the recurring part depends on which edition you run. The software itself is free to download under AGPL-3.0 for both Documenso and DocuSeal. Per DocuSeal's pricing page, as read in October 2026, On-Premises Open Source is free, while On-Premises Pro costs $240 per user per year. Documenso's pricing page, as read in October 2026, lists its cloud plans separately, and its Enterprise plan is custom priced for cloud or self-hosted setups. Your recurring costs are infrastructure, any paid license, and signing certificates, plus staff time for patching and backups. Ask each vendor for a written quote that states which edition covers your use case.
Which cost components should a HIPAA signing budget include?
A complete budget has five components, and each is paid to a different party.
What drives the cost of self-hosted signing up or down?
The main drivers are edition, user count, integration depth and the number of signing sessions you expect. On DocuSeal, the free on-premises edition has no SSO, bulk send or embedded signing, so any requirement for those features moves you to On-Premises Pro. Per DocuSeal's pricing page, that edition is $240 per user per year and adds $0.20 per completion for embedded signing. Documenso's Teams and Platform plans add API access and embedded signing on its cloud pricing. Each EHR or identity integration adds engineering and testing effort, and a larger user base adds licensing and support load.
Can an internal team deploy HIPAA-ready signing without outside help?
Yes, a team with container and database skills can install both platforms, since Documenso and DocuSeal ship as Docker images. The harder work is the compliance layer: encryption in transit for signer links, access control, audit logging, backups, retention and documentation mapped to the Security Rule. Documenso and DocuSeal can both run on PostgreSQL, and DocuSeal's default SQLite is not a fit for most production workloads, so confirm the database design with your own architects. Before deciding, check whether your team has capacity to maintain the system on an ongoing basis.
How long does a HIPAA-ready signing rollout take?
Timing depends on the scope agreed in writing, not on a general rule. A rollout covering one document type with one identity source takes far less effort than a rollout covering consent forms, vendor agreements, bulk patient mailings and EHR integration. Most engagements at DeployOpen are fixed-scope, so the scope, deliverables and timeline are agreed in writing before work starts. Ask any partner for a phased plan that separates the first production document type from later integrations, and confirm which items depend on your own change control and security review.
What is the potential civil penalty exposure for weak HIPAA safeguards?
Penalty exposure can be substantial, which is why the cost of a sound design should be weighed against it. Under 45 CFR 102.3, the inflation-adjusted civil money penalty for penalties assessed on or after January 28, 2026 ranges from $145 per violation where there was no knowledge, up to $2,190,294 per violation for uncorrected willful neglect, with a calendar-year cap of $2,190,294. The Security Rule violations that matter for signing include unauthorized access to ePHI in transit and missing audit controls under 164.312(e)(1) and 164.312(b). Confirm the current figures with your counsel before using them in a board paper.
Does a HIPAA certificate or vendor badge reduce the work?
No, there is no HIPAA certification, so no vendor badge replaces your own evidence. HHS states that no Security Rule standard requires certifying compliance, and that it does not endorse or recognize private certifications. Pricing pages that list HIPAA among compliance references, such as Documenso's, do not tie that claim to a plan or replace a risk analysis. Budget for the risk analysis, policies, workforce training and audit evidence that you own, and for any independent assessment you choose to commission from an auditor.
What should I ask a partner for in a self-hosted signing quote?
Ask for a written quote that lists scope, deliverables, exclusions and assumptions, so you can compare bids on the same basis. Request these items:
What DeployOpen scopes, configures and tests before go-live
Before any signing workflow carries patient data, DeployOpen plans the deployment inside the client's own cloud account, data center or private network, and records where every component runs, who operates it and where the signed PDFs, signer records and audit tables are stored. The scoping output is a written design that names the hosting boundary, the database (Documenso uses PostgreSQL, while DocuSeal runs on SQLite by default and supports PostgreSQL or MySQL through DATABASE_URL), the storage location for documents, the outbound email path for signer invitations, and the backup and restore arrangements. Covered entities and business associates should confirm which of these components they are responsible for under their own risk analysis, since the Security Rule applies to every system that handles electronic protected health information.
Configuration then turns that design into controls that can be shown to an assessor. Access is set up with named administrator roles, separate accounts for template authors and senders, and single sign-on where the chosen edition supports it, since DocuSeal's free on-premises edition has no SSO and DocuSeal Pro lists SSO with SAML as a Pro feature. Audit logging is enabled and forwarded to a central log store that the client controls, so that the record of who viewed, sent and completed a document can be examined as the audit controls in 45 CFR 164.312(b) require. Transmission security covers TLS on signer links and the admin interface, and the signing certificate choice, such as a self-signed .p12 certificate documented by Documenso or a key held in a cloud KMS, is recorded with its owner and rotation plan.
Before go-live, DeployOpen prepares the evidence file (configuration baselines, access reviews, log samples, backup test results and the risk analysis entries that cover the signing service) and runs security testing against the deployed system, including application and API testing for signer links and webhooks. Findings are fixed or formally accepted with a documented reason, which reflects the addressable-specification logic in 45 CFR 164.306(d). These steps support an independent assessment but do not replace one, and DeployOpen does not issue audit reports, attestations or certifications. Clients should confirm with their privacy and security officers which evidence their assessors expect, and agree the test scope and acceptance criteria in writing before work starts.
How DeployOpen delivers HIPAA-ready self-hosted signing
DeployOpen plans, implements, hardens, documents and supports self-hosted signing platforms inside your own cloud accounts, data centers or air-gapped networks. We prepare the systems, access controls and evidence that a HIPAA Security Rule review will ask about, while your compliance team and independent assessors make the final determinations.
How we scope
- We agree a written, fixed scope covering the signing platform, hosting boundary, signer workflows and integrations before work starts.
- The scope names which document types carry ePHI, who may view signed records, and which audit events must be retained.
- We confirm with your privacy officer which safeguards are required and which addressable specifications you plan to document.
How we build
- We deploy Documenso or DocuSeal in your environment with PostgreSQL or MySQL, TLS for signer links, and access restricted to approved networks.
- We configure role-based access, signing certificates and audit logging, then test those controls against the scope agreed in writing.
- We run security testing on the signing application and its APIs and record the results as evidence for your risk analysis.
How we hand over
- You receive architecture diagrams, configuration records, access matrices and runbooks mapped to the Security Rule standards in scope.
- We document retention settings, backup and restore procedures, and the evidence location for each audit control your team reviews.
- Knowledge transfer sessions cover administration, certificate management and incident steps so your staff can operate the service.
How we support
- Ongoing support, upgrades and continuous security testing are available as a retainer, scoped separately from the build.
- We apply upgrades to the signing platform and re-test changed controls before they reach production records.
- Support requests and change control follow the written agreement, so your compliance evidence stays current after go-live.
