> ## Documentation Index
> Fetch the complete documentation index at: https://docs.regentra.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Audit Requests (IRLs)

> Track auditor-issued information requests through a NOT_READY → INTERNAL_REVIEW → AUDIT_READY → APPROVED / FLAGGED workflow with linked evidence, comments, and per-control scope.

The **Audit Requests** module is Regentra's Information Request List
(IRL) workflow — the inbox-style queue auditors and operators use to
work through every "send us X" ask during a fieldwork window. Each
request is a discrete piece of evidence collection with a status, an
owner, a deadline, and an audit trail.

## Finding it in the sidebar

Open the Compliance module and click **Audit Requests** in the left
sidebar. Direct URL: `/compliance/audit-requests`.

The Compliance sidebar is long. Audit Requests sits below the controls
section under a small uppercase caption that reads
**EVIDENCE & REPORTING** — the caption is a visual divider, not a
clickable group. The siblings under the same caption are
*Control Tests*, *Audit Periods*, *Issues*, *Reports*,
*Evidence Collection*, *Questionnaires*, and *Audit Trail*.

If you can't see Audit Requests at all, you're probably in the **PSA**
module — switch to **Compliance** in the top-left module switcher.

## When to use this vs. compliance issues

| You want to…                                  | Use…                                             |
| --------------------------------------------- | ------------------------------------------------ |
| Respond to an "auditor asked for X" item      | **Audit Requests**                               |
| Track a finding you have to remediate         | [Compliance Issues](/compliance/audit-lifecycle) |
| Capture a quarterly access-review attestation | [Access Reviews](/compliance/access-reviews)     |
| Define the audit window, scope, and Type 1/2  | [Audit Periods](/compliance/audit-lifecycle)     |

Audit Requests live *underneath* an Audit Period, and an individual
request may pull evidence from any of the others. They are the
operational surface for "what does the auditor want next?"

## Request types

| Type            | What it represents                                                                        | Typical evidence                                |
| --------------- | ----------------------------------------------------------------------------------------- | ----------------------------------------------- |
| **Document**    | A policy, contract, log export, screenshot, signed acknowledgment                         | Files or links attached directly to the request |
| **Test**        | A control test result — e.g. "show me 5 randomly sampled new-hire access reviews from Q1" | Linked test results + sampling notes            |
| **Observation** | The auditor needs to watch the control operate (live screen share, walkthrough recording) | Calendar invite + recording link                |
| **Inquiry**     | A question the auditor wants answered in writing                                          | Reply text + supporting attachments             |

## Status workflow

Every request moves through a five-state machine. Three are working
states; two are terminal.

```
NOT_READY → INTERNAL_REVIEW → AUDIT_READY → APPROVED
                                          ↘
                                            FLAGGED → (loops back to NOT_READY or INTERNAL_REVIEW)
```

| Status               | Who sees it        | What it means                                                                                                              |
| -------------------- | ------------------ | -------------------------------------------------------------------------------------------------------------------------- |
| **NOT\_READY**       | Operator only      | Just created; the owner is still gathering evidence. Auditor cannot see the request.                                       |
| **INTERNAL\_REVIEW** | Operator only      | Evidence is attached; a second person on the customer side is checking it before sharing. Still hidden from the auditor.   |
| **AUDIT\_READY**     | Operator + auditor | Visible to the auditor through their token-scoped portal. Auditor reviews; their decision is the next status.              |
| **APPROVED**         | Operator + auditor | Terminal accepted state. The auditor signed off and the request is closed.                                                 |
| **FLAGGED**          | Operator + auditor | Auditor needs more or different evidence. The request loops back to the operator with the auditor's comment as the reason. |

The "INTERNAL\_REVIEW before AUDIT\_READY" step is the same idea as
PR review on a code change — your second pair of eyes catches "this
screenshot has another customer's name in it" before the auditor sees
it. It is optional but strongly recommended.

A FLAGGED request is not a finding. It is a *retry* — the auditor said
"that's not quite what I asked for; try again" and the customer can
add evidence, push it back to AUDIT\_READY, and continue. Findings live
on [Compliance Issues](/compliance/audit-lifecycle).

## Cadence (recurring requests)

Requests can be one-time or recurring:

| Cadence       | Use case                                                                  |
| ------------- | ------------------------------------------------------------------------- |
| **ONE\_TIME** | The default — "show me the most recent BCP test result"                   |
| **MONTHLY**   | Continuous-monitoring evidence — "monthly user-access review attestation" |
| **QUARTERLY** | Quarterly access reviews, change ticket samples                           |
| **ANNUAL**    | Annual penetration test, annual policy review attestation                 |

A recurring request automatically respawns a NOT\_READY copy on its
cadence so the owner can begin collecting next cycle's evidence without
the auditor having to re-issue the ask.

## Creating a request

<Steps>
  <Step title="Open Audit Requests">
    **Compliance → Audit Requests** in the sidebar, then click **New Request**.
  </Step>

  <Step title="Link to an audit period (recommended)">
    Pick the audit period this request belongs to. The period scopes
    deadlines against the audit window so dashboard counters are
    accurate. Leave blank for internal prep work outside any active
    audit.
  </Step>

  <Step title="Optionally tag the auditor invite">
    If the request came from a specific external auditor, link their
    invite. The request will become visible in that auditor's portal
    once it reaches AUDIT\_READY.
  </Step>

  <Step title="Capture the request metadata">
    * **External ID** — the auditor's reference (e.g. `IRL-042`). Not
      unique in Regentra because the same code may recur across audits.
    * **Title** + **Description** — what the auditor wants.
    * **Type** — Document, Test, Observation, or Inquiry.
    * **Cadence** — one-time or recurring.
    * **Owner** — the operator responsible for gathering the evidence.
    * **Due date** — for SLA tracking.
  </Step>

  <Step title="Link controls (optional but high-value)">
    Tag every [internal control](/compliance/controls) the request
    evidences. Linking controls means the same evidence shows up on the
    control card, in the [evidence map](/compliance/evidence-collection),
    and on cross-framework reports — without a second upload.
  </Step>

  <Step title="Save in NOT_READY">
    The request lands in the NOT\_READY column. The owner is notified.
  </Step>
</Steps>

## Attaching evidence

Evidence is added inside the request:

* **Files** — direct uploads (PDFs, screenshots, CSV exports)
* **Links** — URLs to dashboards, monitoring tools, or live runbooks
* **Existing controls' evidence** — reference an evidence record that
  is already attached to a linked control (no second upload)
* **Existing test results** — pull a control-test run directly into the
  request

Every attachment carries the uploader, timestamp, and a (server-side)
hash, so even if the file is replaced later, the audit trail shows what
the auditor saw at each status transition.

## Comments and the back-and-forth

Each request has a comment thread visible to both sides once the
request is AUDIT\_READY. Internal comments (visible only to the
customer side) are also supported for the back-channel "is this the
right version?" conversation that should not be in the auditor view.

The thread is preserved when a request is FLAGGED → re-attached →
pushed back to AUDIT\_READY, so the auditor sees the full history of
the loop.

## Status transitions and who can drive them

| Transition                                 | Who can trigger                                                        |
| ------------------------------------------ | ---------------------------------------------------------------------- |
| `NOT_READY → INTERNAL_REVIEW`              | Owner or any compliance team member                                    |
| `INTERNAL_REVIEW → AUDIT_READY`            | Compliance Admin / Compliance Officer (the "second pair of eyes" role) |
| `INTERNAL_REVIEW → NOT_READY`              | Same — sends it back to the owner with comments                        |
| `AUDIT_READY → APPROVED`                   | The external auditor through their portal                              |
| `AUDIT_READY → FLAGGED`                    | The external auditor through their portal                              |
| `FLAGGED → NOT_READY` or `INTERNAL_REVIEW` | Operator side — restart the loop with whatever the auditor asked for   |

The auditor never directly authors evidence; they only approve or
flag what's been shared. This separation is what makes the audit
trail defensible.

## What the auditor sees

External auditors interact with Audit Requests through their
token-scoped portal at `/audit/{token}` — they never receive a login
to the main Regentra app. Through that portal they can:

* See every request currently in AUDIT\_READY, APPROVED, or FLAGGED
  (NOT\_READY and INTERNAL\_REVIEW requests are hidden — they're
  customer-side prep)
* Download attachments
* Read the linked controls and their evidence
* Comment on a request
* Approve or flag the request
* Download a per-request CSV and the full audit-package ZIP for the
  audit period

The audit-package ZIP they download is the same artifact your team
can generate from the admin side, scoped to the auditor's token. See
the [audit-package builder](/compliance/audit-lifecycle#audit-package)
for the file inventory.

## Status dashboard

The Audit Requests page surfaces five lanes (NOT\_READY, INTERNAL\_REVIEW,
AUDIT\_READY, APPROVED, FLAGGED) with counts and a list of requests in
each. Filters: by audit period, by owner, by cadence, by type, by
"overdue only".

A request is "overdue" when its due date is past and its status is
NOT\_READY, INTERNAL\_REVIEW, AUDIT\_READY, or FLAGGED — APPROVED requests
never show as overdue regardless of their original due date.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="What's the difference between a FLAGGED request and a Compliance Issue?">
    A FLAGGED request means "auditor wants different evidence" — you
    iterate inside the request. A Compliance Issue means "auditor
    found something wrong with the control itself" — you remediate
    the underlying control, then evidence that remediation in a
    separate request.
  </Accordion>

  <Accordion title="Can I bulk-import an IRL from a spreadsheet the auditor sent me?">
    Not yet — bulk import is on the roadmap. For now, paste each row
    into a New Request form. The auditor's External ID, title, and
    description fields are designed to mirror the columns of a typical
    IRL spreadsheet, so the data maps cleanly even when typed manually.
  </Accordion>

  <Accordion title="What happens to a recurring request when the audit period ends?">
    Recurring requests keep respawning on their cadence regardless of
    audit-period status — they're tied to *continuous* monitoring, not
    a single window. Stop the recurrence by flipping the cadence to
    ONE\_TIME on the most recent instance.
  </Accordion>

  <Accordion title="Can the auditor see who on my team uploaded each piece of evidence?">
    Yes. Every attachment shows the uploader's name and timestamp in
    the auditor portal — that's what makes the audit trail defensible.
    If you have a privacy concern, use a service account for sensitive
    uploads.
  </Accordion>

  <Accordion title="A request was approved by the auditor. Can I edit it?">
    No — APPROVED is terminal and the attached evidence is locked. If
    something changes (a policy version, a screenshot), open a new
    request that supersedes the old one and reference the original in
    the description.
  </Accordion>
</AccordionGroup>