How to Get Customer Accounts and Data Right
What a store stores about its customers, why, and how that is protected and honored.
Marcus Adeyemi
Where most projects go wrong
The usual mistakes:
- Collecting data because it might be useful later
- Indefinite retention
- Handling subject requests manually at volume
- Storing payment details outside a compliant provider
What good looks like instead
- Record a lawful basis for each processing purpose
- Collect only what is needed and delete it when it is not
- Build subject access and erasure as functions, not manual processes
- Set and enforce retention periods
- Have a breach response plan before you need it
Why it matters
Customer data carries legal obligations that apply whether or not anyone has thought about them, and the penalties are real.
The specs that matter
| Measure | Figure |
|---|---|
| Legal framework | UK GDPR and the EU GDPR for customers in those markets |
| Lawful basis | required for every processing purpose |
| Data minimization | collect only what is needed for the stated purpose |
| Subject rights | access, rectification, erasure and portability |
| Retention | defined periods rather than indefinite storage |
| Breach notification | required within defined timescales |
Knowing when to hand it over
Tip: Bring in help when subject requests cannot be fulfilled, when retention periods are undefined, or after any suspected data breach.
Where this comes from
- Information Commissioner's Office — UK GDPR guidance
- European Commission — Data protection rules
- OWASP — Data protection practices
The figures and practices above come from the sources listed.
Working on something like this?
We take on E-commerce Development work for teams who want it done once, properly. Tell us what you are building and we will tell you honestly whether we are the right studio for it. Start a project.
Where to go next
Spotted something wrong? Report an error on this page. We correct on the page and say what changed.
