Privacy in Joomla

1. The Basics

1.1 What is the Joomla Privacy Suite?

The Privacy Suite is Joomla's built-in toolkit for data-protection law such as the EU's GDPR. Joomla introduced it in version 3.9 (May 2018) and it has shipped in core ever since. It is not a single screen but a small set of cooperating parts:

• A component, com_privacy, with a dashboard, requests, consents, and capabilities.
• A group of privacy plugins that know how to export and remove data for one area each.
• A Privacy Consent system plugin that asks logged-in users to agree to your privacy policy.
• A Terms and Conditions user plugin for the registration form.

You do not install anything. Everything described here is already in your Joomla. You only need to switch on and configure the parts you want.

1.2 What "Personal Data" Means Here

Under GDPR, personal data is any information that can identify a living person. On a typical Joomla site that includes:

• The name, username, and email in #__users.
• Contact-form and contact-component entries.
• Private messages between users.
• IP addresses stored in the action log.
• The record that a person consented to your privacy policy.

The Privacy Suite is built around two rights that the law gives every person: the right of access (give me my data) and the right to erasure (delete my data). Joomla calls these an export request and a removal request.

1.3 Where Do I Find It?

In the Joomla 6 backend the Privacy Suite lives under the Users menu:

Users  → Privacy                  the Privacy heading opens the dashboard
Users  → Privacy → Requests       export and removal (information) requests
Users  → Privacy → Capabilities   what data each area processes
Users  → Privacy → Consents       who agreed to the privacy policy
System → Manage → Plugins         the privacy and consent plugins

The component itself lives at administrator/components/com_privacy/. Two small naming quirks are worth knowing up front. First, it sits under Users, not under System, which trips up people who expect a privacy tool to be a system setting. Second, there is no separate "Dashboard" link: the Privacy heading in the menu is the dashboard. The Requests screen also reads Privacy: Information Requests at the top of the page, even though the sidebar link is just Requests.

1.4 What the Privacy Suite Does Not Do

One point clears up most confusion before it starts: the Privacy Suite is a framework for information requests and consent records, not a magic compliance button. In particular, it does not handle:

• Cookie banners or cookie consent.
• Analytics and tracking consent, such as gating Google Analytics or Matomo until a visitor agrees.
• Marketing opt-ins for newsletters or advertising.
• Third-party scripts that load before a user has agreed.

Those need separate configuration or a dedicated cookie-consent extension. Installing com_privacy does not, on its own, make a site GDPR compliant. It gives you a structured way to answer data-subject requests and record consent, which is one important piece of compliance, not the whole of it.

3. Information Requests: Export and Removal

3.1 The Two Request Types

Everything the suite does for an individual flows through a request. There are exactly two kinds:

A request is tied to one email address, not to a user id. That is deliberate: the person asking may be a guest who filled in a contact form, not a registered user.

3.2 Creating a Request as an Administrator

To handle a request that arrived by email or post:

1. Go to Users → Privacy → Requests and click New.
2. Enter the person's email address.
3. Choose Export or Removal.
4. Save. Joomla emails a confirmation link to that address.

The confirmation step matters. By sending a token to the email address, Joomla makes sure the person who controls that mailbox actually wants the action. This stops one user from deleting another user's account by guessing an email.

3.3 Letting Users Submit Their Own Requests

You can also let people start the process themselves, without an admin in the loop. The Privacy component ships front-end menu item types for exactly this:

• Create Request: a public form where a visitor enters their email and chooses export or removal.
• Confirm Request: the landing page the confirmation email links to.
• Extend Consent: a page where a logged-in user renews their privacy consent.

Build a menu item of each type, link them from your privacy policy page, and the whole confirm step runs on its own. You still process the confirmed request by hand, which keeps a human in control of any deletion.

3.4 The Confirmation Email and Mail Templates

The whole request flow depends on one email reaching the person. Joomla sends it through its central mail templates system, so you can review and translate the wording under System → Templates → Mail Templates. Find the privacy request confirmation template and adjust the text to sound clear and non-technical.

Because that email is the gatekeeper, make sure it actually arrives:

• Use a real SMTP service rather than PHP mail() for reliable delivery.
• Set up SPF, DKIM, and DMARC so the message is not filtered as spam.
• Send a test before you open a public request form.

If mail does not work, requests pile up at Confirmation Pending and the whole suite quietly stops being useful.

5. Consents: Recording Agreement

5.1 What a Consent Record Is

The law often asks you to prove that a person agreed to something, and when. The Users → Privacy → Consents view is that proof. Each row records that a specific user agreed to a specific document (your privacy policy) at a specific time.

A consent record stores the user, the subject and body of what they agreed to, the date, and a state (valid or revoked). Because the suite saves the actual text the user saw, you can show later exactly what they agreed to, even if you change the policy afterwards.

5.2 Where Consents Come From

Consent rows are written by the Privacy Consent plugin (section 6) when a logged-in user ticks the agreement box. They are not created by hand. The Consents view is read-only in spirit: you review and, if needed, invalidate a consent, but you do not type one in.

This is the same philosophy as the action log: a record you can freely edit is not trustworthy evidence, so Joomla limits what you can change.

7. Terms and Conditions vs Privacy Consent

7.1 Two Plugins, Two Moments

People often confuse the two consent plugins because both put a checkbox in front of the user. The difference is when they act:

The overlap is the Privacy Consent plugin: it adds its checkbox to the user registration and profile forms, and it also redirects an already-logged-in user who has never consented to a consent page. So it can act both at sign-up and on a later visit. The Terms and Conditions plugin, by contrast, acts only on the registration form.

7.2 Which to Use

Use Terms and Conditions when you want every new account to accept your site rules at the moment they sign up. Use Privacy Consent when you also want existing users, who registered long before you wrote a policy, to give a recorded, dated agreement. Many sites run both: terms at the door, privacy consent on the way in.

Only the Privacy Consent plugin writes rows into the consents table that the Privacy Suite can later export and audit. The terms plugin simply blocks registration until the box is ticked.

9. Under the Hood (Developer View)

9.1 The Database Tables

The Privacy Suite keeps its state in two main tables:

#__privacy_requests    one row per export or removal request
#__privacy_consents    one row per recorded consent

The core fields of #__privacy_requests are:

id                       auto-increment primary key
email                    the data subject's email address
requested_at             when the request was created
status                   confirmation pending / confirmed / completed / invalid
request_type             'export' or 'remove'
confirm_token            hashed token sent in the confirmation email
confirm_token_created_at when the token was issued (for expiry)

The core fields of #__privacy_consents are:

id        auto-increment primary key
user_id   the user who agreed
state     1 = valid, 0 = revoked
created   when consent was given
subject   the title of what they agreed to
body      a snapshot of the agreed text

9.2 The Plugin Group

The real work is done by plugins in the privacy group, each extending Joomla's PrivacyPlugin base class. The component never touches user, contact, or message tables directly. Instead it fires events and lets each plugin handle its own data. This is the same loose-coupling pattern Joomla uses across the CMS: the component orchestrates, the plugins do the domain work.

9.3 The Four Events

A privacy plugin can subscribe to four events:

9.4 How an Export is Built

An export is not one big query. Each plugin returns one or more domains, and each domain holds items made of name-value fields. The component collects every plugin's domains and serialises the whole set to XML. A simplified export handler looks like this:

public function onPrivacyExportRequest(PrivacyExportRequestEvent $event)
{
    $request = $event->getRequest();
    $user    = $event->getUser();

    $domain = $this->createDomain('user_profile', 'Joomla user account');
    $item   = $this->createItemForUserId($user->id, $tableData);
    $domain->addItem($item);

    return [$domain];
}

Because every plugin speaks the same domain-item-field shape, the export file is consistent no matter how many extensions contribute to it.

11. Making Your Own Extension Privacy-Aware

11.1 Why Bother

If your component stores personal data, for example a booking system with names and phone numbers, it should join the Privacy Suite. Otherwise an export will be incomplete and a removal will leave personal data behind, both of which break the promise you made in your privacy policy.

11.2 The Three Steps

Write one plugin in the privacy group that subscribes to the events you need:

1. Implement onPrivacyCollectAdminCapabilities so your data shows in the Capabilities view.
2. Implement onPrivacyExportRequest to return your data as domains and items.
3. Implement onPrivacyRemoveData (and optionally onPrivacyCanRemoveData) to erase or anonymise it.

A minimal capabilities handler is enough to make your extension visible to an auditor:

public function onPrivacyCollectAdminCapabilities()
{
    $this->loadLanguage();

    return [
        Text::_('PLG_PRIVACY_BOOKINGS') => [
            Text::_('PLG_PRIVACY_BOOKINGS_CAPABILITY_NAME'),
            Text::_('PLG_PRIVACY_BOOKINGS_CAPABILITY_PHONE'),
        ],
    ];
}

11.3 Anonymise Rather Than Delete

For a removal, deleting a row is not always right. If you delete a booking outright you may break an invoice that legally must be kept. The common pattern is to anonymise: replace the name, email, and phone with neutral placeholders while keeping the record's structure intact.

UPDATE #__bookings
SET customer_name  = 'Removed',
    customer_email = CONCAT('removed-', id, This email address is being protected from spambots. You need JavaScript enabled to view it.'),
    customer_phone = ''
WHERE customer_email = :email;

Whichever you choose, always bind the email as a parameter rather than concatenating it into the SQL. Joomla's query builder makes this easy with ->bind(':email', $request->email). Building the query string by hand opens an SQL-injection hole on the very data you are trying to protect.

Anonymising satisfies the right to erasure for personal data while preserving the non-personal accounting trail. Choose deletion only when no other obligation requires you to keep the row.

11.4 When to Block a Removal

Sometimes the right answer to a removal is "not yet". Your onPrivacyCanRemoveData handler is where you say so, with a clear reason the administrator can read. Common, defensible blockers include:

• An unpaid invoice or an open order.
• An active subscription or membership.
• A legal-retention period, such as tax records you must keep for years.
• An open dispute, chargeback, or fraud investigation.

Blocking is not a refusal of the person's rights; it is a documented pause while a stronger legal obligation applies. Record why, and remove the data once the obligation ends.

11.5 Keep Exports Clean and Safe

An export is read by the person, and sometimes by a regulator, so design it for them, not for your database. Two rules matter most:

• Make it readable. Return meaningful domains and items ("Profile", "Bookings", "Newsletter status"), not raw table dumps or serialized blobs.
• Never leak more than the person. An export must contain only that individual's data. Keep out other users' records, internal tokens, API keys, password hashes, and configuration secrets.

Over-sharing in an export is itself a data breach. When in doubt, include less and label it clearly.

13. IP Addresses, Logs, and Other Personal Data

13.1 The Action Log Connection

The most easily forgotten store of personal data is the action log, because an IP address counts as personal data under GDPR. The plg_privacy_actionlogs plugin ties the two systems together: when you export a person's data, their action-log rows are included, and a removal can scrub them.

If you turn on IP logging in the action log, write that into your privacy policy and set a retention period. An IP kept forever is hard to justify; a 90-day window for security is easy to defend.

13.2 Data the Suite Does Not See

The Privacy Suite only knows about data that a privacy plugin reports. It cannot reach:

• Personal data inside a third-party extension that ships no privacy plugin.
• Data in external systems, such as a newsletter platform or a payment provider.
• Backups and database dumps stored outside Joomla.

When you answer a removal request, remember the data living outside Joomla's reach. A complete erasure often means a few manual steps beyond the button in com_privacy.

13.3 Finding Where Personal Data Hides

Before you trust an export to be complete, find out where personal data actually lives. A quick audit query lists every column that looks like an email address across the whole database:

SELECT TABLE_NAME, COLUMN_NAME
FROM   INFORMATION_SCHEMA.COLUMNS
WHERE  TABLE_SCHEMA = DATABASE()
  AND  COLUMN_NAME LIKE '%email%'
ORDER  BY TABLE_NAME, COLUMN_NAME;

Repeat it for %phone%, %ip%, and %name%. Each table that turns up but has no matching privacy plugin is a blind spot in your export and removal. This query does not replace proper privacy plugins; it tells you which ones you still need to write or install.

15. Common Mistakes and Pitfalls

15.1 "The Confirmation Email Never Arrives"

Symptom: a request stays at Confirmation Pending forever, and the user says they got nothing.

Fix: the suite uses Joomla's mailer. Check System → Global Configuration → Server → Mail and send a test. On a local stack, a catcher like MailHog confirms whether Joomla sent the message at all. No working mail means no privacy workflow.

15.2 "I Enabled Privacy Consent and Locked Everyone Out"

Symptom: every logged-in user is bounced to a consent form, including you.

Fix: this is expected behaviour, but it needs a real policy to point at. Before enabling the plugin, publish the privacy article and select it in the plugin's Privacy Article setting. Then the consent form has something to show.

15.3 "The Export is Missing Data"

Symptom: an export does not include messages, contacts, or a third-party extension's data.

Fix: a privacy plugin only contributes while it is enabled. Check that every relevant privacy plugin is on, and remember that extensions without a privacy plugin are invisible to the export.

15.4 "A Removal Did Nothing"

Symptom: you click Remove Data and the account survives.

Fix: a plugin vetoed it. The user plugin refuses to remove a Super User. Lower the account's group or transfer its content first, then retry, or handle that account by hand.

15.5 "We Deleted the User but the Data Came Back in a Backup"

Symptom: a removed person reappears after a restore.

Fix: erasure must cover backups in your retention policy. You usually cannot edit old backups, so document that personal data persists in backups for a stated period and is overwritten as backups rotate.

15.6 "Privacy is Not in My Menu"

Symptom: you cannot find the Privacy screens.

Fix: they are under Users, not System, and ACL hides them from anyone without access to the component. Check the account's group permissions.

17. Quick Reference

DASHBOARD     Users → Privacy  (the heading itself)
REQUESTS      Users → Privacy → Requests
CONSENTS      Users → Privacy → Consents
CAPABILITIES  Users → Privacy → Capabilities
OPTIONS       Users → Privacy → Requests → Options
URGENT DAYS   Options → Days To Consider Request Urgent (default 14)
CONSENT PLUG  System → Plugins → System - Privacy Consent
TERMS PLUG    System → Plugins → User - Terms and Conditions
PLUGIN GROUP  privacy (user, contact, message, consents, actionlogs)
TABLES        #__privacy_requests, #__privacy_consents
REQUEST TYPE  export  |  remove
STATUSES      confirmation pending → confirmed → completed | invalid
EXPORT FORMAT XML, built from plugin domains and items
EVENTS        onPrivacyCollectAdminCapabilities, onPrivacyExportRequest,
              onPrivacyCanRemoveData, onPrivacyRemoveData
REST API      none in core (by design)
MAIL TEMPLATE System → Templates → Mail Templates
NOT COVERED   cookie consent, analytics/marketing opt-ins
SINCE         Joomla 3.9 (May 2018)