Information Governance Policy and Development Plan for Aseptika Ltd

Document version IGToolKitASP0001.3

17th December 2015

 

Introduction

This requires that named individuals take responsibility for co-ordinating, publicising and monitoring standards of information handling within the organisation and for developing and implementing an Information Governance (IG) improvement plan (also known as implementation or work plan).

The Information Governance Lead(s) also need(s) to ensure that IG Toolkit assessments are submitted as required.

The named individual is: Dr Kevin A Auton Ph.D (Managing Director).

 

Policy of appointing an IG Lead

The senior management will consider the responsibilities of an IG Lead and decide whether these can be met by one member of staff or whether the responsibilities should be shared between a number of staff.

As Aseptika has multiple locations from where its staff work, we will appoint an overall lead with our other staff supporting at the premises level. Those appointed should have sufficient seniority and authority to ensure that any necessary changes in information handling within the organisation can be implemented and enforced.

For example, implementation models may include:

  • If a contractor is supported by a substantial head office function, a member of head office staff may be appointed to co-ordinate information governance across the organisation however there will still be a need for a local IG lead to co-ordinate local IG activities such as developing an improvement plan relevant to the local circumstances and supporting a monitoring visit from the commissioning organisation.
  • If a contractor runs an individual business the IG lead would typically be a senior permanent member of the staff.

It is our policy that we ensure confidentiality as a key part of the clinical governance requirements in contractual frameworks. IG responsibilities may be combined with other similar responsibilities, e.g. where there is a contractual framework requirement for an organisation to have an identifiable clinical governance lead, this individual might also act as the IG Lead.

We will have a written assignment of IG Lead responsibility. This document forms this written assignment with the signatories at its end.

All staff with IG leadership responsibilities must be a signatory to this document.

 

Training and Support for the IG Lead

Our policy is that an IG Lead needs to be sufficiently trained to undertake their key responsibilities.

Training should cover the Data Protection Act, security, confidentiality, appropriate information sharing and Freedom of Information Act requirements (if this Act applies to the organisation).

Training may be undertaken through a variety of methods, for example through in-house training packages produced by multiple premises organisations, courses provided by a commercial training company, or where available, training provided by a commissioning organisation.

The on-line NHS Information Governance Training Tool should be used at a minimum.

The NHS IG Training Tool comprises a structured e-learning programme with Introductory, Foundation and Practitioner level modules covering all aspects of IG. Aseptika is registered to use the IGTool an account has been created. Only the IG Lead should have access to this account on a need to know basis.

An organisation administrator (ideally the IG Lead) should be nominated and given the appropriate permissions to monitor staff training.

Members of staff are able to register on the Tool. As part of the user registration process, staff will be asked for their organisation's ODS code, so it is important to ensure staff know what the code is before they attempt to register.

The IG Lead will have access to sufficient support to do their job and if s/he is not a health or care professional (e.g. pharmacist, optician, ophthalmologist, GP, dentist, etc) or a senior manager, they will need access to such a person for support with queries.

 

Responsibilities of the Information Governance lead

The IG lead is not required to carry out all the work necessary to meet the NHS IG requirements, but should be able to supervise and direct the work of others where necessary.

Table 1 provides a summary of the key responsibilities of the Information Governance lead.

 

Table 1: Key responsibilities of an Information Governance lead

  • ensure there is an up to date IG policy in place;
  • ensure that the organisation’s approach to information handling is communicated to all staff and made available to the public;
  • coordinate the activities of staff given Data Protection Act, confidentiality, information sharing and Freedom of Information Act responsibilities;
  • monitor the organisation’s information handling and sharing activities to ensure compliance with law and guidance;
  • ensure staff are sufficiently trained to support their role;
  • ensure that the organisation submits their annual IG Toolkit assessment;
  • support monitoring visits from the commissioning organisation (where appropriate).
  • ensure that the organisation is aware of information incidents and that there are policies/procedures for reporting information incidents.

 

Creating an Improvement Plan

A duty of the Information Governance Lead is to develop a locally tailored IG improvement plan which documents both the current level of compliance with the NHS IG requirements and the targets that have been identified to progress to the next level of compliance.

To create the improvement plan, the IG Lead should work through each IG Toolkit requirement and consider the current compliance status and next steps to improve compliance.

By setting targets and entering comments within the IG Toolkit an improvement plan can be automatically generated.

As evidence of completed work is accumulated details should be entered into the IG Toolkit and the compliance level will be automatically updated. For further detail, see the Improvement Planning guide on the Help page of the IG Toolkit website.

Aseptika has implemented an internal process whereby we meet once each week to review our IG Policy, our Goals and Targets and implementation. Notes and minutes are written and filed.

 

13-115 Information Governance Management

There is an information governance policy that addresses the overall requirements of information governance.

 

Requirement Description

There is a need to ensure that everyone working for or on behalf of Aseptika (including temps, volunteers, locums and students) is aware of the organisation’s overall approach to IG and where underpinning procedures and processes can be found.

This will be achieved through our Information Governance policy as described in this document.

 

Developing our Policy

Responsibility for developing and/or maintaining the currency of the policy sits with the organisation’s Information Governance Lead and should be agreed by a senior management member of the organisation, for example the Directors or the Board of Directors.  

Best practice requires that the policy is regularly reviewed and updated in the light of that review. Any amendments to the policy over time also must be signed off by a senior representative.

 

Table 1: Key content of Aseptika’s Information Governance policy will include:

A section specifying why the policy is required – i.e. to safeguard the movement of personal identifiable data in the organisation;

An overview of how information will be handled by the organisation – maintenance of confidentiality, safe havens, storage of data, consent to view data, situations where disclosure may be required;

A description of accountability and responsibility for the policy – i.e. details of who is the IG lead in the organisation and job roles of any support staff;

A process for monitoring the policy;

Staff duties and responsibilities for information governance (maintaining confidentiality of data, ensuring secure storage of data, being aware of situations where disclosure may be required);

A description of how the various areas within the policy link together;

Actions to be taken if the policy is breached – i.e. sanctions against staff, remedial work on the part of those responsible for IG procedure.

 

The policy should be made available to all staff members, including administrative staff. Particular attention should be drawn to the section of the policy setting out staff responsibilities for compliance and also to the procedures that underpin the policy.

The IG Policy for Aseptika makes full reference to this document.

  

13-116 Information Government Management

All contracts (staff, contractor and third party) contain clauses that clearly identify information governance responsibilities.

 

Requirement Description

One of the ways in which Aseptika ensures that it fulfils our legal and other responsibilities regarding confidential information is to ensure that all staff members (including temps, locums, students and volunteers) are fully informed of their own obligations to comply with information governance requirements.

 

Contractual Clauses

All organisations have a common law duty as well as a specific requirement under the Data Protection Act 1998 (Aseptika’s Registration with the Data Protection Act is: CSN9471795) to ensure that confidential information is processed lawfully and protected from inappropriate disclosure.

Breach of confidence, inappropriate use of patient/service user records or abuse of computer systems may lead to disciplinary measures including for NHS contractors, loss of their NHS contract.

Fulfilling the organisational duties necessarily requires that everyone working for or on behalf of Aseptika complies with information governance requirements.

References to staff members therefore includes employees, temporary and bank staff, locums, volunteers, students on placement etc.

Our policy is to include a specific and explicit clause in the contract of employment, volunteer agreement or contract for services (e.g. IT services) stating an obligation to keep personal information confidential; otherwise, Aseptika has little or no defence in the event of an accidental or intentional breach by a member of staff or third party.

The contract will also provide a formal record that Aseptika has taken steps to ensure that staff recognise their own responsibility for protecting health and care information.

Although setting out the responsibilities of staff members will not automatically absolve the Company of all blame, it will clearly be of assistance should a member of staff deliberately and intentionally, or recklessly, breach the law.

 

Content of the Clause

The contract clause will reference the organisation’s staff confidentiality code of conduct (where a code is required, as a source of further information about how the organisation expects its staff to behave in respect of maintaining the confidentiality and security of health and care information.

 

Table 1: Suggested Contract Clause for Individual Staff Members:

You may not during or after the termination of your employment, disclose to anyone other than in the proper course of your employment or where required by law, any information of a confidential nature relating to the company or its business or customers.

Breach of this clause may lead to dismissal without notice. Guidance on standards expected can be found in the Staff Handbook and in your employment contract.

 

For staff members that don’t have a contract of employment, for example locums, volunteers or university students on temporary placement, Aseptika’s Policy is to put in place an agreement which obligates the individuals to safeguard personal information and makes reference to the confidentiality code of conduct. The individual could be asked to sign a stand-alone confidentiality contract or, where it exists, be asked to sign a written locum contract.

For third parties, care needs to be taken to ensure there are appropriate confidentiality and non-disclosure clauses in contracts with suppliers and service providers where they may have access to personal or sensitive information. This will include those third parties who may incidentally have access, (e.g. cleaners) and those with access to the systems which hold such information (e.g. IT system suppliers or software support).

 

Ensuring Compliance

To support compliance with these obligations, Aseptika must ensure that contracts with staff, contractors and third parties contain clauses which clearly set out their responsibilities for ensuring and maintaining good information governance practice.

Aseptika’s policy is undertake an audit of personnel records, contractor and other third party contracts and determine how many have written contracts, and of those, which contain clauses that identify responsibilities for information governance, linked to disciplinary procedures (where appropriate).

Where any gaps exist, a process should be implemented to ensure that appropriately worded clauses are issued to, signed and incorporated within the contracts of existing staff, contractor and third parties; and all new members of staff and new contracted third parties sign a contract containing an IG clause.

 

Addressing Security in Third Party Agreements

Aseptika, like many organisations will have individuals from third party companies gaining access to their assets or premises. These might include:

  • other healthcare professionals;
  • contract cleaners;
  • security consultants;
  • auditors and accountants;
  • IT suppliers and other consultants.

It is a key part of Aseptika’s policy that these third parties are made aware of information governance requirements; what they can and cannot do, and who they should contact if things go wrong.

Aseptika should conduct a full risk assessment to determine any potential threats to networks, systems and locations from third party operatives.

The extent of the risk assessment should be appropriate for the role of the third party contractor. For example, a risk assessment for cleaning contractors will be different to that carried out for an IT contractor connecting to the organisation’s network. Temporary access will also see different considerations to long-term access. It is essential that the nature and level of access is determined before the risk assessment is conducted and before the information governance elements of the contract are completed.

The Company will also see to know what safeguards the third party has in place. For example, does the third party:

  • have adequate security controls, policies and training?
  • screen their staff?
  • have the necessary skills to train their staff in information governance issues?

If not, Aseptika will agree training and awareness requirements with the third party.

Aseptika’s policy is that it will take all reasonable steps to ensure that the contractors and support organisations to whom personal information is disclosed comply with their contractual obligations to keep personal information secure and confidential.

Contracts with 3rd party data recipients must always include a clause requiring incidents to be reported to the data provider.

A copy of the Third Party Non-Disclosure Agreement is available. Key relevant items include:

Table 2: Key components of third party non-disclosure agreements

Specific reference to Data Protection and security issues, such as:

  • notification of the fact of processing data to the IG Lead;
  • obligations to comply with limits set by Aseptika;
  • the security and data protection standards that apply to both parties;
  • whether the contractor can act independently or only on instruction from Aseptika.

Specific reference to freedom of information issues, such as:

  • duty to disclose;
  • exemption from disclosure provisions;
  • records management processes;
  • responsibility for freedom of information applications.

Additionally:

  • penalties for breach of the non-disclosure agreement;
  • a provision to indemnify the organisation against breaches by the third party;
  • responsibilities for costs, e.g. for security audit, subject access, for handling information requests;
  • incident-reporting requirements, contracts with 3rd party data recipients must include a clause requiring incidents to be reported to the data provider.

 

Our primary security process is not to allow third parties access to any patient-related data unless absolutely necessary.

Should this be necessary, there should be a mechanism in place that provides Aseptika with assurance that information governance requirements have been met.

For third party contractors, this could take the form of viewing the third party contractor’s security policies, procedures or controls to ensure they are acceptable, complete and up to date.

Alternatively, the contractor could sign to confirm they adopt the organisation’s own information governance policies and procedures, or an independent assurance certificate could be provided by the contractor (for example, an ISO 27001 certificate).

Third party access may be granted to electronic systems and networks. For example, the software for a patient record may be maintained by a contractor, under contract. In this case it is quite likely that the supplier’s staff will have significant access to personal data. Care needs to be taken to ensure there are appropriate confidentiality and non-disclosure clauses in these contracts.

 

13-117 All staff members are provided with appropriate training on information governance requirements.

To maintain information handling standards in the organisation staff should be provided with appropriate training on information governance.

 

Information Governance Awareness and Training

It is essential that everyone working for or on behalf of Aseptika is fully informed about Information Governance (IG) procedures and in particular given clear guidelines about their own individual responsibilities for maintenance of good IG practice.

 

Ensuring Staff are Effectively Informed about Information Governance at Aseptika.

Measures must be put in place to ensure that all staff members are fully informed of the procedures implemented to ensure Information Governance requirements are met.

Aseptika will ensure that appropriate IG training is made available to all staff, including temps, locums and volunteers.

This document forms part of the clearly documented and communicated process for making all staff aware of the availability and importance of training.

All staff will be provided with basic IG awareness training and informed where support and further information are available. Particular emphasis should be placed on how the requirements affect their day to day work practices.

All staff members who have routine access to confidential information should be provided with additional IG training.

All new staff members should be provided with IG training within a short time of taking on their post.

 

Training Needs Assessment

To identify appropriate training, a training needs assessment could be carried out. Only staff trained in Information Governance will be allowed access to patient information.

For those with the need for access to patient information, such an assessment will generally consist of the following steps:

  • an assessment of the skills and competencies required to perform a particular job, with emphasis on the importance of that skill-set to the job.
  • an assessment of the current level of skills and competencies of the staff member performing the job;
  • a comparison of the two assessments and identification of any gaps between the two, i.e. does the person performing the role have, or have access to a person with, sufficient skill and knowledge to enable successful performance;
  • identification of appropriate training to meet the skills/competency gap.

  

Training

Aseptika will use the NHS IGTT.

For the purpose of satisfactorily completing the IG Toolkit, training will be documented for evidence purposes.

The materials are available from the NHS IGTT website at: https://www.igtt.hscic.gov.uk/igte/index.cfm.

Required reading includes:

  • Introduction to Information Governance (for staff with routine access to patient identifiable information).
  • Information Governance: The Beginner's Guide (Vers 1.04) (for staff who do not have routine access to patient identifiable information.

  

13-202 Confidential personal information is only shared and used in a lawful manner and objections to the disclosure or use of this information are appropriately respected.

The Data Protection Act 1998 provides conditions that must be met when processing personal information. In addition, where personal information is held in confidence (e.g. details of care and treatment), the common law requires the consent of the individual concerned or some other legal basis before it is used and shared. Staff must be made aware of the right of an individual to restrict how confidential personal information is disclosed and the processes that they need to follow to ensure this right is respected.

 

Use and Disclosure of Personal Information

Data Protection Act 1998 Conditions

The Data Protection Act 1998 provides eight Principles that apply to all use and disclosure of personal information. In addition to satisfying these eight Principles, Aseptika must also satisfy one condition from a supplementary schedule and where the information is deemed sensitive under the provisions of the Act a further condition from a second supplementary schedule.

Where a care organisation is using and disclosing personal information for purposes relating to the care of an individual the Act will not prevent that use or disclosure. However, other uses or disclosures are likely to require the explicit consent of the individual concerned.

 

Common Law Obligations

The Common Law requires that there is a lawful basis for the use or disclosure of personal information that is held in confidence. Unlike the Data Protection Act which applies to legal organisations in their entirety, the common law applies to the clinic, team or workgroup caring for an individual, i.e. those not caring for the individual cannot assume they can access confidential information about the individual in a form that identifies them even when they are working in the same organisation.

Normally the basis of access to confidential information will be the consent of the individual concerned and this must be obtained before disclosure or use of the information.

Consent can be implied in some circumstances, but not in others. It is generally accepted that consent can be implied where the purpose is directly concerned with an individual’s care or with the quality assurance of that care and the disclosure should not reasonably surprise the person concerned.

Note: Whilst consent can reasonably be implied for direct care in many cases, this is not automatically the case and consent cannot be implied when an individual has expressly dissented.

In other circumstances and for other purposes consent cannot be implied and so must be specifically sought or there must be some other lawful basis for disclosing the information.

 

Sharing Information for Care Purposes

It should be noted that this requirement does not affect the duty to share information for care purposes. This duty was re-asserted by the Caldicott 2 Review Panel in their report ‘Information - To share or not to share: The Information Governance Review’. A new Principle 7, states that the duty to share information can be as important as the duty to protect patient confidentiality. This means that health and social care professionals should have the confidence to share information in the best interests of their patients/service users within the framework set out by the Caldicott Principles.

 

Using the Information for Purposes Unconnected to Care Services

The Department of Health response to the Caldicott2 Report placed an expectation on all health and care organisations to:

  • Clearly explain to patients and the public how the personal information they collect could be used in de-identified form for research, audit, public health and other purposes.
  • Make clear what rights the individual has open to them, including any ability to actively dissent.

Where an organisation such as Aseptika wishes to disclose confidential personal information for a purpose unrelated to care, consent cannot be implied.

In most cases, individuals must be asked for their explicit consent for information to be shared with non-care organisations, for example:

  • housing departments;
  • education services;
  • voluntary services;
  • Sure Start teams;
  • the police;
  • government departments.

 

Individuals must also be asked for explicit consent for their confidential personal information to be shared for non-care purposes, such as those in Table 1.

 

Table 1: Non-care purposes

Checking quality of care

Testing the safety and effectiveness of new treatments and comparing the cost-effectiveness and quality of treatments in use;

Supporting Care Quality Commission audit studies;

Comparative performance analysis across clinical networks; and

Ensuring the needs of service users within special groups are being met e.g. children at risk, chronically sick, frail and elderly.

Protecting the health of the general public

Drug surveillance (pharmacovigilance) and other research-based evidence to support the regulatory functions of the Medicines and Healthcare products Regulatory Agency;

Surveillance of disease and exposures to environmental hazards or infections and immediate response to detected threats or events;

Vaccine safety reviews;

Safety monitoring of devices used in healthcare;

Linking with existing National Registries for diseases / conditions;

Analysis of outcomes following certain health interventions (i.e. public health interventions as well as treatments);

Monitoring the incidence of ill health and identifying associated risk factors; and

Identifying groups of patients most at risk of a condition that could benefit from targeted treatment or other intervention.

 

Managing care services

Capacity and demand planning;

Commissioning;

Data for Standards and Performance Monitoring;

National Service Frameworks;

Clinical indicators;

Information to support the work of the Care Quality Commission;

Evidence to support the work of the National Institute for Health and Clinical Excellence;

Measuring and monitoring waiting times, in support of the 18 week target;

Data to support Productivity Initiatives;

Agenda for Change; and

Benchmarking.

Supporting research

Assessing the feasibility of specific clinical trials designed to test the safety and/or effectiveness and/or cost-effectiveness of healthcare interventions;

Identification of potential participants in specific clinical trials, to seek their consent;

Providing data from routine care for analysis according to epidemiological principles, to identify trends and unusual patterns indicative of more detailed research; and

Providing specific datasets for defined approved research projects.

 

Where explicit consent cannot be obtained Aseptika may be able to rely on the public interest justification or defence. This is where we believe that the reasons for disclosure are so important that they override the obligation of confidentiality (e.g. to prevent someone from being seriously harmed or for safeguarding).

Disclosure may also be required by Court Order or under an Act of Parliament, i.e. there is a statutory or other legal basis for the disclosure. Of particular note in this respect are disclosures permitted under section 251 of the NHS Act 2006, formerly known as section 60 of the Health and Social Care Act 2001. Applications for approval to use Section 251 powers are considered by the Confidentiality Advisory Group (CAG) of the Health Research Authority.

All activities that involve the use or sharing of confidential personal information that do not have a lawful basis must be reported as an IG Serious Incident Requiring Investigation (IG SIRI) using the IG Toolkit Incident Reporting Tool.

In general no-one may consent on behalf of another individual who has the capacity and competence to decide for themselves. However, treating clinicians, parents of young children, legal guardians, or people with powers under mental health law, e.g. the Mental Capacity Act 2005 must make decisions that they believe are in the best interests of the person concerned.

It should also be borne in mind that an individual has the right to change their mind about a disclosure decision at any time before the disclosure is made, and can do so afterwards to prevent further disclosures where an activity requires a regular transfer of personal information.

 

The NHS Care Record Guarantee for England

Individuals’ rights regarding the sharing of their personal information are supported by the NHS Care Record Guarantee, which sets out high-level commitments for protecting and safeguarding service user information, particularly in regard to: individuals' rights of access to their own information, how information will be shared (both within and outside of the organisation) and how decisions on sharing information will be made.

 

The NHS Constitution for England (revised 2013)

The NHS Constitution sets out a series of patients' rights and NHS pledges. All NHS bodies and private and third sector providers supplying NHS services are required by law to take account of the Constitution in their decisions and actions.

The relevant rights for this requirement are:

  • You have the right to be informed about how your information is used.
  • You have the right to request that your confidential information is not used beyond your own care and treatment and to have your objections considered, and where your wishes cannot be followed, to be told the reasons including the legal basis.

The relevant pledges for this requirement are the NHS commits:

  • to anonymise the information collected during the course of your treatment and use it to support research and improve care for others.
  • Where identifiable information has to be used, to give you the chance to object wherever possible.
  • To inform you of research studies in which you may be eligible to participate.

Where an organisation contracts with a third party to provide care services the contracts must prevent personal information from being used for purposes other than those contracted for and must also ensure that there is explicit consent or some other lawful basis where required. NB: Data processor arrangements and contracts can enable an organisation to share information with a third party working on their behalf, but these do not satisfy the requirements of the common law for there to be a lawful basis before confidential information can be shared with a third party.

Policy: if in doubt, ask the IG Lead for an opinion.

  

13-206 Staff access to confidential personal information is monitored and audited. Where care records are held electronically, audit trail details about access to a record can be made available to the individual concerned on request

Organisations should ensure that access to confidential personal information is monitored and audited locally and in particular ensure that there are agreed procedures for investigating confidentiality events.

 

Confidentiality Audit Procedures

Good practice requires that Aseptika handles personal information have in place control mechanisms to manage and safeguard confidentiality, including mechanisms for highlighting problems such as incidents, complaints and alerts.

The Company’s policy is to highlight actual or potential confidentiality breaches in their systems, particularly where person identifiable information is held. Aseptika also has procedures in place to evaluate the effectiveness of controls within these systems.

Aseptika’s systems which hold personal information will have audit trails that detail anyone and everyone who has accessed a service user's record. Information about who has accessed an individual’s record should be made available in a suitable form if requested by the individual.

 

Purpose of the Confidentiality Audit

Confidentiality audits will focus primarily on controls within electronic records management systems, but should not exclude paper record systems: the purpose being to discover whether confidentiality has been breached, or put at risk through deliberate misuse of systems, or as a result of weak, non-existent or poorly applied controls.

Assurances that these controls are working effectively should be part of the organisation’s overall assurance framework and, as such, it is likely that many organisations are, at some level, already complying with this requirement. For example:

  • the IG Lead or equivalent may be undertaking reviews/follow ups of failed log-in reports provided for information systems;
  • IG Leads or equivalent may be monitoring incident reports regarding stolen/lost computers, disclosure of confidential material, complaints etc;
  • internal audit processes may include reviews of IT security that cover such areas as records’ systems to highlight allocation, use or abuse of passwords (indicating possible breach of access privileges).

 

Monitoring and Auditing Access to Confidential Information

The organisation should ensure that it has assigned overall responsibility for monitoring and auditing access to confidential personal information to an appropriate senior staff member, e.g. the IG Lead. This member of staff should be responsible for ensuring that confidentiality audit procedures are developed and communicated to all staff with the potential to access confidential personal information. The procedures should include:

  • how access to confidential information will be monitored;
  • who will carry out the monitoring of access;
  • reporting processes and escalation processes;
  • disciplinary processes.

The following are examples of events that Aseptika will audit for frequency, circumstances, location etc:

  • failed attempts to access confidential information;
  • repeated attempts to access confidential information;
  • successful access of confidential information by unauthorised persons;
  • evidence of shared login sessions/passwords;
  • disciplinary actions taken.

 

Investigating Confidentiality Events and Alerts

The IG Lead has responsibility for the investigation of confidentiality events.

Investigation and management of confidentiality events and alerts should be in line with the management and reporting of serious incidents requiring investigation (SIRIs). Disciplinary procedures outline the penalties for unauthorised access or attempts, e.g. suspension, supervised access to systems, ending a contract, firing an employee, or bringing criminal charges.

 

Providing Audit Trail Information to Service Users

Both the National Information Board in ‘Personalised Health and Care 2020’ and Dame Fiona Caldicott in the ‘Report of the Caldicott2 Review’ have reaffirmed the commitment made in the NHS Care Record Guarantee to ensure that an audit trail that details anyone and everyone who has accessed a service user's record should be made available in a suitable form to service users, preferably via their personal health and social care records.

The terms and conditions applying to the use of Aseptika’s products should also be included in this information governance along with the right to be forgotten.

 

13-209 All person identifiable data processed outside of the UK complies with the Data Protection Act 1998 and Department of Health guidelines.

Aseptika is responsible for the security and confidentiality of personal information we process. Processing may include the transfer of that information to countries outside of the UK, and where person identifiable information is transferred, organisations must comply with both the Data Protection Act 1998 and the Department of Health guidelines.

Our policy is to keep information about all personal information within the UK.

 

Transfers Outside the UK

The Data Protection Act 1998 implements into UK law Directive 95/46/EC of the European Parliament and of the Council of 24 October 1995 on the protection of individuals with regard to the processing of personal data and on the free movement of such data. The aim is to harmonise data protection laws so that potential obstacles to cross-frontier flows of personal data between member states of the European Union (EU) are reduced and a high level of data protection within the EU is ensured.

Principle 8 of the Act governs transfers of personal information and requires that it is not transferred to countries outside of the European Economic Area unless that country has an adequate level of protection for the information and for the rights of individuals.

 

The European Economic Area

The European Economic Area (EEA) is made up of the EU member states plus the European Free Trade Association (EFTA) countries of Iceland, Liechtenstein and Norway. The current EU member states are in Table 1.

         

Table 1: The European Union Member States

Austria

Belgium

Bulgaria

Croatia

Cyprus

Czech Republic

Denmark

Estonia

Finland

France

Germany

Greece

Hungary

Ireland

Italy

Latvia

Lithuania

Luxembourg

Malta

Netherlands

Poland

Portugal

Romania

Slovakia

Slovenia

Spain

Sweden

United Kingdom

   

 

Further details can be found at: European Commission Transferring your data outside the EU.

 

An Adequate Level of Protection

The European Commission has the power to determine whether a third country (ie not an EU member state or an EFTA country) ensures an adequate level of protection for personal data by reason of its domestic law or the international commitments it has entered into.

The commission has so far recognised Andorra, Argentina, Canada (commercial organisations), Switzerland, Faeroe Islands, Guernsey, Israel, Isle of Man, Jersey, New Zealand, Uruguay and the US Department of Commerce's Safe Harbour Privacy Principles as providing adequate protection.

Information on countries with an adequate level of protection and the US Safe Harbor agreements can be found within the European Commission decisions on the adequacy of the protection of personal data in third countries.

 

Department of Health Guidelines

Aseptika complies with the following guidelines issued by the Department of Health:

  • Person identifiable information must not be transferred outside of the UK unless appropriate assessment of risk has been undertaken and mitigating controls put in place.
  • Aseptika will regularly review the flows of person identifiable information identified for requirement 308 or requirement 322, to understand whether information transferred to external organisations flows outside of the UK.
  • Information about overseas transfers of information must be included within Aseptika’s Data Protection notification to the IG Lead and must be added to this Information Governance policy if information is transferred overseas.
  • Decisions on whether to transfer person identifiable information must only be taken by the IG Lead.

Aseptika will always obtain an assurance statement from third parties that may process the personal data of our service users or staff overseas. This assurance may be within the contract between the two organisations or within other terms of processing.

 

Data Protection Act Principles

As Aseptika has determined that it makes no transfers of personal information to non-UK countries, we have documented this in this present policy for audit purposes.

  

13-210 All new processes, services, information systems, and other relevant information assets are developed and implemented in a secure and structured manner, and comply with IG security accreditation, information quality and confidentiality and data protection requirements.

The Company will ensure that when new processes, services, systems and other information assets are introduced that the implementation does not result in an adverse impact on information quality or a breach of information security, confidentiality or data protection requirements. For best effect, requirements to ensure information security, confidentiality and data protection and information quality should be identified and agreed prior to the design, development and/or implementation of a new process or system.

 

Impact and Risk Assessments

Aseptika rapidly changes its technology and this has a major impact on processes and systems already in place, often requiring change simply to keep up to date and to enable the safe and secure processing of personal information.

It is vitally important that the impact of any proposed changes to Aseptika’s processes and/or information assets are assessed to ensure that the confidentiality, integrity and accessibility of personal information are maintained.

We recognise that changes to organisational processes and information assets may also be driven by service changes, and the implementation of new products.

 

Responsibilities

The Information Governance Lead should be consulted during the design phase of any new service, process or information asset or product so that they can decide if a privacy impact assessment is required for a particular project or plan.

Responsibilities and procedures for the management and operation of all information assets should be defined and agreed by the IG Lead.

Development of IG security accreditation documentation should be carried out by those staff with the best knowledge of a planned, new or existing information asset, its intended purposes and its operating environments.

All staff members who may be responsible for introducing changes to services, processes or information assets must be effectively informed about the requirement to seek approval from the group that considers information governance compliance issues.

 

Compliance with Information Quality, Confidentiality and Data Protection Requirements

Compliance with confidentiality and data protection must be taken into account and there must also be a comprehensive consideration of potential impacts on information quality at the design phase of any new process or information asset. Some of the considerations that should be taken into account are whether a new process or information asset will:

  • affect the quality of personal information already collected;
  • allow personal information to be checked for relevancy, accuracy and validity;
  • incorporate a procedure to ensure that personal information is disposed of through archiving or destruction when it is no longer required;
  • have an adequate level of security to ensure that personal information is protected from unlawful or unauthorised access and from accidental loss, destruction or damage;
  • enable data retrieval to support business continuity in the event of emergencies or disasters;
  • enable the timely location and retrieval of personal information to meet subject access requests;
  • alter the way in which Aseptika records in or monitors and reports information from a key operational system.

 

Compliance with Information Security Requirements

Information security related aspects of IG including any risk to the integrity of information should be identified, considered and necessary actions integrated and documented in the overall project or plan for the new process or information asset.

An information security risk analysis will be carried out at an early stage of each project to identify requirements for design and risk mitigation purposes. The security controls will address all developmental and operational aspects of the asset and become an integral aspect of the project. The IG Lead should be involved as part of the project team throughout to ensure the selected security controls are identified and implemented properly and tested satisfactorily.

Appropriate IG security accreditation documentation will be developed and maintained for all security controls applied to a particular information asset including assessments and assurance reviews of those controls, to assess their effectiveness in mitigating identified risks to that information asset.

 

Information Assets: IG Security Accreditation

Although the definition of an information asset incorporates ‘softer’ aspects such as the skills or specialist knowledge of staff members, in the majority of cases IG security accreditation would have most relevance to the ‘hardware’ and ‘software’ components of an information asset, including their configuration settings.

Accreditation documentation will provide those leading on information risk (e.g. IG Lead) with assurance that information security has been properly considered and addressed within the design, development, implementation, operation and decommissioning stages of an asset’s lifecycle.

Accreditation will normally be achieved in stages aligned to the asset’s project feasibility, design, development and implementation stages and should be routinely reviewed and extended or refined throughout its operating lifetime.

 

Project Management

A structured and logical approach to conducting projects and should be utilised when developing new information assets.

The main stages of development for projects that the Information Governance lead should ensure are reflected in project plans and controls:

  • requirements analysis;
  • functional specification;
  • system architecture and design;
  • creation or selection of software;
  • testing;
  • assuring fulfilment of project objectives;
  • assuring quality;
  • acceptance and implementation;
  • operation and maintenance.

Existing provisions for project management should be reviewed to determine whether they are in accordance with the stages above.

 

Separation of Development, Test and Operation Facilities

Processes or information assets in development or under test can potentially cause problems to operational systems, so should be separated until approved for introduction as operational systems. The final test, that of a new process or asset being run as an integral part of the organisation’s operations, should be carefully monitored as some problems only become apparent at this last stage.

Development software and test data should be run on different systems or domains until all tests are successfully completed. Operational data, including person identifiable data, must not be used for test purposes as this may endanger its integrity and reliability and/or may cause an unforeseen security event.

Access to development tools and system utilities should be restricted to relevant authorised personnel only and must not be accessible from operational systems.

Testing environments should attempt to emulate the operational environment as far as possible. Preferably, a test domain will include replications of all the operational systems it will interface with. This will increase the likelihood that conflicts between the new asset/process and other operational systems will be identified during testing. For this to be valid, it is important that updates, patches, etc for operational systems are also replicated in the test environment.

 

Separate user IDs should be established for use on test systems

Test systems should be subject to the same access and security controls as operational systems. This provides protection for the systems and allows staff an opportunity to experience and practice operational procedures. Test data should be backed up to ensure the integrity of the test system. Care should be taken in the selection and creation of test data that it is not live data or could be re-identified as such.

 

Capacity Planning

The capacity of the existing infrastructure to cope with the introduction of new or amended processes or assets should be considered as part of the implementation planning process. Bandwidth, storage space, technical and helpdesk support, other staffing, maintenance and replacement costs and implications should all be taken into consideration.

Additional physical resources such as accommodation, furniture, paper supplies, training materials and material storage cabinets need to be considered.

 

Acceptance

The following criteria should be included for new processes and information assets:

  • error recovery and restart procedures;
  • preparation and testing of routine operating procedures to defined standards;
  • an agreed set of security controls;
  • training in the use of the information asset or process for user and technical/helpdesk support;
  • user involvement at all stages of asset or process development to ensure the new way of working is as intuitive as possible.
  • Agreed Set of Security Controls

These should include:

  • effective manual fallback procedures;
  • business continuity and disaster recovery arrangements;
  • evidence (through testing, calculations and validation of data) that the new assets or processes will not adversely affect existing operational systems.

 

Guidance for Staff

Documented operating procedures should be made available for all users of information assets, as part of user training. It is essential that these procedures are kept up to date, to reflect any implications of changes to software/hardware or working methods.

System administrators and technical support personnel will also need access to more detailed operating procedures to carry out their roles. The operating procedures should become part of the information asset register and become subject to regular review. Typically, the procedures should include:

  • information processing and handling instructions;
  • information backup procedures
  • job scheduling requirements, including interdependencies with other information assets;
  • instructions for handling errors;
  • restrictions on access to and use of system utilities;
  • support contacts for operational or technical difficulties;
  • instructions for handling output and media, including the disposal of confidential waste and failed jobs;
  • system restart and recovery;
  • the management of audit and log data.

 

Change Management

System software, hardware and operating procedures are subject to regular change. It is essential that any changes are subject to a strict change management regime, to ensure that all changes are controlled and approved. Failure to do this can result in patching deficiency and unforeseen system faults or failures. Formal documented change management procedures should be put in place, which will typically include the following:

  • change management structures, responsibilities and approval processes;
  • identification and recording of changes;
  • proposed change impact analysis;
  • communication plan for proposed changes;
  • fallback procedures in case of unforeseen errors/problems following change.

  

13-211 All transfers of personal and sensitive information are conducted in a secure and confidential manner.

There is a need to ensure that all transfers of personal and sensitive information (correspondence, faxes, email, telephone messages, transfer of patient records and other communications containing personal or sensitive information) are conducted in a secure and confidential manner. This is to ensure that information is not disclosed inappropriately, either by accident or design, whilst it is being transferred or communicated to, within or outside of the organisation.

 

Transfers of Personal and Sensitive Information

 Transfers of personal and sensitive information within and between organisations should be controlled, and should be compliant with any relevant legislation, for example the Data Protection Act 1998.

The loss of personal information will result in adverse incident reports which will not only affect the reputation of Aseptika but, in the case of disclosing personal information intentionally or recklessly, is also a criminal offence. With effect from April 2010 fines of up to £500,000 may be imposed by the Information Commissioner's Office on Aseptika if we do not take reasonable steps to avoid the most serious breaches of the Data Protection Act.

 

Defining Personal and Sensitive Information

Personal Information. This relates to information about a person which would enable that person’s identity to be established by one means or another. This might be fairly explicit such as an unusual surname or isolated postcode or items of different information which if taken together could allow the person to be identified. All information that relates to an attribute of an individual should be considered as potentially capable of identifying them to a greater or lesser extent.

Sensitive Information. This can be broadly defined as that which if lost or compromised could affect individuals, organisations or the wider community. This is wider than, but includes, information defined as sensitive under the Data Protection Act 1998, e.g. an individual’s bank account details are likely to be deemed ‘sensitive’, as are financial and security information about an organisation.

 

Movement of Personal and Sensitive Information

Information is commonly moved around and between organisations, whether in paper health records, in electronic form or on other media. Where this information is personal or sensitive information it must be transferred with appropriate regard to its security and confidentiality. It is also essential that the media are protected from unauthorised access and environmental damage at all stages of the move. External exchanges should be carried out on the basis of agreements between exchanging organisations.

Procedures and standards to protect information and media (paper, electronic storage media, photos, X-rays, etc) in transit should be established. The business and security implications associated with transferring information electronically, e.g. by email should be considered.

There must also be procedures in place to ensure all personal and sensitive information relating to patients/service users is received to a secure and protected point. These secure points, also referred to as ‘safe havens’ should be in place wherever the information is received, including transcribing of phone messages, fax in-trays, electronic mailboxes, pigeon holes and in-trays for paper information etc.

 

Appropriate Transfer Methods

Guidelines on appropriate transfer and protection measures are provided below under the following headings:

Encryption: Encrypted electronic media transported between sites or organisations should be properly packaged and clearly labelled to ensure they are handled correctly and not corrupted by magnetic fields.

 

Email

Email is not a secure system. All staff using email should be made aware of this during their induction training and during any training provided for use of the email system. Therefore, patient identifiable and other sensitive information should not be sent by email unless it has been encrypted to standards approved by the NHS.

Emails containing patient identifiable information must be stored appropriately on receipt, e.g. incorporated within the individual’s record, and deleted from the email system when no longer needed.

Email attachments are one of the most common methods for transmitting viruses. All users should be informed of the dangers posed by opening attachments, especially those they were not expecting. Up to date anti-malware software that includes anti-virus capability, should be installed and configured where possible for on-access scanning.

 

General Retention / Appropriate Storage Issues

All staff should ensure that when personal or sensitive information is received it is stored securely with access only by those with a legitimate right to the information. The type of storage that is appropriate will depend on the media on which the information is received.

 

Procedures and Guidance for Staff

Before transferring information, staff should be directed to obtain answers to the following questions:

  • is there a valid need to use/disclose confidential information?
  • is it necessary to use confidential information?
  • has the minimum possible confidential information been used?
  • do the proposed recipients need to know all of the confidential information?
  • have all staff members been informed of their responsibilities for protecting confidential information?
  • is the use of confidential information lawful?
  • does the stated purpose for transferring the information make it more important that the information is shared rather than withheld?

All areas from which correspondence, email, telephone messages, transfer of patient records and other communications containing personal information may be sent should be identified, and procedures developed to ensure security and confidentiality are maintained. The types of issues the procedures should address are:

  • how much information can be given, e.g. on the phone;
  • where and how incoming messages are recorded, e.g. a message book;
  • when a particular type of mail route may be used, e.g. email;
  • when a courier should be used;
  • discussion of patients in public.

  

13-305 Operating and application information systems (under the organisation’s control) support appropriate access control functionality and documented and managed access rights are in place for all users of these systems.

Aseptika will control access to Information Assets and systems by ensuring that system functionality is configured to support user access controls and by further ensuring that formal procedures are in place to control the allocation of access rights to local information systems and services.

These procedures will cover all stages in the life-cycle of user access, from the initial registration of new users to the final de-registration of users who no longer require access to information systems and services.

Special attention should be given to managing access rights which allow support staff to override system controls.

 

Access Controls and Controls Functionality

The guidance provided below reflects general good practice that Aseptika will follow for information system specification, design, and proper usage.

We apply this guidance when considering or reviewing access and control functional requirements for existing and new systems, and the individuals and groups requiring access.

Access to information assets, information processing facilities, and business processes should be controlled on the basis of business need and security policy requirements.

This requirement is scoped to include all operating systems (e.g. Linux or Windows variants, etc), application and information systems (e.g. patient / service user administration system, Microsoft Excel).

 

System-Level Security Policy / Access Control Policy

Each key information asset listed in the Company’s asset register should have IG accreditation documentation that includes a system-level security policy that contains rules regarding its access control.

The system-level security policy should be approved by IG Lead, be available to all users who are granted access to the system and should be reviewed on a regular basis. A typical system-level security policy should take account of the following:

  • The System Security Requirements. A risk assessment for the system will help determine the security requirements. For example, the level and type of access controls, location of hardware associated with the system, type of data held, etc.
  • Identification of all information related to the system, and possible risks to the information. For example, a system holding patient data. A risk analysis will point to risks of unauthorised access, input of inaccurate data, corruption of data, loss of processing facilities, etc.
  • Rules for information dissemination and authorisation eg dissemination based on a need to know basis and authorisation to data based on granular user profiles.
  • Consistency between the access control and any information classification policies of different systems and networks. This applies where an information classification scheme has been implemented within the organisation.
  • Relevant legislation and any contractual obligations regarding protection of access to data or services. Reference should be made to legislation such as the Data Protection Act 1998, Freedom of Information Act 2000, Computer Misuse Act 1990, etc. Any national NHS or other relevant guidelines should also be acknowledged.
  • Standard user access profiles for common job roles in the organisation. This relates to granularity of access. In practice, system user profiles should be kept to a minimum, based on business needs. For small departmental systems, this can mean administrator; user with ability to read, create, amend, delete, copy and print files; user with ability to read only, etc. However, systems with a wide variety of users will require significant thought in devising and reviewing access profiles.
  • Management of access rights in a distributed and networked environment which recognises all types of connections available. The policy should take account of the ways in which users can get access to the system eg local workstation only, any networked workstation, remote access, wireless, etc; and ensure secure access procedures for those applicable are put in place.
  • Segregation of access control roles. The IG Lead should ensure that written procedures are produced that cover access requests, authorisation and administration. The procedures should ensure that no single member of staff is able to authorise all access.
  • Requirements for formal authorisation of access requests. Information Asset Owners should ensure that a written procedure exists detailing how to apply for access and how to process applications.
  • Requirements for periodic review of access controls. The review should ensure that user accounts remain appropriate. For example, is the account still used, has the user changed role, do changes to the system call for a new assessment of role-based access, etc
  • Removal of access rights. Documented procedures should exist that include the criteria for removal of access rights, who authorises removal and when removals are permitted, and for audits of removals.
  • Forensic readiness policy. Organisations should ensure that systems are capable of providing admissible digital evidence, if required by an investigation or legal proceedings.

 

Secure Logon Procedures

Computer systems will have a logon authentication procedure that includes at least a unique user ID and password. A risk assessment should help determine what level of authentication is required. The following features should be considered:

  • System/application identifiers should not be displayed until the logon procedure has been successfully completed.
  • Do not indicate which part of the logon information is incorrect eg if a user makes an error. This prevents unauthorised users identifying patterns when attempting to gain access to systems.
  • Limit the number of unsuccessful consecutive logon attempts. Many systems allow three unsuccessful attempts before locking users out. A pop-up window then advises the user to contact a helpdesk to have the password reset. The system can also be set to record unsuccessful logons (useful to identify frequency of errors and to alert of a possible hacking attempt).
  • Limit the maximum time allowed for logon.
  • The system should record the date and time of successful logons. Logs may be used during investigations. The log is therefore a valuable source of evidence and should be linked to a workstation identity (the Media Access Control (MAC) address will be needed to do this).
  • The password being entered should not be displayed in clear text. Most systems show a number of asterisk characters and some systems nothing at all in the password field.
  • Passwords should not be transmitted in clear text over the network. Passwords should be encrypted through, for example, a RSA or hashing algorithm, for transmission over networks.
  • Systems should enforce password changes after a specified period of time.

 

Identifying and Authenticating Users

In order to facilitate and operate effective access control and audit functions it should be possible to uniquely identify all users of an information asset. This function may potentially be achieved by unique username and password combination or, in systems containing sensitive information, secondary smart token technology and biometrics.

 

Password Management System

Password management systems are used to establish rules concerning the use of passwords in the system. The system owner should establish the rules, which will then be implemented by the system administrator. The following criteria should be considered:

  • In all but exceptional circumstances, all users will be identified as individuals (including system administrators) when they log on.
  • Do users have to change their initial password (issued by the system administrator) following their first logon? Users should be encouraged to set their own password, as it will usually be based on something they can remember.
  • Are web browsers configured to prevent the recording of website passwords when logging in to web based applications? Recording of website passwords renders the password ineffective as a security measure. Passwords are therefore best if manually entered by the user at each login to be effective.
  • Does the system log user passwords and prevent re-use? Repetitive re-use of passwords weakens the effectiveness of the password and should be avoided.
  • Can users change their own passwords when they wish? This function increases security as users can change passwords, if they feel their current one has been compromised.
  • Are complex passwords required? Simple passwords (less than 6 characters, number or letter only, repeated use) pose a threat to the system. Alphanumeric passwords of 6 characters or more should be considered for any system.
  • Are periodic password changes enforced? A maximum period of three months between enforced changes is the norm for most systems.
  • Are passwords displayed on the screen when being entered? Displayed passwords can obviously be seen by others and pose a security threat. Most systems now display only asterisks when characters are entered and some systems do not display anything. One of these latter rules should be implemented.
  • Are passwords stored separately from application system data? Crackers normally search application sub-folders to locate password files. Therefore, every care should be taken to store passwords in protected network folders.
  • Are passwords stored and transmitted in encrypted or hashed form? All passwords should be stored or transmitted using encryption or hashed.

 

Use of System Utilities

Some systems may include utilities that can override normal controls (such as all those listed above). The IG Lead should ensure that all system utilities are identified, disabled where not necessary, and access to and use of any functional system utilities strictly controlled.

 

Session Time Out

Some systems incorporate time-outs that clear a session screen if activity has not taken place for a pre-determined time. On some sensitive systems the connection with the application/network is also terminated.

 

Information Access Restrictions

The integrity and availability of information is obviously important and should be considered. The ‘need to know’ principle of access should be supplemented with additional controls for altering or deleting information. File storage systems should be constructed with these criteria in mind as, in many cases, access to a folder allows the user to view, alter, copy or delete files in the folder (and sub-folders) unless they are protected.

 

Sensitive System Isolation

Systems holding data that is considered sensitive should be physically and logically protected from unauthorised access. When looking at NHS computer systems it is difficult to define which systems should not be considered sensitive. The nature of the data, the relationship of the system to other systems and the network, and the location of the system all contribute to a variety of risks and threats that can have an impact on more than a single system or its data.

Patient/service user, personnel and financial data are all considered sensitive due to legislation, (e.g. the Data Protection Act 1998) or commercial considerations. Systemic weaknesses in a system that does not contain sensitive data can lead to malicious code being transmitted to systems that do include sensitive data. Therefore, these criteria should be considered during the risk assessment for the system.

 

User Access Management

Aseptika uses a wide range of locally based information systems, from office electronic file storage to specialist databases. Some systems may allow all members of staff access whilst others can restrict access to particular personnel. In all cases, it is essential that effective access management systems are in place, in order to prevent unauthorised access, loss or corruption of data, the introduction of malicious or unauthorised codes, the abuse of access rights, etc. This requirement applies equally to locally managed systems which process personal data and to those which do not.

Staff members are allowed to access the internet for limited private purposes, eg email or web browsing. Where this is allowed locally, the conditions for personal use of such facilities should be defined within appropriate policy documents (eg Employee Handbook). The use of web email and the browsing of ‘untrusted’ web sites may potentially introduce risks, for example, the download of malicious code (spyware, viruses, worms, etc) or the viewing/sharing of inappropriate or illegal material. Therefore, Aseptika has formal policies exist which detail staff obligations and undertakings for acceptable use.

 

User Registration

The IG Lead is responsible for identifing in the system-level security policy. The policy also identifies the need for and existence of a formal registration / deregistration procedure, with restricted authorisation for registering / deregistering users.

The registration process should ensure that the system can reliably identify the user. User authentication can vary in complexity depending on the sensitivity of the data to which the user may have access or depending upon the criticality of the system to the business of the organisation.

It is best practice that computerised system users should have a unique logon identity (ID), with a system and/or application log that shows logon/off times and activity. Some systems may by exception allow group IDs to be used locally. Where it is impossible to attribute actions to an individual, group IDs should be used only when absolutely necessary and personal accountability is not an overriding issue.

User access rights should reflect the business needs of the user. For example, some users may only need to view data, but not change or add to it. Some systems are also granular, in that they only allow users to access data on a ‘need to know’ basis. For example, a receptionist who books appointments for a patient / service user only needs to confirm the person’s identity and not see other data in the system relating to the individual’s condition. Therefore, the local system administrator should establish user profiles and manage user rights based on the ‘need to know’ criteria.

Users should acknowledge (digitally, or in writing) 'acceptable terms of use' documentation or similar as part of the registration process. This should explain user rights in unambiguous terms and users should sign to acknowledge they have read, understood and agree to these terms.

User training documentation, guidance and the provision of user training sessions should also be an integral part of the user registration process.

Effective procedures should also be in place for deregistering users who no longer need access to the system eg they no longer work for the Company or have changed jobs. For deregistration to work effectively, the system owner, supported by the system administrator.

A procedure should be available for temporarily suspending user accounts. This procedure may apply to those who have lost their log-on credentials, are suspected of misusing the system or are on long-term sick or leave.

 

Privilege Management

System and database administrators/managers will typically have special system access rights that allow them to view and correct system data as part of a system’s maintenance or potentially to amend data that other users have entered in error.

This constitutes the basis of privilege management (also known as privileged users or superusers). Local system owners (or equivalently responsible individuals) should ensure that such high-privilege user accounts are kept to a minimum and that the actions of those using such accounts can be fully identified, and be auditable and actions accountable. For example, a group logon as ‘administrator’ and a common password should be avoided, since it is impossible to reliably audit activity.

 

User Password Management

Passwords are a common means by which a user is identified to the system and therefore password creation, distribution and use should be strictly controlled. If a password is being distributed electronically then it may be encrypted (this requires either an existing secure interface or an additional exchange process to allow the password to be decrypted by the intended user). Another option may be to deploy an ID token that can generate a random one-time password or unique number that is synchronised with the system to be accessed.

It is well documented and acknowledged that the proliferation of system passwords leads to control weakness by their owners, e.g. password sharing or loan, writing down passwords, changing all passwords to the same common value. The fewer passwords assigned to each user the better and indeed some organisations have implemented a single sign-on approach whereby a user need only control a single set of credentials. User access rights should be reviewed at regular intervals and the process detailed within organisational access control procedures. This ensures that the access rights applicable to an individual are still appropriate to their organisational role.

Systems are best configured to ensure that initial passwords issued to their users have to be changed during the system’s first access and regularly thereafter.

User passwords should be robust. As a minimum, passwords should be no fewer than 6 characters, alphanumeric (mixture of letters, numbers and special characters e.g. 5a!!AcY), non-consecutive, (e.g. Pa55w0rD1 followed by Pa55w0rD2 would not be allowed) and minimum enforced change periods established. A recommended solution would be to use memory tricks to help create memorable, but hard to guess passwords. For example, make a password out of the first letters of each word in a memorable phrase. “Somewhere over the rainbow way up high” (sotrwuh). Then by adding a mixture of upper and lower case with numbers and special characters included to produce; S0trw^h1gh

Some systems may employ configurable password construction and management standards that exceed this basic level. Users should also be provided with the opportunity to change their passwords more frequently, if they wish.

System users should be issued with written guidance on password confidentiality, construction, changing, storage and what to do when they forget a password. The guidance should also include instructions for reporting suspected password / identity misuse or theft or the loss of log-on devices.

 

Review of User Access Rights

A written procedure will be developed to regularly review all system user access rights. The review should be used to ensure users remain active and their access rights are allocated correctly. Six months is the recommended maximum period between such reviews although access reviews are best undertaken on a frequent basis and may be aligned with staff recruitment or movement cycles.

Privilege rights assigned to users and superusers should also be reviewed frequently. Three months is the recommended maximum period between reviews.

 

Unattended User Equipment and Data

Users should lock access to their workstations when they are not using them at periods during the day, through the use of a password screensaver and / or by removing any provided access management device such as a user NHS Smartcard. Local guidance on the mechanisms to be used should be provided.

Paper and other media should also be locked away when not in use. This is especially important for media that contain personal details or other sensitive information.

 

13-313 Policy and procedures are in place to ensure that Information Communication Technology (ICT) networks operate securely.

The objective of this requirement is to ensure there is appropriate protection for systems hosted and information communicated over local networks, and for the protection of the supporting infrastructure components (including wireless networks).

 

Security of Communication Networks

The secure operation of networks, which may span organisational boundaries and beyond, requires that careful consideration be given to management, dataflows, legal implications, monitoring, and protection. Additional controls may also be required to protect sensitive information passing over public networks including the internet.

 

Information Assets: Network Controls

Network controls should exist to protect the local network from threats to its components. This includes the systems and applications using the network, as well as the information passing through it, and the level of access permitted. To ensure good network security the following should be considered:

  • The assigned individual responsible for the asset (IG Lead) should ensure there is a Network Security policy.
  • Network operational management responsibility should be separated from desktop computer operations. This helps protect against possible conflict of interest and may help with problem management.
  • Procedures should be established for the remote management of equipment owned by the Company. This includes portable and fixed equipment used remotely.
  • Establish controls to protect the confidentiality and integrity of data passing over public (e.g. World Wide Web) or wireless networks.
  • Logging and monitoring of all network activity.
  • Security of Network Services

 Network services (in-house or provided externally) should normally be subject to service level agreements or contracts, and the security features for the service identified, defined, with the responsibility for maintenance, monitoring and reviewing of security features agreed by the nominated IG Lead. Aseptika will ensure it includes the right to audit the services provided as part of the agreement.

Security features should be identified through risk assessment processes and subject to regular review and where necessary, refinement. Typical security features to be considered include:

  • Authentication, encryption and network connection controls.
  • Technical parameters required for secure network connections.
  • Access approval, restriction and revocation procedures.
  • Anti-virus / malicious code detection, removal and prevention procedures.
  • Environmental controls to protect network equipment, ie from fire, flood etc.

Where a network connects to the NHS national network (N3), it is essential that the information security management standards applied to the local network are sufficient to prevent onward threats arising to the N3 or the information assets of its other connected organisations. This includes the implementation and management of effective anti-virus measures and, where necessary, firewalls.

Comprehensive network security requirements are provided and assured by the Health and Social Care Information Centre (HSCIC) through its Information Governance Statement of Compliance (IGSoC) processes and related Information Governance security guidance, for the benefit of all organisations that use the N3.

 

13-314 Policy and procedures ensure that mobile computing and teleworking are secure.

Mobile computing and teleworking pose a substantial risk. For example, devices may be lost, damaged, or stolen, potentially resulting in the loss or inappropriate disclosure of data.

The information security protection measures required should be commensurate with the risks presented by these working arrangements.

 

Security of Remote Working and Mobile Computing

When using mobile computing, the risks of working in an unprotected environment must be considered and mitigated where possible by the use of appropriate security procedures or facilities. In the case of teleworking or remote working, each Aseptika employee or contractor should assess the risks involved and apply proportionate security controls to mitigate these risks.

Documented and agreed working procedures, describing best practice, must be in place to ensure that our staff and contractors working remotely, do so safely and securely.

The Company’s policy is that the individual assigned responsibility for the asset is aware of, and has approved in advance, the use of mobile working for the information assets they are responsible for.

 

Mobile Computing and Remote Communications

The use of portable devices and mobile computing equipment is now commonplace, with users connecting remotely to required information services through laptops, mobile phones, smartphones, etc. Users are also connecting from a variety of locations – home, hotels, NHS and council premises, and through internet, wireless and dial-in technologies. Therefore, it is essential that the following are considered within a risk assessment:

Theft, Loss or Damage of Equipment. Equipment in transit is at particular risk of being damaged, lost or stolen. This is especially the case for equipment used by authorised mobile workers who are likely to connect to information systems from a number and variety of locations. Training, procedures and written guidance must be put in place for users, to cover these threats.

Unauthorised Access to Data. Unauthorised access is possible in a number of ways. Users may leave portable devices, computer equipment or media containing data unattended in a place where it may be seen or used by unauthorised individuals.

Encryption. Any digital information that is either person identifiable or otherwise sensitive, must be encrypted. This mandate applies to both the storage of, and transfer of any such digitally held information.

Technical Hacking/Cracking. The implementation of appropriate policy statements and supporting procedures together with user training, can help mitigate this risk. Unauthorised use can be gained through technical means, e.g. through ‘network sniffing’ or through guessed passwords on unattended or unprotected laptops. Encrypted data on media, encrypted transfer, strong access controls, user identification and authentication and secured wireless networks should all be considered to counter opportunist technical hacking / cracking.

Malicious and Unauthorised Mobile Code. Care must be taken to ensure that all mobile devices and removable media have their anti-virus / anti-spyware components regularly updated to protect against these types of attacks. “On access” file scanning should also be enabled within anti-virus products, to help detect email messages containing malicious code, or infected files transferred from other storage media.

Data Backups. Data stored on local drives (e.g. laptop hard disk) may be vulnerable to loss or corruption. If data is merely saved to a local drive and the device is lost, then so is the data. The minimum amount of data required must be carried on mobile devices to reduce the potential impacts of an unforeseen event. Master copies of documents should never be stored on local disk drives; only copies of information should be taken ‘off-site’.

Mobile Working Policy. Aseptika has a documented policy (and supporting procedures) that covers all aspects of mobile working. If teleworking or homeworking is undertaken, then the security, management arrangements and user requirements for this must be communicated to the employee or contractor.

The Use of Employee Mobile Devices in Care Settings. The Information Governance Alliance (IGA) is producing a set of guidance in this area.

 

Teleworking and Homeworking

Teleworking / homeworking is distinct from mobile working in that the location is normally fixed (e.g. the employee’s or contractor’s home or premises of business). The criteria listed above apply to teleworking and the following should also be considered within a risk assessment:

The Physical Security of the Location. The risks of home burglary must be considered. However, the information security issues may potentially be addressed through a unified mobile working policy.

The Environmental Conditions. Aseptika has a health and safety obligation to teleworkers that include assessing the environment to ensure teleworking equipment does not pose a threat to the teleworker's property, the teleworker's person, or to third persons. Equally, the environment should be assessed to ensure it does not pose a threat to the Company’s equipment or business functions, for example, poor ventilation resulting in overheating and loss of access or service capability.

Equipment Ownership. Aseptika will in most cases provide the necessary workstations and associated equipment for business use. In certain cases, an employee-owned device may be utilised as part of a “Bring Your Own Device” (BYOD) scheme. In such cases, consideration will be taken to address the associated risks including (but not limited to) legal ownership of the stored information; mixing of personal and business information; safeguarding business information. Our policy includes a provision that specifies official equipment is not to be used by unauthorised users or for unauthorised purposes, and guidance should be issued.

Employer Insurance. Aseptika will ensure that adequate insurance cover is available for teleworkers and that covers any equipment on a teleworker’s premises. Cover is normally available within the homeworker’s normal home contents insurance.

  

13-316 There is an information asset register that includes all key information, software, hardware and services.

The objective here is to account for information assets containing patient/service user information to ensure that in the event of damage, destruction or loss, there is awareness of what information is affected and, in the case of loss, whether the information held on the asset is protected from unauthorised access.

 

Information Asset Register

Unless we as an organisation know the type of information assets we possess it will be more difficult to ensure that each item is adequately protected through appropriate confidentiality and security measures.

Recording this information will also assist if an organisation needs to make a claim on our insurance for loss or damage to any of their assets.

The scope of the requirement is assets that hold or provide access to NHS patient information.

Information assets should be reviewed annually and updated bearing in mind hardware/software upgrades during the assets life-cycle, and changes to the partners who may have access to such assets. For Aseptika, this is most likely limited to the Activ8rlives database and product-related devices or services only.

 

Categories of Information Assets

There are many types of information asset, but the initial focus should be on the four major categories below;

  • Information: Patient databases, system documents and procedures, archived information etc.
  • Software: Applications, system, development tools and utilities.
  • Physical: Equipment such as PCs, laptops, PDAs, memory sticks, smartphones.
  • Services: Computing and communications, (including online / internet facing services).

Assets must be written down and kept in the form of a simple register. Useful information should be captured to enable compliance with the objective of this requirement.

For example the entry for a physical asset such as a computer will include:

  • Its physical location, i.e. what part of the organisation it is in (with portable equipment the member of staff it has been assigned to - see also requirement 318 or requirement 314, depending on organisation-type).
  • What software and information is included on it.
  • Who is responsible for the maintenance of the computer.
  • How to contact them if something goes wrong.
  • If it is linked to an Uninterrupted Power Supply (UPS) system. and
  • Any Business Continuity Plans for recovery.

 

Information Asset Owners

An information asset owner is a senior member of staff that has overall responsibility for an information asset. The responsibility should ideally be linked to a post rather than to a person, as such responsibilities tend not to get passed on when an individual leaves the organisation or changes jobs within it.

The role of information asset owner is likely to be delegated to the IG lead or equivalent, (although ultimate responsibility will still rest with the owner). The asset owner should compile a list of information assets (i.e. what information is held, what is added and what is removed, how information is moved, and who has access and why) and identify any risks to the information. This will enable the risks to be addressed and ensure that use of information complies with legal and other obligations.

The information asset owner can assign day to day responsibility for a particular information asset to someone else (e.g. an employee who has sole use of a laptop). They should also be aware of any assets that are not the sole responsibility of the organisation, eg equipment that is leased or shared in use.

As information asset registers are likely to include commercially sensitive information, there is no requirement for the details of the register to be shared with a commissioning organisation during monitoring visits. Commissioning organisations will however want to have some evidence that the register exists and is up to date, for example details about the date the register was last updated and where it is stored. Please note that it is best practice to ensure that any suppliers Aseptika also adhere to this requirement.

 

13-317 Unauthorised access to the premises, equipment, records and other assets is prevented.

It is important to ensure that the organisation’s assets, premises, equipment, records and other assets including staff are protected by physical security measures.

 

Securing the Premises

Aseptika has established procedures for premises security. Whilst the focus traditionally has been to safeguard property and staff, the NHS Information Governance requirements require procedures to safeguard the security of hardware, software and information.

Therefore there must be measures in place to delay and prevent unauthorised access, to detect attempted or actual unauthorised access, and to ensure that there are procedures for employees and contractors to follow in the event that unauthorised access does occur. The protection provided to premises should be balanced against the identified risks - that is, there should be an assessment of whether a particular risk is likely to occur and appropriate measures put in place to minimise that risk.

 

Security for Office and Store Areas

A risk assessment should be undertaken on the security of offices and store areas. Key considerations are the type of information stored in these areas, whether there is an adequate minimum staff level in these areas, and whether the rooms are in routine use. There may be a need to consider physical security measures such as keeping doors locked during working hours when the rooms are not in use.

 

Window Security

Windows in ground floor rooms are favourite access points for burglars and, particularly during hot weather, staff should ensure that they are closed when the room is not occupied. A risk assessment should be undertaken with possible physical security measures including window locks or if the area contains information or products which need to be particularly protected, window shutter systems or security grilles may be appropriate.

 

Back Doors and Fire Escapes

On some premises, back doors and fire escapes may be left ajar for ventilation purposes in hot weather. This practice has the potential to compromise the security of the premises and should be discouraged.

 

Alarms

There should be an alarm system that is of an adequate specification to protect the premises. Security specialists should be engaged when installing a new alarm system, or taking over new premises. Alarm systems should be tested on a regular basis. When refitting the premises, or developing new services, there should be consideration of whether the existing alarm system is adequate for the new security requirements, and seek security advice if necessary.

Fire alarms should be fitted in all areas and regularly tested. Fire doors, automatic and manually operated fire control systems all help prevent the spread of fire.

 

Keys and Staff Access

Physical keys should be issued on a need-to-have basis and a degree of inconvenience may be preferable to a large number of duplicate keys. Electronic keys can be cancelled with relative ease, but it can be time consuming and expensive to change locks on doors. A record should be kept of keys issued for long-term use and staff should be briefed on the importance of reporting lost keys. A log should be maintained, and procedures adopted to ensure keys have been returned when staff members have left employment.

 

Clear Desk and Clear Screen Policy

Staff are encouraged to clear desks of any sensitive and confidential information when it is no longer required for the task in hand and to ensure that such information is locked securely away overnight. Employees should also be informed of how to use a password protected screen saver on their computers if they need to leave their machine unattended.

 

Assessment of Physical Security

There should be an assessment of physical security. This should look at the premises as a whole, taking into account legitimate entry and exit points, areas where forced entry is possible and any unstaffed parts of the building(s). Having identified any areas of risk, the risks should be weighed against the likelihood of the threatened risk actually occurring. For example, the assessment may identify a risk of burglary, the question to be asked is whether this a high risk, a medium risk or a low risk.

Where the risk of a breach in security is likely, the necessary resources should be allocated to increase the physical security of those assets. In the example above this may require installing security grilles on ground floor windows to minimise the risk of a break-in.

Where the perceived risk is low, it may be decided that action is unnecessary at this time; however, this should be documented and that area kept under regular review.

Physical security should be subject to regular risk assessment and updated guidance/ procedures issued to reflect new risks to the premises due to new ways of working or the purchase of new equipment. There should be checks that staff members comply with the procedures, e.g. by review of burglar alarm logs. Awareness and training should be provided to all new staff as part of their induction, and existing staff should be provided with regular updates as necessary.

 

Steps to Take Following Unauthorised Access

Measures should be put in place so that staff members are aware of the steps to take should unauthorised access occur, e.g. ensuring that they do not enter the premises alone where there is evidence of a break-in as the burglar may still be inside. There should also be advice about who to notify and minimising the losses where possible.

 

13-319 There are documented plans and procedures to support business continuity in the event of power failures, system failures, natural disasters and other disruptions.

In the event of a security failure or a disaster, natural, accidental or deliberate, vital business processes still need to be carried out. Having documented business continuity plans and procedures assists this process enabling all staff to know what they need to do in the event of a security failure or disaster.

 

Business Continuity Planning

Business Continuity Plans (BCP) represent an attempt by Aseptika to predict, assess and counteract threats and risks that may lead to events that seriously disrupt or curtail all or part of our business functions. Business Continuity assessments analyse the probability of untoward events occurring, their likely impacts, determine what the organisation can do if they happen, and how the organisation systematically goes about recovering from these events.

 

Purpose of Business Continuity Planning

Business continuity planning enables an organisation to:

  • Assess the risks of a security failure or disaster occurring.
  • Analyse the consequences to the running of the organisation if a security failure or disaster was to occur.
  • Plan measures to reduce the likelihood of a security failure or disaster occurring.
  • Plan measures to allow the organisation to continue to function if a security failure or disaster does occur.

A senior staff member should oversee risk assessments and coordinate an overall assessment plan for the organisation.

 

Critical Information Systems

Critical information systems should include all systems containing patient/service user data and communication systems necessary for transmitting patient/service user information. Critical processes should include those necessary for delivering patient/service user care.

Risks to the confidentiality, integrity and availability of systems and processes should be assessed. The impact of threats should be assessed to determine priorities and plans put in place to counter the threats. Critical times (those affecting the potential to deliver adequate patient/service user care) should be assessed and countermeasures put in place to ensure system or process recovery occurs within agreed time limits.

Plans should be tested as table-top exercises and walk-throughs (such as validation of data back-ups).

Review groups should be established to take responsibility for review, coordination and testing of the plans. A regular review and testing timetable should be established, with both being conducted on an annual basis. Reviews should also be carried out following significant system changes, relocation of facilities and staff reorganisation.

 

Information Security and Business Continuity Planning Terminology

Risk assessment: Assessment of threats, impacts and vulnerabilities on organisational services and assets to enable measures to be taken to reduce the identified risks.

Disaster: Accidental, natural or malicious events, which threaten or disrupt normal operations or services for sufficient time to have significant effects on the organisation's business.

Threat: A potential cause of an unwanted incident, which may result in harm to a system or organisation.

Confidentiality: Ensuring that information is accessible only to those authorised to have access.

Integrity: Safeguarding the accuracy and completeness of data and information and processing methods.

Availability: Ensuring that authorised users have access to information and associated assets when required.

  

13-320 There are documented incident management and reporting procedures.

Information incidents include a loss/breach of staff/patient/service user personal data, a breach of confidentiality or other effect on the confidentiality, information security or quality of staff/patient/service user information.

All incidents and near-misses should be reported, recorded and appropriately managed so that where incidents do occur, the damage from them is minimised and lessons are learnt from them.

An Information Governance Serious Incident Requiring Investigation (IG SIRI) deemed reportable to national bodies e.g. the Information Commissioner, should be recorded and communicated via the IG Toolkit Incident Reporting Tool.

 

Incident Management and Reporting

Information incidents are any event or occurrence that has resulted or could have resulted in either the disclosure of confidential information to an unauthorised individual, put at risk the integrity of the system or data, or put at risk the availability of the system/services and include a breach of the Data Protection Act with regards to personal data.

Any breach of legislation or best practice guidance relating to personal data or confidential information provided by the health or adult social care sector to the hosted team should also be considered an information governance incident and treated accordingly.

 

Reporting via the IG Incident Reporting Tool

Some Information Governance related incidents may be classified as a Serious Incident Requiring Investigation (IG SIRI).

An IG SIRI is any incident which involves actual or potential failure to meet the requirements of the Data Protection Act 1998 and/or the Common Law Duty of Confidentiality. This includes unlawful disclosure or misuse of confidential data, recording or sharing of inaccurate data, information security breaches and inappropriate invasion of people’s privacy. This definition applies irrespective of the media involved and includes both electronic media and paper records relating to staff and service users.

Since June 2013 all Organisations processing health and adult social care personal data should use the IG Toolkit Incident Reporting Tool to report Level 2 IG Serious Incidents Requiring Investigation (SIRI) to the Department of Health (DH), NHS England and the Information Commissioner’s Office (ICO). IG SIRI functionality will be extended in early 2015 to capture cyber related incidents.

Where applicable, under terms of agreement there should be a requirement to notify service commissioners in writing of all serious incidents that affect or are likely to affect their contractual obligations. Whilst the commissioner will necessarily be concerned with clinical incidents, information governance incidents should not be overlooked as they can also have a serious effect on patient care. Other NHS contractors should also consider whether it is appropriate to inform service commissioners or other external organisations of IG Serious Incidents Requiring Investigation (IG SIRI), for example if this is likely to lead to a patient complaint/distress/harm.

 

Identifying an Information Incident

Information incidents are not always apparent e.g. a computer stolen during a burglary may be seen as merely a hardware issue. However, the information contained on the computer, especially sensitive information, can undermine the security and good reputation of the organisation, if disclosed to those not authorised to see it. Other incidents should also be taken into account, e.g. an attempt to access confidential information by an unauthorised person; a software malfunction; etc.

 

Managing Information Incidents

There has been a requirement to record and analyse critical incidents in relation to medicines for some time. The underlying principles are equally applicable to the management of information incidents. These include:

  • Establishing that an incident has, in fact, occurred.
  • Establishing where the responsibility for the incident lies.
  • Evaluating the extent of the damage or risk to the organisation as a result of the incident.
  • Taking timely and appropriate remedial action.
  • Reviewing procedures to reduce the risk of the incident occurring again, and keeping a record of lessons learned.

Responsibility should be assigned for managing information incidents to an appropriate member of staff and procedures put in place for the reporting and management of incidents. In small organisations this responsibility may reside with the IG Lead.

The incident management procedures should detail:

  • The need for the procedure.
  • The scope of the procedure.
  • A brief explanation of the types of incident, how they will be managed and reported and any countermeasures.
  • Responsibilities of management and staff towards incident reporting.
  • Referenced documentation (e.g. the Information Governance policy).

 

How to report SIRIs using the IG toolkit Incident Reporting Tool to inform Department of Health, NHS England and Information Commissioner's Office.

Some of the procedures will be discrete, such as investigating computer misuse (child pornography, fraud) and others will form part of Business Continuity Plans, e.g. in the event of complete computer failure.

The procedures should include a process of review to allow discussion and reflection in the event of an incident. The review should involve all disciplines of staff and the process should be carried out avoiding the allocation of blame. A culture of blame is not conducive to improvements being made; lessons can usually be learnt from any identified shortcomings allowing improved processes for the future. Where applicable, new countermeasures and procedures should be put in place to avoid a repetition of the event.

 

Recording Information Incidents

All Information governance incidents of all severities should be recorded. This can be through the use of local organisation systems/processes or via the IG Toolkit Incident Reporting Tool. Particularly high severity information governance incidents (e.g. Level 2 IG SIRIs), which are reportable to national bodies, should also be recorded and escalated via the IG Toolkit Incident Reporting Tool. The information which should be recorded:

  • Date of incident (if identifiable).
  • Location of incident (if identifiable).
  • Details of staff involved (if identifiable and applicable).
  • Description of incident.
  • Degree of risk associated with the incident (correlates with risk assessment for data transfer).
  • Any contributing factors.
  • Remedial action taken following this incident.
  • Suggested action to be taken to prevent a reoccurrence of this incident.
  • Informing the insurer and others (if appropriate), e.g. the police, the Information Commissioner's Office and the commissioning organisation.

 

Reporting Information Incidents

It is essential that all staff members are aware of the necessity to report information incidents, including lost or stolen equipment, breaches of confidentiality and near-misses.

Staff should be fully informed and trained in the use of all procedures in place to protect information. No matter how good existing procedures are weaknesses will always become apparent. New threats and new systems or ways of working will expose these weaknesses and users on the ground are normally the first to identify them. Therefore, staff should be encouraged to report anything they feel threatens security. This approach needs to be adopted during induction training.

If there is a standard reporting form it should also include information incident reports. All incident reports should be referred for further action to the person assigned responsibility for managing information incidents.

The person who has responsibility for managing information incidents should consider whether it is appropriate to inform the commissioning organisation of high risk incidents, for example if this is likely to lead to a patient/service user complaint/distress/harm. It is also considered best practice to inform the Information Commissioner if the data loss falls into a high risk category, the IG Toolkit Incident Reporting Tool does this for you as part of an automated notification process. It may be appropriate to report the incident to others including the police, for example in the event of data theft, or to the insurer, e.g. in the case of stolen equipment.

  

13-323 All information assets that hold, or are, personal data are protected by appropriate organisational and technical measures.

Organisations must ensure that all of their information assets that hold or are personal data are protected by technical and organisational measures appropriate to the nature of the asset and the sensitivity of the data.

 

Protection of Information Assets

All organisations own and use information assets that support their local business needs. A subset of these assets will be personal data in some form and/or the equipment within which personal data is held. The majority of these information assets will underpin service user / patient care processes, human resource processes, activity management or clinical audit, research or service evaluation but there may be a wide range of other business activities supported by such assets.

Whilst all information assets should be protected the importance of ensuring that this particular subset is held securely is paramount.

   

Examples of information assets relevant to this requirement

Paper records (service user, patient records and staff records)

Other media records (audio, images, scans etc)

Paper reports (clinical, research, service evaluation, complaints, waiting times)

Computing hardware including PCs

Blackberry and removable media

Smartphones

Tablet computers

Databases and data files

Back-up and archive data

Audit trail data

 

Responsibilities

An Information Asset Owner (IAO), or equivalent, should be assigned unique responsibility for each significant information asset, or group of assets, of the organisation. For example, a Director of IT may be the IAO for network servers, desktop computers, laptops and other IT equipment.

It is essential that each IAO understands the scope and boundaries of their assigned information assets, their approved purposes, who the users of the assets are and what their requirements for guidance and training may be, the criticality of the assets to the organisation, their dependency on other assets, and which other assets are dependent upon them. In order to achieve this detailed understanding, it is necessary that each information asset and its component parts are identified within an asset register or inventory that allows the Information Governance safeguards to be considered individually and collectively.

Safeguards fall into two categories:

  • Those mandated for the public sector.
  • Those that might be deployed to mitigate against risks.
  • Safeguards mandated for the public sector

These safeguards include:

  • Servers should be kept in a physically secure area inaccessible to unauthorised individuals or an encryption solution must be deployed. Encryption is recommended in all cases.
  • An encryption solution must be deployed to protect all laptops, computer discs, memory sticks, back-ups and other removable or portable media in line with mandatory requirements and standards.
  • Anti-virus software should be installed on each computer and configured to check all possible sources of infection e.g. CD and DVD-ROMs, USB devices, email, websites, downloaded files etc. The anti-virus software should be kept up to date at all times.
  • The operating systems of computers should be regularly updated with published security patches and where an operating system is due to be retired adequate plans should be in place for its replacement.
  • The disposal or destruction of information assets must be managed securely following agreed procedures.

There must be clearly defined and manageable rules for access and use of the information asset based on the need to know principle.

Safeguards that might be deployed to mitigate against risks

These safeguards include:

Anti-theft measures: Have desktop and laptop computers used in public areas been equipped with anti-theft devices?

Premises security: Have staff been assigned responsibility for locking doors and windows in locations where an information asset is located? What are the controls for storing assets (e.g. lockable cabinets), and are they used appropriately by staff?

System classification: Has there been an assessment of the business importance and sensitivity of information to be processed by the information asset and has a classification been assigned to the system and/or its data?

Backups: Are procedures available to perform and test regular data backups, and is at least one copy of that data stored in a secure off-site location?

Business continuity: Is there a business continuity plan available and tested in case of a disaster?

 

Additional Guidance: Secure Disposal or Re-Use of Equipment

Using computer utilities it is technically possible to retrieve data that has been 'deleted' from hard drives, removable disks and other media, e.g. digital photocopiers. Software to do this is available on the Internet and is relatively easy to use. Therefore, it is essential that classified or sensitive information (especially service user or patient data) is properly protected and securely disposed of when it is no longer required. This is also the case even where discs or media have been encrypted. Secure emergency recovery processes should be established where encryption has been used to encrypt files and discs. Such recovery processes must only be available to properly authorised and trained staff and in accordance with approved procedures.

In the case of hard drives and removable media, disposal may mean physical destruction, if they are not being re-used within the organisation. Older equipment with hard drives that potentially contain data of the organisation are sometimes passed on to charities or disposed of by third parties. It is essential that equipment with hard discs or removable media, including USB connectable memory devices, that has processed classified or sensitive information is not passed on without first guaranteeing that all such data has been irrevocably destroyed. In the case of third party secure disposal, a written contract must enforce this requirement.

Backup media that have reached their ‘use by date’ or that are redundant should be physically destroyed beyond any further use by incineration, shredding or cutting.

 

IG Improvement Plan

We will review the IGToolKit Documentation on a quarterly basis and indicate compliance and areas for improvement.

Each internal audit will be documented and scored.

Each week, the core IG Team will meet to review current status and undertake improvements by section. Minutes will be written and stored. Improvements agreed will be made by the person responsible. This IG Policy and the improvement plan will be updated frequently.

The IG Improvement plan was first signed-off and approved.

 

 

17th December 2015

 

Records for each audit will be added here:

 

Date of audit

IG Lead

IGToolKit checklist (Location)

Approved

(location of checklist)

Areas for improvement

(location of recommendations)

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Sign up to our Newsletter