Security

Our approach

PulsePanels is a multi-tenant cloud platform for managing digital signage, operated by Technoserve W.L.L., with an optional fully self-hosted deployment. We build security into the application, the infrastructure and our operational practices rather than treating it as an afterthought.

Encryption in transit and at rest

In transit

Traffic between your browser or screens and the PulsePanels dashboard and APIs is encrypted in transit using TLS (HTTPS). Public traffic is served through Cloudflare, which provides TLS termination, content delivery and protection against attacks.

At rest

• Sensitive secrets are encrypted at the application layer with AES-256-GCM before they are stored. This covers third-party integration tokens (such as calendar and Canva connections), webhook signing secrets, two-factor authentication secrets and live-stream credentials.
• Passwords are hashed with bcrypt and are never stored in plain text.
• API keys, connector tokens and trigger URL tokens are stored only as SHA-256 hashes, so the original value cannot be read back from our database.
• Off-site backups are stored in Cloudflare R2, which encrypts data at rest.

Authentication and access control

• Passwords must be at least 10 characters long and are checked against a list of common passwords.
• Two-factor authentication with an authenticator app (TOTP) is available to users, and an organisation can require it for all of its members.
• Single sign-on with SAML 2.0 can be configured for each organisation, so access follows your own identity provider and its policies. Users can also sign in with Google or Microsoft.
• Organisations can restrict sign-in to specific IP ranges, countries or email domains.
• Sessions use signed, HTTP-only cookies. A session ends after 24 hours of inactivity and at the latest 7 days after sign-in. Users can sign out of all their sessions at once, and all sessions are ended when a password is changed or reset.
• Repeated failed sign-ins are blocked: 10 failed password attempts for one account within 15 minutes lock password sign-in for that account for 15 minutes, and requests are also rate-limited per IP address.
• Role-based access control applies organisation and Space roles, including custom roles, so people get only the access they need.
• Programmatic access to the public API uses scoped API keys that can be limited to specific Spaces, IP addresses and an expiry date.
• Security-relevant actions — such as sign-ins and failed sign-ins, role changes, API key changes and webhook changes — are recorded in an audit log that organisation administrators can review.

Tenant isolation

PulsePanels uses a multi-tenant architecture in which each organisation's data is logically isolated and scoped by organisation and Space. Access-control checks enforce that users and devices can only reach data belonging to their own organisation. Physical or per-tenant database separation is not used in the standard cloud service; customers requiring stronger isolation can use the self-hosted / on-premise deployment.

Infrastructure security

• Our application servers and PostgreSQL database are hosted by Hetzner Online GmbH in Nuremberg, Germany (European Union). The Redis cache runs on the same infrastructure.
• All public web traffic passes through Cloudflare, which provides DNS, content delivery, a web application firewall and DDoS protection.
• The origin web server (nginx) only accepts web traffic from Cloudflare's published IP ranges. The database, cache and internal API ports are not reachable from the internet.
• The application sets HTTP security headers (via Helmet), including a strict Content Security Policy on the API.
• Inbound requests pass strict server-side input validation; unexpected fields are rejected.
• API rate limiting protects against abuse and runaway clients.
• Configuration and secrets are validated when the application starts; it refuses to start with an invalid or incomplete security configuration, and secrets are kept out of source control.

Logging and monitoring

Host monitoring checks disk and memory and emails our team when something needs attention, and a failed backup or restore test also sends an alert. Our scheduled background jobs record heartbeats that an internal operations dashboard flags when a job falls behind, and the service's health-check endpoint is checked on every deployment. Application activity is logged on our servers. We are adding an external uptime monitor that will alert us if the service becomes unreachable.

Backups

• The production database is backed up every day, and each backup is kept on the server for 14 days.
• Customer media is backed up every day, and each backup is kept on the server for 7 days.
• A copy of each daily backup is sent off-site to Cloudflare R2, which encrypts data at rest.
• An automated restore test regularly restores the latest off-site backup into a separate, temporary database to check that it is complete and usable.
• A failed backup or failed restore test triggers an alert.

Backups are taken once a day; we do not offer point-in-time recovery. How long backups are kept is also described in the Data Retention statement.

Secure software development

• All code is version-controlled on GitHub, and changes are made through pull requests.
• Every pull request runs automated checks — a full build, type checks and an automated regression test suite — which must pass before the change can be merged.
• Releases are deployed with scripted, repeatable deployments that include health checks and a quick rollback path. We avoid ad-hoc changes directly on production.

Vulnerability management

We review third-party dependencies for known vulnerabilities using npm audit and update them when issues are found. We carry out periodic internal security reviews of the platform; several were completed during 2026, and the issues they found were fixed. We are working on adding automated dependency scanning.

We have not yet commissioned an independent penetration test. We welcome reports from the security community — see our Vulnerability Disclosure page.

Incident response

We follow an internal procedure to identify, contain and fix security incidents. If we confirm a personal-data breach affecting a customer's data, we will notify the affected customer without undue delay and, where feasible, within 72 hours of confirming it, with the information reasonably available to help them meet their own obligations.

Staff access

Access to production systems and customer data is limited to a small number of authorised staff who need it to run and support the service. Production servers are administered over SSH using key-based authentication only. Two-factor authentication is required for PulsePanels platform administrator accounts signing in with a password.

Third-party providers

We rely on a small set of established service providers to deliver the service. Our current subprocessors, what they do and where they operate are listed on the Subprocessors page.

Data deletion

Customers can delete their content at any time. When an account is closed, customer data is deleted within 90 days, as described in the Data Processing Agreement and the Data Retention statement. Deleted data can remain in backups until they expire on their regular rotation.

Data residency and self-hosting

The PulsePanels cloud service is hosted by Hetzner Online GmbH in Germany (European Union). Some service providers process data in other countries; see the Subprocessors page. PulsePanels is also available as a fully self-hosted / on-premise deployment, so organisations with data-residency or in-country requirements can run it entirely within their own network.

Compliance

Security contact

To report a security concern, email security@pulsepanels.com. For responsible disclosure of a vulnerability, follow the process on our Vulnerability Disclosure page.