Part I
Data Processing Agreement
This Data Processing Agreement ("DPA") forms part of the agreement between Macon Apps ("Vendor", "Processor") and the customer installing the Rule Vault application ("Customer", "Controller") governing Customer's use of Rule Vault (the "App"), an application for Atlassian Jira Cloud distributed through the Atlassian Marketplace. It applies to the extent the Vendor processes Personal Data on behalf of the Customer in providing the App.
1. Definitions
"Personal Data", "processing", "controller", "processor", "data subject", and "supervisory authority" have the meanings given in the EU General Data Protection Regulation (GDPR). "Personal Information", "business", "service provider", "sell", and "share" have the meanings given in the California Consumer Privacy Act as amended (CCPA/CPRA).
2. Roles
For Personal Data processed by the App, the Customer is the controller (or a processor acting for another controller) and the Vendor is a processor. For customers subject to the CCPA, the Vendor acts as a service provider. The Vendor is independently a controller of data it collects for its own business operations (e.g., support tickets and billing information), which is governed by the Vendor's Privacy Policy, not this DPA.
3. Subject Matter and Details of Processing
| Subject matter | Backup, version history, change detection, alerting, and restoration of Jira automation rule configurations on the Customer's Atlassian site |
|---|---|
| Duration | The term of the App subscription, until uninstallation (see Clause 10) |
| Nature & purpose | Automated periodic and on-demand capture of automation rule configurations; computation of change diffs; creation of alert issues; restoration of configurations on Customer instruction |
| Categories of data | Atlassian account IDs of rule authors/actors/collaborators; names and email addresses embedded in rule configurations (e.g., notification recipients); administrator service-account email and API token (encrypted); rule names and change summaries which may incidentally contain personal data entered by Customer users |
| Data subjects | Customer's employees, contractors, and other users of the Customer's Atlassian site whose identifiers appear in automation rule configurations |
| Special categories | None intended or required. The Customer is responsible for not embedding special-category data in automation rule configurations. |
4. Processor Obligations
The Vendor will:
- Process Personal Data only to provide the App and only on the Customer's documented instructions (given via installation, configuration, and use of the App), unless required otherwise by law, in which case the Vendor will inform the Customer unless legally prohibited.
- Ensure persons authorized to process Personal Data are bound by confidentiality obligations.
- Implement and maintain the technical and organizational measures described in Part II (Written Security Policy).
- Assist the Customer, insofar as reasonably possible, in responding to data-subject requests (access, rectification, erasure, restriction, portability, objection) and in meeting the Customer's obligations under GDPR Articles 32–36.
- Make available information reasonably necessary to demonstrate compliance with this DPA, and allow for audits limited to (a) the Atlassian Marketplace Privacy & Security listing disclosures, (b) this DPA and Part II, and (c) written responses to reasonable security questionnaires no more than once annually.
5. Sub-processors
The Customer authorizes the Vendor's use of Atlassian Pty Ltd and its affiliates ("Atlassian") as sub-processor. The App runs entirely on Atlassian's Forge platform: all data is stored in Forge storage within Atlassian's cloud infrastructure, and the App's only network communication is with Atlassian's own APIs. The Vendor uses no other sub-processor. The Vendor will provide 30 days' notice (via the Marketplace listing and/or email) before adding or replacing any sub-processor, and the Customer may object on reasonable data-protection grounds by terminating the subscription.
6. International Transfers
Data residency and cross-border transfer of data stored in Forge storage are governed by Atlassian's cloud hosting infrastructure and Atlassian's own data-transfer mechanisms (including standard contractual clauses in Atlassian's customer agreements). The Vendor does not itself export Personal Data outside the Atlassian platform.
7. Security Incidents
The Vendor will notify the Customer without undue delay, and in any event within 72 hours of becoming aware, of a personal data breach affecting the Customer's Personal Data processed by the App, providing information reasonably available about the nature, scope, and remediation of the breach, and will cooperate with the Customer's reasonable requests in connection with the breach.
8. CCPA Service Provider Terms
To the extent the Vendor processes Personal Information subject to the CCPA on the Customer's behalf, the Vendor: (a) acts as a service provider; (b) will not sell or share Personal Information; (c) will not retain, use, or disclose Personal Information for any purpose other than providing the App or as otherwise permitted by the CCPA; (d) will not combine Personal Information received from the Customer with information from other sources except as permitted by the CCPA; and (e) certifies that it understands and will comply with these restrictions. The Vendor will notify the Customer if it determines it can no longer meet its CCPA obligations.
9. Data Subject Requests
Given the App's architecture, the Customer can satisfy most data-subject requests directly: deleting or editing the underlying automation rule and allowing subsequent snapshots to reflect the change, or uninstalling the App. On written request, the Vendor will assist with deletion of specific stored snapshot versions where technically feasible.
10. Deletion and Return
Upon uninstallation of the App, all App data — snapshots, version history, activity logs, settings, and stored credentials — is automatically and permanently deleted by the Forge platform. The Customer is responsible for exporting any records (e.g., CSV activity exports) required for its own retention purposes before uninstalling. No separate return procedure exists because all underlying source data (the automation rules themselves) remains in the Customer's Jira site at all times.
11. Liability and Order of Precedence
The liability of each party under this DPA is subject to the limitations of liability in the governing agreement (the Atlassian Marketplace Terms of Use or the Vendor's EULA, as applicable). In case of conflict between this DPA and that agreement regarding processing of Personal Data, this DPA prevails.
Part II
Written Security Policy
This policy describes the technical and organizational measures protecting Customer data processed by Rule Vault. It is reviewed at least annually and after any material architectural change.
1. Architecture and Data Flow
- Rule Vault is built entirely on Atlassian Forge and runs exclusively within Atlassian's cloud infrastructure. There are no Vendor-operated servers, databases, or third-party services.
- The App's only network egress is to Atlassian's own API endpoint (api.atlassian.com), used to read and restore the Customer's automation rules. No Customer data is transmitted to any non-Atlassian destination.
- All processing (snapshots, diffs, alerts, restores) executes in Forge functions inside Atlassian's sandboxed runtime.
2. Data Storage and Encryption
- Snapshot data, version history, and activity logs are stored in Forge Key-Value Storage, encrypted at rest and in transit (TLS 1.2+) by the Atlassian platform.
- The administrator-provided API token is stored exclusively in Forge encrypted secret storage, is only readable by the App's backend functions, is never logged, and is never exposed to the App frontend.
- Data residency follows the Atlassian Forge platform's hosting arrangements.
3. Access Control
- The App's admin interface is available only to users with Jira administration permissions on the Customer's site, enforced by Atlassian's module-level access control.
- The Vendor has no standing access to Customer data. Forge's developer tooling does not expose stored Customer data to the Vendor in normal operation; application logs are limited to operational metadata and error diagnostics.
- Vendor accounts with publishing access to the App are protected by strong, unique credentials and two-factor authentication.
4. Credential Handling
- The App requires a Customer-created Atlassian API token because Atlassian's Automation API does not yet support Forge app-scoped authentication. The Vendor recommends a dedicated service account and documents quarterly token rotation.
- Failed authentication is surfaced to Customer administrators in the App UI (health banner) so revoked or expired tokens are visible, not silent.
5. Secure Development
- All changes pass an automated test suite (unit and integration tests covering the snapshot, diff, alerting, and restore paths) before deployment.
- Dependencies are limited to Atlassian's official Forge SDK packages and are kept current; the codebase is linted with Atlassian's forge lint tooling.
- Deployments use staged environments (development → production); production deploys occur only after functional verification on a development site.
6. Vulnerability Management and Disclosure
- Marketplace apps are subject to Atlassian's ecosystem security scanning, and the Vendor participates in Atlassian's Marketplace security programs applicable to its tier.
- Security reports may be submitted to [email protected]. The Vendor will acknowledge reports within 2 business days, and aims to remediate critical vulnerabilities within 2 weeks of confirmation, in line with Atlassian Marketplace security bug-fix expectations.
7. Incident Response
- Operational failures are detected via platform logs and in-app health monitoring.
- On discovering a security incident affecting Customer data, the Vendor will: contain the issue (including disabling the affected capability if needed), assess scope using platform logs, notify affected customers within 72 hours per Part I Clause 7, and publish remediation details.
8. Data Retention and Deletion
- Snapshot versions are retained for the life of the subscription to serve the App's purpose (historical restore).
- Uninstalling the App permanently deletes all stored data via the Forge platform's app-storage lifecycle. No copies exist outside Atlassian infrastructure.
9. Business Continuity
- Availability, redundancy, and disaster recovery of the runtime and storage are provided by the Atlassian Forge platform. The App holds no data outside that platform, so there is no separate Vendor recovery surface.
- The App is stateless apart from Forge storage; redeployment from source restores full service.
10. Sub-processors
- Atlassian (Forge platform: runtime, storage, APIs) — sole sub-processor.