Version 1.3 · Effective 29 August 2026
This policy explains what data Overdue Digest for Jira (the “app”) reads, sends, stores and logs, and how it is secured. The app is published on the Atlassian Marketplace by Myriastra Studio (“we”, “us”), and is built on Atlassian Forge. The security disclosures are in section 8, Security. The data residency declaration is in section 6.
The app runs entirely on Atlassian's Forge platform and meets the technical requirements for the Runs on Atlassian program (see section 8). We operate no servers, no database and no analytics infrastructure of our own for this app. The app makes no network requests to any host outside Atlassian, and we operate no system that receives your data. The digest email itself is delivered by Atlassian's own notification service to each recipient's mail provider — see section 3.
Once a day the app queries Jira for work items that are not yet done and whose due date is either in the past, or within the next 7 days. It then narrows that set to the two bands it actually emails about — 8 or more days overdue, or due in 3 to 7 days — and discards the rest. Work items outside those bands are read but not used, and nothing about them is kept.
For each work item returned, the app takes:
Jira returns each requested field as a complete object. The app takes only the values listed above and keeps nothing else from the response.
The app also reads the list of Jira Service Management projects (so it can skip them) and your
site's base URL (so it can build links back into Jira). It reads this data with the
read:jira-work scope, using its own app identity, and it is subject to the same
project permissions as any other user — work items in projects the app cannot browse are not returned.
Once a week the app asks Jira to send each recipient a single digest email, using
write:jira-work and Jira's own notification service. We do not operate a mail server;
the message is queued and delivered by Atlassian to the email address on the recipient's Atlassian account.
The email body includes each work item's key, summary and status. For work items assigned to someone other than the recipient, it also includes the assignee's display name. The email also shows how many days each item is overdue or how many days remain until its due date, and a link back to Jira.
Who receives the email: the assignee and the reporter of a matching work item.
If a matching work item has no assignee, its reporter still receives it, and the row is marked
Unassigned. This means a recipient can see work items that are assigned to another person.
Work items with neither an assignee nor a reporter are skipped.
The app stores the following in Forge storage, which is hosted by Atlassian:
The app does not store work item keys, summaries, statuses, due dates, display names or email addresses. Those are read, used to compose the email, and discarded when the run ends.
The app writes to Forge's application log in two situations.
Once per completed run, whether or not anything went wrong, it writes a single operational line so that we can tell "the run did not happen today" apart from "the run happened and had nothing to send". That line carries no personal data — only whether delivery is switched on, the timestamp of the first digest this site ever sent, and a schema version.
When something goes wrong it writes a diagnostic entry, and where the failure happened decides what that entry carries. A failure while asking Jira to send, or while assembling one recipient's digest, is recorded with either an Atlassian account ID, or a work item ID, depending on which stage failed — the two never appear in the same entry — alongside the error, which may come from Jira or from our own handling of the work item data. A failure to read or write Forge storage is recorded with no identifier at all: the fact that it failed, and the error. We do not write summaries, display names or email addresses to the log ourselves; error text returned to us by Jira or Forge is recorded as we receive it. Forge logs are held on Atlassian's infrastructure and are retained according to Atlassian's platform policy; we read them only to diagnose faults, and we do not copy them anywhere else.
Atlassian asks each app to define and publish what it treats as in scope and out of scope for data residency. This section is that declaration. It adds no new processing — it restates what sections 2 to 5 already describe, in the terms Atlassian's data residency programme uses.
What the scope is drawn around. A value is in scope when two things are true at once: it identifies or relates to a person on your site, and this app writes it to Forge hosted storage. Both tests matter, and they fail in different directions. Because the second test is about where a value is written, the same kind of value can be in scope in one place and out of scope in another — an account ID is in scope where the app stores it, and out of scope where it lands in Atlassian's platform log. Because the first test is about what the value is, things the app certainly does write to storage — settings, per-week counters, run markers — are still out of scope: they describe projects, configuration and runs rather than people. Where either test decides a case below, we say which one.
All in-scope End-User Data is held exclusively in Forge hosted storage, which Atlassian operates. We operate no storage of our own, so where that data physically sits is determined by the Atlassian platform for the site the app is installed on, under Atlassian's data residency policy rather than under any arrangement of ours.
⚠️ Read “exclusively” against the definition above. It means this app writes in-scope data to no store other than Forge hosted storage. It does not mean an account ID appears nowhere else on Atlassian's infrastructure: the Forge platform log is a separate location with a separate guarantee, and we set out what we can and cannot say about it under Platform logs below.
Delivered email is also outside this scope. Once Atlassian's notification service has sent a digest, the message sits in the recipient's own mailbox with whatever provider they use — see section 9. We never held it, and we cannot recall it.
The app has no sub-processors. It shares data with no third party, and it contains no analytics, advertising or tracking code. This page itself loads a web font from Google Fonts; the rest of the page is served by Cloudflare Pages.
This section is the security policy for Overdue Digest for Jira. Myriastra Studio is a one-person studio, and this app's security rests on how little the app is able to do, rather than on a formal compliance program. Everything below is a property of the app rather than a promise about us.
Who is responsible for what. Atlassian provides the platform the app runs on: the infrastructure, tenant isolation, TLS in transit, encryption at rest for Forge storage, and the authentication of everyone involved. We are responsible for the app itself: the permissions it asks for, what it does with them, what it writes to logs and storage, its dependencies, and fixing it when something is wrong. Nothing below asks you to take Atlassian's certifications as ours.
There is no Myriastra Studio server, database, queue or endpoint anywhere in this app. It exists only as functions running on Atlassian's Forge platform, and its manifest requests no permission to contact any host outside Atlassian — so the platform itself refuses to let the app send data anywhere else. It also has no inbound entry point: there is no web trigger and no URL of ours that anyone can call. This egress property is what makes the app eligible for Atlassian's Runs on Atlassian program. That badge is a check on where data can go, not Atlassian vouching for the rest of our code, and we do not present it as one.
The app does not ask for, receive or store any API token, password or shared secret belonging to you or to anyone on your site. It authenticates to Jira using the app identity Atlassian issues to it, and it never acts on behalf of a user. There is no credential of yours for us to lose, and none for you to rotate.
The app requests three scopes and no others: read:jira-work, write:jira-work
and storage:app. These are declared in the app's manifest, which is the complete list of what
the app is able to do, and Atlassian requires each one to be justified before an app can be listed on the
Marketplace.
We want to be plain about the second one, because it is the one that looks alarming on the installation
screen. write:jira-work is required by the single Jira endpoint the app calls to make Jira send
the digest email. Jira grants that scope more broadly than the app uses it: it would also
permit creating, editing, transitioning and deleting work items, and adding comments and attachments.
The app does none of those things. It does not create, edit, transition or delete work
items, and it does not add comments or attachments. The only write it performs is asking Jira to send the
email.
Every byte the app touches stays inside Atlassian — your Jira site, and Forge storage hosted by Atlassian. Encryption at rest and TLS in transit are therefore provided by the Atlassian platform under Atlassian's own security program. We add no encryption of our own, and we operate no storage outside Atlassian in which your data could be held to a weaker standard.
The app's runtime dependencies are Atlassian's own Forge packages and React; it bundles no analytics, advertising or tracking library. Every release is built from a version-controlled source tree and has to pass the project's automated checks before it is deployed.
Updates are delivered by Atlassian, not by us. Once we publish a version, Atlassian rolls it out to the sites that already have the app; we have no channel of our own for pushing code to your site. A version that asks for new permissions is the exception — Atlassian holds it until one of your administrators approves the new scopes, so this app cannot quietly widen what it is allowed to read or write.
Please write to contact@myriastrastudio.com with security in the subject line, describing what you found and how to reproduce it. If you believe an issue is being actively exploited, say so in the subject line so that it is triaged first. Please test only against a site you control, and please do not access or modify data that is not yours.
Please do not put customer data, work item contents or any other confidential material in your report. That mailbox is an ordinary email account outside Atlassian — the “nothing leaves Atlassian” property above is a property of the app at runtime, and it does not extend to an email you send us.
We will acknowledge your report and tell you what we intend to do about it. Confirmed vulnerabilities are fixed on the timeline set by Atlassian's Security Bug Fix Policy, which applies to us as a Marketplace partner. We do not run a bug bounty, do not run continuous scanning or scheduled penetration tests, and cannot offer payment.
If we become aware of a security incident affecting this app, we will investigate it, report it to Atlassian as the Marketplace Security Enforcement Policy requires, work with Atlassian on containment and a fix, describe it on this page, and contact affected installations wherever we are able to identify them.
So that a procurement team can rule us in or out quickly: Myriastra Studio holds no SOC 2 report, no ISO 27001 certificate and no other third-party security certification, has not completed a CAIQ Lite assessment, and offers no separate data processing agreement. If your organisation requires any of those, this app is not yet a fit — please write to us before you buy rather than after.
Uninstalling the app stops all further processing. Atlassian deletes the app's Forge storage after the retention window defined by the Forge platform — currently up to 28 days, so the data is not erased the instant you uninstall — and reinstalling does not restore it.
Emails that have already been delivered stay in the recipients' mailboxes. We cannot recall or delete them, because we never held them.
A Jira administrator can switch the digest off at any time in Settings → Apps → Overdue Digest, or uninstall the app.
Because the app processes data only inside your own Atlassian site, requests about a specific person's data are usually best served by your Jira administrator, who controls that site. If you would like to contact us about this policy or about a data request, write to contact@myriastrastudio.com. If you are reporting a security vulnerability, please read section 8 first — it tells you what to include and, more importantly, what not to.
If we change how the app handles data, we will update this page and the version and date at the top of it.