# GDPR.md — Data Protection & Privacy Engineering Guide

This document describes how GDPR principles are applied across our systems from an **engineering, operational, and architectural** perspective.

It is **not** a customer-facing privacy policy.
It exists to guide developers, system designers, and operators.

**Last verified:** 2026-02-09 14:50

---

## 1) Scope & Purpose

This system supports:
- B2B eCommerce
- B2C eCommerce
- POS / in-person transactions

It processes personal data relating to:
- customers
- business contacts
- end users
- staff (where applicable)

This document applies to:
- application code
- integrations
- databases
- logs
- backups
- analytics
- operational processes

---

## 2) GDPR Roles

Depending on deployment and client relationship, we act as:

- **Data Processor** (most common for client-owned stores)
- **Data Controller** (for our own B2C / POS operations)

The **client** is typically the Data Controller for their customers.
We process data only on documented instructions unless otherwise agreed.

---

## 3) Categories of Personal Data

Systems may process the following categories:

### Identification & Contact
- Name
- Email address
- Phone number
- Company name
- Billing and delivery addresses

### Account & Commercial
- Account credentials (hashed)
- Order history
- Pricing agreements
- Credit account status
- Transaction records (B2B / POS)

### Technical
- IP address
- Device/browser metadata
- Session identifiers
- Audit logs

### Payment
- Payment tokens or references (via PSPs)
- **No raw card data is stored**

---

## 4) Lawful Basis for Processing

Typical lawful bases include:
- **Contractual necessity** (orders, accounts, invoicing)
- **Legal obligation** (tax, accounting records)
- **Legitimate interest** (fraud prevention, system security)
- **Consent** (marketing communications, cookies)

Consent-based processing must be:
- explicit
- revocable
- auditable

---

## 5) Data Minimisation & Purpose Limitation

Engineering principles:
- Collect only data required for defined business functions
- Avoid duplicating personal data across systems
- Avoid embedding personal data in free-text fields
- Avoid storing personal data in logs unless required

Do not:
- repurpose data without documented lawful basis
- retain personal data “just in case”

---

## 6) Data Storage & Security

### Storage
- Databases are access-controlled
- Production data is separated from development where possible
- Secrets and credentials are not stored in source control

### Security Measures
- HTTPS enforced
- Passwords hashed using industry standards
- Role-based access controls
- Audit logging for sensitive actions

---

## 7) Integrations & Data Sharing

External integrations may include:
- ERP systems
- Payment providers
- Email services
- Shipping providers
- Analytics tools

Rules:
- Share only required fields
- Prefer identifiers over full personal records
- Document data flows for each integration
- Ensure DPAs are in place where required

---

## 8) Data Subject Rights (DSAR)

The system must support:
- Right of access
- Right to rectification
- Right to erasure (where legally permitted)
- Right to restriction
- Right to data portability

Engineering expectations:
- Personal data must be retrievable by identifier
- Deletion/anonymisation must be deterministic
- Legal retention requirements must be respected

---

## 9) Retention & Deletion

Retention periods depend on:
- legal requirements (e.g. tax records)
- contractual obligations
- operational necessity

Typical patterns:
- Orders/invoices retained for statutory period
- Inactive accounts reviewed periodically
- Soft delete followed by anonymisation where required

Deletion must:
- remove or anonymise personal data
- not break referential integrity
- preserve legally required records

---

## 10) Logging, Monitoring & Backups

### Logs
- Avoid logging personal data unless required
- Mask sensitive fields where possible
- Logs have defined retention periods

### Backups
- Encrypted at rest
- Access-restricted
- Subject to retention and expiry rules
- Included in erasure/anonymisation procedures where feasible

---

## 11) Development & Testing Rules

- Do not use real personal data in development or testing
- Anonymise or synthesise data where possible
- Restrict access to production data
- Debug output must never expose personal data

---

## 12) Incident Management

In the event of a suspected data breach:
- Contain and assess immediately
- Identify affected data and subjects
- Notify the Data Controller without undue delay
- Support regulatory notification where required

Incident response procedures must be documented and rehearsed.

---

## 13) Documentation & Accountability

- Data flows should be documented
- GDPR-relevant changes must be reviewed
- This document must be kept up to date with system behaviour

---

## 14) AI & Automation Considerations

When using AI or automation:
- Do not expose personal data unnecessarily
- Avoid using live customer data in prompts
- Ensure data minimisation in AI-assisted tooling
- Treat AI systems as processors unless explicitly defined otherwise

---

## 15) When in Doubt

If a change affects:
- personal data handling
- data sharing
- retention
- visibility of personal data

Stop and ask before proceeding.
