Prompt, Model, and Configuration Change Control for SOC 2

What this control should accomplish

Changes to prompts, models, tools, retrieval, system messages, and orchestration are reviewed, validated, released, and reversible as identifiable versions.

How to implement Prompt, Model, and Configuration Change Control

1. 1

   Define versioned components

   Identify prompts, system messages, model identifiers, parameters, tools, retrieval settings, guardrails, and routing rules that affect behavior.

   You should end up with: Version-controlled AI configuration manifest

2. 2

   Assess the proposed change

   Document the reason, affected use cases, expected behavior, data implications, reviewer, and rollback version.

   You should end up with: AI change record with impact assessment

3. 3

   Validate before release

   Run representative and adverse cases against explicit quality, safety, privacy, and operational acceptance criteria.

   You should end up with: Version-specific evaluation results

4. 4

   Release and observe

   Use a staged deployment where practical, record the active version, monitor defined signals, and retain the rollback decision.

   You should end up with: Release record and post-change validation

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.

Which records should you prepare for the audit?

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: Changes to prompts, models, tools, retrieval, system messages, and orchestration are reviewed, validated, released, and reversible as identifiable versions.

• 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 production configuration and provider audit events to version-control changes, tickets, approvals, and releases; investigate console edits, mutable aliases, emergency paths, and unrecorded rollbacks. Separately reconcile every annual review due date from the schedule and active workflow inventory to a completed no-change or change decision, a documented missed review, or a rescheduled review that preserves the original and new due dates.

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

  Retain the complete active workflow-version manifest, its approval and evaluation, the identified rollback version, and the latest scheduled annual change-control review and disposition on the selected date.

• Prepare period evidence for a Type 2 engagement

  List every production change during the period to a prompt, system message, model, parameter, tool, retrieval source or setting, routing rule, or guardrail, including staged, failed, cancelled, rolled-back, console, and emergency changes; also include every scheduled annual review of the active AI configuration inventory and change-control process, including no-change completions, missed reviews, and rescheduled reviews.

• Inspect the approval / review evidence

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

  • Inspect approvals

    For each selected record, confirm it demonstrates An authorized reviewer accepted the exact proposed workflow version and its evaluation results before production release.

    • Workflow version
    • Decision
    • Approver
    • Approval time
    • Evaluation reference
    • Release conditions

• Inspect the operating / technical evidence

  Dated proof that the control actually ran, such as tickets, logs, settings, exports, reports, and test results.

  • Inspect Prompt/model version history

    For each selected record, confirm it demonstrates Every production behavior version identifies its prompt, model, parameters, tools, retrieval settings, and effective period.

    • Workflow version
    • Prompt or system-message revision
    • Model identifier
    • Configuration values
    • Effective timestamp
    • Change author

  • Inspect change tickets

    For each selected record, confirm it demonstrates The AI behavior change has a reason, impact assessment, owner, planned validation, approval, and rollback target.

    • Ticket ID
    • Changed components
    • Affected use cases
    • Risk and data impact
    • Approver
    • Rollback version

  • Inspect validation results

    For each selected record, confirm it demonstrates The candidate version met defined behavioral, security, privacy, and operational acceptance thresholds before or during staged release.

    • Evaluation run ID
    • Workflow version
    • Test-set version
    • Acceptance thresholds
    • Results and failures
    • Reviewer decision

  • Inspect rollback records

    For each selected record, confirm it demonstrates The team can identify and restore the complete prior prompt, model, retrieval, tool, and configuration state when a release regresses.

    • Release ID
    • From and to versions
    • Rollback trigger
    • Initiator
    • Timestamp
    • Validation outcome

• 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

• Prompts are edited directly in a provider console without durable version history.
• A model alias changes behavior without a recorded application release.
• Evaluation uses happy-path examples that do not reflect customer or adversarial inputs.
• Rollback restores code but not the prompt, index, model, or tool configuration.

Before you call this control ready

• Can the team reproduce the full AI configuration active on a chosen date?
• Does a material provider or model change trigger review and evaluation?
• Are acceptance thresholds defined before results are examined?
• Has rollback been demonstrated for the complete workflow version?

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.

• CC8.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.

Related controls to review next