Auditor portal

Run the audit inside Joopler instead of over email. An auditor gets a single home for every client they review; each engagement is scoped, time-boxed, logged, read-only, and clipped to the audit window. This page covers both sides: how an auditor works, and how a customer grants access.

For auditors

Your engagements (the hub)

Signing in lands you on Your engagements - every client that has invited you, across firms, in one list. Each card shows the framework, the audit window, whether you have accepted, plus signals like open evidence requests or a new client reply. Open one to review it; if you audit several clients, switching between them here moves you from one to the next without signing out.

The review workspace

Opening an engagement drops you into that client's workspace, framed with a persistent Reviewing: <Client> banner so you always know which client you are in and that your access is read-only. The work is organized into tabs:

• Overview - the frameworks in scope and live control posture (pass / fail / pending / not-applicable), each manual control linked to the exact signed attestation or applicability determination.
• Policies - every published policy; open one for the read-only signed document, its full version history, and the controls it maps to.
• Evidence - the tamper-evident ledger, clipped to your audit window so you only see artifacts captured in-period. Each is KMS-signed, RFC-3161 timestamped, and hash-chained; download any bundle and verify it yourself at /verify.
• Requests - the Prepared-By-Client (PBC) workflow (below).
• Messages - a bi-directional thread with the client; posting emails them.
• Report - per-framework readiness with the requirement-to-control crosswalk, the same roll-up the client sees, plus OSCAL export.

Everything is scoped to that one client, window-clipped, and read-only.

Accept the engagement

An engagement is bilateral: after a client invites you, you accept it (with an optional independence attestation) from the workspace before it counts as active. The accept step shows a quick snapshot of what you are taking on - framework, readiness, controls, policies - and the client sees the engagement flip from Pending to Accepted.

Ask for more time or another reviewer

You never manage your own access - you ask, and the client approves. From the engagement Overview:

• Request more time - if the audit runs longer than planned, ask to extend your access end date. Your access is a forward-looking time-box (separate from the audit window, which is the observation period being reviewed and is usually in the past), so it ends on its own unless extended.
• Request a colleague - ask the client to add another reviewer from your firm by email. On approval they get their own invitation to join.

Each request shows its status (awaiting client / approved / declined); the client is emailed when you raise one, and you are emailed the moment they decide. Approving applies the change automatically - the extension takes effect, or the colleague is invited - so nothing needs a second round trip.

Export

Download export from the workspace gives you one comprehensive, machine-readable bundle for the engagement - control posture, policies, the window-clipped evidence index, and OSCAL 1.1.2 (catalog, System Security Plan, Assessment Results) - so your own tooling can ingest it rather than re-keying anything.

Firm accounts: admins and users

An audit firm can be multi-user. A firm admin manages the firm in the partner portal - the firm profile and address, the outbound webhook, the API tokens, and the user roster (invite / promote / remove). A firm user simply reviews the engagements assigned to them. Both are reached from the auditor left nav (Firm, admins only), alongside Certification (become Trained on Joopler / a Joopler Certified Auditor) and the Partner API for headless access.

For customers

Engage a firm, and let the firm staff it

You buy an audit firm, not a named individual, and when you sign an engagement you usually do not yet know which of their people will do the work. So you do not have to guess a name to get started: engage the firm, set the access expiry and the audit window, and the firm assigns one of their own.

The chain is deliberate:

1. You authorize the firm. This grants nothing on its own - it is a request, and it carries no access.
2. The firm names someone, from their own roster, in their partner portal or over the Partner API. That is what mints the actual auditor invitation.
3. You see who they named, and can revoke them like any other auditor.

You set how long and how much; the firm chooses who. If the firm declines, or nobody is assigned, no access ever existed to clean up.

Naming an individual directly still works exactly as before, for when you already know who is doing the audit.

Grant access

Invite your auditor and grant them a scoped, time-boxed view. Their access is read-only, limited to what the audit needs, clipped to the audit window, and every action is logged. Accepting the emailed invitation adds them to your workspace and lands them in the auditor portal; until they accept, the engagement shows Pending, flipping to Accepted once they confirm, so you always know whether they are actually in.

Access ends on its own at the expiry you set - no cleanup needed. The audit window is a separate thing: it scopes which evidence they see (the observation period), not how long they can sign in. When the audit is done, click End engagement to cut access immediately (it also removes their workspace membership, so a former auditor never lingers as a plain member).

Requests from auditors

Auditors do not extend their own access or add their own colleagues - they ask, and you approve. Open requests appear in Requests from auditors on the auditor panel:

• More time - approve to extend that auditor's access end date (you can approve a different date than requested).
• Add a colleague - approve to send that colleague their own invitation; declining changes nothing. Approval only ever grants access by sending a real invitation, so an approved colleague always has a genuine way in.

You are notified when a request comes in, and the auditor is emailed your decision.

Prepared-by-client (PBC) requests

The back-and-forth runs as tracked requests, not a shared inbox:

1. The auditor raises a request - a piece of evidence, or a sample of a given size from a control's population.
2. You fulfill it in-app with the attachment or the sampled items.
3. The auditor accepts or rejects each one, and the whole exchange stays on the record.

The result is an audit with a complete, timestamped trail of who asked for what, what was provided, and what was accepted - and an auditor who can verify every artifact without taking the platform's word for it.

Programmatic access

Everything an auditor can do interactively is also available headlessly over the Partner API with a firm token: list pending vs active engagements, accept one, pull the export / OSCAL / evidence, run the PBC and message workflows, and raise engagement requests (more time / add a colleague). Deciding a request is the client's action, so it is intentionally not on the firm token.