Skip to main content

Consent Notices

Last verified: 2026-08-11

Awthy can help site owners present consent notices, categorize optional tracking, record visitor choices, and release configured snippets after consent. The site owner remains responsible for legal copy, category choices, lawful basis, region requirements, and enabled tracking tools.

Notice display styles​

Use the display style that matches the store's privacy posture and theme. A notice should be readable, dismissible only when appropriate, and clear about which categories are required versus optional.

Do not use Awthy's UI copy as a substitute for legal review.

Draft, activate, and deactivate​

Editing a notice does not change the notice visitors currently see. Save the edits as a draft, review the saved categories and copy, and then select Activate notice to make that policy live. If a notice is already active, saving another draft leaves the active version unchanged until the new draft is activated.

Deactivation requires confirmation and stops the public notice without deleting existing minimized consent records. An archived policy can be activated again from the same settings screen. Failed saves preserve the current draft for retry, while failed activation or deactivation leaves the previously active state unchanged.

Categories​

Consent categories should describe what the site actually uses. Required categories cover functionality the site needs to operate. Optional categories can cover analytics, marketing, or other tracking the site owner chooses to enable.

Required categories are always enabled. Each optional category can be enabled or disabled in the saved policy; disabled categories are not offered to visitors and their snippets are not released.

Avoid vague catch-all categories. Visitors should understand what changes when they opt in or out.

Snippet release​

Awthy stores declarative snippet registrations and releases them only when the required category consent is satisfied. It should not store arbitrary raw script bodies as secret business logic or act as a general tag manager replacement.

Review snippets before enabling them. Site owners are responsible for the behavior of third-party tools those snippets load.

Consent records store minimized evidence such as policy version, selected categories, locale, timestamps, hashed visitor/source evidence, and optional WordPress user ID. They do not store raw IP addresses, raw user agents, full URLs, browser fingerprints, session IDs, cart tokens, order keys, or customer journey sequences.

Retention preview​

Use retention previews to understand how long consent evidence is kept. Retention should match the site's privacy policy and legal requirements.

What Awthy does not decide​

Awthy does not decide whether a site needs consent, which lawful basis applies, what the privacy policy must say, whether a tool is legally allowed, or whether a region-specific banner is sufficient. Those decisions belong to the site owner and their advisors.

Fleet status, scan campaigns, and signed rule releases​

When a site opts in to Awthy Hub fleet status and scan campaigns, Awthy sends a tightly bounded set of operational metadata to Hub. The current scope is:

  • Data sent. A signed rule version, the SHA-256 identity of the verified rule bundle, scan-campaign idempotency keys, an exact-finding payload digest (a hash of the structured finding, not the matched content), bounded counts grouped by severity and rule identifier, reinfection state, and a coarse remediation outcome. Hub never receives WordPress customer records, credentials, authorization headers, cookies, raw file bodies, file paths, matched snippets, or scan error bodies in the fleet-status report.
  • Retention. Fleet-status history is kept for up to 90 days. The latest status for a disconnected, deleted, or deactivated install is hidden immediately and becomes eligible for bounded deletion after 30 days. Account deletion and install disconnection controls therefore remove access first; scheduled cleanup completes the physical deletion within those windows.
  • Deletion window. A paused, cancelled, or unreachable campaign leaves the campaign state on the install and is removed by the same bounded cleanup that runs after 30 days of inactivity. Replays of the same idempotency key are no-ops at the persistence boundary.
  • Retention extension. Extending either retention window requires an explicit Awthy owner approval and is not configurable from a site owner's dashboard. The current windows and the supporting data contract are documented in the Awthy fleet rule and scan operations guide.

Managed recovery content​

When managed recovery is enabled, authorized Hub processing retains exact file versions, logical database snapshots, recovery-point manifests, and their bounded integrity metadata in private, non-web Cloudflare R2 storage. Cloudflare provides the R2 storage and Worker processing platform for this Hub path. Requests use TLS and account/install-scoped authorization. Awthy stores immutable SHA-256 identities and storage receipts, not retained file bodies, generated diff bodies, raw SQL, or database row values in the WordPress database. Hub processing can read the retained content to compare versions, identify known threats, and prepare isolated recovery output; Awthy does not offer customer-selected storage regions or customer-managed keys for this v1 recovery content.

Recovery objects and verified database snapshots are retained for at most 90 days. Expired content becomes eligible for scheduled deletion only after Hub confirms that no active recovery reference still owns the shared bytes; deletion is verified by checking that the R2 object is absent and is then recorded as a tombstone. An authorized install can also request deletion of its retained version or snapshot. A failed or incomplete deletion remains visible as unresolved storage state rather than being reported as complete.

Last updated on