Security, Access and Backup - technical details

Application-level access controls

Access to Member Wizard requires an authenticated user account. Access is also restricted according to the organisations and functions that the user has been authorised to access.

Our application APIs validate the identity and authorisation of the user rather than relying solely on controls within the browser application. This is important because browser-side controls alone cannot prevent someone from attempting to call an API directly.

Additional controls include:

• encrypted HTTPS/TLS communication between users, the application and its APIs;

• access controls that restrict users to the relevant organisation and permitted functions;

• individual user accounts, rather than shared accounts, to support accountability;

• restricted administrative and database access;

• logging and monitoring of application and infrastructure errors; and

• payment card information being handled by our payment providers rather than stored in the Member Wizard database.

• also: sessions expire after 12 hours, passwords are hashed, Member Portal login attempts are throttled, user logins can be de-activated, database access is restricted by IP address, invalid login attempts are monitored

SQL injection protection

Yes. Database commands are written using parameterised SQL commands rather than constructing SQL statements by directly concatenating information supplied by users.

Parameterisation ensures that user-supplied values are treated as data rather than executable SQL. We also validate inputs at the application/API layer and restrict the permissions granted to application database identities using Microsoft Entra.

Developer passwords and privileged access

Developer and administrative access is separate from ordinary Member Wizard user access. Developers do not use normal client accounts to obtain unrestricted access to client information.

Access to Azure, source code, deployment systems and production resources is limited to authorised personnel. Privileged accounts are subject to stronger controls than ordinary Member Wizard accounts, including unique accounts and multi-factor authentication.

Passwords and authentication secrets used by the application are not stored in source code. Sensitive configuration is held in Azure Key Vault.

MFA for developers

We are in the process of enforcing MFA consistently across all privileged systems

MFA for Member Wizard users

MFA is not currently available as an organisation-level option for standard Member Wizard administration users.

We recognise that MFA would provide a valuable additional control, particularly for users who can access personal or financial information, and it is an item we are considering for the Member Wizard Admin Portal authentication system.

We are not considering it for Member Portal access at this stage as, taking into account the technical proficiency of many members, we believe it would be an impediment to users accessing their own information via their Portal. 

Database backups

Azure SQL Database performs automated backups.

These backups support point-in-time restoration within the configured retention period. Microsoft manages the underlying backup files and determines the combination of full, differential and transaction-log backups needed for a restore.

Clients are not provided with direct access to Microsoft’s internal Azure SQL backup files. Direct access would introduce both security and confidentiality risks.

We can, however, provide an export of an organisation’s Member Wizard data where required, subject to the applicable agreement, security checks, export format and any reasonable processing requirements.

Our current point-in-time backup retention period is 35 days. Long-term retention is 12 months.

RTO and RPO

It is important to distinguish between Microsoft Azure’s platform capabilities and Member Wizard’s own tested recovery objectives.

For recovery from an accidental data change or database corruption using point-in-time backup, the potential data loss is normally limited by the most recent available transaction-log backup. Azure SQL transaction-log backups are generally taken approximately every 10 minutes. However, this should not be presented as a contractual RPO unless we have formally committed to and tested it.

Restore time depends on factors including database size, database activity, the selected restore point, available Azure capacity and whether restoration is occurring into another region. Microsoft notes that some restores can take several hours.

Our present recovery objectives are:

• RPO: up to 15 minutes for a database incident, subject to Azure backup availability.

• RTO: 12 hours for a database restore and service recovery during supported hours.

These objectives should be regarded as targets.

Our current regional-disaster configuration is recovery from backup stored in a different Azure data center.

Previous restores and disaster-recovery testing

We have restored Member Wizard databases when required. Each occasion has occurred when a client has ignored delete confirmation. Minimum charge for restoration when the client has caused the need is $500

The most recent tested restore was completed in 2026. The database was restored to a point 1 day before, and the restore was completed 12 hours after the request.

Audit trail

Member Wizard uses individual user accounts so that activity can be associated with the person who performed it. The system records audit information for financial transactions, communications, invoice changes, logins, attendance.

The current financial transaction audit information records user, date/time, action, previous value and new value.

Not every data field necessarily has a complete historical record of every old and new value.

Clients can access audit information through financial and class audit reports. Additional audit information can be supplied by Member Wizard support where appropriate, although technical security logs may contain information relating to other clients or security-sensitive system details and cannot be provided without review.

Data Breach Response Plan

We have procedures for investigating, containing and responding to suspected privacy or security incidents. We are currently consolidating these procedures into a formal written Data Breach Response Plan aligned with the Australian Notifiable Data Breaches scheme. We would prefer to be transparent about that status rather than describe the current procedures as a completed formal plan.

We are happy to provide further information on any of these controls, subject to ensuring that disclosure does not itself reveal security-sensitive configuration or information relating to other Member Wizard clients.