Does licensing data to AI developers affect your SOC 2 report?

When is a licensing project in scope for SOC 2?#

A licensing project is in scope for SOC 2 when it reads from, changes access to, or moves data out of the systems described in your report. The system description sets the boundary, so compare the project's sources with that description rather than with a general sense of what feels sensitive.

When in doubt, treat the project as in scope. The cost is a little more documentation; the alternative is an auditor finding exports with no record behind them.

Which four controls should you document?#

The four controls to document are approval, de-identification, transfer and deletion, because together they show who allowed the data to leave, what was removed, how it moved and what was left behind. Most companies already run each control for other purposes, so the work is applying them to this project and keeping the evidence.

These map onto criteria your report already tests. SOC 2 examinations use the AICPA's Trust Services Criteria, which cover five categories: security, availability, processing integrity, confidentiality and privacy. The security category's common criteria, which include logical access, restrictions on transmitting and removing information, change management and vendor risk, apply in every SOC 2 report; confidentiality and privacy apply only if your report includes them. Write each control into the project plan before exports start. Evidence created at the time is far more convincing than a reconstruction assembled for fieldwork.

• 1Approval: a named approver, a written scope listing systems and record families, and counsel's sign-off on rights.
• 2De-identification: the method and tools used, the fields removed or replaced, and a human review of a sample.
• 3Transfer: encryption in transit and at rest, an account created for the project, logged access and confirmation of receipt.
• 4Deletion: destruction of staging copies and temporary accounts, with dated records of what was removed and by whom.

What evidence will an auditor expect to see?#

An auditor will expect the same evidence your control matrix already calls for, applied to the project's tickets and accounts. The table maps each control to typical evidence and a likely owner.

Keep the evidence in the same system as your other audit material. A separate folder created for the project is easy to forget when the auditor's sample request arrives.

Does timing within a Type 2 period matter?#

Timing matters because a Type 2 report tests whether controls operated over a period, while a Type 1 report looks at control design at a point in time. A project that runs during a Type 2 period produces tickets and access changes the auditor may sample, so every step should follow normal procedure.

A project between report periods is not invisible either. Customers who receive a bridge letter, management's statement covering the gap since the last report, rely on it to describe significant changes, and a large export program can be one. If the project changes the system itself, such as adding a permanent export pipeline, the next system description may need to mention it.

If a period is about to close, decide whether the project can wait or can run under fully documented procedures from its first export. Starting with improvised steps and formalizing them later is the pattern most likely to produce an exception.

What about customer data and your service commitments?#

Customer data raises a question of commitments before any question of controls. SOC 2 system descriptions typically state service commitments such as keeping customer data confidential and using it only to provide the service, and a release to an AI developer can sit uneasily with those promises.

Watch for customer data hiding inside company records. Support resolutions quote customer messages, engineering issues paste customer logs and screenshots, and test fixtures sometimes copy production rows, so de-identification evidence should show these were found and handled, not only that obvious fields were removed.

Many SaaS companies avoid the conflict by scoping licenses to company records, such as engineering history and support resolutions with customer details removed. Where customer data is involved, counsel should confirm the contractual basis first. This is general information, not legal advice.

Common mistakes that create exceptions#

Most exceptions come from shortcuts taken under time pressure, not from the licensing itself. The patterns below tend to surface in an auditor's sample.

Each mistake has a simple fix that costs less than an exception. Project accounts with an end date, one approved staging location and a close-out checklist signed by the project owner cover nearly all of them.

• 1Using a personal admin account or token for exports instead of a project account.
• 2Leaving temporary accounts and tokens active after the work ends.
• 3Copying exports to laptops or unmanaged storage for convenience.
• 4Running de-identification without saving the configuration or the review result.
• 5Skipping vendor review for an intermediary that handles staged data.
• 6Changing scope mid-project without a new approval.

Illustrative: a bid management software company mid-audit#

Illustrative: a fictional bid management software company for commercial contractors decides to license engineering history from GitHub and support resolutions from a help desk it retired after a migration. GitHub sits inside its SOC 2 boundary as part of change management; the retired help desk archive does not.

The CTO opens a change ticket for the GitHub export, creates a read-only token that expires when the project ends, and records the de-identification configuration and a reviewed sample. The help desk archive follows the same steps under company policy, even though it sits outside the report.

Staging copies are deleted after delivery, with a dated log. When the auditor's sample includes the change ticket, the evidence is already filed beside the company's other change records.

How SourceX fits your control evidence#

SourceX is set up so that each step of the SourceX five-step transaction leaves a record the supplier can file with its own audit evidence. The fit check uses metadata only, so nothing leaves an in-scope system at that stage, and large datasets stay in the supplier's own storage or ship on encrypted drives.

The SourceX Evidence Packet records provenance, licensing rights, permitted use, the privacy record and release authorization for each package. Compliance teams can file it beside the approval and de-identification evidence described above; it supports, but does not replace, your auditor's judgment about scope.