Data Processing Addendum

App: Outageloop (Jira Cloud, Atlassian Forge, with an external monitoring backend)
Processor: MernPearl Technology Private Limited (CIN U62099RJ2024PTC097952)
Registered office: C/O Sunil Kumar Sharma, Bar Chowk, Pilani, Jhunjhunu, Rajasthan 333031, India
Controller: the Atlassian customer installing the App
Last updated: 1 October 2026

1. Scope and roles

This Addendum supplements the Terms of Service (https://outageloop.mernpearl.com/terms) and applies where MernPearl Technology Private Limited ("Processor") processes personal data on behalf of the customer ("Controller") in connection with the Outageloop app ("the App").

The scope is narrow, and Annex A is the reason: the App persists exactly one category of personal data — an Atlassian account ID — and holds it only in Atlassian Forge hosted storage. The Outageloop backend that Processor operates holds no personal data (Annex B.2). Read Annex A before the clauses, because it determines how much of this Addendum has subject matter at all.

Atlassian is a separate processor of Controller's Jira data under Controller's own agreement with Atlassian. This Addendum does not govern that relationship.

2. Processor obligations

Processor shall:

1. process personal data only on Controller's documented instructions, which for the App consist of the Controller's configuration and use of it as described in the Terms of Service and Annex B;
2. ensure that persons authorised to process personal data are bound by confidentiality;
3. implement appropriate technical and organisational measures, as described in Annex C;
4. not engage another sub-processor except as disclosed in §3, and give Controller at least 30 days' notice of an intended addition or replacement, during which Controller may object;
5. assist Controller, so far as the narrow scope in Annex A permits, with data subject requests and with Controller's own obligations regarding security, breach notification and impact assessments;
6. delete personal data at the end of the provision of services as described in §6;
7. make available the information necessary to demonstrate compliance with this Addendum (§10).

3. Sub-processors and recipients

See Annex B for the flow-by-flow position. In summary:

No other third party receives any data from the App. There is no analytics provider, error-reporting vendor or application-performance-monitoring service.

4. Status-page operators are not processors

Processor's backend polls third-party status pages with an unauthenticated GET request carrying no request body, no credential, no Atlassian site or tenant identifier, no user identity and no Jira content. Each service is polled once for all customers. The operator learns only that a request arrived from the backend server's IP address.

Because no personal data and no Controller data of any kind is transmitted, status-page operators are not processors or sub-processors of Controller's data. They are listed for transparency only.

5. Slack

Slack receives data only if a Controller site administrator connects a Slack workspace, using a bot token the Controller itself creates and supplies, to post into channels the Controller nominates.

Processor characterises this as a customer-initiated integration rather than a Processor-appointed sub-processor: the Controller chooses the destination, supplies the credential and can disconnect it at any time. Controller's use of Slack is governed by Controller's own agreement with Slack. In either characterisation, the Slack payload contains no personal data (Annex B.2(e)).

6. Deletion and return of data

Forge hosted storage, which holds the account ID in Annex A, is cleared automatically by the Atlassian platform on uninstall: soft-deleted immediately, retained for a platform-managed window during which a reinstall can relink it, then permanently deleted under Atlassian's own retention policy. Atlassian does not publish a fixed number of days; see https://developer.atlassian.com/platform/forge/storage-reference/hosted-storage-data-lifecycle/

The Outageloop backend is instructed by the App's uninstall handler to delete the installation. That deletes the installation record, callback secret, catalog selections and queued messages from the database and cache immediately. If the instruction fails, the backend deletes any installation it has not heard from in 90 days. Nightly database backups are kept for 14 days, so deleted backend records persist in backups for up to 15 days. None of these records is personal data.

Granular erasure before uninstall is also available: deleting a project-dependency mapping removes its addedBy account ID.

7. Data subject rights

Processor will assist Controller with any request it receives directly, and will refer requests about Controller's Jira data generally to Controller or to Atlassian as appropriate.

8. Security incidents

Processor shall notify Controller without undue delay, and in any event within 72 hours, after becoming aware of a personal data breach affecting personal data processed under this Addendum, and provide the information reasonably available to it.

For transparency: the only personal data in scope is held in Forge hosted storage, so most breach scenarios affecting it would be detected and notified by Atlassian under Controller's agreement with Atlassian. Processor's own detection covers the App's code and the backend it operates (Annex B.2).

9. International transfers

The personal data in Annex A stays in Forge hosted storage, where Atlassian hosts it under Controller's agreement with Atlassian, and is not transferred to Processor's backend.

The Outageloop backend is located in India (Oracle Cloud, Mumbai). It holds no personal data. To the extent that any data transferred to it, or any access by Processor's personnel in India, involves personal data originating in the EEA, Switzerland or the United Kingdom, the parties agree that the EU Standard Contractual Clauses (Module 2, controller to processor), together with the UK International Data Transfer Addendum where UK law applies, are incorporated into this Addendum by reference.

10. Audit

Processor shall make available the information necessary to demonstrate compliance with this Addendum. On Controller's written request, no more than once in any twelve-month period (or after a personal data breach), Processor will answer a reasonable written security questionnaire about the App and the backend it operates. On-site audit of the Forge platform is a matter for Atlassian. Processor does not commit to disclosing its internal security-review records or risk register.

Annex A — Personal data processed

Categories of data subject: Atlassian users of Controller's Jira site who attach a dependency to a
project (in practice, project administrators).

Categories of personal data — complete list:

That is the entire list. The App stores no names, email addresses, avatars, IP addresses, Jira issue content, issue keys, comments, attachments or free-text customer content, in Forge or on the backend.

Special categories: none. Children's data: none.

Transiently, in platform logs: an account ID may appear in Atlassian Forge application log entries — for example when the App records a denied permission check. These are Atlassian platform logs, retained and managed by Atlassian. The App exports them nowhere.

Non-personal data the App also stores in Forge: dependency records (catalog service, category, chosen regions); current status per dependency and per watched region or component; incidents and their event timeline; notification rules (project and Slack channel identifier); notification logs and outbox markers; Slack connection metadata (team ID, team name, connection timestamp); backend registration and opaque source identifiers; onboarding timestamps; and the subscription mirror (tier, limits, evaluation flag).

Non-personal data held on the Outageloop backend: see Annex B.2.

Credentials: the Slack bot token (if Controller connects Slack) and the per-installation callback
secret are held in Forge encrypted secret storage. The callback secret is also held on the backend, encrypted with AES-GCM. Neither is personal data.

Duration of processing: for the life of the installation, then per §6.

Annex B — Processing activities and where controls come from

B.0 The governing rule

Atlassian's SOC 2 / ISO 27001 control inheritance applies only to data within the Forge platform. It does not apply to the Outageloop backend, which Processor operates and is responsible for. See Forge and SOC 2 / ISO 27001.

B.1 Inherited — Forge hosted storage

All Forge-side App data, including the Annex A account ID and the credentials, resides in Forge hosted storage. For that data, the following inherit in full from Atlassian:

Processor does not hold SOC 2 or ISO 27001 certification for the App and does not claim one.

B.2 Processor's own responsibility — the backend and the outbound flows

The Outageloop backend runs on one Oracle Cloud virtual server in ap-mumbai-1 (Mumbai, India), as Docker containers: an API service, a poller, PostgreSQL, Redis and RabbitMQ. It stores:

The flows that leave the Forge platform:

(a) The backend verifies Atlassian's signed token and derives the tenant key from the installation identifier in it. It does not store or log any user identity carried by the token.

(e) Slack notifications — the only flow carrying customer-derived content. The text is composed from three values only: the display name of the monitored service (e.g. "Stripe"), the event type (opened, resolved or severity changed) and the severity (major or minor). It contains no personal data, no account IDs, no Jira issue keys, no project names and no free-text Controller content:

:red_circle: Stripe is DOWN — incident opened (Major severity).

B.3 Processor's own responsibility — cross-cutting

• Backup of the deployed app code. The App's source code, including the backend and its deployment configuration, is held in Processor's private source-control repository, from which Processor's administrators can rebuild and redeploy both the Forge app and the backend.
• Security governance — change management, access control to the vendor and hosting accounts, incident response and vulnerability disclosure. See Annex C.

Annex C — Technical and organisational measures

Stated only where true of the App as built and deployed.

Inherited from Atlassian Forge (Annex B.1), for Forge-side data: encryption at rest and in transit, tenant isolation, physical and network security, platform vulnerability management, logging and backup.

Implemented by Processor in the Forge app:

• No scopes permitting writes to Jira data. The App requests storage:app, read:permission:jira and read:jira-work. It cannot create, modify or delete any Jira content.
• Authorization on every access path. Project-scoped data is gated on the caller's Jira permissions, checked against Jira's own permissions API before any read or write.
• Egress restricted by the Forge manifest to the Outageloop backend and slack.com.
• Credential isolation. The Slack bot token and callback secret are held in Forge encrypted secret storage, never in ordinary storage, and are never logged.
• Log and telemetry redaction at both the telemetry and logging layers.
• Data minimisation. Account IDs only, never email addresses or display names; no Jira issue content.

Implemented by Processor on the Outageloop backend:

• Encryption in transit: TLS for every request to the backend; the backend's pushes to Forge are HTTPS and HMAC-signed.
• Encryption at rest: callback secrets are AES-GCM-encrypted by the application; Oracle Cloud encrypts the server's storage volumes by default.
• Tenant isolation: PostgreSQL row-level security, forced on the tables that hold installations and selections, scopes every API request to its own tenant; installations are identified only by a one-way HMAC tenant key.
• Authentication: every API request must carry a valid Atlassian-signed Forge Invocation Token for this App.
• Network exposure: only the API is reachable from the internet, through a reverse proxy that exposes a single endpoint. The database, cache and queue accept no outside connections.
• Server access: SSH with public keys only; password login and root login are disabled. Secrets are held in a root-only configuration file. Backups are root-only.
• SSRF protection and fail-safe classification on status-page polling: a blocked or failed request is recorded as unknown, never as healthy.
• Retention by design: automatic deletion of status history (90 days), delivered messages (7 days), stale installations (90 days) and backups (14 days).

Governance and development practices:

• Mandatory code review as a merge gate on every change, and an automated CI gate (type-check, lint, format, full test suite) before merge.
• A documented security review pass, recorded per phase.
• Vulnerability disclosure: report suspected vulnerabilities to info@mernpearl.com with "Security" in the subject. Processor acknowledges reports within 5 business days and asks for coordinated disclosure.
• Access control to vendor and hosting accounts: access to the Atlassian developer and Marketplace vendor accounts, the Oracle Cloud account and the production server is limited to the MernPearl staff who administer the App, and is removed when it is no longer needed.