Your board's most sensitive information, protected — and explained plainly

Your data belongs to you

You own your data. Everything your organisation puts into BoardTable — meeting papers, minutes, registers, declarations and uploaded documents — remains your organisation's property at all times. BoardTable is the custodian, not the owner.

We do not sell your data or share it with third parties for marketing. BoardTable does not use customer content to train its own models; provider handling of customer-directed AI requests is governed by the relevant API terms and our sub-processor arrangements. Administrators can export data while the account is active. Closure, deletion and backup expiry follow the written closure plan and verified operational retention settings described in our DPA and Privacy Policy; we do not currently promise an automated 30/60/90-day lifecycle.

Hosting & infrastructure Production evidence required

BoardTable's intended primary hosting region is Microsoft Azure, Australia East (Sydney). This does not mean all processing remains in Australia: the sub-processors and customer-directed integrations listed in our DPA can process limited data overseas or on global infrastructure. Region locks, backup location, managed identities and other Azure controls are deployment settings, so we confirm them from the live environment rather than inferring them from application code.

We build on Azure precisely because its underlying platform carries independent accreditations that no small vendor could achieve alone. Azure's infrastructure is certified against ISO/IEC 27001, 27017 and 27018, SOC 1, SOC 2 Type II and SOC 3 and PCI DSS, and is assessed under the Australian Government's IRAP framework. To be clear about what that means: these are Azure's certifications for the data-centre and cloud platform we run on — not BoardTable's own organisational certifications. BoardTable's own SOC 2 programme is on our roadmap (below).

Encryption In place

In transit

The application enforces HTTPS outside local development and sends HSTS headers. Supported TLS versions and cipher suites are controlled at the Azure edge and must be verified against the live production endpoint; they cannot be proven from this repository alone.

At rest

BoardTable supports SQLCipher/AES-256 database encryption with a separately managed key, and AES-GCM protection for authenticator secrets. These controls are effective only when production keys are configured and protected. Azure storage-layer encryption for databases, uploaded documents and backups is an infrastructure setting that must also be confirmed from the live subscription. This is encryption at rest, not end-to-end encryption.

Passwords

Passwords are never stored in plaintext. We hash them with bcrypt (work factor 10), which makes brute-force attacks computationally infeasible.

Access controls In place

BoardTable uses a role-based access-control model with four roles, so people see only what their role allows:

• Administrators manage the organisation's account, users, meetings and all governance records.
• Staff (e.g. a company secretary or EA) can build meetings, agendas and packs, but don't have full account control.
• Chair has director access plus chair-specific abilities such as finalising minutes.
• Directors access meeting materials, submit conflict-of-interest declarations, and view the documents they've been given permission to see.

A member's effective permissions come from their role in your organisation, and individual agenda items or documents can be marked confidential and restricted to named people. Authenticated API and protected-file requests re-check the current account, organisation membership, role, session revocation and MFA state against the database, so removal or a role change takes effect on the next protected request.

Two-factor authentication In place

BoardTable requires time-based one-time-password (TOTP) two-factor authentication for every account, compatible with apps such as Google Authenticator and Authy. It is enforced on every request, not only at sign-in: a session stops working the moment an account is deactivated, demoted or removed from a board.

When two-factor is first switched on for an existing board, each account has a seven-day enrolment window. Inside that window a director who has not yet set up an authenticator app can choose “Set up later” and keep working, and we record that choice against their deadline; after it, enrolment is the only way in. Superadministrators are excluded from the window and must enrol immediately, and an organisation can switch the window off entirely so that two-factor applies from the moment it is enabled. We describe it plainly because during those seven days a password alone can still open a session for an un-enrolled account — which is the trade-off the window exists to make.

Audit logging In place

BoardTable records significant events — sign-in successes and failures, protected document access and downloads, exports, changes to governance records, user/role changes, denials and administrative actions. The application provides broad safety-net coverage plus richer domain events, but does not claim to record every read or UI interaction. Retention and immutable off-system storage are operational controls that must be confirmed for the production environment.

Backups In place

Production takes a daily online snapshot of the database, keeps the most recent fourteen locally, and copies each one off the application host into Azure Blob Storage. Every run is audited, including its failures. The off-host account is geo-redundant within Australia (Australia East with a paired copy in Australia Southeast), blob versioning and soft delete are on, and snapshots expire after ninety days. The credential the application holds can create and write snapshots but cannot read, list or delete them, so a compromise of the application cannot quietly destroy its own backups.

Restore tested 22 August 2026. A production snapshot was downloaded, integrity-checked and served by a running instance in under a minute of working time. That figure is the restore step only — it excludes the time to detect a problem and decide to act, so we quote it as evidence that the path works rather than as a recovery-time guarantee. Administrators can also export organisation data at any time from the Backup & Export tools.

Handling a security incident In place

If a data breach affecting personal information ever occurred, we would act to contain it promptly, assess whether it is likely to result in serious harm, and notify affected organisations without undue delay. We will comply with our obligations under the Notifiable Data Breaches (NDB) scheme administered by the Office of the Australian Information Commissioner (OAIC), including notifying the OAIC and affected individuals where the scheme requires it, and we'll give affected organisations a written summary of what happened and what we did about it.

Superadmin & staff access In place

BoardTable is operated by a very small team, and staff access to your data is limited to what's needed to run and support the service, under a principle of least privilege. The platform has a single superadmin role, held only by BoardTable's operators, which exists to provision new organisations and provide technical support. Superadmins are bound by confidentiality and will never read, disclose or act on the contents of your board's papers, minutes or registers except where strictly necessary to resolve a support request you've raised, or where required by law.

Reporting a security or privacy concern

If you believe you've found a security vulnerability, or you're concerned data may have been exposed or accessed improperly, email hello@boardtable.com.au with as much detail as you can safely share. We operate a responsible-disclosure approach, will acknowledge your report within 2 business days, and will keep you informed as we investigate. Please give us a reasonable opportunity to address an issue before disclosing it publicly.

Our security roadmap

We'd rather be honest about where we're headed than imply we're further along than we are. These are the security investments we're working towards — they are not in place yet: