The alert hit before the code was even merged. A red flag: GDPR compliance risk. The culprit wasn’t the backend. It wasn’t the database. It was user config–dependent behavior buried deep in the logic.
GDPR compliance user config dependent workflows are dangerous because they shift privacy obligations based on settings that can change at any time. A user toggles a preference, and in an instant, your application’s data handling rules change. If those rules aren’t synchronized with GDPR requirements, you have a compliance gap.
The General Data Protection Regulation is not flexible about personal data processing. Your system must honor rights like erasure, portability, and restriction of processing—regardless of which options a user selects. When compliance depends on config, you risk inconsistent handling of data across users, sessions, and deployments.
Many teams make the mistake of treating GDPR compliance as a static checklist. In reality, when user preferences control data retention, sharing, or tracking, compliance becomes dynamic. Each possible configuration creates its own compliance path. The complexity compounds when configs chain across microservices, background jobs, and integrations.