Data Integration Platform Security: A Buyer's Guide

A data integration platform holds a working credential for every system it reads from and writes to, and it moves your most sensitive records between them in bulk. ETL, ELT, replication and change data capture (CDC) tools are usually chosen by data teams on connector count, sync speed and price, and the security review arrives after the shortlist is fixed. This vendor-neutral buyer's guide sets out the security requirements to put into the RFP, how to weight them, the questions to ask and the tests to run in a proof of concept. It is written for security architects, data platform owners, privacy teams and procurement leads choosing a SaaS, hybrid or self-hosted data integration product. It covers batch and streaming data movement into warehouses and lakes; general application-to-application workflow tools are covered in Security Requirements for Selecting an Integration Platform (iPaaS), and hardening a pipeline you already run is covered in the ETL and ELT Pipeline Security Guide.

Key takeaways

The platform is a credential vault you did not plan to build. Database passwords, OAuth refresh tokens, cloud keys and SSH keys for every source and destination sit in one product, so score its secret handling as strictly as you would a secrets manager.
Know where the data plane runs. Whether records pass through the vendor's cloud, stay in your network through a hybrid agent, or never leave your account changes the privacy, residency and contract position more than any other choice.
Every connector is a non-human identity. Require a dedicated, least-privilege, rotatable account per source and destination, an inventory of them, and audit records that name which connector did what.
Privacy controls belong in the pipeline. Column exclusion, hashing or masking before load, region pinning and deletion propagation are far cheaper to require now than to bolt on after personal data has spread into the warehouse.
Prove it before you sign. Test bring-your-own vault, a revoked source credential, a blocked column, a schema change and a full audit export in the proof of concept.

Define requirements

Agree the following with the data platform team, the privacy office and the system owners of the main sources before you speak to vendors. Each answer changes which requirements matter most.

Sources and destinations: list the databases, SaaS applications, file stores, event streams and warehouses in scope, and note which hold personal data, special category data under GDPR Article 9, payment data or regulated records.
Direction of flow: one-way loading into an analytics store, or also reverse ETL that writes back into CRM, marketing or finance systems. Write access to production applications raises the stakes of a stolen connector credential considerably.
Deployment model: fully managed SaaS (vendor control plane and data plane), hybrid (vendor control plane, data plane agent in your network or cloud account) or fully self-hosted. See the comparison below.
Data residency: which regions data may be processed in, including transient staging, logs and error samples, and whether any support access from other regions is acceptable.
Network reachability: how sources will be reached: private connectivity, SSH tunnels, fixed egress IP addresses for allowlisting, or public endpoints. Public database endpoints opened just for the tool are a common, avoidable exposure.
Transformation: whether transformations run inside the product, in the warehouse, or through user-supplied code (Python, SQL, notebooks, custom connectors). User code is software supply chain and needs review.
Exit: how pipeline definitions, connector configurations, logs and any retained data will be exported or deleted on exit, in line with GDPR Article 28(3)(g).

Deployment model	Where credentials live	Where data passes	Fits when	Watch for
Fully managed SaaS	Vendor-held, encrypted by the vendor or with your key	Vendor cloud, transient or staged	Small teams, mostly SaaS sources, limited regulated data	Vendor staff access, staging retention, residency of logs and error samples
Hybrid (customer-hosted data plane)	Your vault or the agent host, referenced by the control plane	Your network or cloud account	Regulated data, on-premises databases, strict residency	Agent patching, what metadata still reaches the vendor, agent outbound connections
Self-hosted	Your infrastructure	Your infrastructure	Air-gapped or sovereign needs, large engineering capacity	You own patching, scaling, secret storage and the audit trail entirely

Small organisations with a handful of SaaS sources can usually accept a managed service if it meets the identity, secret and logging requirements below. Large or regulated organisations should expect a hybrid data plane, customer-managed keys, a bring-your-own vault option and contractual commitments on staging retention and support access.

Capability areas

Identity and administration of the platform

Single sign-on: SAML 2.0 or OpenID Connect for every user, with local passwords disabled except for documented break-glass accounts. CISA's Secure by Demand guide asks buyers whether standards-based SSO is included at no extra cost.
Provisioning: SCIM 2.0 so leavers lose the ability to view connection details or run pipelines when the identity provider disables them. See the SCIM Provisioning Guide.
Role model: separate roles to administer the workspace, create or edit connections (and so see or replace credentials), edit pipelines, run pipelines and view logs. Many data engineers need to run syncs without being able to change a destination.
Environment separation: distinct workspaces or projects for development, test and production, with production connections that cannot be reused from development.
Platform API keys: the management API is itself a credential to every connection. Require scoped, expiring API keys or OAuth clients tied to a named owner, not a single account-wide key.

Connector credentials and secret handling

Bring your own vault: the option to reference secrets held in your secrets manager or cloud key vault rather than pasting them into the product, so rotation happens in one place.
Preferred authentication per connector: key-pair authentication for warehouses, workload identity federation or role assumption for cloud storage (no static access keys), and OAuth for SaaS sources, with refresh tokens limited to the minimum scopes. RFC 9700, the IETF Best Current Practice for OAuth 2.0 Security, recommends restricting token privileges to the minimum required and audience-restricting access tokens.
No credential echo: secrets are write-only in the interface and API, never returned in responses, logs, error messages or exported configuration.
Rotation without downtime: the ability to update a source or destination credential and have running pipelines pick it up, plus a report of credential age per connection.
Encryption of stored secrets: envelope encryption with an option for customer-managed keys, and a statement of which vendor roles can decrypt them.

The Sisense breach shows what concentration means in practice. KrebsOnSecurity reported that attackers took data including customer access tokens and credentials from the analytics vendor, and CISA urged customers to reset any credentials and secrets shared with the company. Sisense's own reset list ran from database connection strings to directory synchronisation credentials and Git credentials. Ask every shortlisted vendor what your equivalent list would be.

Data handling and privacy controls

Column and table selection: exclude columns or tables at source, so data never leaves the source system, rather than dropping them after load.
In-flight protection: hashing, masking or tokenisation of chosen fields before data reaches the destination. See the Data Masking and Tokenisation Buyer's Guide and the Pseudonymisation Techniques Guide.
Staging and caching: documented retention for any intermediate storage, queues, retries and error samples, with the option to disable record samples in logs and support views.
Encryption: TLS 1.2 or higher for every connection, certificate validation that cannot be silently turned off, and encryption at rest for staged data.
Region pinning: processing, staging and logs held in the chosen region, with sub-processors listed by region.
Deletion propagation: support for passing deletes from source to destination (hard or soft deletes in CDC) so erasure requests are not undone by the next sync. See the Data Retention and Secure Deletion Guide.

Network and data plane

Private connectivity options to sources and destinations, SSH tunnelling with key authentication, and published, stable egress IP addresses for allowlists.
For hybrid agents: outbound-only connections to the control plane, signed agent releases, a documented update channel and the ability to restrict which destinations an agent can reach.
Data integrity checks such as row counts, checksums or reconciliation reports, so silent truncation or tampering is visible.

Custom code and connectors

Custom connectors, transformation code and notebooks held in version control, with review and promotion between environments.
Restrictions on outbound network calls and package installation from user code, and isolation between tenants for code execution in managed services.
A software bill of materials or dependency list for the vendor's connectors and agents on request.

Audit, logging and vendor assurance

Audit events for sign-ins, role changes, connection creation and edits, credential updates, pipeline changes, manual runs, schema changes and API key use, exportable to your SIEM.
Security logs retained and available for at least six months at no additional charge, the baseline CISA's Secure by Demand guide sets for cloud and SaaS providers.
Independent assurance (SOC 2 Type II, ISO/IEC 27001 with a scope covering the service and region), a published vulnerability disclosure policy, and incident notification terms that let you meet GDPR Article 33, which requires the controller to notify the supervisory authority without undue delay and, where feasible, not later than 72 hours after becoming aware of a personal data breach, unless it is unlikely to result in a risk to individuals.
A processor contract covering the GDPR Article 28(3) terms, including documented instructions, confidentiality, Article 32 security measures, sub-processor conditions under Article 28(2), assistance with breaches and deletion or return of data at the end of the service.

Evaluation criteria

Weights are illustrative. Increase the weight on data handling for regulated data, and on connector credentials when reverse ETL gives the platform write access to production applications.

Criterion	What good looks like	Evidence to request	Weight
Connector credential handling	Bring-your-own vault, key-pair or federated auth, write-only secrets, rotation without downtime, credential age report	Architecture document; PoC rotation test	20%
Data plane location and residency	Hybrid or in-account data plane available; region pinning for staging and logs	Data flow diagram; sub-processor list by region	15%
Privacy controls in flight	Column exclusion at source, hashing or masking, delete propagation, no record samples in logs	PoC test on a test personal data set	15%
Platform identity and roles	SSO and SCIM included; separate connection and run roles; scoped management API keys	Role matrix; licence schedule	15%
Audit and log export	Connection, credential and pipeline events, SIEM export, six months or more included	Sample audit export and schema	10%
Network controls	Private connectivity, SSH tunnels, static egress IPs, outbound-only agents	Network guide; agent documentation	10%
Vendor assurance and contract	Current SOC 2 Type II or ISO 27001 in scope, Article 28 terms, breach notice terms, exit deletion	Reports under NDA; data processing agreement	15%

The threats below drive these criteria. ATT&CK IDs are from ATT&CK v20.

Threat	ATT&CK	Requirement that addresses it
Theft of stored connector OAuth tokens	T1528 Steal Application Access Token	Bring-your-own vault, minimum scopes, rapid revocation per connector
Reuse of stolen tokens against SaaS sources	T1550.001 Application Access Token	Audience-restricted tokens, source-side IP restrictions, anomaly alerts
Compromise through the integration vendor	T1199 Trusted Relationship	Hybrid data plane, least-privilege connector accounts, vendor access logging
Bulk reading of staged data or exports	T1530 Data from Cloud Storage	Short staging retention, encryption with your key, access logging
Abuse of cloud service accounts used by connectors	T1078.004 Cloud Accounts	Role assumption or federation instead of static keys, per-connector accounts

Where identity fits

A data integration platform is one of the densest concentrations of non-human identities in most estates. Each source and destination has a service account, key pair, OAuth grant or cloud role, and the platform has its own management API keys and agent credentials. Require that each connector has its own account with read-only rights on sources wherever possible, that every account has a named human owner, and that the platform can list them with last use. Feed them into your NHI inventory from day one. See the NHI Discovery Across Cloud, SaaS, CI/CD and On-Premises Environments, the Service Accounts in Snowflake Guide and the ETL and iPaaS platform integration security guide.

Questions to ask vendors

Where exactly do record contents pass, and where are they stored even briefly: queues, staging buckets, retry stores, error samples, support tooling?
Can connector credentials stay in our own secrets manager, and if not, how are they encrypted, with whose key, and which of your staff roles can decrypt them?
Which connectors support key-pair, federated or role-based authentication instead of static passwords and access keys?
Are secrets ever returned by your API, shown in the interface, written to logs or included in configuration exports?
If your platform were breached, which of our credentials would we need to rotate, and how would you tell us and how quickly?
Can we exclude columns at source and hash or mask fields before they reach the destination, and are record samples kept in logs?
How are deletes propagated through CDC, and how do you support our erasure obligations?
Can we separate the right to create or edit connections from the right to run pipelines?
What audit events exist for connection and credential changes, how long are they kept at no extra cost, and how are they streamed to our SIEM?
Which independent reports cover this service and region, who are your sub-processors, and what do you delete on exit and when?

Red flags

Connector secrets visible to administrators in the interface, returned by the API or present in exported configurations.
Only static cloud access keys supported for object storage, or only password authentication for warehouses.
One account-wide management API key that never expires.
Staging or error sample retention that is undocumented or cannot be shortened.
SSO, audit logs or a hybrid data plane available only in a tier you are not buying.
No clear answer to "what would we rotate if you were breached".
An assurance report whose scope omits the region, the agent or the connectors you will use.

Proof of concept

Connect the trial workspace to your identity provider with SSO and SCIM, disable local login and confirm that a disabled user loses access within the agreed time.
Configure one database source with key-pair authentication from your vault and one SaaS source through OAuth with minimum scopes; confirm the secret is never displayed or returned by the API.
Rotate the database credential in the vault and confirm the next sync succeeds without manual edits; revoke the OAuth grant at the source and confirm only that connector fails, with a clear audit event.
Load a synthetic data set with personal data fields; exclude one column at source and hash another, then confirm in the destination and in the platform logs that neither appears in clear text.
Delete a record at source and confirm the delete reaches the destination through the chosen sync mode.
Run a hybrid agent if offered and capture its network connections to confirm outbound-only traffic to documented endpoints.
Export the audit log for the PoC period to your SIEM and check that each step above is present with the user or API key that performed it.

Score each step pass or fail against the criteria table. Keep the trial separate from production data and delete the trial workspace and its credentials afterwards. If credential handling or audit tests fail, do not proceed on the promise of a future release.

After selection: measures and common failure patterns

Once live, track: connector credentials older than your rotation standard; the share of connections using key-pair, federated or vault-referenced authentication; connector accounts with write rights on sources; the number of pipelines carrying personal data without a masking or exclusion rule; and median time from a leaver event to loss of platform access. See the ETL and iPaaS platform rollout playbook and ETL and iPaaS platform health check.

Administrator credentials on sources: the first connection uses a DBA or admin account because it was quickest, and it is never replaced.
Everything replicated: whole schemas are synced by default, so personal data the analytics team never asked for spreads into the warehouse.
Public endpoints for convenience: a database is exposed to the internet with an allowlist that later grows to include broad ranges.
Reverse ETL without review: write-back connectors to CRM or finance systems are added by data teams without the owning team's approval.
No rotation plan for a vendor breach: when a supplier incident is announced, nobody knows which credentials it held. See If your ETL and iPaaS platform is compromised.

Framework mapping

Framework	Reference	Relevance to selection
NIST CSF 2.0	GV.SC-05, GV.SC-06, PR.DS-01, PR.DS-02, PR.PS-04	Supplier requirements and due diligence, data at rest and in transit, log availability
NIST SP 800-53 Rev. 5	SA-4, SA-9, SR-6, AC-6, IA-5, SC-8, SC-12, SC-28, AU-11	Acquisition, external services, supplier review, least privilege, authenticator management, encryption, key management, log retention
GDPR	Articles 28, 32, 33	Processor contract, security of processing, breach notification
ISO/IEC 27001:2022 Annex A	5.19, 5.23, 8.24	Supplier relationships, cloud services, use of cryptography
NCSC Cloud Security Principles	Principles 1, 2, 3, 8, 13	Data in transit, asset protection, separation between customers, supply chain, audit information

Standards and references

How NHI Mgmt Group can help

We provide independent requirements, RFP and evaluation support. Browse vendors in our products directory or contact us.

Security Requirements for Selecting a Data Integration Platform: A Buyer’s Guide to Connector Credentials, Data Handling and Testing