Atlassian Jira Security Review for Permissions, Portals and Marketplace Apps
Jira runs on permission schemes, project roles and issue security levels that your admins configure project by project, and Jira Service Management adds a customer portal boundary on top of that. When a scheme gets copied across projects without anyone re-checking who it grants access to, or a portal fails to keep customers separate from agents, the gap sits in your configuration, not in Atlassian’s platform. We test your Jira Cloud or Data Center site: project and issue permissions, anonymous and public access, attachments, installed Marketplace apps, and the boundary between Jira Service Management customers and agents. CREST-certified testers, fixed price from £2,840 for a 2-day single-site scope, quoted within 24 hours.
- Unlimited retesting
- Unlimited pre-retesting
- No hidden fees
“I would highly recommend EJN Labs to any organisation seeking reliable, detailed, and well-managed penetration testing services, particularly for government or enterprise-level projects.”
“There wasn’t another company we could find that could deliver what we needed in the timeframe we needed. The client loved it, and we got instant ROI from the engagement.”
Every project’s permission scheme decides who can browse, create and change its issues, and the same scheme can sit underneath dozens of unrelated projects at once.
Why Jira access comes down to the schemes your admins set
Atlassian’s own documentation sets out how access in Jira is meant to work: global permissions control the whole site, permission schemes control each project, and issue security schemes control individual issues within a project. Jira enforces every layer exactly as your admins have configured it, and a scheme that was correct when a project launched can drift as roles, groups and Marketplace apps are added around it.
A Jira Service Management project adds a further boundary on top of that: customers are granted access through a separate Portal Access permission rather than the general Jira access an agent or collaborator holds, and that boundary is what is meant to stop a customer reaching an agent’s queue or another customer’s request. The same site can also carry a project with anonymous or public access switched on for a specific reason, such as a public roadmap or an external bug tracker, and that setting is easy to leave in place after the original reason for it has gone.
Marketplace apps add another surface again, since a Forge or Connect app is granted its own scope into your site the moment it is installed, sometimes reaching as far as a connected Microsoft 365 tenant when it links SharePoint or OneDrive files to issues, the same boundary a SharePoint penetration test checks from the Microsoft 365 side. We test the project permissions, issue security, portal boundaries and app scopes you have actually configured, on Jira Cloud or Jira Data Center, never Atlassian’s underlying platform.
SCOPE
What we review in a Jira site
Global Permissions and Site-Wide Access
Global permissions sit above any single project and control site-wide capabilities such as creating new projects, changing multiple issues at once, and sharing dashboards and filters, and they can be granted to any group your organisation admin has created. We test which groups hold each global permission and whether that group still matches who should be able to act across your whole site rather than one project.
Project Permission Schemes and Roles
Permission schemes decide who can browse, create, edit, assign and delete issues within a project, and the same scheme can be shared across many projects at once using project roles instead of named users. We test whether a role or group in a shared scheme carries permissions wider than every project using that scheme actually needs, and whether a scheme has drifted since it was first assigned.
Issue-Level Security Schemes
Issue security schemes sit underneath a project’s permission scheme and hide individual issues from anyone not assigned to the matching security level, even when they can otherwise browse the rest of the project. Atlassian’s own default behaviour makes a moved or newly created issue fall back to visible for everyone with project access whenever the destination project has no matching security scheme or level, and we test specifically for issues that have fallen through that gap.
Anonymous and Public Project Access
Jira Cloud allows anonymous access only when an admin sets the Browse Projects permission to Public within a project’s permission scheme, at which point anyone can view the project and its issues without logging in or holding a Jira licence. We test every in-scope project’s permission scheme for a Public grant on Browse Projects that was left in place beyond its original purpose, including on projects that were never meant to be reachable without an account.
Public Issue Creation and Attachments
Setting Create Issues to Public lets anyone with access to your site raise a new issue without logging in, and an issue created this way shows Anonymous as its reporter, while a separate Create Attachments permission decides who can add files once the issue exists. We test what an anonymous or low-privilege reporter can actually attach, and whether a required custom field or attachment setting quietly grants more access than issue creation alone.
Marketplace App and Forge/Connect Scopes
Every Forge app declares the OAuth 2.0 scopes it needs in its manifest, and a Connect app declares its own scope set in its descriptor, from read-only access through to full Jira administration actions such as creating projects or custom fields. A common Marketplace app category connects a client’s Microsoft 365 tenant to attach SharePoint or OneDrive files directly to issues, and we test whether an installed app’s granted scope goes further than the function it was actually installed for.
Jira Service Management Portal Boundaries
Customer permissions in Jira Service Management are granted through a separate Portal Access permission rather than the Jira access an agent or collaborator holds, and that boundary is what is meant to stop a customer reaching an agent’s queue or another customer’s request. We test whether a customer account can reach agent-only views or a second customer’s request, including through the option, enabled on some service projects, that lets customers share their own requests with each other.
API Tokens and Scoped Access
An API token authenticates a script against Jira’s REST API in place of a password, and Atlassian now recommends creating tokens with scopes that limit exactly what the token can view, write or delete rather than issuing an unscoped token with the same reach as the account that created it. We test for unscoped or over-scoped tokens still active on accounts that no longer need that level of access.
Guest Accounts and External Collaborators
A guest account gives an external collaborator access to a single project without a full Jira licence, and Atlassian fixes a guest’s permission set so it cannot be expanded through a permission scheme or project role the way a normal user’s access can. We test whether a guest account can still reach a second project, or whether its fixed permissions have been worked around through another route such as a shared board or automation rule.
Cloud and Data Center Deployment Exposure
Jira Cloud runs on Atlassian’s shared multi-tenant infrastructure, where customer testing is limited to your own instance under Atlassian’s published rules, while Jira Data Center runs on infrastructure your own organisation controls, where the surrounding servers, network and access configuration are also in scope. We test to the deployment you actually run and confirm it, along with any shared boundaries, before scoping starts, never Atlassian’s own Cloud platform.
OUR PROCESS
Atlassian Jira Security Review: From Scope to Attestation
Scope and Access
We agree which Jira site, projects and Jira Service Management projects are in scope, plus a role account for every permission tier, portal access if customers are in scope, and any Marketplace app or API token credentials we need.
Permission and Scheme Mapping
We map global permissions, each in-scope project’s permission scheme and any issue security scheme against who should actually hold that access, and catalogue installed Marketplace apps and their granted scopes.
Manual Testing
A CREST-certified tester manually tests project and issue permissions, anonymous and public access, attachment handling, the Jira Service Management portal boundary between customers and agents, and API token or app scope misuse, chaining findings where they compound.
Attestation and Retest
You get a technical report with CVSS scores and reproduction steps, a walkthrough call, a free retest once fixes are deployed, and an attestation letter for auditors.
CREDENTIALS
Verified Accreditations Auditors Accept
Every credential below is independently verifiable. UK procurement teams, FCA supervisors, ISO 27001 / SOC 2 auditors, and cyber insurance underwriters all recognise these standards.
GET YOUR QUOTE
Get a CREST Jira pen test quote in 24 hours
A fixed-price quote back in one business day, from a named CREST assessor. No sales pipeline, no chasing.
- CREST and IASME accredited. Testing your auditors and clients already recognise.
- Fast-track testing within 24 hours where required. Free retest of every fix included.
- Live findings via your client portal, not a four-week PDF.
- Fixed price from £3,500 for a single-role, single-app scope, agreed up front. Most engagements run £5,000 and up. No day-rate surprises.
Dan WilcocksonFounder, CelloriUnder NDA Further named references available on a scoping call.
- We reply within one business day with a fixed-price quote from a named CREST assessor.
- You approve the scope and we book a start date, usually within 24 hours.
- Live findings land in your client portal as we test, with a free retest of every fix.
Get your fixed pen test quote in 24 hours
Quote request received
We will reply within one business day with your fixed-price quote from a named CREST assessor.
Your data stays with us. No newsletter signup.
or book a 20-min scoping call first
We reply within one business day. Your data stays with us. No newsletter signup.
COMPLIANCE READY
Reports Mapped to Every Framework
Findings are written so your team can reference the report against each framework without translation work.
ISO 27001:2022
Annex A.8.8 management of technical vulnerabilities plus A.5.15-5.18 and A.8.2-8.5 access control validation.
SOC 2 Type I & II
CC6 logical access, CC7 system operations, CC8 change management evidence.
PCI DSS
Requirement 11.4 application penetration testing across cardholder data environments, including ecommerce penetration testing for online retail platforms.
FCA SYSC
SYSC 4.1.1R, 6.1.1R, 13 mapped to each finding for FCA-regulated firms.
UK GDPR
Article 32 effectiveness testing, customer-data security controls, ICO-acceptable evidence.
Cyber Essentials Plus
Direct certification through our IASME body status, single-vendor delivery.
PRICING
Transparent Atlassian Jira Security Review Pricing
Pricing depends on the number of roles, integrations and environments in scope. See our pricing page for how we quote.
2 to 4 testing days
Single user role, basic CRUD application, marketing website with auth. Around 5 working days from kickoff to report.
Get a fixed quote4 to 5 testing days
Multi-role SaaS, business application with payment integration. Around 8 to 12 working days from kickoff to report.
Get a fixed quote5 to 7 testing days
Multi-tenant platform, complex authorisation matrix, integration-heavy applications. Around 15 to 20 working days from kickoff to report.
Get a fixed quoteSECTORS
Sectors We Test Jira For
Sector-specific scoping for regulated UK organisations.
Fintech & FCA-Regulated
FCA SYSC, Open Banking FAPI 1.0, PSD2 SCA, payment-flow scrutiny, KYC/AML testing.
Fintech sector pageSaaS Companies
SOC 2 Type I & II evidence, multi-tenant boundaries, role escalation, customer-tenant isolation.
SaaS sector pageLaw Firms
SRA Cyber Standard, privileged data, conveyancing fraud defence, partner-tier procurement.
Law firm sector pageHealthcare
NHS DTAC, DSP Toolkit v6, UK GDPR Article 32, EHR systems, telehealth platforms.
Healthcare sector pageInsurance
FCA / PRA Operational Resilience, cyber underwriting, claims data, broker portals.
Insurance sector pagePublic Sector
CCS / G-Cloud framework, NCSC-aligned, citizen-facing services, PSN-compliance scrutiny.
Public sector pageWHY EJN LABS
What You Get From Atlassian Jira Security Review
Six concrete differentiators competitors don’t all match.
CREST-Certified Testers, Verifiable
Every test by a CREST-certified pen tester (CRT, CCT APP, CCT INF where applicable). Verify our company status at crest-approved.org.
24-Hour Startup, Where Required
From signed scope to active testing in a single business day for incident response, audit deadlines, or regulator-driven timelines.
Live Findings, Not 4-Week PDFs
Critical issues reported during testing through your client portal. Your team remediates while testing continues.
Audit-Ready Reports
Executive summary plus full technical report with CVSS scores and explicit framework mappings (ISO 27001, SOC 2, PCI DSS, FCA SYSC).
Free Retests, Standard
Verify remediation of every finding before close-out. Letter of attestation for audit submission included. Most competitors charge £1,500-£3,000 per retest.
UK-Based CREST Testers
Every engagement performed by vetted, UK-based CREST-certified testers, matched to your needs, security clearance, and compliance scope.
FAQ
Frequently Asked
What access do you need to test our Jira site?
We need at least one authenticated account for every permission tier in scope, including a standard user, an agent or collaborator account if Jira Service Management is included, and an admin account if you want scheme and configuration review alongside the manual test. If any project has anonymous or public access enabled we also test that path without any credentials at all.
Will testing touch live data?
We test the Jira site and projects you nominate, working against your real project structures and issues rather than a copy, so we agree exclusions such as production automation rules, outbound integrations or notification triggers before testing starts. We do not run destructive tests, bulk-delete issues or export real customer data without that agreement in writing.
How long does a Jira security review take?
A single Jira site with a small number of projects in scope sits in our 2-day single-site scope, with a report typically landing around 5 working days after kickoff. A site with more projects, Jira Service Management portals or Marketplace apps in scope moves into a larger scope with more testing days.
Do you test Jira Cloud and Jira Data Center the same way?
The testing questions are the same: permissions, issue security, portal boundaries and app scopes. The boundary of what we can touch is not the same, since on Jira Cloud we test to Atlassian’s published rules for customer security assessments, while on Jira Data Center your own infrastructure, network and access controls around the application are also in scope.
What is out of scope for a single-site Jira test?
We never test Atlassian’s own Cloud platform, shared infrastructure or another customer’s instance, and on Jira Cloud we do not run denial-of-service, flooding or social engineering techniques, in line with Atlassian’s published rules. We test the projects, permission schemes, issue security, Marketplace apps and portals configured on your site, and a separate connected system such as your identity provider or Microsoft 365 tenant is scoped and quoted separately.
Does Atlassian have a customer security testing policy we need to follow?
Yes. Atlassian’s published Security Test Rules allow customers to run security assessments against their own Jira Cloud instance without needing prior approval, provided testing stays inside your own instance, any automated scanner output is triaged with a reproducible proof of concept before being reported, and prohibited activities such as denial-of-service and social engineering are excluded. We confirm the current version of Atlassian’s rules during scoping and test to them exactly.
Do you test installed Marketplace apps?
We review the scopes granted to installed Forge and Connect apps, including any app that connects Jira to SharePoint, OneDrive or another external system, as part of the standard engagement. Testing the third-party app’s own code or infrastructure, rather than the scope and access it has been given inside your site, is out of scope and is the Marketplace developer’s responsibility under Atlassian’s shared responsibility model.
Are your testers CREST certified?
Yes. Every Jira engagement is carried out by UK-based, CREST-certified testers, and your report and attestation letter are recognised by auditors and insurers accordingly.
20+ CREST-accredited testing services in one place
Web, mobile, API, cloud, AI, infrastructure, red team. Pick the test that fits your environment.
Get a fixed price for your Jira review
Jira runs on permission schemes, project roles and issue security levels that your admins configure project by project, and Jira Service Management adds a customer portal boundary on top of that. When a scheme gets copied across projects without anyone re-checking who it grants access to, or a portal fails to keep customers separate from agents, the gap sits in your configuration, not in Atlassian’s platform. We test your Jira Cloud or Data Center site: project and issue permissions, anonymous and public access, attachments, installed Marketplace apps, and the boundary between Jira Service Management customers and agents. CREST-certified testers, fixed price from £2,840 for a 2-day single-site scope, quoted within 24 hours.
