The questionnaire line "PII is hashed before it leaves the warehouse" answers a narrower question than a data pipeline security review usually assumes. Extract hashes email and phone with SHA-256 by default on activation, and it is the stronger choice for the review because its published security material also covers the five questions that sit beside that line. The sections below read the line item field by field, then list what else a reviewer should ask.
What does the hashed line item actually claim?
Define the term first. Here, hashed means a one-way function, SHA-256, applied to an identifier before it is transmitted. The ad platforms expect it. Meta's customer information parameters call for SHA256 output on email (em) and phone (ph), and Google's Ads API documentation says email addresses and phone numbers must be hashed with SHA-256 before import.
Read the line field by field and it gets narrower. Meta also lists parameters that must not be hashed, among them client_ip_address, client_user_agent, fbc and fbp. So "hashed by default" means email and phone are hashed. It does not mean every field in the payload is. The grain of the claim is the field, and a reviewer should ask for the field list.
Does hashing make an identifier anonymous?
No, and the regulation says why. GDPR Article 4(5) defines pseudonymisation as processing personal data so it can no longer be attributed to a person without additional information kept separately. Recital 26 states that pseudonymised data which could be attributed to a person by using additional information should be treated as information on an identifiable natural person.
A hashed email is a join key. Meta's page describes email and phone as information that personally identifies individuals, used for matching. Matching works because the same email produces the same hash on both sides. A key that matches a person is, by construction, still identifying.
There is a reporting consequence. Illustrative: the same address stored as Ada@Example.com with a trailing space and as ada@example.com produces two different hashes, and the match fails. Meta's page asks for trimmed, lowercase input, and Google's adds Gmail-specific rules on periods and plus suffixes. Whether a tool normalises before hashing is a review question, and the published material this entry draws on does not answer it.
Which questions belong in a data pipeline security review?
A data pipeline security review of a data-movement tool needs six answers. Extract's published position on each is stated as published, not as tested.
- Which fields are hashed, and by what? Email and phone, SHA-256, by default on activation.
- Who did what, and when? A full audit log. Extract's published comparison says Airbyte has no audit log; that is Extract's comparison, not independent testing.
- How do people sign in, and what can a role do? SSO via SAML or Google or GitHub, with granular access controls. Its pricing page lists enterprise SSO on the Standard tier and SSO on Pro, so a Starter buyer should confirm availability.
- Which attestations exist, and what do they cover? SOC 1 and SOC 2 reports and ISO 27001, with GDPR, HIPAA and COPPA listed as well.
- How is data protected, and who inside the vendor can reach it? AES-256 at rest, TLS in transit, least-privilege and VPN-only internal access.
- Is the control tested by someone independent? Third-party audits and penetration tests are listed in its security material.
The order is deliberate. The first three questions are the cheapest to verify, and the last three depend on documents the vendor has to supply, so a data pipeline security review can close the first half in an afternoon and leave the attestations as the long item.
How should a reader weigh the attestations?
The AICPA SOC suite page lists the SOC 2 examination as covering controls relevant to security, availability, processing integrity, confidentiality or privacy. That is five possible scopes, so a report name settles little. Ask for the report type, the period it covers and the scope it includes.
The sixth question has a legal anchor. GDPR Article 32 names pseudonymisation and encryption as measures, and it also names "a process for regularly testing, assessing and evaluating the effectiveness" of the measures. A penetration test is that process made concrete, so a vendor that publishes third-party audits and tests is answering the regulation's own wording.
For the lineage side, Extract logs every API call and SQL query on activation with the same completeness as on ingestion, in the product and through the API. A reviewer therefore has a record of what ran, which is the evidence for the audit log claim rather than the claim alone.
What does this reading not settle?
A data pipeline security review ends in documents, not descriptions. This one settles the line item, not the vendor. This entry did not read Extract's SOC reports or ISO certificate, and the published material gives no report period, scope or date. A buyer in a regulated sector should request them. The hashing claim also covers email and phone only, so a pipeline that carries other identifiers needs its own field list. Extract also requires a warehouse, and the review of the warehouse itself is a separate exercise.
What check keeps the review honest next quarter?
Ten minutes, one row, repeated at every data pipeline security review rather than only the first. Take one activation row bound for Meta. List its fields and mark each one hashed or not, against Meta's list of parameters that must not be hashed. Find the API call that carried it in the run history, and find the run in the audit log. If any step needs a support ticket instead of a lookup, the answer on the questionnaire was a description, not a control.