Audit Workflow

Scope

Audit workflow is where evidence, requests, follow-up, and accountability all need to hold together. The public version keeps the operator guidance and leaves private control-plane detail behind.

Reviewer, requester, assignee, and discussion-author labels come from the authorized audit response. Check the displayed authority context when names are similar. An inactive or removed badge is historical attribution, not permission to assign new work. Use the eligible-person selector for assignment; if the person is absent, restore their current-tenant membership and required role instead of entering an ID.

Finding detail is program-type aware. General GRC findings never load or display SOX financial-account or PCAOB-assertion linkage panels. Those panels are available only when the finding’s audit cycle belongs to a sox_icfr program.

This guide walks through running an internal audit cycle in Meridian — from creating the cycle through producing a finalized findings log.

Step 1: Create the Audit Cycle

You can reach the audit workspace two ways:

• Sidebar → Audits — the cross-program workspace at the relevant workflow. Pick a program from the selector to see its audit cycles, filter by status or type, and page through history. This is the everyday entry point.
• Programs → [Your Program] → Audits — the per-program drill-in at the relevant workflow. This is the “New Audit Cycle” entry point and the view the sidebar “Program View” button opens.

The program selector searches the server-backed program directory as you type, so a program does not need to appear in the first result page to be discoverable. A deep link such as the relevant workflow loads that program by ID before displaying its name. If either the selected-program lookup or the directory search fails, use Retry; the failed dependency is not presented as an empty program list.

Keyboard navigation: In both audit cycle tables, rows are keyboard-operable. Tab to a row, then press Enter or Space to open the cycle detail.

From the per-program view, click New Audit Cycle. Fill in:

• Name: e.g., 2026 Q1 Internal SOC 2 Audit
• Audit Type: internal (or external if this is an external party — the cycle is still managed here, but external auditors get their own portal in WS-10)
• Auditor Firm / Lead Auditor: only relevant for external cycles
• Start Date / End Date: optional period bounds. The audit year on finding refs is taken from the start date.

The cycle is created in planning state. The review queue remains empty until an engagement plan is independently approved and you advance to fieldwork.

Step 2: Plan and Approve the Engagement

Open the Engagement plan tab on Audit Detail. Record at least one objective and audit-universe risk, select the exact controls justified by that risk, explain the scope, and enter a positive budget with active tenant resource allocations. Save creates a new revision; if another operator saved first, reload the current revision before applying your changes.

Submit the complete plan for approval. The author/editor/submitter cannot approve their own work. A different auditor reviews the visible scope, risk, budget, and resource context and records a substantive approval or rejection reason. A rejection remains in history; edit from the rejected content and save a new draft revision.

The plan and scope-change history load independently. If history shows an error, the current plan remains visible but decisions and new scope changes are blocked. Use Retry before acting; do not infer an empty history from a failed read.

Step 3: Move to Fieldwork

After approval, advance the cycle from planning to fieldwork. Meridian revalidates the approved scope and active resources, then creates review rows only for approved controls. This is the work queue.

Meridian also assigns each review to a conflict-free auditor using current workload and a stable tie-break. It excludes the control owner, anyone who prepared a current manual test, and the audit author. When no eligible independent reviewer exists, the review stays visibly unassigned; it is not silently routed to a conflicted person.

The Audit Cycles status cards count every cycle matching the active program, status, type, and search filters—not only the rows on the current page. Changing a filter or search term updates both the cards and paginated list from the same server result.

If risk or resourcing changes later, return to Engagement plan, adjust the approved scope/budget/resources, and enter a substantive change rationale. Another auditor must approve the change. An approved addition creates its review during fieldwork; a direct program-control addition does not. Meridian refuses to remove a control whose review already has activity. If an allocated user was deactivated, replace that allocation before fieldwork or change approval; the old approved revision keeps its frozen historical name and email.

Step 4: Review Controls

Open the Review Queue (from the audit detail page). Each row is a control to examine. Click a row to open the Control Review Workspace.

The Audit Detail page itself is available with Meridian.view, including its aggregate review and finding counts. Opening the Review Queue or Findings Log requires audit-review access (Meridian.audit). If your role is view-only, those cards explain the required access instead of sending you to a denied route; ask a tenant administrator if your responsibilities require either workspace.

The workspace has three panels:

• Left: Control info — description, implementation notes, current control status
• Center: Evidence collected on this control (with freshness)
• Right: Discussion thread with the control owner

To start a review:

1. Click Claim Review. Status moves to under_review.
2. Examine the evidence. Click into individual evidence artifacts to review the underlying files or structured data.
3. Post questions or assertion challenges as you find issues. Use the comment type selector: - Note: casual context - Question: ask the control owner something - Assertion Challenge: when you disagree with the control’s claimed state. These are highlighted prominently in the UI. - Response: when responding to a previous comment

Requesting More Evidence

Comments and evidence requests load independently in the review workspace. If one panel reports a read failure, use that panel’s Retry action; the other panel and the review record remain usable. A blank panel without an empty-state message is not evidence that no comments or requests exist.

If the existing evidence isn’t enough, click New Request in the Evidence Requests panel. Describe what you need, set an appropriate priority, optional due date, and the criteria that make the response acceptable. Meridian assigns the request to the active control owner when one is available and creates a linked evidence-collection task. The assigned contributor sees the same description, deadline, priority, and criteria in My work. Select Provide evidence, give the uploaded artifact a title, and submit it; Meridian validates the file and records the evidence, reviewed-control binding, request fulfilment, task completion, and audit trail together. If the upload fails, the entered title and selected file stay available to correct and retry.

An open request past its due date appears as overdue and is delivered once through the configured event route. It remains visible until it is fulfilled, cancelled by an authorized requester or manager, or its due date is moved forward; correcting any of those conditions clears the overdue alert.

When the control owner fulfills the request, it’s linked to a specific evidence record and becomes terminal. You can’t re-open a fulfilled or cancelled request — create a new request if you need more.

Scope check on fulfillment: the linked evidence must belong to the same program as the control under review. When the artifact has canonical control bindings, at least one tenant-owned binding must target the reviewed control; with no binding rows, a matching direct control or program-level with evidence bound to Control B are rejected — the audit trail won’t claim satisfaction with an unrelated artifact.

must match the evidence tenant and every bound control must belong to the evidence’s program. An invalid import or administrative data change is rejected instead of being hidden by tenant filtering and treated as legacy evidence.

Cancelling a request: the compliance manager can cancel any open request. You can also cancel a request you opened yourself (e.g., if you later realize the evidence wasn’t needed). Cancelling is terminal — the request stays in the audit trail marked cancelled and cannot be re-opened. A confirmation dialog appears before cancel since it closes the thread.

Rendering a Conclusion

Once you’ve examined the evidence and resolved any open assertions, render your conclusion in the bottom-left panel:

• Effective: The control is operating as intended
• Observation: Minor issue worth noting
• Deficiency: Meaningful gap
• Material Weakness: Audit-blocking failure

Add review notes (sampling approach, scope, exceptions), then click Render Reviewed. The status moves to reviewed.

If you need to amend a reviewed control later, click Re-open to bounce it back to under_review.

Step 4b: Test Executions During Fieldwork (CW-23)

The Control Review Workspace now surfaces Test executions during this cycle above the evidence list. This shows every run of every control test that landed in the cycle’s fieldwork window — in-window runs are expanded, out-of-window runs are collapsed behind a “Show older runs” toggle.

Each execution row shows who ran it, when, the result, sample size/description, notes, and the linked evidence artifacts with primary/supporting roles. Evidence in the lower list is also badged from test execution when it was produced by a run, so you can quickly distinguish test-derived evidence from manual uploads.

If the control owner hasn’t recorded an execution in the window yet, ask them to — or record it yourself from ControlDetail Tests tab while you’re in the workspace. Executions recorded mid-review show up on the next refresh.

Step 5: Create Findings

Conclusions other than effective typically result in a finding. From the workspace, click New Finding. The form pre-fills the control and links the finding to this review. You can also open the audit’s Findings Log, click New Finding, and choose a control review from the searchable selector.

Fill in:

• Title: Concise statement of the issue
• Description: Full description — issue, impact, evidence reviewed, recommendation
• Root Cause Analysis (optional): category, corrective or preventive action type, and a free-text root-cause explanation

Click Create. The finding gets an auto-generated reference like F-2026-001 (sequential within the audit cycle).

The audit cycle and control-review directory load independently. If either request fails, the form identifies the failed dependency and offers Retry without discarding entered finding text. A failed control-review load disables both the selector and Create, because submitting without a verified review/control pair would produce an invalid finding association.

Editing Findings

Findings start in draft and can be freely edited until they’re finalized. You can move them through draft → under_discussion if you want to formally signal “the control owner is responding to this” before locking.

Finalizing a Finding

When the finding is settled and ready to lock, click Finalize. Once finalized, the title, description, classification, materiality, and finding status cannot be changed from the finding page. Create or open its Management Action Plan to record implementation, independent verification, recurrence, and closure; that lifecycle is the authoritative remediation record.

A confirmation dialog appears before finalization since it’s irreversible for the text fields.

Step 6: Move to Reporting

Work efficiently in the review queue

The review queue searches control reference and title across the full audit, not only the visible page. Status, conclusion, My reviews, and Unassigned filters are server-side. Sortable desktop headers and pagination use the same server query. The URL retains search, filters, sort, and page so refresh, back, and shared links restore the same worklist.

On phones and narrow screens, every review is a complete card with control reference and title, status, conclusion, reviewer, comment/evidence-request/ finding activity, and an Open action. No field is available only through a horizontally scrolled table.

Use Saved review views for recurring worklists. Enter a name and save the current search/filter/sort preset. Saved views follow your Meridian identity across browsers, are private to you within the tenant, and never change review records. Names are unique for your identity regardless of capitalization or extra spaces. You may keep up to 20 views. Updating or deleting a stale version fails safely; reload the saved-view list and repeat the explicit action.

Step 6b: Generate the Evidence Package (CW-23)

Before you close the cycle, generate the package you’ll hand to the auditor. Scroll to the Evidence Package panel on AuditDetail and choose the generation path:

• Use Generate package for small cycles where a foreground build can finish while the request is open.
• Use Generate in background for large or timeout-prone cycles where the build should survive page closes, worker restarts, and retries.

Both paths use the same backend package builder:

1. Walks the whole cycle — controls, reviews, tests, executions, evidence, findings.
2. Builds a deterministic canonical manifest (same state, same bytes, every time).
3. Computes a SHA-256 manifest_hash over the canonical bytes. This is what the auditor references in their workpaper.
4. Zips the manifest + every evidence file under evidence/{id}/{filename}.
5. Writes the bundle to storage and inserts a package row.

Click Preview manifest to expand the manifest tree inline. Every control block shows its governance snapshot, the reviews, the tests with executions, the evidence entries (with short content_hash), and the findings. If something is missing or wrong, fix it in the UI and regenerate — the second generation returns a new row with a new hash only if the data actually changed.

Use Diff previous when more than one package snapshot exists for the cycle. Meridian compares the selected package to the previous snapshot from the same audit cycle and shows added, removed, and changed entries. This is useful after regenerating a package because it shows exactly what changed before a new share link is issued.

Share the package:

2. Add a note (e.g. “Q1 2026 external auditor”) for your own records.
3. Click Issue share link. You’ll see the package download endpoint and the raw bearer token with a warning that the token is shown only once. Copy both values immediately. The endpoint URL alone is not enough to download the package.
4. Send the endpoint and raw token to the auditor via separate channels where possible, or send the exact header form: Authorization: Bearer <raw_token>.
5. The auditor downloads from the endpoint with the bearer header — no login — and the ZIP streams to their browser. Every successful download writes an audit log entry with the remote IP and user agent, increments the token’s download count, and updates last_used_at.

If the auditor is using the authenticated auditor portal instead of a bearer share token, grant the invite download_package. That permission lets the portal read package metadata and download the latest published package ZIP; view_evidence is only for individual evidence-file downloads from control detail.

The panel lists every active share token with badges:

• Not yet used — issued but never opened.
• Downloaded recently — opened in the last 24 hours (auditor is working on it).
• Last used {date} — older downloads.

Click Revoke to kill a token before its expiration; revokes are idempotent. Issue a fresh link if the auditor needs more time.

Step 7: Complete the Audit

There are two terminal closeout paths, and both are strict.

Internal operator completion from AuditDetail: all control reviews must be reviewed, all findings must be finalized, and every test on every control in the program must have at least one non-superseded execution during the cycle’s fieldwork window. If only test execution coverage is missing, the internal UI may open an Override modal:

• Lists every missing test (control ref + test name).
• Live character counter; Submit button disabled until the minimum is met.

Provide a real reason (“Connector X was down 2026-02-03 to 2026-02-10, manual coverage documented in ticket LIN-4221” is useful; “n/a” is not). On submit, the cycle closes and an audit_cycle.closure_override audit log entry records the reason plus the full missing-tests snapshot at override time. Future you — and the auditor — can see exactly what was skipped and why.

No override exists for unreviewed controls, non-final findings, missing sign-off, tenant scoping, or permissions.

A complete audit cycle is immutable. No further reviews, comments, evidence requests, findings, or status changes can be made. The cycle is the audit record of record.

Filters and Triage

The Review Queue supports filters:

• By conclusion: any of the four values
• By reviewer: see who is working on what

The Findings Log supports filters by classification and status to triage what needs attention.

Common Operator Errors

You see	What it means	What to do
Invalid status transition: 'X' -> 'Y'	The state machine doesn’t allow that move	Check the lifecycle in the functional doc
Fieldwork requires a current independently approved engagement plan	The plan is absent, incomplete, rejected, submitted, or no longer current	Open Engagement plan, resolve validation, and obtain an independent approval
Engagement plan changed; current revision is N	Another operator saved or decided after the visible revision	Reload, reconcile the visible revision, and repeat the explicit action
Resource users must be active in this tenant	An allocation points to an inactive, missing, or foreign tenant user	Replace it using the active resource selector; historical approved snapshots remain unchanged
Only one scope change may be pending for an audit	An existing governed change is awaiting decision	Approve or reject the pending change before creating another
Cannot enter reporting: N control review(s) not yet reviewed	Not all reviews done	Filter the queue by not_reviewed and finish them
Cannot complete: N finding(s) not finalized	Some findings still draft/under_discussion	Filter findings by draft and finalize each
incomplete_test_coverage	One or more tests have no non-superseded execution in the cycle’s fieldwork window	Record the missing executions, or use the internal audited override if launch policy accepts it
override_reason_too_short	The internal missing-test override reason is blank or shorter than the configured minimum	Provide a specific reason at or above the configured minimum
Report must be signed off before the engagement can be closed.	The external auditor tried to close the engagement before report sign-off	Sign off the report first using the portal report sign-off action
External close still returns incomplete_test_coverage after sending override_reason	Portal closeout has no missing-test override path	Record the missing executions, or have an internal operator use the audited internal override
A conclusion is required when status is 'reviewed'	You tried to render reviewed without picking a conclusion	Pick one in the dropdown
Finding is final ...	You tried to edit a locked finding’s text	Status changes are still allowed; create a new finding if the text needs to change
Evidence does not belong to the same program as this control review	Fulfilling a request with evidence from another program	Pick evidence from the correct program
Evidence is for a different control than this review	Fulfilling with evidence tagged to a different control	Use program-level evidence or evidence tagged to the correct control
Only the requesting auditor or a compliance manager can cancel this evidence request	You tried to cancel someone else’s evidence request	Ask the original auditor or a manager to cancel
Only the assigned evidence contributor can fulfil this request	You tried to fulfill work assigned to someone else	Ask the assignee or a compliance manager to link the evidence
Could not allocate a unique finding_ref after multiple retries — please retry the request	Rare finding_ref race (two concurrent creates in the same cycle)	Retry the request. If persistent, investigate duplicate creators
Cannot post comments on a completed audit cycle	The cycle is closed	Open a new cycle if you need to add to the audit record

Tips

Audit management controls expose stable identifiers for browser automation and diagnostics. Invite, closure-override, manifest, and evidence-package share actions preserve their form state when the server rejects an action; review the displayed error, correct the prerequisite, and retry rather than recreating the workflow.

• Claim controls before reviewing them. Setting a reviewer makes it clear who is working on what and helps avoid duplicate effort.
• Resolve independence warnings before deciding. The review workspace names each conflict. Managers can select an eligible auditor. If staffing requires a conflicted assignment while the policy is enabled, enter a specific reason of at least 20 characters; it becomes part of the audit trail and expires if the reviewer, conflict facts, or policy revision changes.
• Govern the account default in Settings. Account admins can enable or disable Require independent audit review under Audit governance. Disabling requires acknowledging the displayed consequence; conflicts remain visible even when they stop blocking decisions.
• Use assertion challenges for real disagreements, not just questions. Reserve them for moments where you want to formally flag “the evidence does not support this claim.” They’re highlighted in the UI for a reason.
• Finalize findings sooner rather than later. The longer a finding sits in draft, the more likely the text drifts. Locking forces a clean record.
• Re-open a review if you find new information — don’t avoid amending. The audit trail captures all changes, and re-opening keeps the conclusion accurate.

The Evidence Package tab distinguishes package integrity from audit readiness. does not mean control review is complete. The tab shows reviewed, total, and unresolved counts. External share-link issuance remains disabled until all control reviews are complete. An audit manager may claim an unassigned review for themselves in the same action that starts review; decisions still remain restricted to the effective assignee. Self-claim uses the authenticated identity, so a missing optional directory display name does not block the operator from taking responsibility for the review.

Assign an external audit firm

When creating an external audit cycle:

1. Search and select an active audit firm from the registry.
2. Search that firm’s active members and select the lead auditor.
3. Retry either list if it cannot load; the form retains your other entries.
4. Create the cycle. Meridian records the authoritative IDs and freezes the displayed firm and lead names for historical reports.

You cannot type an arbitrary firm or lead name, select a member from another firm, or select a deactivated record. A legacy cycle marked “not reconciled” retains its historical names but is not proof of a current authoritative identity; update it by selecting a firm and member together.