Muggie van Staden | CEO | Obsidian Systems | mail me |
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.
Meanwhile, the customer gains the service capabilities that come with software as a service (SaaS). However, moving to the cloud does not eliminate the institution’s responsibility to manage technology risks and meet regulatory requirements.
What does not move is the institution’s regulatory accountability. This distinction is important, particularly 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 on the governing body. It requires institutions to define and implement backup and restoration procedures. They must also align backups with business recovery requirements and system criticality, then regularly test restoration procedures.
For organisations that depend heavily on Atlassian Cloud, compliance depends on whether their platform operations meet the recovery and control requirements of their risk environments. Therefore, moving to the cloud requires institutions to assess how their operational controls support regulatory obligations.
Uptime is not recoverability
Organisations often discuss cloud resilience in terms of availability. If the service stays online and the provider maintains disaster recovery processes, the environment may appear well protected. However, this does not establish whether the institution can recover its own information when something goes wrong. Its recovery capability must meet the recovery point and timeframe that the business requires.
Atlassian provides native backup and export capabilities, but these have defined scopes and limitations. For example, Jira Cloud exports 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. However, it must determine whether the available recovery mechanisms meet the recovery point and recovery time objectives for the processes that rely on the platform.
Atlassian products can also support 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 represents only part of the requirement. The information and workflows within 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. Although the technical action may be simple, its effect on a controlled business process may be significant.
Joint Standard 1 requires institutions to record, test, assess, approve, implement and verify changes to IT systems in a controlled manner. It also calls for appropriate segregation between development, testing and operations environments, where applicable.
Atlassian provides capabilities that can support this work. Audit logs record administrative activity, although the depth of information depends on the subscription. Premium and Enterprise plans provide sandboxes. Atlassian also currently offers a beta feature that allows users to deploy supported configuration changes from a sandbox to production.
These features can form part of a control framework, but they do not automatically establish one. The institution must still determine which changes require formal control, who can make them, how approval is evidenced, and how staff will handle a failed change.
This is where older governance practices can fall short. Organisations usually subject code changes to formal governance because they recognise them as system changes. However, some still treat SaaS configuration as routine administration, even when it determines how permissions or workflows operate within a critical process.
The effect of a change determines its risk, regardless of whether someone wrote code to implement it. Consequently, moving to the cloud requires institutions to apply governance principles to configuration changes, not just traditional software development.
Audit readiness has to be designed in
The real test is whether an institution can demonstrate the controls it claims to have. It must define recovery requirements for its Atlassian environment and align its backup approach with those requirements. It must also test restoration against them. Furthermore, significant configuration changes should remain traceable through testing and approval. The institution must establish a clear recovery path if a change causes a problem.
Achieving this requires technology and governance to work together. The organisation needs a clear view of what the cloud platform provides and where its own controls begin. It must then determine whether both sets of controls collectively support its established risk requirements.
A cloud provider can operate a resilient service while continually expanding the tools customers can use to govern it. Nevertheless, the financial institution must understand which business processes depend on the service. It must also build appropriate controls around that dependency.
In conclusion
Joint Standard 1 makes accountability clear. The governing body remains ultimately responsible for compliance, regardless of where the technology runs. A compliance gap emerges 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, testing that assumption before an audit forces the issue is essential. Ultimately, moving to cloud should involve more than transferring technology to a service provider. Institutions must also establish, test, and demonstrate the recovery and governance controls needed to support their regulatory obligations.