§AAbbreviations
§1Purpose
This Information Security Policy (“Policy”) establishes the security framework and minimum controls that Hawthorn Technologies Pty Ltd (“Hawthorn Technologies”, “HTPL”, “we”, “our”) applies to protect the confidentiality, integrity, and availability of all information assets — including personally identifiable information (PII) and any data handled under applicable Australian regulatory frameworks.
The Policy exists to:
- Protect customer and consumer data entrusted to Hawthorn Technologies.
- Meet obligations under applicable data protection and privacy regulations, including the Privacy Act 1988 (Cth) and the Australian Privacy Principles (APPs).
- Meet obligations applicable to the Consumer Data Right (CDR) framework where Hawthorn Technologies operates as a CDR participant or representative.
- Provide assurance to regulators, data intermediaries, insurers, and integration partners that adequate controls are in place.
- Establish clear security responsibilities for all personnel who interact with information systems.
§2Scope and Governance
2.1 Persons Covered
This Policy applies to all persons who access, process, or support Hawthorn Technologies systems or data, including employees, contractors, consultants, and third-party service providers with access to Hawthorn Technologies systems or data.
All covered persons must read, acknowledge, and comply with this Policy as a condition of engagement. Acknowledgement is recorded at onboarding and upon each annual review.
2.2 Systems Covered
This Policy applies to all systems used to deliver Hawthorn Technologies services, including production infrastructure, development and staging environments, source code repositories and CI/CD pipelines, identity and access management systems, support tooling, monitoring and observability platforms, and any system where sensitive data or PII could appear — including logs, error reporting tools, and analytics environments.
2.3 Named Roles
- Data Governance Lead: Director, Hawthorn Technologies Pty Ltd. Responsible for data classification, privacy compliance, regulatory obligations, and this Policy.
- IT Security Lead: Designated Technical Lead, Development Partner. Responsible for infrastructure security, vulnerability management, incident response coordination, and security of the software development lifecycle.
In the event of unavailability, the Director assumes both responsibilities until a substitute is designated.
2.4 Governance and Review
This Policy is reviewed on the following schedule:
- Scheduled annual review: the first Monday of February each year, regardless of any interim reviews during the preceding 12 months.
- Triggered review: upon a significant security incident, material change to systems or data handling practices, or change in applicable regulatory requirements.
Interim triggered reviews do not reset the scheduled annual review date. The next scheduled review is 1 February 2027.
§3Data Privacy
3.1 Categories of Sensitive Records Held
| Record Category | Notes |
|---|---|
| Personally Identifiable Information (PII) | Names, addresses, phone numbers, email addresses of customers, contractors, and business partners. |
| Government identification numbers | ABNs, regulatory registration numbers, trade licence numbers. |
| National Metering Identifiers (NMI) | Property electricity connection identifiers. |
| Financial account details | Bank account details of contractors for RCTI payments. Stored encrypted. |
| Usernames and credentials | Hashed and salted via the identity provider. Plaintext credentials are never stored. |
| Payment card numbers | Not held. Hawthorn Technologies does not process, store, or transmit cardholder data. |
| Healthcare or medical records | Not held. |
| CDR energy data | Electricity account details, NMI data, consumption history, billing data, and tariff information — accessed via accredited CDR intermediary with explicit customer consent. |
3.2 Estimated Volume of Records
Hawthorn Technologies anticipates holding records for approximately 5,000–6,000 unique individuals in the first year of operation. This estimate is reviewed annually.
3.3 Payment Card Industry (PCI DSS) Position
Hawthorn Technologies does not process, store, or transmit cardholder data. Any payment activity is handled by third-party PCI DSS-compliant payment processors via hosted checkout or equivalent redirect-based integration. Cardholder data does not enter Hawthorn Technologies systems. Hawthorn Technologies’ applicable PCI DSS scope is limited to the lightest self-assessment tier (SAQ A) covering correct configuration of the redirect integration.
3.4 Privacy Act 1988 (Cth) Compliance
Hawthorn Technologies is committed to compliance with the Privacy Act 1988 (Cth) and the 13 Australian Privacy Principles (APPs), including: a Privacy Policy reviewed by qualified Australian legal counsel; consent obtained before collection of personal information; Data Subject Access Request capability; a data deletion workflow; and Notifiable Data Breaches (NDB) scheme compliance.
§4Access Control
4.1 Least Privilege
Access to all systems and data is granted on a least-privilege basis. Access is explicitly authorised by the Director or IT Security Lead and reviewed upon role change, at least annually, and immediately upon termination — access is revoked on the same business day.
4.2 Multi-Factor Authentication (MFA)
MFA is mandatory for all accounts that can access email and identity provider systems, cloud management consoles, source code repositories, CI/CD pipelines, production systems and databases, administrative tooling, and any system that may contain sensitive data or PII.
Accepted MFA factors include authenticator apps (TOTP), hardware security keys, and SMS one-time passwords. The specific method required for a given system may be determined by the IT Security Lead based on the sensitivity of that system.
Service accounts and API credentials — including OAuth tokens used for third-party integrations — are managed via a secrets management system. OAuth refresh tokens are encrypted at rest using AES (preferred) or equivalent symmetric encryption of comparable strength, and are stored separately from application code. Encryption keys for stored tokens are held in a configuration store separate from the token store itself. OAuth tokens and other customer-identifying information are never exposed in user-facing application output and are not shared with other parties. Credentials are scoped to the minimum required permissions and rotated periodically.
4.3 Privileged Access
Privileged access is restricted to named individuals with a documented business need, subject to break-glass procedures where standing access is not warranted, logged, and reviewed at least quarterly.
§5Asset and Endpoint Security
5.1 Scope of This Section
Hawthorn Technologies operates a fully cloud-native model. The organisation does not own or operate physical servers, on-premise infrastructure, or fixed office assets. Workforce devices are limited to laptops and mobile devices used by the Director, contractors, and development partner staff to administer cloud accounts and access systems and data.
This section therefore applies to: (a) cloud accounts and tenancies operated by Hawthorn Technologies; (b) credentials and secrets used to access those accounts; and (c) end-user devices used by covered persons to administer those accounts. It does not extend to devices owned or operated by platform users, who access the platform through the application interface and are subject to the authentication and access controls in Section 4.
5.2 Cloud Account and Credential Security
Hawthorn Technologies maintains a register of all cloud accounts, tenancies, code repositories, and administrative consoles used to operate the platform. The register identifies, for each account: the service category, the named owner within Hawthorn Technologies, the persons with administrative access, and the recovery contact. The register is reviewed at least annually and upon any change in personnel.
For each account in the register the following minimum controls apply: MFA enabled on all administrative access; use of a unique, strong, password-manager-stored credential; named individual ownership (no shared logins); recovery options secured to the same standard as primary credentials; and immediate revocation of access on personnel change.
5.3 Secrets Management
API keys, OAuth client secrets, encryption keys, and other machine-to-machine credentials are stored in a dedicated secrets management facility separate from application source code and configuration. Secrets are not committed to source control under any circumstances. Access to the secrets store is logged and reviewed. Secrets are rotated periodically and immediately upon any suspected compromise or upon departure of any person who held access.
5.4 Endpoint Hygiene
Devices used by covered persons to administer Hawthorn Technologies cloud accounts or access sensitive data must meet the following baseline requirements:
- Run a vendor-supported operating system with current security patches; automatic security updates enabled where available.
- Have full-disk encryption enabled.
- Be protected by a PIN, password, or biometric lock with automatic lock on inactivity.
- Have endpoint protection (anti-malware) installed and active.
- Not be jailbroken, rooted, or otherwise have manufacturer security controls disabled.
- Use only an approved, supported web browser kept current with vendor updates.
Personally-owned devices used to administer cloud accounts must additionally have remote wipe of work-related data enabled, and must not be used to directly access production databases or infrastructure consoles. Non-compliant devices have access suspended immediately pending remediation.
§6Vulnerability and Patch Management
Hawthorn Technologies performs regular vulnerability scanning of production infrastructure and application components, including automated dependency scanning in the CI/CD pipeline and periodic infrastructure-level scans.
Patch priority: Critical (CVSS 9.0+) within 72 hours or immediate compensating controls; High (7.0–8.9) within 14 days; Medium (4.0–6.9) within 30 days; Low within 90 days. Exceptions require Director approval, are documented with compensating controls and a remediation date, and reviewed monthly.
Where a critical, high, or medium-priority vulnerability is identified by an integration partner’s security review, remediation is performed within the timeframe specified by that partner, in any case no later than 14 days from notification.
§7Security Incident Identification, Logging, and Response
7.1 Definition
A security incident is any event that has resulted in, or has the potential to result in, unauthorised access to, disclosure of, or destruction of information assets or customer data — including confirmed breaches, suspected events, and near-misses.
7.2 Minimum Logging Requirements
Logs must capture: timestamp (UTC); user or system identity; affected system and data type; nature of the action; outcome; source IP address; and detection method. Logs are retained for a minimum of 12 months in a tamper-resistant environment and reviewed at least monthly.
User credentials and data received from third-party integration platforms must never be written to application logs, error reports, analytics streams, or any other persistent log destination. Logging frameworks are configured to redact sensitive fields at the source.
7.3 Incident Response
- Triage: classify severity and determine whether sensitive data, PII, or CDR data is involved.
- Containment: limit impact and prevent further exposure.
- Partner notification: where an incident involves data held under a third-party integration agreement (including CDR, accounting, or other API integrations), notify the relevant partner within the timeframe required under that agreement — in any case within 24 hours of identification.
- Evidence preservation: preserve logs and artefacts without alteration.
- Investigation and root cause analysis.
- Regulatory notification: notify the OAIC and other relevant bodies as required under the Notifiable Data Breaches scheme and applicable regulatory frameworks.
- Remediation and post-incident review.
All incident records are retained for a minimum of 7 years.
§8Data Protection
8.1 Encryption in Transit
All data transmitted over public or untrusted networks uses TLS 1.2 or higher (TLS 1.2 with AES-256 and SHA-256 or higher is the preferred configuration). TLS 1.0 and 1.1 are prohibited on customer-facing endpoints. This applies to all customer-facing endpoints, API communications, and internal service-to-service traffic. Certificates are monitored for validity and renewed before expiry. HTTPS is enforced on all pages of all Hawthorn Technologies web applications.
8.2 Encryption at Rest
All sensitive data and PII stored by Hawthorn Technologies is encrypted at rest using AES-256 or equivalent, including databases, object storage, backups, and any logs that may contain sensitive data. Encryption keys are managed through a dedicated key management service and are not stored alongside the data they protect.
8.3 Web Application Hardening
Hawthorn Technologies web applications are configured with the following minimum hardening controls:
- Caching disabled on pages that contain sensitive data or are served over authenticated sessions, using Cache-Control values of no-cache and no-store (not private).
- HTTP TRACE and other unused HTTP methods disabled at the web server.
- All session cookies set with the Secure and HTTPOnly attributes.
- Endpoints that receive sensitive customer information or authentication tokens via URL parameters do not return HTML in the response body; they respond with an HTTP 302 redirect to prevent token leakage via the Referer header.
- Operating system, web server, and application server security patches are kept current within the timeframes set out in Section 6.
8.4 Data Retention and Secure Deletion
- Data is deleted upon consent withdrawal, consent expiry, or completion of the collection purpose — whichever occurs first.
- Deletion is performed securely (cryptographic erasure or equivalent).
- Residual backup copies are purged within 30 days of the deletion trigger.
Regulatory compliance records are subject to a mandatory 7-year immutable retention period. CDR consent-based data is subject to the shorter CDR consent period, which takes precedence.
8.5 Data Minimisation and Use Restrictions
Only data fields necessary to deliver the consented or contracted service are collected and processed. Data is not repurposed beyond the original collection purpose.
Data received via third-party integration APIs (including accounting software integrations) is used solely to provide the specific functionality disclosed to and authorised by the user. Such data must not be used for AI model training, product development, analytics, profiling, secondary marketing, or any purpose unrelated to delivering that functionality. Bulk or persistent export of integration data beyond what is strictly required to deliver the service is prohibited. Integration data is not made available to any third party, including via external API calls or any other means, except as required to deliver the consented functionality.
Hawthorn Technologies does not store credentials used by end users to access third-party systems.
§9Third-Party and Supplier Security
9.1 Vendor Assessment
Before engaging any vendor whose systems may host, process, access, or log sensitive data, Hawthorn Technologies assesses that vendor’s security posture, certifications, data residency practices, incident notification obligations, and sub-processor arrangements.
All data controlled by Hawthorn Technologies is hosted in Australia. Data residing within third-party SaaS platforms accessed via OAuth or API (such as accounting software) is subject to those platforms’ own data residency terms and is outside the scope of Hawthorn Technologies’ hosting obligations.
| Provider Category | Notes |
|---|---|
| Cloud infrastructure | Australian region mandatory for all data controlled by Hawthorn Technologies. Providers must hold recognised security certifications (ISO 27001 / SOC 2 Type II or equivalent). |
| Payment processing | PCI DSS-compliant provider required. Cardholder data does not enter Hawthorn Technologies systems. |
| Identity and access management | Must support MFA and meet applicable security standards. |
| CDR data intermediary | Must be an accredited CDR Data Recipient under the Australian CDR framework. |
| AI and machine learning services | Deployed within Australian infrastructure where possible; data handling assessed prior to engagement. Providers must be contractually prohibited from using Hawthorn Technologies data, or data Hawthorn Technologies controls on behalf of integration partners, to train or improve their own models. |
| Accounting software | Cloud-based accounting platforms — assessed prior to integration. |
| Communications (SMS / VoIP) | Assessed prior to engagement. |
| Document signing | Assessed prior to engagement; audit trails and document integrity required. |
| Development partner | Bound by confidentiality and security obligations under the development agreement. |
A written list of sub-processors and third parties with access to Hawthorn Technologies data is maintained and made available to integration partners upon request.
9.2 Contractual Requirements
All vendors with access to sensitive data are contractually required to: implement appropriate security controls; restrict access to authorised personnel on a least-privilege basis; notify Hawthorn Technologies within 24 hours of any incident involving Hawthorn Technologies data; delete or return data on termination; not sub-process sensitive data without prior written approval; and comply with applicable Australian privacy laws.
9.3 Partner Audit Rights and Security Assessments
Hawthorn Technologies acknowledges that integration platform partners may, under their respective developer program terms, conduct periodic compliance audits, request system vulnerability scan results, require completion of a security affidavit, or require participation in security assessments.
Where a partner so requests, Hawthorn Technologies will: permit the partner to conduct a system vulnerability scan within 2 weeks of the request, or provide reputable scan results from a scan conducted within the preceding 12 months; complete a security affidavit within 2 weeks of the request; and promptly remediate any issues identified, with critical, high, or medium-priority findings remediated within the timeframe specified by the partner and in any case no later than 14 days from notification.
9.4 Ongoing Review
Vendor assessments are reviewed at least annually or upon material change to services, a security incident involving the vendor, or significant change in ownership or accreditation. Hawthorn Technologies does not waive its right of recourse against any third-party provider.
§10Business Continuity and Disaster Recovery
10.1 Business Continuity
Hawthorn Technologies maintains a Business Continuity Plan addressing operational continuity during key failure scenarios. All application infrastructure is defined as Infrastructure-as-Code (IaC) in version-controlled repositories. The platform is designed for high availability within the primary cloud region with multi-availability-zone deployment for critical components. Field operations are designed for graceful offline degradation.
10.2 Backup and Disaster Recovery
- Primary database: automated daily backups with 30-day point-in-time recovery retention.
- Compliance archive (7-year immutable): Object Lock storage with cross-region replication to a separate access-restricted account.
- Operational object storage: daily snapshots with cross-region replication.
- Infrastructure configuration: version-controlled Infrastructure-as-Code.
Backups are stored in an environment isolated from primary infrastructure. Object Lock and cross-account replication ensure backups cannot be deleted by a compromised primary account.
10.3 Recovery Time Objectives
| Provider Type | Application / Service | Recovery Objective |
|---|---|---|
| Cloud (Internal) | Primary database | Immediate |
| Cloud (Internal) | Document and photo storage | Immediate |
| Cloud (Internal) | Application servers | Immediate |
| Cloud (Internal) | Identity and access management | Immediate |
| Third party | Payment processing | < 12 hours |
| Third party | AI compliance review | < 12 hours |
| Third party | SMS / VoIP communications | < 12 hours |
| Third party | Document signing | < 24 hours |
| Third party | Accounting software integration | < 24 hours |
§11Staff Security Awareness Training
All covered persons receive security awareness training at onboarding and at least annually thereafter, covering: phishing identification (including AI-generated phishing); password and credential hygiene; multi-factor authentication; acceptable use of devices and cloud accounts; data privacy obligations; secure handling of PII, CDR data, and integration partner data; incident identification and reporting; and acceptable use of AI services. Training completion is recorded and retained for a minimum of 3 years. Training is also delivered on a triggered basis upon material change in role or upon a relevant security incident.
§12Intellectual Property Protection
- All employees and contractors acknowledge at onboarding that use of a previous employer’s or client’s IP, know-how, or trade secrets is strictly prohibited.
- Development agreements with the development partner address IP ownership — all platform outputs developed for Hawthorn Technologies vest in Hawthorn Technologies.
- Qualified legal counsel reviews standard customer contracts, terms of service, and high-value contracts prior to execution.
- A formal procedure is maintained to safeguard against infringing third-party IP rights, including review of third-party software licences.
§13Quality Controls and Development Practices
13.1 Development Methodology
Hawthorn Technologies and its development partner follow a documented agile delivery methodology with defined sprint cycles, mandatory code review before merge, automated testing in the CI/CD pipeline, staged deployment environments (development → staging → production), and documented deployment and rollback procedures.
13.2 Secure Development — Application Vulnerability Testing
Application code is tested before release for the following classes of vulnerability, at minimum:
- Cross-Site Request Forgery (CSRF).
- Cross-Site Scripting (XSS), including reflected and stored variants.
- SQL injection.
- XML injection.
- Authentication, session management, and functional-level access control flaws.
- Unvalidated forwards and redirects.
Findings of any of the above classes are remediated under the priority schedule in Section 6 prior to release.
13.3 Change Control
All scope changes to active contracts require written documentation of the proposed change, an impact assessment, and signed approval by both parties before work commences.
13.4 Customer Acceptance
Platform delivery milestones include defined UAT stages with formal written sign-off gates by both parties.
13.5 Problem and Complaint Management
Hawthorn Technologies maintains a formal procedure for documenting platform downtime, technical problems, and complaints received directly from platform users. All issues are logged, investigated, and reviewed for systemic patterns. Platform-level incidents additionally follow the incident response process in Section 7.
13.6 Industry Standards
The platform is developed and operated in accordance with:
- Privacy Act 1988 (Cth) and Australian Privacy Principles (APPs).
- Consumer Data Right Rules and Data Standards (Treasury / ACCC / DSB).
- OWASP Top 10 — web application security.
- NIST SP 800-123 (Server Security) and CIS Benchmarks — server and infrastructure hardening.
- Cloud provider security architecture frameworks (security pillar).
- NETCC (New Energy Tech Consumer Code).
- VEU (Victorian Energy Upgrades) Specifications 2018 v23.0.
§14Penetration Testing
Hawthorn Technologies conducts external penetration testing of the platform by a qualified, independent security firm prior to commercial go-live and at least annually thereafter. Test scope covers the web application and API, mobile application (iOS and Android), authentication and authorisation controls, and cloud infrastructure configuration. Findings are remediated in accordance with the priority schedule in Section 6.
§15Compliance and Enforcement
All covered persons are responsible for compliance with this Policy. Suspected violations must be reported to the Director immediately. Violations may result in disciplinary action up to and including termination. Where a violation constitutes a criminal offence or regulatory breach, Hawthorn Technologies will report the matter to the appropriate authorities. Compliance is reviewed as part of the annual scheduled review.
§16Contact
- Organisation
- Hawthorn Technologies Pty Ltd
- ABN
- 35 694 551 098
- Address
- Delahey VIC 3037, Australia
- Security contact
- security@swiftrebate.com.au
- Privacy contact
- privacy@swiftrebate.com.au
- Platform
- swiftrebate.app