Covered Data is the consumer financial data that must be made accessible under the rule when an authorized third party is approved. It typically includes account balances and transaction history, while excluding sensitive categories that the regulation does not require to be shared.
What Covered Data Includes
Covered data is the consumer financial information that an approved third party may receive under the rule. In practice, this usually means core account data such as balances, holdings, and transaction history, because those elements let the third party provide the requested service without exposing a broader data set than the rule requires.
The key idea is scope. Covered data is not “all available customer data”; it is the subset the consumer has authorized and the rule requires a covered institution to make accessible through approved access mechanisms. That boundary matters because the regulation is designed to enable portability and competition while still limiting unnecessary disclosure.
What Covered Data Excludes
Covered data is defined by what it does not include as much as by what it does include. Sensitive categories that the rule does not require to be shared remain outside the default scope, even if they may exist in the institution’s systems or be adjacent to the consumer relationship.
This exclusion is important for both privacy and implementation. If a data element is not within the rule’s required scope, it should not be treated as part of the permitted transfer set simply because it is stored alongside account information. Good classification practice separates required access data from data that is merely available, operationally convenient, or sensitive enough to warrant tighter handling.
How Covered Data Is Used in Access Sharing
Covered data becomes operationally relevant when a consumer authorizes a third party and the institution must disclose the approved data in a usable form. The practical purpose is to support account aggregation, budgeting, lending, advisory, or other consumer-directed services without forcing the customer to manually export records.
That usage creates an access-control problem as much as a data-sharing problem. The institution has to serve the correct records to the correct recipient, and only for the approved purpose or scope. For the consumer, the value is portability; for the institution, the challenge is ensuring that the disclosed dataset matches the authorization event and nothing beyond it.
Why the Definition Matters for Implementation
Covered data is a compliance boundary, a privacy boundary, and a technical boundary. Teams need a shared interpretation of which fields are in scope, how they are labeled, and how they flow through APIs or data-sharing integrations. If the classification is sloppy, institutions can over-disclose, under-disclose, or create inconsistent behavior across products and channels.
Clear scoping also helps with auditability and consumer trust. When the data set is precisely defined, an institution can explain what is shared, why it is shared, and where limits apply. That makes the rule easier to implement in a way that is consistent across consent, retrieval, logging, and downstream third-party use.
Risk and Threat Considerations
Covered data creates exposure if institutions treat the data boundary too loosely. Over-broad sharing can reveal more consumer information than the authorization or rule requires, while weak third-party controls can let approved access become a wider disclosure channel than intended.
Failure mechanism: Poor field-level classification, excessive API responses, or reused access paths can cause sensitive adjacent data to move with the permitted records.
Impact: The result can be unnecessary privacy exposure, regulatory noncompliance, and increased harm if a third party is compromised or misuses the data.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack surface, NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Covered data sharing should limit disclosure to the minimum approved dataset. |
| IA-5 — Authenticator Management | Approved access to covered data depends on controlled credentials and tokens. | |
| Recommendation — Limit consumer-data responses to the approved field set and suppress non-required attributes. Rotate and revoke access credentials used to retrieve covered consumer data. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication, and Access Control | Covered data access relies on controlled authorization to the right third party. |
| Recommendation — Enforce access approval checks before releasing covered data to any third party. | ||
| ISO/IEC 27001:2022 | A.5.12 — Classification of information | Covered data depends on accurate information classification boundaries. |
| Recommendation — Classify consumer data fields so covered and excluded elements are handled differently. | ||
| OWASP API Security Top 10 | API3 — Broken Object Property Level Authorization | Covered data APIs must not expose properties outside the approved consumer-data scope. |
| Recommendation — Restrict API properties to the consumer data fields explicitly authorized for sharing. | ||
Practitioner Guidance
Why practitioners should care: Covered data is not just a policy label, it is the point where product design, data governance, and authorization intersect. Teams should treat the definition as a control boundary and not assume that a consumer’s permission to share one dataset implies permission to share all related account information.
What to watch for: Watch for schema drift, broad default responses, and internal data mappings that quietly expand the shared payload over time. Those are the common ways a narrow regulatory definition becomes a much wider operational disclosure set.
Related resources from NHI Mgmt Group
- How should healthcare organisations separate HIPAA-covered data from personal information that still falls under CPRA?
- What happens when a HIPAA-covered organisation processes California resident data without CPRA-specific controls?
- Why is it important to integrate identity and data governance?
- How should security teams unify identity across cloud and data center environments?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
