Personal data requests
What the plugin hands over when someone asks to see or delete their data, what it keeps back, and why.
- Intermediate
- 6 min read
- Applies to 2.0
The tools this answers
WordPress ships two, under Tools: Export Personal Data and Erase Personal Data. Both work by asking every plugin what it holds about an email address, then assembling the answers.
Attributes registers with both, so what it holds shows up in the export and comes out on erasure — with two deliberate exceptions, below.
This matters because a plugin that registers nothing is not flagged as missing: it is simply absent from the result, and the report looks complete. So an export that does not name its source for this data is not necessarily excluding it — but one that does, is accounting for it.
What the export contains
| Group | What is in it |
|---|---|
| Failed sign-in attempts | the identifier tried, the method, how many failures, when, the IP address and the browser string |
| Account activity log | every audit entry for the account — when, what happened, from which address, with which browser |
| Connected sign-in providers | which providers are linked, the address and name held there, when connected and last used |
| Two-factor authentication | whether the account is enrolled — never the secret |
Failed attempts are matched on the address itself as well as on the account.
Somebody who tried to sign in as you@example.com and never got in produced a
record about you, whether or not that address has an account here.
The authenticator secret and the backup codes are deliberately left out.
They are what an app derives its six-digit codes from. Putting them in a file the member downloads — or that arrives in their mailbox — would hand over the second factor in the name of transparency, to whoever opens the message. The export says the account is enrolled, which is the fact being asked about.
What the erasure removes, and what it keeps
Removed: failed sign-in counters for that address, connected providers, and any outstanding magic links.
Kept, and reported as kept:
- The security activity log. It records who reached the site and when. It is the thing an administrator reads after a break-in, and in many places keeping it for a stated period is itself an obligation. It would also make the erasure tool an excellent way of covering one's tracks. It clears itself instead, on the retention period set on User Access → Security.
- Two-factor enrolment. Removing it is done from the account. Otherwise a privacy request becomes a way of switching off somebody's second factor.
WordPress shows both of these to the requester as retained items with the reason attached, rather than quietly dropping them from the report.
How long things are kept
| Data | Kept for |
|---|---|
| Audit log entries | your retention setting, 30 days by default |
| Failed sign-in counters | the same setting, unless you change it |
| Magic links | until they expire, then to the next daily purge |
Failed sign-in counters follow the audit retention by default so that "we keep sign-in records for thirty days" is true of both. To set them apart:
add_filter( 'attrua_pro_login_attempts_retention_days', function () {
return 7;
} );The daily purge that enforces this is attrua_pro_purge_expired. It catches up
on an admin page load if a day passes without running, so a site whose cron is
misconfigured does not silently keep personal data for ever — see
The scheduled tasks.
- You have run an export against a real address and read what comes back
- Your retention period is the one your privacy policy states
- Whoever answers these requests knows the log and the 2FA enrolment are kept
Related articles
Something missing or out of date? Tell support.