# Audit & Evidence (AUD) Requirements — 7 Workforce AI Security Controls > Produce tamper-evident logs and auditor-ready evidence across every control. 7 vendor evaluation requirements with acceptance criteria, verification tests and framework mappings. Source: Harmonic Security, updated October 2026. 7 requirements. Disclaimer: Mappings indicate relevant contributions, not complete compliance, certification, assurance, a conformity assessment or legal advice. Read each explanation and its scope conditions. Legal applicability depends on jurisdiction, role, use and effective dates. Reference summaries are selective; consult current official sources and full licensed standards before relying on them. ## SPM-011: Support the AI tool approval and review lifecycle - Area: AI Security Posture Management - Verification: Walkthrough - OWASP adoption tier: AT0–AT4, AT6 - Formerly: GOV-008 - URL: /r/SPM-011 **Acceptance criteria:** Define and track unapproved versus approved AI tools and MCP servers. **Why it matters:** Without a governed approval path, teams route around the control. **How to verify:** Walk a tool or MCP server request from intake to a recorded decision. **OWASP adoption context:** Managed assistants, platforms and connected-agent workflows need approval status and periodic review; status should be visible throughout the tool lifecycle. **Mappings:** - NIST AI RMF: GOVERN 6.1, MANAGE 3.1; SOC 2: CC9.2, CC5.3 — Approved/unapproved tool and MCP-server records supply inventory context and inputs to third-party governance and permitted-use review. Tracking status alone does not establish assessment criteria, due diligence, approval authority, periodic supplier review, retirement decisions, enforcement or conformity of actual use with its intended purpose. - ISO 27001: A.5.9, A.5.23 — Tool identity and approval status provide asset-register fields and, for cloud services, approval tracking within an operated cloud-use process. A status flag does not establish assessment criteria, approval authority, supplier due diligence, periodic review or retirement decisions. - ISO 42001: A.4.2 — Approved and unapproved tool records document AI resources and their status. They do not assess supplier responsibility or establish that actual use matches the system’s intended functions. - NIST CSF 2.0: ID.AM-02 — Approved and unapproved tool states provide concrete software and service-inventory attributes. Status tracking does not itself assess or manage changes and exceptions for cybersecurity risk. ## GRD-018: Turn acceptable-use policy into enforceable scenarios - Area: Runtime Guardrails - Verification: Walkthrough + Proof of value - OWASP adoption tier: AT0–AT4 - Formerly: GOV-007 - URL: /r/GRD-018 **Acceptance criteria:** Express AUP rules as policies and demonstrate enforcement. **Why it matters:** An acceptable-use policy only matters if it can be enforced and shown to be enforced. **How to verify:** Three clauses from your AUP are expressed as policies and successfully tested in your pilot. **OWASP adoption context:** Acceptable-use rules need concrete scenarios across the listed employee AI contexts rather than a policy that only addresses one application type. **Mappings:** - NIST CSF 2.0: GV.PO-01; ISO 42001: A.2.2, A.9.2; SOC 2: CC5.3, CC4.1; ISO 27001: Cl. 8.1, A.5.10, A.5.36 — Translating approved acceptable-use rules into executable scenarios connects organizational policy to responsible-use procedures and practical restrictions. Would-have-fired and actual-action records help evaluate implementation; simulation alone does not demonstrate operational enforcement, policy communication or a completed periodic compliance review. - NIST AI RMF: GOVERN 1.2 — Executable acceptable-use scenarios and their results help operationalize trustworthy-AI characteristics in organizational policy and practice. Coverage depends on which characteristics the approved rules actually address. ## AGT-004: Attribute every connector and tool call alert to a person - Area: Agent & MCP Governance - Verification: Live test - OWASP adoption tier: AT3, AT4, AT6 - URL: /r/AGT-004 **Acceptance criteria:** Answer which server and tool were called, by whom, using which identity, every time an alert or intervention fires. **Why it matters:** Without attribution, an agent action cannot be investigated or tied to accountability. **How to verify:** Every pilot tool call alert shows the tool used, the surface, the user identity, and the result. **OWASP adoption context:** The listed connected-agent contexts need an identity chain from the employee to the server and tool call, including the delegated identity actually used. **Mappings:** - SOC 2: CC2.1, CC7.2 — Linking the person, execution identity, server, tool, scope and result supplies usable information for correlating calls and reviewing identity use. It can reveal gaps between human and delegated identities; attribution alone does not authenticate the caller, manage the identity lifecycle or authorize the operation. - ISO 42001: A.6.2.8; ISO 27001: A.8.15 — The person-to-identity-to-tool chain supplies attribution needed for AI event records and an audit trail. Answering those questions does not by itself require persistent protected logs, and the chain must preserve the distinction between the person and any service or delegated identity. ISO/IEC 27001: Human attribution must not expose credential values. - OWASP ASI: ASI03 — Visible identity and scope relationships help investigate inherited-identity abuse, excessive delegation and confused-deputy behavior. Attribution exposes how authority was used; it does not itself stop an unauthorized call. - NIST CSF 2.0: DE.AE-03 — Joining the person, execution identity, server, tool, scope and result supports event correlation. Attribution does not authenticate the caller, manage identity lifecycles or authorize the operation. ## AUD-001: Keep a configurable record of each conversation - Area: Audit & Evidence - Verification: Walkthrough - OWASP adoption tier: Tier-independent - Formerly: GOV-014 - URL: /r/AUD-001 **Acceptance criteria:** Record the prompts, responses, uploaded files and tool calls that make up each conversation, with content capture set per policy: full, partial, metadata-only or none, in line with privacy and retention rules. **Why it matters:** The conversation, not the single prompt, is the unit an investigator or auditor needs to see. **How to verify:** Show one pilot conversation's record at full, partial and metadata-only capture settings. **OWASP adoption context:** Logging-depth choices apply across adoption tiers, balancing needed evidence against data minimization and any applicable retention rule. **Mappings:** - NIST CSF 2.0: PR.PS-04; ISO 42001: A.6.2.8; SOC 2: CC7.2, P3.1, P4.2 — Selectable prompt/response capture provides AI/security logging evidence while letting privacy and retention policy constrain content depth. The buyer must test that each chosen mode preserves needed event metadata; capture configuration alone establishes neither log integrity nor an adequate monitoring and retention process. SOC 2: P3.1/P4.2 require the Privacy category and relevant information in scope. - NIST AI RMF: MEASURE 2.8 — Choosing and documenting content depth can supply evidence for evaluating transparency and accountability alongside privacy trade-offs. A configuration option alone does not establish the evaluation or its adequacy. - ISO 27001: A.8.15, A.5.34 — Configurable prompt and response capture supports logging design and privacy minimization. Preserve needed event metadata, usable attribution and appropriate retention, protection and analysis even when content capture is disabled. Capture-depth options alone establish neither log integrity, record protection nor lawful monitoring. ## AUD-002: Export audit and forensic evidence - Area: Audit & Evidence - Verification: Walkthrough - OWASP adoption tier: Tier-independent - Formerly: GOV-002 - URL: /r/AUD-002 **Acceptance criteria:** API, CSV, webhook or evidence package suitable for audit and incident response use. **Why it matters:** Evidence has to leave the console in a form legal, HR and auditors can use. **How to verify:** Export an evidence package for one pilot incident. **OWASP adoption context:** Evidence export serves investigation and audit across adoption tiers; the relevant source and access restrictions still follow the records. **Mappings:** - NIST CSF 2.0: RS.AN-07; ISO 42001: A.6.2.8; SOC 2: CC2.1, CC7.3; ISO 27001: A.5.28 — Exportable AI-event and incident records provide usable information for incident analysis and evidence handling. Preserve source identifiers, times, provenance and integrity through export into the relevant evidence procedure. Format support alone establishes neither accuracy, completeness, chain of custody, recorded investigation actions nor an internal-audit program or incident decision. - NIST AI RMF: GOVERN 4.3 — Evidence packages make AI-event information available to people responsible for testing, incident identification and information sharing. An export facility is an input to those practices, rather than the complete practice. ## AUD-003: Restrict and audit access to raw prompt content - Area: Audit & Evidence - Verification: Walkthrough - OWASP adoption tier: Tier-independent - Formerly: GOV-005 - URL: /r/AUD-003 **Acceptance criteria:** Provide RBAC controls over who can read full prompt content, and record each access to it. **Why it matters:** Raw prompts are among the most sensitive data the control holds, so access must be limited and logged. **How to verify:** Only an authorized role can open full prompt content, and each access is recorded. **OWASP adoption context:** Raw prompt access needs protection across the listed employee AI settings, independently of whether the underlying application is sanctioned. **Mappings:** - NIST CSF 2.0: PR.AA-05, PR.DS-01; SOC 2: CC6.3, CC7.2; ISO 27001: A.8.3, A.8.15 — Role-scoped access restricts who can read raw prompts, helping protect stored content, while records of each read supply monitoring evidence. Restrictions must operate across relevant access paths; logged reads still require review and follow-up to detect misuse. ISO/IEC 27001: Enforce restrictions before access across the UI, exports, APIs, search and administrators. Retain, protect and analyze attributed access logs; logging access does not authorize it. - NIST AI RMF: MEASURE 2.10 — Restricted and recorded access to identifiable prompt content provides evidence of a treatment for privacy risk. The broader examination and documentation of privacy impacts remain necessary. ## PLT-008: Separate administrative roles, and authenticate them through enterprise SSO - Area: Platform, Privacy & Assurance - Verification: Walkthrough - OWASP adoption tier: Tier-independent - Formerly: POL-002 - URL: /r/PLT-008 **Acceptance criteria:** Separate policy, approval, administration, investigation and exception duties; authenticate administrators through enterprise SSO; apply least-privilege roles over policy, alerts, raw prompts, exports and dashboards; and record administrative and investigative actions. **Why it matters:** Whoever can change policy or read prompts holds a lot of power, so roles must be separated and every action recorded. **How to verify:** Show separate policy, investigation and exception roles, SSO login and the record of an admin action. **OWASP adoption context:** Administrative role separation and enterprise authentication apply to governance of workforce AI regardless of the end-user adoption tier. **Mappings:** - NIST CSF 2.0: GV.RR-02, PR.AA-03, PR.AA-05; SOC 2: CC6.1, CC6.3; ISO 27001: A.5.3, A.8.2, A.8.3, A.8.5, A.8.15 — Separating administrative duties, authenticating administrators through enterprise SSO and restricting access to prompts, exports and policy functions implement authenticated, least-privilege administration. Recorded administrative and investigative actions provide an activity trail. The role assignments must actually prevent conflicting duties; SSO alone does not establish authentication strength. ISO/IEC 27001: A.5.3: Adopt the organizational process and validate this requirement against the buyer’s actual ISMS scope; product availability is not implementation. A.8.3: Apply restrictions before the operation. A.8.5: SSO must meet buyer-approved authentication requirements; its presence alone does not prove MFA or session strength. A.8.15: Logs need usable attribution and appropriate retention, protection and analysis; a live view alone is insufficient. - NIST AI RMF: GOVERN 2.1; ISO 42001: A.3.2, Cl. 5.3 — Distinct policy, approval, investigation and exception duties make AI-risk responsibilities and authorities concrete. The roles provide evidence for governance assignments and lines of responsibility; these references do not prescribe enterprise SSO or establish every organization-wide role and communication path.