DPA Setup Page — Linkwright for Jira
This DPA Setup Page, together with the Bonterms Data Protection Addendum (Version 1.0) (the “DPA”), forms part of the Agreement below.
| Field | Value |
|---|---|
| Agreement | The Bonterms Standard End User Agreement, with our Provider-Specific Terms, under which the customer uses Linkwright for Jira through the Atlassian Marketplace. |
| Provider | Saad Lagzouli, sole proprietor (entrepreneur individuel) trading as Linkwright (SIREN 130 855 364, France) |
| DPA Effective Date | The date the customer first installs a paid or evaluation version of the App. |
| Provider privacy contact | saad@linkwright.io |
| Audit | Provider answers written security questionnaires once per year at no charge, from its documentation and this page. On-site audits: not offered (the Provider operates no infrastructure; processing runs on Atlassian Forge, whose own audit reports apply). |
| Subprocessor notification | Update of the Subprocessor List at the URL of this page, at least 30 days before a new Subprocessor processes Customer Personal Data. |
Subprocessor List
| Subprocessor | Function | Location |
|---|---|---|
| Atlassian Pty Ltd and its affiliates (Atlassian Forge) | Runs the App’s code, stores its data (Forge SQL, Forge key-value storage) and its function logs | Atlassian’s hosting regions |
Not Subprocessors: GitHub is the customer’s own service, from which the customer instructs the App to read data; Atlassian Jira is the customer’s own site, to which the App writes data.
Schedule 1 — Subject Matter and Details of Processing
Nature and purpose. Linking the customer’s GitHub activity to Jira issues: reading GitHub data for repositories the customer attaches to Jira projects, indexing it per issue, displaying it in the App’s issue panel and in Jira’s native Development panel, and reporting synchronization freshness.
Categories of data subjects. Contributors to the customer’s GitHub repositories (commit authors, branch pushers, pull request authors, requested reviewers, reviewers); the customer’s Jira administrator who associates a GitHub installation; owners of personal GitHub accounts whose login appears in a repository name.
Categories of personal data.
- commit author names and the GitHub name of whoever pushed a new branch; pull request author, requested reviewer and reviewer GitHub logins;
- GitHub logins contained in repository names (
owner/name) of personal accounts; - the GitHub login of the Jira administrator who associated an installation;
- content that may contain personal data: first line of commit messages, pull request titles, branch names.
No special categories of data are intended to be processed. The App stores no email addresses of commit authors and no Atlassian account identifiers.
Frequency. Continuous, on each GitHub webhook delivery and on periodic reconciliation.
Duration and retention. For as long as the App is installed on the customer’s site. Webhook delivery identifiers: 24 hours. Function logs: per Atlassian Forge log retention. On uninstall, the App’s Forge storage and the data sent to Jira’s Development panel are deleted according to Atlassian’s rules.
Schedule 2 — Technical and Organizational Measures
- No Provider-operated infrastructure: code and data stay on Atlassian Forge, isolated per customer site; no copy to systems the Provider controls.
- Authentication of inbound data: every GitHub webhook is verified with an HMAC-SHA256 signature over the raw body, compared in constant time, with a per-site secret; missing or invalid signatures are rejected (fail closed).
- Secrets: GitHub App private key and webhook secrets in Forge encrypted variables or Forge encrypted storage; never in code, URLs or logs.
- Least privilege: Jira scopes limited to app storage and development/deployment information;
outbound network access limited to
api.github.comand GitHub’s OAuth endpoints. - Customer isolation of repositories: only installations associated by an administrator who controls the GitHub account (verified server-side), and only repositories a project administrator attaches to that project, are processed.
- Data minimization in logs: no commit messages, author names, emails, reviewer logins, tokens or secrets in logs (reviewed line by line, re-reviewed with each new log statement).
- Database safety: parameterized queries only.
- Dependency hygiene:
npm auditbefore each release; no known critical or high vulnerability in production dependencies at submission. - Vulnerability handling: Atlassian Marketplace security bug fix policy (critical issues fixed within 10 days).
Schedule 3 — Cross-Border Transfer Mechanisms
The Provider is established in France (European Union). Customer Personal Data is stored and processed on Atlassian Forge; transfers by Atlassian outside the EEA are governed by Atlassian’s own data processing terms and transfer mechanisms. The Provider does not otherwise transfer Customer Personal Data outside the EEA.
Schedule 4 — Region-Specific Terms
None.