Ein Vertragsprozess muss ersetzt werden, doch die neue Lösung darf keine Verträge an einen Signatur-SaaS-Dienst senden. DocuSeal, Documenso und OpenSign gehören auf diese Auswahlliste für DocuSign-Alternativen. Alle bieten einen selbst hostbaren Kern. Aussagekräftig ist der Vergleich der betreibbaren Edition, der exportierbaren Nachweise und der Dienste, die die Installation weiterhin aufruft. Die Erlaubnis, einen Server zu mieten, und die Erlaubnis, Dokumente an einen Auftragsverarbeiter zu senden, sind getrennte Entscheidungen.
Einen bereits genehmigten DocuSign-Prozess beizubehalten, kann sinnvoll bleiben, solange Nachweise oder Betrieb der Ersatzlösung unvollständig sind, sofern dieser Prozess die Anforderungen Ihrer Organisation erfüllt. Untersagt eine Richtlinie das Verarbeitungsmodell, beseitigt Vertrautheit diese Einschränkung nicht. Legen Sie die Abnahmekriterien für die Ersatzlösung fest, bevor Sie echte Verträge umstellen.
Kurzfassung
- DocuSeal: Die kostenlose selbst gehostete Edition unterstützt mehrere Unterzeichner und Ihren eigenen SMTP-Server. Pro ergänzt unter anderem automatische Erinnerungen, SAML-SSO, Benutzerrollen und Teams sowie erweiterte API- und Einbettungsfunktionen. Siehe den On-Premises-Vergleich.
- Documenso: Die Community Edition umfasst grundlegende Signaturfunktionen, Vorlagen und API-Zugriff. Kommerzielle Funktionen sind unter anderem das Organisations-Authentifizierungsportal, die erneute Authentifizierung bei Dokumentaktionen und die eingebettete Dokumenterstellung. Siehe den Editionsvergleich.
- OpenSign: Das Repository dokumentiert wiederverwendbare Vorlagen, Signaturreihenfolgen, E-Mail-Codes für Gäste und Abschlusszertifikate. Die API-Token-Dokumentation unterscheidet kostenpflichtige Live-Token und kostenlose Sandbox-Token. Klären Sie die API-Berechtigung für den gewählten selbst gehosteten Build; diese Seite belegt sie nicht eindeutig.
Kostenlose Editionen und ihre Betriebsanforderungen vergleichen
Die folgende Tabelle vergleicht den Umfang des kostenlosen Codes, die Installationsanforderungen und kommerzielle Funktionen der einzelnen Werkzeuge.
| Tool | Umfang des kostenlosen Codes | Installationskomponenten | Kommerzielle oder ungeklärte Voraussetzungen |
|---|---|---|---|
| DocuSeal | Die Repository-Lizenz ist AGPLv3. Die DocuSeal-Preisseite unterscheidet kostenloses Open Source On-Premises und kommerzielles Pro On-Premises. | Docker/Compose; standardmäßig SQLite, alternativ PostgreSQL/MySQL, wie in den Installationsoptionen beschrieben. Planen Sie persistente Dateien und Datenbanken sowie den E-Mail-Versand. | Die Pro-Einrichtungsanleitung ordnet Branding, Erinnerungen, SSO, Rollen/Teams, Webhooks und API/Einbettung dem kommerziellen Angebot zu. Klären Sie die genauen Integrationsrechte und Nutzungsgebühren; allgemeine Integrationshinweise im Repository beantworten das nicht. |
| Documenso | Der Editionsvergleich unterscheidet die kostenlose Community Edition, eine jährliche Business-Edition-Lizenz und eine individuell vereinbarte Enterprise Edition. Das Repository enthält auch separat lizenzierten kommerziellen Code. | Die Anforderungsdokumentation nennt PostgreSQL, E-Mail-Transport, einen Reverse Proxy und ein Signaturzertifikat sowie optional S3-kompatiblen Speicher. Berücksichtigen Sie Dokumente und Auditdatensätze in der Datenbank im Persistenzkonzept. | Die Liste kommerzieller Funktionen nennt Organisationsauthentifizierung und erneute Authentifizierung bei Dokumentaktionen. Die Editionsdokumentation nennt außerdem eingebettete Dokumenterstellung, auch als White-Label, und CSC-Fernsignatur. Klären Sie erforderliche Exporte, Zeitstempelkonfiguration und kostenlosen API-Umfang für die gewählte Edition. |
| OpenSign | Die Self-Hosting-Seite beschreibt einen kostenlosen selbst gehosteten Kern. Die AGPLv3-Lizenz im Stammverzeichnis enthält Verzeichnis- und Drittanbieter-Ausnahmen. | Die Docker-Anleitung konfiguriert MongoDB, lokalen oder externen Dateispeicher, SMTP/Mailgun und ein Signaturzertifikat. Prüfen Sie Persistenz und Datenbankexposition der gewählten Installation. | Die API-Token-Anleitung unterscheidet kostenpflichtige Live-Token und kostenlose Sandbox-Token, während die Self-Hosting-Seite eine REST-API bewirbt. Klären Sie die Rechte der gewählten selbst gehosteten Edition, bevor Sie darauf bauen. Die OpenSign-Vorlagenanleitung dokumentiert die Einstellung „Merge Certificate to PDF“: Aktiviert fügt sie das Abschlusszertifikat ins endgültige PDF ein, deaktiviert liefert sie ein separates Zertifikat-PDF. Prüfen Sie die Exportoptionen Ihres installierten Builds. |
Eine Open-Source-Anwendung für elektronische Signaturen kann einen nutzbaren kostenlosen Kern und zugleich kommerzielle Pakete bieten. Prüfen Sie für jeden geplanten Prozess die Nutzungsrechte: die Aktion, die sie erlaubende Edition und den aufgerufenen Dienst. Ein öffentliches Repository belegt nicht ausreichend, dass eine benötigte Funktion kostenlos ist.
Führen Sie eine kurze Auswahldokumentation: gewähltes Paket, benötigter Prozess, ungeklärte Voraussetzung und zuständige Person für die Klärung. Tragen Sie nicht „ja“ in ein ungeklärtes Feld ein, nur weil es eine ähnlich benannte Cloud-Funktion gibt. Eine ungeklärte Anforderung sollte die Einführung dieses Prozesses verzögern, auch wenn der Rest der Anwendung geeignet erscheint.
Einen Kandidaten passend zum Signaturprozess auswählen
Meine erste Auswahl wäre DocuSeal für einen manuell verwalteten PDF-Vorlagenprozess, Documenso Community bei zwingend kostenlosem API-Zugriff und OpenSign, wenn Vorlagen und Gast-E-Mail-Codes zum Prozess passen. Das sind Ausgangspunkte für einen Pilotversuch anhand offizieller Dokumentation; ich habe keine Installations- oder Signaturtests durchgeführt.
DocuSeal für PDF- und Vorlagenprozesse
DocuSeal ist ein sinnvoller erster Pilot für die PDF-Vorbereitung und wiederverwendbare Signaturvorlagen, wenn der kostenlose Kern den Prozess abdeckt. Die FAQ zum Auditzertifikat beschreibt einen herunterladbaren Abschlussnachweis mit Ereignissen je Partei und bedingten Verifizierungsfeldern. Bewerten Sie die aufgezeichnete Methode anhand Ihrer Anforderungen, bevor Sie das Zertifikat als Nachweis eines bestimmten Identitätsniveaus behandeln.
Das Zertifikat erfasst E-Mail-Adressen der Parteien, Ereigniszeiten, IP-Adresse, Sitzungs-ID, Browserinformationen und Zeitzone. E-Mail- oder Telefonverifizierung hängen von der verwendeten Methode ab; ein vorhandenes Feld beweist nicht, dass eine stärkere Methode ausgeführt wurde. Fordern Sie ein Beispiel aus Ihrer geplanten Konfiguration an, gegebenenfalls auch für abgelehnte oder delegierte Anfragen.
Stoppen Sie die Auswahl, wenn erforderliche Authentifizierung oder Integration eine noch nicht genehmigte kommerzielle Edition voraussetzt. Der Dokumenteditor kann die sichtbare Anforderung erfüllen, während eine unverzichtbare Folgeaktion ungeklärt bleibt.
Documenso für ein bestehendes PostgreSQL-Betriebsmodell
Documenso ist einen Pilotversuch wert, wenn Sie Datenbank, E-Mail- und Zertifikatsabhängigkeiten zusammen betreiben können. Die Self-Hosting-Anforderungen nennen eine konkrete Falle: Die Anwendung kann ohne Signaturzertifikat starten, während das Signieren von Dokumenten fehlschlägt. Eine reagierende Oberfläche ist daher kein Abnahmetest für diese Installation.
Die Anforderungen beschreiben digitale X.509-Signaturen mit einem bereitgestellten oder erzeugten .p12-Zertifikat und Auditlogs in der Datenbank. Das beschreibt die Signaturinfrastruktur; es belegt weder, welchen persönlichen Authentifizierungsnachweis ein Empfänger verwendete, noch den Inhalt eines bestimmten Exports.
Documensos Dokumentlebenszyklus beschreibt ein abgeschlossenes signiertes PDF mit angehängtem Auditlog. Das Änderungsprotokoll v2.14.0 dokumentiert außerdem separate Zertifikats- und Auditlog-PDF-Downloads per API. Exportieren Sie diese Nachweise im Pilotversuch aus dem installierten Build, prüfen Sie den Inhalt und validieren Sie das signierte PDF unabhängig.
OpenSign für Vorlagen und Signaturreihenfolgen
OpenSign kommt infrage, wenn wiederverwendbare Vorlagen und eine festgelegte Beteiligungsreihenfolge zentrale Anforderungen sind. Die Projekt-README dokumentiert mehrere Unterzeichner, Signaturreihenfolgen und E-Mail-Codes für Gäste. Testen Sie diese Abläufe mit dem vollständigen Backend und Ihrer Speicherkonfiguration. Ein E-Mail-Code belegt den Zugriff auf ein Postfach, keine unabhängig geprüfte persönliche Identität oder Vertretungsbefugnis.
Die Entwicklungs-Installationsanleitung weist darauf hin, dass der reine Frontend-Weg das Staging-Backend des Projekts nutzt, einschließlich Dokumentuploads. Schließen Sie diesen Weg für vertrauliche Verträge aus. Ein Frontend auf Ihrem Rechner belegt nicht, wo dessen Backend Dokumente verarbeitet.
Nachweise hinter einer abgeschlossenen Signatur prüfen
Ein abgeschlossenes PDF und ein Ereignisbericht beantworten unterschiedliche Fragen. Sammeln Sie Nachweise über Signaturaktionen, Dokumentintegrität, Identität und Befugnis des Unterzeichners sowie den Zeitpunkt. Die eSignature-FAQ der Europäischen Kommission und das ESIGN-Gesetz unterscheiden die Anerkennung elektronischer Signaturen von weitergehenden Anforderungen. Kein einzelner Export und kein technisches Feld bestimmen die rechtliche Beurteilung eines bestimmten Vertrags.
Für US-Transaktionen im Handel zwischen US-Bundesstaaten oder im Außenhandel sowie für Transaktionen mit Auswirkungen darauf begrenzt ESIGN §7001 die Verweigerung rechtlicher Wirkung allein wegen der elektronischen Form einer Signatur oder Aufzeichnung. Dieses Signaturgesetz erhält andere Pflichten und verpflichtet nicht jeden, elektronische Aufzeichnungen zu akzeptieren. Unter bestimmten Umständen gelten Bedingungen für Verbraucherinformationen. Die Ausnahmen in Section 7003 umfassen testamentarische und familienrechtliche Unterlagen, bestimmte handelsrechtliche Sachverhalte, Gerichtsdokumente und bestimmte Mitteilungen; diese Ausnahmen verbieten elektronische Nutzung nicht selbst.
Die eSignature-FAQ der Kommission unterscheidet elektronisches Signieren von seiner digitalen, kryptografischen Umsetzung. Nach der EU-Verordnung eIDAS rechtfertigt elektronische oder nicht qualifizierte Form allein keine Verweigerung der Rechtswirkung. Qualifizierte Signaturen haben die gleiche Wirkung wie handschriftliche. Fortgeschrittene Signaturen erfordern Identitätsbindung, Kontrolle des Unterzeichners und Änderungserkennung; qualifizierte ergänzen ein qualifiziertes Zertifikat und eine qualifizierte Signaturerstellungseinheit. Diese Regeln entscheiden weder Vertragsabschluss, Befugnis, Dokumentformalitäten noch einzelne Streitfälle und klassifizieren kein bestimmtes Werkzeug.
Prüfen Sie ein Beispiel-Nachweispaket anhand von vier Punkten:
- Ereignisse und Kontrolle. Ein Audit-Trail für elektronische Signaturen sollte erkennen lassen, wer handelte, was die Person sah oder akzeptierte, welche Verifizierung stattfand und wann der Prozess endete. Halten Sie relevante Einwilligungsnachweise fest. Klären Sie, wer Ereignisse ändern oder löschen kann, ob Änderungen aufgezeichnet werden und was die aufbewahrte Kopie unabhängig vom Anwendungsadministrator schützt. Ein Ereignislog allein belegt keine Manipulationsresistenz.
- Dokumentintegrität. Bewahren Sie das ursprüngliche abgeschlossene PDF auf und validieren Sie gegebenenfalls vorhandene digitale Signaturen, ihre Zertifikatsketten und die abgedeckten Bytes. NISTs Definition einer Hashfunktion beschreibt eine verdichtete Darstellung der Eingabe. Eine Hashprüfung zur Manipulationserkennung braucht eine authentifizierte Referenz: einen Digest mit nachweisbarer Herkunft und Schutz. Werden PDF und daneben gespeicherter Hash ersetzt, versagt ein bloßer Vergleich. Ein Hash allein belegt keine Unterzeichneridentität. Fragen Sie, ob auch der separate Auditnachweis geschützt ist.
- Identität und Befugnis. Dokumentieren Sie die Verifizierungsmethode und ihre Verbindung zur benannten Person. Postfachzugriff oder Einmalcode belegen allein weder die Identität noch die Befugnis, ein Unternehmen zu verpflichten. NISTs Definition einer digitalen Signatur verknüpft Ursprungsauthentifizierung und Integrität mit korrekter Umsetzung. Ein Server-Signaturzertifikat darf nicht stillschweigend zur Behauptung werden, jeder Empfänger habe einen individuellen Authentifizierungsnachweis besessen.
- Zeit und Aussteller. Trennen Sie das Ereignisdatum der Anwendung von einem unabhängig ausgestellten Zeitstempeltoken. RFC 3161 definiert ein Zeitstempelprotokoll mit einem Message Imprint, einem Digest der zeitgestempelten Daten. Prüfen Sie das Token anhand des aufbewahrten Dokuments und untersuchen Sie den Aussteller. Qualifizierter Zeitstempelstatus ist eine weitere Unterscheidung: Die Kommission beschreibt Vermutungen für Datums-/Zeitgenauigkeit und Integrität verknüpfter Daten; qualifizierte Dienste stehen in Vertrauenslisten. RFC-Unterstützung allein belegt diesen Status nicht und garantiert kein Ergebnis für das Dokument.
Wege von Dokumenten, Metadaten und Digests erfassen
Eine selbst gehostete Signaturanwendung kann abgeschlossene PDFs weiterhin über einen externen Relay-Dienst senden, wie DocuSeals Einstellungen für Abschluss-E-Mails zeigen. Self-Hosting bezeichnet den Anwendungsbetreiber; jeder konfigurierte Dienst braucht eine eigene Prüfung. Unterscheiden Sie Vertragsinhalt, personenbezogene Metadaten und Digests und dokumentieren Sie für jeden Weg Endpunkt und erlaubte Verarbeitung, bevor echte Dokumente ins System kommen.
Verbietet die Einschränkung Signatur-SaaS, erlaubt aber genehmigte gemietete Infrastruktur, bleiben Unternehmenshardware und ein genehmigter VPS oder eine private Cloud möglich. Ein gemieteter VPS ist Drittinfrastruktur. Ein wörtliches Verbot sämtlicher Drittinfrastruktur lässt sich nicht durch deren Kauf erfüllen. Nutzen Sie unternehmenskontrollierte Infrastruktur und prüfen Sie jeden unterstützenden Dienst anhand dieser Grenze.
Unser Ein-Klick-DocuSeal VPS wird mit vorinstalliertem DocuSeal geliefert. So können Sie die manuelle Anwendungsinstallation überspringen und sich auf Ihren Signaturprozess konzentrieren. Wählen Sie aus unseren weltweiten VPS-Standorten passend zur benötigten Datenplatzierung.
Ein ausdrücklich genehmigter Vertrauensdienst kann trotz verbotener SaaS-Dokumentverarbeitung nützlich sein. Bewerten Sie Nutzdaten und Zweck anhand der Richtlinie, statt anzunehmen, eine selbst administrierte Anwendung liefere automatisch stärkere Nachweise.
| Datenweg | Dokumentierte Daten oder Funktionen | In Ihrer Konfiguration zu klärende Fragen |
|---|---|---|
| E-Mail und Empfängerpostfach | DocuSeals Einstellungen für Abschluss-E-Mails können signierte PDFs und Audit-PDFs anhängen. OpenSigns Dokumentation der E-Mail-Vorlagen beschreibt Anfragedetails, Signaturlinks und Anhänge mit abgeschlossenem Dokument und Zertifikat. Diese Wege können Inhalte und personenbezogene Metadaten transportieren. | Welche Relays und Postfächer empfangen sie? Prüfen Sie Betreff, Text, Links und Anhänge. Deaktivierte Anhänge beseitigen keine Empfänger-, Titel- oder Linkmetadaten. Klären Sie Documensos tatsächliche E-Mail-Nutzdaten separat. |
| Primärdateien und Backups | Die Installationsdokumente beschreiben Datenbank-/Dateispeicher und optionale externe Speicher. Kopien können vollständige Dokumente und personenbezogene Auditmetadaten enthalten. | Wo werden Dateien, Replikate und Backups aufbewahrt? Wer kann sie lesen, wie lange bleiben sie erhalten und wohin legt eine Wiederherstellung sie ab? |
| Identität, SMS und SSO | Dokumentierte Authentifizierungsoptionen variieren nach Produkt und Edition; OpenSign dokumentiert E-Mail-Codes für Gäste. | Welche Methode ist aktiviert? Erhält ein genehmigter Dienst Kennungen, Telefonnummern oder Identitätsunterlagen? Nehmen Sie nicht an, dass Ausweisdokumentuploads standardmäßig erfolgen. |
| Zeitstempeldienst | DocuSeals Zeitserverkonfiguration akzeptiert einen eigenen oder externen Endpunkt für RFC 3161. Das Protokoll verwendet einen Digest; das belegt nicht sämtliche Anfragen der Anwendung. | Welche Edition ermöglicht das, welcher Aussteller antwortet und ist qualifizierter Status erforderlich? Prüfen Sie tatsächliche Anfragen und Netzwerkmetadaten. |
| Zertifikate, Fernsignatur und Lizenzierung | Zertifikatskonfiguration, Documensos kommerzielle Fernsignaturoption und DocuSeal-Pro-Registrierung werfen jeweils eigene Konfigurationsfragen auf. | Überträgt der gewählte Weg ein PDF, einen Digest, Kennungen oder Nutzungsdaten? Klären Sie die Nutzdaten für Lizenzierung und Verbrauchsmessung; nehmen Sie keine reine Digest-Verarbeitung an. |
| Integrationen und optionale Automatisierung | Webhooks und Integrationen sind konfigurierbare Wege, kein Beleg für ein vollständiges Inventar ausgehender Verbindungen. | Erfassen Sie Endpunkte, Ereignisinhalte und Dienstlogs einschließlich aktivierter KI oder Analysefunktionen. Prüfen Sie auf Dokument-URLs, Inhalte und personenbezogene Metadaten. |
| Hosting und Support | Ein gemieteter Server ergänzt neben der Signaturanwendung eine Infrastrukturbeziehung. | Genehmigen Sie physischen Standort, Backups, administrativen Zugriff und Supportzugriff getrennt. |
Nutzen Sie dasselbe Inventar externer Aufrufe wie für andere Geschäftsanwendungen: Verfolgen Sie jede Verbindung über die Oberfläche hinaus. Prüfen Sie konfigurierte Endpunkte und Nutzdaten mit synthetischen Dateien. Eine erfolgreiche lokale Anmeldung belegt nichts über ungeprüfte ausgehende Wege.
Edition und verbleibende Arbeit budgetieren
Auch ein lizenzkostenfreier Betrieb braucht Speicher, E-Mail-Versand und eine für Wiederherstellung zuständige Person. DocuSeals Pro-Anleitung und Documensos Editionsvergleich trennen Softwarerechte von Infrastruktureigentum. Budgetieren Sie den genauen Prozess einschließlich kostenpflichtiger Aktionen und unterstützender Dienste und weisen Sie Betriebsverantwortung zu. „Unbegrenzte“ Dokumente oder Benutzer liefern keine unbegrenzte Serverkapazität und keinen kostenlosen Betrieb.
Budgetieren Sie Rechenleistung, Datenbank- und Dokumentenspeicher, Backups, E-Mail-Versand, Zertifikate oder Vertrauensdienste, kommerzielle Lizenzen, Nutzungsgebühren und Administrationszeit.
| Budgetposten | Vor der Genehmigung einzutragen |
|---|---|
| Lizenz und Nutzung | Benötigte Edition, Verlängerungsbedingungen, Integrationsgebühren und gebührenauslösende Einheit. Lassen Sie mehrdeutige Export- oder Authentifizierungsoptionen bestätigen. |
| Rechenleistung und aufbewahrte Daten | Anwendungs-/Datenbankhosting, Primärdateien, Backupkapazität, Wachstum durch Aufbewahrung und Wiederherstellungsinfrastruktur. Unternehmenshardware verursacht ebenfalls Kapazitäts- und Wartungskosten. |
| Unterstützende Dienste | E-Mail-Versand, Identität/SMS, Signaturzertifikate sowie erforderliche Zeitstempel- oder Fernsignaturdienste. Berücksichtigen Sie nutzungsabhängige Gebühren. |
| Zeit für den Betrieb | Updates, Zugriffsprüfungen, Sicherheitskonfiguration, Zustellfehler, Überwachung und isolierte Wiederherstellungsübungen. Benennen Sie Hauptverantwortliche und eine Vertretung. |
Schätzen Sie anhand von Dokumentgröße, Aufbewahrungsdauer und Signaturspitzen. Vergleichen Sie ein SaaS-Abonnement nicht nur mit der Rechenleistungsrechnung der Ersatzlösung; sie umfassen unterschiedliche Arbeit. Bleibt eine benötigte kommerzielle Voraussetzung oder ein Dienst unbekannt, ist das Budget trotz kostenloser Anwendungslizenz unvollständig.
Ein kleinerer genehmigter Prozess ist ein vernünftiger Einstieg. Verschieben Sie optionale Automatisierung, bis Nutzungsrechte, Datenwege und Zuständigkeit geklärt sind.
Vor der Vertragsumstellung einen synthetischen Pilotversuch durchführen
Bewerten Sie die gewählte Edition vor der Umstellung mit einem fiktiven Vertrag und Testempfängern. Documensos Anforderungen und OpenSigns Docker-Anleitung nennen Abhängigkeiten; Ihr geplanter Pilot muss Signieren, Nachweisexport und Wiederherstellung gemeinsam testen. Dies ist ein Abnahmeplan, kein Bericht durchgeführter Tests. Dokumentieren Sie Fehler und offene Fragen zusammen mit der geprüften Konfiguration.
- Fixieren Sie Release oder Image und dokumentieren Sie Edition, Lizenz und installierte Version. Definieren Sie vor der Installation benötigte Aktionen und akzeptable Nachweise. Bewahren Sie diese Aufzeichnung bei der Installationskonfiguration auf, damit ein späteres Update dieselben Prüfungen wiederholen kann.
- Genehmigen Sie Endpunkte und Speicherziele. Erfassen Sie externe Wege im Arbeitsblatt und prüfen Sie synthetische Einladungs- und Abschluss-E-Mails, Anhänge und beobachtete Nutzdaten. Stellen Sie gegebenenfalls sicher, dass der gewählte OpenSign-Weg Ihr Backend umfasst.
- Führen Sie eine repräsentative Einladung mit externen Testempfängern durch. Testen Sie die erforderliche Verifizierung, Signaturreihenfolge, Ablehnung oder Ablauf und Abschluss. Bestätigen Sie die Erreichbarkeit außerhalb des Unternehmensnetzes und untersuchen Sie Zustellfehler.
- Exportieren Sie abgeschlossenes PDF und Auditnachweis in der geforderten Form. Validieren Sie Signaturen, Zertifikate und Zeitstempeltoken unabhängig von der Erfolgsmeldung der Anwendung. Vergleichen Sie die Integrität mit der aufbewahrten authentifizierten Referenz; verändern Sie eine separate Kopie und prüfen Sie die Erkennung. Dies ist eine technische Prüfung, kein Test rechtlicher Ergebnisse.
- Starten Sie die Installation neu und bestätigen Sie die weitere Zugänglichkeit der Aufzeichnungen. Stellen Sie in einer isolierten Umgebung wieder her und wiederholen Sie Abruf und Validierung. Geben Sie Backupzielen und Wiederherstellungsverantwortung eindeutige Abnahmekriterien; eine Erfolgsmeldung des Backupjobs reicht nicht.
- Planen Sie eine kontrollierte Umstellung. Bewahren Sie abgeschlossene PDFs und Originalnachweise getrennt von neuen Vorlagen auf. Entscheiden Sie, wie offene Anfragen abgeschlossen werden. Der PDF-Import in eine neue Anwendung rekonstruiert nicht den ursprünglichen Signaturverlauf.
Unsere Ein-Klick-DocuSeal-Installation hilft bei der Ersteinrichtung, wenn genehmigte gemietete Infrastruktur zum Empfängerzugriff passt. Manuelle Installation auf Unternehmenshardware oder bei jedem genehmigten Anbieter bleibt möglich. Wählen Sie aus unseren weltweiten VPS-Standorten passend zur benötigten Datenplatzierung.
Häufig gestellte Fragen
Abrechnungseinheiten, Paketlizenzen und installierte Builds brauchen auch nach der Prozessauswahl getrennte Aufzeichnungen.
Werden signierende Empfänger als Plattformbenutzer abgerechnet?
Nein. DocuSeals Erläuterung zur Pro-Abrechnung unterscheidet Plattformbenutzer und signierende Empfänger. Die Nutzungseinheit für API und Einbettung ist eine abgeschlossene Einreichung, die mehrere Dateien und Parteien enthalten kann. Dokumentieren Sie Plattformbenutzerrechte und anfallende Nutzungsgebühren getrennt; übertragen Sie dieses Abrechnungsmodell nicht auf andere Projekte.
Deckt eine Lizenz alle Repository-Komponenten ab?
Prüfen Sie die gewählten Dateien und Pakete. Documenso hat eine separate Lizenz für das kommerzielle Verzeichnis; OpenSigns Ausnahmen der Stammlizenz nehmen ein bestimmtes Server-Routenverzeichnis aus, falls vorhanden. Dokumentieren Sie bei einem eigenen Build enthaltene Komponenten und ihre Lizenzen, bevor Sie annehmen, die Hauptlizenz des Repositorys beschreibe alle Komponenten.
Identifiziert ein Upstream-Release meinen installierten Build?
Nein. Ein Upstream-Release bezeichnet Upstream-Software; eine Installation hat ihren eigenen bereitgestellten Build und ihre Edition. Erfassen Sie vor dem Pilot die von der laufenden Anwendung oder ihren Bereitstellungsmetadaten ausgewiesene Version. Leiten Sie diese Zuordnung nicht aus einer Releaseankündigung ab und wiederholen Sie die Abnahmeprüfungen bei Änderungen des installierten Builds.
Diskussion
Kommentare
Melden Sie sich an, um mitzudiskutieren.