{"title":"Audit & Evidence (AUD) Requirements — 7 Workforce AI Security Controls","description":"Produce tamper-evident logs and auditor-ready evidence across every control. 7 vendor evaluation requirements with acceptance criteria, verification tests and framework mappings.","updated":"2026-10-21","count":7,"requirements":[{"id":"SPM-011","section":"AI Security Posture Management","requirement":"Support the AI tool approval and review lifecycle","acceptance":"Define and track unapproved versus approved AI tools and MCP servers.","tier":"AT0–AT4, AT6","whyItMatters":"Without a governed approval path, teams route around the control.","verificationMethod":"W","verificationTest":"Walk a tool or MCP server request from intake to a recorded decision.","formerly":"GOV-008","alsoIn":["audit"],"sort":10,"adoptionContext":"Managed assistants, platforms and connected-agent workflows need approval status and periodic review; status should be visible throughout the tool lifecycle.","mappings":[{"frameworks":["rmf","soc2"],"explanation":"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.","kind":"framework","references":{"rmf":["GOVERN 6.1","MANAGE 3.1"],"soc2":["CC9.2","CC5.3"]},"relation":null,"conditions":[]},{"frameworks":["iso27001"],"explanation":"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.","kind":"framework","references":{"iso27001":["A.5.9","A.5.23"]},"relation":null,"conditions":[]},{"frameworks":["iso"],"explanation":"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.","kind":"framework","references":{"iso":["A.4.2"]},"relation":null,"conditions":[]},{"frameworks":["csf"],"explanation":"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.","kind":"framework","references":{"csf":["ID.AM-02"]},"relation":null,"conditions":[]}],"area":"AI Security Posture Management","areaSlug":"SPM","url":"/r/SPM-011","frameworkRefs":{"ISO27001":["A.5.9","A.5.23"],"ISO42001":["A.4.2"],"NIST-CSF":["ID.AM-02"],"NIST-AI-RMF":["GOVERN 6.1","MANAGE 3.1"],"SOC2":["CC9.2","CC5.3"]}},{"id":"GRD-018","section":"Runtime Guardrails","requirement":"Turn acceptable-use policy into enforceable scenarios","acceptance":"Express AUP rules as policies and demonstrate enforcement.","tier":"AT0–AT4","whyItMatters":"An acceptable-use policy only matters if it can be enforced and shown to be enforced.","verificationMethod":"W + POV","verificationTest":"Three clauses from your AUP are expressed as policies and successfully tested in your pilot.","formerly":"GOV-007","alsoIn":["audit"],"sort":28,"adoptionContext":"Acceptable-use rules need concrete scenarios across the listed employee AI contexts rather than a policy that only addresses one application type.","mappings":[{"frameworks":["csf","iso","soc2","iso27001"],"explanation":"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.","kind":"framework","references":{"csf":["GV.PO-01"],"iso":["A.2.2","A.9.2"],"soc2":["CC5.3","CC4.1"],"iso27001":["Cl. 8.1","A.5.10","A.5.36"]},"relation":null,"conditions":[]},{"frameworks":["rmf"],"explanation":"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.","kind":"framework","references":{"rmf":["GOVERN 1.2"]},"relation":null,"conditions":[]}],"area":"Runtime Guardrails","areaSlug":"GRD","url":"/r/GRD-018","frameworkRefs":{"ISO27001":["Cl. 8.1","A.5.10","A.5.36"],"ISO42001":["A.2.2","A.9.2"],"NIST-CSF":["GV.PO-01"],"NIST-AI-RMF":["GOVERN 1.2"],"SOC2":["CC5.3","CC4.1"]}},{"id":"AGT-004","section":"Agent & MCP Governance","requirement":"Attribute every connector and tool call alert to a person","acceptance":"Answer which server and tool were called, by whom, using which identity, every time an alert or intervention fires.","tier":"AT3, AT4, AT6","whyItMatters":"Without attribution, an agent action cannot be investigated or tied to accountability.","verificationMethod":"LT","verificationTest":"Every pilot tool call alert shows the tool used, the surface, the user identity, and the result.","formerly":null,"alsoIn":["aidr","audit"],"sort":39,"adoptionContext":"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":[{"frameworks":["soc2"],"explanation":"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.","kind":"framework","references":{"soc2":["CC2.1","CC7.2"]},"relation":null,"conditions":[]},{"frameworks":["iso","iso27001"],"explanation":"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.\nISO/IEC 27001: Human attribution must not expose credential values.","kind":"framework","references":{"iso":["A.6.2.8"],"iso27001":["A.8.15"]},"relation":null,"conditions":[]},{"frameworks":["owasp"],"explanation":"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.","kind":"framework","references":{"owasp":["ASI03"]},"relation":null,"conditions":[]},{"frameworks":["csf"],"explanation":"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.","kind":"framework","references":{"csf":["DE.AE-03"]},"relation":null,"conditions":[]}],"area":"Agent & MCP Governance","areaSlug":"AGT","url":"/r/AGT-004","frameworkRefs":{"ISO27001":["A.8.15"],"ISO42001":["A.6.2.8"],"NIST-CSF":["DE.AE-03"],"SOC2":["CC2.1","CC7.2"],"OWASP-ASI":["ASI03"]}},{"id":"AUD-001","section":"Audit & Evidence","requirement":"Keep a configurable record of each conversation","acceptance":"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.","tier":"Tier-independent","whyItMatters":"The conversation, not the single prompt, is the unit an investigator or auditor needs to see.","verificationMethod":"W","verificationTest":"Show one pilot conversation's record at full, partial and metadata-only capture settings.","formerly":"GOV-014","alsoIn":["aidr"],"sort":52,"adoptionContext":"Logging-depth choices apply across adoption tiers, balancing needed evidence against data minimization and any applicable retention rule.","mappings":[{"frameworks":["csf","iso","soc2"],"explanation":"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.\nSOC 2: P3.1/P4.2 require the Privacy category and relevant information in scope.","kind":"framework","references":{"csf":["PR.PS-04"],"iso":["A.6.2.8"],"soc2":["CC7.2","P3.1","P4.2"]},"relation":null,"conditions":[]},{"frameworks":["rmf"],"explanation":"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.","kind":"framework","references":{"rmf":["MEASURE 2.8"]},"relation":null,"conditions":[]},{"frameworks":["iso27001"],"explanation":"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.","kind":"framework","references":{"iso27001":["A.8.15","A.5.34"]},"relation":null,"conditions":[]}],"area":"Audit & Evidence","areaSlug":"AUD","url":"/r/AUD-001","frameworkRefs":{"ISO27001":["A.8.15","A.5.34"],"ISO42001":["A.6.2.8"],"NIST-CSF":["PR.PS-04"],"NIST-AI-RMF":["MEASURE 2.8"],"SOC2":["CC7.2","P3.1","P4.2"]}},{"id":"AUD-002","section":"Audit & Evidence","requirement":"Export audit and forensic evidence","acceptance":"API, CSV, webhook or evidence package suitable for audit and incident response use.","tier":"Tier-independent","whyItMatters":"Evidence has to leave the console in a form legal, HR and auditors can use.","verificationMethod":"W","verificationTest":"Export an evidence package for one pilot incident.","formerly":"GOV-002","alsoIn":[],"sort":53,"adoptionContext":"Evidence export serves investigation and audit across adoption tiers; the relevant source and access restrictions still follow the records.","mappings":[{"frameworks":["csf","iso","soc2","iso27001"],"explanation":"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.","kind":"framework","references":{"csf":["RS.AN-07"],"iso":["A.6.2.8"],"soc2":["CC2.1","CC7.3"],"iso27001":["A.5.28"]},"relation":null,"conditions":[]},{"frameworks":["rmf"],"explanation":"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.","kind":"framework","references":{"rmf":["GOVERN 4.3"]},"relation":null,"conditions":[]}],"area":"Audit & Evidence","areaSlug":"AUD","url":"/r/AUD-002","frameworkRefs":{"ISO27001":["A.5.28"],"ISO42001":["A.6.2.8"],"NIST-CSF":["RS.AN-07"],"NIST-AI-RMF":["GOVERN 4.3"],"SOC2":["CC2.1","CC7.3"]}},{"id":"AUD-003","section":"Audit & Evidence","requirement":"Restrict and audit access to raw prompt content","acceptance":"Provide RBAC controls over who can read full prompt content, and record each access to it.","tier":"Tier-independent","whyItMatters":"Raw prompts are among the most sensitive data the control holds, so access must be limited and logged.","verificationMethod":"W","verificationTest":"Only an authorized role can open full prompt content, and each access is recorded.","formerly":"GOV-005","alsoIn":["platform"],"sort":54,"adoptionContext":"Raw prompt access needs protection across the listed employee AI settings, independently of whether the underlying application is sanctioned.","mappings":[{"frameworks":["csf","soc2","iso27001"],"explanation":"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.\nISO/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.","kind":"framework","references":{"csf":["PR.AA-05","PR.DS-01"],"soc2":["CC6.3","CC7.2"],"iso27001":["A.8.3","A.8.15"]},"relation":null,"conditions":[]},{"frameworks":["rmf"],"explanation":"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.","kind":"framework","references":{"rmf":["MEASURE 2.10"]},"relation":null,"conditions":[]}],"area":"Audit & Evidence","areaSlug":"AUD","url":"/r/AUD-003","frameworkRefs":{"ISO27001":["A.8.3","A.8.15"],"NIST-CSF":["PR.AA-05","PR.DS-01"],"NIST-AI-RMF":["MEASURE 2.10"],"SOC2":["CC6.3","CC7.2"]}},{"id":"PLT-008","section":"Platform, Privacy & Assurance","requirement":"Separate administrative roles, and authenticate them through enterprise SSO","acceptance":"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.","tier":"Tier-independent","whyItMatters":"Whoever can change policy or read prompts holds a lot of power, so roles must be separated and every action recorded.","verificationMethod":"W","verificationTest":"Show separate policy, investigation and exception roles, SSO login and the record of an admin action.","formerly":"POL-002","alsoIn":["audit"],"sort":62,"adoptionContext":"Administrative role separation and enterprise authentication apply to governance of workforce AI regardless of the end-user adoption tier.","mappings":[{"frameworks":["csf","soc2","iso27001"],"explanation":"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.\nISO/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.","kind":"framework","references":{"csf":["GV.RR-02","PR.AA-03","PR.AA-05"],"soc2":["CC6.1","CC6.3"],"iso27001":["A.5.3","A.8.2","A.8.3","A.8.5","A.8.15"]},"relation":null,"conditions":[]},{"frameworks":["rmf","iso"],"explanation":"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.","kind":"framework","references":{"rmf":["GOVERN 2.1"],"iso":["A.3.2","Cl. 5.3"]},"relation":null,"conditions":[]}],"area":"Platform, Privacy & Assurance","areaSlug":"PLT","url":"/r/PLT-008","frameworkRefs":{"ISO27001":["A.5.3","A.8.2","A.8.3","A.8.5","A.8.15"],"ISO42001":["A.3.2","Cl. 5.3"],"NIST-CSF":["GV.RR-02","PR.AA-03","PR.AA-05"],"NIST-AI-RMF":["GOVERN 2.1"],"SOC2":["CC6.1","CC6.3"]}}]}