SOC 2 Control Implementation Guide

AI / LLM Governance

AI/LLM Workflow Inventory and Ownership for SOC 2

AI/LLM workflows are inventoried, assigned owners, classified by use case and risk, and reviewed for approved production use.

Use this guide to put the control into operation, decide what records to retain, and check that an auditor can trace the evidence back to the work your team performed.

Maintained by GreenHat Security · Reviewed August 21, 2026

What this control should accomplish

Every production AI or LLM workflow has a known purpose, owner, risk classification, data boundary, model dependency, and approval status.

First SOC 2 program

A credible starting point

Create a lightweight register for customer-facing and internal production workflows, assigning one business owner and one technical owner to each entry.

As the company scales

Make it repeatable

Discover workflows from repositories, model gateways, and cloud accounts; connect inventory changes to release review and periodic risk reassessment.

How to implement AI/LLM Workflow Inventory and Ownership

  1. 1

    Define inventory scope

    Specify which applications, agents, retrieval services, automations, and embedded model features count as production AI workflows.

    You should end up with: Documented AI inventory boundary

  2. 2

    Record each workflow

    Capture purpose, users, owner, model and provider, tools, data types, customer impact, environment, and current status.

    You should end up with: Complete workflow register entries

  3. 3

    Classify practical risk

    Apply defined tiers based on data sensitivity, autonomy, external impact, privileged actions, and dependence on generated output.

    You should end up with: Risk tier with recorded rationale

  4. 4

    Review inventory changes

    Reconcile the register with deployed services and approve new, materially changed, dormant, or retired workflows.

    You should end up with: Dated inventory review and decisions

Evidence to keep, and what it should prove

Build the evidence set in three layers: what defines the control, who approved or reviewed it, and what proves it operated. Collect operating records when the work happens so they remain dated, attributable, correctly scoped, and traceable to the underlying activity.

Before sharing, remove unrelated personal or customer data, never expose passwords, tokens, or secret values, preserve enough source context to authenticate the record, and use the secure exchange approved for the engagement.

Policy / design artifacts

Documents that define the control, its scope, ownership, and expected way of working.

AI workflow inventory

  • Confirm what the record proves

    All active, planned, dormant, and retired production AI workflows are identifiable with their purpose, components, data use, risk, and status.

  • Include this context

    Workflow ID

  • Include this context

    Purpose

  • Include this context

    Environment

  • Include this context

    Model and provider

  • Include this context

    Data categories

  • Include this context

    Risk tier

Weak evidence to avoid

A product-name list that omits workflow boundaries, models, data, environment, risk, and lifecycle status.

owner assignments

  • Confirm what the record proves

    Business and technical accountability is explicitly assigned for each workflow and remains current.

  • Include this context

    Workflow ID

  • Include this context

    Business owner

  • Include this context

    Technical owner

  • Include this context

    Assignment date

  • Include this context

    Responsibilities

  • Include this context

    Approval

Weak evidence to avoid

A generic team name in a spreadsheet with no accountable role, assignment date, or accepted responsibilities.

Approval / review evidence

Records showing that an accountable person reviewed, approved, challenged, or accepted the work.

risk classifications

  • Confirm what the record proves

    Each workflow received a repeatable risk decision based on its data, autonomy, impact, tools, and output reliance.

  • Include this context

    Workflow ID

  • Include this context

    Risk tier

  • Include this context

    Decision factors

  • Include this context

    Assessor

  • Include this context

    Assessment date

  • Include this context

    Required safeguards

Weak evidence to avoid

A high-medium-low label with no rationale, assessor, criteria, or required treatment.

review records

  • Confirm what the record proves

    An authorized reviewer periodically confirmed workflow scope, owner, risk, approval status, and required follow-up.

  • Include this context

    Review date

  • Include this context

    Inventory scope

  • Include this context

    Reviewer

  • Include this context

    Decisions

  • Include this context

    Exceptions

  • Include this context

    Action owners and due dates

Weak evidence to avoid

Meeting notes saying inventory reviewed without the population, decisions, exceptions, or follow-up.

Which records should you prepare for the audit?

Type 1

Evidence at the as-of date

Retain the current workflow register with approved owners and risk decisions plus the latest completed inventory review as of the selected date.

Type 2

Evidence across the review period

Account for every AI workflow active at any time during the period and every new, materially changed, suspended, or retired workflow, together with each scheduled inventory review and resulting ownership or risk decision.

Completeness check

Reconcile the register to production model-gateway clients, cloud AI resources, deployed services, and repositories; explain unregistered runtime callers and verify retired workflows no longer execute.

Build the record set from

  • AI workflow register
  • Model gateway
  • Production deployment platform
  • Source control
  • Cloud AI account inventory
  • Risk register

Keep these fields for each record

  • Workflow ID
  • Lifecycle status and dates
  • Owner
  • Model or provider
  • Environment
  • Data categories
  • Risk tier
  • Approval
  • Change or review event

How an auditor may test this control

Use this checklist to prepare for procedures an auditor may perform. The exact steps and sample selection depend on your engagement scope and the service auditor's professional judgment.

  • Confirm the intended control outcome

    Determine whether the control is designed to achieve this result: Every production AI or LLM workflow has a known purpose, owner, risk classification, data boundary, model dependency, and approval status.

  • Confirm ownership and operating cadence

    Compare the documented owner with the intended role (AI Workflow Owner / CISO / Engineering), then compare dated records with the stated cadence: Per workflow/change; review at least annually.

  • Establish the complete audit record set

    Reconcile the register to production model-gateway clients, cloud AI resources, deployed services, and repositories; explain unregistered runtime callers and verify retired workflows no longer execute.

  • Prepare the as-of-date evidence for a Type 1 engagement

    Retain the current workflow register with approved owners and risk decisions plus the latest completed inventory review as of the selected date.

  • Prepare period evidence for a Type 2 engagement

    Account for every AI workflow active at any time during the period and every new, materially changed, suspended, or retired workflow, together with each scheduled inventory review and resulting ownership or risk decision.

  • Inspect the policy / design artifacts

    Documents that define the control, its scope, ownership, and expected way of working.

    • Inspect AI workflow inventory

      For each selected record, confirm it demonstrates All active, planned, dormant, and retired production AI workflows are identifiable with their purpose, components, data use, risk, and status.

      • Workflow ID
      • Purpose
      • Environment
      • Model and provider
      • Data categories
      • Risk tier
    • Inspect owner assignments

      For each selected record, confirm it demonstrates Business and technical accountability is explicitly assigned for each workflow and remains current.

      • Workflow ID
      • Business owner
      • Technical owner
      • Assignment date
      • Responsibilities
      • Approval
  • Inspect the approval / review evidence

    Records showing that an accountable person reviewed, approved, challenged, or accepted the work.

    • Inspect risk classifications

      For each selected record, confirm it demonstrates Each workflow received a repeatable risk decision based on its data, autonomy, impact, tools, and output reliance.

      • Workflow ID
      • Risk tier
      • Decision factors
      • Assessor
      • Assessment date
      • Required safeguards
    • Inspect review records

      For each selected record, confirm it demonstrates An authorized reviewer periodically confirmed workflow scope, owner, risk, approval status, and required follow-up.

      • Review date
      • Inventory scope
      • Reviewer
      • Decisions
      • Exceptions
      • Action owners and due dates
  • Trace the control from design to operation

    Use the categories that apply to this control: connect any policy or design artifact to its approval or review record, then trace a selected operating record through execution, result, and any exception or remediation.

Common implementation and evidence gaps

  • The register covers sanctioned products but misses experiments that reached production.
  • A team name is listed instead of an accountable individual role.
  • Risk tiers have labels but no repeatable decision factors.
  • Retired workflows remain connected to providers, tools, or data.

Before you call this control ready

  • Can deployment and gateway records be reconciled to the workflow register?
  • Does every active workflow have business and technical accountability?
  • Would a model, tool, or customer-data change trigger reassessment?
  • Are disabled workflows removed from credentials, integrations, and monitoring?

Trust Services Criteria references

These identifiers help you navigate related Trust Services Criteria. They do not reproduce the criteria or prove that this control fully addresses them in your environment.

  • CC2.1
  • CC3.2
  • CC5.2
  • C1.1
  • P4.1

Confirm final scope, mappings, and testing expectations with your service auditor. SOC 2® is an AICPA trademark; GreenHat Security is not affiliated with or endorsed by AICPA.