Johannesburg, 10 Sept 2026
When a financial institution moves Jira, Confluence, or Jira Service Management into the cloud, part of the operational burden shifts to the provider. Atlassian runs the platform and maintains the underlying infrastructure, while the customer gains the service capabilities that come with SaaS.
What does not move is the institution’s regulatory accountability. That is important to remain cognisant of since Joint Standard 1 of 2023 on IT Governance and Risk Management came into effect on 15 November 2024.
The Standard places ultimate responsibility for compliance with the governing body. It requires institutions to define and implement backup and restoration procedures, align backups with business recovery requirements and system criticality, and regularly test restoration procedures.
For organisations that depend heavily on Atlassian Cloud, their compliance position depends on whether their platform operations meet the recovery and control requirements set by their own risk environment.
Uptime is not recoverability
Cloud resilience is often discussed in terms of availability. If the service stays online and the provider has disaster recovery processes behind it, the environment can appear well covered. That still does not establish whether the institution can recover its own information when something goes wrong. Its recovery capability has to match the recovery point and timeframe the business requires.
Atlassian provides native backup and export capabilities, but they have defined scope and limitations. Jira Cloud exports, for example, do not automatically include automation flows or some Jira Service Management data. Atlassian also distinguishes between the backups it maintains for application recovery and the exports customers can use for their own recovery.
A regulated institution can still use Atlassian Cloud appropriately. The responsibility is to determine whether the available recovery mechanisms meet the recovery point and recovery time objectives set for the processes that rely on the platform.
Atlassian products can also be integrated into operational processes. A service management environment may support incident response, while Confluence may hold documentation used during regulated activities. When Atlassian supports regulated operations, availability is only part of the requirement. The information and workflows inside the platform must also remain recoverable and appropriately controlled.
Configuration is part of the control environment
SaaS has also changed what an IT change looks like. An administrator can alter a Jira workflow, adjust a permission scheme, modify an automation rule, or change a custom field without touching traditional application code. The technical action may be simple, but its effect on a controlled business process may not be.
Joint Standard 1 requires that changes to IT systems be recorded, tested, assessed, approved, implemented, and verified in a controlled manner. It also calls for appropriate segregation between development, testing and operations environments where applicable.
Atlassian has capabilities that can support this work. Audit logs record administrative activity, with the depth of information depending on the subscription. Premium and Enterprise plans provide sandboxes, and Atlassian currently offers a beta feature to deploy supported configuration changes from a sandbox to production.
Those features can form part of a control framework, but they do not automatically create one. The institution still needs to decide which changes require formal control, who is authorised to make them, how approval is evidenced and how a failed change will be handled.
This is where older governance habits can fall short. Code changes usually receive formal governance because organisations recognise them as changes to a system. SaaS configuration is still sometimes treated as routine administration, even when it determines how permissions or workflows operate inside a critical process.
The effect of the change determines the risk, irrespective of whether somebody wrote code to make it happen.
Audit readiness has to be designed in
The test is whether an institution can demonstrate the controls it claims to have. Recovery requirements for the Atlassian environment need to be defined, the backup approach aligned with those requirements, and restoration tested against them. Significant configuration changes should also be traceable through testing and approval, with a clear recovery path if a change causes a problem.
That requires technology and governance to work together. The organisation needs a clear view of what the cloud platform provides, where its own controls begin, and whether the two collectively support the risk requirements it has set.
A cloud provider can operate a resilient service and continue expanding the tools customers can use to govern it. The financial institution still has to understand the business processes that depend on the service and build controls around that dependency.
Joint Standard 1 makes the accountability clear. The governing body remains ultimately responsible for compliance regardless of where the technology runs. A compliance gap appears when an organisation assumes that controls supplied by a cloud platform automatically satisfy the controls required by its own risk environment.
For financial institutions using Atlassian Cloud, that assumption is worth testing before an audit forces the issue.
Share