Preparing for a buyer's security review as a data supplier

What does a buyer's security review cover for a data supplier?#

A buyer's security review of a data supplier covers the controls around the specific records being licensed: access to source systems, the export, preparation, staging storage and transfer. It looks different from a normal vendor review, where the buyer worries about you holding its data. Here the buyer worries about receiving records that were mishandled, contain personal details or credentials, or came from systems the supplier did not control.

Expect a questionnaire, which may be the buyer's own or one based on a common format such as SIG or CAIQ, plus requests for third-party reports and a call with the CTO or IT lead. A short internal kickoff before the questionnaire arrives saves most of the scrambling: decide who answers, where documents live and who signs off on what is sent.

The evidence pack: one document per question area#

The evidence pack is a folder of existing and newly written documents, each mapped to the question areas reviewers ask about. Buyers generally prefer a short answer plus an attached document over a long narrative.

Some items exist already, such as policies and audit reports. Others, such as the export procedure and the de-identification record, are specific to the dataset and are best written while the work is being done rather than reconstructed later.

How to write the export procedure reviewers ask for#

The export procedure is often the weakest document in the pack because exports were run informally by one engineer. Writing the procedure before the export, then following it, turns an awkward question into a straightforward answer.

• 1Name the source system, environment and account used for the export.
• 2State the filters: date range, record types, queues or projects included and excluded.
• 3Use a dedicated export account or API token created for the job and revoked afterward.
• 4Write output to one encrypted staging location with access limited to named people.
• 5Record file names, record counts and a checksum for each output file.
• 6Log who ran each step and when.
• 7Delete intermediate copies after delivery and record the deletion.

Documenting de-identification so it holds up#

The de-identification record explains what was removed, how it was removed and how the result was checked. Reviewers usually ask for a field-level list of removals, the tools used, whether replacement tokens stay consistent across records, the sampling approach and what human reviewers found and fixed.

Free text is where most problems hide. Support ticket bodies, Slack threads, email chains and code comments carry names, phone numbers and account details outside any structured field, so deleting columns is not enough.

Automated tools help, but they are not the whole answer. The documentation for Presidio, an open-source PII detection tool, warns that automated detection gives no guarantee of finding all sensitive information and that additional systems and protections should be used. A record showing human review of a sample, with the errors found and corrected, answers the follow-up question before it is asked.

Questions that catch suppliers off guard#

A handful of questions come up repeatedly and are hard to answer on the spot. Preparing answers in advance keeps the review call short.

When a question reaches beyond the package, such as a request for every policy the company has ever written, answer for the systems and people involved in the dataset and say so plainly. A clearly scoped answer is easier to verify than a broad one, and it keeps unrelated parts of the business out of the review.

Illustrative: a field service software company prepares#

Illustrative: a fictional vertical software company that sells dispatch software to HVAC contractors plans to license support conversations from Intercom linked to Linear issues and GitHub pull requests. The buyer sends a long questionnaire and asks for a call with the CTO.

The CTO maps each question to an existing or new document. The company's SOC 2 report covers its production platform but says nothing about the dataset, so the team writes an export procedure, runs a secret scanner across the repository history and conversation exports, and finds API keys pasted into older conversations. The keys are removed from the package, rotated and logged.

The privacy lead documents the redaction method and a human review of sampled conversations. The review closes with one follow-up question about staging copies, answered with the deletion log.

How SourceX supports a security review#

In the SourceX five-step transaction, the Preparation step produces the privacy record and the Approval step captures the supplier's release authorization. Together with provenance, licensing rights and permitted use, these make up the SourceX Evidence Packet, which addresses the dataset-level questions a reviewer asks about where records came from and how they were prepared.

Large datasets stay in the supplier's own storage or ship on encrypted drives; SourceX never hosts multi-TB datasets. The supplier approves every step, and nothing is shared during the initial assessment.