Everything Certia does, and how to use it

Overview

Companies that hold SOC 2 or ISO 27001 certification (or want to) have to periodically prove that every person's access to their systems is still needed — a periodic access review. Today that's usually a manual fire drill: someone exports a spreadsheet of users and groups, emails it to managers, and under deadline pressure "still needs it?" quietly becomes "approve all." The result technically satisfies the audit checklist but doesn't actually catch stale access, and leaves no real trail an auditor can trust.

Certia runs that same review inside Jira instead. An admin scopes a campaign (who's being reviewed, by whom, by when); Certia pulls each person's groups, roles, and activity, and computes risk flags automatically; each reviewer sees their people with full context and an AI-suggested "safe" or "needs review" tag, and clicks Keep, Revoke, or Escalate with a required note; Certia chases anyone who hasn't acted; and at the end it produces a certified, tamper-evident report mapped to the specific SOC 2 and ISO 27001 controls an auditor actually checks.

A few terms come up throughout this documentation — knowing them up front makes everything else easier to follow:

Roles: Admin vs. Reviewer

Certia has exactly two roles. The same person can be both — for instance, a manager who also runs the compliance program — but what each role can see and do is kept strictly separate and checked on the server every time, not just hidden in the interface.

Admin

Creates and runs campaigns from a dedicated screen in Jira's admin settings ("Access Review Admin"). This requires your Jira site's ADMINISTER permission — the same permission that controls Jira's own admin settings generally. Every admin action (creating a campaign, listing the full user directory, opening a certified report) re-checks this permission on the server for whoever is actually calling it, rather than assuming a request came from someone who's allowed to see the admin screen. An admin can see every campaign at the site, the full user/group directory, and every certified report.

Reviewer

Decides Keep/Revoke/Escalate for the people assigned to them. A reviewer needs no special Jira permission at all — the moment an admin assigns you at least one review item, a My Reviews entry appears in Jira's main navigation with your queue already populated. A reviewer can only ever see and act on the review items actually assigned to them, never anyone else's — this is enforced on the server, not just by what the screen happens to show.

Getting started

Requirements

• A Jira Cloud site. Certia is a Forge app and does not run on Jira Server/Data Center.
• Confluence is optional. If your site has it, Certia also scans Confluence space permissions in the background to catch direct grants there (see Core concepts). If it doesn't, that step is skipped automatically with no error and no missing functionality on the Jira side.
• To create campaigns, you need Jira's ADMINISTER permission on the site (see Roles).

Installing

Install Certia from the Atlassian Marketplace the same way as any other Jira Cloud app — from your site's Manage apps page. Installing an app itself requires Jira admin access.

First time in the app

As an admin: open Access Review Admin from Jira's admin settings. The first time, you'll see an empty campaign list and a Create campaign button — see Creating a campaign to get started.

As a reviewer: nothing appears until an admin assigns you to a campaign. Once they do, My Reviews shows up in Jira's main navigation on its own.

Core concepts

A handful of ideas explain almost everything about how Certia behaves. Understanding these up front makes the rest of the app predictable rather than surprising.

A campaign goes active immediately

There's no separate draft or launch step. The moment an admin saves a new campaign, it's active, reviewers are notified, and decisions can start coming in. Scope can't currently be edited after creation — see FAQ.

The snapshot is point-in-time, not live

When a campaign is created, Certia captures each subject's groups, roles, last-active signal, and risk flags at that moment and stores it as part of the review item. If that person's real Jira access changes the next day, the review item still shows what was true when the campaign started. This is deliberate: it's what makes the eventual report a credible record of a specific point in time, rather than a live query that could quietly change underneath an auditor reading it later.

Group membership vs. direct grants

Some access is granted by putting someone in a group; some is granted straight to a person — a direct Jira project-role assignment, or a direct Confluence space permission — bypassing any group entirely. A campaign scoped to "review this group" would normally miss the second kind of person completely, since they were never a member of anything. Certia scans for both, so a group-scoped campaign also catches anyone who holds the exact same access directly.

Blast radius

For access granted through a group, Certia also records everything else that same group controls — every other project role or space permission it's tied to. A reviewer sees this before deciding, so revoking someone's group membership never comes as a surprise about what else it also takes away.

Sensitivity marking

At campaign setup, an admin can mark specific groups, Jira projects, or Confluence spaces as higher-risk for that campaign. This isn't a permanent registry — it's chosen fresh each time. Anyone whose access touches a marked resource gets a visible "Sensitive" flag and is sorted to the top of their reviewer's queue, ahead of automated risk flags.

Previous decision

If the same person was reviewed in an earlier campaign, their review item shows what was decided last time (and by whom, and when) — so a reviewer isn't starting from zero on someone reviewed just last quarter.

Audit log vs. notifications

These sound similar but serve different purposes. The audit log is permanent — every decision, reminder, and escalation is recorded there forever, and it's what the certified report is actually built from. A notification is transient — it's what a specific person currently sees on their own screen (a reminder banner, an escalation banner), and it can be dismissed or can stop showing once the thing it describes is resolved. Losing track of a notification never loses the underlying evidence; that only ever lives in the audit log.

Creating a campaign (Admin guide)

Full walkthrough of scoping and launching a new access-review campaign.

1. Open Access Review Admin from Jira's admin settings, and click Create campaign.
2. Name the campaign and set a due date.
3. Choose scope: by one or more groups, or by individually picked people. Either way, Certia's direct-grant scan (see Core concepts) folds in anyone with equivalent access granted directly, so scope is never limited to literal group membership.
4. Optionally mark specific groups, Jira projects, or Confluence spaces as sensitive for this campaign.
5. Assign reviewers — either one reviewer per selected group, or one reviewer per selected person.
6. Save. The campaign is active immediately and every assigned reviewer's "My Reviews" queue populates right away.

Behind the scenes, saving a campaign does three things at once: it takes the point-in-time snapshot for every subject, generates one review item per (subject, reviewer) pair, and sends a batched request to Certia's AI classifier so reviewers see a "likely safe" / "needs review" tag from the first moment they open their queue (see AI-assisted classification).

Completing a review (Reviewer guide)

Everything shown and every action available on the "My Reviews" screen.

What you see, per person

• Their groups, roles, and last-active status (or a plain "no recent activity data" label if that signal isn't available — Certia never guesses at one).
• Any automated risk flags — see Risk flags reference.
• How they got their access: a tag for group membership, a separate tag for anything granted directly, and a warning line if revoking a group membership would also remove access to other things (blast radius).
• The AI's "Likely safe" / "Needs review" / "Unclassified" tag, with its one-line reason always shown — never hidden behind a hover.
• A "Sensitive" badge if an admin marked this campaign's access as higher-risk in a way that applies here.
• An "Active" or "Deactivated" badge for the subject's current Jira account status.
• What was decided about this same person last cycle, if anything.

Filtering and finding people

Search by name, or filter by AI tag (All / Needs review / Likely safe / Unclassified — only shown when at least one item actually matches). The list itself is sorted with the people who most need attention first: sensitivity-flagged, then risk-flagged, then AI "needs review," then everyone else, alphabetically within each group.

Making a decision

Click Keep, Revoke, or Escalate — all three are shown with equal visual weight on purpose, so nothing nudges you toward any one of them. Every decision opens a note prompt; a written reason is required for all three, Keep included, since a bare "kept" with no explanation is exactly as unhelpful to an auditor as a bare "revoked" would be.

You can change a decision at any time up until the campaign's due date. After that, decisions lock — the item still shows what was decided and its note, but the action becomes "Deadline passed — locked" instead of an editable choice.

AI-assisted classification

Every review item gets an automatic "Likely safe" or "Needs review" suggestion the moment a campaign is created, so reviewers can prioritize their attention instead of reading every item with equal weight.

What's sent, and what isn't

Only four things are sent to the AI model for classification: group names, role names, days since last active, and the computed risk-flag labels. The subject's name, email address, and Jira account ID are never sent — the AI classifier never receives anything that identifies who the person actually is.

The three tags

• Likely safe — nothing about this access pattern looked unusual.
• Needs review — something about it (inactivity plus admin rights, for instance) is worth a closer look, with a plain-language one-line reason attached.
• Unclassified — the classification didn't happen (the AI service was unavailable or returned an unparseable response). This never blocks campaign creation; an item simply stays unclassified rather than the whole campaign failing.

Reclassifying

If a campaign has unclassified items (for example, because the classification key wasn't set up yet when it was created), an admin can bulk-retry all of them at once from the Report view's "Reclassify unknown" button — a single batched call, not one request per item.

Reminders & escalation

Certia checks once a day for anyone who still has work to do, so an admin doesn't have to manually chase reviewers.

Any reviewer with pending items in an active campaign gets a single in-product reminder banner the next time they open Jira — one banner covering every pending item in that campaign, not one per item. If a campaign passes its due date with anything still pending, its admin (whoever created it) gets an escalation banner naming how many reviews are stuck and across how many reviewers.

Delivery is in-product only — Certia doesn't send email today.

A banner can be dismissed directly, and separately, it stops showing on its own once the thing it describes is actually resolved (the reviewer finished their pending items, or the campaign is no longer overdue) — it doesn't need to be manually cleared just because the underlying issue went away. A fresh reminder/escalation will still appear the next day if the same issue is still real.

The certified report

The document a SOC 2 or ISO 27001 auditor actually reads — available to admins from each campaign's Report view.

What it contains

• Every subject, their reviewer, the decision made, and the note behind it.
• How each subject's access was granted (group membership vs. a direct grant), and whether it touched something marked sensitive.
• Whether the subject's account was already deactivated at the time of review.
• Each subject's last-active status.
• A section mapping the review directly to SOC 2 CC6.1–CC6.3 and ISO 27001's access-control requirements — see Compliance framing.
• A scope-completeness statement: how many of the site's total Jira users were actually in scope for this specific campaign.
• Explicit reviewer-attestation language, stating plainly what recording a decision actually required (an authenticated reviewer, a required note).
• A "Proof of revocation" section for every Revoke decision, with the exact caveats that apply to it (see below).
• A sha256 integrity fingerprint computed over the campaign's full audit log, plus a "Verify this report" tool that recomputes it later so you can confirm the underlying record hasn't changed since the report was generated.

Interim vs. completed

You can open a campaign's report before every item has a decision — it's clearly labeled as an interim status summary rather than a finished certification, so it's never mistaken for a completed record. A campaign is marked completed automatically the first time every item in it has a decision and its report is opened — there's no separate "mark complete" action.

What "proof of revocation" actually proves

Exporting

A campaign's report can be exported as CSV for pivoting/filtering yourself, or captured as a deterministic PDF (not a raw browser print — it's paginated to match the actual document). A separate Print button is also available for a physical copy.

Risk flags reference

Every risk flag is computed automatically when a campaign is created — none of these are set by a person. They're prompts to look closer, not a verdict.

Separately, you may see "No recent activity data" instead of a last-active date. That's a deliberate label, not a bug — it means the activity signal is missing or unreliable for that person, and Certia would rather say so plainly than guess at a date that might be wrong.

Warnings & alerts reference

Every distinct warning, badge, or alert you might encounter anywhere in Certia, and exactly what each one means.

Compliance framing

Precise, deliberately unglamorous language about what Certia actually proves.

Certia helps satisfy the periodic access review requirement of:

• SOC 2 Common Criteria CC6.1, CC6.2, CC6.3 — logical access controls: who has access, how it's granted and revoked, and periodic review of that access.
• ISO 27001's access-control requirements (Annex A).

One more distinction worth being precise about: recording a Revoke decision is evidence that a reviewer decided access should be removed — it is not, on its own, proof that the access was actually removed from Jira or Confluence. See The certified report for exactly how the report handles this.

Data & security

A short summary — the full, binding detail lives in the linked policies below, not duplicated here.

• Certia runs entirely on Atlassian Forge. There are no separate servers or databases outside Atlassian's own platform.
• Stored data includes: campaign metadata; each reviewed person's snapshot (name, groups, roles, last-active signal, risk flags, direct grants, prior-cycle decision, sensitivity flags); every decision and its required note; and a permanent audit log.
• Email addresses are read but never stored. They're used transiently to compute one derived signal — the "external domain" risk flag — and then discarded.
• Nothing leaves Atlassian's cloud. AI classification runs on Atlassian's own hosted AI (Forge LLMs), and even that receives only a narrow slice (group names, role names, days-since-active, risk-flag labels) — never a name, email, or Jira account ID. See AI-assisted classification.
• Data persists for the life of your subscription and is deleted within 30 days of uninstalling.

Full detail: Privacy Policy, Data Processing Agreement, and Security Policy.

Business use cases

Concrete situations Certia is built to handle.

• Quarterly (or annual) SOC 2 access reviews for a company already pursuing or maintaining SOC 2 Type II — the recurring evidence an auditor expects to see every cycle.
• Annual ISO 27001 access-control reviews, covering the same underlying Annex A requirement.
• Offboarding verification — confirming a departed employee's access was actually revoked, not just that their account was deactivated. Certia treats these as related but distinct facts (see the Deactivated badge in Warnings & alerts reference).
• Privileged/admin-access audits — a focused campaign scoped just to admin-level groups, run more often than a full org-wide review.
• Evidence for a customer's security questionnaire or vendor risk assessment, where "how do you review access?" is a standard question with a real, demonstrable answer.
• Atlassian Marketplace vendors reviewing their own access — Marketplace partners are themselves required to hold SOC 2 or ISO certification, making this one of Certia's own first intended audiences.
• Any compliance-minded team replacing a spreadsheet-and-email process that technically checks the audit box but doesn't produce anything a skeptical auditor would actually trust.

FAQ & troubleshooting

Why don't I see "My Reviews"?

It only appears once an admin has assigned you at least one review item. If you expect to have been assigned, check with whoever's running the campaign.

Why is a reminder or escalation banner still showing?

It re-checks whether the thing it describes is still true every time the page loads, and clears on its own once it isn't (see Reminders & escalation). You can also dismiss it directly. If it keeps coming back, the underlying issue (pending items, an overdue campaign) is genuinely still open.

Why is some Confluence data missing from my campaign or report?

Two different reasons look similar but aren't: if your site simply doesn't have Confluence enabled, this is expected and nothing is wrong — Jira-side data is unaffected. If Confluence is enabled, look for the "Confluence scan incomplete" warning icon on the campaign (see Warnings & alerts reference) — that means a real, one-time scan failure, not a permanent limitation.

What does "interim report" mean?

The campaign isn't fully decided yet — the report reflects in-progress status only, and is clearly labeled so it's never mistaken for a finished certification.

Can I edit a campaign's scope after creating it?

Not in the current version — scope, due date, and reviewer assignment are set at creation. Plan the campaign's scope carefully before saving it.

A reviewer left the company mid-campaign — can I reassign their items?

Not yet from inside the app. The certified report will flag any reviewer who went inactive with items still pending, so it's never silently mistaken for the reviewer ignoring their queue — but actually reassigning those items today is a manual, outside-the-app step.

Does clicking "Revoke" actually remove the person's access?

No. It records the reviewer's decision, with a required note, as evidence for your audit trail — it does not call out to Jira or Confluence to remove anything itself. See The certified report.

Support

Questions, bugs, or anything unclear in this documentation: [email protected].