SOC 2 is the AICPA’s security attestation framework used by organizations to demonstrate controls over access, system operations, change management and vendor risk.
AIUC and AICPA have partnered to offer SOC 2 + AIUC-1 together. Organizations earn a full SOC 2 attestation and AIUC-1 certification together in one engagement with the existing SOC 2 auditor.
CPA firms assess an organization’s controls against the Trust Services Criteria developed by the AICPA, with security as the required baseline, and availability, processing integrity, confidentiality and privacy as optional extensions.
AIUC-1 complements SOC 2. Certification against AIUC-1:
- Addresses AI-specific controls not covered by SOC 2
- Maps SOC 2’s TSCs to AI-specific requirements
- Includes quarterly third-party technical testing of agents against real-world risks
See the reverse mapping of AIUC-1 requirements by SOC 2 criteria here.
SOC 2 crosswalks by criteria
| SOC 2 criteria | SOC 2 description | Relevant AIUC-1 requirements | Gap analysis |
|---|---|---|---|
| A1.1: Capacity management | The entity maintains, monitors, and evaluates current processing capacity and use of system components (infrastructure, data, and software) to manage capacity demand and to enable the implementation of additional capacity to help meet its objectives. | SOC 2 asks for managing processing capacity and demand, but AIUC-1 has no capacity or availability requirement, so there is no overlap. | |
| A1.2: Environmental protection and backups | The entity authorizes, designs, develops or acquires, implements, operates, approves, maintains, and monitors environmental protections, software, data backup processes, and recovery infrastructure to meet its objectives. | SOC 2 asks for environmental protections, backups and recovery infrastructure, but AIUC-1 has no backup or recovery requirement, so there is no overlap. | |
| A1.3: Recovery plan testing | The entity tests recovery plan procedures supporting system recovery to meet its objectives. | SOC 2 asks for testing recovery-plan procedures, but AIUC-1 has no recovery-testing requirement, so there is no overlap. | |
| C1.1: Identify and maintain confidential information | The entity identifies and maintains confidential information to meet the entity’s objectives related to confidentiality. | SOC 2 asks for identifying and maintaining confidential information, AIUC-1 requires policies and safeguards against AI-enabled confidential-data exposure across internal IP and PII. | |
| C1.2: Dispose of confidential information | The entity disposes of confidential information to meet the entity’s objectives related to confidentiality. | SOC 2 asks for disposing of confidential information, AIUC-1 is scoped to data policies and PII protection. DLP system integration is included as a supplemental control in A006 | |
| CC1.1: Commitment to integrity and ethical values | COSO Principle 1: The entity demonstrates a commitment to integrity and ethical values. | SOC 2 asks for an entity-wide commitment to integrity and ethical values; AIUC-1’s closest touchpoint is E010 (AI acceptable use policy), which sets conduct expectations for AI use but is not an entity-wide ethics or code-of-conduct program. | |
| CC1.2: Board independence and oversight | COSO Principle 2: The board of directors demonstrates independence from management and exercises oversight of the development and performance of internal control. | SOC 2 asks for independent board oversight of internal control, but AIUC-1 has no board-governance requirement, so there is no overlap. | |
| CC1.3: Structures, authorities, and responsibilities | COSO Principle 3: Management establishes, with board oversight, structures, reporting lines, and appropriate authorities and responsibilities in the pursuit of objectives. | SOC 2 asks for entity-wide structures, reporting lines and authorities, but AIUC-1 only assigns accountable leads and internal reviews for AI systems, so the difference is organizational scope. E004 assigns a named accountable lead for AI system changes and documents approval authority; E008 institutes regular internal process reviews. Entity-wide management structure is outside AIUC-1’s scope. | |
| CC1.4: Attract, develop, and retain talent | COSO Principle 4: The entity demonstrates a commitment to attract, develop, and retain competent individuals in alignment with objectives. | SOC 2 asks for attracting, developing and retaining competent individuals, but AIUC-1 has no workforce competence or training requirement, so there is no overlap. | |
| CC1.5: Accountability for internal control | COSO Principle 5: The entity holds individuals accountable for their internal control responsibilities in the pursuit of objectives. | SOC 2 asks for holding all individuals accountable for internal-control responsibilities, but AIUC-1 only names accountable owners for AI system changes, so the difference is breadth of accountability. E004 names accountable owners for AI changes. There is no entity-wide performance-accountability mechanism (incentives, evaluation, discipline), which is the core of CC1.5. | |
| CC2.1: Use of relevant, quality information | COSO Principle 13: The entity obtains or generates and uses relevant, quality information to support the functioning of internal control. | SOC 2 asks for quality information supporting internal control across the entity. AIUC-1 mandates AI specific activity logging and risk monitoring, so the difference is the information universe covered. E015 (AI activity logs) and C008 (risk-category monitoring) generate relevant, quality information for the AI system - a subset of the entity’s information needs. | |
| CC2.2: Internal communication of controls | COSO Principle 14: The entity internally communicates information, including objectives and responsibilities for internal control, necessary to support the functioning of internal control. | SOC 2 asks for internal communication of control objectives and responsibilities, but AIUC-1 has no internal-communication requirement, so there is no overlap. | |
| CC2.3: External communication of controls | COSO Principle 15: The entity communicates with external parties regarding matters affecting the functioning of internal control. | B001: Third-party testing for security riskB003: Manage public release of technical detailsC010: Third-party testing for safety riskC011: [Retired] Third-party testing for out-of-scope outputsC012: [Retired] Third-party testing for customer-defined riskD002: [Retired] Third-party testing for hallucinationsD004: Third-party testing for reliability riskE016: Implement AI disclosure mechanismsE017: Document system transparency policy | SOC 2 asks for communicating with external parties on matters affecting internal control; AIUC-1 requires third-party testing with results documented for external stakeholders (B001, C010-C012, D002, D004) and user-facing disclosure and transparency mechanisms (E016, E017), scoped to AI systems. |
| CC3.1: Clear objectives for risk assessment | COSO Principle 6: The entity specifies objectives with sufficient clarity to enable the identification and assessment of risks relating to objectives. | SOC 2 asks for objectives specific enough to enable risk identification, but AIUC-1 asks for a risk taxonomy built on system capabilities and deployment context, so the difference is only that objectives are AI-scoped. C001 is the direct AI analog of risk-objective specification: it defines the risk categories against which all AIUC-1 testing and safeguards are organized. | |
| CC3.2: Identify and analyze risks | COSO Principle 7: The entity identifies risks to the achievement of its objectives across the entity and analyzes risks as a basis for determining how the risks should be managed. | SOC 2 asks for identifying and analyzing risks across the entity, but AIUC-1 identifies and tests only AI risks, so the difference is the risk universe. C001 identifies AI risks via the taxonomy, C002 analyzes them through pre-deployment testing across categories, C008 monitors them in operation. | |
| CC3.3: Assess fraud risk | COSO Principle 8: The entity considers the potential for fraud in assessing risks to the achievement of objectives. | SOC 2 asks for considering fraud potential in risk assessment, but AIUC-1 has no fraud-risk requirement, so there is no overlap. | |
| CC3.4: Identify and assess change | COSO Principle 9: The entity identifies and assesses changes that could significantly impact the system of internal control. | SOC 2 asks for identifying changes that could impact internal control, but AIUC-1 has no change-impact risk-assessment requirement mapped here, so there is no overlap. | |
| CC4.1: Ongoing and separate evaluations | COSO Principle 16: The entity selects, develops, and performs ongoing and/or separate evaluations to ascertain whether the components of internal control are present and functioning. | B001: Third-party testing for security riskC010: Third-party testing for safety riskC011: [Retired] Third-party testing for out-of-scope outputsC012: [Retired] Third-party testing for customer-defined riskD002: [Retired] Third-party testing for hallucinationsD004: Third-party testing for reliability riskE008: Review internal processesE013: Implement quality management system | SOC 2 asks for ongoing or separate evaluations that controls are present and functioning, but AIUC-1 asks for quarterly third-party testing plus internal reviews of AI controls, so the difference is only the control population evaluated. E008 (internal process reviews), B001/C010-C012/D002/D004 (quarterly third-party technical testing across security, safety and reliability) and C002 (pre-deployment testing) form a robust evaluation regime for AI controls. |
| CC4.2: Evaluate and communicate deficiencies | COSO Principle 17: The entity evaluates and communicates internal control deficiencies in a timely manner to those parties responsible for taking corrective action, including senior management and the board of directors, as appropriate. | SOC 2 asks for evaluating and communicating control deficiencies to those responsible for correction, but AIUC-1 only drives remediation of AI control failures, so the difference is deficiency scope and escalation breadth. Failure plans (E001-E003) assign owners and remediation; testing programs (B001) surface deficiencies; E008 documents review records and approvals. | |
| CC5.1: Select and develop control activities | COSO Principle 10: The entity selects and develops control activities that contribute to the mitigation of risks to the achievement of objectives to acceptable levels. | SOC 2 asks for control activities mitigating risks to all entity objectives, but AIUC-1’s safeguard families mitigate AI risks only, so the difference is the risk universe addressed. The safeguards (C003, C005, B006, D003) are explicitly organized around the C001 risk taxonomy. | |
| CC5.2: General controls over technology | COSO Principle 11: The entity also selects and develops general control activities over technology to support the achievement of objectives. | SOC 2 asks for general controls over all technology, but AIUC-1 asks for access, environment and code controls over the AI stack, so the difference is technology footprint. B007 (access controls), B008 (deployment-environment security incl. encryption/authorization) and B010 (secure code patterns) are technology general controls for the AI stack - a subset of entity IT. | |
| CC5.3: Deploy controls through policies | COSO Principle 12: The entity deploys control activities through policies that establish what is expected and in procedures that put policies into action. | SOC 2 asks controls be documented in policies generally, where AIUC-1 focuses on a scoped list of policies that are important for AI systems (A001, A002, E010). The spirit of COSO principle 12 is found in E004 and E008 as well | |
| CC6.1: Logical access security | The entity implements logical access security software, infrastructure, and architectures over protected information assets to protect them from security events to meet the entity’s objectives. | SOC 2 asks for logical access architecture over all protected assets, but AIUC-1 asks for access controls over AI systems, agents and their deployment environment, so the difference is asset scope. B007 (AI user access), B008 (deployment-environment security) and A003 (task/role/context-based data-access limits for agents) cover logical access for AI assets. | |
| CC6.2: User registration and deprovisioning | Prior to issuing system credentials and granting system access, the entity registers and authorizes new internal and external users whose access is administered by the entity. For those users whose access is administered by the entity, user system credentials are removed when user access is no longer authorized. | SOC 2 asks for registering, authorizing and de-provisioning every system credential, but AIUC-1 asks for maintained access and admin privileges on AI systems, so the difference is lifecycle prescriptiveness. B007 requires user access controls and admin privileges for AI systems in line with policy; the entity-wide joiner/mover/leaver credential lifecycle is broader and more prescriptive. | |
| CC6.3: Role-based access management | The entity authorizes, modifies, or removes access to data, software, functions, and other protected information assets based on roles, responsibilities, or the system design and changes, giving consideration to the concepts of least privilege and segregation of duties, to meet the entity’s objectives. | SOC 2 asks for role-based least-privilege access with segregation of duties, but AIUC-1 asks for the same discipline applied to AI users and agents, so the difference is only system scope. B007 (access/admin privileges), A003 (limit agent data access by task, user role, agent role and context - least privilege for agents) and B006 (prevent actions beyond authorized privileges). | |
| CC6.4: Physical access restrictions | The entity restricts physical access to facilities and protected information assets (for example, data center facilities, backup media storage, and other sensitive locations) to authorized personnel to meet the entity’s objectives. | SOC 2 asks for restricting physical access to facilities, but AIUC-1 has no physical-security requirement, so there is no overlap. | |
| CC6.5: Secure asset disposal | The entity discontinues logical and physical protections over physical assets only after the ability to read or recover data and software from those assets has been diminished and is no longer required to meet the entity’s objectives. | SOC 2 asks for rendering data unrecoverable before disposing of physical assets, but AIUC-1 has no media-sanitization requirement, so there is no overlap. | |
| CC6.6: Protection against external threats | The entity implements logical access security measures to protect against threats from sources outside its system boundaries. | SOC 2 asks for perimeter defenses against external threats, but AIUC-1 asks for AI-system defenses, so the difference is the boundary protected. B004 (prevent endpoint scraping/probing), B008 (deployment-environment security) and B002 (adversarial-input detection) defend the AI system boundary; the entity’s full external-threat surface is broader. | |
| CC6.7: Secure transmission and removal | The entity restricts the transmission, movement, and removal of information to authorized internal and external users and processes, and protects it during transmission, movement, or removal to meet the entity’s objectives. | SOC 2 asks for protecting information during transmission, movement and removal; AIUC-1 requires encryption, access controls and authorization within the AI deployment environment (B008). Media movement and removal are not separately addressed. | |
| CC6.8: Malicious software prevention | The entity implements controls to prevent or detect and act upon the introduction of unauthorized or malicious software to meet the entity’s objectives. | SOC 2 asks for preventing or detecting the introduction of unauthorized or malicious software; AIUC-1 addresses the AI analogs: adversarial inputs as attack payloads (B002), insecure generated code (B010, C006) and deployment-environment protection (B008). | |
| CC7.1: Vulnerability detection and monitoring | To meet its objectives, the entity uses detection and monitoring procedures to identify (1) changes to configurations that result in the introduction of new vulnerabilities, and (2) susceptibilities to newly discovered vulnerabilities. | SOC 2 asks for detecting new vulnerabilities from configuration changes and emerging threats; AIUC-1 requires monitoring anomalous third-party access patterns (E009) and preventing vulnerable outputs and generated code (C006, B010), so the difference is AI scoping. | |
| CC7.2: Anomaly monitoring | The entity monitors system components and the operation of those components for anomalies that are indicative of malicious acts, natural disasters, and errors affecting the entity’s ability to meet its objectives; anomalies are analyzed to determine whether they represent security events. | SOC 2 asks for monitoring components for anomalies indicating malicious acts or errors, whereas AIUC-1 asks for adversarial input detection, activity logging and third-party access monitoring, so the difference is detection depth. E015 (activity logs) and E009 (third-party access monitoring) record events, while B002 analyzes inputs to detect malicious activity. | |
| CC7.3: Security event evaluation | The entity evaluates security events to determine whether they could or have resulted in a failure of the entity to meet its objectives (security incidents) and, if so, takes actions to prevent or address such failures. | SOC 2 asks for evaluating security events and acting on incidents, and AIUC-1 asks for monitoring to triage AI events and an AI breach failure plan that acts on incidents. E001 (security-breach failure plan with owners and actions) plus C008 (risk monitoring) support event evaluation and escalation for AI systems. | |
| CC7.4: Incident response | The entity responds to identified security incidents by executing a defined incident-response program to understand, contain, remediate, and communicate security incidents, as appropriate. | SOC 2 asks for a defined incident-response program for all security incidents, and AIUC-1 asks for documented AI failure plans with owners, notification and remediation. E001 requires a documented AI failure plan for privacy/security breaches assigning accountable owners and establishing notification and remediation with third-party support. | |
| CC7.5: Recovery from incidents | The entity identifies, develops, and implements activities to recover from identified security incidents. | SOC 2 asks for recovery activities restoring operations after incidents, but AIUC-1 only asks for remediation within failure plans, so the difference is restoration and recovery. E001 requires remediation, but system recovery/restoration (backups, failover, restoration procedures) is not required explicitly by AIUC-1 | |
| CC8.1: Change management | The entity authorizes, designs, develops or acquires, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures to meet its objectives. | SOC 2 asks for authorizing, designing, testing and approving all system changes, AIUC-1 asks for documented review and approval of AI changes combined with pre-deployment testing. | |
| CC9.1: Business disruption risk mitigation | The entity identifies, selects, and develops risk mitigation activities for risks arising from potential business disruptions. | SOC 2 asks for risk mitigation against business disruptions, but AIUC-1 has no business-continuity requirement, so there is no overlap. | |
| CC9.2: Vendor and partner risk | The entity assesses and manages risks associated with vendors and business partners. | SOC 2 asks for assessing risks from all vendors and partners, and AIUC-1 asks for due diligence on AI and model vendors. E006 requires AI vendor due diligence for foundation/upstream model providers covering data handling, PII controls, security and compliance. | |
| P1.1: Privacy notice to data subjects | The entity provides notice to data subjects about its privacy practices to meet the entity’s objectives related to privacy. The notice is updated and communicated to data subjects in a timely manner for changes to the entity’s privacy practices, including changes in the use of personal information, to meet the entity’s objectives related to privacy. | SOC 2 asks for privacy notices to data subjects with timely updates, but AIUC-1 asks for AI data policies communicated to customers without exact specifications of update timelines. A001/A002 communicate data-use, retention and output policies to customers. Data subjects are not necessarily the customer, and there is no notice-update lifecycle - hence Moderate. | |
| P2.1: Choice and consent | The entity communicates choices available regarding the collection, use, retention, disclosure, and disposal of personal information to the data subjects and the consequences, if any, of each choice. Explicit consent for the collection, use, retention, disclosure, and disposal of personal information is obtained from data subjects or other authorized persons, if required. Such consent is obtained only for the intended purpose of the information to meet the entity’s objectives related to privacy. The entity’s basis for determining implicit consent for the collection, use, retention, disclosure, and disposal of personal information is documented. | SOC 2 asks for communicated choices and documented consent across the data lifecycle; AIUC-1 asks for output opt-in/opt-out, deletion rights and data-use terms. A002 (output opt-in/out and deletion) and A001 (customer data rights) provide choices. | |
| P3.1: Consistent collection of personal information | Personal information is collected consistent with the entity’s objectives related to privacy. | SOC 2 asks for collecting personal information consistent with privacy objectives, AIUC-1 requires explicit definition of input and output ownership policies | |
| P3.2: Explicit consent before collection | For information requiring explicit consent, the entity communicates the need for such consent as well as the consequences of a failure to provide consent for the request for personal information and obtains the consent prior to the collection of the information to meet the entity’s objectives related to privacy. | SOC 2 asks for explicit consent obtained before collection, but AIUC-1 only asks for data policies referencing customer rights and opt-ins, so the difference is a consent mechanism. A001/A002 touch consent and opt-in at policy level; no explicit-consent-before-collection mechanism is mandated. | |
| P4.1: Limit use of personal information | The entity limits the use of personal information to the purposes identified in the entity’s objectives related to privacy. | SOC 2 asks for limiting personal-information use to identified purposes, AIUC-1 asks for defined permitted data use in its policies. | |
| P4.2: Retention of personal information | The entity retains personal information consistent with the entity’s objectives related to privacy. | SOC 2 asks for retaining personal information per privacy objectives; AIUC-1 asks for retention periods in the AI input data policy (A001) and requires those commitments be upheld in log storage policies (E015) as well. | |
| P4.3: Secure disposal of personal information | The entity securely disposes of personal information to meet the entity’s objectives related to privacy. | SOC 2 asks for secure disposal of personal information, AIUC-1 asks for deletion policies plus safeguards against PII persisting in outputs and logs. | |
| P5.1: Data subject access rights | The entity grants identified and authenticated data subjects the ability to access their stored personal information for review and, upon request, provides physical or electronic copies of that information to data subjects to meet the entity’s objectives related to privacy. If access is denied, data subjects are informed of the denial and reason for such denial, as required, to meet the entity’s objectives related to privacy. | SOC 2 asks for giving data subjects access to their stored personal information, AIUC-1 has a supplemental control (A001.3) requiring organizations to document processes for handling end-user data subject rights. | |
| P5.2: Correction of personal information | The entity corrects, amends, or appends personal information based on information provided by data subjects and communicates such information to third parties, as committed or required, to meet the entity’s objectives related to privacy. If a request for correction is denied, data subjects are informed of the denial and reason for such denial to meet the entity’s objectives related to privacy. | SOC 2 asks for correcting personal information on data-subject request, but AIUC-1 has no rectification requirement, so there is no overlap. | |
| P6.1: Disclosure with consent | The entity discloses personal information to third parties with the explicit consent of data subjects and such consent is obtained prior to disclosure to meet the entity’s objectives related to privacy. | SOC 2 asks for third-party disclosure only with data-subject consent, AIUC-1 requires clear input/output data ownership and usage in policies | |
| P6.2: Record of authorized disclosures | The entity creates and retains a complete, accurate, and timely record of authorized disclosures of personal information to meet the entity’s objectives related to privacy. | SOC 2 asks for a record of authorized disclosures of personal information, but AIUC-1 has no disclosure-record requirement, so there is no overlap. | |
| P6.3: Record of unauthorized disclosures | The entity creates and retains a complete, accurate, and timely record of detected or reported unauthorized disclosures (including breaches) of personal information to meet the entity’s objectives related to privacy. | SOC 2 asks for a record of unauthorized disclosures and breaches, AIUC-1 requires documenting AI failure plans for privacy & security breaches with a control on defining breach notification procedures. | |
| P6.4: Vendor privacy commitments | The entity obtains privacy commitments from vendors and other third parties who have access to personal information to meet the entity’s objectives related to privacy. The entity assesses those parties’ compliance on a periodic and as-needed basis and takes corrective action, if necessary. | SOC 2 asks for privacy commitments from all vendors handling personal information, AIUC-1 asks for due diligence on AI and model vendors’ data and PII controls, and requires monitoring third party access. E006 requires AI vendor due diligence covering data handling, PII controls, security and compliance, assessed for foundation/upstream model providers. E009 requires monitoring & logging third-party access | |
| P6.5: Vendor breach notification commitments | The entity obtains commitments from vendors and other third parties with access to personal information to notify the entity in the event of actual or suspected unauthorized disclosures of personal information. Such notifications are reported to appropriate personnel and acted on in accordance with established incident-response procedures to meet the entity’s objectives related to privacy. | SOC 2 asks for vendor breach-notification commitments, but AIUC-1 asks for vendor due diligence and an internal breach plan without the notification clause. E006 (vendor due diligence) plus E001 (breach failure plan) partially cover this; AIUC-1 does not explicitly mandate obtaining the vendor notification commitment. | |
| P6.6: Breach notification obligations | The entity provides notification of breaches and incidents to affected data subjects, regulators, and others to meet the entity’s objectives related to privacy. | SOC 2 asks for notifying data subjects and regulators of breaches, AIUC-1 asks for a breach plan establishing notification plus documented regulatory obligations, so the difference is only prescriptive detail. E001 requires establishing notification (with legal/PR/insurer support as needed); E012 documents applicable regulatory obligations. | |
| P6.7: Accounting of disclosures | The entity provides data subjects with an accounting of the personal information held and disclosure of the data subjects’ personal information, upon the data subjects’ request, to meet the entity’s objectives related to privacy. | SOC 2 asks for giving data subjects an accounting of their personal information and its disclosures, but AIUC-1 has no accounting requirement, so there is no overlap. | |
| P7.1: Data quality | The entity collects and maintains accurate, up-to-date, complete, and relevant personal information to meet the entity’s objectives related to privacy. | SOC 2 asks for accurate, complete and relevant personal information, but AIUC-1 has no PI data-quality requirement, so there is no overlap. | |
| P8.1: Inquiry and complaint handling | The entity implements a process for receiving, addressing, resolving, and communicating the resolution of inquiries, complaints, and disputes from data subjects and others and periodically monitors compliance to meet the entity’s objectives related to privacy. Corrections and other necessary actions related to identified deficiencies are made or taken in a timely manner. | SOC 2 asks for a process to resolve data-subject inquiries, complaints and disputes; AIUC-1’s C009 (real-time user feedback and intervention) enables complaint intake for AI interactions but includes no resolution or dispute process. | |
| PI1.1: Relevant processing information | The entity obtains or generates, uses, and communicates relevant, quality information regarding the objectives related to processing, including definitions of data processed and product and service specifications, to support the use of products and services. | SOC 2 asks for definitions of data processed and product and service specifications, but AIUC-1 as mapped only asks for documenting AI processing locations, so the difference is specification depth. E011 documents where AI data is processed - tangential to defining what is processed and to what specification. | |
| PI1.2: Input completeness and accuracy | The entity implements policies and procedures over system inputs, including controls over completeness and accuracy, to result in products, services, and reporting to meet the entity’s objectives. | SOC 2 asks for input controls ensuring completeness and accuracy, AIUC-1 requires hallucination prevention and tool call restrictions, the main accuracy domains for AI | |
| PI1.3: Processing controls | The entity implements policies and procedures over system processing to result in products, services, and reporting to meet the entity’s objectives. | SOC 2 asks for processing controls yielding correct products and services; AIUC-1 requires hallucination prevention (D001) and tool call restrictions (D003), the main accuracy domains for AI, though it has no general processing-policy requirement. | |
| PI1.4: Output delivery accuracy | The entity implements policies and procedures to make available or deliver output completely, accurately, and timely in accordance with specifications to meet the entity’s objectives. | A002: Establish output data policyB009: Limit output over-exposureC003: Prevent harmful outputsC004: Prevent out-of-scope outputsC005: Prevent agent-specific high risk outputsC006: Prevent output vulnerabilitiesD001: Prevent hallucinated outputsD002: [Retired] Third-party testing for hallucinationsD003: Restrict unsafe tool calls | SOC 2 asks for complete, accurate and timely output delivery, AIUC-1 requires hallucination prevention and tool call restrictions, the main accuracy domains for AI |
| PI1.5: Storage completeness and accuracy | The entity implements policies and procedures to store inputs, items in processing, and outputs completely, accurately, and timely in accordance with system specifications to meet the entity’s objectives. | SOC 2 asks for storing inputs, items in processing and outputs completely and accurately, AIUC-1 defines input and output policies including retention (A001, A002), PII protection (A006) and storage of logs (E015) |
37.782274° N -122.392147° WFIG. A (SITE INDEX)
Artificial Intelligence Underwriting Company
CodeStructural unita.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.
I. Standard
II. Learn
III. Office
100© AIUC — ALL RIGHTS RESERVED