Wellness HR
PrivacySecurityTerms

Legal & trust

Security Statement

Effective and last updated: 15 August 2026

Wellness HR is designed to protect sensitive workforce information through layered technical and organisational safeguards. This statement explains our current security approach without disclosing details that could weaken it.

At a glance

  • Encrypted HTTPS connections and restrictive browser security headers protect data in transit.
  • Tenant isolation and role-based access controls limit access within the HR platform.
  • Production files are designed to remain private and are accessed through authorised application routes.
  • Security concerns can be reported confidentially to info.wellnesshrm@gmail.com.

On this page

1. Scope and security principles2. Identity, access, and tenant separation3. Application and network safeguards4. Data protection5. Secure operations and resilience6. Customer responsibilities7. Incident management8. Responsible vulnerability reporting9. Assurance and questions

1. Scope and security principles

This statement covers the public Wellness HR website and the hosted Wellness HR application. We apply controls based on data sensitivity, user role, system risk, and the shared responsibilities in each customer agreement.

Our approach is based on defence in depth, least privilege, tenant separation, secure defaults, data minimisation, controlled change, and recoverability. This page is a summary, not a certification, audit report, warranty, or complete list of controls.

2. Identity, access, and tenant separation

  • Authenticated platform access with server-enforced authorisation checks.
  • Role, module, and action permissions that customers can configure for employees, managers, HR teams, and administrators.
  • Tenant-aware routing and data access designed to keep each customer workspace separated.
  • Secure, HTTP-only refresh cookies for persistent browser sessions over HTTPS.
  • Audit-oriented workflow records for sensitive administrative and employee actions.

3. Application and network safeguards

  • TLS is required for production websites, applications, and API traffic.
  • Content Security Policy, HSTS, anti-framing, MIME-sniffing prevention, referrer, and browser permission headers are applied at the web edge.
  • Origin allowlisting, request validation, bounded input lengths, API no-store caching, and policy-based rate limiting reduce common web risks.
  • File-upload boundaries validate size and permitted content types before application processing.
  • Production configuration checks are designed to fail deployment when critical security settings are unsafe or missing.

4. Data protection

  • Production documents and images are designed for private object storage; direct public bucket access is denied and application access is authenticated.
  • Short-lived signed access can be used for authorised file delivery.
  • Stored third-party access-control credentials are protected with versioned AES-256-GCM encryption and keys kept outside tenant databases.
  • Secrets and cloud credentials are expected to be supplied through protected runtime configuration, not client code or source control.
  • Data returned by HR and authentication APIs is marked not to be cached by shared or browser caches.

5. Secure operations and resilience

  • Automated tests cover security headers, session handling, tenant guards, authorisation policy, uploads, and sensitive credential handling.
  • Deployment checks validate configuration, migrations, storage access, and HTTPS behavior before or during release.
  • Database backup, tenant restore, controlled migration, rollback, and object-version retention procedures support recovery.
  • Operational logging supports diagnosis and investigation, with access intended for authorised personnel.
  • Security fixes and dependencies are reviewed as part of ongoing product maintenance.

6. Customer responsibilities

Security is shared. Customers should:

  • assign only the permissions each user needs and promptly remove departed users;
  • use unique, strong credentials and protect administrator accounts and connected devices;
  • configure lawful retention, workforce notices, integrations, email, and attendance devices;
  • keep endpoints and browsers supported and secure; and
  • report suspected compromise promptly and preserve relevant evidence.

7. Incident management

We investigate suspected security events, work to contain and remediate confirmed incidents, and notify affected customers or authorities when required by applicable law or contract. Customers remain responsible for notifying their workforce or other individuals where they are the controller, with our reasonable assistance as agreed.

8. Responsible vulnerability reporting

Report a suspected vulnerability to info.wellnesshrm@gmail.com with the affected URL or component, steps to reproduce, potential impact, and a safe proof of concept. Do not include personal data, credentials, or confidential customer information unless requested through an approved secure channel.

Please avoid privacy violations, service disruption, social engineering, destructive testing, automated high-volume scanning, or accessing data beyond what is necessary to demonstrate the issue. Allow us a reasonable opportunity to investigate before public disclosure. This channel does not create a bug bounty or authorise activity that would otherwise be unlawful.

9. Assurance and questions

Specific controls can depend on deployment, customer configuration, and service plan. Customers evaluating Wellness HR may request relevant security and data protection information through their sales or account contact. Confidential technical details may require a non-disclosure agreement.

General security questions may be sent to info.wellnesshrm@gmail.com. Privacy matters are governed by our Privacy Policy.

These public documents are designed to be read together.

PrivacySecurityTerms