Security and data handling

1. What leaves your server

Activity signals, not raw content. Each integration emits a small, allowlisted set of structured events about what is happening — authentication attempts, scheduled work, outbound mail, errors, configuration changes, request shape. The shape of the activity travels; the content does not.

Specifically: no request bodies, no response bodies, no form contents, no comment text, no post bodies, no session data, no email addresses, no email message bodies. Usernames travel as one-way hashes with length, not in cleartext. Sensitive configuration values travel as hashes of their before-and-after, not as values. File-edit signals carry size deltas and a few high-signal heuristics, never the file. Each signal type is individually toggleable from the integration's admin UI — the operator on your end owns the trust boundary, not us.

The test we apply to every signal type when designing it: can we describe what happened on the site without describing what the user said? If yes, the signal ships. If no, it doesn't.

2. Where the data lives

The hosted service runs in the European Union. All of it — ingestion, processing, storage, the dashboard, the alerting layer. There is no replica or backup region outside the EU. If your data residency requirements rule out EU hosting entirely, the hosted service is not the right fit and self-hosting is the path; see Self-hosting below.

Encryption is in place both for data in transit and for data at rest. We don't consider that a feature worth a checkbox — it's table stakes, and not naming it would be louder than naming it.

3. Who can read what

Inside your tenant. Access is per-tenant by design. Your users see your sites; users from other tenants do not. Roles inside a tenant control who can view alerts, change rule configurations, and manage integrations. Where possible we recommend single sign-on for production tenants; it is supported on the enterprise plan.

Inside our team. Production data is read by a small number of named operators when investigating a specific support issue or incident, and only then. Access is logged. We don't bulk-read customer data; we don't train internal models on it; we don't ship it to third parties for analytics or enrichment.

Inside the report product. A subset of the Logystera team that generates weekly reports reads aggregated signal data for the entities those reports cover. Reports are AI-assisted with human review; the AI sees aggregated metrics and signal patterns, not the underlying individual events. If your contract requires that no human at Logystera ever read your data, the report product is not for you and the monitoring product alone is the right scope.

4. How long we keep it

Time-series data — the metrics derived from your signals — is retained for the window appropriate to your plan, typically 7 days on the free tier, 30 days on the standard plan, and 90 days or more on enterprise. Individual signals (the raw activity events) are retained for a shorter window, because the metrics derived from them are what powers the product. Retention is configurable on enterprise.

When you cancel, signal and metric data is deleted within 30 days. Configuration data (rule definitions, integration settings) is deleted with the account. We do not retain a "shadow copy" of anything; cancellation is real.

5. Authentication, in plain terms

Every batch of signals from your integration to our gateway is cryptographically signed using a secret unique to that site. The gateway verifies the signature on every batch and refuses anything it can't authenticate. Replay protection is in place. Site-specific secrets can be rotated without affecting other sites. We have not seen, and we do not store, your WordPress or Drupal admin credentials at any point in this chain — those never enter the integration.

For the customer-facing dashboard, authentication is session-based. Single sign-on against your organization's identity provider is available on the enterprise plan.

6. Self-hosting

Self-hosting is available for organizations whose data-handling requirements the hosted service cannot fully meet — typically government, healthcare, or specific national-data-residency requirements. It is offered through a contracted arrangement, not as a self-serve download. It is real and used in production by such customers today; it is also operationally non-trivial for both sides, so we don't pretend otherwise. If your situation makes self-hosting necessary, that's a conversation worth having early in the evaluation.

7. What we do not have, today

We don't have SOC 2 attestation today. We don't have ISO 27001 today. We have the operational practices that would support such audits, and we are intentional about not having a logo we haven't earned. If your procurement requires the logo, that's information we want early.

We don't have HIPAA-covered status. We don't have FedRAMP authorization. If you require either, the conversation is about whether self-hosting in your environment satisfies the requirement; the hosted service does not.

8. Responsible disclosure

If you believe you've found a security vulnerability in Logystera, the WordPress plugin, or the Drupal module, email security@logystera.com. We respond within two business days and work with reporters on disclosure timing. There is no formal bug bounty today, but we credit reporters with their consent and we are direct about timelines.

9. What this page does not cover

Legal terms of service are in /terms. Privacy specifics are in /privacy. The operational mechanics of how detections work are in /architecture. If you have a question about something here that isn't answered, write to us and we'll either answer it directly or, more usefully, add a section to this page. Several of the sections above exist because a customer asked.