Skip to main content

Security measures

Last updated: August 9, 2026

This page describes the technical and organisational measures ("TOMs") that SolidPing applies to the hosted service under Article 32 GDPR. It is the authoritative version of Annex II of our DPA.

We may improve these measures over time. We will not reduce the overall level of protection while a Data Processing Agreement is in force.

Encryption​

In transit. All connections to the dashboard, the API, and between our own components use TLS 1.2 or above. HTTP is redirected to HTTPS. Check agents open outbound-only authenticated WebSocket connections to the API — there is no inbound port on an agent and no path from an agent to the database.

At rest. Databases, backups, and object storage are encrypted at the storage layer by our infrastructure provider.

Application-layer encryption. Some data is encrypted a second time, inside the application, so that a copy of the database alone does not yield usable secrets:

  • OAuth tokens for connected platforms (Slack, Discord, Microsoft Teams, and similar);
  • third-party integration credentials you enter, such as Twilio account credentials, webhook secrets, and API keys;
  • TOTP secrets and recovery codes.

The master key lives outside the database, in the deployment's secret store.

Passwords. Passwords are hashed with Argon2id by default (bcrypt is a configurable alternative). Hashes are transparently upgraded on login when the cost policy changes. Plaintext passwords are never stored or logged.

Authentication and access control​

For your users. SolidPing supports password sign-in with optional TOTP two-factor authentication and WebAuthn/passkeys, plus single sign-on through Slack, Discord, Google, GitHub, GitLab, Microsoft, generic OIDC, and LDAP. Sessions use short-lived access tokens with refresh tokens bounded by both a sliding idle window and an optional absolute maximum session duration you can configure.

Access inside an organisation is role-based: every user's permissions are scoped to the organisation and role they hold.

For our staff. Production access is limited to a small number of named individuals, granted on a least-privilege basis, protected by multi-factor authentication, and reviewed periodically. Everyone with access is bound by a confidentiality obligation. Administrative actions are recorded in audit logs.

Tenant isolation​

Every record that belongs to a customer carries an organisation identifier, and isolation is enforced in the data-access layer rather than being left to individual queries. Check agents are enrolled with signed, per-agent credentials, and a claim for work is validated against the region and organisation the agent is authorised for.

Changes touching authentication, credential handling, or tenant isolation get an explicit security review before they ship.

Availability and resilience​

  • The Service runs on a Kubernetes cluster that restarts and reschedules unhealthy workloads automatically.
  • Daily automated database backups, encrypted, written to object storage in France (OVHcloud, Gravelines) separately from the database host.
  • A documented restore procedure.
  • Infrastructure defined as code, so an environment can be rebuilt from a known state.
  • SolidPing monitors itself from check workers hosted with different providers in different countries, so a single provider's outage cannot take down both the Service and the monitoring of it.

Secure development​

  • All changes go through code review before merging.
  • Automated tests, linting, and static analysis run on every change in CI.
  • Automated dependency and vulnerability scanning, with prompt patching of security advisories.
  • Secrets are never committed to the repository; CI enforces this.
  • The core software is open source, so its security properties can be inspected independently rather than taken on trust: github.com/fclairamb/solidping.

Data minimisation​

Security is easier when there is less to protect. Concretely:

  • We do not read or store the content of your Slack or Discord channel messages, and we do not enumerate your workspace member directory.
  • We do not access files in your chat workspaces.
  • Product analytics use a pseudonymous identifier derived from organisation and user IDs. The analytics client is structurally incapable of carrying an email address, a check target, or any customer free text, and the set of events it can emit is a small closed list.
  • Special-category data (Article 9 GDPR) is never requested and never required.

Incident response​

We maintain an incident response process covering detection, containment, eradication, recovery, and post-incident review.

For a personal data breach affecting customer data, we notify affected customers without undue delay and in any event within 48 hours of becoming aware of it, so that customers — as controllers — can meet their own 72-hour obligation under Article 33 GDPR. The notification covers the nature of the breach, the categories and approximate volume of data and data subjects concerned, likely consequences, measures taken, and a contact point. Where the full picture is not immediately available, we provide information in phases.

Where SolidPing acts as controller in its own right, we notify the CNIL within 72 hours and affected individuals where Article 34 requires it.

Reporting a vulnerability​

If you believe you have found a security vulnerability, email contact@solidping.io with enough detail to reproduce it. Please give us a reasonable opportunity to fix the issue before public disclosure. We will acknowledge your report, keep you informed, and credit you if you would like to be credited. We will not pursue legal action against good-faith security research that respects user privacy and does not degrade the service.

Certifications​

SolidPing does not currently hold ISO 27001 or SOC 2 certification. We do not claim compliance we have not been audited against. The measures above are what we actually do, and we are happy to answer specific questions in a vendor security review — email contact@solidping.io.

Self-hosted deployments​

If you run SolidPing yourself, the security of your deployment is yours to manage. The software gives you the building blocks — application-layer credential encryption, Argon2id password hashing, TOTP and WebAuthn, role-based access control, audit logging, agent enrolment signing — but configuring them, patching, backing up, and securing the host are your responsibility. See Self-hosting & GDPR.