> ## Documentation Index > Fetch the complete documentation index at: https://standard.aiuc-1.com/llms.txt > Use this file to discover all available pages before exploring further. # Evidence collection export const InlineClock = ({city, timeZone}) => { const [time, setTime] = useState('--:--:--'); useEffect(() => { const update = () => setTime(new Intl.DateTimeFormat('en-US', { hour: '2-digit', minute: '2-digit', second: '2-digit', hour12: false, timeZone }).format(new Date())); update(); const id = setInterval(update, 1000); return () => clearInterval(id); }, [timeZone]); return
{city} {time}
; }; Evidence collection is where the client gathers proof, for every requirement in scope, that a control exists and works, and hands it to the auditor as a quality-assured evidence pack.
| | | | - | - | | Leads | Client | | Supports | AIUC can provide inputs to the gap assessment, per-control guidance on request, and a quality-assurance pass (as needed).

The auditor is available for an optional preliminary review | | Timing | Weeks 1 to 6, in parallel with scoping and the [technical evaluations (evals)](/auditors/deliver-and-certify/evals) | | Inputs | The [Statement of Applicability](/auditors/deliver-and-certify/scoping/requirements-in-scope) and the standard's control list | | Output | An evidence pack for every in-scope control, on a shared platform with access for the auditor and AIUC | *Weeks 1 to 2.* The client assesses every in-scope control against what exists today, building on the gap assessment from [Introduce and scope](/auditors/introduce-and-scope/request-a-gap-assessment) and starting from the requirements it marked to be verified. AIUC supports by providing inputs as needed. The result is a remediation path agreed for every gap. *Week 2.* Opt-ins are proposed at [scoping](/auditors/deliver-and-certify/scoping/requirements-in-scope) and can be revised here until the evidence pack is handed over. Where evidence is readily available, include it: opted-in items are referenced directly in the audit report and shape how strong it reads. The Statement of Applicability is final at handover. *Weeks 2 to 6.* Start with the core controls of each requirement. Evidence goes into a shared platform (for example, Drata, Vanta, or Fieldguide) with external access for the auditor and for AIUC. Evidence falls into four categories:  Policies and contracts, such as ownership of inputs and outputs, or the agent's acceptable use policy. Safeguards in the codebase or tooling, such as sensitive data protection or hallucination guardrails. Process documentation, such as accountability for agent changes or failure plans. The eval results. Provided by AIUC today; the auditor validates that scope and results meet the standard. *Week 6.* The evidence pack is handed to the auditor together with the final Statement of Applicability. Evidence should be complete before handover so the auditor's follow-up questions during fieldwork are minimized. ## The auditor during evidence collection Auditors clarify what a requirement needs and may review readiness, but do not design or implement controls. Within that boundary: * **Preliminary review, optional.** A review of specific controls or evidence can be agreed where useful, for example on controls the client is unsure about, so issues surface before fieldwork rather than during it * **Questions on what a requirement needs.** Answer against the intent of the requirement. The rules for judging whether a control meets a requirement are on the [Fieldwork](/auditors/deliver-and-certify/fieldwork#how-to-judge-whether-a-control-meets-a-requirement) page * **Workshops, for new auditors.** You will be added to one or two evidence collection workshops with a client, to see how evidence is gathered in practice. Contact AIUC's delivery lead for details One person can play several roles: a primary point of contact coordinating collection, often the security or governance lead; a policy or AI-governance owner for policy and accountability controls; legal or privacy counsel for data-protection and contractual evidence; and engineering for technical evidence such as architecture, access controls, logging, and guardrails. GRC and audit tools are set up per client and must be updated each quarter with the standard's changes, so the version agreed at scoping is the one in the tool. If you use your own audit platform, AIUC shares an updated spreadsheet with the controls mapping each quarter. Which version applies to a given audit is on the [Requirements in scope](/auditors/deliver-and-certify/scoping/requirements-in-scope) page. **Output.** Evidence against every in-scope requirement, quality-assured, on a shared platform, handed to the auditor with the final Statement of Applicability. *** How the evals run, and what the auditor validates.
37.782274° N -122.392147° W FIG. A (SITE INDEX)
Artificial Intelligence Underwriting Company
Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input.
100 © AIUC — ALL RIGHTS RESERVED
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.