Cyber Security Policy

Document control

1. Purpose

This Policy sets the minimum requirements for protecting the confidentiality, integrity and availability of [Organisation]'s information assets, including those managed by related parties and third parties. It ensures that:

2. Scope

This Policy applies to:

3. Regulatory and standards alignment

The table summarises the main requirements this Policy supports, as at October 2026. Delete those that do not apply to you.

3.1 ASIC expectations and court decisions

• ASIC v RI Advice Group Pty Ltd [2022] FCA 496 (5 May 2022): the Federal Court declared that RI Advice breached s912A(1)(a) and (h) by failing to have documentation and controls adequate to manage cyber security and cyber resilience risk across its authorised representative network, and ordered it to engage a cyber security expert to identify and implement further measures (ASIC 22-104MR).
• ASIC v FIIG Securities Limited [2026] FCA 92 (13 February 2026): FIIG admitted breaches of s912A(1)(a), (d) and (h). The failures included inadequate MFA, passwords and access controls, firewall and security software configuration, vulnerability scanning and penetration testing, patching, monitoring of threat alerts, staff awareness training, and incident response planning and testing. The Court imposed a $2.5 million penalty and ordered an independent expert compliance program (ASIC 26-021MR).
• ASIC v Fortnum Private Wealth Ltd (Supreme Court of NSW, 2026): Fortnum admitted failing to have an adequate cybersecurity policy across its business and authorised representative network, adequate processes to oversee and monitor its authorised representatives' cyber resilience, adequate specialised cybersecurity expertise, and adequate cybersecurity risk management systems. The Court ordered a $1.35 million penalty (ASIC 26-244MR).
• ASIC's open letter to licensees and directors of 8 May 2026 (26-092MR) asks licensees to act now on the cyber risk from frontier AI by strengthening the basics: protect critical assets, review user access and privileges, patch promptly, reduce attack surfaces, use defence-in-depth that assumes breach, exercise incident response and business continuity plans, and manage third-party risk.

4. Key definitions

Definitions of CPS 234 terms follow CPS 234 paragraph 12 so that the same words mean the same thing across the industry. The remaining terms (key control, material control weakness, privileged access and phishing-resistant MFA) are this Policy's working definitions. Incident, Issue, Breach, Root cause, Critical operation and Material service provider are as defined in the RiskFA Incident & Issues Management Standard.

5. Principles

1. The Board is ultimately responsible. Information security is a Board-level risk, governed within risk appetite like any other material risk (CPS 234 para 13).
2. Know what matters. Every information asset has an owner and a classification by criticality and sensitivity. Protection follows classification.
3. Assume breach, defend in depth. No single control is relied on. Preventive, detective and corrective controls are layered so that a failure of one is caught by another.
4. Least privilege and zero trust. People and systems get only the access they need, for only as long as they need it, and every access request is verified.
5. Secure by default and by design. Security is built into systems, products, changes and contracts from the start, not added later.
6. Do the basics well, everywhere. The Essential Eight is the minimum baseline, implemented consistently across all eight strategies to the target maturity level.
7. Keep controls current. Controls are monitored, tested and adjusted as threats, vulnerabilities, technology and the business change (CPS 234 para 17), so that [Organisation] stays within risk appetite.
8. Third parties are part of our perimeter. Information assets managed by others meet the same standard, and we verify it.
9. Detect and respond fast. We plan for incidents that could plausibly occur, rehearse the plans, and meet every notification clock.
10. Prove it. Controls are tested for design and operating effectiveness by people independent of their operation, and results are reported honestly.

6. Three lines of accountability

7. Governance, roles and responsibilities

CPS 234 paragraph 14 requires the information security roles of the Board, senior management, governing bodies and individuals to be clearly defined. [Organisation] defines them as follows.

8. Information security capability

[Organisation] must maintain an information security capability commensurate with the size and extent of threats to its information assets, and which enables the continued sound operation of the entity (CPS 234 para 15). To do this, [Organisation]:

9. Information security policy framework

The information security policy framework must be commensurate with [Organisation]'s exposure to vulnerabilities and threats, and give direction on the responsibilities of all parties who must maintain information security, including staff, contractors, related parties, third parties and customers (CPS 234 paras 18–19).

10. Information asset identification and classification

[Organisation] must classify its information assets, including those managed by related parties and third parties, by criticality and sensitivity. The classification must reflect the degree to which an information security incident affecting the asset could affect, financially or non-financially, [Organisation] or the interests of depositors, policyholders, beneficiaries or other customers (CPS 234 para 20).

11. Implementation of controls

[Organisation] must have information security controls that protect its information assets, including those managed by related parties and third parties, and that are implemented in a timely manner and commensurate with: vulnerabilities and threats; the criticality and sensitivity of the assets; the stage of the asset's life-cycle; and the potential consequences of an incident (CPS 234 para 21). Controls are designed, implemented and embedded in line with risk appetite and are monitored and tested for design and operating effectiveness (CPS 230 paras 28–29).

11.1 Control baseline and Essential Eight target

• The CISO maintains a control baseline (Appendix A) that maps each control to the Essential Eight, the CPS 234 paragraphs and the relevant ISM guideline, with an owner, control type (preventive, detective, corrective), whether it is a key control, and its testing frequency.
• [Organisation]'s Essential Eight target is [Maturity Level Two] across all eight strategies for the corporate environment, and [Maturity Level Three] for systems that support critical operations or hold Highly Confidential information. ASD recommends reaching the same maturity level across all eight strategies before moving higher.
• The Essential Eight is a minimum set of preventive measures for internet-connected IT networks. It does not address every threat, and is not designed for operational technology or enterprise mobility. [Organisation] adds controls from the ISM and other standards where its risk assessment requires.
• Where [Organisation] is subject to the SOCI CIRMP Rules, it records which framework it complies with under Rules s8(4) or (5) (for example the Essential Eight at no less than Maturity Level One).
• Controls are prioritised on risk: critical and internet-facing assets first.

11.2 Control design and the control environment

• Every material information security risk in the risk register is linked to its key controls. Controls are rated effective, partly effective or ineffective based on testing (section 22).
• Controls are monitored continuously where practicable (for example automated configuration, patch and MFA coverage checks) and the results are reported against risk appetite metrics (section 26). When monitoring shows a control is drifting outside its target, the control owner acts and the change is recorded.
• Control gaps and weaknesses are raised as issues and managed under the RiskFA Incident & Issues Management Standard until remediated, and stay in the operational risk profile until fixed (CPS 230 para 30).
• Where information assets are managed by a related party or third party, [Organisation] evaluates the design of that party's controls that protect its assets (CPS 234 para 22; section 19).

12. Identity and access management

12.1 All users

• Every user has a unique, named identity. Shared accounts are prohibited unless approved as an exception with compensating controls.
• Access is granted on least privilege and need-to-know, approved by the information asset owner, and provisioned through [the identity governance tool] wherever possible.
• Joiners, movers and leavers: access is removed on the last day of employment or engagement (immediately for terminations), and changed on role change.
• Access to systems holding Confidential or higher information is reviewed at least [six-monthly], and privileged access at least [quarterly].
• Password and passphrase rules follow the ISM. Credentials are never shared, and compromised credentials are reset immediately.
• Customer-facing authentication is risk-based. Higher-risk customer and member activities (for example changes to contact or bank details, withdrawals, rollovers and benefit transfers) require MFA or an equivalent control, with alternatives for customers who cannot use digital channels.

12.2 Multi-factor authentication

• MFA is required for: all remote access; all access to [Organisation]'s and third-party online services that process, store or communicate sensitive data; all privileged access; all users of systems; and access to email, cloud consoles and identity providers.
• MFA used for staff access to online services and systems is phishing-resistant (required at Essential Eight Maturity Level Two). SMS and voice codes are not used for staff, and are phased out for customers where phishing-resistant options are available.
• Customers of online services are offered a phishing-resistant MFA option.
• Successful and unsuccessful MFA events are centrally logged and monitored.

12.3 Privileged access

• Privileged access is requested, validated and approved before it is granted, and is disabled after [12 months] unless revalidated, and after [45 days] of inactivity (Essential Eight Maturity Level Two).
• Privileged users have a separate, dedicated privileged account used only for privileged duties. Privileged accounts cannot access the internet, email or web services unless explicitly authorised and limited.
• Administration is done from separate privileged operating environments and through jump servers or a privileged access management tool. Just-in-time access is used for the most sensitive systems where practicable.
• Credentials for break-glass, local administrator and service accounts are long, unique, unpredictable and managed in a vault.
• Privileged access events, and privileged account and security group changes, are centrally logged, protected from change, and reviewed.

13. Secure configuration, patching and vulnerability management

13.1 Secure configuration and hardening

• Systems are built from approved, hardened baselines using ASD and vendor hardening guidance (the most restrictive applies when they conflict). Deviations are exceptions.
• Application control restricts execution to an organisation-approved set on workstations and internet-facing servers, and rulesets are validated at least [annually].
• Microsoft Office macros are disabled for users without a demonstrated business need; macros from the internet are blocked; users cannot change macro security settings.
• User application hardening: web browsers, office productivity suites and PDF software are hardened and users cannot change their security settings; unneeded features are removed.
• Configuration drift is detected automatically and corrected within [timeframe].
• Unsupported (end-of-life) operating systems and applications are removed or replaced. Any that remain are exceptions with compensating controls and a retirement date.

13.2 Vulnerability management

• Vulnerability scanning with an up-to-date database runs at least daily for online services and internet-facing systems, weekly for office productivity suites, browsers, email clients, PDF software and security products, and fortnightly for other applications and internal systems (Essential Eight).
• Vulnerabilities are rated using vendor severity, exploit availability (including known-exploited lists), exposure and asset classification.
• Threat intelligence and ASD alerts about actively exploited vulnerabilities trigger an emergency response.
• Overdue vulnerabilities are reported to the CISO and asset owner, and those that cannot be fixed in time go through the exception process (section 25).

13.3 Patch timeframes

Patches, updates or other vendor mitigations are applied within these timeframes from release. They match Essential Eight Maturity Level Two; tighten them for Maturity Level Three systems.

14. Logging, monitoring and detection

[Organisation] must have robust mechanisms to detect and respond to information security incidents in a timely manner (CPS 234 para 23).

15. Network, endpoint and email security

15.1 Network security

• Networks are segmented by trust and function, so that a compromise in one zone cannot spread freely. Critical systems, privileged environments, backups and payment systems are in protected segments.
• Traffic between zones and to the internet is denied by default and allowed only by approved rules. Firewall rules are reviewed at least [six-monthly].
• The internet-facing attack surface is kept to a minimum, inventoried, and scanned. Administrative interfaces are never exposed directly to the internet.
• Remote access uses approved, MFA-protected services with device health checks.
• Wireless, DNS and web traffic are protected and filtered, and encrypted protocols are used.
• Protection against denial-of-service attacks is in place for critical customer-facing services.

15.2 Endpoint security

• All endpoints (laptops, desktops, servers, mobile devices) are enrolled in management, encrypted, hardened and patched, and run endpoint detection and response.
• Personal devices may access [Organisation] information only through approved, managed containers or virtual desktops.
• Removable media is blocked by default, and allowed only by exception with encryption.

15.3 Email and web security

• Email is filtered for malware, phishing and impersonation. Attachments and links are scanned or detonated before delivery.
• Sender authentication (SPF, DKIM and DMARC at enforcement) protects [Organisation]'s domains from spoofing.
• External emails are clearly tagged. Staff can report suspicious emails in one click, and reports are triaged promptly.
• Web access is filtered, and access to newly registered, malicious and uncategorised sites is blocked.

16. Backup and recovery

• Backups of data, applications and settings are performed and retained in line with business criticality and business continuity requirements, including the maximum data loss tolerance for each critical operation (CPS 230 para 37(b)).
• Backups are synchronised so that systems can be restored to a common point in time.
• Backups are retained in a secure and resilient manner: at least one copy is immutable or offline and logically separated from production identity systems, so that ransomware or a compromised administrator cannot delete or encrypt it.
• Unprivileged accounts cannot access backups belonging to other accounts, and cannot modify or delete backups. Privileged accounts other than backup administrators cannot access backups belonging to other accounts, and cannot modify or delete backups (Essential Eight Maturity Level Two). At Maturity Level Three, backup administrators also cannot modify or delete backups during their retention period.
• Restoration to a common point in time is tested as part of disaster recovery exercises at least [annually] for each critical operation, and the results are compared against tolerance levels.
• Recovery plans assume that a cyber attack may make primary systems and recent backups untrustworthy, and include clean-room or isolated recovery for critical systems.
• Backup and recovery are included in the BCP testing program, including severe but plausible cyber scenarios and disruption at material service providers (CPS 230 paras 42–43).

17. Data security, encryption and key management

17.1 Data protection

• Information is handled according to its sensitivity label (Appendix B), including where it may be stored, who may access it and how it may be shared.
• Personal information is protected under APP 11 using technical and organisational measures, collected only where needed, and destroyed or de-identified when no longer needed for any permitted purpose (APP 11.2), subject to record-keeping laws.
• Production data containing personal or Confidential information is not used in development or test environments unless masked or de-identified, or approved as an exception.
• Data stored, processed or accessed offshore is identified in the information asset register, and the risks are assessed before it moves (see section 19 for APRA notification).
• Media and equipment are sanitised or destroyed securely at end of life, with evidence kept.

17.2 Encryption

• Confidential and Highly Confidential information is encrypted in transit and at rest, including on endpoints, removable media, backups and in cloud services.
• Only approved algorithms, key lengths and protocols are used, in line with the ISM Guidelines for cryptography. Weak and deprecated protocols are disabled.
• [Organisation] keeps an inventory of where and how cryptography is used (a cryptographic inventory), to support crypto-agility.

17.3 Key management

• Cryptographic keys are generated, stored, rotated, backed up and destroyed under the [Cryptography and Key Management Standard], using hardware security modules or managed key services for high-value keys.
• Duties are separated so that no single person can access both encrypted data and its keys without oversight.
• Keys for the most sensitive data held in the cloud are controlled by [Organisation] where practicable.
• Certificates are inventoried, monitored for expiry and renewed automatically where possible.

17.4 Post-quantum cryptography

A future cryptographically relevant quantum computer could break today's public-key cryptography, and data stolen now could be decrypted later. ASD's ISM recommends ceasing use of traditional asymmetric cryptography (such as RSA, Diffie-Hellman, ECDH and ECDSA) by the end of 2030 and moving to ASD-approved post-quantum algorithms. [Organisation] plans and manages this transition under the RiskFA Quantum Risk and Post-Quantum Cryptography Standard, starting with the cryptographic inventory and long-lived sensitive data.

18. Secure development and change

• Security requirements, threat modelling and privacy impact assessment are part of the design of every new system, product, significant change and AI use case.
• Software is developed under the [Secure Development Standard], including secure coding practices, peer code review, automated code and dependency scanning, secrets scanning and a software bill of materials for key applications.
• Separate development, test and production environments are kept, and developers do not have standing access to production.
• Changes to production follow the [Change Management Standard]: risk-assessed, tested, approved, scheduled and reversible. Emergency changes are reviewed after the event.
• High-risk and internet-facing applications are security tested (for example penetration testing) before go-live and after significant change.
• Systems are not put into production with known High or Critical vulnerabilities unless approved as an exception.
• Off-the-shelf and open-source software is checked for supported status, known vulnerabilities and supply chain risk before use.
• Low-code tools, end-user computing and AI tools that handle Confidential information are inventoried and controlled in proportion to their risk.

19. Cloud, third-party and material service provider security

Information assets managed by related parties and third parties are protected to the same standard as [Organisation]'s own. This section works with the [Service Provider Management Policy] required by CPS 230 paragraph 46.

19.1 Before entering into an arrangement

• Every arrangement involving [Organisation]'s information assets is risk-assessed, based on the classification of the assets and the potential consequences of an incident.
• [Organisation] assesses the provider's information security capability (CPS 234 para 16) and evaluates the design of its controls that protect [Organisation]'s assets (CPS 234 para 22), using questionnaires, independent assurance reports (for example ISAE 3402 / ASAE 3402, SOC 2 or ISO/IEC 27001 certification with a relevant scope), and on-site or technical testing for the highest-risk arrangements.
• Due diligence for material arrangements includes the provider's ability to provide the service on an ongoing basis, and risks from geographic location and concentration, including fourth parties (CPS 230 paras 47 and 52).
• Core technology services providers are classified as material service providers unless [Organisation] can justify otherwise (CPS 230 para 49(d)).

19.2 Contract requirements

Agreements must, in proportion to the risk, include:

19.3 Ongoing oversight

• Each arrangement has an owner who monitors security performance, including the effectiveness of controls (CPS 230 para 59(b)).
• Security reassessments are performed at least [annually] for material service providers and arrangements involving Highly Confidential information, and every [2–3 years] for others.
• Where [Organisation] relies on the provider's control testing, it assesses whether the nature and frequency of that testing is adequate (CPS 234 para 28).
• APRA is notified within 20 business days of entering into or materially changing an agreement for a service relied on to undertake a critical operation, and before entering into any material offshoring arrangement, including where data will be located offshore (CPS 230 para 60).
• Authorised representatives, brokers and other distribution partners who handle [Organisation]'s customer data are subject to minimum cyber security requirements and oversight, proportionate to the data they hold (see ASIC v RI Advice).

19.4 Cloud services

• Cloud services are used only after a security and risk assessment, and on approved platforms and regions.
• The shared responsibility model is documented for each service, so that it is clear which controls the provider operates and which [Organisation] operates.
• Cloud configuration is managed as code where practicable and continuously checked against approved baselines (cloud security posture management).
• Cloud administrator accounts, root accounts and identity providers are treated as privileged access with the strongest controls.

20. Security awareness, culture and personnel security

• All staff and contractors complete security and privacy awareness training at induction and at least [annually], covering phishing, social engineering, credential protection, data handling, AI tools, and how to report incidents.
• Role-based training is given to privileged users, developers, the security team, executives and the Board.
• Phishing simulations run at least [quarterly]. Repeat failures lead to further training, not blame.
• Background and reference checks are proportionate to the role and the sensitivity of access. Roles with privileged or Highly Confidential access receive enhanced screening.
• Staff must report a suspected incident or weakness immediately, without fear of penalty for reports made in good faith.
• Breaches of this Policy are managed under the RiskFA Consequence Management Framework.

21. Information security incident management

[Organisation] must have robust mechanisms to detect and respond to incidents in a timely manner, and must maintain information security response plans for incidents that could plausibly occur (CPS 234 paras 23–24). The response plans must cover all stages of an incident, from detection to post-incident review, and escalation and reporting to the Board, other governing bodies and individuals responsible for incident management and oversight (para 25).

22. Testing control effectiveness

[Organisation] must test the effectiveness of its information security controls through a systematic testing program (CPS 234 para 27). The nature and frequency of testing must be commensurate with: the rate at which vulnerabilities and threats change; the criticality and sensitivity of the asset; the consequences of an incident; the risks of exposure to environments where [Organisation] cannot enforce its policies (untrusted environments); and the materiality and frequency of change to the asset.

22.1 The testing program

22.2 Requirements

• Testing is performed by appropriately skilled and functionally independent specialists (CPS 234 para 30). Independence means the tester does not design or operate the control being tested.
• Test findings are rated, recorded as issues and remediated under the RiskFA Incident & Issues Management Standard. Remediation is retested before closure.
• Testing results that identify control deficiencies that cannot be remediated in a timely manner are escalated and reported to the Board or senior management (CPS 234 para 29), and assessed for APRA notification (para 36).
• The sufficiency of the testing program is reviewed at least annually, or when there is a material change to information assets or the business environment (CPS 234 para 31). The review is reported to the [Board Risk Committee].
• Results of control testing are reported to senior management, and gaps are rectified in a timely manner (CPS 230 para 29).

23. Internal audit

• Internal audit activities include a review of the design and operating effectiveness of information security controls, including those maintained by related parties and third parties (information security control assurance) (CPS 234 para 32).
• Internal audit uses personnel appropriately skilled in providing such assurance, using co-sourced specialists where needed (CPS 234 para 33).
• Where an incident affecting assets managed by a related party or third party could materially affect [Organisation] or its customers, and internal audit intends to rely on that party's control assurance, internal audit assesses the quality of that assurance (CPS 234 para 34).
• Internal audit's information security coverage is set out in a risk-based plan approved by the [Board Audit Committee], and covers this Policy, the testing program and the remediation of findings.

24. Notifications to APRA and other parties

Notification decisions are made under the RiskFA Incident & Issues Management Standard and the RiskFA Cyber Incident Response Plan. The table summarises information security notifications as at October 2026. Clocks run from when [Organisation] becomes aware, not from the end of an investigation.

25. Exceptions and risk acceptance

Exceptions should be rare, limited in scope and time, and supported by compensating controls. ASD's Essential Eight guidance expects exceptions to be documented, approved through an appropriate process, minimised, and regularly reviewed.

26. Risk appetite, metrics and reporting

• The Board sets information security risk appetite statements, supported by measurable limits and key risk indicators (KRIs) (Appendix C).
• The CISO reports to the executive [monthly] and to the [Board Risk Committee] at least [quarterly] on: the threat environment; KRIs against limits; Essential Eight maturity against target; control testing results; material incidents and near misses; notifications; material weaknesses and remediation; exceptions; and third-party security.
• Any KRI outside its limit is escalated with an action plan. A breach of risk appetite is reported to the Board.
• The Board receives at least [annually] a report on the overall state of information security, the adequacy of the capability and resources, and the strategy.
• Reports focus on risk and trends, in plain language, not on volumes of technical data.

27. Compliance, review and related documents

27.1 Compliance with this Policy

Compliance with this Policy is mandatory. Breaches are recorded as incidents, managed under the RiskFA Incident & Issues Management Standard and the RiskFA Consequence Management Framework, and considered in performance and remuneration outcomes under the RiskFA Remuneration Policy (CPS 511 where it applies). The CISO may direct the immediate removal of access or isolation of a system to protect information assets.

27.2 Review

The CISO reviews this Policy at least [annually], and after any material change to the threat environment, information assets, the business or regulation, or after a Critical incident. The Board approves material changes.

27.3 Related documents

• RiskFA Risk Management Framework; RiskFA Incident & Issues Management Standard; RiskFA Cyber Incident Response Plan; RiskFA Data Breach Response Plan; RiskFA Quantum Risk and Post-Quantum Cryptography Standard
• [Service Provider Management Policy], the RiskFA Business Continuity Policy, [Privacy Policy], [Acceptable Use Standard] and the security standards listed in section 9
• APRA: CPS 234 and CPG 234, CPS 230 and CPG 230, CPS 220 / SPS 220, CPS 511
• ASD: Essential Eight maturity model and FAQ; Information security manual; Strategies to mitigate cyber security incidents; Planning for post-quantum cryptography
• Legislation: SOCI Act and CIRMP Rules; Cyber Security Act 2024; Privacy Act 1988 (APP 11 and Part IIIC); Corporations Act 2001 s912A; FAR Act
• ASIC: RG 78 Breach reporting by AFS licensees and credit licensees; ASIC cyber resilience publications and the open letter of 8 May 2026
• Standards: AS ISO/IEC 27001 and AS ISO/IEC 27002, AS ISO 31000 Risk management, ISO/IEC 27035 Information security incident management, ISO 22301 Business continuity, NIST Cybersecurity Framework

Appendix A. Control baseline: Essential Eight and CPS 234 mapping

Key controls are marked. Adapt the targets to your Essential Eight target maturity level. Type: P = preventive, D = detective, C = corrective.

Appendix B. Information classification scheme

B.1 Sensitivity (confidentiality and integrity)

B.2 Criticality (availability)

Appendix C. Metrics and key risk indicators