Summary

  • Atlassian's April 2022 Cloud outage affected a small subset of customers, but the event carried a large accountability lesson because the affected entity was the customer site itself, not only a shared service component.
  • Who had practical control over maintenance tooling, tenant deletion safeguards, backup restore order, customer-specific recovery estimates, status-page language, and proof that SaaS restoration recovered business context rather than only service availability?
  • The accountability issue is that collaboration and workflow SaaS platforms hold operational memory, so customer-specific restoration evidence matters more than a generic service-up statement.
  • Software teams, IT departments, project managers, small businesses, enterprise customers, auditors, and SaaS buyers needed evidence that tenant restoration, customer notice, and backup design were controlled as continuity obligations.
  • This article treats Atlassian statements as evidence of what Atlassian publicly reported, status and trust pages as operating commitments and vocabulary, contract material as customer-facing allocation of duties, and standards material as control benchmarks rather than as retroactive findings.

Why this case belongs in a risk and accountability file

Atlassian made cloud-site restoration a tenant-continuity accountability test because the public trigger exposed a difference that cloud buyers often blur. A SaaS platform can be available in a general sense while a particular tenant is absent, incomplete, or still waiting for a validated restore. That difference matters for Jira Software boards, Jira Service Management queues, Confluence spaces, incident records, release histories, approval trails, procurement notes, customer requests, and internal engineering memory. In those environments, the customer site is not just a container.

It is where work is described, prioritized, approved, audited, escalated, and remembered.

The public Atlassian engineering update at https://www.atlassian.com/blog/atlassian-engineering/april-2022-outage-update described a failure pattern that is unusually instructive for SaaS accountability. Atlassian said the incident affected roughly 400 customers, that a maintenance script was run with the wrong execution mode and the wrong list of customer site IDs, and that restoration required rebuilding from backups rather than simply toggling a service back on. Those public facts do not prove every internal control detail, and the article does not treat them as a private forensic file. They do show why the practical control surface included maintenance tooling, deletion safeguards, backup design, restore sequencing, and customer-specific communication.

That control surface changes the accountability frame. A traditional outage review asks whether the service is up, whether incident communications were timely, and whether the provider found the root cause. Those questions remain necessary. They are not enough when the affected unit is a tenant that contains operational history.

Customers need to know whether their specific site is restored, whether attachments and relationships are intact, whether integrations can resume safely, whether automation rules should be replayed, whether service tickets were lost or delayed, and whether audit evidence still supports decisions made before the outage. A green component status cannot answer those tenant-level questions by itself.

The central question is therefore not a rhetorical flourish. Who had practical control over maintenance tooling, tenant deletion safeguards, backup restore order, customer-specific recovery estimates, status-page language, and proof that SaaS restoration recovered business context rather than only service availability? The answer should separate provider-side control from customer-side continuity duties. Atlassian controlled the internal maintenance tool, the target list, the deletion path, the backup restore mechanics, and the language used to describe restoration.

Customers controlled some exports, local process workarounds, vendor-risk escalation, and downstream reconciliation. But customers could not restore Atlassian's cloud tenant from Atlassian's internal backup system. That asymmetry is the accountability issue.

A tenant is an operating record, not a generic service component

The word "site" can sound administrative. In SaaS continuity, it is far more consequential. A cloud site can hold the issue graph that defines a product release, the service desk queue that defines customer promises, the Confluence space that defines process memory, the approval chain that supports audit, and the integration state that tells other tools what happened. Losing ordinary access to that site disrupts the work itself and also disrupts the evidence by which work is coordinated. Restoration therefore has to recover more than availability. It has to recover context.

The accountability problem is visible in the distinction between platform health and tenant health. The public status page at https://status.atlassian.com/ can tell customers whether Atlassian is reporting active incidents or component problems. That is essential common evidence. But a status page is shared by many audiences. It cannot, by design, prove that a specific customer's Jira issue links, Confluence pages, attachments, permissions, automation rules, marketplace app states, and integration histories have returned to a trustworthy state. A tenant restore requires a lower-level proof file.

Customers also experience a tenant outage differently depending on their role. A small software team may lose its sprint board and release notes. A support team may lose visibility into open customer tickets. A regulated enterprise may lose the ability to show change approvals or incident-management history. A procurement team may face internal questions about why the selected SaaS provider could not provide a site-specific recovery estimate quickly. The same provider incident therefore creates different accountability duties for engineering, legal, compliance, customer support, and executive leadership.

This is why generic "service restored" wording can be accurate and still limited public evidence. If the site contains business memory, restoration must include a reconciliation layer. Customers need to know which time window was affected, whether any data was unrecoverable, whether operations performed during workaround periods must be reentered, whether connected tools should be resynchronized, and whether audit narratives should disclose the provider outage. The provider may not be able to answer every customer-specific business question, but it controls the evidence that makes those questions answerable.

Integrations make a site restore a cross-system event

The tenant boundary is also wider than the product UI. A Jira or Confluence site often connects to identity providers, marketplace apps, chat tools, incident-management tools, source-code platforms, customer-support systems, business-intelligence exports, and automation rules. A restored tenant can therefore be technically available while its connected operating environment is still in an uncertain state. The missing evidence is not only whether Atlassian restored the data. It is whether the customer can determine which external systems consumed stale, absent, duplicated, or delayed state during the outage window.

That integration layer changes the meaning of recovery sequencing. If an issue tracker feeds a deployment workflow, a missing ticket can delay a release or conceal an approval gap. If a service desk queue feeds a customer communication workflow, delayed restoration can change what customers were told and when. If Confluence pages are the source of operational procedure, a team may work from a cached copy, a local export, or memory while the authoritative record is unavailable.

After the site returns, the organization has to decide which temporary record is authoritative and whether any work performed during the outage must be copied back into the platform.

This is where the provider-customer split becomes especially visible. Atlassian can restore the tenant and provide product-level validation evidence. It cannot know every downstream system that a customer connected, every automation that failed, or every manual workaround that substituted for the site. Customers need their own dependency map. But the customer dependency map relies on provider evidence for the affected window, restore stage, known exceptions, and product surfaces involved. Without that evidence, the customer cannot distinguish a local integration problem from a provider restore consequence.

Marketplace apps add another accountability layer. A customer may depend on app-specific fields, automation, permissions, reports, or integration state that live beside core product data. A tenant restore that is complete for core product tables may still require customer or app-vendor validation before business processes are fully trustworthy. That does not mean Atlassian is responsible for every third-party app behavior. It means the public recovery language should avoid implying that site access alone proves the entire collaboration environment has returned to its pre-incident state.

For auditors and boards, the key question is whether integration reconciliation was planned before the outage. A mature SaaS continuity file would include a register of critical integrations, the business process each integration supports, the owner who can validate it, and the evidence needed to close it after provider restoration. The register does not have to be elaborate. It does have to exist before people are reconstructing days of work from chat messages, local notes, or screenshots.

The script failure shows why deletion controls need a different standard

Atlassian's public account made the maintenance-script problem central to the incident. In simple terms, a tool intended to delete legacy app data was executed with a mode and ID list that caused broader site deletion for a limited customer set. The important accountability point is not that a script failed. Every complex provider uses administrative tooling. The point is that destructive tooling inside a SaaS provider must be treated as a continuity risk, not only as an engineering convenience.

For destructive tooling, ordinary access control is only the first layer. The stronger control file asks whether the tool had dry-run behavior, blast-radius limits, dual authorization, customer-site allow lists, validation against expected entity types, stop conditions, irreversible-action warnings, rate limits, and independent monitoring. It asks whether the tool could delete a whole tenant when the intended target was an app data entity. It asks whether the operator could see, before execution, the difference between the entity population expected and the entity population actually selected.

Those are governance questions expressed as engineering controls.

The April 2022 event also shows why "rare" is not the same as "low impact." A subset of customers can still represent severe business disruption for each affected organization. SaaS accountability should not depend only on percentage impact across the entire provider base. It should also evaluate severity at the customer tenant. If a provider serves hundreds of thousands of tenants and only a few hundred are affected, the aggregate availability percentage can look tolerable while the affected customers face days of operational impairment. Continuity governance has to measure both.

The same point applies to operational sign-off. A deletion script can be correct in most prior runs and still need a protection model that assumes a future wrong target set, wrong flag, wrong environment, or wrong operator assumption. The correct question is not whether the maintenance task was legitimate. It is whether a legitimate task could pass through enough independent checks before it touched production tenant state. In a SaaS platform, internal maintenance convenience should never outrank tenant recoverability.

Customer-specific estimates are part of the control record

Communication is often reviewed as a public-relations function. In a tenant-level outage, it is part of the operational control record. A customer deciding whether to keep support teams in a manual workaround, pause a release, notify its own users, preserve alternative notes, or escalate to a regulator needs a time estimate that is specific enough to guide action. A global update that says work is continuing can be truthful and still not support a customer's next decision.

Atlassian's post-incident review at https://www.atlassian.com/blog/atlassian-engineering/post-incident-review-april-2022-outage matters because it moved beyond a short status note and described corrective themes. For accountability purposes, the value of a post-incident review is not that it sounds contrite. It is that it should narrow uncertainty. It should connect the trigger, the affected entity, the customer impact, the restoration method, the preventive controls, and the follow-up owner. When a review does not make those links, customers are left to infer whether the provider has repaired the actual failure mode or only improved messaging around it.

Customer-specific estimates are difficult because they require operational truth under stress. A restore queue may depend on backup size, product mix, data relationships, marketplace apps, validation checks, manual review, and engineering bottlenecks. Publishing a precise estimate too early can mislead customers if the assumptions change. Publishing only broad language can leave customers unable to plan. The accountability answer is to disclose the basis of the estimate: what is known, what is still being tested, what could change the date, and when the next update will be meaningful.

That disclosure should also distinguish recovery stages. A site can be identified as affected, queued for restore, restored to an internal environment, validated by provider checks, exposed to the customer, monitored after reactivation, and closed after customer confirmation. Each stage carries a different operational meaning. A single "restoring" label is too coarse for customers who need to decide whether to resume work. Better status language would map the stage, the evidence, and the remaining customer action.

Restore order is a governance decision

Restoration order is sometimes described as an engineering queue, but it is also a governance decision. If every affected tenant cannot be restored at once, the provider must choose a sequence. That sequence may depend on backup size, product complexity, technical dependencies, validation confidence, support escalation, contractual commitments, regulated use, or customer criticality. Each factor can be defensible. The accountability risk appears when the factors are invisible and customers cannot tell whether they are waiting because of technical necessity, operational triage, or support escalation noise.

An accountable restore order does not require publishing a public ranking of customers. It does require an internal rule set that can survive later review. The provider should be able to explain whether it restored the simplest tenants first to prove the process, prioritized the most complex tenants because they carried greater risk, batched similar product configurations, or escalated customers with known public-service or regulated continuity duties. The rule matters because it determines who bears outage time while the provider is still repairing the failure.

Customers need a version of that reasoning translated into action. If a customer is late in the queue because its site has unusual product complexity, it can plan differently from a customer that is waiting because backup validation has not yet completed. If a customer is told only that restoration is continuing, it may overcommit to its own stakeholders. If the customer knows the restore is technically complete but post-restore validation is pending, it can prepare internal validation teams. The same estimated date can mean different things depending on the stage and reason behind it.

Restore order also affects evidence preservation. A team that waits several days may accumulate more manual records, more duplicate work, more customer communications, and more integration drift than a team restored early. That later customer needs stronger reconciliation guidance. A provider that treats every restored tenant as equivalent misses the cumulative burden of time. The accountability record should therefore distinguish elapsed outage time, restore stage, known exceptions, and customer reconciliation burden.

For boards, this is the uncomfortable part of SaaS concentration. When many organizations depend on one provider's internal restore queue, the provider becomes a temporary allocator of business continuity. That allocation may be necessary and technically rational. It should not be invisible. A post-incident review should state how restore sequencing was governed, what metrics were used, and what changed so the next restore queue is shorter, better evidenced, and easier for customers to interpret.

Backup evidence matters only if it is separable from the failure

Backups are often advertised as resilience, but the April 2022 event shows that the accountable question is not merely whether backups exist. It is whether backups are independent enough, complete enough, and testable enough to recover a tenant when the provider-side control plane is the source of the failure. A backup that is stored, authorized, deleted, or restored through the same flawed path as the production tenant may not create real separation. A backup that exists but cannot be restored quickly enough for a business-critical tenant may still fail the continuity expectation customers thought they had purchased.

Atlassian's trust and resilience material at https://www.atlassian.com/trust/resilience provides useful vocabulary for how the company presents reliability, resilience, and operational practices. The article uses that material as present control context, not as proof that every control behaved in a particular way in April 2022. The same boundary applies to https://www.atlassian.com/trust/security/data-management, which helps readers understand how Atlassian describes data management and protection responsibilities. Public trust pages are valuable because they tell customers what the provider considers part of its assurance model. They do not replace incident-specific evidence.

An accountable backup record for this kind of event would answer at least six questions. Which backup set was used for each affected tenant? What recovery point did it represent? What restore order was applied? What validation showed that product data, permissions, attachments, and relationships were intact? What data, if any, could not be recovered? What customer action was required after restoration? Those questions are not academic. They decide whether a customer can trust the restored tenant as the authoritative record.

The strongest evidence would also show restore rehearsal. A provider that has tested tenant-level restore under realistic scale can communicate differently from one discovering dependencies during the incident. Rehearsal does not eliminate surprises, but it changes the proof file. It lets the provider publish expected stages, common exceptions, validation gates, and escalation paths without inventing them under pressure. For a SaaS platform that holds operational memory, restore rehearsal is a customer-facing continuity obligation even when the rehearsal itself is internal.

Legal allocation cannot substitute for operational clarity

Contracts and service levels matter, but they are not the whole accountability record. Atlassian's customer agreement at https://www.atlassian.com/legal/atlassian-customer-agreement and service-level material at https://www.atlassian.com/legal/sla help define the legal and commercial terms under which customers use cloud products. Those documents are relevant because procurement and legal teams need to understand remedies, commitments, and exclusions. They do not by themselves tell an engineering team whether a restored site has complete attachments or whether support-ticket history can be trusted.

This distinction is important because cloud buyers can confuse contractual allocation with operational readiness. A contract may allocate risk, limit liability, or define credits. A continuity plan still has to keep the business running. If the provider controls the only practical restoration path, the customer needs evidence that the provider's restoration design is operationally credible. If the customer has duties to export data or maintain local contingency records, the provider still needs to describe what exports can and cannot do when the tenant itself becomes unavailable.

The public source at https://support.atlassian.com/security-and-access-policies/docs/understand-data-residency/ is useful for a separate but related reason. It shows how cloud customers often think in terms of where data is hosted, which can be important for compliance and governance. But locality is not the same as recoverability. A tenant can be located in the expected region and still be unavailable. A backup can respect residency promises and still need independent restore controls. SaaS risk governance should therefore avoid treating data residency, contractual SLA, and tenant continuity as interchangeable ideas.

The same distinction applies to cloud migration and enterprise adoption. Atlassian's cloud enterprise material at https://www.atlassian.com/enterprise/cloud reflects the provider's broader case for moving organizational work into cloud products. The stronger that case becomes, the stronger the continuity burden becomes. When a platform becomes the place where everyday work happens, the provider's restoration evidence becomes part of the customer's own risk file. Procurement should ask for that evidence before the next incident, not after a customer site has vanished from normal access.

The customer side still has continuity duties

Provider accountability does not erase customer responsibility. A customer that relies on a SaaS platform for business-critical work should know which teams depend on it, which processes stop when it is unavailable, which exports or local reports are necessary, which workflows have manual fallbacks, which customers or employees must be notified, and which internal owner can accept degraded operation. The fact that Atlassian controlled the failed maintenance path does not mean every downstream continuity choice belonged to Atlassian.

The customer-side problem is that many SaaS platforms become critical slowly. A small team starts with issue tracking. Another team adds service management. A third team uses Confluence for policies. Integrations begin to create cross-tool dependencies. Automation rules route work. Audit evidence accumulates. By the time a site outage occurs, the platform is no longer a tool someone can simply ignore for a day. It is a coordination system. Customers need to inventory that dependency before a provider incident forces them to discover it under stress.

For SMEs, this is particularly hard. Smaller organizations may lack a vendor-risk office, a formal business-continuity team, or an internal Atlassian administrator with time to maintain exports and incident playbooks. Yet they may depend heavily on Jira or Confluence because cloud SaaS is how small teams avoid running their own infrastructure. That economic logic is rational. It also means that the provider's communication and restore evidence must be understandable to organizations that do not have dedicated resilience staff. SME continuity is not a lesser duty because the customer is smaller.

For enterprises, the issue is different. Large customers may have continuity programs, but they can also have more complex tenants, more integrations, more regulated records, and more internal stakeholders. A restore that works technically may still require enterprise reconciliation across identity providers, support portals, deployment workflows, legal holds, and audit reports. The provider's proof file should support that reconciliation. A customer cannot responsibly close its internal incident if it cannot map provider recovery stages to its own business processes.

Status evidence should separate common visibility from private proof

Status pages play an important role in cloud accountability. They create a common public place where customers can see whether a provider has acknowledged a problem and how it describes component health. But status pages cannot carry every private recovery detail. The design challenge is to make them precise enough to prevent false reassurance while preserving the customer-specific channel for sensitive restore information.

A useful status update for a tenant-level outage should identify the affected product family, the class of affected customers, the nature of the affected entity, the current recovery stage, the next meaningful milestone, and the channel through which affected customers will receive site-specific information. It should avoid language that implies a general platform failure when the problem is tenant-specific, and it should avoid language that implies complete restoration when only the first internal stage has been completed. Precision is not only a writing preference. It is a control.

The public Atlassian status page at https://status.atlassian.com/ is therefore best understood as one evidence lane. It can show shared incident history and provider-facing component language. The affected customer's support case, direct emails, admin console notices, and post-restore validation reports form another evidence lane. A regulator, auditor, or board reviewing the event should expect both. If only the public status record is preserved, customer-specific proof may disappear. If only private support threads exist, the public accountability record may understate the pattern.

The same logic applies to customer communications after restore. A provider should not close the incident solely because systems have been reactivated. Closure should be tied to evidence: validation completed, known exceptions listed, customer action requested, unresolved questions assigned, and future preventive controls described. That does not require a provider to disclose sensitive architecture details. It requires the provider to explain what kind of proof supports the claim that business context has returned.

Negative proof matters after a tenant returns

Restoration creates a second proof problem: customers need to know not only what was recovered, but also what did not happen. Did the provider find any unrecoverable records? Were any attachments excluded? Were any permission states rebuilt from a later source than product content? Were any automation rules disabled, replayed, or left for customers to inspect? Were any marketplace-app states outside the provider's validation boundary? These negative statements are often harder to write than positive restoration claims, but they are more useful for customer risk decisions.

The reason is simple. A customer can test what it sees. It is harder to test what might be missing. A project manager can open a board and see issues. A service manager can see a queue. An auditor can inspect some pages. None of those checks proves that every relationship, attachment, historical comment, webhook state, or permission edge is exactly as it was before the incident. The provider's validation report should therefore tell customers which completeness tests were performed and which areas remain outside provider assurance.

Negative proof also protects the provider. Without a clear boundary, every later data oddity can be attributed to the outage, even when it was caused by customer workflow, third-party integration behavior, or unrelated configuration. A provider that says precisely what was checked, what was not checked, and what customers should validate gives everyone a cleaner way to separate incident residue from ordinary operational drift. That is better than broad reassurance because it makes later disputes more factual.

For a SaaS platform that holds operational memory, the best closure language would combine restoration status, exception status, customer validation steps, and support escalation paths. It would say, in effect: here is what we restored, here is how we checked it, here is what we cannot independently validate for you, here is what you should inspect, and here is how to report a discrepancy. That is the difference between announcing that a site is back and helping a customer trust that its work record is whole.

Independent standards help frame the proof, but they do not decide the facts

General resilience and risk-management standards are useful because they give boards and customers a vocabulary that is not limited to one vendor's post-incident language. The AWS Well-Architected Reliability Pillar at https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html emphasizes design for failure, monitoring, recovery, and change management. NIST's Cybersecurity Framework at https://www.nist.gov/cyberframework gives a public structure for identifying, protecting, detecting, responding, and recovering. NIST SP 800-34 at https://csrc.nist.gov/publications/detail/sp/800-34/rev-1/final adds contingency-planning context, while NIST SP 800-53 at https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final gives a control-catalog vocabulary for availability, backup, contingency planning, audit, and change-management controls. ISO 22301 information at https://www.iso.org/standard/75106.html gives business-continuity vocabulary. The Cloud Security Alliance Cloud Controls Matrix at https://cloudsecurityalliance.org/research/cloud-controls-matrix offers cloud-control categories.

Those sources are not findings about Atlassian. They are benchmarks for evaluating whether a cloud provider and its customers asked the right questions. For this incident, the useful control families include change management, privileged administrative tooling, data backup, recovery testing, customer communication, supplier risk, incident response, and business continuity. A board review should be able to map the April 2022 facts to those control families without pretending that a framework contains the incident evidence itself.

This separation protects the public record from two common errors. The first error is to treat a trust framework as proof that the actual incident was controlled. The second is to ignore standards because the incident is vendor-specific. The better approach is to use standards as a checklist for the evidence that should exist. If the provider says restoration was completed, the framework helps ask what recovery evidence supports that statement. If the customer says business impact was contained, the framework helps ask which fallback process made that true.

The source boundary also matters for the article's tone. This is not a damages finding, a legal conclusion, or a private forensic reconstruction. It is an accountability analysis based on public material. Atlassian's own statements are the primary evidence for what Atlassian publicly reported. Public trust and legal pages explain the provider's stated commitments and vocabulary. Standards provide control benchmarks. News or commentary would be secondary context, not proof of customer-specific harm. Keeping those lanes separate is part of responsible risk writing.

What better evidence would look like next time

The next accountable evidence file for a SaaS tenant-deletion incident should begin before the incident. It should define destructive administrative actions, classify tenant-level deletion as a high-risk operation, require independent verification for target lists, enforce hard blast-radius caps, and make rollback or restore assumptions explicit. It should show that provider tooling can distinguish app data, product data, site metadata, and tenant containers before a command runs. If a tool can erase a customer site, the tool should carry the procedural weight of a continuity risk.

During an incident, the evidence file should track affected tenant identification, customer notification, restore queue stage, backup set, recovery point, validation status, known exceptions, customer-facing next steps, and communications history. Customers should be able to see where they are in the process without interpreting broad status language. Provider leadership should be able to see whether restore bottlenecks are technical, operational, communication-related, or dependent on customer validation. Auditors should later be able to reconstruct why a customer received a particular estimate on a particular day.

After restoration, the evidence file should not end with a final apology. It should include a control-change record. Which destructive scripts were changed or retired? Which approval gates were added? Which validation checks now prevent wrong target lists? Which backup restore rehearsals were added? Which customer communication rules changed? Which metrics will prove improvement over time? A post-incident review that cannot answer those questions may be honest about the past but still weak as a preventive record.

For customers, better evidence means adding SaaS tenant continuity to business-impact analysis. Which Atlassian products are critical? Which teams lose operational memory if the site is down? Which exports or reports must be retained outside the platform? Which manual process keeps support, product development, incident response, or compliance work moving for 24 hours, 72 hours, or a week? Which executive accepts the residual risk when a provider controls the only full restore path? Those questions should be answered while the platform is healthy.

Reader evidence file

The article uses the following public sources as a reading file for Atlassian Cloud 2022 outage, customer-site deletion, restoration sequencing, status communication, and SaaS tenant continuity accountability record. Each source is treated with boundaries: company statements prove what the company publicly stated, status pages and trust pages provide operating vocabulary, contract pages provide customer-facing allocation language, support pages provide current product guidance, and standards documents provide control benchmarks rather than retroactive findings.

This evidence file is deliberately wider than one outage post because SaaS tenant continuity affects more than incident chronology. The same customer may need provider facts, contractual language, support guidance, status evidence, and independent control vocabulary. The article does not claim that every source proves every operational fact. It uses the sources to define what can be responsibly known from the public record and what remains inside provider or customer evidence files.

Board review questions

A board review should ask whether destructive maintenance tooling was governed as a production-risk system or treated as an internal convenience. The answer should identify the owner of the tool, the approval model, the blast-radius limits, the validation checks, the monitoring, and the emergency stop path. If the tool can affect customer tenant state, the control standard should be closer to change-management and continuity governance than ordinary scripting practice.

The review should also ask how the provider knows a restored tenant is complete enough for customer reliance. That answer should name recovery points, backup sets, validation tests, product-specific checks, known exceptions, customer confirmation steps, and post-restore monitoring. A general statement that data was restored is not specific enough for a tenant that contains operational memory.

Customers should ask their own mirror question: which business processes depend on Atlassian Cloud, and what would the organization do if its site were unavailable for multiple days? The answer should cover support queues, product roadmaps, incident records, change approvals, policy pages, integration triggers, exports, and decision ownership. It should also state which evidence the customer expects from the provider before closing an internal incident.

The final accountability test is whether the post-incident record would let a new buyer understand the risk without relying on reassurance. The record should show what failed, why tenant restore took the path it did, which controls changed, how customer communication improved, and which evidence now proves that a similar maintenance error would be bounded. Anything less leaves the next customer to discover the same dependency only after the collaboration memory of the business goes dark.