How to Protect Customer Data in Your Online Store

How to Protect Customer Data in Your Online Store

Complete guide to data protection in e-commerce. Encryption, access control, backup, GDPR and regulatory requirements.

Introduction

Every online store is a custodian of customer data. From the moment a visitor lands on your site and a cookie is set, to the point where they create an account, place an order, and receive a shipment, you collect, process, and store personal information at every step. This data is valuable — to you for business purposes, and to attackers for fraud, identity theft, and resale on the dark web.

Protecting customer data is simultaneously a legal obligation (under GDPR and Norwegian law), a business imperative (a breach can destroy customer trust overnight), and an ethical responsibility. This guide covers the practical measures every online store should implement, from encryption and access control to backup strategies and regulatory compliance.

Understanding your data landscape

Before you can protect data, you must know what you have. Conduct a thorough data mapping exercise that answers these questions:

What data do you collect? Create a complete inventory:

• Identity data — names, email addresses, phone numbers, dates of birth
• Address data — billing and shipping addresses
• Financial data — payment tokens (never raw card numbers), invoices, refund records
• Behavioral data — browsing history, search queries, clicked products, abandoned carts
• Technical data — IP addresses, device types, browser versions, session IDs
• Communication data — customer service tickets, chat transcripts, email correspondence
• Preference data — newsletter subscriptions, marketing consent, language preferences
• Authentication data — password hashes, 2FA recovery codes, session tokens

Where is it stored? Map every storage location:

• Your primary database (MySQL, PostgreSQL, MongoDB)
• Your CMS or e-commerce platform (WooCommerce, Magento, Shopify)
• Third-party services (email marketing, CRM, analytics, helpdesk, shipping providers)
• Backups (local, cloud, offsite)
• Logs (web server, application, error logs)
• Employee devices (exported spreadsheets, local email clients)

Who has access? Document every person and system with access:

• Admin users and their permission levels
• Developers with server access
• Third-party agencies or freelancers
• Integrated services and their API scopes
• Hosting provider support staff

This data map forms the foundation of your protection strategy and is also a GDPR requirement (Records of Processing Activities / ROPA).

Encryption — the foundation of data protection

Encryption is your primary technical defense against unauthorized data access. Implement it at every layer:

Encryption in transit

All data moving between systems must be encrypted:

• Web traffic — TLS 1.2 or 1.3 on all pages, not just checkout. Configure HSTS with a minimum one-year max-age. Disable older protocols (TLS 1.0, 1.1, SSLv3). Score your configuration at SSL Labs — aim for A+.
• API communications — all API calls between your store and third-party services (payment gateways, shipping APIs, ERP) must use HTTPS. Verify TLS certificate validity and pin certificates for critical integrations.
• Email — use TLS for SMTP connections. Consider S/MIME or PGP for sensitive customer communications (order confirmations with personal data, invoice attachments).
• Database connections — if your database is on a separate server, encrypt the connection with TLS. On cloud platforms, this is usually a configuration option.
• Internal communications — if you use microservices or separate admin tools, encrypt all internal traffic. Do not assume internal networks are safe.

Encryption at rest

Data stored on disk should be encrypted:

• Database-level encryption — enable Transparent Data Encryption (TDE) if your database supports it, or use application-level encryption for sensitive fields (e.g., encrypting customer notes, internal comments, or support tickets that contain personal information).
• Disk encryption — use full-disk encryption on all servers (LUKS on Linux, BitLocker on Windows). Cloud providers offer managed encryption (AWS EBS encryption, Azure Disk Encryption).
• Backup encryption — encrypt all backups with AES-256 before storing them. Never store unencrypted backups in cloud storage.
• Log encryption — if logs contain personal data (IP addresses, email addresses, error messages with user input), encrypt log storage or ensure logs are rotated and deleted according to your retention policy.

Password hashing

Passwords deserve special attention because they must never be encrypted — they must be hashed using a one-way function:

• Use bcrypt, scrypt, or Argon2id — never MD5, SHA-1, or SHA-256 for password hashing
• Use a unique salt per password (handled automatically by bcrypt/Argon2)
• Set a high work factor (bcrypt cost factor of 12+, Argon2 with appropriate memory/time parameters)
• WooCommerce uses WordPress’s phpass library by default, which uses bcrypt — do not override this with a weaker algorithm
• Magento 2 uses bcrypt with SHA-256 — this is adequate
• Never log, display, or transmit passwords in any form

Access control — the principle of least privilege

Every person and system should have the minimum access required to perform their function:

Staff access management

• Define roles clearly — create specific roles for order managers, content editors, marketing staff, developers, and administrators. Each role should only access the data and functions they need.
• Individual accounts — never share admin accounts. Every staff member must have their own account with their own credentials. Shared accounts make audit trails meaningless.
• Two-factor authentication — enforce 2FA for all staff accounts without exception. TOTP apps (Google Authenticator, Authy) are the minimum standard. Hardware keys (YubiKey, SoloKey) are strongly recommended for admin accounts.
• Regular access reviews — audit staff access quarterly. Remove accounts for departed employees immediately. Review elevated permissions and reduce them if no longer needed.
• Session management — set short idle timeouts for admin sessions (30 minutes maximum). Force re-authentication for sensitive operations (changing email addresses, processing refunds, exporting customer data).

Developer and agency access

• Separate environments — developers should work in staging/development environments, not production. Grant production access only when necessary and revoke it after the task is complete.
• SSH key management — use SSH keys, not passwords, for server access. Rotate keys regularly. Remove keys for departed team members immediately.
• API key hygiene — use scoped API keys with minimum required permissions. Rotate keys regularly. Never embed keys in client-side code or commit them to version control.
• Code review — all code changes that touch data processing should be reviewed by a second developer before deployment.

Third-party service access

• Audit app permissions — review the permissions granted to every third-party app, plugin, or integration. Remove any that request more access than they need.
• Data Processing Agreements — sign DPAs with every service that processes customer data on your behalf. This is a legal requirement under GDPR.
• Vendor security assessment — before integrating a new service, evaluate their security practices: Do they encrypt data? Where are their servers located? Do they have SOC 2 or ISO 27001 certification? Have they experienced breaches?

Backup and disaster recovery

Backups are your safety net when everything else fails:

Backup strategy (3-2-1 rule):

• 3 copies of your data (production + 2 backups)
• 2 different storage media or locations (e.g., local + cloud)
• 1 copy offsite (different data center, cloud provider, or geographic region)

Backup schedule:

• Database: automated daily, with point-in-time recovery if possible
• Files: automated daily
• Full system snapshot: weekly
• Retention: minimum 30 days of daily backups, 12 months of monthly backups

Backup security:

• Encrypt all backups with AES-256 before transfer and storage
• Restrict access to backup storage — separate credentials from production
• Store backup encryption keys separately from the backups themselves
• Use immutable storage (write-once) to prevent ransomware from encrypting your backups

Recovery testing:

• Test restoring from backup at least quarterly
• Document the restore procedure step-by-step
• Measure and record your Recovery Time Objective (RTO) and Recovery Point Objective (RPO)
• Verify data integrity after restoration — not just that files exist, but that the data is complete and uncorrupted

Regulatory requirements for Norwegian stores

Norwegian online stores operate under multiple overlapping regulatory frameworks:

GDPR / Personopplysningsloven

• Data minimization — collect only the data you actually need. If you do not need a date of birth, do not ask for it.
• Purpose limitation — use data only for the purpose it was collected. Order data collected for fulfillment cannot be used for marketing without separate consent.
• Storage limitation — define retention periods for each data category and implement automated deletion or anonymization.
• Breach notification — report breaches to Datatilsynet within 72 hours. Notify affected individuals “without undue delay” if the breach poses a high risk to their rights and freedoms.
• Data subject rights — implement processes for access requests, rectification, erasure, portability, and objection.

Bokforingsloven (Norwegian Bookkeeping Act)

• Transaction records must be retained for 5 years (previously 10, reduced in 2024)
• Supporting documentation (invoices, receipts) must be retained for 3.5 years
• This creates a tension with GDPR’s data minimization principle — you must retain financial records but should anonymize or delete non-essential personal data

Markedsforingsloven (Norwegian Marketing Act)

• Unsolicited electronic marketing (email, SMS) requires prior consent
• Existing customer relationships allow marketing of similar products (soft opt-in) but must include an easy opt-out
• The Norwegian Consumer Authority (Forbrukertilsynet) enforces marketing regulations

Ekomloven (Electronic Communications Act)

• Implements the ePrivacy Directive in Norway
• Requires informed consent for non-essential cookies and tracking
• Nkom (Norwegian Communications Authority) has oversight

Handling specific sensitive data types

Payment data

• Never store raw credit card numbers, CVVs, or PINs
• Use PCI-compliant payment gateways: Vipps, Klarna, Dintero, Stripe, Adyen
• Prefer hosted payment pages or iframes over JavaScript-based card forms
• If you must store payment tokens, encrypt them with AES-256 and restrict database access

Customer passwords

• Hash with bcrypt (cost 12+) or Argon2id
• Implement account lockout after 5-10 failed attempts
• Offer password reset via email with time-limited, single-use tokens
• Check passwords against breach databases (Have I Been Pwned API)
• Never email passwords in plaintext — not even temporary ones

Norwegian personal identification numbers (fodselsnummer)

• Avoid collecting fodselsnummer unless legally required
• If collected (e.g., for Klarna or BankID verification), encrypt at the application level with AES-256
• Restrict access to the minimum number of staff members
• Log all access to records containing fodselsnummer
• Delete or anonymize when the legal retention period expires

Customer communication logs

• Chat transcripts, support emails, and phone call recordings may contain sensitive information shared by the customer
• Implement data retention policies for communication channels
• Anonymize or delete resolved support tickets after a defined period (e.g., 24 months)
• Train support staff not to request unnecessary personal information via chat or email

Monitoring and detection

Protection is incomplete without the ability to detect when something goes wrong:

• Access logging — log all access to customer data, especially bulk exports, admin panel access, and API usage
• Anomaly detection — alert on unusual patterns: large data exports, access from unexpected IP addresses or geographies, access outside business hours
• File integrity monitoring — detect unauthorized changes to application files, especially checkout pages and payment processing code
• Database activity monitoring — track and alert on unusual query patterns, mass SELECT queries, or direct database access outside the application
• Regular vulnerability scanning — automated weekly scans of your web application and infrastructure

Data protection checklist

• Data mapping completed — all data categories, storage locations, and access documented
• TLS 1.2+ on all connections, HSTS enabled
• Database encryption at rest enabled
• Backups encrypted with AES-256, stored offsite
• Password hashing with bcrypt or Argon2 (verified, not assumed)
• 2FA enforced for all admin and staff accounts
• Role-based access control implemented with least privilege
• DPAs signed with all data processors
• Privacy policy published, accurate, and accessible
• Cookie consent mechanism implemented
• Data retention policy defined and automated
• Breach notification process documented (72-hour Datatilsynet notification)
• Data subject request process operational (access, erasure, portability)
• Access logging and monitoring active
• Backup restore tested within the last quarter
• Staff trained on data protection responsibilities

Conclusion

Protecting customer data is not a one-time project — it is an ongoing commitment that requires technical measures, organizational processes, and continuous vigilance. The investment pays for itself many times over: in avoiding regulatory fines (up to 4% of global turnover under GDPR), in maintaining customer trust, and in preventing the devastating operational impact of a data breach.

Start with the fundamentals — encryption, access control, and backups. Then build outward: monitoring, incident response, and regulatory compliance. If you need expert guidance, we are here to help.

---

Read also

• Security audit services
• GDPR services
• All guides