Enterprise Security Whitepaper

Plus Ultra Innovations Pty Ltd
ABN: 23 686 310 850
Wellbeing Dashboard Platform

Version: 1.9
Last Updated: 2 October 2026

Changelog

2 Oct 2026 (v1.9): removed statements the platform does not support: "end-to-end encryption" (the server decrypts; the highlight now says in transit and at rest), the password requirements (invitation and join-code sign-up enforce no complexity rule), every SOC 2 Type II statement — the two providers' "certified" lines, the attestation in Section 7.1 and the Platform target in Section 7.2 — none established for this document, and the ISO 27001 target, with Section 7.2 and "Certifications" in the Section 7 title.
1 Oct 2026 (v1.8): Section 3.1: the emailed sign-in link now asks for the second factor from anyone who must use one.
1 Oct 2026 (v1.7): removed five statements that had not been established: a 24-hour session timeout and a limit of five devices, background checks for all staff, a default rate limit of 100 requests per minute, IP allowlisting, and "SOC 2 Type II compliant infrastructure". The header date is now labelled "Last Updated".
30 Sep 2026 (v1.6): removed certificate pinning, key management in a hardware security module, automatic key rotation, single sign-on (SAML/OIDC), SMS and security-key second factors, Anthropic and AI processing, and the Singapore data-residency option, none of which the platform does. HSTS stated as the platform sends it. Second-factor sign-in stated as enforced. Section 7 no longer states compliance with any law. Section 10 points to the Service providers page.
25 Sep 2026 (v1.5): the security team and vulnerability-report contacts (Section 12) are now privacy@plusultrainnovations.com.
25 Sep 2026: the privacy contact email is now privacy@plusultrainnovations.com (Section 12).
22 Sep 2026: removed statements that had not been established (data processing agreements, Data Protection Officer).
18 August 2026: v1.2.
Classification: External - Client Distribution

Executive Summary

Plus Ultra Innovations has built the Wellbeing Dashboard Platform with security as a foundational principle. This whitepaper details our comprehensive security architecture, controls, and practices designed to protect sensitive employee wellbeing data.

Key Security Highlights:

Encryption in transit and at rest (TLS 1.3, AES-256)
Role-based access control; a second sign-in factor for administrators and team leaders, enforced by the database
Privacy thresholds preventing individual identification
Data held in Sydney, Australia
Continuous provider-level availability and error monitoring
Automated dependency vulnerability scanning

1. Security Architecture

1.1 Infrastructure Overview

Our platform uses a multi-layered security architecture:

Client Layer — Browser connections secured with TLS 1.3 encryption.

CDN/WAF Layer — Vercel Edge Network with DDoS protection.

Application Layer — Next.js on Vercel Serverless with input validation, authentication, and authorization.

Database Layer — Supabase PostgreSQL with AES-256 encryption at rest, row-level security policies, and automated backups.

1.2 Technology Stack Security

Frontend (Next.js) — CSP, XSS protection, CSRF tokens.

Backend (Next.js API Routes) — Input validation, rate limiting.

Database (Supabase PostgreSQL) — RLS, encryption, audit logs.

Authentication (Supabase Auth): a second sign-in factor (authenticator app), secure session management.

Hosting (Vercel) — DDoS protection, edge security.

Email (Resend) — SPF, DKIM, DMARC.

2. Data Protection

2.1 Encryption

In Transit:

TLS 1.3 for all connections
HSTS enabled (max-age 63072000, including subdomains, preload)
Perfect Forward Secrecy (PFS)

At Rest:

AES-256 encryption for all data
Encrypted backups

2.2 Data Classification

Confidential — Survey responses, health scores. Controls: Encrypted, access-logged, privacy thresholds.

Internal — Aggregated analytics, configs. Controls: Encrypted, role-based access.

Public — Marketing content, docs. Controls: Standard web security.

2.3 Privacy Thresholds

To prevent individual identification in aggregate reports:

Every jurisdiction, including Australia and Singapore: a minimum group of 10 people. The threshold is fixed and enforced in the database, counted as distinct people rather than responses. It is never lowered, never configurable, and has no jurisdiction exception.

Groups below the threshold receive a privacy notice in place of metrics. That notice is distinct from the "data unavailable" state shown when a read fails: a group that is too small and a report that could not be produced are never presented the same way.

3. Access Control

3.1 Authentication

Methods Supported:

Email and password. Administrators and team leaders must use a second factor at password sign-in, enforced by the database since 30 September 2026; an organisation can require the same of its workers
Emailed sign-in link (passwordless). Anyone who must use a second factor is asked for it before their dashboard opens

Password Protections:

Breach database checking
Account lockout (5 failed attempts)

Second factor:

Authenticator apps (TOTP)

3.2 Authorization

Role-Based Access Control (RBAC):

Employee — Own data only, personal dashboard.

Team Lead — Own data plus aggregated team metrics.

Admin — Organisation-wide aggregated data, user management.

Platform Admin — System configuration, support access.

Row-Level Security Example:

-- Users can only access their own survey data
CREATE POLICY user_surveys ON wellbeing_surveys
    FOR ALL
    USING (user_id = auth.uid());

3.3 Session Management

Session revocation on password change
Secure cookie attributes (HttpOnly, Secure, SameSite)

4. Application Security

4.1 Secure Development Lifecycle

Design — Threat modelling, security requirements.

Development — Secure coding standards, code review.

Testing — SAST, DAST, dependency scanning.

Deployment — Security gates, automated checks.

Operations — Monitoring, vulnerability management.

4.2 Input Validation

All user input is validated:

Server-side validation (never trust client)
Schema validation (Zod)
Parameterised queries (SQL injection prevention)
Output encoding (XSS prevention)

4.3 API Security

API key authentication for integrations
Request signing for webhooks
CORS restrictions
Input size limits

4.4 Dependency Management

Automated vulnerability scanning (Dependabot)
Weekly dependency updates
Critical vulnerabilities patched within 24 hours
SBOM (Software Bill of Materials) maintained

5. Infrastructure Security

5.1 Cloud Security

Vercel (Application Hosting):

Automated deployments with rollback
Edge network with DDoS protection
Isolated serverless functions

Supabase (Database):

Dedicated PostgreSQL instances
Automated backups (daily)
Point-in-time recovery

5.2 Network Security

Web Application Firewall (WAF)
DDoS mitigation
Network segmentation

5.3 Logging & Monitoring

Audit trails. All administrative actions and all mutations of the WHS risk register are recorded in an append-only audit trail, attributed to the acting user and written in the same database transaction as the action itself. Register records cannot be updated or deleted. The WHS audit trail is retained for the life of the organisation's engagement and is not automatically purged.

Data retention. Identifiable data is retained for the duration of the engagement. On termination an export is provided and identifiable data is verifiably deleted within 90 days. De-identified, floor-suppressed aggregates (n≥10) are retained for benchmarking and product improvement, as disclosed in the collection notice. Raw sensitive free-text carries shorter windows: safety-flag text is deleted after 90 days, feedback comments after 12 months, enforced by a daily automated process.

Security and authentication records. Sign-in attempts, platform-administrator sessions and application security events are recorded in the database. They are not automatically purged and follow the engagement-lifetime retention above.

Infrastructure and application logs. Request and runtime logs are managed by the hosting provider and retained on the provider's schedule; Plus Ultra does not operate a separate application-log store.

Monitoring. Platform availability and runtime errors are monitored continuously by our hosting provider's built-in observability, which the founder reviews. Security events are recorded in a security events log readable only by platform administrators.

Response. We aim to acknowledge critical incidents within one business day and to communicate a plan within two. As a founder-led business we do not currently offer a 24/7 response commitment; where a client requires one, it can be negotiated as part of a pilot agreement.

6. Operational Security

6.1 Personnel Security

Security awareness training (annual)
Least privilege access
Immediate access revocation on termination

6.2 Vulnerability Management

Vulnerability management. Dependency vulnerabilities are monitored through automated weekly scanning, with updates raised automatically as pull requests and remediation prioritised by severity — critical issues are addressed first, ahead of feature work. As a founder-led business we do not publish fixed remediation windows; prioritisation by severity is the commitment we can honour.

Every change to the main branch must pass an automated build, type-check and lint gate before merging. Deeper static code scanning (CodeQL) is configured for on-demand runs and does not yet run automatically.

6.3 Penetration Testing

No third-party penetration test has been conducted to date; one can be arranged where a client requires it as a condition of engagement.

6.4 Incident Response

Incidents are handled by the founder, with acknowledgement targeted within one business day and a communicated plan within two (see Section 5.3)
Security events are recorded as they occur and reviewed on investigation
Post-incident review, with corrective actions tracked to closure

7. Privacy Law

7.1 Privacy law

Australian Privacy Act: the Platform is built to support an organisation's own privacy obligations; how we handle personal information is set out in our Privacy Policy. We make no statement of compliance on any organisation's behalf.

8. Data Residency

8.1 Where Data Is Held

Australia: database in Sydney (ap-southeast-2); the application's server functions run in Sydney.

8.2 Data Flow

Primary data stored in Sydney, Australia
Backups in the same region
CDN caches static assets globally (no PII)

9. Business Continuity

9.1 Availability

Target SLA: 99.9% uptime, delivered on managed serverless hosting and a managed database service

9.2 Backup & Recovery

Backups — the production database is backed up automatically each day, with the last 7 days of backups retained.

RPO (Recovery Point Objective) — up to 24 hours on the daily backup cycle. Point-in-time recovery is available as a paid add-on and can be enabled where a client's recovery objectives require it, reducing the window to minutes.

Recovery — restores follow a documented, step-by-step disaster-recovery runbook, including post-restore verification. We do not publish a fixed recovery-time commitment.

9.3 Disaster Recovery

Documented DR plan
Geographic redundancy can be arranged where a client requires it as a condition of engagement
Incident communication follows the response commitment in Section 5.3 — acknowledgement targeted within one business day and a communicated plan within two, direct from the founder. No separate formal communications plan document exists.

10. Third-Party Security

10.1 Vendor Assessment

Our service providers are listed publicly. We do not operate a separate formal vendor-assessment programme.

10.2 Current Service Providers

The current list, with what each provider handles and where, is on our Service providers page (https://app.plusultrainnovations.com/legal/subprocessors).

11. Customer Security Features

11.1 Available Controls

All Tiers (Lite, Professional, Max):

A second sign-in factor for administrators and team leaders, and optionally for workers

Professional and Max:

Full audit logs
Custom session timeout

Max Only:

Custom data retention

11.2 Security Recommendations

For optimal security, we recommend:

Require a second sign-in factor for workers as well (an organisation setting)
Review access logs regularly
Implement security awareness training
Configure appropriate session timeouts

12. Contact & Support

Security Team:
privacy@plusultrainnovations.com

Report a Vulnerability:
privacy@plusultrainnovations.com
(We aim to respond within 24 hours)

Privacy contact:
privacy@plusultrainnovations.com

This whitepaper reflects our security posture as of January 2026. For the most current information, please contact our security team.