This is the multi-page printable view of this section. Click here to print.
This is a placeholder page for now.
Eventually, we’ll build this out to include a more structured navigation to key resources, including how to contribute to the Handbook.
For now, you can see the top-level sections below, or in the sidebar to the left.
The purpose of this policy is to ensure corporate credit cards are issued and used appropriately for Vaxa related business, and all expenses incurred are properly approved and acquitted.
The Corporate Credit Card Policy sets out Vaxa’s policy on corporate credit cards (“Card”). It applies to all corporate credit cardholders (“Cardholder”), managers responsible for authorising credit card applications, and approvers of the Cardholder’s acquittals.
Corporate Credit Cards must be used appropriately within relevant delegations, and in accordance with Vaxa policies and legislation.
The purpose of the Card is to facilitate and simplify the purchasing process for minor purchases and travel expenditure which are not able to be processed through Vaxa’s Purchase Order process.
The Card will only be issued to an employee who:
Both ongoing and non-ongoing employees can apply for the Card provided they have a genuine business need such as that specified above.
Contractors will not be eligible for the Card. The exception to this is where a contractor is working on a long term contract for Vaxa, and will be required to undertake frequent travel as part of that engagement.
Standard transaction and monthly limits are as follows
| Delegation | Transaction Limit | Monthly Limit |
|---|---|---|
| Managing Director | $1,000 | $5,000 |
| Director | $500 | $2,000 |
| Executive Assistant | $200 | $1,000 |
| All other staff | $200 | $1,000 |
Variations to the standard limits must be supported by genuine business need and approved by the Managing Director only.
Limits are subject to annual review.
The Card is not transferable and may be cancelled by Finance when:
Cardholders must obtain approval from an appropriate financial delegate before using the Card to pay for their own business expenses e.g. professional membership, training, travel etc., see Instrument of Delegations—Financial Authorisations.
Direct debit authorities must not be placed on the Card except where business conditions necessitate and are approved by the Managing Director.
Centrally purchased items such as assets, IT equipment, property/equipment, stationery and insurance should only be purchased by the Managing Director, unless the Cardholder has obtain specific approval from the respective teams to purchase items separately on the Card.
Misuse of the Card is a serious matter and may constitute a breach to this policy.
Penalties apply for fraud or misuse of the Card under the Crimes Act 1914. Cardholders may be liable for any loss to Vaxa.
Suspected or inadvertent misuses of the Card must be reported, investigated and dealt with in accordance with the Corporate Credit Card Procedures. Disciplinary action against the cardholder includes, and is not limited to, a warning, full recovery of monies, criminal proceedings, or other direction at the discretion of the Managing Director.
Non-compliance with this policy may result in the cancellation of the Card and/or disciplinary action, up to and including termination of employment.
None.
The purpose of this policy is to establish a streamlined change management control process that ensures all changes to major systems are effectively managed, minimising risk and ensuring system stability. This policy is supported by our continuous integration and continuous delivery (CI/CD) approach.
This policy applies to all team members involved in the development, testing, deployment, and maintenance of major systems within the organisation.
Who is responsible for doing what. This should refer to departments or roles instead of specific individuals.
| Role | Responsibility |
|---|---|
| Developer | Propose and implement changes, perform initial testing. |
| Second developer | Review and approve changes, assess risks, authorise deployments. |
| CTO | Approve all medium & high-risk changes and ensure compliance with the policy. |
All changes to major systems must follow the procedures outlined below to ensure proper risk assessment, testing, authorisation, and control.
All changes, approvals, test results, and deployment logs are stored in version control for audit purposes. This are retained in line with our Data Retention Policy.
Overview of why the controlled document is being implemented.
Who or what does the controlled document apply to.
Who is responsible for doing what. This should refer to departments or roles instead of specific individuals.
| Role | Responsibility |
|---|---|
| [Role] | [Responsibility] |
The details! Detail the specific policy, procedure, or process. This section can include step-by-step instructions or rules that must be followed.
Define how exceptions to the controlled document will be tracked.
Define how compliance with the controlled document will be monitored and what checks will be performed (where applicable).
Procedure documents should map back to a governing policy or standard, and may relate to one or more procedures or other uncontrolled documentation. Policy documents may relate to an internal or external framework or legal requirement.
This document provides a detailed overview of our Munki and Autopkg setup, which is used to manage software installations and updates across our organisation. It is designed to cover most things, from the basics for non-technical users to in-depth technical details for our administrators and contributors.
Imagine you have many computers in an organisation, and you need to install and keep software updated on all of them. Doing this manually would be very time-consuming and prone to errors. This is where Munki and Autopkg come in.
Munki is like an app store for our organisation’s computers, but it works in the background. It automatically installs new software, updates existing software, and even removes software when needed, all without requiring constant manual intervention. Think of it as an automated software delivery system that ensures everyone has the right tools and the latest versions.
Autopkg is a tool that works with Munki to make software management even easier. Autopkg automates the process of finding new versions of software, downloading them, and preparing them for Munki to install. It’s like a helper that constantly searches for updates so we don’t have to do it manually.
Why are Munki and Autopkg important?
In short, Munki and Autopkg are essential tools that help us manage software efficiently, securely, and consistently across our organisation, ensuring everyone has the tools they need to work effectively.
For those involved in managing or contributing to our Munki and Autopkg setup, understanding the basic workflow and tools is essential.
autopkg/recipes: The main repository containing a wide range of common software recipes.vaxa-tech/autopkg-recipes: Our internal repository of recipes.vaxa/vaxa-security/munki repository. This repository is then synced to Azure Blob Storage, and access from a workstation is facilitated via a Shared Access Token (downloaded via Intune) and middleware_azure.py.Refer to each of the repositories for detailed setup instructions:
Our Munki and Autopkg infrastructure is designed for reliability, scalability, and automation.
The Munki repository is hosted on Azure Blob Storage. This location was chosen because it integrates nicely with our Microsoft stack, and additionally has a lower cost for storing large files versus GitHub’s LFS (where we originally hosted Munki).
Autopkg runs are automated using Azure DevOps Pipelines. We use Azure DevOps Pipelines to:
We leverage Azure DevOps for:
To contribute a new package to our Munki setup, follow these steps:
pkg, dmg, app).autopkg run -v <YourRecipe.recipe> for verbose output and debugging.autopkg/overrides directory. This allows us to customise recipes for our environment without affecting the base recipes. This is still secure because only the original base recipe is trusted; any changes to the base recipe will require manual review. Most of the time, you’ll want to change the catalogs in the override to release (until we get autopromote working).autopkg run -v <YourOverride.munki.recipe>.main branch, clearly describing the new package and any relevant details.Updating existing packages is crucial for security and ensuring users have the latest features.
import catalog in our Munki repository.import catalog for testing.testing Munki catalog for deploying updates to a subset of test machines.prerelease catalog can be used for even earlier testing phases.testing catalog, packages can be promoted to the release catalog to be deployed to all managed machines. Catalog promotion is typically done by:Input variables or processors. These changes should be made via pull requests as described in the “Contributing New Packages” section.The pull request workflow in Azure DevOps is essential for maintaining the quality and stability of our Munki and Autopkg setup.
main branch. This action triggers the automated deployment process, making the changes live in our Munki environment.munki/icons directory. Ensure new packages have appropriate icons for a better user experience in Self Service (if used).munki/manifests) define which software packages are installed on different groups of machines. The site_default manifest is the primary manifest applied to most machines. Create or modify manifests as needed to customise software deployments for specific departments or user groups.munki/pkgsinfo) contain metadata about each software package, such as name, version, description, and dependencies. Autopkg automatically generates pkginfo files based on recipes. Review and customise pkginfo files as needed for specific requirements.-v flag) when running Autopkg commands for debugging.This document provides a comprehensive guide to our Munki and Autopkg setup. By following these guidelines and procedures, we can ensure efficient, consistent, and secure software management across our organisation.
Cybersecurity isn’t just about protecting systems—it’s about maintaining trust, ensuring business continuity, and safeguarding the data we’re entrusted to keep safe.
Vaxa’s cybersecurity strategy focuses on practical, high-impact measures that align security with our business operations.
We structure our approach around five key pillars: risk management, cyber detection and prevention, access and identity control, data security, and resilience and response. Each pillar provides a guiding framework for securing our business without unnecessary complexity or overhead.
Security starts with understanding risk. We take a proactive approach by identifying the most critical threats to our business—whether that’s data breaches, insider threats, phishing attacks, or system failures.
Risk assessments are an ongoing process, not a one-time exercise. We evaluate risks based on their likelihood and impact, ensuring that security measures are proportionate to the business’s size and resources. Where possible, we mitigate risks through secure architecture, strong internal practices, and cyber insurance for financial protection.
Our strategy prioritises early detection and proactive prevention to reduce the likelihood and impact of cyber incidents.
We implement continuous monitoring for suspicious activity, using tools that provide real-time alerts on unauthorised access attempts, malware, or data exfiltration. Prevention starts with strong authentication, secure configurations, and automated updates—ensuring our systems remain protected without manual intervention. We also use external threat intelligence to stay ahead of emerging risks.
A key part of prevention is educating our team. Cybersecurity awareness is built into our culture, ensuring that everyone understands the risks of phishing, weak passwords, and social engineering attacks.
Limiting access is one of the simplest and most effective ways to reduce cyber risk. We follow a zero trust approach, where access is only granted on a need-to-know basis. Every system, account, and user remains untrusted at every link in the chain. We instead verify each request based on the user’s identity, device, and context to make an informed decision on providing access.
Multi-factor authentication (MFA) is enforced across all critical systems, reducing the risk of compromised credentials. Administrative privileges are tightly controlled, and regular audits ensure that old or unused accounts are removed. We use role-based access control (RBAC) to define who can access what, ensuring that sensitive data is never exposed unnecessarily.
As a digital business, our most valuable asset is data. Protecting it is non-negotiable.
We encrypt sensitive data both in transit and at rest, ensuring that even if data is intercepted, it remains unreadable. Backups are maintained regularly and stored securely, with an emphasis on offsite and immutable backups that can’t be altered by ransomware.
Client and business data is handled with clear security and privacy considerations, ensuring compliance with relevant regulations (e.g., Australian Privacy Act). Secure file sharing and communication methods are used to prevent accidental data leaks.
No security strategy is complete without a plan for when things go wrong. Cyber resilience is about ensuring the business can recover quickly from incidents while minimising disruption.
We maintain a simple but effective incident response plan, detailing how to contain, investigate, and recover from security breaches. Regular testing, including simulated phishing attacks and breach response drills, ensures that we’re prepared for real threats.
Business continuity is a priority. We ensure that critical systems and data can be restored quickly in the event of an attack, outage, or data loss. By combining strong technical defences with a well-rehearsed response plan, we build a business that can withstand and adapt to cyber threats.
Cybersecurity is not just an IT function—it’s a core part of how we operate. By embedding security into every aspect of our business through risk management, cyber detection and prevention, access control, data security, and resilience, we ensure that security supports growth rather than hinders it.
This strategy evolves as the business grows, adapting to new threats and technologies while keeping security simple, effective, and aligned with business needs.
As part of our mission, Vaxa necessarily handles privileged information on behalf of our clients, partners and personnel.
The information we hold needs to be treated with care and respect regardless of its physical or electronic format–it’s our ethical duty.
Vaxa also has legislative, moral and contractual responsibilities to ensure that we protect all information adequately. By designing for security, establishing strong policy frameworks, and providing training, we can help protect the information we handle against the ever-growing landscape of information security threats.
The security controls implemented to safeguard the information should mitigate threats to prevent harm from coming to those we are assisting and ensure we can continue to provide first-class services. We should strive to implement security controls that appropriately safeguard information, but with respect to the impact it has on our operations.
Vaxa has committed to series of policies that guide organisation-wide decision making when it comes to operating at highest standards when securing information. They will also help demonstrate to our clients that we operate with integrity and accept that we are accountable for protecting the information entrusted.
Above all else, we build on the following fundamental security principles:
Our policies apply equally to all personnel (staff or contractor) accessing information or our information processing systems. Vaxa commits to ensuring all personnel are issued with the appropriate policies (namely, via the Handbook), can access them easily and understand the importance of adhering to them. Vaxa commits to plain language and clear communication across all that it does.
Vaxa also commits to reviewing and updating our policies to meet the changing external landscape and our internal requirements.
Have questions? Please reach out to the ISG Group.
Written and adopted by:
Vaxa’s Cyber Incident Response Plan (CIRP) provides a structured approach to detecting, responding to, and recovering from cyber incidents.
The goal is to minimise damage, restore normal operations quickly, and prevent future incidents. Cyber-attacks can escalate rapidly, so a clear and coordinated response is critical.
This plan covers cyber and information security incidents that impact Vaxa’s IT systems, data, or digital assets. These incidents may include:
Technically speaking, cybersecurity incidents are a subset of Information Security incidents (for example, the loss of a physical document containing sensitive information would be an Information Security incident, but not a Cybersecurity incident). In practice, we treat these the same way so we can respond quickly and effectively without the overhead of maintaining many separate plans.
General IT issues don’t fall part of this plan unless they’re suspected to be caused by a cyber incident. This therefore excludes things like:
If you’re experiencing one of these, you should use the usual process to report to the IT team who may enact the Disaster Recovery policy and plans as required.
All employees play a role in keeping Vaxa’s systems secure. As part of the team, you should:
Managers are responsible for ensuring their teams understand and follow security policies. Specifically, managers should:
The CIRT is responsible for managing incidents and coordinating response efforts. Their responsibilities include:
The CIRT structure will vary based on incident severity, but typically includes:
As Vaxa doesn’t engage a permanent IT Service Provider, the CTO will be responsible for coordinating with external IT providers if required.
Ownership of these plans and their review/update sits with the CTO. They are responsible for ensuring the plans are up to date. Particular importance is placed on the responsibility of keeping contact details up to date.
Proactive preparation reduces risk and ensures Vaxa is ready to respond effectively. This includes:
Actual or suspected incidents must be identified quickly to reduce potential damage.
If you suspect a cyber incident:
Failure to report an incident may result in disciplinary action.
Once a report of an incident is received and validated, the CIRT will be activated. The CIRT can place a priority on the incident.
Incident management occurs in our Grafana incident response management system.
Once an incident is confirmed, the CIRT will take action to prevent further damage. This may involve:
As part of containment, forensic evidence should be gathered where appropriate. Our approach generally keeps logs in a place where they can’t be tampered with, but still, care should be taken to ensure that evidence is preserved as much as possible. General guidance for forensic evidence preservation includes:
Once initial containment is complete, the CIRT must contact our First Response provider:
The First Response Advisor:
The advise of the First Response Advisor should generally be followed as they are experts in the field of cyber incident response, and are familiar with the legal and regulatory environment in which we operate. Our cyber insurance policy recommends that we follow their advice.
The CIRT will perform the initial triage and investigate the source, method, and impact of the attack. This includes:
The incident severity will be determined based on:
The severity will guide the response and recovery efforts.
Once the issue is understood, the next step is to fix vulnerabilities and prevent recurrence. This may involve:
We try to develop a range of playbooks that can be used to respond to common incidents. You can find this in the Playbooks & Plans section, and in Grafana.
Restoring systems and monitoring for lingering threats. Recovery actions include:
Managing stakeholders is an important part of our incident response. This section outlines the communication and reporting requirements for different types of incidents.
Some incidents require notification to external parties. Our First Response Advisor will usually advise on this as the expert.
Generally, if we have a CRITICAL or HIGH incident, we will need to notify the following parties (each has their own specifics though):
For urgent support, contact:
If there is a threat to life or risk of harm, call 000.
For suspected incidents, use the internal email notification template to report details to your manager and the CIRT team.
| Incident Type | Description |
|---|---|
| Installation or execution of unauthorised or malicious software | Suspected, attempted or actual installation or execution of unauthorised or malicious software on a Vaxa device. Includes malware detections by anti-malware software (even if mitigated successfully) and detections by application whitelisting solutions. |
| Network intrusion, enumeration, or another probe | Suspected, attempted or actual network intrusion, enumeration, or probe. Includes intrusion alerts generated by network security equipment such as firewalls or IDS/IPS. |
| Physical loss, theft, or damage of an IT asset | Suspected, attempted or actual physical loss, theft or damage of any IT asset containing Vaxa data. Includes the loss or theft of laptops, tablets, smartphones, or removable media (USB sticks, CDs, DVDs, DATs, etc.). |
| Physical loss, theft, or damage of hardcopy information | Suspected, attempted or actual physical loss, theft, or damage of any Vaxa information in hardcopy. |
| User impersonation | Suspected, attempted or actual instance of user impersonation. Includes password-sharing, attacks on authentication controls, impossible log-on scenarios, etc. |
| Suspicious privilege amendment | Suspected, attempted or actual instances where a genuine user appears to have been placed in an inappropriate user group or to otherwise have gained excessive privileges. |
| Suspicious use of legitimate privileges | Suspected, attempted or actual instances where user appears to have abused legitimate access privileges, e.g., by accessing large number of files, e-mailing data to unauthorised recipients, copying data to removable media or unusual network locations, etc. |
| Eavesdropping on a legitimate comms channel | Suspected, attempted or actual instances where Vaxa data appears to have been intercepted by an unauthorised party. Includes instances where sensitive data is transferred to authorised recipients in unencrypted form. |
| Service spoofing | Suspected, attempted or actual instances where a data service belonging to, or used by, Vaxa is spoofed by a third party. Includes fake websites. |
| DoS or excessive resource consumption | Suspected, attempted or actual instance where an entity places an excessively high demand on an information system or asset. Includes Denial of Service and spam. |
| Phishing | Suspected, attempted or actual instances where: - Email received that claims to be something, or from someone, that it is not. - Persons outside receive email which claims to be from Vaxa but is not. |
| Social Engineering | Suspected, attempted or actual instances where an unauthorised person attempts to gain access to Vaxa data or IT systems by deception or extortion of authorised users (staff, customers or third parties). |
| Inappropriate use of IT facilities (including inappropriate web browsing) | Suspected, attempted or actual instance where user uses system which they have authorised access in an illegal manner, breach policy or contrary to workplace norms. This includes browsing websites that are inappropriate for workplace; sending threatening, obscene or harassing communication; or accessing/storing illegal material. |
| Other harmful mode not listed | Any event that is deemed to be a security event that falls within the remit of the CIRT, but which does not fall into any of the above categories. |
The following is an explicit description of Incident Threat Levels in descending order of criticality (worst at the top):
| Incident Threat Level | Description |
|---|---|
| Threat Level 1 | Human-Controlled Root-Level Compromise: - Unauthorised external personnel (cyber intrusion). - Partner organisation exceeding authority. - Internal personnel exceeding authority. - Close-access breach (physical penetration of a site). - Rogue wireless access point. - Router re-direct. |
| Threat Level 2 | Human-Controlled User-Level Compromise: - Unauthorised external personnel (cyber intrusion). - Partner organisation exceeding authority. - Internal personnel exceeding authority. |
| Threat Level 3 | Automated (malware-controlled) Root-Level Compromise |
| Threat Level 4 | Automated (malware-controlled) User-Level Compromise |
| Threat Level 5 | Denial of Service |
| Threat Level 6 | Focused Scanning or Unmanaged Malware |
The criticality of systems and information that is potentially at risk is the second component to guiding the assessment of the severity of an incident. The following is an explicit description of these system or information criticalities in descending order of importance (most important first):
| System/Information Criticality | Description |
|---|---|
| Criticality Level 1 | Company-Wide Network Resources (Revenue-Generating Services, Routers, Switches, DNS, Proxies, Firewalls etc.). |
| Criticality Level 2 | Highly Critical Information – Confidential Information (Intellectual Property, PII, PHI). |
| Criticality Level 3 | High Criticality Systems (Active Directory, Exchange, Web Services etc.). |
| Criticality Level 4 | Sensitive Information – Restricted Information (Sensitive Corporate Information, non-PII, Financial Transaction Information etc.). |
| Criticality Level 5 | Non-Critical Multi-Use Systems (File Servers, SharePoint etc.). |
| Criticality Level 6 | Individual Systems and Non-Sensitive Information. |
The following table outlines the severity of incidents based on the combination of Incident Threat Level and System or Information Criticality.
| System or Information Criticality | Threat Level 1 | Threat Level 2 | Threat Level 3 | Threat Level 4 | Threat Level 5 | Threat Level 6 |
|---|---|---|---|---|---|---|
| Criticality Level 1 | Critical | Critical | Critical | High | High | Medium |
| Criticality Level 2 | Critical | Critical | High | High | Medium | Medium |
| Criticality Level 3 | Critical | High | High | Medium | Medium | Medium |
| Criticality Level 4 | High | High | Medium | Medium | Medium | Low |
| Criticality Level 5 | High | Medium | Medium | Medium | Low | Low |
| Criticality Level 6 | Medium | Medium | Medium | Low | Low | Low |
This policy outlines Vaxa’s overarching approach to information security management and signposts to specific sub-policies within our framework.
The Information Security Policy applies to
Who is responsible for doing what. This should refer to departments or roles instead of specific individuals.
| Role | Responsibility |
|---|---|
| [Role] | [Responsibility] |
To ensure comprehensive information security management, Vaxa has opted to establish several detailed policies that support and complement this Information Security Policy.
Employees, contractors, and other stakeholders are required to familiarise themselves with these policies and adhere to their guidelines.
The related policies include:
| Policy | Description |
|---|---|
| Privacy Policy | Outlines how Vaxa collects, uses, discloses, and manages personal and sensitive information. |
| Acceptable Use Policy | Describes the acceptable use of Vaxa’s information systems and resources. |
| Personnel Screening Policy | Details the procedures for screening personnel before employment/engagement. |
| Access Control Policy | Describes the requirements for granting access to Vaxa’s information systems and resources. |
| BYOD Policy | Describes the requirements for using personal devices to access Vaxa’s information systems and resources. |
| Data Classification Policy | Details measures and practices to classify data in compliance with relevant regulations and our risk tolerance, so that appropriate protections can be applied. |
| Data Retention Policy | Sets out the principles for retaining and disposing of data in a secure and compliant manner. |
| Mobile Device Policy | Describes the requirements for using mobile devices to access Vaxa’s information systems and resources. |
| Password Policy | Describes the requirements for creating and managing passwords. |
| Patching Policy | Describes the requirements for keeping Vaxa’s information systems and resources up-to-date with security patches. |
| Secure Development Policy | Outlines best practices for developing and maintaining secure software applications. |
| Supplier Security Policy | Establishes security requirements for engaging and managing third-party suppliers. |
| Asset Management Policy | Details procedures for managing information assets throughout their lifecycle. |
| Cloud Security Policy | Provides guidelines for the secure use and management of cloud services. |
| Remote Working Policy | Specifies security measures and practices for employees working remotely. |
| Backup Policy | Outlines procedures and guidelines for data backup to ensure data availability and integrity. |
Use caution when communicating confidential information in public areas due to the risks of being overheard.
Refer to our related third-party security policies;
Personnel will undergo background checks before being employed. See the Personnel Screening Policy for more information.
Define how exceptions to the controlled document will be tracked.
Define how compliance with the controlled document will be monitored and what checks will be performed (where applicable).
Procedure documents should map back to a governing policy or standard, and may relate to one or more procedures or other uncontrolled documentation. Policy documents may relate to an internal or external framework or legal requirement.
The purpose of this Backup Policy is to protect the confidentiality, integrity, and availability of data for both Vaxa and its customers. Complete backups are performed at regular intervals to ensure that data remains available when needed and in the event of a disaster.
This policy applies to all data and information systems owned, operated, or managed by Vaxa, including customer data, internal data, and all supporting infrastructure and systems.
| Role | Responsibility |
|---|---|
| IT Department | Implement and maintain backup systems and processes. Monitor backups and address any malfunctions promptly. |
| Security Officer | Oversee backup policy compliance and respond to backup failures or incidents. |
| Employees | Ensure business data is stored in company-controlled repositories and follow data classification procedures. |
| Management | Ensure data retention periods comply with regulatory and contractual requirements. |
Data classification:
Data storage:
Backup scope and frequency:
Data retention:
System documentation:
Monitoring and safeguards:
Use of removable media:
Vaxa’s customer data is stored in production accounts across numerous providers, depending on the nature of our engagement with the customer. In any case, Vaxa performs automatic backups to protect against catastrophic loss.
If you are a Vaxa customer, please ask us which of the below applies to your data.
Google Cloud Platform:
Microsoft 365:
Vaxa workstations:
Source code:
Automatic backups:
Backup frequency and encryption:
Monitoring and alerts:
Any exceptions to this policy must be documented and approved by the Security Officer and relevant management. Exceptions will be tracked and reviewed periodically to determine if they are still required.
Compliance:
Monitoring:
Reporting:
The purpose of this Data Classification Policy is to establish a framework for classifying Vaxa’s data based on its level of sensitivity, value, and criticality. This policy ensures that data is appropriately protected and accessible only to authorised individuals & systems.
This policy applies to all employees, contractors, consultants, partners, and any other personnel with access to Vaxa’s information assets. It covers all types of data, regardless of format or medium, including documents, emails, electronic files, and verbal communications.
| Role | Responsibility |
|---|---|
| Employees and Contractors | Classify data according to this policy at the time of creation or acquisition. Handle data according to its classification level. |
| Managers | Ensure team compliance with the data classification policy. Provide guidance on classification levels. |
| Information Owners | Determine the classification of information assets under their control. Approve access requests for sensitive data. |
| Security Officer | Oversee the implementation of the data classification policy. Provide training and support. |
All Vaxa data must be assigned a classification level at the time of creation or acquisition. The classification determines the security controls required for handling, transmitting, or storing the data.
These classification levels shall be applied as protective markings to data and information assets where possible.
| Classification Level | Color | Description |
|---|---|---|
| UNOFFICIAL | BLACK | Internal information not requiring specific protective measures. |
| PUBLIC | GREEN | Information authorized for unlimited external access and circulation to the public. Examples include press releases, marketing materials, blogs, webinars, social media posts, and the Vaxa website. |
| OFFICIAL (Default Classification) | GREY | Information that can be freely disclosed within Vaxa and to authorized external parties with a relevant business relationship. Examples include client metadata and proposals, most client data and reports (depending on sensitivity or client requirements), internal communications, policies, procedures, methodologies, photos taken within Vaxa offices, internal messages, and emails. |
| OFFICIAL: Sensitive | YELLOW | OFFICIAL information requiring limited dissemination due to its sensitive nature. Compromise could result in limited damage to individuals or organizations. |
| PROTECTED | BLUE | Valuable, important, and sensitive information. Compromise would be expected to cause damage to the national interest, organizations, or individuals. |
| VAXA RESTRICTED | BLUE | Information available only to authorized groups within Vaxa relevant to their job function. Can only be disclosed externally to specific third parties. Encryption (AES-256 or equivalent) must be used when transmitting or storing this data. Strong passwords are required if sending files. Examples include some client data and reports (depending on sensitivity or client requirements), data protected by state or federal regulations, and data under non-disclosure or confidentiality agreements. |
| VAXA PRIVILEGED | RED | Information disclosed internally on a need-to-know basis and externally only to specific authorized parties. Access must be approved by the information owner. Examples include finance information, sensitive human resources information, company business and strategy plans, board and shareholder reports, and any information subject to legal privilege. |
As Vaxa commonly interacts with entities under the Australian Government Protective Security Policy Framework (PSPF), we need to consider how our data classification levels align with the PSPF protective markings.
Vaxa, it’s personnel and systems are not authorised to process, store or interact with information above the classification of PROTECTED, and therefore we don’t include those classifications in this policy. There may be exceptions made under the appropriate legislative instruments, but these are rare and require specific approval. Internally, however, we do have similar classifications for data above PROTECTED, but again these are only for internal use.
Below is a table that steps out the alignment between Vaxa’s data classification levels and the PSPF protective markings.
Table 2 - Alignment between Vaxa’s Data Classification Levels and Australian PSPF Protective Markings
| Vaxa Classification Level | PSPF Protective Marking | Description |
|---|---|---|
| UNOFFICIAL | UNOFFICIAL | Internal information not requiring specific protective measures. |
| PUBLIC | UNOFFICIAL | Information authorized for unlimited external access and circulation to the public. |
| OFFICIAL | OFFICIAL | Information that can be freely disclosed within Vaxa and to authorized external parties with a relevant business relationship. |
| OFFICIAL: Sensitive | OFFICIAL: Sensitive | OFFICIAL information requiring limited dissemination due to its sensitive nature. Compromise could result in limited damage to individuals or organizations. |
| PROTECTED | PROTECTED | Valuable, important, and sensitive information. Compromise would be expected to cause damage to the national interest, organizations, or individuals. |
| VAXA RESTRICTED | No equivalent | This is a Vaxa-specific classification. |
| VAXA PRIVILEGED | No equivalent | This is a Vaxa-specific classification. |
(We note that UNOFFICIAL is not an officially recognsied PSPF Protective Marking, however many entities use this classification for internal information that does not require specific protective measures.)
Assignment of classifications:
Handling of data:
Review and Reclassification:
Any exceptions to this policy must be approved in writing by the Security Officer and the Managing Director. Requests for exceptions should include a justification and any mitigating controls.
Training:
Monitoring:
Reporting:
The purpose of this Data Retention Policy is to ensure that Vaxa retains necessary data for business operations, legal obligations, and regulatory compliance. This policy aims to manage data efficiently, reduce storage costs, and minimise risks associated with unnecessary data retention.
This policy applies to all employees, contractors, and third-party partners of Vaxa who handle company data. It covers all types of data collected, stored, processed, or transmitted by Vaxa, including electronic and physical records.
| Role | Responsibility |
|---|---|
| Management | Oversee policy implementation and compliance. |
| IT Department | Manage data storage, backups, and disposal. |
| Data Owners | Classify data and define retention periods. |
| All Staff | Follow data handling and retention guidelines. |
| Security Officer | Monitor compliance and conduct audits. |
Data classification
Retention periods
Data Disposal
Legal and regulatory dompliance
Third-party data
Any exceptions to this policy must be documented and approved by the Security Officer. Requests for exceptions should outline the reasons and duration of the exception, as well as details of how it was implemented in our data storage systems.
The Security Officer will conduct regular reviews to ensure adherence to this policy. Non-compliance may lead to disciplinary actions as per company guidelines.
This policy defines how Vaxa Analytics manages identities and access to systems, applications, and data. It ensures access is granted based on business needs while minimising security risks. The policy aligns with our Zero Trust Network Architecture (ZTNA) principles, ensuring access is continuously verified, minimises privileges, and follows least privilege access principles.
This policy applies to all employees, contractors, vendors, and third parties who access Vaxa’s IT systems, applications, or data.
| Role | Responsibility |
|---|---|
| CTO | Oversees IAM strategy, reviews high-risk access requests, and ensures policy compliance. |
| Information Security Group | Implements IAM controls, reviews access logs, manages identity lifecycle, and enforces access revocation policies. |
| System Owners | Approve and review access requests, ensuring they align with least privilege principles. |
| HR | Ensures onboarding and offboarding processes align with identity lifecycle management. |
| All Users | Adhere to IAM policies, use only approved authentication mechanisms, and report any suspicious activity. |
Any exceptions to this policy require documented approval from the CTO and Information Security Group. Exceptions must be risk-assessed and periodically reviewed.
The purpose of this policy is to establish comprehensive guidelines and procedures for employment screening in accordance with AS 4811:2022.
This policy aims to ensure that all potential and existing employees, contractors, and volunteers are appropriately screened and monitored based on their level of access to sensitive information or their position within the organisation. It is designed to mitigate risks such as fraud, theft, or reputational damage while promoting a fair and transparent process across all levels of employment.
This policy applies to all potential and current employees of the organisation, including full-time, part-time, and temporary staff, as well as contractors and volunteers. It also extends to ongoing employment screening, periodic re-screening, and continuous monitoring of current employees, particularly those in sensitive positions.
Additionally, it applies to external contractors in certain circumstances.
The person undertaking the employment administrative tasks is responsible for ensuring that all potential employees undergo the appropriate screening checks in accordance with this policy.
Potential and current employees, contractors, and volunteers each bring about a different level of risk. Our risk-based approach classifies employees into four Levels, which in turn determines the appropriate level of screening/vetting/due diligence.
These levels are:
Records of all employment screening checks must be kept for five years from the date of the last action taken on the records. Record shall be securely disposed of after this time.
This applies to both potential and current employees, including any re-screening checks conducted during ongoing employment. The organisation shall ensure compliance with data privacy laws and secure storage practices for these records.
Screening checks shall be conducted using an approved third-party supplier. Where possible, the organisation shall not store personal information of potential or current employees, in line with the organisation’s information security management policies. Instead, the organisation will store only the outcome of the screening provided by the third-party supplier.
Offers of employment (or in the case of a contractor, engagement) shall:
Candidates must be informed of the screening process and the types of checks that will be conducted as part of the job offer process. This ensures transparency and allows candidates to provide accurate and complete information, facilitating a smooth and efficient screening process.
The following screening checks shall be conducted for all potential and current employees (Level 2, Level 3, and Level 4) prior to employment or as part of ongoing employment monitoring:
Periodic re-screening of current employees, particularly those in Level 3 and Level 4 positions, is required to ensure continued suitability for their roles. This includes re-screening at intervals determined by the organisation based on the risk profile of the position.
The following additional screening checks may be conducted depending on the assessed screening level:
The organisation is committed to ensuring that the employment screening process is conducted in a manner that is respectful and inclusive of all cultural, religious, and personal backgrounds. The following considerations must be taken into account:
See also our Environmental and Cultural Heritage Policy.
Vaxa recognises the importance of maintaining strong, transparent relationships with third-party suppliers we use that are responsible for conducting employment screening checks.
These vendors, like all Vaxa vendors, are subject to our Supplier Security Policy. These vendors shall be assessed under that policy.
In addition, these vendors should be subject to the following additional requirements:
Any violation of this policy may result in disciplinary action, up to and including termination of employment.
For all personnel, the Information Security Group shall be responsible for monitoring compliance with this policy.
For personnel in scope of DISP, then the DISP Security Officer shall also be responsible for monitoring compliance with this policy.
Overview of why the controlled document is being implemented.
Who or what does the controlled document apply to.
Who is responsible for doing what. This should refer to departments or roles instead of specific individuals.
| Role | Responsibility |
|---|---|
| [Role] | [Responsibility] |
The details! Detail the specific policy, procedure, or process. This section can include step-by-step instructions or rules that must be followed.
Define how exceptions to the controlled document will be tracked.
Define how compliance with the controlled document will be monitored and what checks will be performed (where applicable).
Procedure documents should map back to a governing policy or standard, and may relate to one or more procedures or other uncontrolled documentation. Policy documents may relate to an internal or external framework or legal requirement.
This Privacy Policy outlines how Vaxa collects, uses, discloses, and manages personal and sensitive information. Our commitment is to protect the privacy of individuals and ensure compliance with the Privacy Act 1988 (Cth) and the Australian Privacy Principles (APPs). By adhering to these standards, we aim to maintain transparency and trust with our clients, partners, and employees.
This policy applies to all personal and sensitive information collected, stored, processed, or disclosed by Vaxa in the course of our data analytics, software development, solution design, program design, and advisory services. It encompasses all employees, contractors, consultants, partners, and third parties who handle personal information on our behalf.
| Role | Responsibility |
|---|---|
| CTO | Set and maintain the technical implementation of this policy across the business. |
| Privacy Officer | Monitor adherence to the Privacy Act and APPs. Provide guidance on privacy matters. Respond to inquiries and manage data breaches alongside CTO. |
| Employees and Contractors | Comply with this policy and report any privacy concerns. |
| Third Parties | Adhere to privacy obligations when handling information on our behalf. |
We collect personal information only when it is necessary for our business functions or activities. This may include:
We strive to collect information directly from individuals. When collecting from third parties, we ensure that consent has been obtained or it is otherwise permissible under the law.
Personal information is used for:
We do not disclose personal information to third parties except:
We take reasonable steps to protect personal information from misuse, interference, loss, unauthorized access, modification, or disclosure. Measures include:
These protections form part of our broader Information Security Policy.
Individuals have the right to access and correct their personal information held by us. Requests should be directed to our Privacy Officer and will be addressed within a reasonable time frame.
We may transfer personal information overseas only if:
Where practicable, individuals may interact with us anonymously or under a pseudonym. However, certain services may require identification.
We will not use personal information for direct marketing without consent. Individuals can opt-out of marketing communications at any time.
In the event of a data breach likely to result in serious harm, we will notify affected individuals and the Office of the Australian Information Commissioner (OAIC) as required under the Notifiable Data Breaches scheme.
Complaints regarding privacy breaches can be submitted to our Privacy Officer via security@vaxagroup.com. We will investigate and respond promptly, in accordance with our obligations and this policy.
Any exceptions to this policy must be approved by the Managing Director and the Privacy Officer. All exceptions will be documented, including the rationale and duration.
We are committed to regular monitoring and review of our privacy practices to ensure compliance. Actions include:
Non-compliance may result in disciplinary action, including termination of employment or contracts.
This policy ensures that privileged access to systems, applications, and data is securely managed, controlled, and monitored. It aims to minimise security risks associated with privileged accounts, ensuring they are only granted when necessary and for a limited duration.
This policy applies to all employees, contractors, and third parties who require privileged access to Vaxa’s systems, applications, and data.
| Role | Responsibility |
|---|---|
| Chief Technology Officer (CTO) | Reviews and approves privileged access requests based on necessity and security considerations. Ensures compliance with this policy. |
| Information Security Group | Implements security controls, monitors privileged access events, and manages privileged accounts. |
| System Administrators | Configure and enforce privileged access controls. Manage privileged account lifecycle, including periodic revalidation. |
| Privileged Users | Use privileged accounts strictly for administrative duties. Adhere to access controls, separation of duties, and security best practices. |
Privileged access is defined as access to systems, applications, and data that allows users to perform administrative or configuration tasks that could impact the security, integrity, or availability of the environment. This includes, but is not limited to, access to system settings, user account management, data manipulation, and configuration changes. This is on servers, within applications, across databases, cloud environments, network devices, and local machines.
Exceptions to this policy must be formally requested, documented, and approved by the CTO. Exceptions must include a risk assessment and mitigation strategy.
The Information Security Group will:
This policy allows for the reporting and disclosure of concerns and vulnerabilities discovered by external entities, as well as anonymous reporting of information security policy violations by internal entities. These vulnerabilities or concerns usually relate to security, confidentiality, integrity, and availability failures, incidents, or concerns.
Vaxa’s Responsible Disclosure Policy applies to all Vaxa platforms and information security infrastructure. It applies to all employees and all third parties.
| Role | Responsibility |
|---|---|
| Security and Compliance Team | Review and assess vulnerability reports submitted to the security+vulnerability@vaxagroup.com inbox. Initiate the resolution process, communicate with the reporter, and track remediation efforts. Ensure compliance with legal and ethical standards throughout the process. |
| Product Security Team | Manage receipt and triage of vulnerability reports. Prioritise and assign resources for resolution. Maintain communication with external entities providing vulnerability reports, and acknowledge submissions within 2 business days. Provide public credit to the reporter upon successful resolution. |
| Managing Director/Directors | Act as the point of contact for individuals reporting retaliation, reprisal, or harassment related to whistleblowing. Ensure any instances of retaliation are addressed promptly and appropriately. Support and protect the whistleblower’s rights during an investigation. |
| Neutral Third Party (if necessary) | Assist in resolving communication issues or challenges related to the handling of a vulnerability. Facilitate communication between Vaxa and external entities if conflicts arise. |
Vaxa will not engage in legal action against individuals who submit vulnerability reports through our Vulnerability Reporting inbox. We openly accept reports for all Vaxa products and services. We agree not to pursue legal action against individuals who, in good faith:
To submit a vulnerability report to Vaxa’s Product Security Team, please utilise the following email: security+vulnerability@vaxagroup.com.
A basic version of our responsible disclosure policy is also made available in the security.txt format on each of the Vaxa brands’ public-facing websites at /.well_known/security.txt.
What we would like to see from you:
What you can expect from Vaxa:
If we are unable to resolve communication issues or other problems, Vaxa may bring in a neutral third party to assist in determining how best to handle the vulnerability.
To anonymously report an information security program violation or a violation of related laws and regulations, you can:
security+whistleblow@vaxagroup.com.We encourage you to use a temporary email service to protect your identity if desired.
What we expect from you:
What you can expect from Vaxa:
Any exceptions to this policy must be approved by the Security and Compliance Team and properly documented.
Compliance with this policy will be ensured by:
Vaxa deploys control activities through policies and standards that establish what is expected and procedures that put policies and standards into action.
The purpose of this procedure is to ensure that there is consistency in developing and maintaining controlled documents at Vaxa utilizing a hierarchal approach for managing legal and regulatory requirements.
There are two types of documentation at Vaxa:
Everyone at Vaxa is welcomed and encouraged to submit a pull request to create or suggest changes to controlled documents at any time.
This procedure applies to all controlled documents developed in support of Vaxa’s statutory, regulatory and contractual requirements.
Uncontrolled documents are dynamic in nature and not in scope of this procedure.
| Role | Responsibility |
|---|---|
| Security Compliance Team | Responsible for implementing and maintaining Security Policies and oversight of supporting standards and procedures as part of ongoing continuous control monitoring |
| Security Governance Team | Responsible for conducting annual controlled documents review |
| Security Assurance Management (Code Owners) | Responsible for approving changes to this procedure |
| Control Owners | Responsible for defining and implementing procedures to support Security policies and standards |
At minimum, controlled documents should cover the following key topic areas:
Creation of, or changes to, controlled documents must be approved by management or a formally designated representative of the owning department as defined in the CODEOWNERS file prior to publishing.
Controlled documents require a handbook frontmatter attribute for controlled documents to classify them. This attribute also renders a warning header.
Controlled documents are required to be reviewed and approved on at least an annual basis. Controlled documents may be updated ad-hoc as required by business operations. Changes must be approved by a code owner of the controlled document prior to merge.
Reviewers of controlled documents are required to
An accurate list of current controlled documents can be found here.
Exceptions to controlled documents must be tracked and approved by the controlled document approver(s) via an auditable format. An exception process should be defined in each controlled document.
In the event a team member requires a deviation from the standard course of business or otherwise allowed by policy, the Requestor must submit a Policy Exception Request to the Vaxa Security Compliance team, which contains, at a minimum, the following elements:
Exception request approval requirements are documented within the issue template. The requester should tag the appropriate individuals who are required to provide an approval per the approval matrix.
If the business wants to appeal an approval decision, such appeal will be sent to Legal at legal@Vaxa.com. Legal will draft an opinion as to the proposed risks to the company if the deviation were to be granted. Legal’s opinion will be forwarded to the CEO and CFO for final disposition.
Any deviation approval must:
This procedure defines how privileged access requests are evaluated and approved beyond the access granted to a specific job function, ensuring access is granted based on business necessity and security best practices. This does not cover ordinary access granted to users via their job function as this is automatically granted based on their role.
Applies to all requests for privileged access to systems, applications, and data within Vaxa Analytics.
| Role | Responsibility |
|---|---|
| Chief Technology Officer (CTO) | Approves or denies privileged access requests. Ensures appropriate restrictions and timeouts are applied. |
| Information Security Group | Assesses security risks of access requests. Implements controls and logs all privileged access decisions. |
| Requester | Submits access requests with justification. Adheres to all privileged access controls and security requirements. |
The CTO, with input from the Information Security Group, assesses each request based on:
Exceptions must be submitted in writing and approved by the CTO with documented justification. All exceptions are subject to periodic review.
The ISG has a responsibility to oversee and advise on the organisation’s information security strategy and practices in alignment with its business objectives.
The ISG can be most simply reached by emailing security@vaxagroup.com
Refer to the ISG Terms of Reference to see how these members are selected and what their responsibilities are.
Current people fulfilling these roles are:
The ISG is responsible for overseeing and advising on the organisation’s information security strategy and practices in alignment with its business objectives.
The Defence Industry Security Program (DISP) is an Australian Government membership program designed to help companies meet the necessary security requirements when working with the Department of Defence or handling sensitive Defence information. Its underpinned by the Defence Security Principles Framework - Principle 16, Control 16.1, Defence Industry Security.
It is essentially security vetting for Australian entities.
The purpose of DISP is to:
DISP has several levels of accreditation, and we are currently focused on Entry Level compliance, which covers the foundational security requirements for working with Defence-related contracts and information.
DISP covers four core areas (“security domains”):
Our commitment to DISP compliance helps us protect Defence information, meet government standards, and ensure trust with our Defence partners.
Regardless of your role at Vaxa, DISP compliance is essential because it affects how we all handle sensitive information and protect the security of our workplace–even if this is not Defence-related information. It’s forms part of our standard that we strive to achieve across our entire organisation, you included.
Here’s why it matters:
In short, DISP compliance means keeping our workplace secure, maintaining trust with our clients, and contributing to the success and growth of Vaxa. Every action you take to support security helps ensure we meet these standards.
Our compliance strategy is built on four key pillars:
We leverage industry best practices, a proactive risk management approach, and strict adherence to security protocols to protect Defence information and our interests.
Our Risk Management Policy drives our compliance efforts by focusing on:
By integrating risk management with DISP requirements, we ensure that threats are addressed proactively and compliance is maintained at all times.
Our compliance relies on a comprehensive set of policies, endorsed at the highest level and implemented in our day-to-day. These are designed to meet not only DISP Entry Level standards, but the requirements of Essential Eight (now) and ISO27001 (in future).
These include:
| Policy | Description |
|---|---|
| Information Security Policy | Defines the overarching framework for protecting sensitive information. |
| Access Control Policy | Manages access to systems and information based on the principle of least privilege, supported by multi-factor authentication (MFA). |
| Incident Response Policy | Provides a structured approach for responding to security incidents, including breaches of Defence information. |
| Personnel Security Policy | Details security clearance and vetting processes for all personnel handling sensitive Defence information. |
Each policy is regularly reviewed on a set cadence to stay aligned with changes in DISP requirements and the evolving threat landscape.
Every Vaxa employee should consider themselves playing a key role in ensuring compliance with DISP standards, whether they’re technically in scope or not. This includes you.
To support them, we have a robust training and awareness program that covers:
By embedding security awareness in Vaxa’s culture, we ensure that every employee is equipped to maintain DISP compliance.
We take a proactive approach to monitoring and improving our compliance processes through:
Our continuous improvement framework ensures that we not only meet current DISP Entry Level requirements but also evolve our compliance measures in line with changing Defence, industry, and regulatory needs.
While our primary focus in this Handbook section is obviously our DISP compliance, Vaxa recognises the value and need to comply with other frameworks including ACSC’s Essential Eight and ISO27001.
To comply with these frameworks at once, Vaxa’s approach to each of those frameworks must recognise how these frameworks would interact.
Here is how we see those two frameworks interacting with DISP:
This integrated approach ensures that we meet a high standard of security across all aspects of our operations, from Defence information handling, to client information handling, to how we engage 3rd party suppliers—-if we’re in business, we’re in the business of security.
It is a requirement of all Vaxa staff to:
For questions, concerns, or more detailed information about our compliance strategy, please contact the DISP Team.
This policy outlines Vaxa’s approach to maintaining compliance under the Defence Industry Security Program (DISP) and the requirements for safeguarding DISP-scoped information. It’s supplementary to the organanisation’s overarching Information Security Policy. This set of Security Policy and Plans are designed for Vaxa’s primary (and only) facility located in Brisbane, Australia.
The DISP Security Policy applies to all Vaxa personnel who handle DISP-scoped information or systems, including temporary workers and external contractors.
| Role | Responsibility |
|---|---|
| DISP Chief Security Officer | Oversees the implementation of DISP security controls and ensures compliance with DISP requirements. |
| DISP Security Officer | Acts as the primary point of contact for DISP-related matters and liaises with Defence on operational matters. |
| CTO | Ensures DISP requirements are integrated into the organisation’s technology strategy and architecture. |
The Chief Security Officer (CSO) must be a member of the organisation’s board of directors (or similar governing body), executive personnel, general partner, or senior management official with the ability to implement policy and direct resources. They must be able to obtain and maintain a minimum Baseline Security Clearance.
Todd Crowley is Vaxa’s CSO, and is responsible for oversight of, and responsibility for, security arrangements and championing a security culture in Vaxa.
The CSO is accountable for ensuring:
The SO is responsible for the development and implementation of the security policies and plans and acts on behalf of the CSO. The SO must be an Australian citizen and be able to obtain and maintain a Personnel Security Clearance at the Baseline level or above, as appropriate with the level of DISP membership.
Curtis West as Vaxa’s SO is responsible for:
DISP has four key pillars:
This policy document is structured to address each of these pillars in turn.
Vaxa maintains Security Policies and Plans (SPP) to guide personnel on their security responsibilities. The SO is responsible for developing and maintaining these policies.
All Vaxa employees shall review the SPP annually. New employees shall review it as part of their security briefing.
Vaxa personnel working at Defence establishments shall comply with all applicable local security instructions.
The Security Register (SR) is maintained by the SO and shall capture all security-related matters relevant to Vaxa.
The SR is a living document and shall be updated regularly. It includes records on governance, physical security, personnel security, security education and training, information security, and security incidents.
Vaxa’s Designated Security Assessed Positions (DSAP) register shall be maintained within the Security Register.
Vaxa shall report any potential or actual change in FOCI status.
The SO shall submit FOCI changes using the AE250-1 webform, available on the DISP website or DISP Portal, to DISP.submit@defence.gov.au.
The ASR is a declaration by the CSO, under the authority of the Directors, that Vaxa continues to meet the eligibility and suitability requirements of DISP.
The SO shall ensure the ASR is submitted to Defence annually. The ASR form is located on the DISP website or DISP Portal and shall be submitted to DISP.submit@defence.gov.au.
Copies of the ASR shall be retained in DISP SharePoint under the Annual Security Report document library.
Vaxa shall maintain Security Risk Assessments (SRA) to identify and manage risks. A Defence-specific SRA shall be maintained for any Defence contract Vaxa is engaged in.
Completed SRAs shall be retained in DISP SharePoint under the Security Risk Assessment document library.
All Vaxa employees shall complete annual security awareness training. The SO is responsible for ensuring training completion and maintaining records.
Defence may require Vaxa personnel to complete additional security awareness training via Campus Anywhere.
The SO shall ensure all Vaxa employees receive Insider Threat awareness training.
All security-significant contact with foreign representatives, extremist groups, criminal organisations, or politically motivated entities shall be reported.
Employees shall report any such contact immediately using Form XP168 - Report of Security Contact Concern, submitted to the Security Incident Centre at security.incidentcentre@defence.gov.au.
XP168 forms are available on the Defence Security Incident Reporting System.
Vaxa personnel shall report all security incidents in accordance with DSPF Principle 77.
The SO shall submit security incidents via Form XP188 - Security Incident Report through the DSPF system. If DSPF access is unavailable, incidents shall be reported via email to security.incidentcentre@defence.gov.au.
The SO shall complete the Introduction to DISP training course.
Curtis West, as SO for Vaxa, completed this training on <date>. Renewal is due <date>.
The DISP Portal provides access to security resources via the Defence Online Security Dashboard (DOSD).
The SO has DISP Portal access. Additional access requests shall be submitted using Form SCS 001 to dsvs.awareness@defence.gov.au.
A close of business security check shall be conducted daily to secure classified materials and ensure physical security zones are locked.
The SO shall ensure all personnel are familiar with close of business procedures.
Defence may conduct random security checks on DISP members, reviewing security policies, personnel, and physical security measures.
The SO shall also conduct internal security checks to ensure classified materials are protected and personnel comply with security protocols.
All random security checks shall be recorded in the Security Register.
In an emergency, security-cleared personnel shall:
Emergency responders may require escorted access by security-cleared personnel.
Vaxa maintains a Personnel Screening Policy that complies with AS 4811:2022.
The policy is available in our handbook at Personnel Screening Policy.
The SO shall record all granted security clearances in the Security Register.
All security-cleared Vaxa personnel shall understand and comply with their ongoing security responsibilities.
Further information, including change-of-circumstances reporting, is available on the AGSVA website.
When an employee leaves Vaxa, Defence manages the security clearance after-care process.
The SO shall update the Security Register as required.
Access passes are required to enter Vaxa’s offices at Level 54, 111 Eagle Street.
Vaxa personnel shall:
Electronic access cards are considered security keys and shall be recorded in the Security Register.
The SO shall conduct an annual audit to account for all Vaxa access cards.
Personnel visiting Defence sites shall wear their Defence Visitor or Defence Access pass visibly at all times.
Vaxa personnel engaged under a Defence contract shall:
Vaxa personnel engaged under a Defence contract shall not make false employment declarations. If required, they shall list their status as “contractor”.
Vaxa personnel travelling overseas shall follow the overseas travel briefing process to ensure security awareness and compliance.
| Stage | Responsible Party | Description |
|---|---|---|
| 1 | Person Travelling | Complete Form AB644 – Overseas Travel Briefing and Debriefing for personal or official travel. Submit the form to the SO as soon as travel is planned. |
| 2 | Security Officer | Conduct an overseas travel briefing with the traveller. Complete the pre-travel Security Officer section of Form AB644. Confirm that the traveller has completed any required compartment briefings. |
| 3 | Person Travelling | Obtain travel advice from the DFAT Smartraveller website for all countries being visited or transited through. |
| 4 | Security Officer | Record travel details in the Security Register. Retain Form AB644 (private travel) or Form AA062 (official travel). Conduct a detailed security briefing if: 1) The traveller has a high-level security clearance. 2) DFAT has issued a Consular Travel Advisory Notice or Bulletin for any country on the itinerary. 3) The traveller is carrying a Defence or DISP-issued laptop or Portable Electronic Device (PED) that is not protected by a Laissez-Passer. |
Upon returning from overseas travel, Vaxa personnel shall follow the debriefing process to ensure security compliance and report any security concerns.
| Stage | Responsible Party | Description |
|---|---|---|
| 1 | Person Travelling | Complete the debriefing section of Form AB644 (private or official) with the SO. |
| 2 | Security Officer | Conduct an initial debriefing using the debriefing section of Form AB644. |
| 3 | Person Travelling | Submit any required online forms, including: - XP188 – Defence Security Report (if applicable). |
| 4 | Security Officer | Retain copies of Form AB644 and XP188 (if applicable) in the Security Register. |
Visitors to Vaxa, beyond the public areas of in the office (Zone 1, i.e. the public lounge and kitchen), shall not be granted access to classified material unless their identity, security clearance, and “Need to Know” have been confirmed. They must also sign in at reception upon arrival and be escorted by a security-cleared Vaxa employee at all times if entering secure areas.
The escorting officer is responsible for ensuring the visitor leaves the facility upon conclusion of their visit.
Vaxa’s premises include a Zone 1 foyer on the ground floor and the reception/shared areas on Level 54. The main office area with our workstations is classified as a Zone 2 restricted employee access area.
All official and classified material shall be stored in approved security containers. Access to security containers shall be restricted to approved custodians.
The SO shall maintain records of all security containers, including their locations and custodians, in the Security Register (SR).
The SO shall maintain a register of all facility keys, security containers, combinations, and custodians. Each security container must have an appointed custodian responsible for its contents and access control.
Security keys shall only be issued to authorised and security-cleared personnel.
Keys to classified material containers shall be treated with the same level of classification as the material stored inside.
The SO shall maintain a key register. Duplicate keys shall not be made unless explicitly authorised by the SO and recorded in the register.
The SO shall conduct a facility key audit at least every six months. Loss or compromise of a security key must be reported in accordance with DSPF Principle 77 - Security Incidents and Investigations.
If a security container is compromised or suspected to be compromised, the SO must be informed immediately.
Vaxa, as a DISP member with Information and Cyber Security Entry Level membership, is required to meet at least one of the following ICT network accreditation standards:
Vaxa has completed a self-assessment and meets the ASD Essential 8 Maturity Level 2 requirements.
The Security Officer is responsible for maintaining system-specific Standard Operating Procedures (SOPs) applicable to Vaxa’s ICT systems. These are available in the Handbook under the Security heading. Employees are responsible for adhering to all relevant policies, plans, and procedures for the systems they use. Specifically, they must ensure that information provided in system or network access requests is accurate, secure unattended equipment appropriately, follow a clear desk and clear screen policy, protect their authentication credentials, and report any security incidents to the Security Officer as soon as they become aware of them.
The IT Security Manager (ITSM) is responsible for maintaining a ‘known good’ baseline of Vaxa’s system and network. This baseline aids in detecting and recovering from any incident that affects system integrity.
The ITSM is also responsible for implementing logical security controls in line with the DSPF, ISM, and ASD Strategies to Mitigate Cyber Security Incidents, ensuring that Vaxa’s systems remain protected against malicious code.
Vaxa’s ICT systems shall be monitored in accordance with its established Standard Operating Procedures (SOPs).
The ITSM is responsible for implementing availability controls to mitigate identified risks, in line with DSPF Principle 10.1 – Classification and Protection of Official Information. Backup and restore processes shall be conducted as per Standard Operating Procedures, see our Backup Policy.
Defence official information is classified according to the Australian Government Security Classification System (AGSCS) and must be protected to prevent unauthorised access or disclosure. Access is strictly limited to those with an appropriate security clearance and a need-to-know.
Vaxa personnel handling classified material must ensure that it is not subject to deliberate or casual inspection by unauthorised individuals. When not in use or under direct supervision, all classified material must be stored in an approved security container.
Protective markings assigned to official information indicate the level of protection required during use, storage, transmission, transfer, and disposal. The correct application of protective markings is detailed in DSPF Principle 10 – Classification and Protection of Classified Information.
Our implementation is detailed in our Data Classification Policy.
Protective Security Policy Framework (PSPF) provides the appropriate controls for the Australian Government to protect its people, information and assets at home and overseas. The PSPF can be found at: https://www.protectivesecurity.gov.au/Pages/default.aspx
Defence Security Principles Framework: Defence Security Principles Framework (DSPF) is available from the SO and provides information on security requirements which are specific to Defence and DISP members. The DSPF can be found on the DS&VS website and DISP Portal.
Australian Government Information Security Manual: The Australian Government Information Security Manual (ISM) is the standard which governs the security of government Information Communications Technology (ICT) systems and complements the PSPF. The ISM can be found at https://www.asd.gov.au/infosec/ism
A trusted insider is any current or former employee or contractor who has legitimate access to either Vaxa or our client’s facilities and information. With this access, a trusted insider could pose a security risk by intentionally or inadvertently compromising operations.
Some insiders deliberately seek to harm Defence by leaking classified information, sabotaging assets, or granting unauthorised access. Others may pose a risk through careless security practices, failing to follow procedures and unintentionally exposing sensitive information.
External threat groups may also target trusted insiders, attempting to gain access to valuable information, weapons, or assets. Insiders can be manipulated, coerced, or influenced by foreign or domestic threats—including media organisations seeking unauthorised disclosures. Only authorised personnel may engage with the media.
A trusted insider threat can take many forms, including:
The best defence against insider threats is awareness and vigilance. Every industry professional has a responsibility to uphold security standards and report concerning behaviours.
Signs that a colleague may pose a security risk include:
If you notice any of these signs, take a moment to check in with the person. A simple conversation could help them and prevent a serious security issue. If the behaviour raises a legitimate concern, report it immediately to our Security Officer. Ignoring security risks could endanger your colleagues, property, or even national security.
This is not the time to think, “She’ll be right, mate”, or “It’s un-Australian to dob in a mate.” Security is a shared responsibility, and reporting concerns is the right thing to do.
If you believe someone may be a trusted insider risk, take action by following these steps:
For any security-related questions or concerns, contact:
disp@vaxagroup.comsecurity.incidentcentre@defence.gov.au | Phone: 02 6266 3331Always treat fellow employees, clients, and suppliers with the utmost respect and courtesy. Interactions should be friendly, professional, and focused on excellent service.
Engaging in any of the following actions may result in disciplinary measures, including reprimand, warning, suspension, or dismissal.
Examples of things you should consider to remain compliant with the law and Vaxa’s policies include:
Reporting of any breaches or concerns in any shape are encouraged. Refer to our Responsible Disclosure Policy for more information.
Avoid any interests, influences, or relationships that might conflict—or appear to conflict—with the best interests of Vaxa or our clients. If your loyalty could be divided, disclose the situation promptly to your manager and remove yourself from any related decision-making processes.
Refer to the Conflict of Interest Policy for more information.
The purpose of this Conflict of Interest Policy is to ensure that all employees of Vaxa act in the best interests of both the company and our clients. This policy aims to prevent situations where personal interests could interfere with professional duties and responsibilities, thereby providing assurance to our clients that we diligently and transparently manage potential conflicts on their behalf.
This policy applies to all employees, contractors, consultants, officers, and directors of Vaxa, covering all interactions with clients, suppliers, competitors, and other stakeholders.
| Role | Responsibility |
|---|---|
| Employees | Disclose any actual or potential conflicts of interest promptly. Avoid participating in decisions related to the conflict. Ensure client interests are not compromised. |
| Managers | Receive conflict disclosures, provide guidance, and implement measures to mitigate conflicts. Communicate with clients as necessary to assure them that conflicts are managed appropriately. |
| HR | Maintain records of disclosures, monitor compliance, provide training on conflict of interest matters, and support transparency with clients. |
| Senior Management | Ensure systems are in place to manage conflicts effectively and provide clients with assurance regarding our conflict management practices. |
All employees must avoid any interests, activities, or relationships that conflict—or appear to conflict—with the best interests of Vaxa and its clients. The following guidelines must be followed to ensure our clients can trust in our integrity and the impartiality of our services:
Disclosure of conflicts:
Avoidance of participation:
Client interests:
Examples of potential conflicts:
Guidelines for Gifts and Entertainment:
Conflict resolution:
Client communication:
Any exceptions to this policy must be approved in writing by the Managing Director. Requests for exceptions should include a full explanation of the circumstances, justification, and an assessment of potential impacts on clients.
Monitoring:
Non-Compliance:
Reporting Violations:
Client audits:
This policy outlines Vaxa’s commitment to ensuring, to the best of our ability, that there is no modern slavery in any part of our business operations or supply chain. We are dedicated to acting ethically and with integrity in all business dealings and relationships, in compliance with the Modern Slavery Act 2018 (Cth).
This policy applies to all employees, contractors, suppliers, service providers, and any other parties working on behalf of Vaxa.
| Role | Responsibility |
|---|---|
| Management | Implement anti-slavery measures and ensure legislative compliance. Include anti-slavery clauses in contracts and assess supplier compliance. |
| Employees | Report any concerns or suspicions regarding modern slavery practices. |
We are committed to:
Under the Modern Slavery Act 2018 (Cth) ‘Act’, we are not required to publish a Modern Slavery Statement as we have an annual consolidated revenue of less than $100 million. However, we are committed to ensuring that modern slavery does not occur within our operations or supply chain.
The term ‘modern slavery’ describes situations where coercion, threats or deception are used to exploit victims and undermine their freedom. Coercion, threats and deception can be explicit or implicit.
The Act defines modern slavery as including eight types of serious exploitation; trafficking in persons, slavery, servitude, forced labour, forced marriage, debt bondage, the worst forms of child labour and deceptive recruiting for labour or services.
The worst forms of child labour means extreme forms of child labour that involve the serious exploitation of children, including through enslavement or exposure to dangerous work. The worst forms of child labour does not mean all child work.
Under Australian law, modern slavery is defined in the Act. In the event of any inconsistency between this policy and the Act, the Act will prevail.
No exceptions to this policy are permitted.
We will ensure compliance by:
This policy outlines Vaxa’s commitment to clearly communicate environmental and cultural heritage expectations, meet legal requirements, and progress beyond compliance towards innovation and excellence. It aims to drive continual improvement in managing matters affecting the environment and cultural heritage.
This policy applies to Vaxa, its officers, employees, contractors (where applicable), and any other personnel notified that this policy applies to them.
| Role | Responsibility |
|---|---|
| Management | Implement and uphold the policy, allocate resources, and set objectives and targets. |
| Employees | Adhere to policies, understand and manage environmental and cultural heritage risks. |
| Contractors | Comply with Vaxa’s environmental and cultural heritage policies and procedures. |
Vaxa is committed to:
Vaxa personnel should:
Any exceptions to this policy must be approved by senior management and properly documented.
Compliance with this policy will be ensured by:
The purpose of this procedure is to outline the steps to be followed when offboarding a contractor from Vaxa’s systems and applications. It ensures that the offboarding process is conducted securely, efficiently, and in compliance with Vaxa’s policies and legal requirements.
This procedure applies to all contractors engaged by Vaxa, including temporary staff, consultants, and third-party vendors. It covers the steps to be taken by the IT team and the Onboarding Lead (or designated manager) to remove access to Vaxa’s systems and applications when a contractor’s engagement ends.
| Role | Responsibility |
|---|---|
| Contractor | Cooperate with the offboarding process and return any Vaxa-owned assets. |
| HR or Legal | Inform the IT team and Onboarding Lead of the contractor’s end date and provide any necessary documentation. |
| Onboarding Lead | Initiate the offboarding process and ensure all steps are completed. |
| IT | Disable access to M365, revoke session tokens, and remove access from other systems. |
Important: Offboarding must be initiated as soon as the contractor’s engagement ends, or as directed by HR or Legal. The Onboarding Lead (or designated manager) is responsible for initiating this process and ensuring all offboarding steps are completed, but will be supported by the IT team.
Cloudflare Access Portal:
Productive (Project Management Tool):
Client Sites and Third-Party Services:
The contractor may be notified with an email to their personal email, similar to the following:
Subject: Vaxa Offboarding Notification
Dear [Contractor Name],
This email is to confirm that your access to Vaxa’s systems and applications has been disabled in line with the conclusion of your engagement. If you have any questions or require further information, please contact [Onboarding Lead’s Name] at [Onboarding Lead’s Email Address].
Thank you for cooperation.
Best regards, [Onboarding Lead’s Name]
The Onboarding Lead or IT Manager should periodically review the offboarding process to ensure all steps are followed consistently. Identify any gaps or risks and update this procedure as needed.
If a contractor requires partial offboarding (e.g. retaining access to certain systems for a defined period), ensure it is documented by the Onboarding Lead. Any deviation from this process must be approved by HR or Legal and recorded for audit purposes.
Contractors may be engaged by Vaxa to provide services that are not part of the core business. This procedure sets out the steps to onboard a contractor at Vaxa, including the documentation required and the process for setting up access to systems and facilities. This is important to ensure we’re consistently implementing requirements/controls placed upon contractors e.g. under our Security Policy.
The scope of this procedure is limited to contractors engaged by Vaxa, usually on a day-rate or similar arrangement. It doesn’t include employees or vendors providing a product. It also doesn’t include the accounting or payment process for contractors e.g. setup in Productive/Xero etc.
| Role | Responsibility |
|---|---|
| Contractor | Provide the required documentation to complete the onboarding process, and adopt the required controls placed upon them by Vaxa |
| Onboarding Lead | Ensure the contractor provides all required information and provide this information to IT for setup. |
| IT | Set up the contractor in the required systems and provide access to the required facilities. |
| Legal | Issue the contract to the contractor and ensure it is signed and returned in accordance with the organisational requirements, and requirements provided by the Onboarding Lead |
A suitable contractor must be found; the process for finding and engaging a contractor is outside the scope of this procedure. However, in selecting a suitable contractor, one must consider:
Consider whether an NDA is required prior to sharing any sensitive information with the contractor regarding the job.
You should get verbal approval from the contractor on these matters before proceeding to the next step.
Under our Personnel Security Policy, we are implementing requirements for screening of contractors. Generally, most contractors we engage are classified as Level 1, and so have limited screening requirements.
At the time of writing this procedure, we haven’t implemented checks for Level 2 and above contractors. We endeavour to make this change soon.
The first step here is to sign contracts. To do so, we require the following information:
Provide this information the Legal team, who will issue the contract. The contract shall be sent to Vaxa’s internal signatory/witness first for vetting, and only once signed will it be sent to the contractor for signing.
Remember, signed contracts are automatically filed away into the Contract Register via the Vaxa Link integration.
The contractor must provide evidences of the required insurances.
If this was customised in the contract, then defer to the contract. Otherwise, the standard insurances required are:
Vaxa requires copies of these insurances to be provided before the contractor can commence work.
IT setup cannot commence until contracts are signed, per our Security Policy.
Once the contract is signed, Legal shall inform the IT team will be notified to set up the contractor in the required systems. The IT team will reference the contract and onboarding information to set up the contractor in the required systems.
The first step is to create a new user in M365/Entra. This will take the format of:
first.last@vaxagroup.comWe first create the account within the Admin portal:
Users , then Active UsersTemplates and select Contractor (Business Basic) or Contractor (Business Premium) depending on the level of licensing requiredAdd userGroups click Manage groupsAssign memberships button to assign access to OS_x_Contractors group at a minimum, and any other required groups.We then need to setup authentifaction for the contractor within Entra:
Users , then All Users, and click on the newly created contractor userAuthentication methods in the left-hand menu, then Add authentication methodTemporary access pass method and configure it as follows:No.Add to finalise the TAP creation.We then need to inform the contractor of their new account and how to set it up. To do so:
Subject: Setting up your Vaxa account
Hi [Contractor Name], welcome aboard.
Your Vaxa account has been setup and just requires a few final setup steps from you, stepped out in these instructions. Please note this is a time-sensitive process so please complete it as soon as possible.
Your Temporary Access Pass is available here: [Bitwarden Send Link]
Once you’ve setup your account, you can access Productive (our time tracking and project management tool) via Cloudflare Access here: vaxagroup.cloudflareaccess.com. Simply sign in with your new Vaxa account, then click the tile called Productive.
We’ve also provided you access to:
If you have any issues, please contact reach out to me directly.
Warm regards,
The contractor will receive an email with the onboarding instructions, temporary access pass, and IT’s contact details. The temporary access pass cannot be issued for more than 24 hours.
IT will assign the contractor to the OS_x_Contractors group in M365. This provides basic levels of access to SSO-linked systems, and some Sharepoint sites etc.
By being assigned to the OS_x_Contractors group, the contractor will automatically be given access to Productive. This is our project management tool, and the contractor will be able to log their time and expenses here. IT will provide instructions on how to use Productive.
Accounts in Productive are only issued upon first sign-in, so the contractor must sign in, then IT will be able to assign them to the correct projects. These instructions will be provided in the onboarding email.
The contractor will be advised of our Cloudflare Access portal for apps at vaxagroup.cloudflareaccess.com. This is where they can access other systems including Productive.
By default, the contractor will not have access to:
Some contractors may require different onboarding procedures. If this is the case, the Onboarding Lead should work with the contractor to determine the best course of action. This should be documented in the onboarding documentation.
The Onboarding Lead is responsible for ensuring this procedure is followed for each relevant contractor.
We don’t yet have artifacts in place to monitor compliance with this procedure. This is a gap we need to address.