Atlassian Permission Assessment

Who can actually do what in your Atlassian?

In two weeks we find admins who shouldn't be, technical users without an owner and tokens that never expire. You get a risk rating with blast radius and a ready-made remediation backlog in your Jira.

Module 1

Roles and outliers

We derive a simple role model from your groups and show who deviates from it: admins outside the internal groups, freelancers with internal rights, orphaned admin groups from the Data Center migration and unused licences.

Module 2

Technical users and blast radius

We find every technical account, app and agent, show what each can reach and answer two questions: what could an attacker do with its credentials, and what breaks if the account disappears or the person behind it leaves?

Module 3

Key rotation

For every token: where it is stored, where it is used, when it expires and who rotates it. Personal tokens doing machine work are flagged as candidates for a dedicated technical user.

Module 4

Audit-log analysis

We analyse up to 180 days of audit log: permission grants, deletions, exports, new tokens, app installs, activity at night or from unusual locations, and actions by suspended users.

What you get

Interactive dashboard

All findings on one page, ranked and filterable by risk.

Risk list mapped to ISO 27001

Each risk with rating, evidence and a mapping to the access and identity controls.

Proposed role model

A few clear roles, derived from your current groups.

Remediation backlog in your Jira

Every action as a ticket with owner and due date, ready to work on.

In two weeks

How the assessment works

1
Step 1

Kick-off and access

We agree the scope. You create a time-limited read-only key; we change nothing in your system.

2
Step 2

Inventory

Users, groups, product access, admin roles and the audit log are exported.

3
Step 3

Analysis

Role model, outliers, technical users, blast radius and key rotation.

4
Step 4

Audit-log scan

Find unusual actions and verify them with your admins.

5
Step 5

Report

Dashboard, risk list and actions as tickets in your Jira.

6
Step 6

Readout

Workshop with IT leadership and admins. Afterwards we revoke the key.

Then, permanently

XAAM keeps the order once the assessment has created it

XAAM proposes the rights new employees need from your org chart and roles, and runs requests, approvals and offboarding through Jira Service Management, so the deviations don't grow back.

Also for Google Workspace

The same question for your files: the Google Drive Security Assessment

Who can see which files, which shares go outside, and which accounts have too many rights? The Google Drive Security Assessment answers this for your Workspace.

Frequently asked questions

No. You create a time-limited read-only key for your organisation. After the readout we revoke it together.

No. We record only metadata: name, owner, storage location, where it's used and expiry. We never read or store token values.

No, the assessment is read-only. Your admins carry out the clean-up, or we support you in a separate sprint.

Yes. In the cloud we use the admin API and the organisation audit log; on Data Center, database exports and the instance audit log.

Once a quarter or before every ISO audit. Repeats are much shorter because the role model is in place.

Two weeks elapsed, about six person-days for up to 2,000 accounts.

Better call XALT

Request the assessment

Tell us how many Atlassian accounts you have and whether you run Cloud or Data Center. We'll get back to you with a kick-off date.

XALT Business Consulting GmbH needs the contact information you provide to us to contact you about our products and services. You may unsubscribe from these communications at any time. For information on how to unsubscribe, as well as our privacy practices and commitment to protecting your privacy, please review our Privacy Policy.

Before your next audit

Know who can do what before the auditor asks

Two weeks, read-only access, a ready-made backlog.