If you have read our previous article on what auditors look for, you already know where most access management processes fail. Requests arrive through informal channels. Approvals happen in chat and leave no trace. Access is never reviewed after it is granted. By the time an auditor asks for evidence, the team is reconstructing a history that was never recorded.

This article focuses on the solution. It walks through how to structure the access request process inside Jira Service Management Cloud – from intake forms and approval workflows to provisioning checklists and audit logs – so that evidence is produced automatically, as part of the normal workflow.

What Jira Service Management Offers for Access Management 

JSM Cloud is not marketed primarily as an access management tool, and it is not one. But it is a highly configurable service management platform with several capabilities that map naturally onto the access request lifecycle. The service catalog is where requests enter the system. What happens next – how requests are approved, tracked, provisioned, and recorded – is handled by a separate set of built-in features described below. 

How Service Catalogs Improve Access Request Management

A structured service catalog helps organizations standardize and scale access request management by providing a single entry point for all access-related requests. Through configurable forms, teams can capture key information such as the target application, permission level, business justification, and access duration, ensuring requests are complete and ready for processing from the start.

By creating a consistent access request process, service catalogs improve visibility, support faster decision-making, and reduce administrative overhead. This also makes it easier to apply approval policies and automate routing. Accurate records are maintained throughout the lifecycle, helping organizations improve both operational efficiency and governance. 

Building an Effective Access Approval Workflow

An effective access approval workflow ensures that access requests are reviewed by the right stakeholders based on system sensitivity, user role, and business requirements. By automating approvals and routing requests according to predefined rules, organizations can strengthen access governance, improve accountability, and reduce the risk of unauthorized access or segregation of duties violations.

Using SLA Management to Reduce Access Request Delays

Delayed approvals are a common bottleneck in the access request workflow, particularly in large organizations where multiple teams are involved.

SLA management in JSM lets you set a time limit for each step in the process. For example, a manager must approve a standard access request within 24 hours, and an IT administrator must provision access within 8 hours after approval. If either deadline is missed, JSM sends an automatic reminder to the responsible person. If the request remains unresolved, it escalates to their manager or a defined backup.

This means no request sits unnoticed in someone’s queue. The team always knows which requests are on time, which are at risk, and which are overdue – without anyone manually tracking the status.

Automating the Access Provisioning Process

Once an access request is approved, someone still needs to act on it. This step – actually granting the access in the target system – is called provisioning. In many organizations it happens manually: an IT administrator receives the approved ticket, logs into the relevant system, sets the correct permission level, and confirms the work is done. When this process depends on manual steps, mistakes happen. Access gets granted at the wrong level, steps get skipped, or the ticket sits unactioned for days because the right person was unavailable.

Automation reduces this risk. In JSM, approved requests can automatically assign a task to the right administrator, send a notification with the exact permissions to grant, and move the ticket to the next stage once the work is confirmed. Every step is logged automatically. The result is faster access delivery, fewer errors, and a complete record of what was done and when.

Creating an Audit Trail for Access Reviews and Compliance

A centralized audit trail provides the visibility needed for access reviews, compliance reporting, and internal audits. By recording approvals, workflow actions, status changes, and user activity, it creates a reliable record of access-related decisions and activities. This evidence becomes particularly valuable when preparing for regulatory reviews or external compliance assessments. 

How Atlassian Assets Adds Context to Access Requests

When using JSM alone, one problem remains. The request form shows what someone is asking for – for example, access to the company’s client database or an admin account in AWS. But it does not answer the more important questions: what kind of tool is this and how critical is it to the business? Who already has access to it? Will the new access create a conflict with other permissions this person already holds?

The approver sees the request but not the full picture around it. They do not know whether this is a standard tool used across the department or a system with restricted access. They do not know whether this person already has similar permissions in related tools. They simply click “approve” or “reject” without enough information to make an informed decision.

This is exactly the problem that Assets solves.

With Assets, you can model:

• Systems and applications as configuration items (CIs), with ownership, criticality, and classification attributes
• Roles and entitlement groups as CIs linked to the systems they govern
• Users as CIs or attributes, with their current access profile referenced from open and resolved tickets
• Relationships between roles – for example, which role combinations create segregation-of-duty conflicts

When an access request is raised in JSM, the requester selects a system from an Assets-linked dropdown. The form immediately has context: who owns that system (and should approve), what classification it carries, what roles exist, and what the standard approval path is. Approvers see the relevant CI data alongside the request – not in a separate tool, not after a manual lookup.

Post-provisioning, the access grant can be reflected in the CI record, giving you a living register of who has access to what, updated through the ticketing process itself.

This is not a full-featured identity governance platform. But it is a significant step above a spreadsheet or email thread – and for many organizations, it is the right incremental improvement.

Before You Configure: Key Decisions to Make First 

The most common failure mode in JSM-based access management is configuring the tool before defining the process. The result is a workflow that reflects existing ambiguity rather than resolving it.

A few things are worth settling before the first workflow is built:

Define your access categories. Not all access requests are equal. Routine access to a shared drive is different from privileged access to a production database. Different categories need different approval paths, SLAs, and evidence requirements. Get agreement on this before configuring request types.

Agree on who approves what. The approval matrix – which role approves access to which systems, at which permission level – needs to be a governance decision, not an assumption in the tool configuration. If this is left implicit, approvals will be inconsistently routed and your audit evidence will be incomplete.

Invest in the Assets data model. A CMDB is only useful if its records are accurate. Before linking Assets to your access workflows, ensure that your system and role CIs have current owners, correct classifications, and meaningful relationship data. Start with the systems that appear most frequently in access requests, and expand from there.

Treat the ticket as the record. One cultural shift that matters: access decisions should live in JSM, not in email. Approvals should be captured directly within JSM to maintain process consistency and accountability. Establish early that the ticket is where decisions happen, not where they are documented after the fact.

Building an Access Management Workflow in Jira Service Management 

A well-configured access management process in JSM Cloud typically covers four stages.

Access Request and Intake Process 

The requester submits a structured form through the service portal. The form captures the target system (linked from Assets), the requested permission level, the business justification, and any time limitation. Automation validates completeness and routes the ticket to the correct approval queue.

Access Approval Workflow and Governance Controls 

Once submitted, requests move through an access approval workflow designed to enforce governance requirements. Depending on the sensitivity of the system, approvals may be required from a line manager, application owner, or security representative. JSM helps organizations strengthen access governance by ensuring approvals follow a defined sequence and are supported by the necessary context and supporting information. 

Access Provisioning and User Access Confirmation 

After approval, access is granted by the IT team or system administrator – the provisioning step described earlier. Structured checklists and automated task assignments help ensure this is done consistently and according to policy. Once complete, the requester is notified and the access record can be updated within Assets. 

Access Reviews and Access Revocation

Long-term security depends on regular access reviews and timely removal of unnecessary permissions. JSM automation can support periodic user access reviews, trigger recertification activities, and initiate offboarding workflows when employees leave the organization. This helps transform access review from a manual audit exercise into a continuous access governance process.

Closing Thoughts

JSM Cloud does not make access management compliant on its own. The workflows need to reflect real business rules, the approval logic needs to be agreed upfront, and the review cycles need to be defined before the first ticket is created. But when that foundation is in place, the system maintains the evidence automatically – every day, not just before an audit.

The work is in the design, not the technology.

If you are starting from scratch, the most practical first step is to map your three to five most common access request types and define who should approve each one. That decision alone shapes everything else – the form fields, the routing logic, the SLA thresholds, and the audit trail. Once that is clear, the configuration follows naturally.

Not sure where to start? Our team configures JSM-based access management end to end – so you get a working process, not just a tool. Contact us to get started.