Methods for making requests and giving consent must be easy to understand, offer symmetrical choices (the privacy-protective path no longer or harder than the other, for example Accept All paired with Decline All), avoid confusing wording, double negatives and misleading urgency, avoid choice architecture that bundles or obstructs, and be easy to execute and tested to work. Silence or closing a pop-up is not consent. A flow that substantially subverts or impairs user choice is a dark pattern whatever the intent, and agreement obtained through one is not consent.
This control maps to 2 controls across 2 other frameworks. If you already hold one of them, the evidence you collected for it is the starting point here rather than new work.
Every mapping shown was judged rather than inferred from wording similarity, and the ones that failed review are published too. See the coverage reports and what was rejected.
CCPA/CPRA CCR 7004 is one control. If you already hold one of the frameworks below, a reviewed crosswalk already says how much of CCPA/CPRA your existing evidence covers. Hold GDPR and 17 of 89 CCPA/CPRA controls already carry evidence.
Each report names every control your existing framework evidences, every one it does not, the reasoning behind each claim, and the claims that were argued against and rejected. 0 were rejected on the GDPR pair alone.
The graph holds this control, the 2 it maps to, and the evidence behind each claim, over MCP and REST.