1. Data controller
KeulTech — Andreas Keul
Wildgansweg 4, 31535 Neustadt, Germany
Email: info@keul.tech · Phone: +49 173 639 0736
The controller is the natural or legal person who alone or jointly with others determines the purposes and means of the processing of personal data.
2. Hosting and server log files
This website is hosted by an external provider. The web server automatically collects and stores information in server log files, which your browser transmits automatically: browser type and version, operating system, referrer URL, host name of the accessing computer, time of the server request, and IP address. This data is not merged with other data sources. Processing is based on Art. 6(1)(f) GDPR — the operator has a legitimate interest in the technically error-free presentation and optimisation of the website.
3. Contact by email, telephone or fax
If you contact us, your enquiry and any personal data you provide will be stored for the purpose of processing your request and in case of follow-up questions. We do not pass this data on without your consent. Processing is based on Art. 6(1)(b) GDPR where the request relates to the performance of a contract, and otherwise on Art. 6(1)(f) GDPR. The data remains with us until you ask us to delete it or the purpose for storage ceases to apply. Mandatory statutory retention periods remain unaffected.
4. Google Fonts (local hosting)
This site uses Google Fonts, hosted locally. No connection to Google servers is established when you visit this site.
5. Your rights
You have the right to obtain information about the origin, recipients and purpose of your stored personal data free of charge at any time, and the right to have this data corrected or deleted. You may withdraw consent at any time with effect for the future. You also have the right to data portability and the right to lodge a complaint with the competent supervisory authority. For any of these, contact us at info@keul.tech.
6. Atlassian Marketplace app: "Dependency Guard for Jira"
This section describes data processing by our Atlassian Marketplace app, separately from the website above.
6.1 Nature of the app
Dependency Guard for Jira is a pure Atlassian Forge app. It runs entirely on Atlassian’s own infrastructure. It has no backend of its own, makes no outbound network connections, uses no external services, and engages no sub-processors. No data ever leaves the Atlassian platform.
6.2 Data the app reads
Within the Jira instance where it is installed, and only via the permissions granted at installation (read:jira-work), the app reads:
- issue links between issues,
- issue status and status category,
- issue summaries,
- the project identifier.
In user-facing contexts, these reads are performed under the requesting user’s own identity, so the user’s existing Jira permissions are enforced.
6.3 Data the app stores
The app uses only the Atlassian Forge Storage API (storage:app). It stores exactly two kinds of record:
| Record | Content | Retention |
|---|---|---|
| Project settings | Three configuration values: whether notifications are enabled, whether auto-guard is enabled, and the name of the blocker link type. Contains no personal data. | Until the app is uninstalled or the setting is changed |
| One-time override | The Atlassian accountId of the user who granted a one-time permission to complete an issue despite open blockers, plus an ISO-8601 timestamp. Used solely to attribute the override in an audit comment on the issue. | Maximum 15 minutes; deleted when consumed |
The Atlassian accountId is a pseudonymous identifier issued by Atlassian. The app stores no names, no email addresses, no IP addresses and no free-text user content.
6.4 Data the app writes
The app posts comments on Jira issues — to notify a waiting issue that its blocker is done, and to record an audit trail when an override is granted. Where auto-guard is enabled and an issue is completed while blockers are still open, the app reverts that status transition.
6.5 Legal basis and controller
Where the app processes personal data on behalf of the customer operating the Jira instance, that customer is the controller and KeulTech acts as processor. Processing is limited to what is described above and is necessary for the app’s contractual function under Art. 6(1)(b) GDPR.
6.6 Access by the provider
KeulTech has no runtime access to customer data. There is no provider-operated database, log store or admin console holding customer data. Diagnostic access is limited to Forge application logs in the Atlassian Developer Console, secured by the provider’s own Atlassian account with two-factor authentication.
6.7 Contact
Questions about app data processing: info@keul.tech
The German version of this privacy policy is available at https://keul.tech/datenschutz.
7. Atlassian Marketplace app: "Component Archiver for Jira"
7.1 Nature of the app
A pure Atlassian Forge app that runs entirely on Atlassian’s infrastructure. It has no backend of its own, makes no outbound network connections, uses no external services and engages no sub-processors.
7.2 Data the app reads
Within the Jira instance (permissions read:jira-work, write:jira-work, manage:jira-project): project components, the components set on work items, work item status and update dates. User-facing reads run under the requesting user’s own identity.
7.3 Data the app stores
(Forge Storage, storage:app) – per project: IDs of archived components, their original name and description, archive date, reason, successor component, the Atlassian accountId of the administrator who archived them, and the project settings. Retention: until the component is restored, the settings change or the app is uninstalled.
7.4 Data the app writes
It renames archived components and adds a note to their description, removes archived components from work items (and sets the successor) and adds a comment explaining the change.
7.5 – 7.7 – Legal basis/controller, access by the provider and contact as in 6.5 – 6.7.
8. Atlassian Marketplace app: "Project Archiver for Jira"
8.1 Nature of the app
A pure Atlassian Forge app; runs entirely on Atlassian’s infrastructure, no outbound connections, no external services, no sub-processors. All actions run under the identity of the Jira administrator using the app.
8.2 Data the app reads
Projects, their permission scheme, notification scheme and category, project roles, the number of work items and the date of the last update.
8.3 Data the app stores
(Forge Storage) – per archived project: project ID and key, original name, original permission scheme, notification scheme and category IDs, archive date and the reason entered by the administrator; plus a history of archive/restore actions. No personal data (no account IDs, names or e-mail addresses).
8.4 Data the app writes
It creates a read-only permission scheme, an empty notification scheme and the category "Archived", assigns them to archived projects and adds "[Archived]" to the project name; restore puts the original values back. Nothing is deleted.
8.5 – 8.7 – as in 6.5 – 6.7.
9. Atlassian Marketplace app: "Google Chat Notifications for Jira"
9.1 Nature of the app
An Atlassian Forge app that sends Jira updates, scheduled reports and alerts to Google Chat spaces configured by the customer. It has no backend of its own. Its only outbound connection is to Google Chat incoming webhooks (https://chat.googleapis.com).
9.2 Data the app reads
For work items that match the configured filters, reports or alerts: key, summary, status, type, priority, assignee, due date, changed field values, comment text, the display name of the user who made the change, watchers and mentions (to decide who receives personal notifications), and whether a recipient may view the work item. For Jira Service Management requests also the request type, the running SLAs (time left, breached, paused) and whether a comment is internal or visible to the customer.
9.3 Data sent to Google Chat
A message card per update containing: work item key and summary, status, assignee, type, priority, changed field values or up to 600 characters of comment text, the display name of the user who made the change and a link to the work item; for service requests also the request type and SLA status. Reports and personal summaries contain a list of matching work items (key, summary, status, assignee, due date) and their number; alerts contain one work item each. Messages are sent only to spaces whose webhook URL a Jira administrator (team spaces) or the user (personal space) has entered. Google LLC processes these messages under the customer’s own Google Workspace agreement; the customer decides which spaces receive data. Personal notifications, summaries and alerts only contain work items the recipient may view in Jira.
9.4 Data the app stores
(Forge Storage) – webhook URLs (encrypted, as Forge secrets); space settings (name, projects, events, status and field filters, JQL filter, language); report and alert settings (name, JQL, target space, days, time, time zone); for each alert the keys of the work items already alerted while they keep matching; per user with personal notifications their Atlassian accountId as key and their settings (including summary time and time zone); a delivery log of the last 30 deliveries (time, space name, work item key, event type, result – no message content, no account IDs); messages waiting for a retry after a Google rate limit (deleted after delivery, at most ~10 minutes). Retention: until the setting is removed or the app is uninstalled.
9.5 – 9.7 – Legal basis/controller (customer = controller, KeulTech = processor), access by the provider and contact as in 6.5 – 6.7. KeulTech has no access to the Google Chat spaces or their content.