How to Audit Atlassian Cloud Activity Without Atlassian Guard

The question usually arrives during an ISO 27001 or SOC 2 audit: "Show us who changed permissions in Jira over the last quarter." You open Atlassian's admin console, find the audit page, and discover the data is scattered per product, hard to filter, and even harder to export in a form an auditor will accept.

The reflexive answer is to buy Atlassian Guard. Sometimes that's right. But a surprising amount of audit capability is already included in standard Cloud plans — if you collect it properly. This guide maps what's available without Guard, what genuinely isn't, and how to turn the available parts into a unified, exportable audit trail.

The landscape: what you have vs. what Guard adds

Working backward from what an auditor actually asks for, the requirements are: who did what, where, when — across all products — with an export you can hand over. Here's how the pieces line up on a standard Cloud plan:

The hidden factor most teams overlook: the gap isn't mainly about missing APIs — it's about fragmentation. Four products, four API shapes, four retention behaviours, no cross-product view of a single person's actions. An auditor's question spans products; the native tooling doesn't.

The approach: pull everything into one store you control

AtlasLens (Apache 2.0, self-hosted) was built for exactly this gap. It runs two ingestion pipelines — one for security/forensics (audit logs), one for productivity (content and activity) — and normalises everything from Jira, Confluence, Bitbucket, and JSM into a single event store with a unified dashboard on top.

Design decisions that matter for audit use:

• Incremental, cursor-based sync with idempotent upserts — no duplicates, no data-loss windows, and you keep history beyond whatever the product UIs choose to show.
• Identity resolution — Atlassian account IDs are resolved to people across products, so "what did this person do" has one answer, not four.
• Honest gaps — where Guard-only data is missing (sign-in events, Bitbucket audit), the Security view says so explicitly instead of leaving a silent hole. Auditors respond well to documented limitations.
• Compliance posture built in — email identifiers encrypted at rest, append-only storage, 1-year retention enforced by TTL index, bcrypt-hashed admin accounts.

Step 1 — Try it with synthetic data first (2 minutes)

You can evaluate the entire dashboard without touching your Atlassian instance:

docker compose -f docker-compose.demo.yml up --build
# open http://localhost:8080  →  log in as  admin / atlaslens-demo

This seeds ~4,000 synthetic events across all four products, so Overview, Productivity, Security, Timeline, and Work Items are fully populated. Tear it down with docker compose -f docker-compose.demo.yml down -v.

Step 2 — Connect your real instance

# Start MongoDB
docker compose up -d mongo

# Install the backend
pip install -e ".[dev]"

# Provision an admin account (there is deliberately no signup page)
python -m atlaslens.cli.seed_admin --username admin

# Run the API and frontend
uvicorn atlaslens.api.main:app --reload
cd frontend && npm install && npm run dev

Copy .env.example to .env and add your Atlassian API credentials. For production, a Helm chart deploys backend, frontend, and optional MongoDB to Kubernetes — chart and images are public on GHCR (oci://ghcr.io/lithastra/charts/atlaslens), with secrets passed via your own values file or an existing Secret.

Step 3 — Answer the auditor's questions

Once the connectors have synced (you can trigger a sync on demand and watch per-connector progress live), the questions that used to take a day of CSV wrangling become filters:

• "Who changed permissions last quarter?" — Security & Forensics view, filtered to permission/group operations and the date range.
• "Show all sensitive operations by this contractor." — User Timeline: one chronological stream of that person's actions across Jira, Confluence, Bitbucket, and JSM.
• "Give us the evidence file." — Reports & Export: CSV or PDF of the filtered view, stamped with event count, SHA-256 hash, filter criteria, and timestamp, so the export itself is verifiable.

When you still need Guard

To keep this even-handed: if your auditor requires authentication events (sign-ins, MFA changes) or Bitbucket audit logs, those APIs only exist behind Atlassian Guard — no third-party tool can conjure them. The pragmatic pattern many teams land on: cover everything else with a self-hosted collector, and let the sign-in requirement alone drive the Guard decision instead of buying it for capabilities you already had.