Which eIDAS signature level does a self-hosted e-signature platform actually deliver?
A self-hosted Documenso or DocuSeal deployment produces the platform-side signing and evidence for an advanced electronic signature under eIDAS, provided the signing certificate, identity checks and audit trail are configured to support it. A qualified electronic signature is a different matter: it requires a qualified trust service provider to issue the qualified certificate and, in practice, a qualified signature creation device, so the platform alone cannot deliver it. EU organizations that must sign contracts or internal approvals on their own infrastructure should first map each document type to the level it needs, then decide whether a qualified trust service provider is part of the design. Confirm the exact requirement with legal counsel for each document class, since the level that applies depends on the transaction and the law governing it.
The GDPR is relevant here as context rather than as a signature rule. Article 32 requires controllers and processors to implement appropriate technical and organizational security of processing, which covers access control, encryption of signer links and documents, and logging of who signed what and when. Article 99 sets the applicability date, which has been 25 May 2018, and confirms the regulation applies directly across the EU. The GDPR does not require a signing certificate, an audit or a certificate of conformity, so the choice of signature level is driven by eIDAS and sector rules, not by data protection law. Certification under Article 42 is voluntary and does not transfer responsibility for compliance.
DeployOpen can plan the deployment, configure signing certificates, document the signing workflow and prepare the evidence an assessor will ask for, such as signer identity steps, certificate details and retention settings. DeployOpen does not issue audit reports, attestations or certifications, and it does not act as a qualified trust service provider. Ask any implementation partner to state in writing which signature level each document type will reach, which parts depend on a qualified trust service provider, and who owns the relationship with that provider. Confirm with the chosen trust service provider which qualified certificate and device options it offers before committing to a QES workflow.
Which signing certificate options fit each eIDAS level?
A signature is only as strong as the key and certificate behind it, and the four options below differ sharply in who controls the key and what a third party can later confirm. Read each card against the eIDAS level your documents need, not against a general sense of "more secure."
Self-signed .p12 certificate with OpenSSL
A self-signed certificate is generated locally with OpenSSL and stored as a .p12 file that Documenso can use to digitally sign PDFs. Your team controls the private key completely, which makes it cheap and quick to set up for internal testing or low-stakes internal approvals. What it cannot prove on its own is who the issuer is: no independent authority vouches for the key, so an external reader will see an untrusted signer unless you distribute the root yourself. Confirm with Documenso how the certificate is loaded and protected, and check the result in the PDF validators your recipients actually use.
Signing through Google Cloud KMS
Documenso documents signing through Google Cloud KMS, which keeps the private key inside a managed key service while the application requests signatures. Key custody moves to a cloud key store that your organization administers, with access governed by your cloud IAM policies and audit logs. The key still belongs to a certificate you issued or obtained, so the chain of trust depends on which authority signed that certificate. Ask the vendor and your cloud team which certificate chain is attached, where the key resides, and whether the deployment meets your data residency rules.
Internal certificate authority
An internal certificate authority issues signing certificates to employees or systems under a root your organization operates, and distributes that root to devices and PDF validators. It fits internal approvals, intra-company contracts and air-gapped networks where a public trust service is unavailable. The evidence is consistent and auditable within your own trust domain, but an outside counterparty will not trust the chain unless they import your root. The CA itself becomes a high-value asset, so its key ceremony, revocation process and certificate policy need documented owners before any signing begins.
Certificate from a qualified trust service provider
A qualified trust service provider is a supervised provider whose certificates and signing services can support qualified electronic signatures under eIDAS, when paired with a qualified signature creation device. This is the only option in this list that can be the basis for a QES, and the provider, not your platform, carries the regulatory obligations for identity proofing and the certificate. Self-hosted Documenso or DocuSeal must integrate with that provider's service, which adds a contract, per-signature or per-certificate costs set by the provider, and a dependency on its availability. Confirm the provider's trusted list status, the supported signing workflow and the validation outcome with the provider before you commit to a level.
How eIDAS signature requirements map to self-hosted platform functions
This table maps each eIDAS requirement area to what a self-hosted Documenso or DocuSeal deployment must do, how to configure it, and the gap that remains. Read the last column as the work you still own after installation: qualified status, provider contracts and legal sign-off sit outside the software.
| Requirement area | What the platform must do | How to configure it in Documenso or DocuSeal | Gap that remains |
|---|---|---|---|
| Signer identification | Tie each signature to a person with a level of identity assurance matched to the document's risk | Use named invitations with unique signer links, add email verification and document access controls; confirm whether your edition offers stronger identity checks | Email-link identity is generally a simple or advanced signature basis at most; a qualified level needs a qualified provider's identity proofing |
| Signature linked to the signer and data | Bind the signature cryptographically to the signer and to the content of the document | Configure a signing certificate (documented options include a self-signed .p12 generated with OpenSSL or signing through Google Cloud KMS); keep the signing key under your control | A self-signed certificate proves integrity but not an independently trusted identity; a trusted or qualified certificate comes from a trust service provider |
| Signer sole control | Show that only the signer could create the signature, typically through authentication and a controlled signing session | Enforce per-recipient links, expiry and one-time access; log session events and IP addresses in the audit trail | Sole control at a qualified level usually depends on a qualified signature creation device or remote signing service, which the software alone does not provide |
| Detection of changes after signing | Show that the document has not been altered after signature and let third parties verify it | Keep the sealed PDF as the record copy; use DocuSeal's PDF signature verification and check signatures in an independent PDF validator | Validation trust depends on which certificate chain your verifiers accept, so confirm the trust list with counsel and recipients |
| Audit evidence | Record who did what, when and from where, in a form that an assessor can review | Export and retain the completion certificate and audit log; store them alongside the signed PDF in the same retention system | The software records events but does not decide whether they are sufficient evidence in a dispute; legal review sets that standard |
| Qualified device and provider requirements | Use a qualified electronic signature creation device and a qualified trust service provider where the document type requires a qualified signature | Integrate a qualified trust service provider through its API or remote signing service if your legal review requires QES; do not assume a self-hosted certificate qualifies | Qualified status, device certification and provider contracts are outside DeployOpen's scope to issue; confirm providers and conformity evidence with the provider and counsel |
| Legal level by document type | Map each document class to the signature level it needs before the template is built | Assign templates to levels in your requirements register; route QES documents to a separate workflow | Exact article references and level decisions must be confirmed with qualified legal counsel for each jurisdiction |
Which documents need which eIDAS level?
Internal approvals, purchase sign-offs, expense authorizations and mutual NDAs usually carry limited legal exposure when a dispute arises. The main risk is not forgery but the inability to show who approved what, when, and from which account. For these documents, a simple electronic signature backed by a strong audit trail is often sufficient, provided the platform records the signer's identity, the time of signing, the document hash and the consent given. Self-hosted Documenso or DocuSeal can produce this evidence in your own infrastructure.
- Typical risk: Disputes about whether an approval was given, or by whom, and gaps in internal control evidence.
- Level usually sufficient: Simple electronic signature with a complete audit trail and tamper-evident sealing.
- Signer authentication: Confirm whether login-based or email-based access is enough for each approval role.
- Retention: Set how long approvals and NDAs must be kept under your internal policy and any applicable rule.
- Consent: Confirm whether your counsel wants an explicit agreement to use electronic signatures in internal workflows.
Ask counsel whether any NDA or approval is governed by a rule that requires a specific signature form or a notarized act.
Commercial contracts, supplier agreements, offer letters and employment contracts carry higher financial and enforceability stakes. The usual risk is a counterparty later denying that the signer was bound, or contesting the identity of the person who signed. For most business contracts, an advanced electronic signature is commonly used because it links the signature to the signer in a unique way and makes later changes detectable. Advanced signatures require controls on how the signing certificate is issued and managed, so the design decisions matter more here than for internal approvals.
- Typical risk: Enforceability disputes, identity challenges and changes made after signing.
- Level usually sufficient: Advanced electronic signature where the signing certificate and identity checks are documented.
- Signing certificate: Decide whether the self-signed .p12 option or a managed key service is acceptable for your risk profile.
- Identity verification: Define the checks performed before a counterparty signs, especially for high-value contracts.
- Employment rules: Confirm with counsel any country-specific requirements for employment documents and how they are delivered.
Confirm with counsel which contract types, jurisdictions and counterparties require a higher level or a wet-ink original.
Some documents are subject to a national rule that requires a qualified electronic signature, or that treats only a specific form as valid for a filing, registration or official submission. A qualified signature must be created with a qualified electronic signature creation device and a certificate issued by a qualified trust service provider, which is a requirement that a self-hosted platform cannot meet alone. Self-hosting still helps here by keeping documents, signer data and workflow under your control, but the qualified element comes from an external provider you connect to.
- Typical risk: Rejection of a filing, invalid execution and regulatory penalties.
- Level usually required: Qualified electronic signature, where a national rule or the receiving authority mandates it.
- Qualified provider: Confirm that the trust service provider is qualified for the relevant document type and jurisdiction.
- Device and certificate: Confirm who holds the qualified device and how signers are enrolled and identified.
- Acceptance: Ask the receiving authority in writing which signature form it accepts.
Confirm with counsel and the receiving authority which filings are covered and whether any national rule applies on top of eIDAS.
How to configure the platform for advanced signatures
This sequence takes a self-hosted Documenso or DocuSeal instance from installation to a signing setup that produces signed PDFs with a verifiable signature, a defined audit log and evidence that an outside validator can read. It is a configuration path for advanced electronic signatures, not a qualified signature setup. Exact configuration keys must be confirmed against each project's documentation before deployment.
Install the platform with a production database
The platform team deploys Documenso or DocuSeal inside the organization's own infrastructure. For Documenso, use the supported Docker, Docker Compose, Kubernetes or manual installation paths with PostgreSQL as the database. For DocuSeal, use the docuseal/docuseal image and point the DATABASE_URL variable at PostgreSQL or MySQL instead of the default SQLite. Confirm the exact variable names and version pins in the project documentation. The step is complete when the application starts, connects to the database, and an internal test user can log in over HTTPS.
Set up the signing certificate
The security or PKI team issues the certificate that the platform uses to digitally seal signed PDFs. Documenso documents two options in its signing guide: a self-signed .p12 certificate generated with OpenSSL, or signing through Google Cloud KMS. A self-signed certificate proves that the file was sealed by your instance but does not establish a trust chain that outside parties accept by default. Record who holds the private key, where it is stored, and how it is rotated. The step is complete when a test document carries a certificate signature that the validator can read.
Define signer authentication for each document class
The business owner and legal team assign an authentication method to each document class, such as an email link for low-risk internal approvals and stronger identity checks for client agreements. Confirm with the platform vendor which identity verification options each edition supports, because not every edition provides the same controls. Write the mapping down so that the signing workflow for each template matches the eIDAS level the document needs. The step is complete when each template has a documented authentication setting and a reviewer has signed off the mapping.
Configure audit log retention
The compliance lead defines how long the platform keeps audit events, including sends, views, completions, and changes to templates and certificates, and where those records are stored. Confirm the retention rules required by each applicable regulation, and make sure database backups include the audit tables. Export a sample audit trail for a completed envelope and check that it shows the signer, timestamps and actions. The step is complete when retention settings are documented, backups restore the audit data, and a sample export is filed with the signed document.
Enable PDF signature verification
The platform engineer turns on the PDF signature verification feature that DocuSeal lists among its core functions, and confirms the equivalent verification and certificate handling in Documenso for the chosen version. Check that the platform reads signatures in files it receives and that it flags altered or unsigned content. Confirm the setting names in each project's documentation before changing production configuration. The step is complete when a file signed by the platform verifies in the platform and a file with an edited byte range is reported as altered.
Test validation with an outside PDF validator
An engineer who did not configure the system opens completed sample documents in a third-party PDF validator that the legal team accepts, such as Adobe Acrobat's signature panel or another validator named in the organization's policy. The check confirms that the signature is recognized, the certificate chain is shown, and the document is unchanged after signing. Record the validator name and version, then save the results with the test plan. The step is complete when the outcome for each document class is recorded and any gaps are assigned to an owner before go-live.
Which open-source platforms fit eIDAS signing needs
Two open-source platforms cover most advanced electronic signature workflows on self-hosted infrastructure. Both need a signing certificate, both produce audit evidence, and both differ in edition scope, so the choice depends on the signature level each document type requires and the features your team needs.
Documenso for self-hosted signing
Documenso is licensed under AGPL-3.0, and its v2.20.0 release was published on October 8, 2026. It deploys with Docker, Docker Compose, Kubernetes or a manual installation, using PostgreSQL as its database. Documenso needs a signing certificate to apply a digital signature, and documented options include a self-signed .p12 certificate generated with OpenSSL or signing through Google Cloud KMS. Confirm which certificate type your signature policy accepts before going live.
DocuSeal for self-hosted signing
DocuSeal is distributed under AGPLv3 with Section 7(b) additional terms, and version 3.3.2 was published on October 12, 2026. It ships as the docuseal/docuseal Docker image, with SQLite by default and PostgreSQL or MySQL through the DATABASE_URL variable. It includes PDF signature verification, a field builder and an API with webhooks, which help with verifying signed files outside the platform and wiring signing into case systems.
Free edition limits for DocuSeal
The free on-premises edition of DocuSeal has no SSO, bulk send or embedded signing. Regulated teams that need SAML-based sign-in for staff or bulk sending to cohorts of clients will need the Pro on-premises edition, which the DocuSeal pricing page lists at $240 per user per year. Check the edition against each feature in your requirements before you select the platform.
Edition scope for Documenso
Documenso's pricing page names the ESIGN Act, UETA, 21 CFR Part 11, SOC 2 and HIPAA as compliance references, but does not tie them to specific plans. The Enterprise plan covers self-hosted setups on custom pricing. Ask the vendor in writing which features, support terms and documentation apply to eIDAS-aligned signing before you assume they are included in your edition.
Qualified signatures need outside services
Neither platform issues the qualified certificate that a qualified electronic signature requires. A qualified signature depends on a qualified trust service provider and a qualified signature creation device, and those are separate purchases. Plan for a QTSP integration if any document class requires a qualified signature, and confirm the integration path with both the platform and the provider.
Audit evidence and signature verification
Each platform records who signed, when and from which link, and both let you verify signed PDFs. An advanced signature needs the signer to be uniquely linked, under the signer's sole control and able to detect later changes. Test whether the audit trail and certificate in your chosen platform meet those tests, and keep a sample signed file so an auditor or counterparty can verify it independently.
What evidence auditors and supervisors ask for, and which component produces it
This table maps each evidence item an assessor or supervisory authority may ask for to the component that produces it on a self-hosted signing stack. Read it as a checklist for design: if a row has no owner in your architecture, the evidence will not exist when someone asks for it. DeployOpen prepares this evidence for review, but independent auditors and supervisory authorities make the assessment.
| Evidence item | What it shows | Component that produces it | What to confirm |
|---|---|---|---|
| Signed PDF with embedded signature and certificate data | Who signed, the signing certificate, and whether the document changed after signing | Documenso or DocuSeal signing step, using the configured signing certificate | Whether the platform's PDF signature validates in external tools outside the enclave |
| Audit trail of signer activity | Signer identity inputs, timestamps, IP addresses and access events for each envelope | Platform audit log stored in the PostgreSQL or MySQL database (DocuSeal supports both) | Which identity checks were used before signing and whether they are recorded in the trail |
| Access and change logs for the signing service | Administrator actions, template edits, key changes and user access | Application logs, reverse proxy logs and host logs forwarded to a central store | Log retention period and whether logs are tamper-evident |
| Certificate and key management records | Which signing certificate was used, when it was issued, renewed or replaced, and who controls the private key | Signing certificate source (self-signed .p12 or a cloud KMS, as documented by Documenso), plus your internal key register | Certificate validity period, key custody and rotation procedure with the certificate owner |
| Document retention record | How long signed documents and their trails are kept and when they are deleted | Storage layer and backup set, plus a retention schedule owned by your records function | Retention periods by document type under the rules that apply to your sector and jurisdiction |
| QTSP contract and conformity documents for QES | Evidence that the qualified trust service provider and its qualified signature creation device meet eIDAS requirements | Qualified trust service provider, supplied by the provider and not produced by the signing platform | Current trusted-list status of the provider and the signed contract terms covering QES issuance |
| Evidence package for assessment | A collected set of the items above, organized for an auditor or supervisor | DeployOpen compiles it during implementation; independent auditors or supervisory authorities review it and decide | Who signs off the package internally and how often it is refreshed after upgrades |
What the platform alone does not satisfy
Documenso and DocuSeal can produce advanced electronic signatures inside your own infrastructure, but several requirements sit outside the application. The four gaps below are where legal effect, identity assurance and long-term evidence depend on services, people and decisions that your organization must arrange and document.
Qualified signatures need a provider
A qualified electronic signature depends on a qualified trust service provider that issues the qualified certificate and, where required, a qualified signature creation device that holds the signer's key. Neither the self-hosted platform nor a self-signed .p12 certificate supplies that status. Documenso's documented options, such as a self-signed certificate generated with OpenSSL or signing through Google Cloud KMS, produce signatures that are not qualified in the eIDAS sense. Confirm with your provider which certificate profiles it issues, how the platform connects to them, and who holds the signing key.
Identity proofing beyond the software
The assurance level of a signature depends on how confidently the signer is tied to the person who signed. A signer who receives an emailed link and clicks through is identified only loosely, while stronger processes check an identity document, use a second factor or verify through a trust provider before signing. The platform records what it was configured to check, but the strength of that check is a process decision. Confirm which verification steps your policy requires per document type and whether your identity provider can supply them.
Legal effect is a legal decision
Whether a signed document is valid, and at what eIDAS level it must be signed, depends on the document type, the jurisdiction and the other party's requirements, not on the software setting. Employment terms, consumer credit, property transfers and notarized acts can each carry different formal requirements. Your legal counsel should classify each document family and state the minimum signature level, and the signing workflow should enforce that classification. Confirm the classification in writing before templates go live.
Long-term validation needs an archive plan
A signature that verifies today may be hard to prove years later if the certificate chain, revocation data and timestamp are not preserved. Trustworthy timestamps need a reliable time source, and the signed PDF must be verifiable outside the platform. Your records team should decide retention periods, storage location, and how validation material is kept with each document. Confirm how your platform embeds timestamps and validation data, and test that a sample signed file still verifies after a platform upgrade.
How long does eIDAS setup take and what does it cost?
What drives the cost of an eIDAS signing setup?
The cost depends on which signature levels you need and who you pay for each component. Infrastructure for the self-hosted platform is a recurring cost you run in your own cloud account or data center. Signing certificates are a separate cost, whether you generate a self-signed certificate for internal use or buy one from a provider. A qualified signature adds fees from a qualified trust service provider (QTPS), which are set by that provider, along with any qualified signature creation device, and those fees usually recur per user or per signature. Implementation labor, template migration, integrations and legal review are one-time costs. Ask every bidder for a written quote that separates these lines, states which are one-time and which recur, and names who pays the trust service provider directly.
Can an internal team set up eIDAS signing without a partner?
A capable platform team can deploy Documenso or DocuSeal without an outside partner, since both publish Docker-based installation paths. The harder work sits outside the software: choosing the signature level for each document type, selecting and contracting a qualified trust service provider when qualified signatures apply, configuring signing certificates correctly, and documenting the evidence a reviewer will ask for. Teams with no prior experience in certificate lifecycle or trust services often underestimate that work. A partner can help with the implementation and evidence pack, but legal interpretation of which documents need which level must come from your own counsel.
How long does an eIDAS signing project usually take?
No researched timeline applies to every organization, so the duration depends on scope rather than on a fixed number. The main variables are the number of document types that need advanced or qualified signatures, whether a qualified trust service provider must be onboarded and contracted, how many templates and integrations need migration, and how much legal review the signature levels require. A narrow scope with one document type and a simple certificate choice moves faster than a multi-entity rollout with qualified signatures across several business lines. Ask for a timeline in the written scope, with milestones for certificate issuance, provider onboarding and user acceptance testing, since those steps often depend on third parties.
What does the legal and IT team need to provide?
Legal owns the decision on which documents need which eIDAS level and the wording of consent and signer declarations. IT owns hosting, identity, network access, backups and the mail system that delivers signer invitations. Security owns certificate handling, key storage, access control and logging. Together these teams should provide a list of document types with their legal requirements, the signing roles and approval chains, the systems to integrate, and the retention periods that apply. Start these inputs early, because they set the scope that the quote is based on.
Can Documenso or DocuSeal alone produce qualified electronic signatures?
Neither platform produces a qualified electronic signature by itself. Both can apply signatures and produce audit records, and Documenso documents options for signing with a self-signed certificate or through Google Cloud KMS. Those options support advanced electronic signature use cases, but a qualified signature under eIDAS requires a qualified trust service provider and a qualified signature creation device, and the signer must be identified to the level the regulation requires. Confirm with the vendor and your legal counsel exactly which certificate and provider configuration they will rely on for each document type before committing to a qualified workflow.
Does GDPR require a certificate for self-hosted signing?
No. The GDPR requires no audit, attestation or certificate. Under Article 42, certification is voluntary, is issued for at most three years by accredited certification bodies or supervisory authorities, and does not reduce the controller's or processor's responsibility for compliance. What the GDPR does require is appropriate security of processing under Article 32, along with controller and processor obligations under Chapter IV. For a self-hosted signing service, that means documented access controls, encryption, logging and a clear record of processing. Ask your partner for the evidence pack that supports these controls, and treat it as internal readiness material rather than a certificate.
What recurring costs follow the initial eIDAS setup?
After go-live, the recurring costs are infrastructure, platform support and upgrades, certificate renewals, and any per-signature or per-user fees charged by a qualified trust service provider. If you use a Pro or Enterprise edition, license costs also recur. DocuSeal, for example, lists On-Premises Pro at $240 per user per year and charges $0.20 per completion for embedded signing, according to its pricing page as read in October 2026. Those figures apply only to DocuSeal and are subject to change, so verify them before budgeting. Ask the quote to show each recurring line with its unit, its renewal period and its owner.
What a fixed-scope eIDAS signing engagement covers
A DeployOpen engagement for eIDAS signing starts with a written scope, and the first deliverable is a classification of document types. Working with the client's counsel, the team maps each document family to the signature level it needs (simple, advanced or qualified) and records which documents must be signed by a qualified trust service provider. That register then drives every later decision, from which signing certificates are issued to which signed outputs are tested. Most engagements are fixed-scope, so deliverables, timelines and responsibilities are agreed in writing before work begins, and the client's legal team signs off on the classification.
Once the classification is agreed, the team selects the platform and edition. For Documenso or DocuSeal, that choice turns on features the classification exposes, such as embedded signing, SSO or API access, and the certificate options the edition supports. The engagement then configures the signing certificate chain, the audit log settings and the retention location, and documents which component holds each private key. Each configuration step is tested against real signed outputs: the team verifies the PDF signatures and the audit trail with independent validation tools, and records the results so the client can repeat the checks later. Items that depend on the client's qualified trust service provider, such as its onboarding steps and the signing devices it supports, are listed as client-side dependencies to confirm with that provider.
The handover covers the evidence and the runbooks. The client receives the document classification, configuration records, test results, certificate and key inventories, and runbooks for issuing certificates, rotating keys, restoring the database and investigating a disputed signature. Ongoing operation, upgrades and continuous testing fall under a separate retainer, not the fixed-scope project. DeployOpen prepares systems, controls and evidence for compliance reviews, but it does not issue audit reports, attestations or certifications. Those come from independent auditors, certification bodies or the relevant supervisory authority, so the client should confirm with its auditor which records that party will request before the engagement is scoped.
How DeployOpen delivers self-hosted eIDAS signing and its evidence
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted signing platforms inside your own cloud accounts, data centers or air-gapped networks. For eIDAS work, we start by agreeing in writing which signature level each document type needs, then build the signing and evidence chain to match, and we confirm qualified trust service provider and device requirements with you before any build starts.
How we scope
- Written scope lists each document type and the eIDAS signature level it needs, agreed before work starts.
- Scope names the signing certificate approach, including whether a qualified trust service provider is in or out of scope.
- Scope covers integrations, identity checks, retention periods and the audit evidence each document must produce.
How we build
- We deploy Documenso or DocuSeal in your environment with PostgreSQL or MySQL, not the default single-file database for production.
- We configure signing certificates and test that signed PDFs validate outside the platform with standard PDF verification tools.
- We test signer invitations, audit trail completeness and access controls against the scope before handover.
How we hand over
- You receive documentation of the configuration, certificate handling, audit log locations and backup and restore steps.
- We provide evidence packs that map platform controls to your compliance assessor's questions, without claiming any certification.
- Handover includes a verification procedure your legal and compliance teams can run on signed documents years later.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, and we can plan releases around your change process.
- We re-test signing flows and certificate renewals after each platform upgrade, using the scope as the acceptance baseline.
- Confirm with your legal counsel and qualified trust service provider which obligations stay with you after go-live.
