Skip to main content

Security Transparency

Essential Eight Self-Assessment

The Australian Government's Essential Eight Maturity Model defines baseline cyber security controls for organisations. We publish this self-assessment openly as part of our security transparency programme.

Framework

ACSC Essential Eight

Assessment type

Self-assessed

Last reviewed

July 2025

Self-assessed disclosure

This is a self-assessed disclosure against the ACSC Essential Eight Maturity Model. It has not been independently verified by an accredited assessor. We are pursuing independent verification through penetration testing (scheduled 2025) and will update this assessment when independent results are available. Last reviewed: July 2025.

Maturity Level Summary

#ControlMaturity Level
1Application ControlLevel 1
2Patch ApplicationsLevel 2
3Configure Microsoft Office MacrosN/A
4User Application HardeningLevel 1
5Restrict Administrative PrivilegesLevel 2
6Patch Operating SystemsLevel 2
7Multi-factor AuthenticationLevel 2
8Regular BackupsLevel 2

Detailed Assessment

Control 1Level 1

Application Control

Prevent execution of unapproved or malicious programs on systems.

Our implementation

OpenBook Clinical is deployed as a serverless Next.js application on Vercel's managed infrastructure. There are no traditional servers on which arbitrary applications could be installed or executed. Vercel's serverless runtime enforces strict isolation — only our deployed application code runs. No user-facing code execution environment exists. Database access is mediated exclusively through the Supabase client and server-side API routes, which do not permit arbitrary code execution.

Evidence

Vercel serverless architecture; no shell access to production environment; Supabase RLS enforced at database layer.

Known gaps / roadmap

Traditional application whitelisting tools are not applicable to our serverless architecture. We consider this a functional equivalent at ML1.

Control 2Level 2

Patch Applications

Patch or mitigate vulnerabilities in applications as quickly as possible.

Our implementation

GitHub Dependabot is enabled and configured to automatically create pull requests for dependency updates across all npm packages. Security-critical patches are merged and deployed via Vercel's CI/CD pipeline typically within 48 hours of a Dependabot alert. Vercel automatically deploys from the main branch on every merge — there is no manual patching step. Node.js runtime versions are managed by Vercel and kept current.

Evidence

Dependabot enabled on GitHub repository; Vercel auto-deploy on push to main; npm audit run on every deployment.

Known gaps / roadmap

No formal patch SLA document exists. We are formalising a written patching policy as part of our SOC 2 pathway.

Control 3N/A

Configure Microsoft Office Macros

Configure Microsoft Office macro settings to block macros from the internet.

Our implementation

Not applicable. OpenBook Clinical is a SaaS product with no organisational Microsoft Office deployment. We do not use Microsoft Office in production infrastructure. Staff use Google Workspace for internal documents. No macro-enabled Office documents are used in any production or administrative workflow.

Evidence

N/A — no Microsoft Office deployment in production infrastructure.

Notes

N/A

Control 4Level 1

User Application Hardening

Configure web browsers and other applications to reduce attack surface.

Our implementation

OpenBook Clinical requires a modern web browser (Chrome 90+, Firefox 88+, Safari 14+, Edge 90+). We enforce HTTP security headers including Content Security Policy, X-Frame-Options: DENY, X-Content-Type-Options: nosniff, and Strict-Transport-Security via Next.js headers configuration. No Java, Flash, or deprecated browser plugins are used or supported. The application does not rely on any browser extensions.

Evidence

HTTP security headers configured in next.config.js; CSP restricts script and style sources; no legacy plugin dependencies.

Known gaps / roadmap

We do not currently enforce browser version requirements at the application layer — we rely on user compliance. Formal browser policy to be documented.

Control 5Level 2

Restrict Administrative Privileges

Restrict administrative privileges to systems and applications based on user duties.

Our implementation

Supabase Row Level Security (RLS) is enabled on all user data tables, enforcing least-privilege data access at the database layer. The Supabase service role key (which bypasses RLS) is stored exclusively as a server-side environment variable and is never exposed to the client. Administrative access to the Supabase dashboard and Vercel project is restricted to named individuals with MFA enforced. Privileged access is reviewed quarterly. No shared credentials exist for production systems.

Evidence

Supabase RLS policies on all data tables; service role key in server-side env only; MFA enforced on Supabase and Vercel admin accounts.

Known gaps / roadmap

A formal Privileged Access Management (PAM) policy document is in progress.

Control 6Level 2

Patch Operating Systems

Patch or mitigate vulnerabilities in operating systems as quickly as possible.

Our implementation

OpenBook Clinical operates entirely on managed, provider-maintained infrastructure. Vercel manages all OS-level patching for serverless function runtimes. Supabase (on AWS ap-southeast-2) manages OS patching for all database and storage infrastructure. We have no self-managed servers, virtual machines, or containers that require manual OS patching. AWS and Supabase both publish security bulletins and apply patches on a defined schedule.

Evidence

Vercel managed runtime — no self-managed OS; Supabase on AWS with managed OS patching; no self-hosted infrastructure.

Known gaps / roadmap

We do not receive direct notification of OS-level patches applied by our providers. We rely on provider security bulletins and SOC 2 reports.

Control 7Level 2

Multi-factor Authentication

Use multi-factor authentication for all remote access and privileged accounts.

Our implementation

Supabase Auth provides MFA capability for user accounts, including TOTP-based authenticator app support. All administrative accounts (Supabase dashboard, Vercel, GitHub) have MFA enforced via organisational policy. User-facing MFA for OpenBook Clinical accounts is available and recommended. Staff accounts that have access to production systems are required to have MFA enabled — this is enforced at the SSO/identity provider level.

Evidence

Supabase Auth MFA capability enabled; admin accounts on Supabase, Vercel, and GitHub require MFA; staff MFA enforced via identity provider.

Known gaps / roadmap

MFA is not yet mandatory for all end-user OpenBook Clinical accounts — it is available but opt-in. Mandatory user MFA is on our roadmap.

Control 8Level 2

Regular Backups

Perform and test backups of important data, software, and configuration settings.

Our implementation

Supabase performs daily automated backups of all database data, retained for 7 days on the Pro plan. Vercel provides atomic, immutable deployments — every deployment is a complete snapshot of the application and can be instantly rolled back via the Vercel dashboard. Application configuration (environment variables, deployment configuration) is stored in version-controlled files and Vercel's encrypted environment variable store. Code is backed up continuously via GitHub.

Evidence

Supabase daily automated backups with 7-day retention; Vercel atomic deployments with instant rollback; GitHub as code backup.

Known gaps / roadmap

We have not conducted a formal documented backup restoration test. A quarterly restoration test is scheduled as part of our DR programme.

Security questions?

Want more detail on our security posture?

This self-assessment is a starting point. For detailed security architecture documentation, a Data Processing Agreement, or to discuss specific requirements for your organisation, contact our security team.