Open source e-signature for education

Open source e-signature for education: why campus signing is different

Registrars, HR teams and district offices send enrollment forms, staff contracts and parental consents that carry student records and minors' data, often to an entire cohort at once. A self-hosted Documenso or DocuSeal deployment can fit this work if the institution controls the hosting, the identity layer and the retention rules, and the edition choice turns mainly on two things: bulk sending from a spreadsheet and single sign-on. The free DocuSeal on-premises edition has no SSO or bulk send, while DocuSeal's On-Premises Pro adds both, so a cohort-scale campus usually needs a paid edition before it goes live.

Three federal rules shape the design. FERPA (34 CFR Part 99) governs education records and requires institutions to log each disclosure of personally identifiable information, and it lets an outside contractor handle records only under direct institutional control. COPPA (16 CFR Part 312) applies where operators collect personal information from children under 13, which can include K-12 vendors and some signing flows, and it requires a written retention policy with a deletion timeframe. GLBA's Safeguards Rule (16 CFR Part 314) reaches institutions that participate in Title IV aid, and it requires multi-factor authentication for anyone accessing an information system.

DeployOpen prepares systems, controls and evidence for these assessments, but it does not issue audit reports or certifications, and independent auditors make that determination. Before scoping, confirm with counsel which of these rules apply to each form type, then confirm with the platform vendor which edition provides the SSO and bulk send your design needs. Ask a partner to show where each disclosure is logged and how the signed record is retained.

Which education rules change the signing build

This table maps the federal education, children's privacy and safeguards rules to specific decisions for a self-hosted signing platform, its database and its audit trail. Read each row as a build requirement: the rule, what it means for the signing service, and the evidence a reviewer will ask to see. Most schools will find the access controls, disclosure logging and retention rows drive the most design work.

Requirement	What it means for the signing build	Evidence to keep
School official access (34 CFR 99.31(a)(1))	Limit signing platform roles to staff with a legitimate educational interest. Vendor or contractor operators need a written agreement that places them under the institution's direct control.	Role matrix, access reviews and the contract terms on control and redisclosure
Disclosure record (34 CFR 99.32)	Log each access to and disclosure of student personally identifiable information in signed forms, including the party and their interest. Keep these entries for as long as the records exist.	Disclosure log schema, retention setting and sample log exports
Inspection requests (34 CFR 99.10(b))	Make signed enrollment and consent records findable by student so the registrar can meet a request within 45 days of receipt.	Documented search procedure and test retrieval by student identifier
Enforcement exposure (34 CFR 99.67)	Noncompliance can lead to withheld federal funds or termination of funding eligibility, so the signing platform belongs in the institution's FERPA review.	Records of FERPA review that include the signing platform
Children's data retention (16 CFR 312.10, COPPA)	For personal information from children under 13 collected through signing links, define a retention period, delete on schedule and document the reason for each category kept.	Written retention policy, deletion job configuration and deletion logs
Written security program and risk assessment (16 CFR 312.8, COPPA)	Name a program coordinator and run at least annual risk assessments covering the signing service, its database and file storage.	Coordinator designation, annual risk assessment reports and remediation tracking
Safeguards program and MFA (16 CFR 314.4, GLBA)	Institutions in Title IV programs must keep a written information security program and require multi-factor authentication for anyone accessing an information system, including signing administrators.	MFA enforcement settings, admin account inventory and program documentation
FTC notice (16 CFR 314.4(j), GLBA)	If a notification event affects at least 500 consumers, notify the FTC within 30 days of discovery. Audit logs must be able to show when the event was found.	Incident runbook with a discovery timestamp, log retention and notice template

Which student data ends up inside signed documents

Every signed document carries more student data than the form itself shows. An enrollment packet typically includes the student's name, date of birth, address, guardian details, medical or emergency information and sometimes a government identifier, all embedded as form field values inside the PDF. A parental consent for a child under 13 adds the child's name and the parent's signer email address. A staff contract carries the employee's home address, salary and bank details. Each completed envelope also produces an audit record with signer email addresses, IP addresses and timestamps for every view and signature event, and any uploaded attachments such as birth certificates or immunization records are stored alongside. Before rollout, map each template field to a category your institution has already defined, and confirm with your registrar and general counsel which of these records count as education records under your own policies and under the institution's FERPA annotation.

Both the signed PDFs and the application database become regulated stores. With DocuSeal, the default SQLite file holds envelope metadata, field values and audit events unless you point DATABASE_URL at PostgreSQL or MySQL, and Documenso uses PostgreSQL. Signed files, signer records and the database backups that copy them all need the same access controls, encryption and retention rules as the source system. Under FERPA, the institution must keep a record of each disclosure of personally identifiable information from education records (34 CFR 99.32), and a contractor hosting the platform may only receive those records as a school official under the institution's direct control (34 CFR 99.31(a)(1)(i)(B)). Where a child under 13 is the data subject, the COPPA Rule requires a written data retention policy with a deletion timeframe (16 CFR 312.10), so retention settings in the platform must match that policy rather than default to keeping everything.

Which DocuSeal or Documenso edition covers education needs

For education, cohort bulk sending and campus single sign-on usually decide the edition before anything else does. The four options below differ mainly in whether those two features, white-labeling and vendor licensing are included, so check each against the feature list for the version you plan to run.

DocuSeal free on-premises edition

The free on-premises edition runs from the docuseal/docuseal Docker image with SQLite by default, or PostgreSQL or MySQL through DATABASE_URL. It covers the core signing, form building and PDF verification needs of a small office. It has no SSO, no bulk send and no embedded signing, so a district sending enrollment packets to a full cohort or signing in through campus identity will need a different edition. Confirm the feature set for your release before you plan the workflow.

DocuSeal On-Premises Pro

This is the edition most campuses will evaluate for cohort work. On-Premises Pro adds SSO with SAML, bulk send from CSV or XLSX, unlimited bulk send, and white-label branding for the institution. The listed price is $240 per user per year, which is $20 per user per month billed annually, so the cost scales with the number of staff who send documents. Ask the vendor whether SAML works with your identity provider and how bulk send handles large rosters.

Documenso self-hosted under AGPL-3.0

Documenso is licensed under AGPL-3.0 and can run on Docker, Docker Compose, Railway, Kubernetes or a manual install, with a PostgreSQL database. Institutions with an existing container platform can deploy it there and keep enrollment and consent data on their own infrastructure. Plan the signing certificate early, since documented options include a self-signed .p12 certificate created with OpenSSL or signing through Google Cloud KMS. Confirm which bulk-send and SSO features your edition includes before you commit.

Documenso Enterprise licensing

Documenso offers an Enterprise plan with custom pricing for cloud or self-hosted setups, and self-hosted licensing is handled through its self-hosting page. This route suits a university or district that needs a contract, support terms or features beyond the open-source build. Request a written list of included features, support hours and renewal terms, and compare that list with the cohort and SSO requirements that came out of your scope.

How deployment differs for a district versus a university

A district usually has a small central IT team that runs student information, finance and network services for many schools. A self-hosted signing service placed in a district data center or private cloud subscription keeps enrollment forms and parental consents inside the district's control, which matters when state student data rules require that records stay within defined boundaries. Documenso runs on PostgreSQL, and DocuSeal runs on SQLite by default or on PostgreSQL or MySQL through the DATABASE_URL variable, so the district should choose a managed or well-backed database in the same environment as the application rather than a single local file.

Database placement: Keep the PostgreSQL or MySQL instance in the district's own environment or the private subscription, with encrypted backups stored in the same jurisdiction.
Object storage: Confirm where uploaded PDFs and completed documents are written, and whether the vendor, hosting provider or subprocessor can read them.
SMTP relay: Use a district-controlled relay so signer invitations and reminders leave through a domain the district manages and can monitor.
Signer links: Decide whether guardians reach the service through a public hostname with TLS and rate limits, or through a controlled portal, since most guardians sign from home.
Signing certificate: Keep the self-signed .p12 file, generated with OpenSSL, or the Google Cloud KMS key in a location the district's security team administers, with access logged.

Confirm with your state education agency and legal counsel which storage locations and subprocessors the student data rules permit before choosing a hosting provider.

How a campus e-signature rollout runs

This sequence takes a university or district from a records inventory to a supported signing service that handles enrollment forms, staff contracts and parental consents under the institution's own control. Each phase closes with a written output that the registrar, general counsel and IT leadership can review before the next phase starts.

Classify data and map records with the registrar
Start with a records inventory led by the registrar and general counsel, listing each form type (enrollment, staff contract, parental consent), the personal data it carries, who may view it, and how long it must be kept. Mark which documents contain education records under FERPA and which involve children under 13, since those trigger different obligations. The step is complete when the inventory is signed off and every document type has an owner, a classification and a retention rule.
Choose the edition and confirm licensing
Compare what the free on-premises edition covers against what the campus needs, such as SSO, bulk send from a CSV roster, and embedded signing for the student information system. Confirm with the vendor which features sit behind the Pro or Enterprise tier and how licenses are counted for staff and student users. The output is a short decision record stating the chosen edition, the features it depends on, and the open licensing questions with vendor answers attached.
Design hosting, MFA and campus SSO
Define where the service runs inside the institution's own cloud account or data center, how it is reached from the public internet, and how administrators and signers authenticate. Plan multi-factor authentication for all administrative access, and confirm which SSO protocol the chosen edition supports for campus identity. Document access roles so that school officials see only the records tied to their legitimate educational interest. The output is a configuration baseline covering network placement, identity flow, role matrix and backup location.
Pilot templates and CSV cohort sending
Build the enrollment, staff contract and parental consent templates, then test a bulk send from a CSV file with a small group chosen by the registrar, such as one department and one parent cohort. Check field validation, conditional fields, reminder behavior and how signer invitations arrive in campus mail. Collect feedback from pilot users and correct errors before scaling. The output is a tested template set and a pilot log recording every issue found, its fix and the retest result.
Validate signing certificates and audit exports
Configure the signing certificate method selected for the institution, which may be a self-signed certificate or a key managed in a cloud key service, and confirm with counsel what signature level the documents need. Generate test signatures, verify them with a PDF validator, and export the audit trail to confirm it records signer identity, timestamps and document hashes. Ask the institution's records officer to review a sample export against its retention requirements. The output is a tested audit export and a written note on what the certificate does and does not establish.
Go live with retention and deletion settings
Enable production access in phases, starting with the pilot groups and expanding to other departments once the first cohort completes without defects. Apply the retention periods and deletion schedules from the records inventory, and confirm that student data subject to COPPA is removed after the defined purpose ends. Log access to education records so the institution can answer disclosure requests. The output is a go-live checklist signed by the registrar and IT lead, plus a verified retention and deletion configuration.
Run post-launch support and periodic review
Agree on who responds to signer problems, template changes, certificate renewals and security updates, and how quickly each category is handled. Review the access roles, audit exports and retention settings on a schedule set by the institution, and retest after every platform upgrade. Keep the records inventory current as new form types appear. The output is a support runbook, an upgrade and review calendar, and a log of changes that the registrar and general counsel can inspect.

How the signing platform connects to campus systems

Can campus single sign-on through SAML protect who signs in to the signing platform?

SAML single sign-on is a Pro feature in DocuSeal, and the free on-premises edition does not include SSO, so confirm the edition before you plan identity. With On-Premises Pro, the campus identity provider authenticates staff, and the signing platform receives an assertion instead of holding its own passwords for those users. The control that matters is account lifecycle: when an employee leaves, disabling the directory account should stop access to the signing platform, and admin roles should map only to named campus groups. Also confirm how the edition handles signer access, since external parents and applicants sign through invitation links rather than campus accounts. Ask your identity team to test SAML with a sample group before rollout, and confirm the attribute mapping with your DocuSeal partner.

How does a student information system send enrollment data to DocuSeal through the API?

The SIS or HR system calls the DocuSeal API to create submissions from a template and pre-fill known fields, then DocuSeal sends webhooks when a document is viewed, signed or completed. The data moving includes student or staff identifiers, names, contact details and the completed PDF, so limit the payload to fields the form needs and keep the integration account scoped to one template group. Use webhooks to write only a status and document reference back to the SIS, not the full signed file. Store the API key in a secrets manager and rotate it on a schedule. Confirm with your SIS vendor whether it has a native connector, supports outbound webhooks, and can reach your DocuSeal host over the campus network.

What should a bulk send from a CSV or XLSX roster include?

Bulk send takes a roster file and creates one submission per row, which suits cohort consent forms and annual enrollment packets. Bulk send is part of On-Premises Pro, with unlimited bulk send, while the free edition does not include it. The roster carries personal data about minors, so keep only the columns the form needs, such as name, guardian email and cohort code, and delete the file from shared drives after the send. Check each row for duplicates and invalid addresses before sending, because a wrong guardian address exposes a child's record to the wrong person. Run a small test cohort first, and confirm with your administrators how the roster file is stored and who can upload it.

How should signer invitation emails be delivered from campus infrastructure?

Signer invitations leave the platform as email, so the mail path needs its own design. Connect DocuSeal to an SMTP relay that your campus mail team operates, such as a relay on your own domain, and configure SPF, DKIM and DMARC for that domain so guardians and staff receive invitations rather than spam-folder messages. Keep invitation text generic and avoid putting student names or grades in subject lines. Confirm with your mail administrators which relay addresses are allowed, whether outbound mail to external guardians is permitted, and how bounces are reported back to the signing administrator. Deliverability to personal email providers depends on the domain configuration, so test with several providers before a large send.

How do signing platform logs reach the campus SIEM?

Application and audit logs from the signing platform should reach the campus SIEM so that access to records containing student data can be reviewed. Relevant events include sign-ins, template and document access, bulk sends, API key use and admin changes. Forward logs over an encrypted channel, such as syslog over TLS or a log shipper agent, and restrict who can change the forwarding configuration. Confirm with your security team which fields the SIEM needs, how long logs are retained, and whether the signing database audit trail can be exported on demand. Keep signed documents and logs in separate stores so that log access does not expose student records by default.

Which campus data must stay out of the webhook and API traffic?

Webhooks and API responses should carry identifiers and status, not the full content of education records. The minimum set is a document ID, template ID, status, timestamp and a reference the SIS can look up, while names, grades, health notes and disciplinary details stay in the source system. This limit supports the FERPA rule that a school official receives records only for legitimate educational interests, which is enforced through access controls on the integration as well as the platform. Log every disclosure to an outside party, because FERPA requires a record of each disclosure of personally identifiable information. Ask your registrar and legal office to approve the payload schema before the integration goes live.

Does a SIS or HR vendor integration need custom development on our side?

The DocuSeal API and webhooks support custom integration, so the work depends on whether your SIS or HR vendor already offers a connector. Where no connector exists, a developer writes a small service that maps records to templates, calls the API and handles webhook events. The cost components are the integration build, testing against a staging copy of the SIS, the edition license for API and embedded use, and ongoing maintenance when either system changes. DocuSeal's API and embedding usage is priced separately in its cloud plans, so check which fees apply to your self-hosted setup. Ask the vendor and your partner for a written scope that lists each endpoint, field and event before any work starts.

Can DeployOpen implement these campus integrations for us?

DeployOpen plans, implements, customizes, integrates, hardens and supports self-hosted open-source platforms inside the client's own infrastructure. For this use case, that can cover SAML configuration where the edition supports it, the SMTP relay path, bulk send templates, the SIS integration service, and log forwarding to your SIEM. Most engagements are fixed-scope, so the written scope should name the SIS vendor, the edition, the identity provider and each integration point before the quote is issued. DeployOpen does not publish a price list, and a quote follows from that scope. Your campus teams still own the SIS data, the directory and the retention decisions.

What auditors and regulators will ask to see

This table maps the records an institution's auditors or regulators are likely to request for a self-hosted signing workflow to the component that produces each record. Use it to plan logging and retention before go-live, not after a request arrives. The institution's auditors and counsel make the final determination of what satisfies each requirement.

Evidence item	What it shows and which requirement it relates to	Component that produces it and where it usually fails
FERPA disclosure record	Each request for and disclosure of personally identifiable student information, with the parties and their legitimate interests, kept as long as the records are kept (34 CFR 99.32)	Application audit log and database. Fails when signing events are logged but the recipient's role and purpose are not recorded
School official designations	Written evidence that each contractor or vendor receiving education records is under direct institutional control and bound by redisclosure limits (34 CFR 99.31(a)(1)(i)(B))	Contract file and vendor register, linked to user roles in the platform. Fails when the designation is signed but not mapped to accounts
Role-based access to signed records	Access restricted to school officials with a legitimate educational interest, using technical access controls (34 CFR 99.31(a)(1)(ii))	Platform role configuration and database permission exports. Fails when staff with broad admin roles can view all enrollment packets
MFA configuration for administrators and staff	Multi-factor authentication for anyone accessing an information system under the GLBA Safeguards Rule (16 CFR 314.4(c)(5))	Identity provider policy and SSO logs, plus reverse proxy logs. Fails when local accounts bypass campus SSO
Retention and deletion settings for children's data	A written retention policy with a deletion timeframe, and no indefinite retention of children's personal information (16 CFR 312.10)	Scheduled jobs, database retention settings and deletion logs. Fails when completed parental consents remain in backups with no deletion schedule
Written information security program	A documented program with a designated coordinator and periodic risk assessments, as the GLBA Safeguards Rule requires for institutions in Title IV programs	Governance documents and risk register, supported by configuration baselines. Fails when the program describes controls the platform does not actually enforce
PDF signature verification output	Evidence that each signed PDF validates, showing the signer, signing time and certificate status	Signing service and verification step output, kept with the document hash. Fails when the signing certificate is self-signed and trust is not explained to reviewers
Access and event logs for signed packets	Records of who opened, signed or downloaded a document, supporting audit controls over systems that hold student data	Audit log in the platform, forwarded to a SIEM. Fails when logs roll over before the institution's review cycle

What to ask an implementation partner for a campus rollout

Start by asking how the partner handles FERPA school official designations in the technical configuration, not only in the contract. Ask who in the partner's team has configured role-based access for an outside party that receives education records, and how they would show that the platform limits each signing administrator to the records in which they have a legitimate educational interest. Ask for a sample access matrix from a prior project, with the roles, the groups used to scope them, and the audit log entries produced when a record is viewed or downloaded. Under 34 CFR 99.32, the institution must be able to reconstruct who received what from its records, so ask how the partner configures logging on the signing platform and where those logs are retained. Next, ask the partner to confirm edition features before any scope is written. Bulk send from CSV or XLSX, SSO with SAML and embedded signing are not all in the same DocuSeal edition, and the free on-premises edition does not include SSO or bulk send according to the DocuSeal pricing page. Ask the partner to name the edition, the licence terms that apply to your use, and the exact features they tested in a comparable environment. Request written confirmation of how the campus identity provider will be connected, and whether the partner has verified the SAML attribute mapping for staff and parents, who may not share the same identity source. Also ask how the signing certificate is generated and rotated. For Documenso, the documented options include a self-signed .p12 certificate created with OpenSSL or signing through Google Cloud KMS, so ask which option they recommend for your institution, who holds the private key, where it is stored, and how the rotation date and the process for re-signing or re-verifying older PDFs are recorded. Finally, ask how the partner handles retention and deletion for children's data, since COPPA retention rules under 16 CFR 312.10 apply to operators collecting personal information from children under 13, and parental consent forms may fall in that scope. Ask for the default retention settings they would propose, how they would document the written data retention policy, and who is responsible for running deletions. Public institutions should also ask whether the partner runs accessibility checks against 28 CFR Part 35 Subpart H on signing pages and templates, and what evidence they provide. Close by asking how the fixed-scope work will be written, what happens to open items after go-live, and what support or retainer terms apply.

How much does campus e-signature cost to implement, and what does it need from us?

What are the main cost components of self-hosted campus e-signature?

Total cost comes from five components: edition licenses, per-completion fees, infrastructure, signing certificates, and implementation and testing. Licenses are the only recurring line that scales with headcount. DocuSeal's pricing page lists On-Premises Pro at $240 per user per year ($20 per user per month billed annually), and its free On-Premises Open Source edition has no SSO, bulk send or embedded signing. Documenso's self-hosted options are offered through its Enterprise plan with custom pricing. Per-completion fees apply to embedded signing and API usage on DocuSeal's paid tiers at $0.20 per completion, so confirm whether your integrations trigger them. Infrastructure, certificates and implementation are mostly one-time or annual costs that you should ask for as separate line items in any quote.

Can a campus IT team implement self-hosted e-signature without a partner?

A capable team can deploy the software, but the hard parts are usually SSO, records governance and integration with the student information system. Both Documenso and DocuSeal ship as Docker images and use PostgreSQL, with DocuSeal also supporting MySQL and SQLite by default, so the install itself is standard container work. The effort goes into SAML configuration for campus identity, signing certificate setup, role mapping for registrars and HR, and testing bulk sends against real cohort files. Because FERPA requires a record of each disclosure and reasonable access controls, the records owner must approve the design. Confirm internally whether you have staff for those tasks before deciding between self-implementation and a fixed-scope engagement.

How much does SSO and SIS integration change the implementation timeline?

SSO and SIS work usually sets the timeline, because signing is quick to configure once identity and data feeds are settled. DocuSeal's free edition has no SSO, so campuses that require campus login must plan for On-Premises Pro or another supported path, and that decision should come first. Roster and enrollment data must reach the platform in a format the bulk sender accepts, such as CSV or XLSX, and each feed needs a named owner and a change process. Campus identity providers and SIS vendors often have their own approval cycles, which can run longer than the software work. We do not state a duration here. Ask any partner for a written timeline that lists each dependency and who is responsible for it.

What does our team need to provide before implementation starts?

Your team must supply decisions and access, not just budget. The main inputs are:

Records owner sign-off on which forms are signed, who may see completed documents, and how long each form is kept, because FERPA requires institutions to keep a record of disclosures for as long as the records are kept.
Identity provider SAML metadata and an agreed attribute mapping for roles such as registrar, HR and parent.
Sample roster and enrollment files in the exact CSV or XLSX layout used for bulk sending, including the fields that identify each student.
Hosting details for the server, database, domain names and mail relay used for signer invitations.
A named signing certificate owner and a decision on the certificate approach documented by the vendor.

Confirm these inputs in writing before work begins so that each one has a date and an owner.

Will DeployOpen give a written price before work starts?

Yes, the engagement is fixed-scope, and scope, deliverables and timelines are agreed in writing before work starts. DeployOpen does not publish a price list, so the quote follows from that written scope. Ask for the quote to separate implementation, testing, documentation, any retainer for upgrades and support, and third-party license costs, which DeployOpen does not set. Ask the vendor separately for current edition pricing, because the figures in public price pages can change. Confirm with us which parts of the scope are one-time and which are recurring before you sign.

Is DocuSeal's free edition enough for a small school district?

It may cover basic signing, but it is unlikely to cover a district that needs campus login or bulk sending. The free On-Premises Open Source edition is listed as free and has no SSO, bulk send or embedded signing. Bulk send from CSV or XLSX, which is the core need for enrollment packets and parental consents across a cohort, appears in On-Premises Pro, which lists unlimited bulk send at $240 per user per year. Districts should first check whether manual sending for a small number of forms is acceptable and whether staff can accept local accounts in place of SSO. Confirm current edition features with DocuSeal before deciding, because the free tier may not meet your identity or records requirements.

What should we confirm about signing certificates and infrastructure costs?

Confirm the certificate approach and who operates it before you size infrastructure. Documenso needs a signing certificate to digitally sign documents and documents options such as a self-signed .p12 certificate generated with OpenSSL, or signing through Google Cloud KMS. Choosing a self-signed certificate keeps costs low but may not meet the trust expectations of parents, auditors or counterparties, so ask your records and legal teams to decide. Infrastructure costs depend on your cloud or data center standards, backup needs and expected volume, and we cannot state a figure from our side. Ask any vendor or partner to list server, database, backup, storage and monitoring as separate items with their recurring cost.

What does ongoing support add to the total cost of ownership?

Ongoing support adds recurring cost for upgrades, security patches, backup testing and user changes. Both platforms release new versions regularly, and DocuSeal 3.3.2 and Documenso v2.20.0 are recent examples, so someone must apply updates and test them. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, and we can scope them alongside the initial build. Ask for the response expectations in writing and confirm whether staff time for regular tasks, such as onboarding new cohorts and rotating certificates, is included. Compare this recurring line with the per-user and per-completion fees that a SaaS signing service would charge at your volume.

How DeployOpen scopes and supports campus e-signature

DeployOpen scopes every campus e-signature engagement as a fixed-scope project, with the scope, deliverables and timeline agreed in writing before work starts. For a university or district, that written scope should name each form family in play (enrollment packets, staff contracts, parental consents), the signing groups and bulk sending volumes, which identity provider handles campus SSO, the integrations with the student information system or HR system, and whether the platform is the Documenso or DocuSeal edition the institution has chosen. Confirm in the scope which features the chosen edition actually includes. DocuSeal's free on-premises edition has no SSO or bulk send, so a campus that needs either must price On-Premises Pro into the written scope from the start. Ask for the quote to follow directly from that document.

The build work typically covers hosting inside the institution's own cloud account or data center, database and backup configuration, the signing certificate setup, SSO integration, templates and bulk-send workflows, role design so that only authorized staff can see records, and the access-control and logging settings that support FERPA recordkeeping under 34 CFR 99.32. DeployOpen also documents the configuration and runbooks so that campus IT can operate the platform after handover. DeployOpen prepares the evidence an auditor or the institution's compliance office will ask for, such as configuration records, access rules, audit log settings, retention settings and test results. It does not issue audit reports, attestations or certifications. Those come from independent assessors, and the institution should confirm with its own auditors which artifacts they expect.

After go-live, ongoing support, upgrade and continuous testing are available as retainers, which suit campuses that cannot absorb patch cycles during term time. Ask any partner, DeployOpen included, to state in writing who applies security updates, how long a release is tested before it reaches production, and how a signing certificate renewal is handled. Keep the retainer scope aligned with the institution's own change calendar, especially around enrollment deadlines when bulk sends peak.

Open source e-signature for education