The payment data that flows from the transaction system to the payment processor flows through an API. The health information that moves between the EHR and the patient portal moves through an API. APIs are the primary data movement mechanism in modern enterprise architectures. They are also, in most security programs, governed by the security team as infrastructure rather than by the data governance team as data movement channels. The data that moves through them is governed by neither adequately.
Why the Separation Persists
API security in most organizations sits within the application security or infrastructure security domain. The concern is with the security of the API itself: authentication, authorization, rate limiting, input validation, and protection against injection attacks. These are legitimate security concerns. They are not data governance concerns.
Data governance in most organizations sits within the privacy, data management, or GRC domain. The concern is with what data is processed, under what legal basis, for what purposes, with what retention schedule, and with what access controls. These are legitimate data governance concerns. They are not typically applied to APIs because APIs are in the application security domain, not the data governance domain.
The consequence is that the primary channel through which personal data moves between systems in the modern enterprise is governed for its security properties and not governed for its data governance properties. The API authentication is strong. Whether the data flowing through the API is being processed under an adequate legal basis, for a documented purpose, to a recipient with adequate contractual protections, is typically not assessed as part of API governance.
The API is the data movement event. Data governance that does not govern APIs is data governance that does not govern where the data goes.
What API Governance Misses That Data Governance Needs
What Data Is Flowing Through the API
API security testing validates that the API behaves correctly for authorized requests. It does not typically characterize what personal data categories flow through the API under normal operation. The data protection impact assessment for a new API integration — required when the integration involves high-risk personal data processing — requires knowing what personal data the API transmits. That characterization is often not available because it was not captured when the API was designed and is not monitored in production.
Where the Data Goes After the API Receives It
API authorization controls govern who can call the API. They do not govern what the API recipient does with the data after receiving it. An API that sends customer personal data to a third-party marketing platform has been governed for whether the call was authorized. Whether the recipient's subsequent processing of that data is consistent with the customer's consent, the DPA between the organizations, and the applicable privacy regulation is a data governance question that API security controls do not address.
Whether the API Is in the Data Map
Data mapping exercises identify data flows between systems. APIs are the mechanism through which many of those flows occur. If the data mapping methodology does not systematically identify APIs as data flow mechanisms, data flows that occur through APIs may be absent from the data map. An organization whose data map was built by interviewing system owners about what data they share may have a map that reflects what system owners knew about at interview time — which may not include APIs provisioned by engineering teams without system owner involvement.
API Credentials as Data Access Credentials
API credentials — keys, tokens, OAuth credentials — provide access to data through the API endpoint. They are identity and access management objects with data access implications, governed through the API key management process rather than through the IAM program. When API credentials are compromised, the attacker gains access to the data the API exposes — which may be more accessible through the API than through direct system access. API credential governance and identity governance need to be connected, and in most programs they are not.
Closing the Gap
Closing the gap between API security and data governance requires building data governance visibility into the API governance process. API design reviews that include data governance assessment — what personal data does this API expose, under what legal basis, to what recipients — before the API is deployed. API inventories that include data classification of the information exposed by each API. Data flow mapping methodologies that explicitly include APIs as data movement channels.
It also requires connecting the API security and data governance teams operationally. When a new API is being designed, both teams should be involved: security to assess authentication and authorization design, data governance to assess the data protection implications of what the API will expose. When an API security incident occurs, data governance should be part of the response: assessing what personal data may have been exposed and whether breach notification obligations are triggered.
Govern the API as a data movement channel. The data governance obligation follows the data, not the system boundary.
Include APIs in your data map. Classify the data each API exposes. Connect API security governance to data governance for new API design. The data that flows through ungovernerd APIs is ungoverned data.
Enterprise practitioner perspective. Not legal advice. Part of the Deep Trust Governance Series by Verisq. Get the free weekly Breach Digest.