> For the complete documentation index, see [llms.txt](https://docs.cortex.aic.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.cortex.aic.io/workflow-guides/assurance/audit-custody.md).

# Audit Custody

**Open this area:** In the CORTEX menu, select **Assurance & governance → Security incidents**.

Send selected minimal incident audit events to an approved independent UK receiver with an exact locked-version receipt.

**Who uses this:** Reviewer, Administrator.\
**Open in CORTEX:** `/security/incidents`.\
**In-app guide:** `/help?topic=audit-custody`.

**Expected result:** Durable selected exports survive disconnection and uncertain responses; an accepted external version can be compared with the retained manifest.

## Before you start

* Use the incident workspace with Security read/manage and current access to every linked source.
* The independent custodian must supply a private UK Azure receiver with locked version retention, separate ownership, finite approval and protected credentials.
* The security owner must review the exact AUDIT-CUSTODY system-assurance data flow and applicable approved UK profile. Current external flow policy supports OFFICIAL handling; no sensitive-data exception is added.

## What to do

{% stepper %}
{% step %}

## Inspect source evidence

Open **Related audit records** on the incident, then **Independent audit custody**.

Each source retains its ordinary permissions. Review exact events, limitations and the configured receiver.
{% endstep %}

{% step %}

## Queue the selected events

Choose exact linked events, an approved profile and actual selection rationale.

**Queue selected events** saves an immutable local manifest; it does not send data. Source bodies and incident relevance notes are excluded. Profile, actor/target metadata and digests are included.
{% endstep %}

{% step %}

## Send deliberately

Confirm the selected metadata and receiver, then choose **Send or retry this export**.

Current source access, profile, receiver approval, organisation Online policy and reviewed data flow are checked. A deterministic blob name and no-overwrite upload allow the same export to recover after an uncertain response.
{% endstep %}

{% step %}

## Read the acknowledgement

The receiver must return matching bytes and a locked blob version covering the approved retention interval.

The retained receipt records that version, digest, ETag, receiver creation time and locked-until time. A local queue entry alone is not acknowledgement.
{% endstep %}

{% step %}

## Verify and recover

**Verify accepted external version** performs a fresh read of that exact version.

An outage preserves the queue. Keep uncertain retries unchanged; refresh and compare after conflicts. Preserve altered or unprotected evidence and ask the independent custodian to investigate. Access loss clears the whole incident/custody view.
{% endstep %}

{% step %}

## Witness actual recovery

Use the signed backup/restore procedure and a named independent witness.

Compare source/correlation sequences, queue IDs and exact external versions against the custodian's independent inventory, including entries absent from the backup. Record gaps, disconnected intervals, node/receiver clock offsets and uncertainty, and actual key/credential custody. A replay check covers only a retained queue.
{% endstep %}

{% step %}

## Retain the witnessed evidence

In **System assurance**, attach the actual exercise record with its exact locator, digest and verification limits to the applicable audit-continuity control.

The appointed independent security owner reviews it. Keep missing inventory, clock or custody inputs unresolved; a synthetic software check or a local hash cannot replace the witness.
{% endstep %}
{% endstepper %}

## Check the result

* Is the receiver independently controlled and its UK allocation evidenced?
* Is the exact connection currently approved?
* Do selected events disclose only approved metadata?
* Is a receiver version acknowledged?
* Does its retained manifest still match?

## If you get stuck

<details>

<summary>Why does an accepted receipt need another check?</summary>

The retained receipt records an earlier verified external version. Verify performs a current exact-version comparison; expiry, outage or changed evidence must be investigated.

</details>

<details>

<summary>Can I send while Offline?</summary>

No. Queuing is local, while send and external verification require the organisation's permitted connection and current reviewed data-flow approval.

</details>

<details>

<summary>What happens if Azure accepted data but the response was lost?</summary>

Retry the same retained export. Its deterministic name is inspected without overwriting and the matching locked version can supply the missing local acknowledgement.

</details>

## Responsibility and limits

* There are up to 16 exports per incident and 32 selected events per export. No export or acknowledgement is silently removed.
* Delivery is explicit; there is no automatic background sender or live message to an incident subject.
* Queue and source clocks are observations. Journal sequence determines order; no trusted-time or complete-recovery claim is inferred.
* Protect credentials separately from backups and preserve original accepted version identifiers. Actual witnessed restore, inventory reconciliation, time uncertainty and key custody remain required operator evidence.

**Reference and scope:** F23-R02. Local hashes alone do not prove independent custody, clock accuracy or complete recovery.

**Related workflows:** [Record and manage a defensive security incident](broken://pages/686a1f32f9bd42ca2b59d170632ad3d57be6a73e); [Follow an incident through related audit records](broken://pages/b4b3d8c79b1acf0b9919a4b1ad9f6b53033fbc31); [Track incident reporting and corrective actions](broken://pages/ca09bc7434b5a64dc02686b95d9cfc9a5e799e01); [Maintain a system control and evidence baseline](broken://pages/699956df97c18fc4ddd8894884fea67a7b6e90ce); [Record UK processing paths and approved uses](broken://pages/d1a5ce8a791f7e21103f6f699e97b63ddcffb253); [Work through connection and deployment limits](broken://pages/e2892068271c3c1f3c4471ca5a8f532a8174ba43).