Consumer privacy requests asking a business to disclose what personal information it collects, uses, discloses, or sells. Under the CCPA metrics requirement, businesses must count how many of these requests they received, how many were fulfilled in whole or in part, and how many were denied.
What Requests To Know Measure
Requests to know are consumer privacy requests that test an organisation’s ability to disclose what personal information it holds and how that data is used. For CCPA reporting, the term is also an operational counting unit, not just a disclosure obligation.
The metric matters because it turns a privacy-rights workflow into something measurable and auditable. Businesses have to count requests received, requests fulfilled in whole or in part, and requests denied, which makes intake quality, case routing, and decision consistency part of the control environment.
How Requests To Know Work in Practice
A request to know typically asks a business to identify categories or pieces of personal information it collected, used, disclosed, or sold about a consumer. The business then has to locate relevant records, verify the requester where needed, determine the scope of the response, and provide a disclosure or a lawful denial.
In practice, the challenge is less about the phrase itself and more about the underlying data inventory. If records are scattered across systems, vendors, or retention tiers, the organisation may struggle to confirm whether it can satisfy the request completely or only partially. That makes requests to know a useful test of data discoverability and privacy operations maturity.
Why the CCPA Metric Matters
Under CCPA reporting requirements, requests to know are not tracked only for customer service purposes. They help show whether a business can receive, process, and resolve statutory privacy requests at scale. That is why the denominator and outcome counts both matter.
The metric also distinguishes between volume and effectiveness. A high volume of requests does not tell you much by itself; fulfilment rates and denial rates reveal whether the organisation can actually execute the right workflow, apply exemptions consistently, and maintain evidence for its decisions.
Common Sources of Confusion
Requests to know are often confused with deletion requests, correction requests, or opt-out requests, but they serve a different purpose. A request to know is about disclosure and transparency, not necessarily erasure or suppression of processing.
Another common misunderstanding is treating the term as purely legal. The reporting requirement is legal, but the term exposes a broader operational reality: businesses need intake channels, identity verification steps where appropriate, internal search capability, and a defensible method for counting partial fulfilments and denials.
Risk and Threat Considerations
Requests to know create privacy and governance risk when an organisation cannot reliably locate personal information, mishandles requester verification, or counts outcomes inconsistently. That can lead to inaccurate reporting, incomplete disclosures, and regulatory exposure if the privacy-rights process is not well controlled.
Failure mechanism: Fragmented data stores, weak case handling, and poor records of decision-making make it easy to miss data, over-disclose, or misclassify a request outcome.
Impact: The business can produce misleading CCPA metrics, fail to meet statutory deadlines or response obligations, and undermine consumer trust in its privacy programme.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 sets the technical controls, while GDPR and ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| GDPR | A.5.1 — Principles for processing of personal data | Requests to know concern disclosure and handling of personal data rights. |
| Recommendation — Align disclosure handling with lawful processing and data-subject-rights obligations. | ||
| ISO/IEC 27001:2022 | A.5.34 — Privacy and protection of PII | The term governs operational handling of personal information in a privacy programme. |
| Recommendation — Define and evidence privacy-request handling controls for personal information. | ||
| NIST CSF 2.0 | GV.OC-03 — Legal and Regulatory Requirements | CCPA requests to know are a statutory privacy reporting and response obligation. |
| ID.RA-01 — Asset vulnerabilities are identified and documented | Fulfilment depends on finding where personal information is stored and used. | |
| Recommendation — Track privacy-request obligations as part of organisational governance and compliance. Inventory data locations so requests to know can be answered accurately. | ||
Practitioner Guidance
Why practitioners should care: Requests to know are a practical signal of whether privacy operations are working end to end, from intake to search to final disposition. If the organisation cannot count them cleanly, it usually cannot evidence its response process cleanly either.
Common misunderstanding: Teams often focus on closing tickets rather than preserving the rationale for fulfilment, partial fulfilment, or denial. For a glossary term tied to CCPA metrics, the audit trail is part of the control outcome, not an administrative extra.
Practitioner takeaway: Treat request-to-know reporting as a measurement of data visibility and decision discipline, not only as a legal reporting task.
Related resources from NHI Mgmt Group
- How do security teams know whether Axios requests are still exposed to inherited proxy values?
- When should security teams avoid automated approval for access requests?
- How should IAM teams turn access requests into auditable controls?
- How can organisations keep rich authorization requests from becoming over-permissioned?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
