Software companies

SOC 2 and data licensing: will licensing records affect your audit?

By SourceX Editorial · Updated October 9, 2026

Short answer

Licensing records affects a SOC 2 audit only where it touches what your report covers: systems inside the boundary and the commitments you made to customers about sharing data with third parties. If the licensed records sit outside both, the effect is small; if they do not, run the project as a controlled third-party data transfer and keep the evidence.

Key takeaways

Two documents decide the impact: the system description in your SOC 2 report and the customer commitments it summarizes.
Jira and GitHub are often in scope for change management, so exporting engineering history can touch in-scope systems even without customer data.
An AI developer licensing a copy for its own use is usually not a subservice organization, but a vendor that prepares or moves data for you may enter vendor management.
The controls to check are classification, change, access, transmission, vendor management, disposal, risk assessment and monitoring.
Buyers may ask sellers for evidence of their own controls, and a current SOC 2 report helps answer them.

Will licensing records affect your SOC 2 audit?#

Licensing records affects a SOC 2 audit only to the extent the project runs through systems in your report's boundary or changes a commitment the report describes. SOC 2 does not prohibit sharing data with third parties; it tests whether you share data the way your controls and commitments say you do.

That makes the question answerable in an afternoon. Pull the system description from your latest report, list the systems the licensed records would come from, and read the customer commitments on confidentiality and disclosure. The overlap between those three lists is where audit attention will land.

Also check which categories your report covers. SOC 2 is an attestation report from a CPA firm, built on the AICPA Trust Services Criteria: security, availability, processing integrity, confidentiality and privacy. The security common criteria apply in every report, the others only if you chose them, and a Type 2 report tests whether controls operated effectively over a defined period. A report that includes confidentiality or privacy invites a closer look at any data leaving the environment.

Third-party sharing commitments are written in more places than the SOC 2 report itself. The system description summarizes them as service commitments, but the detail lives in contracts and public statements that auditors may read when they test the confidentiality or privacy criteria.

If every commitment is about customer data, and the license covers only company-owned records with customer content removed, the commitments are usually not engaged. If any commitment is written broadly, such as a promise that no data ever leaves the environment, review the license with counsel and your auditor before it starts.

Where are your third-party sharing commitments written?
Where it is written	Typical commitment	What it means for a license
System description	Customer data is used only to provide the service and is protected as confidential	Licensing customer data would conflict; company-owned records may sit outside
MSA confidentiality terms	No disclosure of customer confidential information without consent	Customer content needs consent or removal before any transfer
DPA and sub-processor list	Personal data processed only on customer instructions and by listed sub-processors	A licensee receiving customer personal data would not fit
Privacy notice and trust center	Statements about sharing, selling and AI training	Public statements must stay true after the license
Questionnaire answers	Answers about third-party sharing and AI use	Answers given during the audit period should match what happened

Why engineering records can be in scope without any customer data#

Engineering records can be in scope without any customer data because SOC 2 audits commonly test change management through the tools that hold it. Jira tickets, GitHub pull requests and code review approvals are often the very evidence an auditor samples to show that changes were reviewed before release.

Exporting that history does not weaken the controls, but the export is itself activity on an in-scope system. Bulk API tokens, new service accounts, permission changes and large downloads are exactly what access and monitoring controls are designed to catch, so they should show up as approved, time-limited changes rather than surprises.

Preparation work can also touch sensitive environments. Secret scanning and de-identification jobs over repositories should run in an approved environment, with the results kept as evidence.

Is the licensee a vendor, a subservice organization, or neither?#

An AI developer that licenses a copy of records for its own use is usually neither a subservice organization nor a vendor performing your service. A subservice organization performs part of the service your report covers; a licensee receives a defined dataset under a license and uses it for its own purposes.

The parties around the transfer are a different matter. A company that prepares, stores or transfers data on your behalf may belong in your vendor management program, with a security review and contract terms like any other vendor handling company data. Settle the classification with your compliance lead early, because it decides which controls and evidence apply.

Controls checklist for a licensing project#

The controls checklist covers what a security lead should confirm before any records leave the environment. Map each row to the control IDs already in your matrix rather than inventing new controls for the project.

Controls checklist for a licensing project
Control area	What to check	Evidence to keep
Data classification	Licensed records are classified, and customer data is excluded or consented	Scope note signed by the CTO and counsel
Change management	Export jobs and scripts are approved like any other change	Change tickets and approvals
Logical access	Service accounts are read-only, scoped and set to expire	Access grants and removal records
Data transmission	Transfer is encrypted and goes only to the approved recipient	Transfer log, checksums, receipt confirmation
Vendor management	Intermediaries that handle data for you are reviewed	Vendor review and contract
Confidentiality and disposal	Staging copies are deleted after delivery	Deletion record
Risk assessment	The project is on the risk register with an owner	Risk register entry
Monitoring	Large exports are expected and reviewed, not raised as incidents	Alert review notes

How AI data buyers look at a seller's controls#

AI data buyers look at a seller's controls to judge whether the records are what the seller says and whether the transfer creates risk for them. A current SOC 2 report helps, because it shows the environment the records came from is governed.

Buyers also ask questions SOC 2 does not answer: where the records came from, what rights the seller holds, what was removed during preparation and who authorized release. Those answers live in provenance and rights documentation, so plan to provide both.

A recent SOC 2 report or bridge letter, shared under NDA.
A description of the source systems and the date range of the records.
Confirmation of rights and any customer or vendor restrictions.
The de-identification method and the review results.
The transfer method, encryption and deletion of staging copies.
The name and authority of the person who approved release.

Illustrative: a property management software company mid-audit#

Illustrative: a fictional property management software company is partway through its Type 2 audit period when it decides to license de-identified Jira issues and pull request reviews. Its system description covers the production platform, and its change management control samples Jira tickets and GitHub approvals.

The security lead reads the commitments: all relate to customer data, and none restrict company-owned records. The project runs under change tickets with a read-only GitHub app and a scoped Jira API token, both set to expire after delivery. Customer names pasted into tickets are removed, staging files sit in an encrypted bucket with access logging, and deletion of the staging copies is recorded.

The auditor hears about the project at the next status meeting. When change tickets are sampled later in the period, the export appears as an approved change with its own evidence, and fieldwork continues without surprises.

How SourceX supports audit-ready transfers#

SourceX runs each package through the SourceX five-step transaction, Supply, Rights, Preparation, Approval and Delivery, with the supplier approving each step. The fit check is metadata only, so nothing touches in-scope systems until the company decides to proceed.

The SourceX Evidence Packet records provenance, licensing rights, permitted use, the privacy record and release authorization for each package, which a compliance team can file beside the change tickets and transfer logs its auditor may sample.

Frequently asked questions

Do we need to update our SOC 2 system description?

Usually not for a one-off license of company-owned records, because the project does not change the service. If licensing becomes a recurring program, runs on in-scope infrastructure permanently or changes what you commit to customers, ask your auditor whether the description should mention it.

Will customers see the licensing project in our next SOC 2 report?

Generally not by name. SOC 2 reports describe systems, controls and test results rather than individual projects. A licensing project would appear only indirectly, for example as a sampled change, unless it caused an exception or changed the system description. Customer communication is a separate decision.

Does SOC 2 require customer consent before sharing data with third parties?

Not as a blanket rule. Where the privacy category is in scope, the criteria address how personal information is disclosed to third parties, so any project involving personal information needs closer review. Where only security and confidentiality are in scope, your own commitments and contracts set the bar, which is why they are the first thing to read.

Should the license require security controls from the buyer?

Yes, in proportion to the data. Common terms cover encryption in transit and at rest, access limits, no onward transfer beyond the license, deletion or return at the end of the term and notice of security incidents. These terms protect the records and support your own risk assessment.

Can we license records while preparing for a Type 1 report?

A Type 1 report looks at the design of controls at a point in time, so a project during preparation matters mainly for whether the description and controls are accurate on that date. Keep the project inside existing controls and tell your auditor, as you would for any significant new data flow.

Sources

SOC 2 examinations use the AICPA's Trust Services Criteria covering security, availability, processing integrity, confidentiality and privacy; the security common criteria apply in every SOC 2 report, and a Type 2 report tests whether controls operated effectively over a specified period. Source

Related resources

See if your company qualifies

A short company assessment. No data uploads are needed.

Start a metadata-only fit check Talk to SourceX