Atlassian can be securely configured and still be poorly governed. Unclear ownership, accumulated permissions, unmanaged Marketplace apps and incomplete audit evidence can leave UK government teams carrying risks that no Jira setting will resolve.
There is no single ‘government-compliant’ Jira configuration. Atlassian can support UK government delivery and assurance requirements, but Secure by Design, access control, data governance and auditability depend on how the platform is configured, governed and operated.
The question is not whether Jira is compliant. It is whether your Atlassian estate helps your organisation meet its obligations and whether you can demonstrate that it is controlled, accountable and continuously assured.
Secure by Design. Atlassian governance for UK Government
All central government departments and arm’s-length bodies must incorporate effective security practices and meet Secure by Design policy when delivering new digital services and significant changes that fall within the digital and technology spend-control process.
Secure by Design focuses on how organisations manage cyber security throughout the service lifecycle. While activities can be tailored to individual circumstances, responsibility for meeting the core principles remains with the organisation.
That distinction matters. Jira, Confluence and Jira Service Management can help teams manage work, document decisions and produce evidence. They do not transfer responsibility for security, risk or assurance to Atlassian.
The NCSC describes cloud security as a shared responsibility. Even when using SaaS, organisations remain responsible for ensuring that a service meets their security needs, configuring it appropriately and deciding what data to place in it.
Atlassian makes the same distinction. It takes responsibility for the security, availability and performance of its applications and hosting environment. Customers remain responsible for policy, compliance, configuration and how the service is operated.
For UK government teams, Atlassian governance therefore means answering a series of practical questions; Who owns the estate? Who can change it? What data does it hold? Which third parties can access it? What evidence does it produce? How are its controls reviewed?
Throughout the estate, governance should connect requirements to controls, accountable owners and evidence that can be reviewed:
Requirement – control – owner – evidence – review
This same discipline supports the delivery of government digital services from Discovery through to Live. Across Secure by Design, the Service Standard and the Technology Code of Practice, the principle is consistent – the tooling should support the organisation’s delivery and governance requirements, not substitute for them.
Good governance should also make delivery easier. Clear ownership, controlled access and predictable configuration reduce ambiguity, simplify handovers and help teams identify security and assurance problems earlier in the lifecycle.
Although the specific Secure by Design obligations apply to central government, the same governance discipline is relevant across wider public-sector Atlassian deployments.
Start with accountability, not Jira configuration
A well-governed Atlassian estate starts with clear ownership.
Secure by Design Principle 1 requires organisations to appoint senior stakeholders who are accountable for managing cyber security risks throughout the service lifecycle. They must also have the authority to lead security activity and make the necessary resources available.
Government guidance places the SRO and service owner within this risk and assurance activity, supported by the CTO, CISO, technical teams and delivery teams. Those responsibilities need to translate into clear authority over the Atlassian estate.
Who owns the platform? Who can grant administrative rights? Who approves projects, spaces, workflows, integrations and Marketplace apps? Who determines whether a configuration change has security or assurance implications? Who is responsible for producing the evidence required for review?
If those questions do not have clear answers, the problem is not a missing Jira setting. It is a gap in the operating model.
That gap usually becomes visible long before it causes a security incident. It appears in inconsistent workflows, unclear escalation routes, delayed access decisions and roadmap changes that stall because nobody can confirm who has the authority to approve them.
Clear accountability therefore does more than reduce risk. It removes administrative friction, accelerates decisions and makes the estate easier to operate as teams, apps and configurations change.
A workflow can record a decision. It cannot make the decision accountable.
Govern access not just authentication
Identity management shows the difference between having a platform capability and governing how it is used.
The NCSC recommends limiting access to authenticated and authorised identities and connecting cloud authentication to established joiner, mover and leaver processes.
Atlassian Guard Standard supports SAML single sign-on and SCIM user provisioning. SCIM can synchronise an external identity directory with Atlassian, creating, updating and deactivating managed accounts as changes are made in the identity provider.
These capabilities help automate identity management, but they do not determine who should have access, what that access should allow or how privileges should be controlled.
| Requirement | Atlassian capability | Organisation must govern |
|---|---|---|
| Authentication | SAML SSO and identity-provider integration | Authentication policy |
| User lifecycle | SCIM provisioning | Joiner, mover and leaver process |
| Access | Groups and permissions | Role and access model |
| Administration | Administrative roles | Privileged-access policy |
Organisations still need to define which roles exist, which groups receive access, who can become an administrator and how privileges are approved, reviewed and removed. Without those decisions, automated provisioning can make an unclear access model operate faster without making it safer.
Catapult CX’s Atlassian consulting services help organisations connect identity capabilities with the governance around them, including SSO, MFA, SCIM provisioning, role-based access and permission structures.
Marketplace apps. Govern the hidden supply chain
Marketplace apps are often treated as minor productivity additions. In a regulated government environment, that view is too narrow.
Secure by Design guidance requires organisations to conduct security due diligence when using third-party products. Those products should be assessed before implementation and reassessed throughout the service lifecycle.
That requirement applies directly to an extensible platform such as Atlassian.
Installing an app may introduce another supplier, permission set, integration and data path into the estate. Atlassian describes app installation as creating a separate relationship between the customer and a Marketplace Partner, leaving the customer responsible for assessing whether the app meets its requirements.
Depending on their functionality, installed apps may also exchange information with services outside Atlassian Cloud.
An Atlassian app is not just a feature. It can be another supplier and another data path.
A governed estate should be able to answer:
- Who is authorised to install apps?
- What security, privacy and supplier due diligence is required?
- What data can each app access?
- Where is that data processed and stored?
- Does the app support the required data-residency location?
- Who approves renewal and reassesses the supplier?
- Who monitors usage and removes apps that are no longer needed?
- What evidence is retained to demonstrate that these controls have been followed?
The objective is not to prevent teams from using valuable extensions. It is to ensure that a seemingly minor installation cannot bypass the security, data and supplier controls applied to the rest of the service.
Data residency. Know what stays where
Atlassian Commercial Cloud allows supported in-scope app data to be pinned to a United Kingdom data-residency location, which Atlassian currently maps to its Europe (London) AWS region.
The words in-scope app data matter.
Data residency is configured for individual Atlassian apps. It does not automatically apply to every piece of information associated with the wider estate. For example, Atlassian identifies user-account information, including names and email addresses, as data held within a centrally managed identity service with globally distributed replicas.
Marketplace apps add another layer. Data-residency support varies between apps and each Marketplace Partner determines which locations its app supports.
So, can Atlassian data be stored in the UK?
Yes. Supported in-scope app data can be pinned to Atlassian’s UK location. But that does not mean all information associated with the Atlassian estate automatically remains in the UK.
Organisations need to understand what data each Atlassian app, Marketplace app and integration holds, where it is processed and which supplier is responsible for it. Data residency should therefore be assessed app by app, integration by integration and supplier by supplier, not assumed at platform level.
For Confluence specifically, see our guide to governing Confluence as an enterprise knowledge-management system.
Audit evidence. Configure Atlassian around what you need to prove
Government assurance depends on evidence, but collecting logs is not the same as demonstrating that a control is working.
The NCSC says organisations should understand what cloud audit information is available, how it can be accessed, how long it is retained and whether it is sufficient to investigate misuse and security incidents.
Atlassian provides organisation-level and site-level audit logs, although the events captured and the available functionality vary by app and subscription. Atlassian states that Guard Standard, Guard Premium or an Enterprise plan is required to store and display organisation-level events.
Audit-log activities are retained for up to 180 days. Where evidence must be kept for longer, Atlassian recommends exporting it to another system.
The starting question should therefore be, What would we need to prove following an incident, assessment or audit?
For example:
- Who changed a permission?
- Who approved the installation or renewal of an app?
- When was a user’s access removed?
- Who altered a workflow, policy or configuration?
- Was the change reviewed and authorised?
Once those evidence requirements are clear, organisations can determine which events Atlassian needs to capture, which records must be exported, where they should be stored and how long they need to be retained.
Audit logs show what happened. They do not automatically prove that the underlying control was appropriate or effective.
Secure by Design makes a similar distinction. Even a high-confidence self-assessment does not replace wider security assurance or prove that a service is secure. Evidence must be reviewed in context and connected back to the requirement, control and accountable owner.
Cloud First does not remove your responsibilities.
The Government Cloud First policy makes public cloud the default when public-sector organisations procure new services or reconsider existing ones. The policy is mandatory for central government and strongly recommended across the wider public sector. Where an organisation chooses another route, it should be able to evidence why.
Cloud First does not mean moving Jira to Cloud regardless of the requirements. Nor does moving to SaaS transfer responsibility for configuration, access, data, suppliers or assurance to Atlassian.
Atlassian also offers Isolated Cloud for organisations with more demanding isolation requirements. It differs from Commercial Cloud in both architecture and feature availability, so it should be selected against defined security, operational and delivery requirements, not because a government organisation is assumed to need the most isolated deployment.
The deployment decision should follow the same governance model as the rest of the estate; establish the requirement, evaluate the available controls, assign ownership and retain evidence for the decision.
Is Atlassian Government Cloud for UK Government?
Atlassian Government Cloud is a FedRAMP Moderate-authorised environment designed for US Government agencies and their industry partners. Access is restricted to US Government bodies and organisations using it for US Government-related work.
It is neither the default nor a generally available deployment option for UK government organisations. UK teams should assess Atlassian’s available deployment options against their own security, data, operational and assurance requirements.
If your organisation is considering a move from Data Center, see our guide to planning a Jira Data Center to Cloud migration.
A practical governance model for Atlassian in government
Atlassian governance should not begin with a feature checklist. It should begin with the organisation’s requirements and trace each one through to a control, an accountable owner and evidence that can be reviewed.
| Governance area | Question to answer | Evidence to retain |
|---|---|---|
| Ownership | Who owns the estate and its risks? | Named platform owner, documented responsibilities and decision authority |
| Identity | Is access connected to the identity lifecycle? | Identity-provider configuration and joiner, mover and leaver records |
| Permissions | Who can see, administer and change what? | Role and group model, permission schemes and access-review records |
| Apps | Who approves third-party products? | App register, due-diligence assessment and approval record |
| Data | Do we know what is stored, processed and transferred where? | Data classification, residency mapping and documented data flows |
| Change | Who can alter the configuration? | Change request, approval trail and implementation record |
| Audit | Can significant actions be reconstructed? | Audit coverage, exported records and retention policy |
| Assurance | Are controls still appropriate and effective? | Scheduled reviews, findings and remediation records |
The operating model is simple. Every requirement needs an appropriate control, an accountable owner, evidence that it operates and a process for ongoing review.
Every material requirement should map to an appropriate control. Every control needs an accountable owner and evidence that it is operating. That evidence must then be reviewed as the service, technology and risk landscape change.
This reflects Secure by Design’s emphasis on continuous security activity and evidence throughout the service lifecycle, rather than treating assurance as a one-off approval gate.
Catapult CX used Jira and Confluence as part of its delivery environment for the digital UK Ship Register for the Maritime and Coastguard Agency. The tools supported delivery alongside cloud-native architecture and DevSecOps practices, while the service progressed through Alpha and public Beta assessments.
Atlassian was one component of the wider delivery model, but the project demonstrates how Jira and Confluence can operate within a real UK government service environment where delivery, security and assurance must work together.
How to tell if your Atlassian estate is under-governed
Governance weaknesses usually become visible before they contribute to a major incident.
Start with three basic questions:
- Who owns the Atlassian estate?
- Who has privileged access?
- Who approves third-party apps?
If you cannot answer all three confidently and support the answers with evidence, the estate has a governance gap.
Other warning signs include:
- Administrative access has accumulated without regular review
- Permissions are assigned to individuals rather than maintainable roles and groups
- Marketplace apps are installed without a documented assessment and approval process
- Integrations and data flows are not fully understood
- Data-residency assumptions have not been checked app by app
- Workflows and configurations vary without a clear operational reason
- Access reviews are inconsistent or absent
- Audit and evidence requirements have never been defined
- Reporting cannot be relied upon
- Configuration changes take place without controlled review and approval
Individually, these issues create friction and uncertainty. Together, they indicate that the Atlassian estate is evolving faster than the governance around it.
Catapult CX’s Atlassian Healthcheck examines permissions, apps, workflows, reporting and governance to identify where an estate is creating operational friction, assurance gaps or avoidable risk.
Governance that is built in. Not bolted on
Atlassian can help teams manage access, capture decisions, document work, track change and produce evidence. It cannot decide who owns your risks, which controls are appropriate, which suppliers you trust or what your organisation needs to prove.
Those decisions belong in the operating model from the start.
Good Atlassian governance connects requirements to controls, controls to accountable owners and owners to evidence that is continuously reviewed. Done properly, it reduces uncertainty, supports more dependable delivery and makes the estate easier to operate and trust. Not simply easier to audit.
Assess your Atlassian estate
Identify where permissions, apps, workflows, reporting or governance are creating operational friction, assurance gaps or avoidable risk. Available to purchase through G-Cloud 15, Catapult CX’s Atlassian Healthcheck gives you a clear view of what needs attention and a prioritised plan for improvement.
Book your Atlassian Healthcheck
Frequently asked questions
Is Jira compliant with UK government requirements?
There is no single Jira configuration or government certification that makes an organisation compliant. Secure by Design applies to how in-scope organisations manage cyber security throughout digital delivery. Jira can support those activities, but compliance depends on the organisation’s controls, governance and evidence.
Can Jira support Secure by Design?
Yes, as part of a wider operating model. Jira can support workflows, ownership, change tracking and the production of evidence. However, installing or configuring Jira does not demonstrate that the Secure by Design principles have been met. The organisation must still define, operate and review the appropriate controls.
Can Jira support the GDS Service Standard?
Yes, as a delivery tool. Jira can support iterative delivery, work tracking, ownership, dependencies and decision records. However, using Jira does not demonstrate that a service meets the GDS Service Standard. Teams must still provide evidence against the relevant service requirements.
Is Atlassian Government Cloud available for UK government?
Not as a general UK government deployment option. Atlassian Government Cloud is a FedRAMP Moderate-authorised environment designed for US Government agencies and their industry partners. Access is restricted to organisations using it for US Government-related work.
Does Cloud First mean UK government organisations must move Jira to Cloud?
No. The Government Cloud First policy makes public cloud the default, but organisations must still assess whether a particular deployment meets their security, data, operational and assurance requirements. Where another approach is selected, the decision should be supported by appropriate evidence.
Can Atlassian data be stored in the UK?
Yes. Supported in-scope Atlassian Commercial Cloud app data can be pinned to Atlassian’s United Kingdom data-residency location. Organisations must separately assess data outside that scope, including relevant account information, Marketplace app data and information exchanged through integrations.
Are Atlassian Marketplace apps covered by the same security controls as Atlassian Cloud?
Not automatically. A Marketplace app can introduce another supplier, permission set, integration and data path. Each app should be assessed against the organisation’s security, privacy, data-residency and supplier requirements before installation and throughout its use.
Does SSO provide a complete access-control model?
No. SSO helps authenticate users, while SCIM can help automate account provisioning and deactivation. The organisation must still define which roles and groups receive access, who can hold administrative privileges and how permissions are approved, reviewed and removed.
Does buying Atlassian through G-Cloud make it government compliant?
No. G-Cloud is a procurement framework through which eligible public-sector organisations can buy cloud services. Buying through the framework does not replace the organisation’s Secure by Design, security, configuration, data-governance and assurance responsibilities.
What should an Atlassian governance review cover?
At minimum, the review should cover ownership, identity, privileged access, permissions, Marketplace apps, integrations, data handling and residency, workflows, change control, audit evidence, reporting and ongoing assurance. It should establish who owns each control, what evidence demonstrates that it operates and how regularly it is reviewed.
