Compliance and GDPR #

This page is for the compliance staff, product managers and system administrators of a host, and for support staff who receive a customer's data protection request. It describes what the software provides: privacy defaults, consent records, access and erasure commands, and retention settings found in the repository. It does not say whether a site complies with any law.

Contents #

1. Roles: who decides what
2. Privacy defaults in the logs
3. The audit trail and personal data
4. Mail consent, unsubscribe and suppression
5. Requests from data subjects
6. Security of processing
7. What stays with the host and the customer
8. Checklist

Roles: who decides what #

In a typical hosting arrangement the customer decides why and how personal data on their site is processed, and the host runs the infrastructure on the customer's behalf. Which legal role each party has, and what contract between them is required, is for the parties and their counsel to settle. For the host the practical consequence is: give the customer the facts and the tools below, keep your own operational logs and backups under control, and support requests when the customer asks.

Privacy defaults in the logs #

MaskIP=disabled writes full addresses; Request logs says to use it "only for a site that has a reason and a legal basis for it". The web server's own access logs (Apache, nginx, the panel's) are outside Exponential and follow the host's settings.

The audit trail and personal data #

From 4.12 Privacy and GDPR tasks of the audit guide, which also says it is not legal advice:

• Minimization by default: addresses truncated to /24 (IPv6 /48), sessions hashed, user agents reduced to browser and OS family, e-mail addresses and attempted logins of unknown users hashed; never passwords, tokens, reset keys, secrets or POST bodies; reads off.
• Stricter: per field full | truncate | hash | off in [AuditPrivacySettings] Field[], BeforeAfter=keys, shorter retention; the strict-privacy configuration.
• Pseudonymization: the index replaces personal fields by their hashed form after PseudonymiseAfterDays (90); the files are not rewritten, because that would break the chain.
• Access request: exp:audit export --subject-user=<id> exports every record by or about a user; review it before handing it out, because it holds other people's actions on that user too.
• Erasure: the guide describes keeping audit records for their retention period and answering with that period and the pseudonymization applied; deleting one would break the chain.

Mail consent, unsubscribe and suppression #

Since 6.0.15 every mail passes the mail gate (13.13):

• Essential categories (security, orders, legal, admin) always go out.
• Optional categories go only to recipients who switched them on, off until the person turns them on, with a footer, a one-click unsubscribe link and List-Unsubscribe headers (RFC 8058).
• Consent log: every change of a person's preferences with time, source, the text shown, IP address and acting user; double opt-in for newsletters and marketing.
• Suppression list: hard bounces, complaints, "stop all" and legal requests; only a salted hash of each address is stored.

The law checklist maps each requirement of CAN-SPAM, GDPR and ePrivacy, CCPA/CPRA and CASL to the code and the test that proves it, and lists what is left to the site (Left to the site):

1. the postal address in the footer (mailpreferences.ini [FooterSettings] OrganisationAddress, empty after an installation) and the sender's name (OrganisationName);
2. a category for every commercial mail sent by custom code;
3. keeping [GateSettings] SplitRecipients=enabled;
4. DKIM signing of List-Unsubscribe and List-Unsubscribe-Post by the mail server;
5. a link to the privacy notice on the registration form, if the design wants one.

Point 4 is often the host's job, because the host runs the mail server; see Mail delivery and Mail consent and bounces. Check the state of a site with:

php bin/php/console exp:mail:status

Requests from data subjects #

Delete exported files when the request they answer is done; they hold addresses. Give mailpreferences/export and audit/read to few people.

Security of processing #

What the software contributes, each described on its own page: bcrypt password hashes and password rules, two-step sign-in, encrypted unsubscribe tokens, session protection, the audit trail with hash chains, security headers and a Content Security Policy (Hardening for hosts). What the host contributes: isolation between customers, encrypted backups, patching, access control for staff, and logs forwarded to systems with their own access rules (Multi-tenant isolation).

What stays with the host and the customer #

• Contracts between host and customer, and their roles under the law.
• The privacy notice, the record of processing activities, and the retention values stated there; the software's retention settings must then be set to match (Log and data retention).
• Backups: the retention of personal data in backups, and how erasure is handled for data that also sits in a backup.
• Web server, mail server and panel logs outside Exponential.
• Third-party services a site embeds (maps, analytics, fonts), which the Content Security Policy makes visible but does not judge.
• Newsletter statistics: the cjw_newsletter extension counts opens and clicks only when the site switches it on ([TrackingSettings] Tracking=disabled by default) and per person only with consent; the checklist names what the site must state in its privacy notice.

Checklist #

• To do: The customer knows which personal data the site's logs, audit trail and mail system keep, from this page and the linked sources.
• To do: MaskIP left enabled unless the customer has a documented reason.
• To do: Audit privacy and retention settings agreed with the customer; a stricter profile applied where asked.
• To do: Mail footer filled in; exp:mail:status clean; DKIM signing on the host's mail server.
• To do: A documented way to answer access and erasure requests, including exported files being deleted afterwards.
• To do: Backup retention for personal data decided and written down.
• To do: Legal questions referred to the customer's and the host's own counsel.

Related pages #

• Security for hosts: overview
• Log and data retention
• E-mail preferences: the law checklist
• E-mail preferences: the administrator's guide
• Audit: privacy and GDPR tasks
• Free documentation: this page is free to copy, translate and improve under the GNU FDL 1.3.