Data Handling and Customer Context Boundaries for SOC 2

What this control should accomplish

AI workflows accept and expose only the customer, confidential, credential, and telemetry data allowed for their approved purpose and tenant context.

How to implement Data Handling and Customer Context Boundaries

1. 1

   Map workflow data

   Identify each input, retrieved context, prompt field, output, log destination, provider, retention path, and tenant boundary.

   You should end up with: Workflow-specific data-flow map

2. 2

   Set handling rules

   Define allowed and prohibited data categories, approved purposes, masking needs, provider restrictions, and retention behavior.

   You should end up with: Enforceable input and context rules

3. 3

   Enforce tenant scope

   Bind retrieval and tool calls to verified tenant and user authorization instead of relying on prompt instructions.

   You should end up with: Authorization-enforced context configuration

4. 4

   Test boundary failures

   Run cases for secret submission, prompt injection, cross-tenant retrieval, excessive context, and sensitive output leakage.

   You should end up with: Boundary test results with remediation

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: AI workflows accept and expose only the customer, confidential, credential, and telemetry data allowed for their approved purpose and tenant context.

• 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 workflow execution counts across the gateway, application, authorization, and retrieval layers; account for missing traces, blocked submissions, data-loss alerts, boundary tests, and approved exceptions.

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

  Retain current data-handling rules and deployed workflow configuration plus a recent negative tenant or prohibited-data test as of the selected date.

• Prepare period evidence for a Type 2 engagement

  Account for every production execution of scoped AI workflows during the period, including blocked, failed, and cross-tenant-denied requests, plus every handling-rule change, boundary test, and approved data exception.

• Inspect the policy / design artifacts

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

  • Inspect Data handling rules

    For each selected record, confirm it demonstrates Each workflow has approved input, context, output, logging, provider, and retention rules tied to its purpose and data classifications.

    • Workflow ID
    • Data category
    • Allowed purpose
    • Provider or destination
    • Protection rule
    • Owner and approval date

  • Inspect allowed/prohibited input lists

    For each selected record, confirm it demonstrates Operators and technical filters distinguish data the workflow may process from secrets, credentials, or restricted categories it must reject.

    • Workflow ID
    • Allowed categories
    • Prohibited categories
    • Examples or detection rule
    • Enforcement point
    • Effective version

• Inspect the operating / technical evidence

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

  • Inspect tenant-scoping evidence

    For each selected record, confirm it demonstrates Runtime retrieval and tool access derive customer scope from trusted authorization and prevent cross-tenant context access.

    • Workflow and test ID
    • Authenticated tenant
    • Requested tenant
    • Authorization decision
    • Retrieved object scope
    • Result and timestamp

  • Inspect workflow configs

    For each selected record, confirm it demonstrates The deployed workflow applies the approved data filters, tenant binding, provider routing, logging, and retention settings.

    • Workflow ID and version
    • Environment
    • Filter settings
    • Tenant binding
    • Provider route
    • Deployment timestamp

• 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 prompt says not to reveal data, but access controls allow broad retrieval.
• Provider settings and retention behavior are not evaluated per data type.
• Logs capture prompts or outputs containing secrets and customer data.
• Tenant identifiers are supplied by the model instead of trusted application context.

Before you call this control ready

• Can the workflow retrieve another tenant's records under any prompt?
• Are credentials and prohibited data blocked before provider submission?
• Do logs and traces follow the same handling rules as prompts and outputs?
• Can the team show the approved purpose for every data category used?

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.

• CC6.1
• CC6.7
• 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.

Related controls to review next