Self-hosted e-signature for 21 CFR Part 11

How 21 CFR Part 11 shapes a self-hosted e-signature platform

A self-hosted e-signature platform can support the 21 CFR Part 11 controls that GxP teams need for signed batch records, SOPs and quality approvals, but the Part 11 compliance module on Documenso is Enterprise-only, and the validation of the system stays with the organization. Buying a license or running the software does not make the signing process compliant. The quality unit has to define the intended use, test the configured workflow against it and keep the evidence. Before comparing platforms, confirm with each vendor which Part 11 features are included in the edition you would deploy, in writing, and what that vendor will and will not supply for validation. The regulation sets three signature controls, and each one maps to a different part of the platform. The first covers signature manifestations: a signed record must show the signer's printed name, the date and time of signing and the meaning of the signature, such as review, approval, responsibility or authorship. The second covers signature and record linking, so a signature cannot be copied or moved to another record to falsify it by ordinary means. The third covers unique signatures: each signature belongs to one individual, is never reused or reassigned, and the organization verifies the person's identity before issuing it. Each control turns into specific configuration, templates, user provisioning and retention decisions that your quality and IT teams must own. For each signing workflow, document how the platform renders the signer's name, timestamp and signing meaning, how signatures are bound to the final PDF, and who approves the user accounts that can sign. Also confirm how identity is proven before an account is created, because the platform cannot do that step for you. Those answers form the core of your validation plan and of the requirements you give any implementation partner.

Mapping 11.50, 11.70 and 11.100 to platform configuration

This table maps each Part 11 requirement to what the signing function must do, how to configure Documenso or DocuSeal for it, and the evidence an assessor will ask for. Read each row as a design control: the platform handles part of it, and your procedures and validation records cover the rest. Note that the Part 11 compliance module in Documenso is an Enterprise feature, so confirm edition before you design around it.

Requirement	What the function must do	Configuration and ownership	Evidence to keep
21 CFR 11.50 signature manifestations	Show the signer's printed name, date and time of signing, and the meaning of the signature (review, approval, responsibility or authorship) on the record and in every readable copy	Set signer name and timestamp fields on the template and confirm they print on the completed PDF. Define a fixed reason text per workflow, since neither platform's free edition is documented here as providing a Part 11 signature meaning field	Sample signed PDFs showing each manifestation element, plus the controlled list of signature meanings approved by quality
21 CFR 11.70 signature-record linking	Bind each signature to its record so it cannot be copied or moved to another record to falsify it by ordinary means	Sign only the final, locked PDF version. Confirm the signing certificate and document hash change on any edit, and test whether a signed file can be extracted and attached elsewhere. Verify this in your own environment	Test scripts and results for copy, excision and version-change attempts, plus the signing certificate configuration record
21 CFR 11.100(a) unique signatures	Each electronic signature belongs to one individual and is never reused or reassigned	Create one named account per signer, disable shared logins and deactivated users, and block account reuse through your identity process. Documenso's Community Edition has basic OIDC support, and full SSO is listed in its Enterprise edition	User account roster, SSO or identity provider configuration, and deprovisioning records
21 CFR 11.100(b) identity verification	Verify the person's identity before assigning a signature	The platform does not perform identity proofing. Run verification through HR or your identity team before account creation, and record who verified each user and when	Signed identity verification forms or HR attestations linked to each account ID
21 CFR 11.100(c) certification to FDA	Certify to FDA that the organization's electronic signatures are the legal equivalent of handwritten signatures, and supply additional certification on request	This is a letter from your organization, not a platform setting. Send it to the FDA before or at the time signatures are first used, and track who signed it. Your quality or regulatory team owns the wording	Copy of the certification letter, date sent, and the FDA submission record
Edition and Part 11 module	A Part 11 compliance module is required for controls beyond the basics	Documenso lists 21 CFR Part 11 among its compliance references on its pricing page, but its Enterprise edition is the one described as adding advanced compliance modules. Get written confirmation of which features each edition provides before purchase	Vendor quote and written feature list matched to the requirement IDs above
Validation of the configured system	Show the platform performs as specified for its intended use	Validation is owned by your organization. DeployOpen can help prepare test protocols and execute them against your configuration, but the validation decision and sign-off stay with your quality unit	Validation plan, requirements traceability matrix, executed test records and change control log

Which edition covers Part 11 needs: Documenso or DocuSeal

The Documenso Community Edition is the self-hosted option that most teams evaluate first, and it is licensed under AGPL-3.0, so the code can be read, run and audited in your own environment. Its documentation describes basic OIDC support and basic eSign compliance. Those features may cover internal review workflows, but they do not, on their own, establish Part 11 controls for GxP records.

Identity: Basic OIDC sign-in is available, which means you should confirm how user provisioning, deprovisioning and role mapping work before relying on it for named signers.
Compliance scope: The Community Edition is described as offering basic eSign compliance, which is not the same as a Part 11 module.
Signing certificate: You must supply a signing certificate, such as a self-signed .p12 generated with OpenSSL or a key in Google Cloud KMS, and the choice affects how signatures are validated.
Database and deployment: The platform runs on PostgreSQL with Docker, Docker Compose, Kubernetes or manual installation, and you own backups and upgrades.

Before selecting this tier for signing GxP records, ask Documenso in writing which Part 11 controls, if any, the Community Edition provides.

Which open-source platforms fit a Part 11 signing workflow

Part 11 signing depends on the signing platform, the identity behind each signer, and the mail path that carries invitations. The options below cover the two self-hosted e-signature platforms and the supporting components that decide whether a signature can be tied to a unique, verified person. No platform is certified by FDA, so fit depends on the edition you deploy and on the validation you perform.

Documenso Enterprise for Part 11

Documenso's Community Edition is licensed under AGPL-3.0 and runs from Docker, Docker Compose, Kubernetes or a manual install on PostgreSQL. Documenso's own materials place the 21 CFR Part 11 compliance module in the Enterprise Edition, alongside full SSO and an Adobe-approved signing certificate. Confirm the module's exact features, and whether they cover the signature manifestations and record linking your SOPs require, before you select this edition. Treat the Enterprise license as a gating decision.

DocuSeal self-hosted editions

DocuSeal is distributed under AGPLv3 with Section 7(b) additional terms and ships as the docuseal/docuseal Docker image. It defaults to SQLite, while PostgreSQL or MySQL can be set through DATABASE_URL, which matters for backup and validation scope. The free on-premises edition has no SSO, so unique user accounts must come from elsewhere. Confirm with the vendor whether any DocuSeal edition provides Part 11 controls before you rely on it for GxP records.

Identity provider for unique accounts

Section 11.100 requires each electronic signature to belong to one individual and never be reused, so every signer needs a single, verified account. A self-hosted identity provider that supports OIDC or SAML, such as Keycloak, can enforce unique usernames, MFA and deprovisioning. Documenso's Community Edition offers basic OIDC, and DocuSeal's Pro edition offers SAML. Check how the identity store links to signing accounts and how disabled users are removed from the signing platform.

Internal mail relay for invitations

Signers receive invitation and completion emails from the signing platform, and those messages become part of the GxP record trail. Route them through an internal relay you control, with sender domain authentication and logs retained under your records policy. Documenso Enterprise lists custom email sender domains as a feature. Ask your validation team to define which notifications are records and how delivery failures are detected and documented.

Database and backup platform

Documenso uses PostgreSQL, and DocuSeal can run on SQLite, PostgreSQL or MySQL. The database holds signed records, audit events and user mappings, so its backup, restore and change control belong inside the validated system. Document which database engine and version you validated, and test restores against the signed record set. Moving between engines later means re-validating the change, so make this decision before go-live.

Signing certificate and key management

Documenso requires a signing certificate to digitally sign documents, with options that include a self-signed .p12 certificate created with OpenSSL or signing through Google Cloud KMS. Part 11 does not prescribe a certificate type, but the certificate and its private key become part of your system controls and need documented custody, rotation and access rules. Confirm with your quality unit which option fits your validation approach, and who holds key administration rights.

What the validation of a self-hosted signing system involves

The sequence gives the organization documented evidence that the signing system does what its intended use requires, that signatures carry the required manifestations and linking, and that later changes do not undo that state. Each step produces a record the quality unit can review and approve.

Define user requirements and intended use
The quality function, system owners and business process owners write down which GxP records will be signed, by which roles, for which meanings of signature such as review, approval, responsibility or authorship. They also state which signing workflows are in scope and which are excluded. This document is the baseline every later test traces back to. It is done when the quality unit has approved the requirements and each requirement has an identifier that tests can reference.
Risk-assess the signing workflow
The team maps each signing step, from document preparation and signer invitation to signature application, record storage and retrieval, and identifies where a failure could let a record be altered, a signature be misattributed or a signed copy be lost. Controls are then assigned to the highest-risk points, such as signer authentication, record-signature linking and audit trail completeness. The output is a risk assessment that justifies the depth of testing for each function. It is done when every identified risk is linked to a control and a test.
Install and configure from controlled specifications
The infrastructure team deploys the chosen Documenso or DocuSeal edition from a written configuration specification covering hosting, PostgreSQL or other database settings, identity provider integration, signing certificate source, email sender configuration and access roles. Versions, container image references and configuration files are placed under version control so that the deployed state can be compared with the approved state at any time. The step is complete when the environment matches the specification and a configuration baseline is recorded. Confirm with the vendor which edition provides the Part 11 module before this specification is written, because that choice determines the configuration available.
Execute installation and operational qualification tests
Testers run scripted checks against the installed system to confirm that components are present at the approved versions, that access controls restrict administrative functions, that audit logging is enabled, and that the system performs as specified under normal operating conditions. Each test records its expected result, actual result, tester and date, and any deviation is raised and resolved before continuing. This evidence shows the system was installed correctly and operates within its specified limits. It is done when all qualification protocols are executed and deviations are closed or accepted by the quality unit.
Document signature manifestation and linking tests
This is the part of validation most specific to Part 11. Testers sign sample records and verify that each signature displays the signer's printed name, the date and time of signing and the meaning of the signature, and that these items appear in the human-readable record and any printout. They then attempt to detach, copy or transfer a signature to another record and confirm the system prevents it by ordinary means. They also check that each signer identity is unique and that accounts cannot be reassigned. Results are compared against the requirements from the first step and the evidence is retained. The step is done when every manifestation and linking requirement has a passing, traceable result.
Approve the validation package
The validation summary, traceability matrix linking requirements to tests and results, deviation log and residual risk statement go to the quality unit and system owner for review. Approvers confirm that the evidence supports the stated intended use and that open items are acceptable or scheduled for resolution. Approval is recorded with signatures that follow the organization's own procedures. The system is released for GxP use only after this approval, and the release date and approved configuration baseline are documented.
Maintain change control for upgrades and releases
Every upgrade, including each new Documenso or DocuSeal release, passes through a documented change control process. The team assesses whether the change affects signing, record linking, audit trails or identity, selects the regression tests that must be repeated, and runs them in a non-production copy before production. Changes to certificates, identity providers and templates follow the same route. The change record, regression results and updated baseline are stored with the validation package. The process is complete when the approved state is re-established and documented after each change.

Evidence auditors ask for and which component produces it

What audit trail of signing events do auditors expect from a self-hosted signing platform?

The signing platform produces the primary audit trail: a time-stamped, attributable record of each event in the signing workflow, including document creation, sending, views, field completion, signing and completion. Auditors under 21 CFR Part 11 look for entries that show who acted, when they acted and what changed, and they expect those entries to be protected from alteration and retained with the record. Confirm with the vendor exactly which events are logged, whether the log is append-only, and how it is exported. Your quality team should also define how long audit entries are kept, since that period is set by your own record retention rules and not by the software.

Which system proves that a signer's identity was verified before credentials were issued?

The identity provider and your own onboarding procedure produce this evidence, not the signing platform alone. Part 11 requires the organization to verify a person's identity before assigning an electronic signature, so the records should show the verification method, the approver, the date and the account that was created or enabled. Those records typically come from HR or access request tickets, the directory and the identity provider's logs. The signing platform should then show a matching user account. Confirm how your identity provider exports provisioning and login events, and keep the verification procedure in a controlled document.

How do signature manifestations appear in human-readable copies of a signed record?

The signing platform generates the manifestation, and the document storage system must keep it intact. Under 21 CFR 11.50, a signed record must show the signer's printed name, the date and time of signing and the meaning of the signature, such as review, approval, responsibility or authorship. Those items must appear in any human-readable form of the record, including printed or PDF copies. Test this by generating a copy from the signed record and checking that each element is visible. Confirm with the vendor how the manifestation is rendered and whether it is included in exported PDFs.

What tests prove that each signature stays linked to its record?

Your validation team produces these tests, using evidence from the signing platform and the document system. Under 21 CFR 11.70, signatures must be linked to their records so they cannot be excised, copied or transferred to falsify a record by ordinary means. Test scripts should try to copy a signature onto another record, edit a signed document, and detect any change to a sealed file, then record the expected and actual results. The signing platform's signature hash or seal and the storage system's integrity checks provide the evidence. Keep the scripts, the outcomes and the deviations in your validation package.

Which access control and role records show who could sign or administer the system?

The identity provider, the signing platform's role settings and your access review process together produce these records. Auditors expect a current list of users, their roles, the signing rights granted to each role, and evidence of periodic review and removal of access when people change jobs. Export role assignments from the signing platform, export group membership from the identity provider, and keep dated review records signed by the system owner. Confirm which administrative actions the platform logs, because changes to roles and templates should be traceable as well as signing activity.

What certificate and key management records does a signing deployment need to keep?

The signing platform, the key management service or certificate store and your change records produce this evidence. Documenso requires a signing certificate to digitally sign documents, and its documented options include a self-signed .p12 certificate generated with OpenSSL or signing through Google Cloud KMS. Keep records of who generated or imported each certificate, its validity dates, where the private key is stored, who can access it, and each rotation or revocation. Confirm with your quality and security teams how keys are protected, and confirm with the vendor which signing approach your edition supports.

What backup and restore logs prove that signed records can be recovered?

Your infrastructure team produces backup and restore logs using the database, file storage and backup tooling you run. Signed records are only useful if the signature, its audit trail and the document can be restored together, so backups must cover the PostgreSQL or MySQL database used by the platform as well as the stored files and signing keys. Keep backup job logs, retention settings and dated restore test results that show a signed document, its audit trail and its verification data came back intact. Confirm the backup schedule and retention period with your quality and records owners.

Which change control and validation records must accompany each platform upgrade?

Your quality system produces these records, supported by the software release notes, your test evidence and deployment logs. Part 11 deployments are validated systems, so each upgrade of the signing platform, database or identity provider needs an impact assessment, a risk-based re-test of critical functions and an approved change record. Documenso published v2.20.0 on October 8, 2026, and DocuSeal published 3.3.2 on October 12, 2026, so a validation plan should state which version is in production and how each new release is assessed before deployment. The validation package remains your responsibility even when a partner performs the technical work.

What tooling alone does not satisfy under Part 11

Installing signing software does not make a GxP system compliant. Part 11 places obligations on the people and procedures around the platform, and those stay with the organization whether the signing service is Documenso, DocuSeal or a SaaS product. The organization still owns the written procedures that define who may sign which record, what each signature means, how signers are identified before accounts are issued, and how account reuse and reassignment are prevented under 21 CFR 11.100. It also owns the training records showing that signers and administrators understand those procedures, and the periodic review that checks whether the procedures still match how the system is actually used.

Validation is the largest item that no vendor can deliver on your behalf. You must document the intended use, risk-based test scope, installation and configuration records, and evidence that the signature manifestations, record linking and audit trail behave as your procedures require. Supplier assessment covers the open-source project, the Docker or Kubernetes images you pull, the PostgreSQL layer, and the signing certificate source. Confirm with the vendor which edition and release you are validating against, and plan a change control process for every upgrade. Your quality unit should decide whether the Enterprise edition, with its Part 11 compliance module, or another platform is the right fit before any validation effort starts, since the Community Edition does not include that module.

Two points are often confused. First, the FDA does not certify software or the signing platform as Part 11 compliant. Under 21 CFR 11.100(c), your organization certifies to the agency that electronic signatures used in the organization are the legal equivalent of handwritten signatures, and individual users may be asked to certify for specific signatures. Second, the EU and US rules overlap only where your records fall under both regimes, such as GxP data handled by an EU establishment. Confirm with your regulatory affairs team which requirements apply to each record set, and treat the EU overlay as a separate assessment rather than assuming one validation covers both.

Four gaps the software cannot close alone

Documenso and DocuSeal can capture signer names, timestamps, signature meanings and sealed PDFs, but Part 11 compliance also depends on the edition you license, the validation file you write, the identity checks you run before issuing a signature and the signing keys you hold. Each card below names one of these gaps and what to confirm before you commit.

Part 11 module and edition

Documenso lists 21 CFR Part 11 among its compliance references on its pricing page, but its self-hosted Community Edition offers only basic eSign compliance, and the Part 11 module is part of the Enterprise Edition. Confirm in writing which module, release and license terms cover Part 11 before you design around it. Ask whether the module's controls apply to your self-hosted build and what support you receive for it. DocuSeal's free on-premises edition also lacks SSO, so check your identity requirements against the edition you buy.

Validation documentation you own

Using a vendor's module does not validate your system. You must document the intended use, risk assessment, requirements, installation qualification, operational tests and the evidence that signature manifestations and record links behave as 21 CFR 11.50 and 11.70 describe in your environment. Plan the validation file for each release you upgrade, because a version change can alter behavior you already tested. Ask your quality team which change control and periodic review procedures they will require.

Identity proof before signature assignment

21 CFR 11.100 requires the organization to verify a person's identity before assigning an electronic signature, and that signature must never be reused or reassigned. Neither Documenso nor DocuSeal decides who a signer really is, so your HR or access process must feed the signing account. Document the verification method, the person who approved it and what happens when an employee leaves or changes role. Confirm how the platform disables accounts and whether deleted users keep their signature history.

Certificate and key custody

Documenso needs a signing certificate to digitally seal documents, and its documented options include a self-signed .p12 generated with OpenSSL or signing through Google Cloud KMS. Whoever holds the private key can alter what appears to be a sealed record, so decide where the key lives, who can access it, how it rotates and how it is backed up. Confirm that the certificate chain you use is accepted by your quality and legal teams, and test that a sealed PDF still verifies after a restore.

Questions GxP teams ask before implementing Part 11 e-signatures

Does the Enterprise edition change the cost and effort of a Part 11 deployment?

Yes, the Enterprise edition changes both the license line and the amount of work. Documenso's Enterprise edition adds full SSO, advanced compliance modules such as 21 CFR Part 11, custom email sender domains, support and an Adobe-approved signing certificate, according to its self-hosting announcement. Its pricing page lists custom Enterprise pricing and does not publish a figure, so ask the vendor for a written quote that names which modules are included. Compare that quote with the effort you would otherwise spend building and maintaining the same controls yourself, including SSO integration, signing certificate handling and validation of the module you rely on. Confirm with Documenso whether the Part 11 module is the one your validation plan will reference, and what version it is tested against.

How long does validation take, and what drives the duration?

Validation duration depends on the risk assessment, the number of signing workflows in scope and how much of the platform your quality team must test themselves. No duration figure is supplied for this work, so ask your validation partner and vendor for a scoped estimate. The main drivers are the number of distinct signature meanings (review, approval, authorship), whether signing certificates are generated internally or through a managed key service, how many integrations write signed records into a GxP system of record, and how many environments you need to qualify (development, test and production). Requirement traceability and the change control process your quality unit already runs often add more time than the software installation itself. Plan validation as a document and evidence project, not a technical task.

Can our internal IT team implement Part 11 e-signatures without an outside partner?

A capable IT team can deploy the software, but Part 11 readiness needs skills beyond deployment. Documenso ships Docker, Docker Compose, Kubernetes and manual installation options with a PostgreSQL database, so the install itself is familiar work for platform engineers. The harder parts are the controls around it: unique identity verification before a signer receives an account, signature-to-record linking, signing certificate choices, backups, audit trail retention and the validation package. Ask whether your team has done computer system validation before and whether it can own change control for the life of the system. An implementation partner can take on fixed-scope tasks such as configuration, integration and evidence preparation, while your quality unit keeps approval of the validation plan and final conclusions.

What does the work need from quality and IT teams?

Quality owns the intended use, the risk assessment, the requirements and the acceptance decisions, while IT owns the environment, identity, backups and change execution. Quality should define which records are GxP, which signature meanings each workflow uses, and which people may sign each record type, because 21 CFR 11.50 requires the printed name, date and time, and meaning of each signature. IT should provide the hosting environment, PostgreSQL administration, SSO or identity source, email for signer invitations and monitoring. Both teams need to agree on the change control procedure before the first configuration change, so that every later update to the platform is assessed for its effect on validated state. Put these responsibilities into the statement of work so neither side assumes the other is covering them.

Can DeployOpen prepare the validation evidence for our Part 11 system?

DeployOpen can prepare systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. In practice, that means configuring the self-hosted platform, documenting the controls you specify, preparing test and installation evidence, and hardening the environment under a written, fixed scope. Your quality unit still approves the validation documents, and FDA does not certify software, so any statement that a system is compliant comes from your own assessment and inspection record. Under 21 CFR 11.100, the organization must also certify to FDA that its electronic signatures are the legal equivalent of handwritten signatures, which is a company obligation that no implementation partner can perform for you. Ask for the evidence list in writing before work begins.

Does the AGPL license affect an internal Part 11 deployment?

For a deployment used only inside your organization, the AGPL-3.0 license generally does not require you to publish your configuration or internal workflows. Documenso is licensed under AGPL-3.0 and its README says the code stays open source to read, audit, run and fork. The license obligations that matter most arise when you modify the code and make it available to others over a network, so if you change Documenso source code, have counsel confirm what you owe for the modified version. DocuSeal is distributed under AGPLv3 with Section 7(b) additional terms, so check those terms as well. Your legal team should confirm the obligations for your specific use, especially if you plan to offer signing to customers, partners or other affiliated entities.

Does a self-hosted Part 11 system need to sign with a certificate?

Yes, Documenso needs a signing certificate to digitally sign documents, and the choice affects validation scope. Its documented options include a self-signed .p12 certificate generated with OpenSSL and signing through Google Cloud KMS. A self-signed certificate is simpler to set up but needs careful key custody and a clear trust model for the people who verify documents. A managed key service adds an external dependency that your validation must cover, including its availability and access logs. Decide which certificate model your signature meanings require before writing the validation plan, because changing it later means revalidating the signing path.

How DeployOpen scopes a Part 11 signing deployment

A Part 11 signing deployment starts with a written scope agreed before any work begins. DeployOpen's engagements are typically fixed-scope, so the scope document names the signing platform edition, the record types that will carry signatures, the identity provider, the signing certificate approach, the integration points with the quality or document system, and the environments in which the system will run. Quality, IT and the system owner should sign off on that document together, because each item in it becomes a validation boundary. Ask for the scope in writing, with the deliverables and acceptance criteria listed against each item, before accepting any quote.

Deliverables for this kind of work normally cover configuration, hardening, documentation and evidence preparation. Configuration includes the signing workflow, the signature meaning fields used for review, approval or responsibility, and the access model for signers and administrators. Hardening covers the server, database, transport encryption and audit logging of the self-hosted platform, which DocuSeal and Documenso both run on PostgreSQL in the standard setups documented by their maintainers. Documentation and evidence preparation give your quality function the specifications, configuration baselines, test scripts and traceability material it needs for its own validation. DeployOpen prepares these materials. It does not issue audit reports or certifications, and your independent auditors and certification bodies make their own determinations.

The organization's quality function approves the validation. It decides the intended use, the risk assessment, the acceptance of test results and whether the system is released for GxP records. Once the system is live, a retainer can cover upgrades, security patches and re-testing of affected functions after each release, which keeps the validated state current. Confirm with DeployOpen how change control will work for version upgrades such as new platform releases, and who re-executes the affected tests. Retainers are agreed separately from the fixed-scope build, so ask for the support scope, response expectations and upgrade handling in writing as well.

How DeployOpen delivers and supports Part 11 signing systems

DeployOpen plans, implements, hardens, documents and supports self-hosted signing platforms inside the client's own infrastructure, including the controls and evidence a Part 11 assessment will look for. We do not issue validation reports or certifications. The quality unit, system owners and independent auditors keep those decisions, and our work is organized so they can make them.

How we scope

Written scope names the signing platform, edition, record types and GxP processes covered before any work starts.
Scope lists which Part 11 signature manifestations and signature-record linking controls the system must meet, agreed with your quality team.
Scope states who owns the validation deliverables, so the split between DeployOpen work and your internal validation is written down.
Engagements are fixed-scope, with deliverables and timelines agreed in writing. Ongoing support is available as a retainer.

How we build

We deploy the platform in your cloud account, data center or air-gapped network, with access control and identity integration set up as specified.
We configure signing certificates, user identity verification steps and unique-signature assignment according to the agreed design.
We run security testing against the signing application and its APIs before the system is handed to validation.
Configuration is kept under version control so each change to the system can be traced to a documented request.

How we hand over

Handover includes system documentation, configuration records and the evidence set agreed in scope, ready for your validation team.
We document backup, restore and upgrade procedures so the system can be maintained in a controlled state after go-live.
Operators receive training on administration, signer account management and audit trail review for the agreed roles.
Your quality unit reviews and approves the validation package, since DeployOpen prepares evidence but does not validate or certify the system.

How we support

Ongoing support covers platform upgrades, patches and configuration changes, each assessed for validation impact before it is applied.
Continuous security testing can be added as a retainer, with findings tracked against the controls in the written scope.
Support requests follow a documented process, so changes to a validated state are approved and re-verified before release.
Ask any implementation partner to confirm how it will handle upgrades to Documenso or DocuSeal and what revalidation evidence it provides.