How to Audit Atlassian User Access for SOC 2 Compliance

[#1]

If your organization is working toward SOC 2 compliance - or maintaining it - user access reviews are one of the controls that comes up repeatedly. Specifically, SOC 2's Common Criteria (CC6.1, CC6.2, CC6.3) require that you demonstrate logical access controls: who has access to what systems, how access is granted and revoked, and how you periodically review that access is still appropriate.

For teams running Jira and Confluence, this means your Atlassian user access needs to be auditable, reviewable, and defensibly managed. This article covers what SOC 2 auditors typically look for in your Atlassian environment and how to build a process that satisfies those requirements without creating a quarterly fire drill.

What SOC 2 Auditors Look For

Auditors evaluating your Atlassian access controls will typically ask:

• Who has access? A current list of all users with access to Jira and Confluence, including their roles and group memberships.
• How is access granted? Documentation of your provisioning process - ideally tied to an identity provider (Okta, Azure AD) via SCIM.
• How is access revoked? Evidence that when someone leaves the organization or changes roles, their access is removed promptly.
• How do you review access periodically? Proof of regular access reviews - typically quarterly - where someone with authority confirms that each user's access level is still appropriate.
• What happens to inactive accounts? Evidence that dormant accounts are identified and addressed, not left with perpetual access.

The last two points are where most Atlassian admins struggle. Provisioning is usually handled by SCIM or IT onboarding workflows. But periodic reviews and inactive account management are often manual, inconsistent, and hard to document.

The Inactive Account Gap

SOC 2 auditors pay particular attention to accounts that have access but show no recent activity. An account that hasn't logged into Jira in six months but still has access to production project boards is exactly the kind of finding that generates an audit exception.

The challenge is that Atlassian doesn't provide a native "flag inactive users" feature. You can see last login dates in the admin console, but there's no automated workflow to act on that data. This means most organizations are either:

• Running manual quarterly exports, filtering by last login, and removing access by hand (time-consuming and inconsistent)
• Relying on SCIM deprovisioning alone (which only catches users disabled in the IdP, not users who are still employed but no longer need Jira access)
• Not addressing it at all and hoping the auditor doesn't dig too deep (risky)

Building an Auditable Access Review Process

Step 1: Establish an Access Policy

Document a written policy that defines:

• Who can approve Jira/Confluence access requests
• What the standard access levels are (product groups, project roles)
• What triggers access revocation (offboarding, role change, inactivity threshold)
• How often access is reviewed (quarterly is the SOC 2 standard)

This policy is what your auditor will reference. It doesn't need to be complex - a one-page document that your IT leadership has signed off on is sufficient.

Step 2: Automate Your User Inventory

Rather than manually exporting user lists each quarter, set up a process that continuously tracks who has access and when they last used it. This can be as simple as a scheduled script that queries the Atlassian Admin API, or a Marketplace app that maintains a live dashboard.

The goal is to be able to produce, at any moment, a report showing: every user with Jira/Confluence access, their group memberships, and their last active date. When your auditor asks for this, you should be able to generate it in minutes, not days.

Step 3: Define and Enforce Inactivity Thresholds

Pick a threshold (60 or 90 days is typical for SOC 2 environments) and enforce it consistently. "Consistently" is the key word - auditors look for evidence that the policy is applied uniformly, not just when someone remembers.

Automated enforcement is significantly easier to defend in an audit than manual enforcement. If you can show that a system automatically flags and removes inactive users on a daily schedule, with logs of every action, you have a strong control narrative.

Step 4: Maintain an Audit Trail

Every access change should be logged: who was added, who was removed, when, why, and by whom (or by what automated system). This trail is what transforms "we clean up users sometimes" into "we have a documented, enforceable access control with continuous monitoring."

Atlassian's built-in audit log covers some of this, but it doesn't specifically track inactivity-based removals or provide the summary view auditors prefer. Supplementary logging from your access management tooling fills this gap.

Step 5: Handle Unmanaged Accounts

SOC 2 auditors will flag any accounts that fall outside your standard governance. Unmanaged accounts (personal email addresses, contractor emails outside your verified domain) are a common finding. These accounts are invisible to SCIM and organization-level controls, but they still have access to your Jira projects and Confluence spaces.

Include unmanaged accounts in your access review scope. Document how you handle them, and ensure your removal process covers them alongside managed accounts.

Tooling That Helps

You can build a SOC 2-compliant access review process with manual exports and spreadsheets. But it's fragile, hard to sustain quarterly, and creates a burst of work before each audit period.

Marketplace apps that handle user lifecycle management can automate most of this: continuous activity monitoring, configurable inactivity thresholds, automated access removal, and audit logs. Full disclosure - I work on User Management Automation for Jira & Confluence, which covers these requirements across both Jira and Confluence in a single install, including unmanaged accounts. There are other approaches on the Marketplace as well - the important thing for SOC 2 is that whatever you use produces consistent, documented, auditable results.

What a Strong Audit Narrative Looks Like

When your auditor asks about Atlassian access controls, you want to be able to say:

• "We have a documented access policy with defined roles, approval processes, and inactivity thresholds."
• "Access is provisioned through our IdP via SCIM, and revoked automatically when users are disabled."
• "Inactive accounts are detected and removed automatically on a daily schedule with a 90-day threshold."
• "Unmanaged accounts are included in our access review scope."
• "Every access change is logged with timestamps, and we can produce a full access report at any time."

That's a significantly stronger position than "we do a quarterly spreadsheet review." And most of it can be automated once, then maintained continuously with minimal admin effort.

If you're preparing for a SOC 2 audit and have questions about how to structure your Atlassian access controls, happy to discuss in the comments.

[Jonas Nilsson]

Strong breakdown. The part that usually gets messy in Atlassian is not producing one export, it is explaining why a user is still billable when the same account may sit in default groups, secondary groups, or unmanaged-account edge cases.

For me the strongest control is not just a quarterly list, but a repeatable review record that ties the user, the billable path, the approver, and the exact cleanup action together. Otherwise the review exists, but the reasoning behind each removal is still scattered across notes and screenshots.