GDPR compliance

Last updated: May 2026

1. Why this page exists

Most "GDPR compliance" pages are vague marketing copy. This one tries to be the opposite: every claim below corresponds to a real control in the running product or a real operational practice we'll defend in writing. Where a control isn't yet shipped, we say so plainly.

Tesla Tech, the company behind StatusPulse, is registered in Portugal. The supervisory authority for Tesla Tech is the Comissão Nacional de Proteção de Dados (CNPD). EU residents can also complain to their local data protection authority.

2. Roles — controller and processor

GDPR splits the world into controllers (who decide what to do with personal data) and processors (who act on the controller's instructions). StatusPulse operates in both roles depending on the data:

For data where we are the processor, a Data Processing Agreement (DPA) is available on request — see section 12.

3. Lawful bases (Art. 6)

Every processing activity is anchored to one of the six Article 6 bases. The full list is in the privacy policy; the short version per surface:

• Running probes, sending alerts, hosting status pages: Art. 6(1)(b) — performance of contract with the account holder.
• Billing, invoicing, tax records: Art. 6(1)(b) and 6(1)(c) — contract + legal obligation (Portuguese tax law: 10-year retention for invoices).
• Rate limiting, abuse prevention, error logs: Art. 6(1)(f) — legitimate interest in keeping the service available and secure for everyone.
• Waitlist sign-up emails: Art. 6(1)(a) — explicit consent, withdrawable any time via the unsubscribe link.
• Anomaly forecasting model: Art. 6(1)(f) — legitimate interest in improving uptime predictions; data minimised so no individual customer's URLs are recoverable from the model (see section 7).

We do not rely on consent for anything that is essential to providing the service — that keeps the consent withdrawal right meaningful (you can refuse marketing emails without breaking your account).

4. Data minimisation (Art. 5(1)(c)) — concrete examples

Article 5(1)(c) requires that personal data be "adequate, relevant and limited to what is necessary." We enforce this in code, not just in policy:

• Waitlist IPs are hashed at the edge. The raw IP is read once for rate-limiting, then converted to a SHA-256 digest with a per-deployment salt before any database write. The salted hash is irreversible without the salt and the salt never leaves Key Vault.
• Rate-limit partition uses the TCP socket IP, not the X-Forwarded-For header. The socket IP stays in request-scope memory for the duration of the request and is never persisted; the header would be spoofable and was deliberately not trusted.
• Application error logs are sanitised before write. Stripe identifiers (cus_, sub_, pi_, etc.), Stripe secret keys (sk_live_, whsec_), and email addresses are stripped from the message column. If the userId on an error row looks like an email, it is replaced with a 12-character SHA-256 prefix prefixed by email:. Raw stack traces are reduced to an 8-character hash for de-duplication; the full trace flows only to Application Insights, where access is gated to the operator role.
• Anomaly detection never sees hostnames or request bodies. Probe targets enter the cross-tenant training set as a SHA-256 hash truncated to 12 characters, and only when at least five distinct probes share that hash. Single-probe hashes are suppressed so an individual customer URL cannot be fingerprinted from the feature space. The model learns time-of-day seasonality and latency drift patterns — not your URLs, not your content.
• Probe credentials are encrypted at rest with AES-GCM. SMTP passwords, IMAP/POP3 passwords, database passwords, WebSocket auth headers, gRPC mTLS client certificates, and gRPC auth headers are stored in the format v1.{nonce}.{tag}.{ciphertext} using a 256-bit master key resolved from Azure Key Vault at process start. The plaintext is held only in memory during a probe execution.

5. Encryption (Art. 32(1)(a)) — at rest and in transit

5.1 In transit

• HTTPS everywhere with HSTS (Strict-Transport-Security with includeSubDomains and preload). The marketing site, dashboard, public status pages, and custom-domain status pages all redirect HTTP → HTTPS at the edge.
• TLS terminated by Azure Front Door / App Service with Azure-managed certificates; minimum protocol pinned to TLS 1.2.
• Outbound probe traffic to your endpoints uses the protocol you configured (HTTP/HTTPS, TCP, ICMP, DNS, IMAP-SSL, POP3-SSL, SMTP-STARTTLS, MySQL/PG/SQL Server/Redis with TLS, WebSocket Secure, gRPC over HTTP/2 or HTTP/3).
• For database probes, a TLS misconfiguration on the target produces a down status with the TLS error preserved — we never silently downgrade.

5.2 At rest

• The Azure SQL database backing StatusPulse uses Transparent Data Encryption (TDE) with platform-managed keys.
• Azure Blob Storage (used for generated PDF reports) uses server-side encryption with platform-managed keys.
• Azure Key Vault holds the AES-GCM master key for the application-layer encryption described in section 4. The master key is read once at process start by the App Service and Function App managed identities (no human user has Key Vault Secrets User on the production vault).
• The encrypted-string format includes a version tag (v1) so we can rotate the master key in future without having to schema-migrate every row.

6. Multi-region hosting and international transfers (Chapter V)

StatusPulse infrastructure runs in two regions — US and EU. Each tenant is provisioned in the region that matches its data-residency needs, and the data for that tenant stays in that region. Specifically:

• Azure resources (App Service, Functions, Azure SQL, Azure Communication Services, Storage, Key Vault, Application Insights) are provisioned in either EU regions (North Europe / West Europe) or US regions (East US / West US), depending on the tenant's chosen region.
• Microsoft Entra External ID directory is configured per region.
• Azure SQL backups are geo-redundant within the tenant's chosen region only — no cross-region replication is enabled, and EU-region tenants never have their backups replicated outside the EEA.

Where a transfer outside the EEA is unavoidable, we rely on:

• Stripe (payment processing): Stripe's intra-group transfers are governed by the EU Standard Contractual Clauses; Stripe maintains an EU data residency option and we use it.
• Anthropic / Claude API (used by the optional AI incident drafter and the AI executive summary in PDF reports): inference happens on US infrastructure. We disclose this here and in the in-app feature copy. Opt-out is permanent and granular: do not enable AI assistance on a probe / status page / report and no data leaves the EU through this channel. AI output is also not the source of truth — every AI-drafted update is editable and requires a human click to publish.
• Microsoft Azure platform support: Microsoft staff outside the EU may exceptionally access platform diagnostics under the Microsoft Online Services Data Protection Addendum, which incorporates the SCCs.

We do not use US-only sub-processors for any non-AI core processing. The list in section 8 below is exhaustive.

7. Automated decision-making and profiling (Art. 22)

StatusPulse does not make decisions that produce legal or similarly significant effects on a person without human involvement. Specifically:

• The anomaly forecast is informational. It writes a probability score back to your own probe row and may surface an anomaly badge in the dashboard. It does not pause monitors, charge money, or contact recipients on its own. The decision to act on the prediction stays with you.
• The AI incident drafter proposes wording for an incident update. The wording is editable and never publishes without a human click.
• The AI executive summary in PDF reports describes patterns in your data. It does not feed back into any automated control.
• Hard opt-out toggles (EmailsBlocked, SmsBlocked on a Person) are checked by the dispatcher before every send and override every other rule, including escalations.

8. Sub-processors (Art. 28(2))

Each sub-processor we use, the data they touch, and the lawful basis for the transfer:

We will give existing customers 30 days' advance notice by email before adding a sub-processor that touches personal data, with an opportunity to object before the change takes effect.

9. Data subject rights (Art. 12–22) — how to exercise each one

For Persons and status page subscribers (where you are the controller), each notification we send carries an unsubscribe token that lands on a public unsubscribe page; one click hard-blocks future sends and is recorded as EmailsBlocked / SmsBlocked on the recipient. Subsequent attempts to email or SMS that recipient short-circuit at the dispatcher before the message is built.

10. Retention (Art. 5(1)(e))

11. Breach notification (Art. 33 / 34)

If we become aware of a personal data breach likely to result in a risk to the rights and freedoms of natural persons, we will:

• Notify the Comissão Nacional de Proteção de Dados (CNPD) within 72 hours of becoming aware (Art. 33(1)).
• Notify affected account holders by email without undue delay where the breach is likely to result in high risk (Art. 34(1)).
• Document the breach in our internal incident log regardless of severity (Art. 33(5)).

For account holders acting as controllers (Persons, status page subscribers, probe configuration), we will notify you as the affected controller without undue delay (Art. 33(2)) and provide enough information for you to fulfil your own Article 33 / 34 obligations.

12. Data Processing Agreement (Art. 28(3))

For customers who need a signed DPA — typically B2B accounts processing personal data of their own end-users through StatusPulse — we provide a DPA on request. Email privacy@statuspulse.ai with your tenant identifier and the DPA will be sent within two business days. Once signed, it forms part of the terms of service.

The DPA covers Article 28(3) requirements: subject matter, duration, nature and purpose, type of personal data, categories of data subjects, controller and processor obligations, sub-processor authorisation (with the list in section 8 above), security measures, audit rights, and return / deletion at end of processing.

13. Records of processing activities (Art. 30) and DPIA (Art. 35)

We maintain an internal Record of Processing Activities (ROPA) covering each processing purpose, the legal basis, the data categories, the recipients, the retention period, and the security measures. The ROPA is available to supervisory authorities on request and in summary form to customers under a signed DPA.

StatusPulse does not currently perform any processing that triggers a mandatory Data Protection Impact Assessment under Article 35: we do not engage in large-scale systematic monitoring of publicly accessible areas, we do not process special-category data (Art. 9), we do not profile individuals to make decisions about them, and our scale is below the CNPD's published DPIA thresholds. We will revisit this if any of those facts change.

14. Children (Art. 8)

StatusPulse is a B2B service for engineers and operators. It is not intended for, and should not be used by, individuals under 16. We do not knowingly collect personal data from children. If we learn that we have, we will delete the data promptly. Please contact privacy@statuspulse.ai if you believe a child has used the service.

15. Cookies and trackers

We deliberately keep the cookie surface small and use only first-party essential cookies — no third-party advertising, no cross-site tracking, no remarketing pixels. Specifically:

• Authentication cookie — Secure, HttpOnly, SameSite=Lax; required for the dashboard. Essential, no consent needed.
• Antiforgery token — Secure, set per request to defend against CSRF on form submissions. Essential.
• Theme preference — first-party cookie remembering your light/dark choice; Secure, SameSite=Lax, 1-year expiry. Essential to UX continuity, not used for tracking.

If we ever introduce non-essential analytics (we have not) we will use a privacy-respecting tool such as Plausible or Fathom, in aggregate-only mode, and will display a consent banner before any cookie is set.

16. Security controls referenced in this page

The technical controls supporting the above (TLS configuration, encryption format, key management, audit logging, network controls) are described in the security posture. Recent independent reviews:

• Code-level security audit, April 2026 — 20 findings, all closed.
• Code-level security audit follow-up, May 2026 — 28 findings, 26 closed and 2 risk-accepted with documented compensating controls.

17. Complaints

If you believe we have mishandled your personal data, please contact us first at privacy@statuspulse.ai — we'd rather fix it than have you escalate. You also have the right at any time to complain to:

• Comissão Nacional de Proteção de Dados (CNPD), Lisbon — supervisory authority for Tesla Tech: cnpd.pt.
• The supervisory authority of the EU member state where you live, work, or where the alleged infringement took place.

18. Contact

For anything on this page, data subject requests, or DPA requests: privacy@statuspulse.ai.

For billing or account issues: support@statuspulse.ai.

See also: Privacy policy · Terms of service · Security posture.