What should happen after someone withdraws consent?

Make the action specific

Stopping promotional email changes permission for that purpose. It does not necessarily request account closure or erasure of every record. Name the purpose clearly in the privacy centre so the person understands the change and the organisation applies it to the correct activity.

Section 6 addresses withdrawal where consent is the processing basis; the relevant legal context still matters. Keep that assessment distinct from the button’s technical behaviour. Do not quietly substitute another basis for the same campaign simply because a person has chosen to stop receiving it.

Change the permission before the next send

In a connected marketing workflow, record the withdrawal and make the affected permission unavailable to the sending process. The next send should check the current user and purpose state. An old export, a cached permission or a copied mailing list should not bypass that check merely because it was created before the withdrawal.

Keep organisation credentials on the backend. Use the user ID, consent and purpose identifiers to locate the permission consistently. The browser needs enough information to explain the result without exposing the organisation secret or being trusted to decide permission for another person.

Track the connected application’s outcome

Recording a decision and completing the client follow-up are separate events. SecureLay can retain the decision while a connected application reports its work. If a callback fails, make that failure visible and keep the affected processing blocked while the team investigates. A notification that was sent is not the same as an action that was completed.

Retries should refer to the same action rather than creating a confusing chain of duplicate withdrawals. Staff need to see the latest state, when it was recorded and the client outcome. If the person allows the purpose again later, preserve the earlier withdrawal in the history and show the new decision clearly.

Test the whole journey

Create an account, allow the marketing purpose and send a message. Confirm delivery in the recipient view. Then withdraw that purpose and try another send from the administrator view. The useful evidence is the rejected processing attempt and the unchanged recipient inbox, alongside the withdrawal record in the console.

Finally, allow the purpose again and check the next permitted send. Test a callback failure and an unavailable permission check. Keep erasure and continuing record obligations under their own reviewed workflow instead of promising that withdrawal always deletes the account.