Privacy and data handling

Version 1.1, effective 03.11.2026.

1. Scope

1.1 This notice describes the processing of personal data by Oktul SignPlus for Confluence (the “Application”). It forms part of the application licence and is read with the data processing addendum (the “Addendum”). Terms defined in the licence have the same meaning here.

1.2 It does not cover oktul.com or the personal data Oktul processes as a company, which are described in Oktul’s privacy policy.

1.3 The Application sends data outside the Atlassian platform. A signature is made by the signer on the signing service of Dokobit, a qualified trust service provider, to which the Application sends the document being signed and each signer’s name and email address. Every destination is listed in clause 5.

2. Roles and contact

2.1 For Customer Data processed by the Application, the customer is the controller and Oktul OÜ is the processor within the meaning of Regulation (EU) 2016/679 (the “GDPR”). Oktul processes it only to provide the Application, on the customer’s documented instructions, as set out in the Addendum.

2.2 Oktul, and not Atlassian, is responsible for the privacy, security and integrity of the personal data the Application processes.

2.3 Dokobit’s role depends on the signing mode:

• Your own token: signings run on the customer’s own Dokobit account, under the customer’s own agreement with Dokobit. Dokobit is not Oktul’s sub-processor. This is the only mode that produces a legally binding signature.
• Test: signings run on Oktul’s account in Dokobit’s test environment, under Oktul’s own contract with Dokobit, and Dokobit is Oktul’s sub-processor. The documents are watermarked and have no legal effect. Oktul has no access to the documents or the signing details on that account and sees only the number of signings. Test mode is for trying the Application, and the customer should not use it for confidential pages.

2.4 In Test mode, Dokobit notifies Oktul of each completed signing by email, to Oktul’s mailbox hosted by Zoho Corporation Pvt. Ltd. The notice carries the document name and each signer’s name and email address, and Zoho is Oktul’s sub-processor for it. A mailbox rule deletes each notice on arrival, unread. No notice is kept.

2.5 Atlassian Pty Ltd hosts the Application on the Forge platform on Oktul’s behalf and is Oktul’s sub-processor for that hosting, under the Forge Data Processing Addendum and the standard contractual clauses it incorporates.

2.6 For the licence record Atlassian provides when the Application is installed or ordered, and for support correspondence, Oktul is the controller. Oktul’s privacy policy governs that processing.

2.7 Contact details:

• Processor: Oktul OÜ, registry code 17589681, Seebi tn 1-703, 11316 Tallinn, Harjumaa, Estonia
• Data protection requests and legal notices: legal@oktul.com
• Support and vulnerability reports: the Oktul Help Center (opens in a new tab) or support@oktul.com

3. Data processed

3.1 The Application stores a record of each signing in Forge storage. The record holds:

• the space’s id, name, address and icon, the page’s id, version number and title, and the SHA-256 hash computed from the space id, the page id and the version number;
• the Atlassian account id of the user who started the signing;
• the signing’s status and reference, and the times the record was created, last updated and last checked with Dokobit;
• the Dokobit document token and the Dokobit environment the document was sent to;
• the request’s name, format, document digest, deadline and message;
• the number of participants who have signed, declined or not yet acted;
• the name, id and role of each Confluence group the signing was sent to;
• each participant’s name, email address, Atlassian account id where they have one, role, status, signing time, Dokobit token and the group they were invited through, in a record of its own per participant;
• the page restrictions in force before the signing, so they can be restored, and whether the page is locked;
• the id and address of the attachment that holds the signed document.

3.2 Every signing started from the page or through the REST API, and a signing started by an automation flow for a group or for more than 100 people, is first stored as a job. The job holds the request, its participants included, until the signing has been sent, and is then reduced to its outcome. A job record is deleted automatically after 7 days.

3.3 The record does not hold the document. The copy sent to Dokobit is excluded from the stored record, and the signed document is stored as an attachment on the Confluence page. The signed document contains each signer’s signing certificate, and the certificate of an Estonian eID includes the signer’s personal identification code. Where the customer’s administrator sets Personal code in the annotation (PDF only) to Visible, the PDF also prints it beside the signature. Anyone who can open the attachment can read it.

3.4 The Application also stores the settings, any uploaded font or logo, and the site’s activity log in Forge storage. A Dokobit token entered by the customer, and each webhook address with the headers configured for it, are stored in Forge’s encrypted secret storage. A saved token or header value is not displayed again. For each participant with an Atlassian account it keeps the time their name and email address were first read, for the reporting in clause 8.6. When it authenticates a REST API request, the Application keeps a SHA-256 hash of the token and the account it belongs to for 2 minutes, and never the token itself.

3.5 The Application keeps two logs:

A test that reads every logging call in the source fails the build on any identifier written to the Forge logs.

3.6 The Application reads a page as the person who started the signing, including when the signing runs in the background, using Forge’s offline user impersonation, so that the document contains what that person may see and nothing else. A signing started through the REST API reads the page as the service account that made the request. A signing or export started by an automation flow reads it as the Application.

3.7 The Application carries out no automated decision-making or profiling within the meaning of Article 22 of the GDPR. A signer decides whether to sign.

4. Where the data is stored

4.1 Data the Application stores in the customer’s site is stored on the Atlassian platform:

4.2 The location of data on the Atlassian platform is determined by Atlassian. Where the customer has configured data residency for Confluence, Atlassian stores the Application’s Forge storage in the same location as the customer’s Confluence data.

4.3 Dokobit states in its privacy policy (opens in a new tab) that it stores and processes data within the EU/EEA and does not transfer customer data outside it, and on its compliance page (opens in a new tab) that data is encrypted with TLS and AES-256 and that its information security is certified to ISO/IEC 27001 and ISO/IEC 27018. Its data processing agreement (opens in a new tab) and list of sub-processors (opens in a new tab) are published there too.

4.4 Dokobit identifies the provider as Dokobit, UAB (registry code 301549834) in its terms of service (opens in a new tab).

5. Recipients and transfers

5.1 The Application sends data to the following destinations and no others. The first five are declared in its Forge manifest. Adding one requires a new version that each administrator must approve.

5.2 Jira Assets objects, and the Jira work items selected in an Oktul Work Item Selector field, are read through Atlassian’s API proxy and are not sent outside the Atlassian platform.

5.3 The Application uses no analytics, telemetry, error-reporting service or third-party script. No Oktul server or database is in the data path.

5.4 Atlassian’s sub-processors are listed at atlassian.com/legal/sub-processors (opens in a new tab).

5.5 The declared permissions are shown on the Marketplace listing under Permissions.

6. Permissions

6.1 The Application requests the following scopes, each for the stated purpose:

6.2 The scopes the Application uses to read a page and its attachments, users, Assets objects and work items are marked for offline user impersonation, for the reason in clause 3.6. Atlassian does not allow impersonation for personal-data scopes, so read:email-address:confluence is read as the Application.

7. Limitations of access control

7.1 A signing started by an automation flow reads the page as the Application, so the document can contain content that the rule’s owner cannot see. The Application checks its own permission to edit the page, not the owner’s, and acts only in the spaces the customer’s Confluence administrator names in the Application’s settings. No space is named until an administrator names one.

7.2 A user who starts a signing from the page, and the account that makes a REST API request, can send it only to the groups they belong to. A signing started by an automation flow can be sent to any group, within the spaces named under clause 7.1.

7.3 The Application reads a group’s members, matches an email address to an account and reads participants’ email addresses with its own permissions, not those of the user who started the signing.

7.4 The Forge permission for *.atlassian.net covers every Atlassian site, because Forge cannot name one customer’s site. The Application retrieves an image from it only when the image’s origin is the site the page belongs to.

8. Retention

8.1 A signing record is kept until someone deletes it, or until the Application is uninstalled and Forge removes its storage. No retention period applies and nothing is deleted by age, because a finished signing’s record shows who signed what. A running signing can be cancelled by the user who started it or by a user who can edit the page, which deletes its record. A finished signing’s record can be deleted by a Confluence administrator, and by the users the customer’s administrator allows in the Application’s settings. The REST API applies the same rules. Deleting a record also removes the page’s signing state.

8.2 The activity log keeps the most recent 500 entries. The settings are kept until the Application is uninstalled.

8.3 Signed documents and exported PDFs are page attachments and are governed by the customer’s Confluence retention. Uninstalling the Application does not remove them.

8.4 According to Dokobit’s documentation of its signing API, Dokobit keeps a document for the signing period and no longer than 30 days, whether or not it is signed. Cancelling or deleting a signing in the Application removes it from Dokobit sooner, for every signer.

8.5 What Atlassian keeps after the Application is uninstalled is stated in clause 9.

8.6 The Application takes part in Atlassian’s personal data reporting (opens in a new tab) for every participant who has an Atlassian account:

• At least every 7 days, a scheduled function reports each such account to Atlassian with the time its name and email address were first read.
• When Atlassian reports an account closed, its name and email address are erased from every signing record and the account is no longer reported. The account id is kept, so the signing still counts the participant.
• When Atlassian reports an account updated, its current name and email address are read from Confluence and replace the stored ones. An address the profile now hides is removed, and an account Confluence gives no name for is erased as if closed.
• A participant without an Atlassian account is not part of this; clause 10.1 applies. A job record (clause 3.2) is deleted within one reporting period and is not reported.
• A signed document is not changed. Its signatures are part of it, and clause 8.3 applies.

8.7 The report uses Atlassian’s report accounts endpoint, which Forge calls on the Application’s behalf. No credential is configured for it, and it sends nothing beyond the account ids and times shown here.

9. Data portability and switching

10. Rights of data subjects

10.1 Data subjects have the rights of access, rectification, erasure, restriction of processing, data portability and objection under Articles 15 to 21 of the GDPR. For Customer Data, the controller is the customer, and requests are made to the customer, whose users can delete a signing record and its copy at Dokobit from the signing’s details and remove a signed document as any attachment. The Application does not erase one signer from a finished signing on request: the signed document carries their signature whatever the Application keeps, so the record stays as the evidence of who signed. Where the customer decides that an erasure request must be met, it deletes that signing’s record. The name and email address of a participant whose Atlassian account is closed are erased automatically, as clause 8.6 describes.

10.2 For data at Dokobit on an account Oktul holds, Oktul acts on the customer’s instruction with Dokobit. For data on the customer’s own Dokobit account, the customer’s agreement with Dokobit governs.

10.3 Oktul assists the customer with such requests free of charge, as clause 7.1 of the Addendum provides. Requests concerning data for which Oktul is the controller are sent to legal@oktul.com and answered within one month, extendable by two further months under Article 12(3) of the GDPR.

10.4 A data subject may lodge a complaint with the Estonian Data Protection Inspectorate (Andmekaitse Inspektsioon, Tatari 39, 10134 Tallinn, info@aki.ee) or with the supervisory authority of their habitual residence, place of work or place of the alleged infringement.

11. Security

11.1 According to Atlassian’s documentation, Forge provides tenant isolation and encryption in transit and at rest. Oktul operates no infrastructure in the data path and holds no credential for the customer’s site. Oktul’s own measures are set out in clause 5 of the Addendum.

11.2 In addition:

• the REST API issues no credentials. A caller presents an Atlassian OAuth token, which is validated for the site, and the caller’s own Confluence permissions on the page apply;
• the Application sends nothing to a webhook address until the customer’s administrator approves its host in Atlassian’s dialog. The approval can be withdrawn in Atlassian Administration;
• a completion is accepted only once Dokobit confirms it and the signed document has been downloaded, and a decline only once Dokobit confirms it;
• a participant’s email address is never sent to a browser. The REST API returns it only to an account that can view the page;
• every value the Application receives, from a browser, the REST API, an automation rule or Dokobit’s notification, is checked before it is used: identifiers must have their expected form, and text loses control characters and the Unicode controls that reorder text on screen and is held to a length. A webhook address must be a public https host, and a webhook header may not contain a line break; both are checked when saved and again before every delivery;
• 1,676 automated tests in 92 suites pass on the build of 03.11.2026, including suites for authorisation, injection and logging.

11.3 Oktul holds no audited security certification. The Application is listed in the Cloud Security Alliance STAR Registry at Level 1, a self-assessment of 138 CAIQ Lite questions, which is published in full in the registry and linked from the security assessment page. A self-assessment is not an independent audit.

11.4 Oktul’s own security testing, set out in clause 5.6 of the Addendum, applies to the Application. Its code is scanned before each release and on the 1st of every month; the first scan ran on 01.11.2026. The Application has two web triggers, the Dokobit notification and the REST API, which Forge opens to anonymous callers. The scan deploys the Application to a separate Forge environment on Oktul’s test site to attack both there, never on a customer’s site; the first attack ran on 03.11.2026. Its penetration test suite, written on 01.11.2026, holds 121 cases for the 88 entry points in its code, and first ran in full on 03.11.2026. Oktul runs that suite by hand every six months and whenever an entry point is new or changed, and its automated checks run with every scan. Before each release Oktul also reviews the Application’s software bill of materials (SBOM): every package added, upgraded or removed since the last review, and every licence that needs reading. Oktul gives the SBOM to a customer who asks for it.

12. Vulnerability reports and security incidents

12.1 A vulnerability is reported through the Oktul Help Center or to support@oktul.com, where it receives a reference. Oktul responds within 24 hours, Monday to Friday, and credits the reporter by name unless asked not to. Oktul does not pay bounties. Research in good faith is covered by clause 8.5 of the application licence. Security testing of a Forge application is testing of the Atlassian platform and must comply with Atlassian’s policies.

12.2 Oktul remediates vulnerabilities within the following periods, measured by CVSS score. The periods under Atlassian’s Security Bug Fix Policy (opens in a new tab) for cloud apps also apply, and the shorter period governs.

12.3 Oktul notifies the customer of a personal data breach affecting Customer Data without undue delay and in any event within 24 hours, as clause 7.3 of the Addendum provides.

13. Changes to this notice

13.1 The version and effective date at the top of this page identify the version in force. A change is recorded in the release notes. A change to the data processed, its recipients or who can access it is stated there, and a new destination is announced before the version that introduces it. Oktul notifies the technical contacts of installations and Atlassian of a material change.

13.2 Version history. 1.1, effective 03.11.2026: Oktul’s security testing in clause 11.4; a signing record kept until someone deletes it, and one signer not erased from a finished signing, in clauses 8.1 and 10.1; the test count in clause 11.2. 1.0, effective 09.10.2026.