Security Policy

1. Our commitment to security

We take the security of your personal and Lodge data seriously. This page describes the technical and organisational measures built into the Masonic Lodge Digital Platform (the "Platform") to protect it, and how to report a concern. No system can guarantee absolute security, but we design and operate the Platform to reduce risk at every layer described below.

2. Multi-tenant data isolation

The Platform hosts many lodges on shared infrastructure, but each lodge's data is isolated from every other lodge's at the database level using row-level security policies, not merely by application-level filtering. Every tenant-scoped request explicitly sets which lodge it is acting for before any data is read or written, so one lodge's members, finances, and communications are never visible to another lodge - the one deliberate, narrowly-scoped exception being a cross-lodge link an officer explicitly creates for a member who holds plural membership at more than one lodge.

3. Access control

Access within a lodge's own data is further restricted by role. For example, welfare information is visible only to the almoner, secretary, worshipful master, and platform administrators - not to the general membership - and administrative functions (managing lodges, feature configuration, and the audit log) are restricted to administrator-tier roles. Every privileged action is checked against the acting user's role before it is permitted.

4. Authentication and account security

• Passwords are never stored in plain text - they are stored using a salted, one-way cryptographic hash (bcrypt), so we cannot see or recover your actual password, even internally.
• Login, password-reset, and account-verification endpoints are rate-limited to slow down automated guessing attempts.
• Sessions use short-lived signed tokens; when you log out, your token is explicitly revoked rather than simply discarded client-side, so it cannot be replayed.
• The Platform supports multi-factor authentication as an additional, optional layer of account protection.
• A forced password-change flow can be triggered by an administrator, for example after a password reset, and blocks access to the rest of the Platform until completed.

5. Encryption and secure transport

All traffic between your device and the Platform is encrypted in transit using HTTPS/TLS. We do not load fonts, scripts, or libraries from third-party content-delivery networks, reducing exposure to third-party supply-chain risk.

6. Application-layer protections

• A Content-Security-Policy header, with a fresh cryptographic nonce on every request, restricts which scripts are allowed to run in your browser, reducing the impact of cross-site scripting.
• Every state-changing form submission carries a per-session CSRF token, so a malicious third-party site cannot silently submit actions on your behalf.
• All database access goes through parameterised queries and stored procedures/functions - user input is never concatenated directly into a database query.
• Output is escaped before being rendered back to the browser to prevent stored or reflected cross-site scripting.

7. Logging and audit trail

Sensitive actions - such as changes to membership records, financial transactions, and administrative configuration - are written to an append-only audit log, viewable by lodge administrators, so unexpected changes can be investigated after the fact.

8. Third-party services

Where a treasurer connects an optional accounting integration (e.g. Xero, Sage, or QuickBooks), that connection uses the provider's own industry-standard authorisation protocol (OAuth2) wherever the provider supports it, rather than the Platform permanently storing your accounting credentials. The Platform does not process online card payments and does not store payment card data.

9. Incident and breach notification

If we become aware of a security incident that is reasonably likely to result in a risk to your personal data, we will investigate promptly and, where required by law, notify the affected lodge(s) and/or the relevant regulator without undue delay - including, where applicable, within the 72-hour window required by the GDPR, and in line with the notification duties under POPIA and the CCPA/CPRA for affected California residents.

10. Reporting a vulnerability

If you believe you have found a security vulnerability in the Platform, please report it responsibly to info@ath.solutions with enough detail for us to reproduce it. Please do not publicly disclose a vulnerability before we have had a reasonable opportunity to investigate and address it, and do not access, modify, or delete data that does not belong to you while investigating. We will acknowledge good-faith reports made in accordance with this policy and will not pursue legal action against researchers who follow it.

11. Your role in keeping your account secure

• Use a strong, unique password for your account and do not share it with anyone.
• Enable multi-factor authentication where it is available to you.
• Log out of shared or public devices after use.
• Report suspicious activity on your account to your Lodge secretary immediately.

12. Changes to this policy

We may update this Security Policy from time to time as the Platform evolves. We will update the "Last updated" date at the top of this page when we do.

13. Contact us

For general questions about this policy, contact your Lodge secretary through the Platform or use our Contact page. For security reports or questions about the Platform's technology, contact info@ath.solutions.