A checked box in a form is not enough to build a reliable consent process. The application must know what authorization was granted, for which action, when, and within what scope; it must also be able to stop acting when consent is withdrawn. This design is especially relevant to optional features, such as communications or processing that is not necessary to provide the core service.
Designing revocable consent in PHP applications requires separating decisions that are often conflated in a single flag. This design does not, on its own, determine whether a practice complies with applicable regulations: it turns product decisions and instructions reviewed by specialists into verifiable technical behavior.
Define the action and separate concepts
Start by describing the specific action that requires authorization. “Accept all” is difficult to interpret and revoke; “receive promotional communications by email” defines the purpose and channel more clearly. If the purpose or scope changes materially, do not assume that previous consent automatically remains valid.
Distinguish consent from related concepts:
- Terms of use: set contractual or access conditions; accepting them does not, by itself, authorize optional processing.
- Preferences: describe presentation or configuration choices. They may require consent, but they do not always represent consent.
- Access permissions: control what an authenticated identity can do within the system. Revoking optional authorization should not automatically deactivate the account.
- Consent: records a decision about a defined purpose and scope, according to the functional and legal criteria adopted.
Document each purpose in a stable catalog, with a description that makes sense in the interface and an internal reference for the code. Avoid reusing a generic key such as accepted for different purposes.
Model the state and its changes
A useful model identifies the subject, purpose, scope, state, source of the decision, and timestamps. The subject may be an account or a linked identity; the choice depends on how consent relates to people, accounts, and channels. Store only the data needed to act on and explain the decision.
Rather than representing everything with a context-free boolean, keep a queryable current record and, if audit requirements justify it, immutable or append-only change events. An event may include:
- Subject identifier and purpose key.
- Recorded action, such as granting or withdrawing consent.
- Applicable scope, such as a channel or category.
- Server date and time in a consistent format.
- Source, such as an authenticated form or administrative workflow, without collecting excessive data.
- Correlation identifier or definition version, when it helps investigate changes.
An event log provides traceability, but it does not automatically prove that the request was clear, that the interface was presented properly, or that the decision is legally valid. Avoid storing unnecessary copies of forms, IP addresses, or other sensitive data as a substitute for sound design.
In PHP, centralize operations in a domain service, such as ConsentService, instead of allowing each controller to write the state directly. When they share storage, updating the current state and inserting the event should take place in a database transaction.
Check authorization at the point of execution
The interface can hide an option when authorization is absent, but that is not a sufficient control. The check must happen at the point that initiates the action: before queueing a message, processing optional data, or calling an external integration. A pending message created before withdrawal must also be checked before it is sent.
A domain operation can query an interface such as ConsentRepository::isGranted($subjectId, $purpose, $scope). The name is illustrative: the result must account for the current state, the exact purpose, the scope, and any expiration or version rules defined by the product. Do not treat consent for one channel as authorization for another.
If execution is asynchronous, pass identifiers and query the state again when processing the job, rather than relying on an old copy sent from the form. If the repository is unavailable, decide explicitly how the system should behave: for a sensitive optional action, it is usually safer not to perform it until authorization can be verified. Log the operational failure without exposing unnecessary data.
Withdraw consent and propagate the change
Withdrawal is an explicit state transition, not a silent deletion of history or a session revocation. The user may remain authenticated and retain access to the service while the authorized optional action is stopped. Similarly, withdrawing consent does not automatically mean deleting all data: retention, deletion, or subsequent processing may be subject to different requirements that should be defined with appropriate advice.
When recording a withdrawal, update the state queried by the application and emit an event that can coordinate subsequent tasks. Identify the propagation points: queued jobs, schedulers, communications systems, and integrations. To avoid inconsistent effects, use patterns such as a transactional outbox and idempotent consumers; define what happens if an integration is unavailable.
It is not always possible to undo an effect that has already occurred, such as a delivered message. Therefore, distinguish between preventing future actions, canceling tasks that are still pending, and correcting effects that have already occurred. Describe the result accurately and retain a retry or operational review mechanism for propagation failures.
Test boundaries, repetition, and partial failures
Tests should cover the full lifecycle, not just whether the form saves a choice. Include granting, rejection, withdrawal, changes of purpose, and repeated requests. Verify that repeating a withdrawal does not reactivate consent and that duplicate events do not result in duplicate messages or contradictory states.
- Check that an action does not start unless current authorization exists for that purpose and scope.
- Withdraw consent after creating a job and confirm that the consumer checks it again before acting.
- Simulate a failure between updating the state and notifying an integration; verify that reconciliation can complete propagation.
- Test stale states, missing data, and repository errors, using the defined safe behavior.
- Verify that withdrawing consent for one purpose does not change other purposes, access permissions, or the session.
Record operational metrics and processing errors without turning technical logs into a parallel repository of personal information. Periodically review pending tasks and discrepancies between the central state and integrations.
Agree on responsibilities before deployment
Product teams should define purposes, scope, wording, and the withdrawal experience; technology teams should enforce those decisions in every execution path. Security teams and legal specialists can review the threat model, data minimization, retention periods, and applicable interpretation. Implementation does not replace that review.
Before deployment, document which actions depend on each purpose, who can change its definitions, and how errors are corrected. This turns consent from an isolated checkbox into a verifiable, traceable condition that can be propagated throughout the PHP application.
