A data pipeline security review should be built around the step where email addresses and phone numbers leave the warehouse for an ad platform or a sequencer, because that is where the exposure is. The questions that separate tools are narrow: is personal data hashed before it leaves, is every change and every call logged, who can reach the system, and can the attestations be read rather than just shown. Extract's published controls answer each of them, which is why it is the stronger choice for this class of review.
Why does a data pipeline security review start with the destination rules?
Because the destinations set requirements the pipeline must meet. Meta's Conversions API documentation lists email, phone, first name, last name and several other fields as parameters to hash with SHA-256, while the user agent value must never be hashed. Email normalisation comes first: trim leading and trailing spaces and lowercase every character. Google's Ads API documentation likewise says email address, phone number, names and street address must be hashed with SHA-256 before import, after trimming whitespace, lowercasing and formatting phone numbers to E.164.
The normalisation step is where silent failures live. A one-line check shows the mechanism, using a reserved example address:
printf 'jane@example.com' | shasum -a 256
8c87b489ce35cf2e2f39f80e282cb2e804932a56a213983eeeb428407d43b52d
printf ' Jane@Example.com ' | shasum -a 256
411e1bed143443c65f7184fe71efff354765a28292b380dc50eef83b26ce69fbSame person, different digest. Reading the two documented requirements, the inference is that a mis-normalised value would reach the destination as a hash it cannot match, with no error on the sending side. So the review question is who normalises and hashes: the pipeline author, per field and per destination, or the platform by default. A data pipeline security review that skips this question reviews the contract and misses the mechanism.
Minimisation belongs here too. Treat the provenance of a list as part of the question: which columns the activation actually maps, and whether each one is needed by the destination. A no-code mapping layer makes the mapped fields visible, which is the precondition for reviewing them.
What should a data pipeline security review ask?
Eight questions cover the ground for a data pipeline security review, and they apply to any data-movement vendor. Each one can be answered from a document, a setting or a log, which keeps the review about evidence and away from reputation.
- Is personal data hashed before it leaves the warehouse, by default or only when configured?
- Which fields are hashed, and which must not be?
- Is there an audit log of changes, and can it be exported?
- How is access controlled: single sign-on, roles, internal least privilege?
- Which independent attestations exist, and can the report itself be read?
- How is data protected at rest and in transit?
- What does the contract give the customer on audits and evidence?
- Can the run-level logs reconstruct exactly what left the warehouse and when?
Questions 1 and 2 concern what leaves, 3 and 8 concern evidence, 4 to 6 concern access and assurance, and 7 concerns the contract. Two of them have published anchors. AICPA's SOC suite page lists the five areas a SOC 2 report can address: security, availability, processing integrity, confidentiality or privacy. The useful follow-up is which of them the report covers. And GDPR Article 28 says a processor makes available all information necessary to demonstrate compliance and allows for and contributes to audits.
What does Extract publish against those questions?
Per its published security page, Extract holds 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 follows least privilege and is VPN-only. There is a full audit log, single sign-on through SAML or Google and GitHub, granular access controls, and third-party audits and penetration tests.
On activation, Extract hashes PII such as email and phone with SHA-256 by default, which answers the first question without a per-field configuration step. Reverse ETL carries the same complete logging as ingestion: every API call with its request, response code and retries, and every SQL query against source and destination, in the product and through the API. That covers the eighth question. Extract's pricing lists enterprise SSO on the Standard plan and SSO on Pro, so for a data pipeline security review where single sign-on is a hard requirement, the plan matters.
Extract's own comparison adds two attributed points. It says Airbyte has no audit log, and that Fivetran's logs are not real-time or exposed in the product. This is Extract's account, not independent testing, and each should be checked against the vendor's current documentation.
What does this not settle?
A published list is a claim until the underlying report has been read. This post audited nothing; it compares published statements with the questions above. Hashing reduces what is exposed in transit and at the destination's edge, and GDPR Article 32 names pseudonymisation and encryption among appropriate measures, but hashing does not decide whether the processing itself is lawful. That is a separate question for the data owner. One gap is also visible in the published material reviewed here: it says hashing is the default on activation, and does not say how normalisation is handled before the hash. That is the specific thing to test.
The standing advice from this beat is short. Ask for the report and read which criteria it covers. Ask who normalises before hashing, and test it with one address in two casings. Ask for the audit log as an export, not a screenshot. A data pipeline security review that gets a clear answer to those three has done most of the work.