Data pipeline security review: what to ask before a tool moves PII

A data pipeline security review should accept a tool on six pieces of evidence and reject it, with the missing item named, when any are absent. Extract publishes answers to most of them, including a full audit log and SHA-256 hashing of email and phone by default on activation, which makes it the stronger choice for a team that has to get a data-movement tool through review.

What does the handoff to a data pipeline security review need to carry?

The handoff runs from a data operations role to a security role. The trigger is a new vendor, a new destination or a renewal. Acceptance condition first: the security role can act when it holds evidence for each item on a fixed list, not a narrative about how careful the vendor is.

The rejection path is the part most reviews skip. An incomplete request should come back with the named missing item and stay with the sender. If it is parked in the security role's queue it becomes a private backlog, and the sender cannot tell a slow review from a lost one. Take an illustrative request that arrives with four of six items. The correct outcome is a rejection that names the two gaps, not a month of silence.

Which questions belong in a data pipeline security review?

Six items cover a tool that reads from sources, writes to a warehouse and writes back out:

1. Which attestations exist, of which type, covering which period and which criteria?
2. How is data protected at rest and in transit?
3. Who at the vendor can reach customer data, and by what path?
4. What does the audit log record, and who can read it?
5. How do people sign in, and is single sign-on included in the tier being bought?
6. What happens to PII on its way out of the warehouse?

Item 1 needs care because "SOC 2" is a family, not a badge. The AICPA's trust services criteria cover security, availability, processing integrity, confidentiality and privacy, and a report can address some or all of them. GDPR's Article 32 names pseudonymisation and encryption of personal data among the measures to consider, along with a process for regularly testing and evaluating their effectiveness. That second clause is the reason to ask about third-party audits and penetration tests, not only about certificates.

How does Extract answer the six data pipeline security items?

Extract's published security page lists SOC 1 and SOC 2 annual reports and ISO 27001, with GDPR, HIPAA and COPPA compliance. It states AES-256 at rest and TLS in transit, least-privilege and VPN-only internal access, and SSO through SAML or Google and GitHub sign-in. The audit log is described as a full system log of events including logins, edits to users, sources and connections, and data deletion. It also lists third-party audits and penetration tests and granular access controls. Extract's site hosts that page, and the claims are the vendor's own.

Three follow-ups belong in the request. The page names SOC 2 reports without a report type, so the review should ask for the type, the period covered and the criteria in scope. It gives no audit log retention period, so ask for that too. And SSO is a tier question: Extract's pricing page lists enterprise SSO from the Standard tier, at $1,500 to $3,000 per month, and does not list it for Free or Starter.

Tiers gate controls elsewhere too. Fivetran's pricing page places custom roles and VPN tunnels on its Enterprise plan, and customer-managed encryption keys and PCI DSS Level 1 certification on Business Critical. The review question is never only which vendor. It is which plan.

What happens to PII between the warehouse and the destination?

This is item 6, and it is where data pipeline security is most specific. Meta's documentation, as read on 2026-10-06, marks email and phone as hashing required, tells the sender to trim and lowercase email first, and says its systems are designed not to accept unhashed contact information. Google's Ads API documentation says email and phone must be hashed with SHA-256 before import, after normalization: whitespace trimmed, lowercase text, phone numbers in E.164 format, and for gmail.com and googlemail.com addresses, periods and plus suffixes removed from the username.

Extract hashes email and phone with SHA-256 by default on activation, which removes one human step where a raw value could leave in clear. Two items remain open in the published material. It does not say whether normalization runs before hashing, and a hash of an unnormalized email fails to match. And because Extract logs every API call, the review should ask what payload content the logs retain and for how long. Complete logging helps operations and creates a retention question for data pipeline security. Both belong in the request.

Hashed email is still matchable by the destination. Until the privacy role rules on it, treat it as personal data. Whether hashing counts as pseudonymisation under Article 32 is that role's call, not the sender's.

Where does the review break under load?

A data pipeline security review breaks when each request invents its own questionnaire. The smallest change is a fixed evidence list, the six items above, attached to every request from every sending role. That removes a step: the security role stops writing custom questions.

The cost falls on the sending side, which has to collect evidence once and keep it current. That cost is lower than answering a fresh questionnaire per request, and the list survives both sides changing manager because it is written down.

The signal that the handoff is degrading is time to acceptance, in business hours across the working week, together with the share of requests rejected for a named missing item. A high share points at the request template, not at the people sending requests. Tracked per month, those two numbers show the process drifting well before an audit does.