How to audit who can reach your JSM portal, desk by desk

[#1]

If you administer Jira Service Management, here is a question that is deceptively hard to answer: who can reach this service desk portal, and how did they get there? Access accrues quietly: customers get added desk by desk, organization memberships drift, agents arrive on the Service Desk Team role directly or through groups nobody re-checks, and deactivated accounts linger on the role after the person leaves. JSM ships no single screen that rolls all of that up per desk. This post explains why, how to assemble the picture natively, and where the manual route runs out.

🚪 Why there is no portal access report natively

Customer lists live in each project's settings, organization membership in its own screens, agent access inside project roles and group memberships managed elsewhere, and none of it is recorded over time. The one site-wide artifact, the portal-only customers export in user management, is a flat list of accounts with no mapping to which projects each one can actually reach.

Exporting this per project is one of the higher-voted open requests on the JSM issue tracker: JSDCLOUD-6160 ("Ability to export users and organization per projects") is under review with about 407 votes and 263 watchers as of this writing. Access reviews keep asking for a per-desk export, and the product does not have one.

🧰 What you can do with native tooling

You can assemble the matrix by hand, and on a site with two or three desks it is a workable afternoon:

• Customers per desk. Open each project's Customers page for the direct list, or query `GET /rest/servicedeskapi/servicedesk/{id}/customer` (it needs the experimental opt-in header).
• Organizations and their real membership. List a desk's organizations, then click into (or query) each one's members. This is where stale access hides: an org can stay granted while its membership drifts to zero or fills with people who left.
• Agents on the Service Desk Team role. Read the project's role actors and, crucially, note how each agent got there: a direct grant, or membership in a group whose contents are managed outside the project.
• Check who is still active. Verify each collected account is not deactivated; deactivated accounts still holding access are the finding auditors care about most.

The honest limits: the result is a point-in-time snapshot with no export, so for the next review you rebuild it and diff by hand, per desk. Group-granted access changes silently between passes, and nothing native tells you what changed since last quarter. On a dozen desks it becomes a standing chore, and the manual diff is where mistakes creep in.

🧭 One option that fills the gap: Portal Governance for JSM

Disclosure: I work for Katabarwa Labs, and we build a small app for exactly this gap, so treat this as one option among whatever you evaluate.

Portal Governance for JSM scans every service desk daily (and on demand) and builds the per-desk access matrix in one place: every customer with direct portal access, every organization grant with its membership rolled up, and every Service Desk Team agent classified by how the grant flows, direct or group.

On top of the matrix it raises exposure flags that point at real risk: deactivated accounts still on the Service Desk Team role, access flowing through drifting groups, organization grants with zero members, and portals exposing zero request types, each with a severity.

Every scan is diffed against the last, so drift (grants added or removed, desks appearing or vanishing) becomes a running record, and the full matrix exports as audit-ready CSV in one click, one row per grant with desk, channel, membership sizes, and flags: the export JSDCLOUD-6160 asks for.

Here is a short walkthrough of the app in action:

https://youtu.be/YwYZUOkP7zg

It runs entirely on Atlassian Forge (Forge functions, a daily scheduled rescan, and Forge storage) inside your own Jira Cloud tenant, so nothing leaves your instance. The scan and export path changes nothing. There is one opt-in write feature, honestly scoped: a cleanup that can remove deactivated accounts from customer lists and organizations, and emptied organization grants from desks. Every run previews as a dry run first, requires an explicit confirmation, and re-verifies each account is still deactivated immediately before removal. To be clear: it removes portal access only, never deactivates accounts, frees no license seats, and removal is recoverable since customers and organizations can be re-added at any time.

If a hand-built matrix once a year covers your desks, build it. If access review should be a lookup instead of a project, the listing is here: Portal Governance for JSM

If the export shape is not quite what your audit needs, tell us what that is and we will build it.