SPARKVIEW PTY LTD

Information Security Policy

Consumer Data Right (CDR) – Schedule 2 Security Framework

Important Implementation Note

This document is a compliance-ready policy draft based on the CDR Rules and publicly available information about Sparkview. It deliberately distinguishes policy commitments from controls that must be evidenced in Sparkview’s actual environment. Before submission to a regulator, assessor, auditor or accreditation process, Sparkview must validate the assumptions, insert the actual responsible people and suppliers, and retain evidence that the stated controls are designed, implemented and operating effectively.

1. Purpose And Executive Summary

Sparkview Pty Ltd is committed to protecting information assets and, where applicable, Consumer Data Right (CDR) data from misuse, interference, loss, unauthorised access, modification and disclosure. This policy establishes the information security governance, risk posture, control expectations, monitoring, testing, and incident-response requirements that apply to Sparkview’s CDR data environment.

The policy is designed to address the five security-governance steps in Schedule 2 of the Competition and Consumer (Consumer Data Right) Rules 2020: security governance; definition of the CDR data environment; maintenance of information security capability; formal controls assessment; and management and reporting of security incidents.

The policy also establishes a control baseline covering the Schedule 2 Part 2 minimum controls, including authentication, privileged access, logging, access governance, physical access, role-based access, unique identities, passwords, encryption in transit and at rest, firewalls, hardening, segregation, data loss prevention, non-production data, lifecycle management, vulnerability management, malware protection, security training and personnel security.

Sparkview operates in technology-focused areas including cloud infrastructure, software development, AI and big-data solutions, web and mobile applications, digital engineering, cloud and data-centre services and related infrastructure. These activities create information-security risks that are relevant to the protection of systems and data used in a CDR environment.

Policy Objectives

• Protect CDR data throughout collection, processing, storage, transmission, backup, retention, deletion and de-identification.
• Apply least privilege, segregation of duties and strong authentication to CDR-system access.
• Maintain a documented and reviewable security risk posture that reflects the potential harm to CDR consumers.
• Ensure security controls are implemented, monitored, tested, and independently assessed at an appropriate frequency.
• Detect, contain, investigate, report and learn from information-security incidents.
• Ensure employees, contractors, service providers and other parties with access to CDR data to understand and meet security obligations.
• Maintain evidence sufficient to demonstrate the design, implementation and operating effectiveness of relevant controls.

2. Scope And Applicability

This policy applies to Sparkview Pty Ltd, its directors, employees, contractors, temporary personnel, consultants, service providers and other parties who access, operate, administer, develop, support or otherwise interact with the CDR data environment.

The policy applies to production and non-production systems, applications, APIs, databases, storage, networks, endpoints, identity services, logging platforms, backup systems, development pipelines, physical facilities and third-party services to the extent that they form part of, connect to, or support the CDR data environment.

Where Sparkview acts in a role other than an unrestricted accredited data recipient, the relevant requirements of this policy apply according to that role. Where Sparkview is a CDR principal, representative, sponsor or affiliate, contractual and CDR obligations are applied in addition to the baseline controls in this policy.

Out Of Scope

• Systems that have no connection to CDR data, CDR processing, or the CDR data environment may be outside the technical boundary, subject to documented boundary assessment.
• Personal systems or services must not be used to process CDR data unless formally approved, secured and brought within the applicable control boundary.
• A system is not treated as out of scope merely because it is operated by a third party. Dependencies that can affect CDR confidentiality, integrity, or availability remain subject to supplier and outsourcing controls.

3. Drafting Assumptions And Validation Register

The following assumptions have been used because company-specific operational evidence was not supplied. They are intentionally stated as assumptions rather than facts. Sparkview must confirm or amend them before formal adoption.

4. Information Security Governance

Sparkview will maintain a formal governance framework for managing information security risks relating to CDR data. Governance will define decision rights, accountability, escalation paths, risk acceptance, security policies, control ownership, testing responsibilities and management reporting.

4.1 Roles And Responsibilities

4.2 Policy Governance

• The policy must be approved by the designated approving authority.
• The policy must be reviewed at least annually and sooner following a material change in threats, technology, CDR processing, suppliers, business operations or the CDR data environment.
• Material deficiencies identified through testing, audit, incident investigation, or assurance activities must be reported to senior management.
• Exceptions must be documented, risk-assessed, approved by an authorised risk owner, and given an expiry/review date.
• Supporting procedures and standards must be maintained consistently with this policy.

5. Information Security Risk Posture

Sparkview adopts a conservative risk posture for CDR data because unauthorised access, misuse, modification, disclosure or loss may cause significant harm to CDR consumers and may create regulatory, contractual, financial and reputational consequences.

Sparkview will not knowingly accept uncontrolled or unnecessary exposure to CDR data. Controls will be selected using a risk-based approach, taking into account the nature and extent of threats, the quantity and sensitivity of CDR data, system criticality, exposure to the internet, dependency on third parties and the potential impact on affected consumers.

6. CDR Data Environment Boundaries

Sparkview will assess, define and document the boundaries of the CDR data environment. The boundary will include systems that store, process or transmit CDR data, and supporting systems where compromise could materially affect the security of the CDR environment.

6.1 Boundary Components

• CDR-facing APIs, gateways, application services, and authentication components.
• Databases, object stores, caches and other repositories containing CDR data.
• Encryption/key-management services and secret-management systems supporting CDR workloads.
• Identity, access-management, privileged-access and administrative systems.
• Networks, firewalls, VPNs, security gateways and supporting infrastructure.
• Logging, security monitoring, alerting, and incident-response systems.
• Backup, recovery, and disaster-recovery systems that contain or restore CDR data.
• Development, test and deployment systems that can access production CDR data or CDR-connected services.
• Corporate endpoints and administrative devices used to access the CDR environment.
• Physical facilities and data-centre areas where CDR systems are hosted or accessed.
• Third-party and outsourced services that store, process, transmit, or administer CDR data.

6.2 Boundary Review

• The boundary must be reviewed at least annually.
• A review must also occur as soon as practicable after a material change to threats, systems, suppliers, architecture or CDR processing.
• The system inventory and data-flow documentation must identify CDR data stores, processing points, interfaces, dependencies, and trust boundaries.

7. CDR Data Classification and Handling

CDR data must be treated as sensitive information requiring heightened security controls. The classification must reflect confidentiality, integrity, availability, and potential harm to consumers.

8. Identity And Access Management

Access to the CDR data environment is based on least privilege, business need, segregation of duties and strong authentication.

• MFA or an equivalent control is required for all access to CDR data, except where the CDR Rules expressly distinguish consumer access.
• Administrative privileges are granted only when needed and for the period required. Persistent, privileged access is minimised and reviewed.
• Each person receives a unique identity. Shared or default accounts are prohibited except where technically necessary for a service and where activity can be attributed and monitored.
• User access is provisioned only after approval by the appropriate system owner and is revoked promptly when no longer required.
• User access privileges are reviewed at least quarterly.
• Role-based access control must limit access to what personnel need to perform their assigned responsibilities.
• Strong password and authentication requirements must be enforced where passwords are used.
• Privileged access must be separately controlled, logged, and monitored.
• Access conflicts and segregation-of-duties risks must be identified and remediated or formally approved.

9. Network, Infrastructure and Endpoint Security

9.1 Encryption

• CDR data at rest must be encrypted using accepted cryptographic methods.
• Encryption keys must be securely stored, access-controlled, backed up where necessary and rotated according to risk and provider capability.
• CDR data in transit must be encrypted using secure protocols and authenticated endpoints.
• Cryptographic access must be logged and limited to authorised personnel and services.

9.2 Firewalls and Network Security

• Traffic from untrusted networks must be restricted using firewalls and network security controls.
• Only necessary protocols and ports may be permitted.
• Firewall administration must be restricted and monitored.
• Firewall configurations must be reviewed periodically and following material changes.

9.3 Hardening and Endpoint Security

• Servers, databases, applications and operating systems must be hardened to acceptable industry standards.
• Corporate endpoints and approved BYOD devices used to access the CDR environment must be appropriately secured.
• Unsupported software and operating systems must not be used for CDR processing unless an approved exception exists.
• Security configuration baselines must be documented and monitored.

9.4 Data Segregation

CDR data must be logically or physically segregated so that data collected or hosted on behalf of one accredited recipient or representative cannot be accessed by another recipient except as authorised. Tenant, client, environment, and dataset boundaries must be enforced through architecture and access controls.

10. Data Loss Prevention and Information Asset Lifecycle

• Controls must prevent CDR data from leaving the CDR data environment through unapproved cloud services, email, portable media, or other unauthorised channels.
• Outbound data transfers must be monitored where technically feasible, including recipient, volume, frequency, and destination signals.
• Email and collaboration systems must use filtering and blocking mechanisms appropriate to CDR data sensitivity.
• Write access to portable storage must be restricted where feasible.
• Information assets must have documented owners, classification, lifecycle status, and disposal requirements.
• Backup, retention, deletion, and de-identification processes must be documented and tested.
• CDR data used for testing or development must be masked or otherwise protected before being made available in non-production environments.

11. Vulnerability Management and Secure Development

11.1 Security Patching

Sparkview will maintain a formal patch-management process for applications, operating systems, infrastructure, and security tooling. Vulnerabilities will be identified, risk-rated, assigned, and remediated within timeframes proportionate to severity and exposure. Critical vulnerabilities affecting internet-facing or CDR systems must receive expedited treatment.

11.2 Secure Coding

• Software changes affecting the CDR environment must follow accepted secure development practices.
• Code changes must be peer reviewed and tested before production release.
• Security testing must be incorporated into development and deployment pipelines where practical.
• Secrets must not be embedded in source code or unsecured configuration.
• Production access for developers must be restricted and monitored.

11.3 Vulnerability Scanning and Penetration Testing

The CDR environment must undergo regular vulnerability scanning and penetration testing. Testing frequency will reflect threat levels, system changes, exposure, and previous findings. Material findings must be tracked to closure and reported to management where risk exceeds accepted thresholds.

12. Malware, Email and Web Protection

• Anti-malware and anti-virus controls must be deployed to relevant endpoints and servers and kept current.
• Security telemetry and compliance metrics must be monitored, with non-compliant systems remediated promptly.
• Web and email filtering must identify, quarantine or block suspicious content.
• Installation of software and executables must be restricted to authorised software.
• Security alerts indicating possible compromise must enter the incident-management process.

13. Personnel Security and Security Awareness

• Personnel must complete security and privacy training before receiving access to the CDR environment.
• Security and privacy refresher training must occur at least annually.
• Personnel must acknowledge acceptable use and security obligations.
• Background screening appropriate to the role and risk must be completed before personnel receive CDR access, subject to applicable law.
• Access must be removed or adjusted promptly following role changes, termination or extended leave.
• Personnel must report suspected phishing, credential compromise, data loss, unauthorised access and other security incidents promptly.
• Confidentiality obligations must apply to employees and relevant contractors and suppliers.

14. Third-Party and Outsourcing Security

Sparkview will manage third-party security risk throughout the supplier lifecycle where a supplier can access, store, process, transmit, administer or materially affect CDR data or the CDR data environment.

• Perform risk-based due diligence before onboarding material suppliers.
• Document security and privacy requirements in contracts, including confidentiality, access control, incident notification, data location where relevant, subcontracting and secure deletion.
• Require suppliers to provide appropriate assurance or evidence of security controls.
• Review material suppliers at least annually or more frequently where risk warrants.
• Maintain a current supplier and sub-processor register.
• Require prior approval for material subcontractors or sub-processors where contractually and legally appropriate.
• Apply an exit process covering data return/deletion, credential revocation and evidence retention.

15. Audit Logging and Monitoring

Critical events within the CDR environment must be identified, logged, and retained to support traceability, accountability, incident detection, and investigation.

• Authentication of successes and failures.
• Privileged and administrative actions.
• Access to sensitive data stores and material data exports.
• Security configuration changes.
• Changes to permissions and identities.
• Security alerts, malware detections, and network security events.
• Relevant API activity and data-access events.
• Backups, restores and deletion operations where technically available.

Logs must be protected against unauthorised alteration or deletion. Monitoring rules must be reviewed periodically, and alerts must be investigated according to severity.

16. Information Security Incident Management

Sparkview will maintain procedures to detect, record, assess, contain, eradicate, recover from and learn from information-security incidents. The incident process must cover plausible incidents affecting CDR data and the CDR data environment.

16.1 Incident Lifecycle

1. Detection and initial reporting.
2. Triage and classification, including assessment of whether CDR data is affected.
3. Containment and preservation of evidence.
4. Investigation and impact assessment.
5. Eradication and recovery.
6. Regulatory, consumer, contractual, and other notifications where required.
7. Post-incident review, root-cause analysis, and remediation.
8. Management reporting and control improvements.

16.2 CDR-Specific Notification

CDR data security response plans must address notification of CDR data security breaches to the Information Commissioner and affected CDR consumers where required under the Privacy Act 1988 and CDR framework. Information-security incidents must also be notified to the Australian Cyber Security Centre as soon as practicable and, under Schedule 2 clause 1.7, no later than 30 days after Sparkview becomes aware of the security incident.

Incident response plans must be tested at least annually, and material changes to threats or the CDR environment.

17. Formal Controls Assessment and Assurance

Sparkview will operate a formal testing program to assess the design, implementation, and operating effectiveness of security controls. Testing frequency and depth will reflect the rate of threat and vulnerability change, material changes to the CDR environment, and the likelihood and impact of control failure.

• Control owners must maintain evidence of implementation and operation.
• Testing must be performed by appropriately skilled persons who are independent from the performance of the controls being tested.
• Deficiencies must be recorded, risk-rated, assigned to an owner, and tracked to remediation.
• Material deficiencies must be escalated to senior management.
• The testing programme must be reviewed at least annually and following material changes.
• Evidence must be retained for audit and assurance purposes in a controlled repository.

18. Schedule 2 Control Coverage Matrix

The matrix below maps the policy to the minimum information security controls in Schedule 2 Part 2. The 'Implementation status' is deliberately marked 'Validate' because this document cannot by itself prove that a technical or operational control exists in Sparkview's live environment.

19. Evidence And Records Requirements

Sparkview must maintain evidence demonstrating that the controls described in this policy are implemented and operating. The following evidence register is a minimum baseline.

20. Exceptions and Risk Acceptance

No person may bypass a CDR security control without an approved exception. Exceptions must be documented before implementation where practicable and must include the affected control, reason, risk assessment, compensating controls, owner, approval authority, and expiry/review date.

• Exceptions must be time limited.
• High-risk exceptions must be escalated to senior management.
• Compensating controls must provide reasonable mitigation for the identified risk.
• Expired exceptions must be closed, renewed with approval, or remediated.
• Emergency deviations must be retrospectively documented and reviewed.

21. Review, Approval and Continuous Improvement

This policy is to be reviewed at least annually and sooner where material changes occur in threats, systems, suppliers, CDR data, business operations, legal requirements or the CDR data environment. Reviews must consider incidents, control testing, audit findings, penetration tests, risk assessments, changes to the CDR Rules, and relevant regulatory guidance.

22. Regulatory And Reference Basis

This policy has been drafted against the Consumer Data Right Rules 2020, Schedule 2 – Steps for privacy safeguard 12 – security of CDR data held by accredited data recipients. The Federal Register identifies the Rules as in force and provides the latest available compilation and downloads. The policy also reflects the security governance and controls described in Schedule 2 clauses 1.3–1.7 and 2.2.

Primary legislative source: Federal Register of Legislation – Competition and Consumer (Consumer Data Right) Rules 2020. Latest-version register: https://www.legislation.gov.au/F2020L00094/latest/downloads

Sparkview source review: Sparkview’s public website was reviewed for organisational context, services, Australian operations, cloud/data-centre activities and technology services. Public information should not be treated as evidence that a particular security control is implemented.

Sparkview website: https://sparkview.com.au/

Regulatory note: CDR accreditation and ongoing compliance can require evidence beyond this policy, including control testing, assurance/attestation, technical implementation evidence, system descriptions, risk assessments and operational records. This policy is one component of a compliance evidence set and should not be submitted as the sole proof of compliance.

23. Approval And Sign-Off

By approving this policy, Sparkview confirms that the organisation has reviewed the policy against its actual operating environment, validated the assumptions and assigned owners for implementing and evidencing the controls.

Appendix A – Minimum Annual Security Review Checklist

The annual review should be completed and retained as evidence. A 'Yes' answer should be supported by documentary or technical evidence.

Appendix B – Draft CDR Security Risk Register