Data integration combines information from multiple sources into a unified view for ongoing or real time use. Unlike migration, it is not a one time transfer into a new platform. In SAP environments, integration supports synchronisation, reporting, and cross system data exchange while keeping source and target systems aligned.
Expanded Definition
Data integration is the controlled combination of records, events, and operational signals from multiple systems into a unified view that can support reporting, synchronisation, automation, or near real time decision-making. In SAP-heavy environments, the term usually covers interfaces, middleware, replication, and event-driven exchange across ERP, CRM, finance, and analytics platforms.
It is distinct from data migration because integration is continuous, not a one-time cutover. It is also broader than simple data transfer because it must preserve meaning, timing, lineage, and trust across systems that may have different schemas and access models. Definitions vary across vendors, especially where integration overlaps with ETL, iPaaS, API orchestration, and master data management, so the operational scope should be documented explicitly. For a governance baseline, the NIST Cybersecurity Framework 2.0 helps anchor the security duties around integrity, access control, and resilience in connected environments.
The most common misapplication is treating integration as a purely technical plumbing task, which occurs when teams connect systems without defining ownership, data quality checks, or security boundaries.
Examples and Use Cases
Implementing data integration rigorously often introduces latency, dependency, and validation overhead, requiring organisations to weigh faster cross-system visibility against stronger controls and maintenance cost.
- An SAP finance platform synchronises vendor master data with procurement and accounts payable so invoices, approvals, and reporting remain aligned across systems.
- A streaming pipeline aggregates inventory, warehouse, and order events into a common operational dashboard for supply chain teams.
- A CRM and ERP integration passes customer status and billing changes between systems while preserving a single source of truth for downstream applications.
- An identity governance team ties service account activity into security monitoring so unusual access patterns can be investigated alongside business transactions, a concern echoed in the NHIMG research on Ultimate Guide to NHIs — Key Research and Survey Results.
- A third-party API exchange is built with scoped credentials and audit logging, reflecting the same supply chain exposure patterns described in Klue OAuth Supply Chain Breach and the NIST Cybersecurity Framework 2.0.
Why It Matters in NHI Security
Data integration becomes an NHI security issue because every connector, API key, service account, token, certificate, and automation credential that moves data between systems expands the attack surface. Poorly governed integration paths often bypass normal user controls, which means a single compromised secret can expose multiple business systems at once. NHIMG research shows that 96% of organisations store secrets outside secrets managers in vulnerable locations, and 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
That risk is especially acute when integrations are built for speed and left in place without rotation, ownership, or offboarding. The practical lesson is that data integration should be governed as an identity-bearing workload, not just a data architecture pattern. External references such as the NIST Cybersecurity Framework 2.0 and GitHub Repo Breach — Heroku and Travis CI OAuth Tokens both reinforce that connected systems need traceable access, monitored credentials, and resilient recovery paths.
Organisations typically encounter the full impact only after a token leak, replication failure, or supply chain breach, at which point data integration becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Integration often exposes secrets and service accounts that this control seeks to secure. |
| NIST CSF 2.0 | PR.AC | Data integration depends on access control, authentication, and least privilege across systems. |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero Trust treats each integration path as untrusted until verified and continuously evaluated. |
| NIST SP 800-63 | IAL/AAL | Service integrations rely on assurance for the identities and authenticators behind machine access. |
| OWASP Agentic AI Top 10 | A1 | Agentic workflows often use integrated data sources and can amplify exposure if inputs are untrusted. |
Inventory integration credentials, store them safely, and rotate or revoke them on a strict schedule.
Related resources from NHI Mgmt Group
- What is the difference between data retention risk and integration risk in AI tools?
- What breaks when AI agents are allowed to touch production data during integration work?
- Who is accountable when a SaaS integration exposes customer data?
- Who should be accountable when an MCP integration exposes cross-tenant data?
