Oktul home
  • English
  • Estonian

The documentation is in English only.

Contact us

Electronic signature terms

What a signature made through SignPlus is, who provides it, what Oktul does and does not guarantee about it, and what the customer is responsible for.

Version 1.0, effective 09.10.2026.

1. Scope

1.1 These terms apply to the creation of electronic signatures with Oktul SignPlus for Confluence (the “Application”). They supplement the application licence (the “Licence”) and form part of the Application’s Documentation within the meaning of clause 7.1 of the Licence. Terms defined in the Licence have the same meaning here.

1.2 Where these terms and the Licence conflict, the Licence governs, except that clause 4 of these terms states the Application’s limitations as clause 7.1 of the Licence provides.

1.3 The processing of personal data by the Application is described in its privacy notice.

2. Who provides the signature

2.1 Oktul OÜ is not a trust service provider and does not create, validate or preserve electronic signatures. The Application prepares a document from a Confluence page and sends it, with the details of each signer, to Dokobit, which provides the signing service.

2.2 A signature is created by the signer, with an identification and signing method Dokobit supports, on Dokobit’s signing page. The Application has no access to a signer’s credentials or PIN. The signed file contains each signer’s signing certificate, and the certificate of an Estonian eID includes the signer’s personal identification code.

2.3 Dokobit states that it is a qualified trust service provider for the validation of electronic signatures and seals under Regulation (EU) No 910/2014 (“eIDAS”), supervised by the Communications Regulatory Authority of the Republic of Lithuania and listed on the EU Trusted List (opens in a new tab). Its compliance page (opens in a new tab) carries its certificates and practice statement. The qualified certificate behind a qualified electronic signature is issued to the signer by the trust service provider behind their eID, not by Dokobit and not by Oktul. Dokobit identifies the provider as Dokobit, UAB (registry code 301549834) in its terms of service (opens in a new tab).

2.4 Which Dokobit account a signing runs on is decided by the signing mode:

  • Your own token: the customer’s own Dokobit account. The customer’s agreement with Dokobit governs the signing service, its fees and its availability.
  • Test: Dokobit’s test environment. A document signed in this mode carries Dokobit’s watermark, can be signed only with test identities, and has no legal effect.

3.1 Under Article 25(2) of eIDAS, a qualified electronic signature has the equivalent legal effect of a handwritten signature. An advanced electronic signature, and any other electronic signature, may not be denied legal effect and admissibility as evidence solely because it is electronic, under Article 25(1).

3.2 The level of signature a signing requires is set by the customer, under E-signature levels in the Application’s settings. Oktul does not advise on, and does not warrant, whether a signature of a given level, format or method meets a requirement of law, of a court, of a public authority or of a counterparty for a particular document or in a particular jurisdiction. That assessment is the customer’s.

3.3 The signed file is the evidence of what was signed. A Confluence page, its byline and the Application’s records are not.

4. What the Application guarantees, and its limits

4.1 The document. The document sent for signing is a rendering of the Confluence page at the moment it was rendered, as its reader could see it: the person who started the signing, the service account that made a REST API request, or, for a signing started by an automation flow, the Application. It is laid out with the site’s export styling and followed by the attachments the page refers to, where they were included. The limits of that rendering are stated in what the document contains. The customer can produce the same document without starting a signing, and should review it before a signing is started.

4.2 Change detection. The Application records, with each signing, a SHA-256 hash of the page’s space id, page id and version number, and reports whether the page’s current version still matches it. This detects that the page was edited after it was sent for signing. It does not identify what changed, and it does not cover the content of other pages, files or systems the page displays.

4.3 Page restrictions. Where chosen, the Application restricts editing of the page to the Application from the start of a signing, and viewing of it to the participants while the signing runs. The edit restriction stays after the signing completes, and is lifted if the signing is declined, cancelled or deleted. A Confluence space administrator, and on some Confluence plans an organisation administrator, can always remove or bypass a page restriction. The Application cannot make a page unchangeable.

4.4 Completion. A signing is recorded as complete only after Dokobit has confirmed it and the Application has obtained the signed file from Dokobit. The Application then attaches the file to the page. If Confluence refuses the upload, the signing stays recorded as complete, and the Application tries again when Dokobit repeats its notice. A notice that a signing was declined is acted on only after Dokobit confirms it.

4.5 Availability. A signing depends on the availability of Dokobit, of the Atlassian platform and of the signer’s identification method, none of which Oktul controls. Clause 12.3 of the Licence applies.

5. The customer’s responsibilities

5.1 The customer is responsible for:

  • the content of the page sent for signing, and the customer’s right to send it to Dokobit;
  • naming the right signers, and the accuracy of the names and email addresses given for them;
  • choosing the signing mode, the signature level, the format and the signing methods suited to the document;
  • reviewing the document before a signing is started;
  • keeping the signed file for as long as the customer needs it as evidence, in accordance with clause 6.

5.2 The customer must not use a document signed in Test mode as a signed document.

6. Retention of signed files

6.1 The signed file is attached to the Confluence page and is subject to the customer’s Confluence retention. Oktul keeps no copy. Deleting the signing’s record in the Application does not delete the signed file from the page, and removes the document from Dokobit for every signer.

6.2 Dokobit keeps a copy for the period stated in the privacy notice. Long-term preservation of a signature’s validity, for example by archive timestamping, is not part of the Application. A customer who needs it uses a preservation service of its choice.

7. Changes

7.1 A change to these terms is recorded in the release notes and made in accordance with clause 19 of the Licence.