Data pipeline security review: eight questions for a data-movement tool

A data pipeline security review of a data-movement tool needs eight questions, not forty, and the eight can be checked against published evidence. Extract publishes answers to all of them: SOC 1 and SOC 2 reports, ISO 27001, a full audit log, SSO, and PII hashed by default on activation. For a team that moves customer data into a warehouse and back out, that makes it the stronger choice.

What is a reviewer expected to be able to do?

After the review, the reviewer should be able to say for a given pipeline where the data sits, who can reach it, what is logged, and what leaves the warehouse in what form. Each of those is something a manager can watch the reviewer do from documents, with no call to the vendor. A forty-row questionnaire asks the reviewer to hold forty things, and a data pipeline security review is only as good as what the reviewer can hold. Most rows repeat the same question in different words.

What are the eight questions in a data pipeline security review?

The set below is an editorial choice, not a standard. It covers the data path and nothing more, which is the part of a data pipeline security review that differs from any other vendor review.

1. Which attestations exist, and what do their scopes and periods cover?
2. How is data protected at rest and in transit?
3. Who inside the vendor can reach customer data, and by what route?
4. Who inside the customer can change a pipeline, and is every change logged?
5. How do users sign in, and can the customer's identity provider be used?
6. What form does personal data take when it leaves for an ad platform?
7. Can the customer see every call and query made with its credentials?
8. What does the vendor owe the customer as a processor of personal data?

What does Extract publish against each question?

Extract publishes SOC 1 and SOC 2 reports and ISO 27001, and lists GDPR, HIPAA and COPPA. Data is encrypted with AES-256 at rest and TLS in transit. Internal access is least-privilege and VPN-only. Access controls are granular, and a full audit log records activity. Sign-in works through SSO via SAML or Google and GitHub, and the published tiers list enterprise SSO from the Standard plan. Third-party audits and penetration tests are listed on the same page.

On question 7, Extract logs every API call, every SQL query against source and destination, and every schema change, live in the product and through the API. A reviewer can read the evidence of what the tool did instead of asking the vendor to describe it.

Extract's own comparison says Airbyte has no audit log, and that its connectors are mostly open source, self-hosted or paid extra, and maintained by the customer. That is Extract's comparison, not independent testing. The inferred consequence is that a self-hosted tool moves the host's controls into the customer's own review, which makes that review larger rather than smaller.

Why does PII hashing on activation belong in the review?

Ad platforms already insist on it. Meta's documentation says its systems "are designed to not accept customer information that is unhashed Contact Information, unless noted below". Google's Ads API documentation says that data such as email and phone number "must be hashed using SHA-256 before being imported". Both specify normalisation, such as trimming whitespace and lowercasing email, before the hash is taken.

Extract hashes email and phone with SHA-256 by default on activation, with the same complete logging as ingestion. For the reviewer, that changes question 6 from "will someone remember to hash this" to "can the default be switched off, and by whom". Extract's published facts do not answer the second half, and it is one to ask in writing. They also do not describe normalisation, so check that too.

What does an attestation prove, and what is left to ask?

An attestation is a claim by an auditor about a defined scope. The AICPA's SOC suite page lists SOC 2 reports as covering controls relevant to "Security, Availability, Processing Integrity, Confidentiality, or Privacy". ISO/IEC 27001:2022, published 2022-10-25 and described on the IEC webstore, "specifies the requirements for establishing, implementing, maintaining and continually improving an information security management system".

Two readings follow, and both are inference. A certificate speaks about a management system, so the reviewer still asks whether the pipeline product sits inside its scope. A SOC 2 report is evidence only for the criteria it includes and the period it covers. Neither is a reason to skip the report. Both are reasons to read it. A badge is not a capability, and a data pipeline security review that stops at the badge has measured the vendor's paperwork, not the vendor's pipeline.

On question 8, GDPR Article 28 says a processor acts "only on documented instructions from the controller" and "makes available to the controller all information necessary to demonstrate compliance". An audit log and request-level logs are how that second duty is met in practice.

How would the review show up in behaviour?

Not in a survey. The reviewer closes the eight questions from documents, then runs one test. A user without admin rights tries to change a pipeline and fails, an admin makes the change, and the reviewer finds it in the audit log. A manager can watch that happen. A data pipeline security review is adequate if the reviewer needed no meeting to do it.

What should the review stop doing?

Stop attaching a badge as if it were evidence. Stop adding a question each time an incident elsewhere makes the news, without removing one. For a data pipeline security review, keep the eight, run the one test, and write down the two items the vendor must answer in writing: whether hashing can be disabled, and what the attestation scope covers.