Can an agency keep Acrobat Sign or run Documenso or DocuSeal inside its boundary?
The answer depends on whether the signing service is a cloud service that the agency uses on its own behalf, and on who must own each control. If Acrobat Sign runs as a provider's shared service that handles federal information, the provider carries much of the authorization burden. If an agency runs Documenso or DocuSeal on infrastructure it controls, the question moves to the agency's own authorization boundary and to whoever operates the servers. Start by mapping each signing workflow to the data it touches: signer names, contract text, signing certificates and the audit trail. Then assign a named owner to every control that protects that data, from access management and logging to backups and retention.
In short, Adobe states that Acrobat Sign is FedRAMP Moderate authorized, so an agency or contractor that relies on it can draw on a provider-level authorization but must still document how its own tenant, users and retention settings are configured. Documenso is licensed under AGPL-3.0 and DocuSeal under AGPLv3 with Section 7(b) additional terms, and both can run inside the agency's boundary on servers the agency controls. Self-hosting does not bring an authorization with it. The agency, or the contractor, carries the authorization work itself. The facts available for this page do not establish a federal authorization status for either open-source option, so confirm the status in writing with the authorizing official and the project before treating any self-hosted deployment as authorized. Check whether the deployment falls within FedRAMP's scope rules for a single agency's own cloud system.
Plan the boundary work before the renewal date forces a decision. NIST SP 800-53B defines control baselines, and a moderate baseline selects 287 controls and enhancements, so the evidence for each selected control has to hold up to outside review. Under FISMA, an agency's Inspector General independently assesses system security and reports to OMB. Ask the Acrobat Sign provider for its current authorization package and the exact scope of the authorized service, including which signing and storage components sit inside it. For Documenso or DocuSeal, decide how signing certificates are issued and protected, where signed records are retained, and how audit trails are exported and kept, since those choices fall to the agency once the software is inside its boundary.
What federal rules require of a signing service
Federal requirements for a signing service depend on what data it touches and who operates it, not on the product name. The cards below cover the rules that most often decide whether a self-hosted signing platform sits inside an agency or contractor authorization boundary, and what to confirm before choosing between Acrobat Sign and a self-hosted option.
FedRAMP scope under M-24-15
FedRAMP covers cloud products and services that create, collect, process, store or maintain federal information on behalf of an agency. A system used only for one agency's operations on cloud infrastructure, and not offered as a shared service, falls outside that scope. A self-hosted Documenso or DocuSeal instance in the agency's own cloud account may therefore sit under the agency's own authorization rather than a FedRAMP package, but this is a determination the agency's authorizing official makes. Confirm the service model and who operates it in writing before you decide.
NIST SP 800-53 baseline selection
SP 800-53B selects control sets by impact level: low, moderate and high baselines contain 149, 287 and 370 controls and enhancements. The impact level comes from the data the signing service handles, such as signer identity, contract terms and audit trails. Pick the baseline during categorization, then map each control to a configuration, a log or a policy owned by a named person. Ask your authorizing team which baseline applies before you scope the platform.
FISMA oversight by Inspectors General
FISMA requires agencies to protect their systems, and Inspectors General independently assess that security and report results to OMB. For a self-hosted signing platform, the IG will ask who owns each control, where logs and audit trails are kept, and whether configuration changes are tracked. Acrobat Sign inherits some of that evidence from its provider, while a self-hosted deployment makes the agency the sole source. Plan evidence collection from day one so the assessment does not depend on memory.
CJIS v6.1 cryptography and scanning
Systems that handle criminal justice information fall under the FBI CJIS Security Policy. Version 6.1 requires FIPS 140-3 certified modules or FIPS 197 AES with at least 256-bit keys for CJI in transit and at rest outside physically secure locations, and vulnerability scanning at least monthly. A self-hosted signing service must therefore use validated cryptographic modules for its database, storage and TLS endpoints, and its scanning must cover the signing stack. Ask the CJIS Systems Officer which requirements apply to your data flows.
NIST SP 800-171 for CUI
Federal agencies that share controlled unclassified information with non-federal systems must use NIST SP 800-171 to set protection requirements, unless the CUI category's authority prescribes other safeguards. If a contractor or partner hosts a signing workflow that carries CUI, the hosting environment must meet those requirements. For defense contractors pursuing CMMC Level 2, a cloud service holding CUI must be FedRAMP Authorized at the Moderate baseline or meet equivalent requirements. Confirm the CUI category and the hosting boundary before you move any signed contract that references CUI.
Which option fits which boundary
Adobe states that Acrobat Sign is FedRAMP Moderate authorized, so the agency inherits part of its control coverage from a provider-maintained authorization instead of building it alone. The service runs in Adobe's environment, and the agency's job shifts toward verifying scope, reading the provider's package and documenting how its own users and records connect to that service. Federal scope rules under OMB M-24-15 cover cloud products that store or process federal information on behalf of an agency, so the agency should confirm that the authorization covers the specific service and data types it intends to use.
- Inherited controls: Confirm which SP 800-53 controls Adobe covers in its package and which remain the agency's responsibility.
- Authorization scope: Ask Adobe whether the Moderate authorization covers the exact Acrobat Sign offering, tenant configuration and data location the agency plans to use.
- Signing certificates: Ask Adobe who issues and holds the signing certificates and how audit trails are generated and retained.
- Records retention: Confirm export options and retention periods so records meet the agency's schedule without relying on the provider's default settings.
- Contract terms: Check incident notification, data return and subprocessor clauses in the agency contract.
Before relying on this option, ask Adobe for its current authorization documentation and confirm the scope in writing.
Documenso self-hosted inside the agency boundary keeps signing data, signer records and the audit trail on agency-controlled infrastructure. The agency owns the hosting, database, backups and access paths, so it also owns the controls that a FedRAMP-claimed service would otherwise provide. Documenso is licensed under AGPL-3.0 and supports Docker, Kubernetes and manual installation with PostgreSQL, which gives platform teams several deployment paths to match an approved architecture. The agency must still assemble the authorization evidence itself.
- Signing certificate: Documenso needs a signing certificate to digitally sign documents. Documented options include a self-signed .p12 certificate generated with OpenSSL or signing through Google Cloud KMS, and the agency must decide which option its policy accepts.
- Enterprise licensing for SSO: Documenso's Enterprise plan, with custom pricing, is offered for cloud or self-hosted setups, so SSO and compliance features are a licensing question to settle before deployment.
- Boundary work: The agency must document the system, its interconnections and its controls for its own authorization package.
- Operations: Patching, backups, logging and monitoring become agency duties.
- Compliance references: Documenso lists the ESIGN Act, UETA, 21 CFR Part 11, SOC 2 and HIPAA as references, which do not establish federal authorization.
Ask Documenso which edition and license include the SSO and support terms the agency needs, and confirm the certificate approach with the agency's authorizing official.
DocuSeal self-hosted inside the same boundary follows the same ownership model: the agency runs the platform, stores the data and builds the evidence. Its free on-premises edition runs from the docuseal/docuseal Docker image with SQLite by default, and PostgreSQL or MySQL can be set through DATABASE_URL, which matters for production records. The free edition does not include SSO, so an agency that requires SAML-based sign-in must evaluate On-Premises Pro. DocuSeal also includes PDF signature verification and an API and webhooks, which help with records checks and integration with agency systems.
- SSO requirement: SSO with SAML is a Pro feature, so the agency must budget for On-Premises Pro if federated sign-in is required.
- Database choice: Move from the default SQLite to PostgreSQL or MySQL through DATABASE_URL for shared production use, and confirm the backup approach.
- Signature verification: Use the PDF signature verification feature in the records review process and document how it is applied.
- Pro pricing components: On-Premises Pro lists $240 per user per year, and API and embedding usage is billed per completion, so the agency should ask for a quote covering its user count and volume.
- Certificates and authorization: As with Documenso, the agency must define its certificate approach and produce its own authorization evidence.
Ask DocuSeal which features its On-Premises Pro license includes, how it handles updates for air-gapped or restricted networks, and whether its terms fit federal procurement rules.
How to deploy Documenso inside an agency boundary
This sequence takes Documenso from a scoping decision with the authorizing official to a piloted, documented deployment inside the agency's own boundary. Each step ends with an output the ATO package can cite.
Confirm scope and data types with the authorizing official
The system owner and the authorizing official agree in writing which documents will be signed, which data types they contain, and whether any of it is controlled unclassified information or criminal justice information. This decides which baselines and requirements apply, including whether the CJIS Security Policy or the NIST SP 800-171 expectations for CUI on non-federal systems come into play. Confirm with your own compliance office that records such as wills, family law filings or court documents, which fall outside the ESIGN Act, are excluded from the workflow. Done when the scope statement is signed and lists data categories, users and signing types.
Select the hosting boundary and confirm cloud status
Choose where the Documenso servers, database and backups will run: an agency data center, an existing authorized enclave, or a cloud account the agency controls. If the deployment is a cloud service offered to multiple agencies, confirm FedRAMP applicability with the agency's authorizing body, since FedRAMP scope turns on whether the service is shared. Document the network zones, ingress paths and external dependencies such as email delivery. Done when a boundary diagram is approved and every component inside it has an owner.
Deploy Documenso with PostgreSQL from the official images
Your platform team deploys Documenso with Docker, Docker Compose, Kubernetes or a manual installation, using the official images from Docker Hub or the GitHub Container Registry and a PostgreSQL database. Pin image versions and record the digests, and build a change process for upgrades. Keep the database off public networks and restrict administrative access to named accounts. Done when the application runs in the staging enclave, the database accepts only application connections, and the deployed version matches the one recorded in the configuration baseline.
Configure the signing certificate and settle key management
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. The agency must decide whether either option meets its key management requirements, including who generates and holds the key, where it is stored, rotation and revocation. A self-signed certificate does not come from a qualified trust service provider, so confirm with counsel what evidentiary weight it carries for each record type. Done when the key decision is documented, the certificate is installed and a test document shows a valid signature.
Enforce encryption and monthly vulnerability scanning
Set TLS for all browser and API traffic and encryption at rest for the database, object storage and backups. Where the data is CJI, check the CJIS Security Policy's requirements for FIPS 140-3 validated modules or FIPS 197 AES at 256-bit keys, and confirm the choice with the authorizing official. Schedule authenticated vulnerability scans of the application, container images and host at least monthly, and track findings to remediation. Done when encryption settings are captured in configuration evidence and the first scan report is filed.
Set up logging, audit trail retention and backups
Forward application, authentication and administrative logs to the agency's central log platform, and confirm that the signing audit trail for each envelope is kept with the signed record. Apply the agency's records retention schedule to signed documents, audit data and logs. Configure encrypted database and file backups, and test a restore into an isolated environment before relying on it. Done when log forwarding is verified, a retention rule is applied and a restore test has been recorded with the time it took.
Build the ATO package and map controls
Map the deployment to the control families in NIST SP 800-53 Rev. 5 that match the agreed baseline, and record which controls the agency inherits, which Documenso and DocuSeal configuration satisfies, and which remain open. Assemble the system security plan, diagrams, configuration baseline, scan results, backup test and key management decision as one package for the authorizing official. DeployOpen can prepare these artifacts, but only the authorizing official grants authorization. Done when the package is accepted for review and open findings have owners and dates.
Run a controlled pilot with a limited user group
Run a pilot with a small set of named senders and signers on documents that the scope statement allows. Compare the signed output, certificate details and audit trail against the expected results, and check that email notifications and access controls behave as documented. Record defects, feedback and any gaps against the ATO package, then decide with the authorizing official whether to widen use. Done when the pilot report is filed, defects are closed or accepted in writing and the expansion decision is recorded.
Who owns the signing certificate and why it matters
Before an agency moves signing in-house, it should decide who owns the signing certificate, because a self-hosted Documenso operator has to supply one. Documenso needs a signing certificate to apply digital signatures to documents, and the documented options include a self-signed .p12 certificate generated with OpenSSL or signing through Google Cloud KMS. In either case the agency, not a signing service vendor, becomes responsible for the private key, its storage, rotation, expiry and revocation, and for how the certificate chains to a trusted root that relying parties recognize. Those become agency controls that an assessor will ask to see evidence for.
A managed certificate from an established e-signature provider moves much of that burden to the provider, which generally holds the keys, runs the issuing infrastructure and publishes the trust position. That convenience has a cost: the agency depends on the provider's practices and must collect that provider's assurance documentation rather than produce its own. Neither model is automatically stronger. A self-signed certificate is useful for internal workflows and testing but will not carry the same trust with outside parties unless the trust chain is established deliberately. Agencies should ask their assessor and records officer which certificate model their policies accept, and confirm with Documenso's SIGNING.md how each option is configured.
The eIDAS signature levels, which the European Commission describes as simple, advanced and qualified, are EU concepts. A qualified electronic signature depends on a qualified certificate from a qualified trust service provider listed in a national Trusted List, so the concept does not transfer to US federal use as-is. US agencies rely on the ESIGN Act's rule that electronic signatures cannot be denied effect solely for being electronic, and on their own authentication and record-keeping policies. Contractors working with EU partners should confirm with counsel whether any eIDAS-level signature is required for those transactions.
The work an ATO adds to a self-hosted signing service
Moving signing inside an agency or contractor boundary turns the platform into an information system that needs its own authorization. The items below are the components an authorizing official will expect to see documented, and each one depends on choices that the operator, not the software vendor, must make.
System security plan mapped to SP 800-53
The system security plan records how the signing service meets the control catalog at the baseline the authorizing body selects. NIST SP 800-53B defines low, moderate and high baselines, which select 149, 287 and 370 controls and enhancements respectively, so the baseline choice changes the workload more than any other single decision. Ask the authorizing body which baseline applies to the data the signing service will touch, then map each control to a named owner, a configuration or a document. Acrobat Sign's FedRAMP Moderate status covers Adobe's side of the boundary only, so the agency still owns the controls for its own hosting, identity and storage.
Continuous monitoring and vulnerability scanning
An ATO is not a one-time event. The operator must show a recurring cycle of vulnerability scanning, patching of the application, PostgreSQL or MySQL database, container images and host operating system, and review of configuration drift. If the signing service will hold Controlled Unclassified Information or criminal justice information, the stricter scanning frequency in those rules applies. Confirm the scanning tools, the patch windows and who reviews the results before the authorizing body asks.
Records retention for agreements and audit trails
A signed agreement and its audit trail are records, and the agency must decide how long each is kept, where it is stored, and how it is disposed of. The ESIGN Act says an electronic record may not be denied legal effect solely because it is electronic, but it does not remove the agency's own retention duties, and it excludes several record types such as wills and most of the Uniform Commercial Code. Design the retention schedule, the storage encryption and the legal hold process before go-live, and confirm the schedule with records officers and counsel.
Accessibility for public-facing signing pages
If members of the public sign documents through the platform, the signing pages and any mobile app are public-facing web content under the ADA Title II rule. That rule requires WCAG 2.1 Level A and AA conformance, with compliance dates of 26 April 2027 for entities serving 50,000 or more people and 26 April 2028 for smaller entities and special districts. Test the signing flow, the field builder and the email links with assistive technology, and document the results. Confirm the applicable compliance date for your entity with counsel.
Supply chain and AGPL license review
Documenso is licensed under AGPL-3.0 and DocuSeal under AGPLv3 with Section 7(b) additional terms. Agencies and contractors should have counsel confirm how those terms apply if the platform is modified, offered to users over a network, or combined with other code, and whether any change must be published. The review should also cover the container images, base images, npm and other dependencies, and a software bill of materials that is refreshed at each upgrade. Pin versions and record the source of every image before the assessment.
Independent assessment and authorization decision
An independent assessor tests the controls against the system security plan, and the authorizing official decides whether the residual risk is acceptable. DeployOpen can prepare the system, configuration evidence and test results, but it does not issue audit reports, attestations or authorizations, and the agency or its assessor makes the final call. Ask the authorizing body early which assessment method it accepts, what evidence format it requires, and whether an existing FedRAMP package can be reused for the platform components.
What does a government signing deployment cost and take?
What cost components make up a self-hosted government signing deployment?
The cost has five parts: the software license or free edition, the hosting inside your boundary, staff time to install and operate the platform, the independent assessment work, and operating the signing certificate. The software line can be zero, since the Documenso and DocuSeal community editions are free to run. The larger costs are usually labor and assessment, and the cloud or data center capacity you already pay for is often reused. Ask any vendor or integrator to price each component separately so you can compare them with your current Acrobat Sign spend.
Which signing costs are one-time and which recur every year?
Setup is mostly one-time: installing the platform, configuring the database and certificate, building templates, integrating with identity and storage, and producing the security documentation for your authorization package. Recurring costs include patching and upgrades, backups and restore testing, monitoring, periodic vulnerability scanning, renewed certificates, reassessment when the system changes, and staff time for user support. Software licenses are recurring only if you choose a paid tier. Plan for the recurring portion to be the larger share over the life of the system.
What does Documenso's cloud pricing show about licensing costs?
Documenso's cloud pricing, as read in October 2026, lists a Free tier with 5 documents per month, Individual at $25 per month, Teams at $40 per month for 5 users plus $8 per extra user, and Platform at $250 per month with unlimited users and API. These are hosted prices, so they do not describe your own deployment. The self-hosted community software is licensed under AGPL-3.0, and Enterprise licensing for self-hosted setups is quoted separately. Confirm with Documenso which features your agency needs before choosing a paid tier.
How much does DocuSeal's on-premises Pro edition cost?
DocuSeal's pricing page, as read in October 2026, lists On-Premises Open Source as free and On-Premises Pro at $240 per user per year, or $20 per user per month billed annually. Pro adds SSO with SAML, unlimited bulk send, white-label, and embedded signing, which charges $0.20 per completion. Multiply the per-user figure by the number of staff who need Pro features, then add completion charges if you use embedded signing. Ask DocuSeal to confirm whether these terms apply to your agency's procurement rules.
Can a government agency run this deployment in-house?
Often yes, if you already operate containers, a PostgreSQL or MySQL database, and identity integration, and your security team can run the assessment package. The main capabilities an in-house team must cover are platform administration, certificate lifecycle management, backups, vulnerability management, logging, and change control under your authorization boundary. Gaps usually appear in the assessment paperwork and in certificate or key handling, not in installing the software. Be honest about staff capacity before committing, because the recurring operating work does not stop after go-live.
What does the agency need to provide for a self-hosted signing deployment?
The agency must supply the hosting boundary, identity provider, database and storage, network controls, a named system owner, and access to the staff who will approve the system's security plan. It also needs decisions on records retention, which signer data is collected, and who holds signing keys. Your authorizing official and assessor will expect documented roles and evidence. Ask any partner to list these inputs in writing before work starts so the agency can confirm it has the people and approvals ready.
Does a fixed-scope engagement fit a government signing project?
A fixed-scope engagement fits well when the agency can define the boundary, the platform version, the integrations, and the deliverables before work starts. DeployOpen works this way for most engagements: scope, deliverables, and timelines are agreed in writing before work begins, and a quote follows from that scope. Ongoing support, upgrades, and continuous testing can be handled through a retainer after the initial work. Ask for the scope to name which assessment artifacts are included and which remain with the agency.
Is Documenso or DocuSeal the better fit for PDF forms?
DocuSeal is generally the stronger fit for PDF forms that need to be filled and signed, because it includes a WYSIWYG PDF form field builder, PDF signature verification, and an API and webhooks for integrations. Documenso is a strong choice when the priority is document signing workflows, templates, and a signing certificate you operate, with its own API. Test both with a sample form from your records office, and confirm which edition each required feature needs before deciding.
How records retention changes when signing moves on premises
When signing moves on premises, the agency becomes responsible for keeping signed documents, audit trails and signer data for the full retention period its records schedule requires. Acrobat Sign stores that material in Adobe's environment today, so the agency's retention plan may rely on a vendor copy it never had to manage. With Documenso or DocuSeal, the completed PDFs, the certificate of completion or audit record, and the signer fields in the PostgreSQL or SQLite database all sit on servers the agency operates. Decide which system is the record copy, where backups of that database and file store go, who can delete or alter them, and how holds for litigation or audit are applied. Those are records management decisions, not configuration defaults.
The ESIGN Act provides that a signature, contract or record relating to a transaction in or affecting interstate or foreign commerce may not be denied legal effect solely because it is electronic (15 U.S.C. 7001(a)). That general rule does not settle retention. Section 7003 excludes several categories, including records governed by laws on wills, codicils and testamentary trusts, state family law such as adoption and divorce, most of the Uniform Commercial Code, and court orders and official court documents. Agencies handling those records must follow their own statutes and rules for form, signature and retention, which may still require paper originals, wet signatures or specific custody. Build a list of record series that fall into these categories so that signing on premises does not silently change how they are kept.
Before go-live, confirm the retention schedule for each signing workflow with the agency records officer and, where needed, agency counsel. Ask which series are permanent, which carry a fixed term, and whether the agency must keep the signing certificate details, verification results and audit history alongside the PDF. Test restoration of a completed envelope from backup, including its audit trail, and record how long that takes. Retention rules and the ESIGN Act exceptions are interpretive questions for the agency, so write the answers into the signing procedure and keep a dated record of who approved them.
How DeployOpen deploys signing inside an agency boundary
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including cloud accounts, data centers and air-gapped networks. For agencies and contractors weighing Documenso or DocuSeal against a FedRAMP-authorized service, we start by mapping which controls the agency would own, then build and document only what the written scope covers.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope maps signing workflows, signer data, retention needs and the boundary the system must sit inside.
- Scope records which control responsibilities move to the agency, so the authorization package reflects who actually owns each one.
How we build
- We install Documenso or DocuSeal in your environment using the documented Docker, Compose, Kubernetes or manual paths, with PostgreSQL as the database.
- We configure the signing certificate your own policy requires, such as a self-signed certificate or a key managed through your chosen KMS.
- We test access control, audit logging, encryption settings and backup restores against the written scope before handover.
How we hand over
- You receive configuration records, architecture diagrams, runbooks and evidence that map to the controls named in scope.
- We document what the platform does not provide, such as any authorization status, so your assessors can judge it accurately.
- Knowledge transfer covers operating, patching and upgrading the platform, so your staff can run it after handover.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover tracking new Documenso and DocuSeal releases, testing upgrades and refreshing evidence for reassessment.
- DeployOpen prepares systems and evidence for compliance assessments, while independent assessors and authorizing officials make the determinations.
