Privacy notice

Effective date: the date Working Day Guard is first published on the Atlassian Marketplace.

Rillnook Labs is the product brand of the individual provider in Japan; the final legal seller disclosure is separate.

App processing

Working Day Guard for Jira evaluates project working-day rules and may correct the standard Due date. It transiently receives Jira events, trusted context and API responses. Used fields include issue and project references, Due dates, creation/update markers and relevant permission and entitlement results. A bounded Due-Date-only history check may be required when timestamps alone do not establish freshness. Responses may contain extra metadata that is parsed in memory; unneeded history authors/content are not intentionally used, persisted or logged. We do not claim that only selected fields enter the runtime.

Forge-hosted storage contains current project settings, dates and retained legacy optional labels, revision/publication information, audit with issue references and outcomes, deduplication/circuit/dispatch safety state, managed catalogs and authorized data-request progress. Issue references and labels can be personal data. The pre-release implementation no longer accepts or newly stores optional calendar labels. Existing labels remain in their original records and authorized return output, with original retention; they are not migrated or erased by this change. New audit/dispatch copies use required reason codes, dates and identifiers rather than raw label text. No claim of personal-data-free operation or PDR exemption follows; required issue references, recipient tracking and old data remain separately covered.

Authorized data fulfilment uses the requesting administrator's trusted Atlassian account identifier and stores a hashed recipient binding and request/progress metadata. The approved pre-release PDR implementation, not yet deployed, also retains the authenticated recipient's accountId, oldest acquisition time, minimal corresponding-copy references, reporting/instruction restart state and next-report time. The daily bounded handler reports only the required accountId/acquisition information to Atlassian's fixed personal-data reporting endpoint. Names, emails and profiles are not newly collected. Hashes and references are not treated as anonymous. Unknown subjects, past hashes and provider-managed copies are not inferred to be covered by this recipient path; reporting and customer-rights duties remain separate release conditions.

The only Jira business field written is Due date, with fixed history metadata. The app declares no external runtime egress and uses no external application server, holiday API, LLM or external analytics. This statement concerns the Forge app; website delivery and support correspondence are separate.

Retention and deletion

Audit has 90-day logical retention; completed deduplication records 7 days; ordinary lease records 1 day; circuit decisions use a 10-minute window and a 1-hour cleanup expiry. Settings remain until replacement or authorized deletion. Managed records use application expiry and transactional hourly/opportunistic cleanup. Logical expiry is not physical deletion. Indexed bodies/pages do not use an independent platform TTL. Active return requests and unresolved Jira dispatches can hold data; an overdue return hold requires customer-instruction review after 7 days rather than silent indefinite retention.

Fulfilment results normally expire after 7 days. Minimal replay/regeneration controls can remain for the installation lifecycle. An authorized request does not promise immediate, all-copy or zero-byte erasure. Forge logs and provider backups are distinct. Operational logs contain bounded outcomes/error classes and action hashes; hashes are not assumed anonymous, and deleting KVS does not delete logs.

PDR tracking is removed after all corresponding copies and pending instructions are gone and completion has been reconciled. No extra90-day tracking period is added, and a tracking record is not itself a reason to retain it forever. PDR and authorized rights processing do not stop merely because paid features are OFF or the license is inactive. Logical expiry, a missing key or HTTP204 alone is not proof that every copy has been erased. The daily handler and these storage changes remain undeployed.

The ordinary page offers bounded return/deletion of currently authorized visible records; PARTIAL is not complete fulfilment. A separate signed administrator procedure traverses the managed catalog in bounded steps and acknowledges return pages. It requires verified customer authority and recipient, with paid processing kept separate. Legacy records, inaccessible installations, log/backup scope and earlier applicable deadlines need a verified additional route. These capabilities are release candidates; outstanding deployment, live-behavior and issuer-procedure gates must close before real entrusted use. An explanation of a gap does not excuse existing-data duties.

Atlassian describes 28 days of hosted-storage retention after actual uninstall and a 21-day window for an authorized recovery request with customer consent. Reinstall alone does not restore. Uninstall is not selective deletion, does not return data first and does not remove Jira's own issues/history.

Website and email

This static site has no forms, advertising, external analytics/scripts/fonts or tracking cookies. Cloudflare Pages/CDN processes request metadata such as IP addresses for delivery/protection through its global network. This is not a claim of no information processing or Japan-only processing.

Ordinary correspondence is used for support, contract administration, security and legal duties. Customer-instructed investigations are a separate processor/subprocessor activity. Purelymail (Add Rabbit LLC) uses the published AWS Northern Virginia location. The recorded configuration has search indexing disabled and mailbox TOTP. This is not end-to-end encryption or a delivery guarantee. The app does not automatically email customer data. Applicable processing/transfer/assistance coverage must be established before entrusted support; synthetic examples still involve real sender metadata.

Ordinary mail is retained 180 days after actual case closure and removed by 210 days through 30-day housekeeping. Open cases and documented necessary legal/dispute/security exceptions are handled separately. Earlier applicable deadlines take priority. Purelymail describes one-month deleted-email backups; that published period is not proof of individual purge. Provider copies and backups remain protected and are not reused for unrelated purposes.

Rights, roles and protection

For customer-controlled Jira data, contact your Jira administrator; for our correspondence or a data request, contact privacy@rillnook.com. We verify minimum necessary authority, scope and recipient and protect other customers' data. No initial identity-document or secret submission is requested. Mistakenly sent secrets are not used; the owner contains disclosure, minimizes copies and may ask the sender to revoke the affected credential.

Customer-instructed personal data is governed by the DPA. Independent website/correspondence purposes are assessed separately. Processing may involve Japan, the relevant Atlassian locations, Cloudflare's global network and US email infrastructure. Contract incorporation is not proof that every transfer has a lawful mechanism; applicable terms and safeguards must be established before use. No advertising profiling, data sale, AI training or unrelated reuse is authorized.

Controls include least-privilege authorization, tenant/project boundaries, bounded input checks, Due-Date-only writing and fail-safe entitlement checks. No absolute-security or atomic-Jira-update guarantee is made. Changes require clear version/effective-date handling and cannot retroactively reduce existing obligations.

Data-request recovery limits

An uncertain report does not by itself erase needed copies or cause unlimited retransmission. The pre-release implementation enters PDR_HOLD with only the existing necessary progress. Current customer authority, the same instruction and recipient, a new signed grant/nonce and matching installation and revision can resume the customer request. This does not reset uncertain Atlassian reporting, its attempt count, acquisition times or cycle. Existing expiry and valid deletion instructions remain separate; HOLD is neither completion nor permission for indefinite retention. Unacknowledged returns keep their existing review deadline. Received PDR instructions are retained even when a period is invalid. Tracking ends only after corresponding copies/instructions are reconciled.

Request authorization and conflicting instructions

Return/deletion requires a currently authenticated Jira administrator with authority for the target site/installation; the project route retains its project and visibility checks. Normal project policy editing is unchanged. Email correspondence, client claims or a signature alone are not execution authority. Signing keys remain in the existing secret-management route only. Lost keys, unknown authority or target mismatch fail closed without an authorization bypass.

When a received PDR erasure instruction conflicts with a required copy in an active signed return, the candidate retains both instructions and the necessary copy in PDR_HOLD for a specific owner decision. Original expiry and review dates remain. RENEW cannot bypass a captured instruction, and no indefinite retention, legal priority or completed fulfilment is inferred. Unrelated copies and non-conflicting erasure/expiry keep their existing bounded path. Actual key custody, managed execution, legal adoption and all historical/provider-data fulfilment are not established here.