← All posts

Compliance & Regulation

402 posts on compliance & regulation.

NIST SP 800-53 AI Controls Mapping: The Control IDs an AI Gateway Actually Answers

SP 800-53 Revision 5 organises its catalogue into 20 control families, and the COSAiS overlay work that will tailor it for AI is still in draft. An AI system inside an authorisation boundary is assessed today against control identifiers that already exist. This maps the specific controls an identity-aware gateway on AI traffic satisfies, at the AC-3, AC-4, AU-3, AU-9, IA-2, SC-7, SI-4 and SR-3 level, and names the ones it contributes nothing to.

nistcomplianceai-governancearchitectureauditpolicy-enforcement
Read post →

Connecticut LLM Requirements: Scope the Use Before You Build the Control

Connecticut regulates LLM deployments through use-specific rules rather than one universal model standard. Public Act 26-15 covers AI subscriptions, companions, employment technology, certain state-agency systems, frontier developers, and audiovisual provenance. The CTDPA separately governs consumer personal data, profiling, sensitive data, and rights. This guide maps common LLM uses to the correct requirement and the HTTP control evidence available.

complianceai-governanceregulationllmai-security
Read post →

Connecticut AI Risk Assessment: Separate the State, Consumer, and Employment Tests

Connecticut AI risk assessment duties depend on role and use. Public Act 26-15 requires state agencies to assess authorized AI procurement and post the assessment before deployment. The CTDPA requires controllers to assess personal-data processing that presents heightened risk. Employment technology adds a separate disclosure and discrimination analysis. This guide turns those branches into a scoped assessment backed by runtime evidence.

complianceai-governanceregulationauditai-security
Read post →

Connecticut AI Incident Reporting: Three Triggers, Three Different Records

Connecticut has no single, general AI incident report. Public Act 26-15 creates an internal catastrophic-risk reporting process for large frontier developers, the state breach statute governs compromised personal information, and the Connecticut Data Privacy Act gives the Attorney General authority over consumer-data violations. This guide separates the triggers, recipients, clocks, and evidence each path requires.

complianceai-governanceregulationauditai-security
Read post →

SOX AI Compliance Checklist for Authenticated LLM Traffic

A SOX AI compliance checklist should test the real route between an authenticated user or agent and an LLM. This checklist assigns scope, authorization, data-flow policy, logging, retrieval, exception handling, ownership, and explicit boundaries so the resulting evidence supports the governing programme without claiming that one gateway delivers full compliance.

ai-complianceai-governancesoxfinancial-reportingauditinternal-controls
Read post →

CCPA LLM Requirements: Current Duties and the 2027 ADMT Deadline

CCPA duties attach to LLM deployments through ordinary collection, purpose, retention, contracting, consumer-rights, sensitive-information, and security rules. The CPPA risk-assessment regulations add current pre-launch work for specified processing, while the narrower ADMT consumer-rights rules reach significant decisions by January 1, 2027. This guide separates those obligations and their deadlines.

ai-complianceai-governancecomplianceregulationllmpolicy-enforcement
Read post →

Canada AIDA LLM Requirements: The Current Baseline for AI Traffic

Canada has no AIDA requirements for LLMs because Bill C-27 died before passage. The current baseline comes from privacy and public-sector rules already in force: PIPEDA accountability, appropriate purposes, consent, limiting use and disclosure, safeguards and breach records; Quebec Law 25 duties where applicable; and federal guidance and automated-decision rules for government institutions. This guide attaches those duties to the outbound prompt and inbound response.

ai-complianceai-governancecomplianceregulationllmpolicy-enforcement
Read post →

Canada AIDA AI Risk Assessment: The Privacy Tests That Apply Today

AIDA died with Bill C-27 before becoming law. A Canadian AI risk assessment now starts with the duties already in force: PIPEDA accountability, appropriate purposes, meaningful consent and safeguards; Quebec Law 25 privacy impact assessments and automated-decision rights where applicable; and the federal Directive on Automated Decision-Making for covered government systems. The unit of analysis is the real data flow, including each LLM request.

ai-complianceai-governancecomplianceregulationauditpolicy-enforcement
Read post →

HITRUST LLM Requirements for Identity, Data, and Evidence

HITRUST LLM requirements are an application of scoped security and privacy controls to a real model workflow, rather than a universal checklist for every deployment. This guide translates the request path into requirements for identity, prompt data, approved destinations, configuration, incident handling, and evidence.

ai-compliancehitrustllmauditidentity-and-authorizationpolicy-enforcement
Read post →

HITRUST AI Incident Reporting for Model Traffic

HITRUST AI incident reporting needs request-level facts before an incident team can classify impact or meet an external notice duty. This guide defines the AI incident record, explains how to preserve model-route evidence, and separates internal response from legal reporting decisions.

ai-compliancehitrustincident-responseauditllm-securitypolicy-enforcement
Read post →

HITRUST AI Risk Assessment at the LLM Request Boundary

A HITRUST AI risk assessment should connect the system inventory and risk analysis to the exact HTTP requests that reach model providers. This guide defines the assessment unit, maps risks to identity and data controls, and specifies evidence that an assessor can sample without claiming that a gateway covers the whole HITRUST scope.

ai-complianceai-governancehitrustrisk-assessmentauditpolicy-enforcement
Read post →

Gong AI Compliance Requires an Operating Control File

Gong publishes a substantial compliance posture, including SOC 2 Type II and ISO/IEC 42001:2023, plus customer controls for retention, redaction, access, and deletion. A Gong AI compliance program still needs a customer-owned operating file that records lawful purpose, recording rules, enabled features, data scope, control owners, change approvals, and recurring evidence tests. This article separates vendor assurance from the controls the deploying enterprise must operate.

ai-complianceai-governancecomplianceauditidentity-and-authorizationpolicy-enforcement
Read post →