Security & Trust Centre

This page is maintained by Nightingale Software Group to answer common security and privacy questions about the Nightingale platform. It describes controls we operate today; it is not an independent certification or audit report.

Version 1 · effective 2026-07-30

This page is maintained by Nightingale Software Group to answer common security and privacy questions about the Nightingale platform. It describes the controls we operate today. It is not an independent audit or certification.

Security is a shared responsibility: we secure the platform, and customers are responsible for how they configure access, who they grant it to, and what data they put in.

Identity and authentication

The Nightingale Admin Centre is the single identity provider for the entire ecosystem. Individual applications do not hold their own credentials and do not run their own sign-in.

  • Sign-in supports email and password and federated single sign-on.
  • Passwords are stored only as salted hashes; we never hold them in readable form.
  • Applications authenticate users through OAuth 2.1 / OpenID Connect with PKCE.
  • Refresh tokens are rotated on use, and a reused token revokes the whole token family.
  • Sessions can be listed and revoked centrally, and revocation propagates to connected applications.
  • Where an application uses PIN-based sign-in for shift workers, PINs are stored only as hashes and verified server-side.

Role-based access control

Permissions are assigned by role, not by individual. Roles are stored separately from user profiles so that a user cannot alter their own privileges, and every permission check is evaluated server-side.

Administrative roles are scoped to a single organisation. Platform-level administration is held by a deliberately small number of accounts.

Tenant isolation

Every customer organisation is a distinct tenant. Isolation is enforced in the database itself through row-level security, so a query issued on behalf of one organisation cannot return another organisation's rows — regardless of what the application layer asks for.

Write operations are additionally guarded so that records cannot be created or moved across organisation boundaries, and attempts are recorded as security violations.

Encryption

Data is encrypted in transit using TLS across all public endpoints and internal service calls. Data at rest is encrypted by the underlying managed storage platform. Application secrets, signing keys and provider credentials are held in an encrypted secret store, not in source code.

Audit logging

Significant actions — permission changes, subscription and entitlement changes, administrative access, impersonation, document publication and configuration changes — are written to an append-only audit log that cannot be edited or deleted, including by administrators.

Organisation administrators can review the audit trail for their own organisation. Support access to a customer organisation is time-limited, explicitly granted, visibly banner-flagged while active, and recorded.

Backup and recovery

The platform database is backed up continuously with point-in-time recovery on the managed database platform. Backups are encrypted and retained in line with our recovery objectives.

Disaster recovery

Our recovery approach relies on managed, redundant infrastructure and point-in-time database restoration. Recovery procedures are documented and reviewed. Specific recovery time and recovery point objectives are available to Enterprise customers on request.

Infrastructure

Nightingale runs on managed cloud infrastructure with a globally distributed application edge and a managed PostgreSQL database. Primary data storage is in the United Kingdom or European Union. There are no self-managed servers to patch, and infrastructure is provisioned through code rather than manual configuration.

The full list of providers is on our subprocessors page.

Security practices

  • Access to production systems is limited to named individuals and individually attributed.
  • Changes go through review before release.
  • Dependencies are monitored for known vulnerabilities and updated.
  • Automated security scanning runs against the platform, and findings are triaged and tracked to resolution.
  • Public API endpoints require signed authentication, verify request signatures, and are rate limited.

Responsible disclosure

We welcome reports from security researchers.

  • Email security@nightingalesoftware.co.uk with enough detail to reproduce the issue.
  • Please give us a reasonable opportunity to investigate and remediate before any public disclosure.
  • Please do not access, modify or delete data belonging to others, degrade the service, or run automated scanning that affects availability.
  • We will acknowledge your report, keep you updated on progress, and credit you if you would like us to.

We will not pursue legal action against researchers who act in good faith and follow this process.

Contact

Security enquiries and disclosure: security@nightingalesoftware.co.uk Data protection enquiries: privacy@nightingalesoftware.co.uk