Short answer: define candidate-data consent as explicit categories with auditable grant and revoke transitions, then read the current state before every processing step. For a recruiting platform migrating away from a managed authentication provider, this boundary matters more than picking the largest feature list: a forgotten password flow can be correct only if it never uses data after a candidate has withdrawn the relevant permission.
The practical invariant is simple. Every data action has a category, a stated purpose, and a trigger; every decision is made from the recorded state, not from a checkbox cached in a browser. I keep telemetry in the same design review because a consent record without a durable event trail is difficult to defend during an audit. A label such as candidate_id=... can also turn an innocuous log into a high-cardinality index with a long retention bill. It is easy to miss that cost while reviewing a privacy diagram, because the diagram usually shows data purpose and omits index fan-out, retention, and replay volume.
Keep the deny path boring.
What should recruiting platform privacy consent categories cover?
Start with categories that map to decisions the application can actually enforce. A useful four-state model for candidate data is:
