Customer Data Processing Addendum

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

1. Scope, roles and priority

This DPA is between the ordering Customer and the individual in Japan identified in the final legal disclosure, trading as Rillnook Labs (Provider), for Working Day Guard for Jira. It applies to personal data processed on Customer's documented instructions to supply the Product or specifically agreed support (Customer Personal Data). Customer is controller, or a processor authorized by its controller; Provider is processor or subprocessor accordingly.

Independent website administration, Provider's own business correspondence, legal compliance and business security are separately described in the Privacy Policy. Actual purposes and applicable law determine roles. This DPA prevails for data protection as specified in the Provider-Specific Terms; mandatory law and binding transfer clauses take priority.

2. Instructions and processing details

The Agreement, documented Product configuration and authorized written requests are the instructions. Processing is limited to operating the working-day policy, evaluating or correcting Due Dates, displaying authorized audit, preventing duplicate or unsafe actions and providing agreed support. Provider will notify Customer of an apparently unlawful instruction and pause affected processing pending clarification unless law requires otherwise. A legally compelled departure will be notified beforehand unless prohibited.

Data subjects may include Jira users, personnel and others identifiable through issue references, retained legacy calendar labels or instructed support. Stored Product data comprise project-scoped policy, calendar dates and retained legacy labels, revision/publication information, audit records with issue references, event/processing times, source/target Due Dates, outcomes and policy/reason/error information, and safety records. The pre-release implementation accepts no new optional calendar-label input and creates no new raw-label audit/dispatch copies; existing values remain in the same records with original retention and authorized return. Its approved recipient PDR path additionally stores the trusted accountId, oldest acquisition time, minimal copy references, reporting/instruction restart state and next-report time. It adds no new name, email or profile collection. A hashed or internal record can still relate to a person and remains protected where applicable.

The pre-release PDR implementation reports accountId and oldest acquisition time to Atlassian from a bounded daily handler, independent of paid-feature license and OFF. Tracking ends after corresponding copies and pending instructions are absent and completion has been reconciled, without an additional90-day period or circular indefinite retention. A missing key, TTL or HTTP204 alone is not full-copy erasure. PDR service instructions and signed customer requests are distinct authority paths. Unknown-subject, legacy and provider-managed copies, unknown HTTP outcome and cross-installation service semantics remain separate conditions. These changes have not been deployed and do not establish actual fulfilment.

Jira events, resolver context and API responses are transiently received and may include metadata beyond the fields used by the algorithm. The algorithm selects issue/project references, Due Dates, created/updated markers and relevant permission/entitlement results. Its issue-local history request filters for Due Date, reads at most four pages, rejects oversized responses and any history, and requires complete pagination and an exact authoritative reread for acceptance. Unneeded history authors, account metadata and content are not intentionally used, persisted or logged, but responses are received and parsed in memory. This is not a claim that only selected fields enter the runtime. Do not enter sensitive personal information in settings or send unrestricted Jira exports.

Operations include retrieval, evaluation, Due-Date-only update with fixed history metadata, managed storage, authorized return/deletion progress and protected retention. Operational state includes bounded catalogs, safety records and replay/regeneration controls. Fulfilment results normally expire after seven days; minimal anti-replay/regeneration controls can remain for the installation lifecycle. Forge logs may contain bounded outcome/error classes and action hashes, with platform invocation metadata separate from KVS. Such hashes are not guaranteed anonymous. No Customer Data is used for advertising, AI training or unrelated purposes.

3. Confidentiality and safeguards

Access is limited to personnel with a need to know and confidentiality duties. The current operator is the individual Provider; additional personnel require authorization and equivalent protection. Measures include Forge-hosted runtime/storage, no declared external app egress, bounded validation, project-admin and current issue-visibility checks, final write permissions, Due-Date-only writes and settings/freshness/deduplication controls.

The recorded MFA measures cover the Cloudflare account, Purelymail administration and contact mailbox; they do not certify every operational or customer account. Credentials and internal lease/control values are not customer export material, without excluding associated personal data from applicable access or deletion duties. Provider minimizes support information and does not request passwords, cookies, MFA/backup codes, private keys or financial/identity documents. Measures may evolve without materially reducing protection. No atomic GET-to-PUT update or absolute security guarantee is promised.

4. Subprocessors and general written authorization

On entry into this DPA, Customer gives general written authorization for the relevant subprocessors identified here: Atlassian for Forge runtime/hosted storage; and Purelymail (Add Rabbit LLC, AWS US-East-1, USA) only for separately agreed Customer-instructed email support after the necessary contracts, transfer and fulfilment conditions are met. Atlassian's processing for Customer's own Jira service is a separate relationship. Cloudflare's global public website/CDN is not an app-data subprocessor merely because it serves the website; independent site administration is separate.

Authorization does not cure an absent processing agreement or unlawful transfer. Provider requires appropriate written protection and remains responsible as required by law and the Agreement. Customer-directed investigation in email needs its safeguards before real instructed data is processed, including free trials. Even a synthetic reproduction normally includes a real sender address and routing metadata, handled under the ordinary-correspondence purposes in the Privacy Policy.

Provider will maintain the relevant names, purposes and locations, monitor applicable supplier change notices and give affected Customers written advance notice through the existing agreed contract contact before using a new or replacement subprocessor. Notice identifies the change and gives a reasonable opportunity to object on data-protection grounds. The parties will seek a lawful resolution; if unresolved, affected processing must not proceed using the disputed supplier and may require suspension or termination, preserving return/deletion duties. General authorization avoids individual re-approval for every change; a website edit alone is not notice. This is a manual correspondence procedure, not an automated notification feature. Mandatory or binding transfer-clause notice periods prevail. Provider must manage upstream timing, not promise an upstream window it does not control.

5. Personal-data incidents

Provider will notify Customer without undue delay after becoming aware of a breach affecting Customer Personal Data and provide available facts, affected categories, likely consequences, mitigation and a contact, with staged updates. Provider will preserve proportionate evidence and cooperate on remediation. No fixed notification-hour count is promised; statutory deadlines apply.

Customer remains responsible for its regulator/data-subject duties. Provider will not notify Customer's data subjects or speak on its behalf without lawful instruction unless legally required. The owner makes final operational and external-notice decisions; internal approval and support hours cannot excuse mandatory or timely notice.

6. Assistance, audit and costs

Provider will assist with data-subject rights, impact assessments, regulator consultation and security duties, taking account of the processing and information available. Requests go to privacy@rillnook.com. Provider verifies minimum necessary authority, routes requests about Customer-controlled Jira data to Customer and protects other customers' information.

Ordinary review starts with relevant existing documentation, written answers and available platform assurance reports. Customer gives reasonable advance notice identifying the processing, questions and evidence needed. Where these do not reasonably resolve the questions, Provider will cooperate with a proportionate audit by Customer or a qualified independent auditor bound to confidentiality. The parties coordinate scope, timing, duration and safeguards to avoid unnecessary repeated work, disclosure of other customers' data or credentials, and disruption. Inconvenience alone does not justify withholding necessary evidence.

Customer ordinarily bears the fees of auditors and external experts it independently appoints; unilateral appointment creates no fee obligation for Provider. Additional optional assistance may require prior written agreement on scope and costs. No new fee schedule is created. Applicable law, binding transfer clauses and valid indemnification obligations override this allocation where required. Necessary rights assistance, incident response and mandatory cooperation must not be unduly delayed by payment, fee negotiations or internal approval. Provider's own work, vendor charges and performance duties are distinct from customer-facing damages caps.

An incident, a specific credible concern of non-compliance or an authority's requirement calls for timely, risk-appropriate cooperation, not automatic deferral to ordinary scheduling or refusal as a duplicate. Mandatory authority and transfer-clause rights remain intact. No penetration-testing permission or unverified access to supplier premises is granted.

7. Return, deletion and actual capability limits

Customer may issue authorized return/deletion instructions. Underlying Jira issues and history remain under Customer's Jira controls. The ordinary settings page displays current settings and recent audit from at most 25 candidates filtered by retention and current issue visibility. Its separate project data controls return bounded visible records and may report PARTIAL. The signed administrator fulfilment workflow described below is distinct from that ordinary view. Existing mail download/IMAP can return selected correspondence to a verified authorized recipient, excluding others' messages and unnecessary secrets. Mail return is not a complete Product-data return mechanism.

At the end of relevant processing, Provider will, at Customer's choice, return or delete Customer Personal Data and delete remaining copies, except where retention is legally required. Return follows the applicable DPA or legal deadline and is distinct from the standard deletion rule. Under Section 12.4(b), after termination or expiration of the Agreement, Provider must delete Customer Data, and each party must delete the other's Confidential Information in its possession or control, within 60 days after receiving the request. This is a deadline to perform deletion, not a requirement that Customer request deletion within 60 days of termination. Any earlier mandatory or DPA deadline applies; routine 180/210-day mail retention does not extend it. Section 12.4(c)'s permitted retention remains subject to security, confidentiality, this DPA and mandatory law, not an indefinite exception.

The release candidate provides currently authorized Jira-admin JSON return with project checks, selected/visible-audit deletion and current-settings deletion. Deletion requires a pause and confirmation; resume writes OFF and does not replay old issues. A separate workflow requires global Jira administration permission and a short-lived signed grant bound to the installation, scope, operation, instruction and verified recipient. It freezes managed writers, traverses the known managed catalog, acknowledges returned pages and processes deletion in bounded steps. Unacknowledged pages, interrupted responses and unresolved Jira dispatches do not justify a false completion claim or blind resend. This does not enumerate unknown legacy records, logs, Jira data or supplier backups. Missing installation provenance is rejected; legacy installations need a verified additional path. License expiry does not delete data or authorize processing: paid save/preview/events stop, while independently authorized data-rights routes are not paid-license gated. Site or platform access loss may prevent those routes.

Actual removal through an authorized customer's official uninstall action starts Forge's hosted-storage retention lifecycle: Atlassian describes 28 days of retention after uninstall and an authorized recovery request within 21 days with customer consent. Cancellation or pending removal is not evidence that this clock started. Uninstall is installation-wide, provides no prior return, does not erase Jira itself and cannot meet every selective or shorter deadline. Current managed records use application expiry and transactional cleanup rather than independent platform TTL on indexed bodies/pages. Audit has a 90-day logical retention; expiry and cleanup are not instant physical erasure. Settings have no automatic expiry. Active return holds and unresolved dispatch state need explicit handling. A return hold has a seven-day instruction-review point that is not silently reset by grant renewal. No unverified Atlassian intervention or expedited-deletion service is promised.

A verified fulfilment path for the actual installation, applicable customer records, recipient and deadlines is required before real instructed processing, including evaluation. The source implementation and local tests do not establish deployed availability or full customer fulfilment. Production deployment/live-behavior, authorized issuer operation, legacy data, logs/backups and supplier assistance remain release gates where applicable. Stopping new intake or obtaining Customer consent does not discharge obligations for existing data. Provider remains responsible for minimizing further processing and promptly securing a lawful, validated method; rights are not waived by a missing feature.

Routine independent correspondence uses actual closure plus 180 days, housekeeping every 30 days and deletion by 210 days. It does not postpone a DPA, legal or termination deadline. Necessary legal/dispute/security exceptions require a recorded basis, restricted use and deletion when no longer needed.

Provider-controlled mail and working copies are handled separately from supplier backups. Purelymail's current privacy notice allows backups for up to 30 days after account closure. Separately, its Security documentation states that deleted email-message backups, including original undelivered messages, are kept for one month. This published schedule is not individual proof of actual purge, a guarantee about every copy, or a processor/transfer agreement. Forge controls its hosted retention. Lawfully retained backups or legal records remain protected, restricted from ordinary reuse and subject to the applicable schedule. Provider will confirm completed actions and specifically justified remaining copies without claiming instant physical erasure.

8. International processing

Provider operates in Japan. Forge locations depend on the relevant hosting/residency arrangement, not every region. Cloudflare's website network is global; Purelymail's published server location is Northern Virginia, USA. These facts alone do not establish a lawful basis for every transfer.

Before a restricted transfer, establish the relevant destinations, roles, lawful mechanism, necessary assessments and supplementary safeguards. DPA incorporation into standard service terms can be effective without a separately signed paper annex. Forge and Cloudflare have such contractual routes and conditional transfer provisions, but these do not supply every Customer-to-Provider or Provider-to-Purelymail arrangement. The applicable agreement and its coverage must be established; publication of a DPA alone is not proof of acceptance. No SCC module, certification or adequacy conclusion is fabricated.

If a required transfer instrument applies, complete it through the authorized legal process before transfer. If no lawful mechanism exists, affected new processing must not begin and existing affected processing must be contained lawfully, with existing-data obligations preserved. Binding clauses, data-subject rights and competent supervisory/court powers prevail over Japan-forum and liability terms.

9. Duration and responsibility

This DPA follows the Product Agreement and continues for retained protected data, including after paid or free evaluation ends. Contractual liability follows the Provider-Specific Terms subject to mandatory rights and binding transfer remedies. Amendments follow the Agreement; operational updates cannot retroactively dilute duties. Publication, price caps or suspension of new processing do not excuse unfulfilled duties for data already processed.

Recovery and retention limits

The pre-release implementation separates renewed authorization for a customer's existing instruction from the unresolved outcome of an Atlassian report. A fresh recipient-bound signed instruction does not authorize reporting retries or extend retention. Existing expiry, valid deletion duties and the review of an unacknowledged return remain independently applicable. If these obligations conflict for specific data, the appropriate authorized decision is still required; the software does not purport to resolve that legal conflict. No new waiver, retention period or all-copy erasure guarantee is added by the local recovery implementation.

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.