An Atlassian data security policy decides what users, apps and anonymous visitors can do with your Jira and Confluence content, and only some of it works without Atlassian Guard. In fact, only one of its seven controls does. When we tried to create an export control on our test organization through the admin API, which has no Guard subscription, the answer came back straight away:
HTTP 400
{"code":"ADMIN-400-3","title":"Atlassian Guard subscription required","detail":"An active Atlassian Guard required"}
That was a draft, not an active control. The Guard check happens before anything is saved.
This post is the map I wanted before I started. Which controls exist, which ones need Guard and which tier, what the app access rule actually takes away from an app, how to set a control up without locking yourself out, and what happens to all of it when content moves into Cloud from Data Center or between two Cloud sites. Everything here comes from Atlassian's own support and developer pages, read on 26 September 2026, plus the calls we made against our own test org the same day. Where the docs are silent I say so rather than guess.
What an Atlassian data security policy covers
Atlassian's definition is short: a data security policy "enables you to govern how users, Marketplace and custom apps, and people outside of your organization can interact with content such as Confluence pages and Jira work items." The important difference from permissions is the next sentence. Instead of relying on user and app permissions, it "leverages controls to allow or block content actions based on content-specific attributes, such as where the content is located, or what classification level has been assigned to it."
The model has also changed recently, which is worth knowing because search results still show the old one. Your organization now has one data security policy made of controls. Each control has a default configuration and optional overrides. The pages that still rank as "Create a data security policy" and "Edit a data security policy" both redirect to Apply a default configuration to a policy control. By default every control is set to allowed.
The Manage an organization's data security policy page lists seven controls:
- Prevent data export
- Prevent public links
- Prevent anonymous access
- Block Marketplace and custom app access
- Manage third-party spreadsheet app permissions for project data
- Prevent Atlassian MCP server access
- Prevent attachment downloads
Data residency is not one of them. It lives next door as its own policy type. On our test org the policies endpoint returned 35 policies, 19 of them data residency, and not one data security policy. We checked the filter on the same endpoint before trusting that empty result: ?type=data-security returned an empty list, and ?type=data-residency returned 19.
Coverage can be set at a few levels. The developer guide names them as the whole organization, a workspace ("a product or site, such as a Confluence or Jira instance"), a container ("like a Confluence Space or Jira Project") and a classification level. The support pages now call Jira projects "spaces" as well, so when you see "Spaces" in the override options it includes projects.
Which data security policy controls need Atlassian Guard
This is the question the Atlassian Guard sales page doesn't answer directly, so here it is from the availability table on What is a data security policy?. The table has three columns: organizations without Guard, Guard Standard and Guard Premium.
Anonymous access, data export, attachment download, public links and the Atlassian MCP server control all say "Not available" without Guard. With Guard Standard they can apply to all your Jira and Confluence apps (all Confluence apps for public links), with overrides by space and by app. Guard Premium adds classification level as a coverage type on top.
The Marketplace and custom app access control is the exception. Without Guard it "Applies to all Jira and Confluence apps" with space overrides that apply "to all or no apps". With Guard Standard or Premium you get to choose which apps. The Block Marketplace and custom app access page puts it as a table: block all apps on selected spaces is "Any plan", and allowing some apps, on all spaces or on selected spaces, needs Guard Standard or Guard Premium.
The spreadsheet app control, which stops apps such as Google Sheets and Microsoft Excel from reading protected Jira project data, is missing from that table, but its own page settles it: "Atlassian Guard Standard or Premium". That makes the count six of seven behind Guard.
Two things about plans trip people up. The tiers here are Guard tiers, not your Jira or Confluence Standard, Premium or Enterprise plan. The one link between them is on the Guard pricing page: the Cloud Enterprise plan "includes Atlassian Guard Standard at no additional cost". Classification-based rules are a Guard Premium feature on top of that. When we checked the pricing page it showed Guard Standard at $4.20 and Guard Premium at $8.18 per user per month, which is higher than the figures in our earlier post on Atlassian Cloud edge security, and prices on that page can be localised, so check it for your region.
The second thing is what happens if you stop paying. Atlassian says that if you cancel, "your existing policies will still be enforced, but any rules or coverage that require Atlassian Guard Standard can't be edited or changed until you restart your subscription." A lapsed subscription leaves you with controls that still block, which you can't change until you pay again.
App access rule: which apps lose access to your content
The app access rule is the only control every Cloud org can use, so it is the one to understand properly. Atlassian announced it in February 2024 in App access rules are coming soon in two versions: one that allows or blocks all apps in a given space or project for everybody, and one that blocks selected apps, for Guard customers only. That is how it shipped.
When an app is blocked on a space, it loses "all ability to read, write, or delete the user-generated content that is covered by the override, regardless of permissions." In Confluence that means pages, blog posts, attachments, the shape of the content tree, and metadata such as version history and ownership. In Jira it means things like summary, description, labels and comments on work items.
What it doesn't take away matters just as much.
The app stays installed. Admins see a BLOCKED lozenge next to it in the apps list, but nothing is uninstalled. A blocked app can still "read and make changes to user groups and permission schemes" if it asked for those permissions at install time. That is admin-level reach the rule does not remove.
Some metadata stays visible. The developer guide says space key and name, and project key and name, cannot be blocked, and an app "may still access the space name, space key, audit records, and templates".
Some apps can't be blocked at all. System apps bundled by Atlassian, pre-installed Atlassian apps such as Smart Links, application links between Jira and Confluence, and Marketplace apps that hold a waiver to use API tokens or credentials. The list of apps that cannot be blocked names 2 Confluence apps and 15 Jira apps, among them JMWE, BigPicture, Configuration Manager for Jira Cloud, Deep Clone for Jira, Rewind Backups, Revyz and JEMH. Marketplace apps in the Atlassian DevOps ecosystem are "currently unsupported".
Data the app already stored isn't touched by the block, but the coverage summary warns that blocking "could result in the installed app deleting the data as no longer required", and that it may not come back if you unblock. If you depend on an app's stored data, ask the vendor what their app does when it gets blocked before you turn this on.
Two behaviours are easy to miss. Blocking all apps covers "any eligible future Marketplace and custom apps" too, so a new install lands already blocked on those spaces. And uninstalling an app doesn't clear its configuration: reinstall it and "your original configuration for that Marketplace or custom app is restored".
For app developers there are Forge events for this (avi:ecosystem.app_policy:blocked:app_access_to_objects.v2 and the _in_container variant) and data policy REST APIs in Jira and Confluence, documented in the data security policy developer guide. The Jira one is app-only. Calling GET /rest/api/3/data-policy with an admin's API token got us 401 {"errorMessages":["Only apps can access this resource."]}.
One number I can't reconcile for you. The support page says "You can block up to 2,000 spaces from up to 2,500 apps." The developer guide says an admin "may select up to 15 spaces (containers) per policy". The support pages describe the current admin experience, so I'd plan against those, but if you're near the limit, test it rather than trusting either number.
Prevent public links and anonymous access in Confluence
These two need Guard Standard, and they're the ones most people are really asking about when they search for locking Confluence down.
When public links are blocked for some content, users can't turn them on for it, and "All existing public links will be turned off for content covered by the control." The part to plan around is the reverse: "If you later change the control to allow public links, these links won't be turned back on automatically." Every link someone sent to a customer or partner stops working, and Atlassian doesn't turn them back on for you. Atlassian says the change can take up to 10 minutes to reach Confluence. Jira Product Discovery is listed as an app you can add as an override, but "Jira Product Discovery apps don't support data classification".
Blocking anonymous access means "Users must be logged in to see work items covered by this control." A direct URL shows a login prompt, and through the REST API the page or work item simply "won't be returned". There's a warning on the overview page worth reading twice: preventing anonymous access "may restrict licensed users who are not part of any space group in Confluence or Jira, resulting in access denial." If you have spaces opened up with a broad "anyone logged in" style grant, check who actually gets in through a group before you turn this on.
The export control blocks the obvious routes (Confluence PDF and Word, space exports, Jira Word, Excel, XML, CSV and friends, JSM forms downloads), but by Atlassian's own account it "doesn't prevent Marketplace or custom apps from exporting content" and doesn't stop "print, save, or actions performed by browser extensions". Treat it as a speed bump, not a wall.
How to create a data security policy (and test it before you activate)
The path is Atlassian Administration, then Security, then Data protection, then Data security policy. From there you set a control's default and add overrides.
There is no simulate or dry-run mode documented anywhere we looked. The only safety net is drafts: "To keep your active control safe while you configure an override, your changes are saved in a separate draft. Each control has one draft." A draft doesn't affect anything. Activating it does, and "When you activate a draft, it replaces the previous control. This action can't be undone. Any overrides configured for your previous control can't be retrieved." Changing a control's default configuration also removes its overrides automatically.
So before you activate, write down the current overrides somewhere outside the admin console, because the console won't keep them for you. Atlassian's own advice after adding overrides is "make sure you test the results", which in practice means a test space, a test page with a public link, and an account that isn't in any space group.
Through the API the order matters too. On our test org, with no Guard, creating an app access block at workspace level came back as ADMIN-400-24 "Unsupported rules present based on policyCoverageLevel". A block on a single container came back with "An existing org-wide policy must be present before creating an override". Once we created an org-wide allow draft first (HTTP 202, no Guard needed), the container block draft was accepted too. We created both as drafts with no spaces attached, so we didn't see their effect on any content, and we removed them afterwards. The v2 delete route doesn't exist (404), the v1 one accepted it (202), and the deleted drafts still show up in the list with status deleted.
Data security policies after a Data Center to Cloud migration
This is where most of the questions come from on migration projects, and where the documentation is thinnest.
The policy lives in the Cloud organization. Data Center doesn't have one of its own, so there is nothing to migrate across as a policy. What can come across is classification. The Confluence Cloud Migration Assistant's "What is migrated" list includes spaces "including the default classification level" and pages "including page restrictions, page classification level". If the levels carry the same names in your Cloud org, Guard Premium controls that target them should then apply to that content, though no migration page says so in as many words, so check it on a sample.
Jira is different. The Jira Cloud Migration Assistant's "What gets migrated" page doesn't mention classification anywhere, not even once, and neither does it mention data security policies. If you classify Jira work in Data Center, don't assume the levels arrive. Check a sample of migrated issues in Cloud.
Classification on Data Center is itself a Cloud feature reaching back. The Classify your data page for the Guard Premium integration for Data Center (in beta) says your Cloud organization must already contain the classification levels and "any data security policies applied to the classification levels". It also says the Data Center app "currently supports export restrictions and anonymous access restrictions. Other restriction policies apply only to your cloud organization, and your Data Center products will ignore those policies." During a phased migration, where some spaces are still on Data Center, a public links or app access control only protects the ones already in Cloud.
Then there's coverage of the newly arrived content. Controls with an app-level default ("Applies to all Jira and Confluence apps") should cover a migrated space along with everything else in that app. I'm inferring that from the wording, since no migration page states it. The app access overrides are explicit the other way: "If you add a new space to an Atlassian app, and you wish to block Marketplace and custom apps from that space, make sure you update the control to include the new space." Every migration wave adds spaces. If your org blocks apps space by space, updating that control belongs in the wave's cutover checklist, next to the identity and config gaps you already check.
Cloud to Cloud migration: do data security policies copy across sites?
A Cloud to Cloud move uses Atlassian's Copy product data, not JCMA or CCMA, and its What data is copied page is specific about a few neighbouring things. Page restrictions are copied. Public links are not: "these will need to be newly generated". Global permissions and default space permissions are copied, the "Security configuration" is not, and neither are apps and app data stored with the vendor.
On data security policies and classification levels, that page says nothing. Neither do Transfer Confluence data, Transfer Jira data, or the before-you-start page. We searched all four for "classif" and "data security" and got zero hits on each.
So here is what I'd tell someone planning it, with the inference labelled as inference. The policy belongs to the organization, not the site. If you're copying between two sites in the same organization, the same policy is already in place, and whether it covers the destination depends on how its coverage is set: an app-level default reaches the destination's apps, a space override does not reach the newly created spaces until you add them. If you're copying into a different organization, nothing we found says the policy travels, so plan to rebuild it there, and budget for Guard on the destination org if the source relied on anything beyond the app access block. Either way, public links are gone after the copy, which removes one exposure but means anyone who relied on a public link to the destination copy needs a new one. Check page classification levels on a sample of copied pages before you rely on classification-based rules in the destination. The Atlassian Cloud architecture post explains the org, site and product layers that make this distinction matter.
What I'd do with this on a real project
If you don't have Guard, your one lever is blocking all apps from specific spaces. It's a blunt tool, but for a handful of HR, legal or security spaces it does what it says, as long as you check the unblockable list against your installed apps and remember to add new spaces by hand.
If you do have Guard Standard, set public links and anonymous access deliberately. Know that blocking public links turns existing ones off and allowing them again won't bring them back, and test with an account that isn't in any space group.
If a migration is in flight, put the data security policy on the cutover checklist. Add the migrated spaces to any space-based app override, spot-check classification levels on migrated Confluence pages, and assume nothing about Jira classification or about a Cloud to Cloud copy carrying policies, because Atlassian hasn't written down that it does.
Originally published on leanzero.net. More Atlassian, Forge and local-AI write-ups at leanzero.net/blog, and if you're planning a migration or a Forge app, that's what we do: leanzero.net/services.
