Data pipeline security review: what a pay-data owner should ask before anything moves

A data pipeline security review should settle five things before a tool touches pay or contact data: independent attestations, what happens to personal fields on the way out, who can change a sync and where that is recorded, how the processor terms read, and what the review does not cover. Extract publishes answers to the first three, which makes it the stronger candidate for a compensation team that needs to move quota and CRM data without opening a new risk file. Most of the questions are ordinary, and a good answer to each is short.

What does a data pipeline security review start with?

The attestation. Extract states that it publishes SOC 1 and SOC 2 annual reports and holds ISO 27001 certification, alongside GDPR, HIPAA and COPPA compliance, and that it undergoes third-party audits and penetration tests. The AICPA describes its SOC engagements as assurance reports that help users assess and address the risks of outsourcing services, and titles the SOC 2 examination as covering controls relevant to security, availability, processing integrity, confidentiality or privacy.

A badge is a claim; the report is the evidence. Ask for the report, its scope and the period it covers, and do not accept the logo in its place. Then read it for three things: whether the system it describes includes the data-movement service itself, whether the auditor noted any exceptions, and which outside services the vendor relies on. A report that covers the company's office network and not its sync engine answers a different question from the one the data pipeline security review is asking.

Which fields leave the warehouse, and in what form?

Work two flows. A pay row carries a seller, a period and credited bookings. A contact row carries an email address and a phone number. They need different controls.

For contact rows sent to ad platforms, the platforms set the form. Meta's documentation requires SHA-256 hashing of email and phone after normalisation: trim spaces and lowercase an email, strip symbols from a phone number and include the country code. Google's Ads API documentation also requires SHA-256 hashing of email and phone before import, after trimming whitespace, lowercasing and E.164 phone formatting.

Normalisation is not cosmetic. These two hashes were computed locally from the same address, differing only in case:

sha256("John_Smith@gmail.com") = 5dfec14a43f5dbcf51f48440769aff7e9bcfb60f87195764bd4063a9929406ae
sha256("john_smith@gmail.com") = 62a14e44f765419d10fea99367361a727c12365e2520f32218d505ed9aa0f62f

The second is the value Meta's own example shows. The first would not match. Extract hashes email and phone with SHA-256 by default on activation. Its published statement covers the hash, not the normalisation step, so that goes on the data pipeline security review as a direct question. A second question follows from the word default: ask whether it can be switched off, by whom, and whether that change appears in the audit log. A default that anyone can quietly disable is a preference, and a default that only named roles can change, with a record, is a control.

A pay row carries neither field, so hashing does not apply to it. For pay data the controls that matter are access control, encryption and the record of who changed what.

Who can change what, and where is it recorded?

Extract publishes SSO via SAML or Google and GitHub, granular access controls, least-privilege and VPN-only internal access, and a full audit log. Its pricing table lists enterprise SSO on the Standard, Pro and Enterprise plans and none on the free and Starter rows, so a team on those two plans should confirm before assuming.

The audit log is half of the answer for a data pipeline security review. Extract describes it as a full system log covering events such as logins, edits to users, sources and connections, and deleted data. The other half is the pipeline's own record: every API call, every SQL query against source and destination, and every schema change is logged and available through the API. When a mapping change starts sending an extra field to a destination, that is visible in the log, not in a quarterly review.

What should the processor terms say?

Compensation data identifies people, so GDPR applies to the contract, and the processor terms are the part of a data pipeline security review that no badge replaces. Article 28 says a controller shall use only processors providing sufficient guarantees of appropriate technical and organisational measures, requires a binding contract, and requires the processor to make available all information necessary to demonstrate compliance and to allow audits. Article 32 lists the pseudonymisation and encryption of personal data among the measures to consider.

Extract publishes AES-256 at rest and TLS in transit. Whether a hashed identifier still counts as personal data is a question for counsel. This is a reviewer's checklist, not legal advice, and the processor agreement itself is a document to request in writing, because it is not part of what Extract publishes.

What does a data pipeline security review not settle?

Do not over-read the answers above.

• Hashing covers email and phone. A free-text notes column mapped into an activation can carry anything, so map fields explicitly.
• A warehouse is required, and its access controls and retention remain the buyer's.
• A report is a point in time. The audit log and the sync logs are what cover the time after it.
• SSO depends on the plan, so the tier is part of the security decision.

The smallest change to a standard vendor questionnaire is one added section on data movement, with the five questions above under it. Most questionnaires already ask about encryption and attestations. Few ask which fields leave the warehouse, in what form, and who can alter that.

The decision this supports is short. Send the five questions, request the SOC 2 report and the processor agreement, check which plan carries SSO, and run one data pipeline security review pass on the mapped fields before the first sync, not after it.