Why Atlassian Marketplace app security deserves a review
Once installed, a Marketplace app can read and sometimes change content in your Confluence spaces or Jira projects, within the permissions it was granted. Installing it also creates a direct relationship between your company and the vendor. Atlassian's own trust material is clear that you are responsible for assessing whether an app suits you and for reviewing the vendor's policies.
Atlassian does set a floor: every cloud app must meet baseline security requirements, vendors must publish a privacy policy, and Atlassian runs ongoing automated security checks across Marketplace cloud apps. That floor tells you nothing about whether a particular app's access fits what you want it to do, or whether its data handling fits your commitments to customers. And if you are working toward a SOC 2 report, apps that touch company or customer data are vendors, so a short written review before each install saves reconstructing one at audit time.
Where to find an app's security information
Start with the listing. Cloud apps on the Marketplace have a Privacy and Security tab, built for a first-pass assessment. Its default view covers whether the app stores or processes end-user data outside Atlassian, whether it supports data residency, its GDPR role, any compliance certifications the vendor claims, a link to the privacy policy, the permissions it uses and whether the vendor runs a bug bounty. An expanded view adds details such as logging, subprocessors and third-party sharing, data retention after uninstall, encryption at rest, whether a data processing agreement is available, and the vendor's security contact.
Vendors are encouraged, but not required, to fill in that tab. A blank or half-empty one isn't proof of a problem, but it means you need the answers from the vendor directly. Also read the vendor's privacy policy (what the app stores, where, for how long, and who receives it), and read the install screen, where Atlassian shows the permissions the app requests and asks for consent.
A security review checklist for Confluence and Jira apps
Work through these in order. The first check decides how deep the rest need to go.
1. Write down what the app is for
Write one or two sentences on what you need the app to do and which spaces or projects it should touch. Every later check compares the app's access against that sentence. An app that formats tables in one team's space is a smaller risk than one that reads every page on the site, so keep the review proportionate.
2. Check the permissions against the purpose
Apps declare the permissions (scopes) they need, and Atlassian presents them to administrators so they can decide whether to install. Ask of each one: does this app need it for the job you wrote down? A reporting app that asks to write pages, or a diagram app that asks to read user details, deserves a question to the vendor. Pay particular attention to write and delete permissions and to permissions on users, groups and space settings.
For apps built on Atlassian's Forge platform, a new version that adds permissions or new external destinations is a major version, and by default it isn't applied to your site until an admin consents to the upgrade. That gives you a natural point to repeat this check.
3. Find out whether data leaves Atlassian, and where it goes
This is often the most important question. Some apps run entirely on Atlassian's infrastructure; others send data to the vendor's servers or to third-party services. Neither is automatically wrong, but you need to know which you have. Look for:
- whether the app stores or processes your data outside Atlassian (the first lines of the Privacy and Security tab),
- which third parties and subprocessors receive data, and in which countries,
- whether the app exposes its own remote API that holds your data,
- what is logged, and whether page content or personal data appears in those logs.
Forge apps must declare every external domain they contact, and Atlassian's runtime blocks calls to anything undeclared, so their outbound traffic is easier to reason about.
4. Confirm data residency, if you have a requirement
Confluence and Jira offer data residency on the Standard, Premium and Enterprise plans. If you have pinned your product data to a region, check whether each app supports residency too: the listing's Privacy and Security tab says so, and in Atlassian Administration, under Data management then Data residency, the details view shows which installed apps are pinned, eligible or not eligible.
5. Look at the vendor's security program
You are trusting the vendor's people and processes, not only the code. Check for a security contact or vulnerability reporting route, any audit reports or certifications the vendor holds, and a data processing agreement if you need one. For an app that will hold sensitive data, ask for the vendor's SOC 2 report or equivalent. Our guide to answering security questionnaires covers the common formats from the other side of the table.
6. Read the trust badges for what they mean
Atlassian runs programs that show up as badges on a listing. Each one tells you something specific:
- Runs on Atlassian marks Forge apps that use only Atlassian-hosted compute and storage, support data residency matching the host product, and send no in-scope end-user data outside Atlassian. Atlassian applies it automatically based on how the app is built.
- Atlassian Enterprise Certified marks Forge apps that Atlassian has checked against a set of enterprise security, reliability, privacy and support requirements.
- Cloud Fortified is an older program covering security, reliability and support. Atlassian has stopped accepting new submissions and is phasing it out by the end of 2026, so you will see it less over time.
A badge answers part of the checklist, not all of it: it says nothing about whether the app's permissions fit your purpose.
7. Know what happens when you leave
Check how long the vendor keeps your data after uninstall, and what stays in your site. Content kept in ordinary Confluence pages or Jira fields remains; content in the app's own storage goes with it. Know this before you depend on the app.
The checklist at a glance
| Check | Where to look | A good answer |
|---|---|---|
| Purpose and reach | Your own request | One clear use, named spaces or projects, a named internal owner |
| Permissions (scopes) | Listing, install consent screen | Every permission matches the purpose; no unexplained write, delete or admin access |
| Data leaving Atlassian | Privacy and Security tab, privacy policy | None, or a short, named list of destinations and subprocessors you accept |
| Data residency | Privacy and Security tab, Data residency in Atlassian Administration | Supported in your region, or not needed for this app |
| Logging | Privacy and Security tab (expanded) | No page content or personal data in vendor logs |
| Vendor security program | Listing, vendor website, direct request | Security contact, vulnerability process, audit report or certification as your tiering requires |
| Retention and exit | Privacy and Security tab, privacy policy | You know what is deleted, what stays and how long the vendor keeps it |
| Decision | Your vendor register | Approved, approved with conditions, or declined, with a date and an approver |
Admin controls for third-party app risk in Atlassian
A review only works if apps can't arrive without one. Atlassian Administration gives you these levers:
- Who installs apps. Organization admins and site admins install Marketplace apps. Some apps can also be installed by individual users; the Connected apps page has a setting to block user-installed apps, so installs go through admins.
- The installed list. The same Connected apps page lists every app installed on a site, which is your starting inventory.
- Blocking app access to content. Data security policies let an organization admin block eligible Marketplace and custom apps from user-generated content, such as pages and work items, in selected spaces and projects. The basic block is available on any plan; allowing specific apps while blocking others needs Atlassian Guard Standard or Premium. Not every app is eligible, and a blocked app may still reach some data, such as space names, so this adds to the review rather than replacing it.
- Upgrades that widen access. Assign someone to look at pending Forge major-version upgrades instead of approving them in bulk.
Review installed apps periodically
Apps change after you install them: new features, new subprocessors, versions that ask for more access. Your use changes too. At least once a year, walk through the installed apps list and for each one:
- Confirm it is still used and still has an internal owner. Remove anything nobody claims.
- Compare its current permissions and Privacy and Security answers with what you recorded at install.
- Check the badges, residency support and privacy policy for changes, such as new subprocessors.
- Record the outcome and the date, even when nothing changed.
Treat Marketplace apps as vendors
Put apps into your existing vendor process instead of inventing a separate one. Each app that touches company or customer data gets a row in your vendor register, a risk tier, an owner and a review date. The checklist above becomes the evidence for that row. Our vendor risk management guide covers tiering, reading a vendor's SOC 2 report and the annual review in detail.
In SOC 2 terms, this is part of how you show you manage vendor and business partner risk (criterion CC9.2 in the Trust Services Criteria). Your auditor decides what evidence they want to see, but a dated review record per app, an approver and a periodic re-review are a reasonable baseline to plan for.
How Compliance in a Box answers the checklist
Here is how Compliance in a Box, our app for running a SOC 2 program in Confluence, answers the checks above.
| Check | Compliance in a Box |
|---|---|
| Where it runs | Built on Atlassian Forge and carries the Runs on Atlassian designation. There is no vendor backend. |
| Data leaving Atlassian | None. No external domains, no remote servers and no third-party subprocessors. |
| Data residency | Supported. App data follows the data residency location of your Confluence site. |
| Permissions | Every scope it requests is justified against the specific Confluence API calls that need it, and the set was settled before the first public release. |
| Personal data | People are stored only as Atlassian account IDs, never names or emails. When an Atlassian account is closed, the app erases it from its records. |
| Vendor access | Auralite Solutions has no access to the data the app stores. |
| Exit | Policies, evidence and generated reports are ordinary Confluence pages in your space, and they stay there if you uninstall. |
The privacy policy lists exactly what the app stores, and the Data and privacy section of the user guide summarizes it for admins.
The app also helps with the vendor side of the problem. Its SOC 2 content includes a Vendor & Third-Party Management Policy and an annual Vendor Risk Review activity, both mapped to CC9.2. Each year the Vendor Risk Review opens its own evidence page, where you can record the Marketplace apps you reviewed alongside your other vendors. The SOC 2 content reference lists every activity and its cadence.
FAQ
Does Atlassian security-review Marketplace apps?
Atlassian requires every cloud app to meet baseline security requirements, requires vendors to publish a privacy policy and runs ongoing automated security checks. It also states that customers remain responsible for assessing whether an app suits them. Treat Atlassian's checks as a floor, not as your review.
Does "Runs on Atlassian" mean I can skip the review?
No, but it makes the review shorter. The badge answers where the app runs, where data goes and data residency. You still need to check permissions against purpose, look at the vendor's security program and record your decision.
Can I stop an installed app from reading certain spaces?
Often, yes, with data security policies in Atlassian Administration, as described above. Not every app is eligible, so check the result for the apps you care about.