How to Audit WordPress Plugins for Personal-Data Requests
How should a small business check whether its WordPress plugins are ready for personal-data export and erasure requests?
Review every plugin and connected service that can receive, create or retain user-linked information. Record the active setting, requester identifier or data location, whether the component participates in WordPress export and erasure, who owns it, and whether erasure reports retained information. A privacy-friendly default is not enough when an optional feature changes what the component records.
Check active settings, not only plugin defaults
WP Statistics says that it does not collect personal data by default. Use that default only as a starting point, then inspect the active configuration of every installed component that could handle requester-linked information. Record the component, setting reviewed, current value, verified data effect, coverage status and owner of any unresolved question.
Sources: Compliant with WordPress Data Export and Erasure - WP Statistics.
WP Statistics says that its Record User Page Views option records user IDs, which it describes as personal data. That example is specific to WP Statistics, so obtain current product-specific evidence before reaching the same conclusion about another extension.
Sources: Compliant with WordPress Data Export and Erasure - WP Statistics.
- Review live settings, not only plugin descriptions.
- Identify options that create or store requester-linked identifiers.
- Obtain current documentation for every component reviewed.
Test participation in WordPress privacy tools
WP Statistics says it exports or erases its relevant data when WordPress tools are used. For every relevant plugin, check current documentation and, where appropriate, run a controlled test showing whether requester-linked data appears in the expected WordPress workflow. Confirm the provider’s current prerequisites before a service-affecting or irreversible test, and mark participation unverified when the result cannot be established.
Sources: Compliant with WordPress Data Export and Erasure - WP Statistics.
- Review current product documentation.
- Use a controlled test where appropriate.
- Mark coverage unknown when participation cannot be verified.
Map dependencies between WordPress and extensions
WooCommerce says that WordPress, WooCommerce and many extensions work together to erase a person’s personal data. Map the site as a system by giving every relevant component one worksheet row with its active setting, requester identifier or data location, privacy-tool participation, owner and coverage status. Include connected services that hold requester-linked information, but mark their participation unverified unless current documentation or an appropriate test supports it.
Sources: Right to Erasure Requests for GDPR with WooCommerce.
- Treat WordPress, extensions and integrations as connected components.
- Use one worksheet row for each component.
- Assign an owner and coverage status to every component.
Record retention and manual-review outcomes
WooCommerce says that information a plugin needs to retain is displayed at the end of the erasure process. When a component reports retained information, record the displayed outcome, responsible component, reviewer and next action in that component’s worksheet row. Escalate whether retention is appropriate or further action is required; the audit identifies the exception but does not provide a legal conclusion.
Sources: Right to Erasure Requests for GDPR with WooCommerce.
- Capture the exact retained-data outcome.
- Name the component, reviewer and next action.
- Do not decide legality from a plugin message alone.
Plugin data-request readiness matrix
Use one row for every relevant plugin or connected service. The matrix records ownership, live configuration, data location, privacy-tool participation and any retained-data follow-up without assuming every extension integrates with WordPress privacy tools.
| Component and owner | Active setting checked | Requester identifier or data location | Export and erasure participation | Retention outcome and next action |
|---|---|---|---|---|
| WP Statistics example; assign site owner | Record User Page Views enabled or disabled | User ID when the option is enabled | Check current documentation and a controlled test where appropriate | Record observed result, reviewer and next action. |
| Each other relevant component; named owner | Actual enabled setting and current value | Actual identifier or storage location | Verified, unverified or not applicable | Displayed result; reviewer; next action. |
Record only observed configuration and supported outcomes. An unknown integration or retained-data message requires a named reviewer and next action rather than an automatic compliance conclusion.
Related guidance
What follow-up questions matter most?
- Is a privacy-friendly default enough?
- No. WP Statistics describes a default that does not collect personal data, while an optional page-view setting records user IDs. Treat that contrast as a reason to inspect active settings, not as a rule about every plugin.
- How do I test privacy-tool participation?
- Where appropriate, use a controlled request in a suitable test environment, review current plugin documentation and record the installed component and configuration tested. Do not assume one plugin’s integration proves another plugin participates.
- What belongs in a retention record?
- Record the exact displayed outcome, responsible component, reviewer and next action. A retention notice requires review and does not by itself establish whether retention is appropriate.
What steps does this workflow follow?
Audit plugins for WordPress personal-data requests
- List relevant components: List plugins and connected services that can receive, create or retain information linked to a user.
- Inspect active settings: Check enabled options that affect collection, identifiers, storage or integrations rather than relying on default descriptions.
- Test tool participation: Review current documentation and, where appropriate, use a controlled test to determine whether the component contributes to WordPress export and erasure.
- Map dependencies: Record the component, active setting, data location or requester identifier, expected privacy-tool action, owner and coverage status.
- Capture exceptions: Record any retained-data message, responsible component, reviewer and next action without making an unsupported legal conclusion.