Security Impact Assessment

This information security statement is a modification and extension of the SA Health Security Impact Assessment and is intended to provide a reference document for the information security posture of HeartAI within the South Australian digital health system. A specific purpose of this document is also to provide a reference particularly for the HeartAI engagement with SA Health. In addition to this document, HeartAI provides specific formal policy documents in relation to HeartAI governance generally.

Governance: Policy

Further information about HeartAI policy may be found with the following documentation:

Organisation of information security

1. Does the HeartAI information security policy ensure confidentiality, integrity and availability of information asset, and is the policy regularly reviewed and communicated to all staff and third parties?

HeartAI policy reflects the high-level of expected due diligence for HeartAI generally, including responsibilities and obligations for organisational, operational, and technical governance. These policies are routinely reviewed and assessed in coordination with SA Government and SA Health governance authorities. HeartAI employees are expected to understand and follow this policy as a formal obligation, and any modifications or amendments to policy are communicated through ongoing change management. HeartAI provides specific policies for information security and sensitive information, in addition to a range of other policies pertinent for deployment within sensitive health system contexts and for the management of sensitive health information.

References:

2. Does HeartAI ensure that all personnel know their roles and responsibilities, their reporting matrix, and are equipped to perform them?

HeartAI employees are governed by corresponding policies in addition to role and responsibilities as defined in the HeartAI standard Employment Agreement. These documents specify the organisational relationships within HeartAI to ensure that diligence is maintained. These responsibilities and obligations are also extended to third parties and service provision relationships.

For HeartAI engagement with corresponding organisations, HeartAI team members may be required to acquire relevant credentials for and comply with the policies of the engagement with these organisations. For HeartAI engagement with SA Health, this typically requires HeartAI team members to be credentialed for access to SA Health digital environments with a corresponding engagement remit. This includes obligations for HeartAI team members to understand and comply with SA Health policies within the bounds of any such specified remit.

The following HeartAI policies describe and specify the obligations of HeartAI team members and generally in relation to personnel security and engagement with corresponding organisations.

References:

3. Does HeartAI ensure that segregation of duties is enforced and formal approval gate for access to the system, to restrict the likelihood of accidental or deliberate misuse of SA Health Information Assets?

HeartAI provides formal policy for access to HeartAI platform environments and data assets. This typically requires the understanding the requested use case and corresponding access scope. If this also requires access to a South Australian Government digital environment the user will also be required to coordinate with corresponding governmental processes including the application of formal credentialing where appropriate.

HeartAI manages user access through an integrated identity access and management framework. This includes support for authentication, authorisation, token exchange, identity brokering, identity federation, and multi-factor authentication. HeartAI users are categorised through a role-based access control (RBAC) mechanism and implements both user roles and user groups relative to the users access. Broadly, HeartAI users are often categorised into administrators, developers, and end-users, with corresponding access. More granular access is provided specific to the corresponding use case, such as permission to access a particular service endpoint or resource. HeartAI generally operates with a minimum necessary permissions access control paradigm.

References:

4. Does HeartAI ensure that all ICT devices used by personnel for official purposes are in compliance to the organisational security standards?

HeartAI maintains formal policy for the management of corporate and personal ICT devices in alignment to the expected usage and access of these devices. In relation to SA Government and SA Health devices, HeartAI follows the responsibilities and obligations of ICT device management within these organisations. HeartAI employees must follow these corresponding policies when accessing potentially sensitive information and are obliged to use appropriate ICT devices within these environments.

References:

Human resource security

5. Does HeartAI ensure that a security awareness program is made available to staff and contractors

The responsibilities and obligations of security awareness and governance are documented as formal HeartAI policy. HeartAI security awareness and governance is maintained through this policy and routinely assessed through organisational and employee management. This includes ongoing assessment of employee use patterns, review of any discernible information security risks, and regular communication of responsibilities and obligations as outlined in governance and policy.

For HeartAI engagement with corresponding organisations, typically HeartAI team members are required to understand and comply with the security awareness programs of these organisations. For HeartAI engagement with SA Health, this will often require that HeartAI team members are appropriately credentialed and understand their obligations in relation to this process.

References:

6. Does HeartAI ensure appropriate criminal and relevant history screening is obtained for all personnel prior to commencement and that Information Security responsibilities are included in terms and conditions of employment?

HeartAI manages organisational and personnel access to potentially sensitive information through a formalised credentialing process with SA Health. This process requires the applicant to submit criminal and relevant history screening in alignment to SA Government and SA Health policy. The standard HeartAI Employment Agreement includes HeartAI policies and requires the employee to understand and follow their obligations.

Asset management

7. Does HeartAI ensure management responsibility for controlling the use, access, provisioning and maintenance of the Information Asset?

In relation to HeartAI deployments and HeartAI devices, typically HeartAI team members provision these through the organisations where there exists a service engagement. For example, for HeartAI deployments within SA Health, the HeartAI platform environment is managed within the SA Government Microsoft Azure tenancy and the SA Health Management Group. For HeartAI devices, HeartAI team members use SA Health managed devices to perform administration and development duties. This requires that HeartAI team members understand and follow the policies of the corresponding organisations. This also requires that HeartAI team members follow access processes with the corresponding organisations, such as for the provisioning of access identities and connections to specific environments. HeartAI policy describes and specifies these obligations for HeartAI team members.

8. Does HeartAI enforce a Standard Operating Procedure in regards to the secure disposal and reallocation of assets and media in accordance with the Information Security Policy Directive?

For HeartAI platform deployments within a corresponding organisation, HeartAI policy provides obligations in relation to the management of sensitive information and information generally. This includes obligations in relation to the secure removal of information and the secure disposal or reallocation of assets and media.

For HeartAI device usage within a corresponding organisation, HeartAI team members typically provision managed devices through the corresponding organisation. This requires that HeartAI team members understand and follow the associated policies of the organisation, including those policies for the secure management of corporate devices. HeartAI team members are required to follow HeartAI policies in relation to this, and this further includes obligations to the policies of corresponding organisations.

Access control

9. Does HeartAI enforce a Standard Operating Procedure to grant and revoke access privileges to the Information Asset, based on justified need and in a timely manner?

Administrator, developer, and end-user identity and access is granted and revoked in relation to the user’s current or changing role. This is typically done at the point of any role change, including revocation of access if such access is no longer required. These identity accounts are regularly reviewed and current policy mandates that this review occurs at least every 12 months.

For HeartAI engagements with corresponding organisations, typically HeartAI access control is collaboratively managed with the organisation. Access to HeartAI platform environments, end-user applications and services, and devices is typically managed by identity accounts managed by the corresponding organisation. For the HeartAI deployment within SA Health, this includes the requirement of an SA Health Health Active Directory (HAD) identity to access HeartAI environments. This process further requires that the relevant obligations of the corresponding organisations are understood and followed.

References:

10. Does HeartAI ensure users follow a documented password and secret authentication use guideline?

Administrator, developer, and end-user credential creation and assignment is constrained and enforced through technical mechanisms provided by the HeartAI identity and access management framework. This includes constraints to the kinds of credential mechanisms are allowed and to the technical specification of these credentials. Typically credentials require at least 8 bytes of credential entropy, restrictions against commonly-used and dictionary phrases, and a rotation period of no more than 6 months. In addition, multi-factor authentication is enforced through integration with phone-based multi-factor authentication applications.

For HeartAI engagements with corresponding organisations, identity accounts may be collaboratively managed with the organisation and the identity of the organisation may be the primary mechanism of access control. This requires a further obligation to understanding and following the relevant policies of the corresponding organisation. For the HeartAI engagement with SA Health, this typically requires that identities are managed through the SA Health Health Active Directory (HAD) identity and access management provider, including any corresponding pasword and secret management guidelines.

References:

11. Does HeartAI ensure that periodic review of general and privileged accounts are conducted?

HeartAI currently has relatively few managed identities, typically these are HeartAI administrators, developers, and some additional limited end-users. Therefore, the management of these identities is performed in relation to the change of role or usage with these users. For more general access to HeartAI service endpoints, it is proposed that end-users are provided access through their SA Health Health Active Directory (HAD) identities, which are currently managed by SA Health. HeartAI supports identity brokering and identity federation with the SA Health instances of Active Directory Federation Services and Azure Active Directory.

References:

12. Does HeartAI ensure access is provided to users on, need-to-know, least-privilege principles with appropriate justification, and that all users have their own personal accounts for normal business use in addition to privileged accounts?

HeartAI manages user access through an integrated identity access and management framework. This includes support for authentication, authorisation, token exchange, identity brokering, identity federation, and multi-factor authentication. HeartAI users are categorised through a role-based access control (RBAC) mechanism and implements both user roles and user groups relative to the users access. Broadly, HeartAI users are often categorised into administrators, developers, and end-users, with corresponding access. More granular access is provided specific to the corresponding use case, such as permission to access a particular service endpoint or resource. HeartAI generally operates with a minimum necessary permissions access control paradigm.

References:

Cryptography

13. Does HeartAI enforce policies and processes for encryption technologies which is in accordance to the industry governing standards to protect confidentiality of sensitive information at rest and in transmission?

HeartAI provides strong commitments with policies and processes for the encryption of data at-rest and in-transit. The practices and technologies implemented meet or exceed industry standard best practice. Data encryption at-rest is provided by Microsoft Azure and is guaranteed and certified by the Microsoft service-level agreement. HeartAI enforces encryption for all external-facing network endpoints and additional network rule enforcement only allows encrypted traffic to these endpoints, such as for network transmission between end-user devices on the SA Health network and the HeartAI virtual private cloud. HeartAI also applies generally encryption for internal network communication, for example between HeartAI services or between a HeartAI service and a HeartAI backing service. HeartAI generally commits to a posture of encryption wherever applicable.

In relation to cryptographic protocols themselves, HeartAI endeavours to maintain alignment or extension to industry standard best practice. This includes modern implementation of encryption technologies, such as TLS 1.2 and TLS 1.3, and rigorous enforcement of cipher suites such as TLS_AES_256_GCM_SHA384 and TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384.

HeartAI certificate management is largely automated and deployable at scale, and includes automated mechanisms for issuance, rotation, and revocation. HeartAI certificates are typically issued to specific service endpoints or software use cases and the use of wildcard certificates is avoided where possible.

References:

Physical and environmental security

14. Does HeartAI ensure that physical access to information systems facilities is controlled and monitored through appropriate mechanisms?

HeartAI does not directly manage physical infrastructure. All current HeartAI deployments are managed through Microsoft Azure, and are governed by rigorous security processes for physical access to Microsoft data centre locations. The following excerpt is provided by Microsoft in relation to the management of these facilities:

Access to physical datacenter facilities is tightly controlled by outer and inner perimeters with increasing security at each level, including perimeter fencing, security officers, locked server racks, integrated alarm systems, around-the-clock video surveillance by the operations center, and multi-factor access control. Only required personnel are authorized to access Microsoft datacenters. Logical access to Microsoft 365 infrastructure, including customer data, is prohibited from within Microsoft datacenters.

Our Security Operations Centers use video surveillance along with integrated electronic access control systems to monitor datacenter sites and facilities. Cameras are strategically positioned for effective coverage of the facility perimeter, entrances, shipping bays, server cages, interior aisles, and other sensitive security points of interest. As part of our multi-layered security posture, any unauthorized entry attempts detected by the integrated security systems generate alerts to security personnel for immediate response and remediation.

Microsoft employs a variety of safeguards to protect against environmental threats to datacenter availability. Datacenter sites are strategically selected to minimize risk from a variety of factors, including floods, earthquakes, hurricanes, and other natural disasters. Our datacenters use climate control to monitor and maintain optimized conditioned spaces for staff, equipment, and hardware. Fire detection and suppression systems and water sensors help to detect and prevent fire and water damage to equipment.

Disasters are unpredictable, but Microsoft datacenters and operations personnel prepare for disasters to provide continuity of operations should unexpected events occur. Resilient architecture and up-to-date tested continuity plans mitigate potential damage and promote swift recovery of datacenter operations. Crisis management plans provide clarity on roles, responsibilities, and mitigation activities before, during, and after a crisis. The roles and contacts defined in these plans facilitate effective escalation up the chain of command during crisis situations.

Additionally, for the SA Health engagement with HeartAI, corporate devices are provided with SA Health Standard Operating Environments (SOEs). These devices are managed in alignment with both SA Government and SA Health policy in addition to HeartAI policy for the management of corporate devices generally. This includes security practices such as:

  • Timed automatic locking of screens.
  • Device monitoring and remote support capabilities.
  • Restricted permissions by default.

HeartAI personnel have been provided physical locations within SA Health premises for the ongoing performance of duties. These physical locations are typically behind locked doors with personnel access corresponding to the permissions assigned to a SA Health employee ID.

References:

15. Does HeartAI ensure that the cabling, line facilities and power supply supporting voice and data communications are protected with physical and environmental controls?

In addition to the above statements concerning the HeartAI deployment to Microsoft Azure, HeartAI administrator and developers are required to maintain secure control of their devices and working environments. This includes basic awareness of the sensitive nature of their environments, such as sensitive information on visible monitors or the possibility of sensitive discussions being overhead. HeartAI team members are expected to operate with a level of due diligence and rigour with sensitive information

Technical controls are maintained for HeartAI usage of corporate devices. Typically these are corporate devices of SA Health or an approved institution. These controls include the automated locking of monitors following short idle periods and the automated disconnection of interfaces to secure environments such as VPN connections. HeartAI team members are expected to operate with a level of due diligence and rigour with sensitive information and generally.

References:

16. Does HeartAI ensure that access to information system facilities dedicated to computer processing is physically restricted using physical controls and access is granted as per the legitimate business responsibilities?

In addition to the above statements concerning the HeartAI deployment to Microsoft Azure, HeartAI team members are obligated to have an understanding and awareness of their working activities and physical environment. This includes understanding any site management and associated policies for HeartAI site locations or any other site locations that HeartAI team members visit. Team members must understand the importance of sensitive and restricted sites and any obligation of information classification. Team members should understand access mechanisms to private or restricted sites, and only operate within their associated physical access credentials. This also includes maintaining diligence in relation to practicing these obligations generally, such as by only allowing approved guests to visit private or restricted sites and insisting that all site visitors perform any required access procedures.

References:

Operations security

17. Does HeartAI maintain policy and process for change management with Information Assets and ensure that corresponding governance authorities meet regularly to review and report on the all the scheduled and failed changes?

The HeartAI change management process is formally documented as policy. Fundamentally, change management occurs through addition, removal, or modification to HeartAI source code, with source version control managed with the Git and GitHub software. This provides a management framework to review source code modifications with appropriate HeartAI administrator oversight. Project and task management are also coordinated through this process, and the successful deployment of software to corresponding environments follows from planned deployment strategies and timed processes. This also includes the maintenance of and reference to a HeartAI knowledge base with task objectives, progress, and outcomes.

HeartAI policy generally describes responsibilities and obligations with reporting to and coordinating with corresponding governance authorities. These processes specify how HeartAI team members must inform and consult these authorities in relation to change management generally.

References:

18. Does HeartAI ensure that all the servers, workstations and laptops are installed with approved malicious software detection or system integrity software that are capable to continuously monitor for any intrusions?

HeartAI provides policy for the management of corporate and personal devices, for the management of sensitive information, and for the security management of personnel. There are three typical use cases for HeartAI devices:

  1. HeartAI servers within Microsoft Azure.
  2. HeartAI servers within Red Hat OpenShift.
  3. HeartAI development environments within SA Health standard operating environments.

For (1), these servers are rarely used directly and exist primarily to manage (2). Microsoft Azure manages the servers for (1) and provides a rigorous service-level agreement and certification to compliance standards. For (2) these servers are typically deployed as hardened and constrained operating system images, provide mechanisms for automated updating and patching, and are locally separated to relatively small scoped environments. In addition, these servers are integrated with extensive logging, monitoring, and observability, through the implementation of Prometheus and Grafana, in addition to event management through the composition of an Elasticsearch, Fluentd, and Kibana (EFK) framework. Further to these, HeartAI also provides automated and continuous assessment of software vulnerabilities, compliance deviations, process execution monitoring, and abnormal behavioural pattern profiling with techologies such as Red Hat Advanced Cluster Security and Snyk.

References:

19. Does HeartAI ensure that backup schedules, location and access controls are developed, documented, and implemented by the appropriate personnel?

HeartAI provides formalised policy concerning business continuity, disaster recovery, and auditability. In relation to backup schedules, these approaches are implemented through two primary mechanisms:

  1. Backup capabilities provided by Microsoft Azure.
  2. Software version control approaches that implement declarative and reproducible software.

For (1), these capabilities are rigorous applied to stateful data and are typically replicated through a high-availability data persistence paradigm. Databases are configured with a retention period of 7 days. Logs are configured with a retention period of 6 months. Microsoft provides rigorous assurance with service assurance through specified service-level agreements and certification to compliance standards.

For (2), the HeartAI source code is managed with best practice approaches with change management and project and task planning. This includes corresponding policy for change management and for access and use of the HeartAI source code repository. HeartAI implements both declarative software and infrastructure-as-code paradigms, which allow HeartAI software to be reproducibly deployed, rolled back or forwards, and transported to different environments where applicable.

20. Does HeartAI maintain platform postures for system hardening, event logging, and time synchronisation?

HeartAI platform components are primarily deployed at two levels: Within Microsoft Azure and within an overlay installation of Red Hat OpenShift. Within both of these environments, hardening occurs through a variety of automated and continual detection and assessment mechanisms for software vulnerabilities, compliance deviations, abnormal process execution, and behaviour pattern profiling. Within Microsoft Azure supporting software includes Azure Log Analytics, Azure Monitor, Azure Network Watcher, and Azure Sentinel. Within Red Hat OpenShift environments supporting software includes Prometheus, Grafana, and the deployment of an Elasticsearch, Fluentd, Kibana (EFK) event-management framework.

Operating system environments are typically specified with minimum deployable images with security preferred constraints, such as Red Hat Enterprise Linux with the inclusion of SELinux capabilities. These environments are monitored for out-of-date software and are often automatically patched with zero-downtime rolling update paradigm. A broad range of logs and metrics are gathered with the inclusion of logging, monitoring, and observability technologies.

Time sychronisation is provided through Red Hat OpenShift by sychronisation with the Red Hat Network Time Protocol servers deployed in a high-availability configuration.

References:

21. Does HeartAI ensure that development, test and production environments are separated operationally, physically, or logically?

HeartAI supports a variety of deployment environments:

  • Local machine development environments.
  • Local machine testing environments.
  • Local machine production environments.
  • Microsoft Azure development environments.
  • Microsoft Azure testing environments.
  • Microsoft Azure production environments
  • Red Hat OpenShift development environments.
  • Red Hat OpenShift testing environments.
  • Red Hat OpenShift staging environments.
  • Red Hat OpenShift production environments.

HeartAI local machine devices may either be corporate or personal devices, including SA Health corporate devices. HeartAI policy specifies that for the management of sensitive information local devices must be SA Health corporate devices or cross-organisational corporate devices with the authorisation of SA Health.

For the Microsoft Azure and Red Hat OpenShift environments, these environments are logically separated through a variety of software-defined networking (SDN) mechanisms. Network traffic through these environments is typically routing through an appropriate virtual network appliance with corresponding logging, monitoring, and observability.

References:

22. Does HeartAI ensure that audit trail logs are active at all times, reviewed at regular intervals and protected from unauthorized access, modification and destruction?

HeartAI maintains a suite of logging, monitoring, and observability frameworks, and captures a broad range of relevant logs and metrics for routine and automated audit. These are further integrated with security information event management deployments. This includes logging capabilities within Microsoft Azure provided with technologies such as Azure Log Analytics, Azure Monitor, Azure Network Watcher, and Azure Sentinel. For the HeartAI OpenShift environment, a variety of logs and metrics are gathered by Prometheus and Grafana. In addition, within the OpenShift environment, HeartAI manages an Elasticsearch, Fluentd, and Kibana (EFK) event management deployment.

References:

23. Does HeartAI maintain policies and practices for monitoring and remediating vulnerabilities?

HeartAI operational environments within the SA Health network are continuing monitored for software vulnerabilities, compliance deviations, abnormal process executions, and behavioural profile abnormalities. This includes the use of integrated capabilities within the Microsoft Azure environment and additional technologies such as Red Hat Advanced Cluster Security. As a further extension, HeartAI source code is routinely assessed for software vulnerabilities and compliance vulnerabilities with the Snyk source code assessment framework. Organisational processes are implemented for the remediation of any detected vulnerabilities, with a corresponding triage process for the prioritisation of remediation.

References:

Communications security

24. Does HeartAI ensure that networks are segregated or divided into separate logic domains so that access between domains can be controlled by means of secure devices?

HeartAI networks are separated logically both within the Microsoft Azure cloud networking environment and the OpenShift overlay software-defined networking (SDN) environment. In addition, within the OpenShift SDN an additional layer of logical SDN-based separation is provided through a service-mesh network topology. Traffic between these logically separated networks occurs through a variety of virtual network appliances and a broad suite of logging, monitoring, and observability frameworks are deployed.

References:

25. Does HeartAI ensure that access to network connected services is authenticated and controlled based on the level of trust attributed to the user/device and the Information Assets classification? Including technologies such as secret exchange, second factor authentication, and device health profiling.

HeartAI application, service, and network endpoints are exposed through a permissions-based process. This utilises the HeartAI identity and authentication access management framework which includes the capability for identity federation with the SA Health Health Active Directory (HAD) identity provider. Native support exists for multi-factor authentication including integration with phone-based authentication applications.

References:

System acquisition, development and maintenance

26. Does HeartAI ensure that information security audits, assessments and penetration tests of information resources are performed at least annually?

HeartAI provides policy in relation to ongoing security review and audit. This specifies that security review and audit must be performed at least every 12 months, and that the outcomes and artifacts of this assessment must be shared and coordinated with stakeholders and governance authorities.

Reference:

27. Does HeartAI ensure that routing and cryptographic controls are incorporated in shared networks that extend across organizational boundaries, including any public network infrastructure?

For the HeartAI deployment within the SA Health digital network, the network configuration is constrained to only be deployed within this network. As such, the SA Health HeartAI deployment does not expose IP addresses to the public internet and only provides routing to network endpoints through private virtual network extension. This occurs with through specific route table configurations that enforce routing through an Azure Firewall that is managed by SA Health.

In relation to cryptography, HeartAI enforces encryption for all network-level traffic by default. This includes both network traffic from SA Health hosts to HeartAI private network endpoints, and internal network traffic beteeen the HeartAI private network hosts.

References:

28. Does HeartAI ensure that security requirements are documented as a prerequisite to system acquisition, development and maintenance?

Security is a central and cross-cutting concern with HeartAI platform components generally. HeartAI policy provides guidelines to the expected level of diligence in relation to information security and this includes policy corresponding to change management governance. These policy definitions require consideration of information security impact to major changes to platform or organisational deployments generally, in addition to specific change management processes for assets maintaining potentially sensitive information.

References:

Suppliers and third parties

29. Does HeartAI ensure that all third-party consultants, contractors, and vendors comply with all SA Health Information Security policies and are held accountable to the same level of security compliance as employees?

HeartAI policy specifies that third-party consultants, contractors, and vendors are expected to understand and follow corresponding HeartAI policy as a formal obligation of the provisioning process.

References:

Information incident management

30. Does HeartAI track all security incidents, review the resolutions provided and update policies to address new areas of risk?

HeartAI policy provides formal guidelines for the management and response to incidents, including appropriate reporting of resolutions. This includes documenting any significant security risks, incidents, technical issues, and policy updates. The initial state, change process, and resolutions are documented and maintained within HeartAI knowledge bases. This is primarily managed through the HeartAI implementations of Git and GitHub, where the knowledge base is maintained, in addition to project, task, and change management generally. HeartAI personnel, including employees and third-party providers, are expected to understand their responsibilities and obligations with following these processes when performing their duties and engaging with HeartAI generally.

References:

Information security aspect of business continuity management

31. Does HeartAI ensure that a business continuity plan, including the security requirements (confidential, integrity and availability) is completed, including specifying responsibilities for each task and a list of services to be recovered, in priority order, and that it is distributed to individuals who are responsible to implement this plan?

For HeartAI deployments within SA Health, operational services may have the potential to impact business and clinical decision-making. There is an expectation for HeartAI to maintain responsibilities and obligations with service assurance and business continuity generally. In the context of service engagement and delivery, this entails the specification of service expectations and service level agreements (SLA) that should define business and clinical objectives, operational procedures and points-of-contact, and business continuity and disaster recovery. These responsibilities should be clearly documented and understood by all parties involved in the engagement.

HeartAI policy provides formal guidelines for business continuity generally.

References:

Compliance

32. Does HeartAI ensure compliance with legal, statutory, regulatory or contractual requirements, including the SA Health Information Security Policy Directive?

HeartAI policy specifies compliance to state and federal laws, policies, regulations, and compliance standards, in addition to those of SA Government and SA Health governance authorities. For the SA Health deployment of HeartAI, the relationship of the deployment is that HeartAI services, products, and technologies are procured by SA Health, and HeartAI is the platform and service provider for the management of these environments. As such, these deployments of HeartAI are strictly governed by SA Government and SA Health laws, policies, regulations, and compliance standards generally. These include

In addition, the SA Health deployment of HeartAI is fully contained within the SA Government digital network (StateNet) through virtual private network extension and this deployment within Microsoft Azure is administered through the SA Government Microsoft Azure tenancy and the SA Health management group.

References:

33. Does HeartAI ensure that the sensitive information can be outsourced outside of border and determine which country’s laws and regulations are applicable for cross-border outsourcing?

HeartAI maintains all sensitive information within the SA Government and SA Health digital network in compliance with the corresponding policies of these organisations. This occurs through the following mechanisms:

a. The SA Health instance of HeartAI is deployed within Microsoft Azure in the Australia East and Australia South-East regions.
b. The SA Health instance of HeartAI is administered within the SA Government Azure tenancy within the SA Health management group.
c. The deployment instance is a fully private network with connection to the greater SA Government digital network, StateNet, through a virtual private network extension approach. The SA Health instance of HeartAI does not expose IPs to the public internet with all network traffic routing privately within the greater SA Government digital network.

The above mechanisms ensure that all network traffic and managed information is contained within Australia for the purposes of data sovereignty.

References: