Standard 2: Risk assessment
Our practice undertakes periodic, structured risk assessments of computer and information security and implements improvements as required
The compliance indicators listed in the matrix identify the specific actions that comprise good security practice for Standard 2.
It is assumed the practice will provide appropriate education and training to facilitate compliance with this Standard.
The compliance indicators at level 3 reflect the minimum level of computer and information security acceptable for this Standard. The compliance indicators for higher levels provide the basis for incremental security improvement.
|Risk assessment compliance indicators||Level 1 Initial||Level 2 Repeatable||Minimum||Level 4 Managed||Level 5 Optimised|
|Level 3 Defined|
|2.1 Policy content
||No formal policy
||No complete written policy
||Complete written policy
||Complete written policy, periodically reviewed
||Complete written policy, reviewed annually
|2.2 Policy communication
||Policy not communicated to the practice team
||Policy communicated verbally to the practice team
||Policy communicated in written format to relevant practice team members
||Policy communicated in written format, training provided and all practice team members have access to the policy
||Policy available in written format to relevant practice team members
Regular training for the practice team and communication strategy reviewed against policy
All practice team aware of the content and implications of the policy
|2.3 Staffing responsibility
||No practice team member specifically assigned in Computer Security Coordinator, Responsible Officer, and Organisational Maintenance Officer roles
Practice manager performs these roles as default
|The roles of the Computer Security Coordinator, Responsible Officer and Organisational Maintenance Officer assigned
||Computer Security Coordinator, Responsible Officer and Organisational Maintenance Officer assigned and appropriate training provided
||Computer Security Coordinator, Responsible Officer and Organisational Maintenance Officer assigned and appropriately trained
Decision roles identified (e.g. who can make decisions on secondary use of data requests) and decision makers assigned
Practice team member skills matrix completed
|Computer Security Coordinator, Responsible Officer and Organisational Maintenance Officer assigned and appropriately trained
Practice team member skills mapped to roles, and training identified and planned
Decision making frameworks in place and documented (e.g. secondary use of data decision framework)
||Contacts not recorded systematically
||Contacts recorded in an ad hoc manner
||Contacts recorded using the CISS template
||Contacts recorded and readily accessible to all practice team members
||Contact list reviewed annually to ensure correctness and updated as required
|2.5 Asset management
||Assets not recorded
||Only hardware/physical assets recorded
||Hardware, software, data and electronic assets recorded
||All computer and electronic assets recorded, including hardware, software, data, and certificates
Configurations partially documented
|All assets and all configurations recorded, including paper assets
Network diagrams created
All documentation updated when changed and log of changes kept and annually checked and reviewed
|2.6 Threat analysis
||Not specifically undertaken – left to installers/vendors
||Installer/vendor have completed, but not provided or explained to appropriate practice team member
||Practice threat, vulnerability and controls assessment done and recorded but undertaken primarily by external IT service providers
||Threat, vulnerability and controls assessment completed and recorded
||As for level 3 plus practice team members have full understanding of the threat context and environment
Plan for improvement identified
Process reviewed annually
|2.7 Security management monitoring and reporting
||Reporting to practice management is ad hoc and only initiated when an incident occurs
No ongoing monitoring
|Formal incident reporting process in place but no proactive monitoring
||Regular reporting and analysis undertaken
|Regular reporting and analysis undertaken
Monitoring undertaken periodically
Regular item on practice meeting agenda
|Established reporting schedule
Established monitoring schedule
Analysis to identify improvements
Regular item on practice meeting agenda
||No ongoing training provided for practice team
||Computer Security Coordinator trained as required and other practice team members at induction only
||At least annual security training updates to all practice team members
||Special topics presentations (at staff meetings)
||Regular planned education and training, and security updates to all practice team members
|2.9 Data breach response and recording
||No formal process documented
Informal breach reporting only
|Formal data breach process implemented and used
||All data breaches reported via a formal process, fully reported and documented
||All data breaches reported via a formal process, fully reported and documented, and the incident reviewed
Ad hoc training to practice team members
|All practice team members trained to recognise, report and document all data breaches
Post-breach analysis and training for all practice team members
|Adapted and reproduced with permission from Dr Patricia Williams
Helpful templates for this Standard
Templates 2.1–2.27 will assist in achieving compliance. Completion of these templates will ensure you have fully documented the requirements of this Standard.
Information security system requirements differ across practices. It is therefore important for all practices to complete a risk analysis of their particular system and security needs, and to document the policies and procedures that the practice team will need to adhere to. This will provide assurance of availability, integrity and confidentiality of all information held within the practice’s clinical and business information systems. Regardless of the size of the practice, it is imperative that there is an understanding and analysis of the threats and vulnerabilities that practices are exposed to, and the possible risks to the computer and information systems. Then the most appropriate security controls can be put in place to minimise these risks. Therefore the first task in ensuring effective information security is to undertake a risk assessment.
The method suggested in this Standard has been adapted from established risk assessment and management processes and simplified to make it a practical and straightforward process for practices to undertake. The risk management process involves establishing the risk profile and appropriate risk mitigation process.
There are elements that require time to document, such as the asset register, however this information is subsequently reused in the business continuity and information recovery plans. Avoidance of this activity will mean that a practice does not have a strong foundation for its computer and information security choices and may not have effective protection of all practice information. In addition, documentation of the risk assessment provides evidence of a proper and systematic approach to security and demonstrates defensible governance. Records should be retained on physical and information assets. As an ongoing practice, each breach in security (accidental or intentional) should be recorded.
2.1 Policy content
The practice policy for assessing the risks of the practice information systems needs to be developed, and periodically reviewed. This policy will describe the roles and responsibilities of technical service providers. It will also include the monitoring processes that should be in place for compliance with practice policies. Further, it will detail the vulnerability management, risk assessment and information security breach reporting procedures.
It is a requirement of the PCEHR Rules 2012 that organisations review their PCEHR system policy at least annually and when any new or changed risks are identified. In conducting such a review, the practice must consider:
- potential unauthorised access to the PCEHR system using the healthcare provider organisation’s information systems
- potential misuse or unauthorised disclosure of information from a consumer’s PCEHR by persons authorised to access the PCEHR system via or on behalf of the healthcare provider organisation
- potential accidental disclosure of information contained in a consumer’s PCEHR
- the increasing risks and potential impact of the changing threat landscape (e.g. newer types of security threats such as ransomware)
- the impact of any changes to the National eHealth record system that may affect the healthcare provider organisation
- any relevant legal or regulatory changes that have occurred since the last review.
2.2 Policy communication
The policy should be in written format and communicated to relevant practice team members.
2.3 Staffing responsibility
Select the person or persons in the practice team who will undertake the coordination of computer and information security in the practice – the Computer Security Coordinator. Refer to Section 1.3 for a definition of the role and responsibilities of the Computer Security Coordinator.
In addition, to comply with the legislation for participation in the National eHealth record system, the organisation must identify practice team members for two key roles – the Responsible Officer (RO) and the Organisation Maintenance Officer (OMO). Refer to Section 1.4 for a definition of the role and responsibilities of the RO and OMO.
Systematically record all technical service provider contact details.
2.5 Asset management
Developing an asset register may require assistance from your technical service provider. The asset register documents the computer hardware, software and information systems used in the practice. The register also records the configuration of the systems that will be used when the business continuity or information recovery plan is invoked. The asset register must be updated as each new item is purchased by the practice or new service or application installed. The Computer Security Coordinator is usually responsible for maintaining the asset register.
Refer to Templates 2.3–2.22 for examples of how to record this information. The assets are grouped as follows:
- physical assets: computer and communications equipment, mobile devices, smart phones, tablet devices, medical equipment that interfaces with the computer systems, backup media and uninterruptible power supplies. Diagrams showing the layout of the network and computers are a useful resource. It could include electronic information assets: databases, electronic files and documents, image and voice files, system and user documentation, business continuity and information recovery plans
- software assets: application programs, operating system, communications software. Include all clinical and practice management software, as well as email, firewall, backup, virus checking and other utilities. Original software media and manuals should be stored securely
- personnel assets: contact details of key members of the practice team and external service providers should be recorded as part of the human resources policy (see Templates 2.1 and 2.2)
- paper documents: contracts, operating and professional guidelines.
2.6 Threat analysis
By doing a threat analysis the practice will better understand and put in place planning to minimise the impact from potential threats and vulnerabilities that could adversely affect the practice. This includes financial loss, breaches in confidentiality, information integrity and availability, and patient confidence. Template 2.24 has been formulated with the common threats and vulnerabilities that face a general practice, and suggested controls to minimise the risks and impact of these.
The threats have been categorised into three areas:
- human (unintentional and deliberate): for example, the theft of a laptop containing clinical or business information, or inadvertent viewing of a patient’s information by non-practice staff or another patient
- technical: for example, a hard disk crash or data corruption from a virus
- environmental: for example, a natural disaster such as a bushfire or flood.
Once the threats and vulnerabilities have been identified, the existing mitigation strategies and security controls implemented in the practice need to be added to Template 2.24. Following this step, the existing controls can be compared to those suggested and any additional required controls (actions to take) added to the table. This will form the practice plan for improving the security of practice computer and information systems. This is referred to as a gap analysis.
To decide the actions to take, consideration must be given to the cost-effectiveness of controls for your practice in order to minimise the risks. Control selection will be based on cost, ease of use, integration with normal workflow, importance to practice, and objective of protection. Selection of controls is also impacted by the financial and time constraints of the practice, as well as the technical skill of the practice team.
Note: No system can ever be 100% secure and there will always be some residual risk after the implementation of security controls. This is unavoidable. Indeed, some level of risk acceptance may be necessary because of low possibility of occurrence and the high cost to protect against a risk.
2.7 Security management monitoring and reporting
Document the planned monitoring for compliance with legal obligations and establish a periodic review schedule for the risk assessment process. This is particularly important when computer equipment and software are updated, new uses of information are embarked on (such as health information exchange, the national eHealth record system [PCEHR system] and Healthcare Identifiers Act 2010 and secondary use of information), practice team members leave or new practice team members commence, when changes occur to legislation or professional requirements, or following incidents or breaches in information security.
Effective communication and education for the practice team about the risks that the practice computer and information systems are exposed to is an important aspect of risk management. Discussion at practice meetings and including these processes within the governance of the practice are essential. There is also a requirement under the PCEHR legislation and the participation agreement that the policy for interaction with the PCEHR system is written, communicated, enforced and reviewed at least annually (PCEHR Rule 25), and further, that GPs and the practice team are educated in their legal responsibilities in regard to interaction with the PCEHR system. How this is to be undertaken should be written into the practice PCEHR system policy.
2.9 Data breach response and recording
Data breaches can occur through the loss or theft of laptops, mobile devices, removable storage devices, hard disk drives and USB sticks. They also occur through unauthorised access of databases from outside the organisation through hacking, or from inside the organisation through access or disclosure by employees outside the bounds of their roles and authorisation. Not all breaches are intentional. Providing personal information to the wrong person or sending it to the wrong address (physical or electronic) can occur, and sometimes insufficient care is taken to confirm the identity of a person to whom information is disclosed. Data breaches are not limited to electronic records and the security of paper records must also be considered.
The practice policy will document the procedures on the detection, action and reporting of breaches of security. This policy will also incorporate identified ongoing training needs of the practice team, reporting procedures and consequences for noncompliance with the policy. Instructions on what action should be taken if a data breach occurs or is suspected are given in a pro forma in Appendix C. A copy can also be found in Template 2.27.
Australia has mandatory data breach notification requirements for the eHealth record system by the System Operator, registered repository operators and portal operators. The System Operator must notify the Office of the Australian Information Commissioner (OAIC) if a data breach to the PCEHR occurs. (Under the PCEHR Act 2012, this is termed a ‘notifiable’ data breach.) Registered healthcare organisations are not required to report breaches to the OAIC. Breaches of security that do not relate to the PCEHR system are out of scope of the mandatory data breach notification. However, the OAIC encourages voluntary data breach reporting in accordance with the Privacy Act 1988. Further information on voluntary data breach notifications can be found on the OAIC website.
Breach or suspected breach notification
Under the conditions of the PCEHR Participation Agreement, Healthcare Provider Organisations must notify the System Operator if a breach or suspected breach has occurred in the circumstances where:
- there is a non-clinical, PCEHR system-related error in a record that has been accessed via, or downloaded from, the PCEHR system, or
- the security of the PCEHR system has been compromised by the healthcare organisation or one of its employees or by the use of its equipment.
The Data Incident/Breach Report form (Appendix C) can be used to record all incidents: both accidental and intentional. The information recorded can be used to report incidents as required under the PCEHR Participation Agreement to the System Operator. In addition, the form could be used by the organisation to report any other (future) potential mandatory breach notification to the OAIC. This form can also be found in Template 2.27.
2.9.1 What to do if you have or suspect a data breach
All breaches or suspected breaches should be recorded and practice management notified, whether or not the breach is considered major or minor in nature.
Based on the OAIC advice, these steps should be followed:
- Containment of the breach
- The first step is to contain the breach so that no further damage can be done. Take whatever steps are possible to immediately contain the breach. This may be to isolate the system or disconnect from the internet if this is likely where the breach occurred. If it is not practical to shut down the system (or it might result in a loss of evidence) then suspend user access to the records affected, or suspend a specific user’s access.
- Assess whether steps can be taken to mitigate the harm a consumer may suffer as a result of a breach.
- Initial assessment of the cause of the breach
- Appoint someone to lead the initial assessment of the breach. This may require technical assistance as the person will need experience in evaluating the cause and be able to make recommendations.
- The analysis will need to consider what personal information the breach involves, what was the cause of the breach, what the extent of the breach is, and what is the potential impact (harm) to individuals of the breach.
- Be mindful of not destroying evidence that may be helpful in determining the cause of the breach or in rectifying the problem.
- Ensure appropriate records of the suspected breach are maintained, including the steps taken to rectify the situation and the decisions made – use the Data Breach/Incident Report form, which can be found in Appendix C and Template 2.27.
- Notification of the breach
- Determine who needs to be notified, both internal and external to the practice, and where relevant:
- notify the practice management
- notify the police if theft or criminal activity is suspected
- notify the PCEHR System Operator (as per the PCEHR Participation Agreement)
- notify the OAIC.
- Investigation of the breach
- Ascertain if the information is encrypted or de-identified.
- Identify who is affected by the breach.
- Evaluate what the breach information could be used for.
- Evaluate the risk of harm from the information disclosed by the breach.
- Determine the risk of further breaches of this type.
- Determine if this is a systemic or isolated incident.
- Evaluate what harm could occur to the practice as a result of the breach.
More detail and further guidance on this can be found in the OAIC documents Data breach notification guidelines (April 2012) and the Mandatory data breach notification in the eHealth record system (September 2012).
Recommendations: Detail the steps that will be put in place to prevent further breaches. For instance, should vulnerability (penetration) testing of the network be undertaken?