Business Continuity Plan

1. Purpose and scope

We understand that reliable and continuous service is essential for our customers. This Business Continuity Plan (BCP) describes how Purde Software keeps its apps available, maintainable, and recoverable in the face of unexpected disruptions, and what customers can expect if we are unable to operate the business ourselves.

It covers:

• our apps for Confluence Data Center (installed and operated by the customer);

• our apps for Confluence Cloud (operated by us on AWS, Heroku, and — increasingly — Atlassian Forge);

• our customer-facing services (service desk, email support, public issue trackers).

This BCP supplements the Cybersecurity Policy, the Privacy Policy, and the Service Level Agreement.

2. Proportionality

Purde Software is a two-person, part-time business. The arrangements below are proportionate to that scale and are designed to make the business resilient through simplicity, redundancy of people and source code, and customer self-sufficiency, rather than through complex internal infrastructure.

3. Roles and responsibilities

Both individuals are self-employed professionals with full operational and technical knowledge of the product portfolio and infrastructure.

4. Recovery objectives

The following objectives apply under normal conditions, assuming upstream platforms (Atlassian, AWS, Heroku, Forge runtime, network providers) are themselves available:

These objectives are best-effort targets, not service credits, and do not override availability statements in the SLA. Incidents within upstream platforms are excluded.

5. Threat scenarios and response

We plan for the following realistic disruption scenarios:

6. Key-person and bus-factor handling

We mitigate single-person risk through three structural measures:

1. Two independent operators. Both individuals can operate and maintain the business independently. Either can run the full release-and-support cycle.

2. Offline emergency access kit. A sealed, encrypted backup of master credentials and recovery information is held offline by the Owner; a second copy is held by the second contributor. The kit is refreshed at least annually and after any material credential change.

If the Owner is unavailable for more than 7 days, the second contributor assumes operational responsibility and notifies active enterprise customers. If both contributors are unavailable for more than 30 days, customers are notified and §7 applies.

7. Long-term continuity for customers

If Purde Software is permanently unable to maintain its apps (for example, due to discontinuation of the business), the following arrangements ensure customers can continue to operate:

7.1 Open-source apps

A significant number of our apps are open source. Customers can:

• review the source code freely;

• operate the software independently;

• maintain and extend the apps within their own environments.

7.2 Proprietary apps

For apps that are not open source, we are committed to:

• Source-code access on request. Active customers may request access to the source code of the version they are using, under a confidentiality and limited-use agreement, to enable continued operation in their own environment.

• Source-code escrow. Available on request and subject to mutual agreement.

7.3 Customer transition support

In the event of business discontinuation, we will:

• give active paying customers at least 90 days' notice before ceasing development and support;

• publish a final release containing critical security and compatibility fixes where feasible;

• transfer or surrender the Atlassian Marketplace listings in coordination with Atlassian.

8. Backups and source-code redundancy

• Source code: Bitbucket Cloud is the primary repository. A local copy is always available.

• Customer support data: held in Atlassian Service Desk; resilience is provided by Atlassian.

• Customer Data in Cloud apps: minimal (installation metadata and operational logs); see Privacy Policy. Recovery is by re-deployment and customer re-installation, not from a customer-data backup.

• Build and release artifacts: rebuildable from source at any tagged commit.

• Restore tests: performed at least annually as part of the BCP review (see §11).

9. Activation, communication, and stand-down

9.1 Activation criteria

This BCP is activated by the Owner (or, in the Owner's absence, the second contributor) when any of the following occurs:

• a confirmed loss of a production cloud environment;

• a confirmed compromise affecting customer data or credentials;

• the unavailability of a contributor for more than 7 days where the other contributor cannot maintain normal service alone;

• any event whose expected impact exceeds the relevant RTO in §4.

9.2 Customer communication

During an activated event, we communicate with affected customers through:

• the Atlassian-hosted service desk as the primary channel;

• email to active administrators using the licence data provided by the Atlassian Marketplace, where appropriate;

• a status update on the Confluence space linked from the Marketplace listing, where appropriate.

We aim for a first communication within 6 hours of activation during business hours, and within 1 business day otherwise. Subsequent updates follow the SLA reaction times for the corresponding severity.

9.3 Stand-down

A stand-down is declared by the Owner once normal operations resume. A short post-incident note is recorded (event, root cause, response, corrective actions) and folded into the next BCP review.

10. Dependencies on suppliers

Continuity of our Cloud apps depends on the continued availability of Atlassian, AWS, Heroku, and (for migrated apps) Atlassian Forge. We rely on the resilience and disaster-recovery commitments of these providers and do not duplicate their controls. Their public commitments are referenced in the Privacy Policy §8 (Subprocessors) and the Cybersecurity Policy §6.

11. Testing, review, and maintenance

• Desktop walkthrough of this BCP: at least once per year, conducted by both contributors. The walkthrough covers a selection of scenarios from §5 and verifies that credentials, recovery instructions, and contact details are current.

• Restore test of a representative source-code repository and of the cloud-app deployment process: at least once per year.

• Review of this plan: at least annually and after any material change to our products, infrastructure, suppliers, or contributor team.

• Results of walkthroughs and tests are recorded internally alongside the audit results referenced in Cybersecurity Policy §15.

12. Related documents

• Cybersecurity Policy

• Privacy Policy

• Service Level Agreement

• End User License Agreement (EULA)

• Code of Conduct

13. Version history