Information Governance
Serious Incident Requiring Investigation Policy
and Procedure
Document Control Sheet
Name of document:
Information Governance Serious Incident
Requiring Investigation (SIRI) Policy and
Procedure
Version:
Final – v1.0
Owner:
Senior Information Risk Owner (Chief
Finance Officer)
File Location / Filename:
G:\Corporate Documents\Policies
Date of this version:
December 2013
Produced by:
Head of Corporate Affairs
Synopsis and outcomes of consultation
undertaken:
Synopsis and outcomes of Equality and
Diversity Impact Assessment:
N/a
Approved by (Committee):
Audit Committee
Date ratified:
14th January 2014
Copyholders:
Next review due:
Head of Corporate Affairs
Corporate Affairs Officer
December 2015
Enquiries to:
Head of Corporate Affairs
Revision History
Revision Summary of Changes
Date
Author(s)
Version
Number
Approvals
This document requires the following approval of either an individual(s), group(s) or board.
Name
Title
Audit Committee
Date of
Version
Issue
Number
14/01/2014
V1.0
Page 2 of 20
Contents
1. Scope .................................................................................................................. 4
2. Introduction .......................................................................................................... 4
3. Definition .............................................................................................................. 4
4. Information Assets ............................................................................................... 5
5. Roles and Responsibilities ................................................................................... 5
6. IG Incident Reporting Tool ................................................................................... 6
7. Reporting and Publication .................................................................................... 9
8. Monitoring ............................................................................................................ 9
Appendix 1 - IG SIRI High Level Process................................................................. 10
Appendix 2 - Assessing the Severity of the Incident ................................................ 11
Appendix 3 – Definition of Breach Types ................................................................. 14
Appendix 4 – IG SIRI Annual Report Templates ...................................................... 19
Page 3 of 20
1.
Scope
1.1.
This policy applies to all staff who work for NHS North Norfolk CCG (NNCCG) and
members of the Governing Body. It is reflective of the Health and Social Care
Information Centre (HSCIC) guidelines for reporting, managing and investigating
Information Governance Serious Incidents Requesting Investigation (IG SIRI).
2.
Introduction
2.1
This policy supports the organisation’s strategic business aims and objectives by:



Ensuring that the CCG has implemented an effective information incident
management and response capability that supports the sharing of lessons
learned;
Ensuring that there is a considered and agreed IG incident response and
communications plan available, including the reporting of ‘perceived’ or ‘actual’ IG
SIRIs; and
Ensuring that the CCG’s management, investigation and reporting of IG SIRIs
conforms to national guidance and does not conflict with the organisation’s
policies and procedures for non-IG Serious Incidents (SIs) (e.g. clinical incidents)
3.
Definition
3.1
There is no simple definition of a serious incident. What may at first appear to be of
minor importance may, on further investigation, be found to be serious and vice
versa. However as a guide it includes:




Any incident which involves actual or potential failure to meet the requirements of
the Data Protection Act 1998 (DPA) and/or the Common Law of Confidentiality.
Unlawful disclosure or misuse of confidential data, recording or sharing of
inaccurate data, information security breaches and inappropriate invasion of
people’s privacy
Personal data breaches which could lead to identity fraud or have other
significant impact on individuals.
Any form of media including both electronic media and paper records i.e. the
CCG’s information assets.
N.B. Loss or theft of encrypted removable media (laptops, CDs, USB memory
sticks, media cards, PDAs) is not a IG SIRI unless you have reason to believe that
the protection applied to the device has been breached and personal data accessed
inappropriately.
3.2
It is essential that all IG SIRIs which occur in Health are reported appropriately and
managed in a robust way within work areas by applying a structured approach to the
identification of Information Assets and assigned Information Asset Owners (IAO).
IAOs will be supported by Information Asset Administrators (IAA) who are operational
staff with day to day responsibility for managing the risk to their information assets.
Page 4 of 20
4.
Information Assets
4.1
Information assets come in many shapes and forms therefore the following list can
only be illustrative. It is generally sensible to group information assets in a logical
manner e.g. where they are related to the same information system or business
process. Typical assets include,
Personal Information Content
 Databases and data files
 Back-up and archive data
 Audit data
 Papers, records (patient care notes
and staff records)
 Paper reports
Other Information Content
 Databases and data files
 Back-up and archive data
 Audit data
 Papers, records and reports
System / Process Documentation
 System information and
documentation
 Operations and support procedures
 Manuals and training materials
 Contracts and agreements
 Business continuity plans
5.
Roles and Responsibilities
5.1
Senior Information Risk Owner (SIRO)
Software
 Applications and System Software
 Data encryption utilities
 Development and Maintenance tools
Hardware
 Computing hardware including PCs,
Laptops, PDA, iPhones, iPads and
removable media
Miscellaneous
 Environmental services e.g. power
and air-conditioning
 People skills and experience
 Shared services including Networks
and Printers
 Computer rooms and equipment
 Records libraries
The SIRO is responsible to the Governing Body for ensuring an Information Risk
Policy is developed, implemented, reviewed and its effect monitored.
The
management and reporting of information incidents is one element of the
management of information risk, which should be managed in accordance with the
Assurance Framework: Key Strategic Risks.
The SIRO will:
 Take ownership of the CCG’s information risks;
 Act as the advocate for information risk on the Governing Body;
 Provide written advice to the Chief Officer, as detailed in the Annual
Governance Statement; and
 Occupy a key role in ensuring effective management and identification of
information risks.
Page 5 of 20
5.2
Information Asset Owners
Information Asset Owners (IAO) are senior staff responsible for ensuring that
specific information assets are handled and managed appropriately. This means
making sure that information assets are properly protected and that their value to the
CCG is fully exploited. Their roles include:





Understanding what information is held;
Knowing what is to be added and removed;
Knowing how information is moved / transferred;
Knowing who has access and why; and
Ensuring compliance with the relevant legal frameworks, i.e. consent and
confidentiality
As a result they are able to understand and address risks to the information assets
they ‘own’ and to provide assurance to the SIRO on the security, confidentiality,
integrity and use of the assets.
5.3
Information Asset Administrators
Information Asset Administrators (IAA) support IAOs by ensuring:




Policies and procedures are followed;
That actual or potential security incidents are recognised and reported;
Consultation with their IAO on incident management occurring; and that
Information Asset Registers are up to date.
6.
IG Incident Reporting Tool
6.1
From June 2013 all Organisations processing health and adult social care personal
data are required to use the IG Toolkit Incident Reporting Tool to report Level 2 IG
SIRIs to the Department of Health (DH), Information Commissioner’s Office (ICO)
and other regulators. A Memorandum of Understanding is in development between
the HSCIC and the ICO to share intelligence on IG SIRIs for the purpose of
supporting, guiding, investigating breaches, performance monitoring and improving
standards of health and adult social care services.
6.2
Local clinical and corporate incident management and reporting tools (including
Strategic Executive Information System – STEIS) can continue to be used for local
purposes but notification of IG SIRIs for the attention of the DH and the ICO must be
communicated using the IG Incident Reporting Tool with immediate effect.
6.3
The high level process for reporting an IG SIRI is categorised as follows, a flow-chart
for which is described at Appendix 1:
6.3.1
Initial Reporting
Suspected Incidents – Initial information is often sparse and it may be uncertain
whether an IG SIRI has actually taken place. Suspected incidents and “near misses”
can still be recorded on the IG Toolkit Incident Reporting Tool, as lessons can often
be learnt from them and they can be closed or withdrawn when the full facts are
known.
Page 6 of 20
Early Notification – Where a suspected IG SIRI has taken place, it is good practice
to informally notify key staff (Chief Officer, SIRO, Caldicott Guardian) as an “early
warning” to ensure that they are forewarned and in a position to respond to enquiries
from third parties. Where incidents occur out of hours, current on-call arrangements
will be followed to ensure that the correct contacts are notified.

6.3.1.1 – On-call arrangements
o
o
o
6.3.2
A member of staff should contact the On-Call Manager using the designated
telephone number as soon as they become aware of a suspected IG SIRI;
The On-Call Manager should contact the IG Lead of the appropriate CCG,
within 24 hours of the initial notification;
The CCG IG Lead should take the appropriate steps described below to begin
the reporting procedure.
Reporting Incidents
Details of the initial findings should be entered onto the IG Incident Reporting Tool
within 24 hours of notification of the incident. Staff should therefore ensure that the
Head of Corporate Affairs is notified as soon as a potential IG SIRI has occurred.
The severity of the incident will be determined by the scale (number of data subjects
affected) and the sensitivity factors selected as detailed in Appendix 2. If the
outcome of the severity is Level 2 (reportable) an email notification will be
generated by the system and sent to the HSCIC External IG Delivery Team, DH,
ICO and escalated to regulators, as appropriate. The IG Incident Reporting Tool
should be regularly updated as the investigation progresses, to enable automated
emails to be triggered to the HSCIC External IG Delivery Team, who will
subsequently be responsible for notifying and updating relevant organisations.
The reporting tool is intuitive but is reliant upon the user entering quality information.
Free text field such as “summary of the incident” and “details of the incident” should
be populated with data including:













Date, time and location of the incident;
Breach Type (Appendix 3);
Details of local incident management arrangements;
Confirmation that documented incident management procedures are being
followed and disciplinary action will be invoked when appropriate;
A factual description of what happened;
Theft, accidental loss, inappropriate disclosure, procedural failure etc.;
The number of patients / service users / staff (individual data subjects) involved;
The number of records involved;
The format of the records (paper or electronic);
If electronic, whether encrypted or not;
Whether the IG SIRI is in the public domain;
Whether the media are aware or there is potential for media interest;
Whether the IG SIRI could damage the reputation of an individual, work-team, an
organisation or the Health and Adult Social Care sector;
Page 7 of 20




Whether there are legal implications to consider;
Initial assessment of the severity level;
Immediate action taken, including whether any staff have been suspended
pending a full investigation; and
Whether the following individuals have been notified:
o Data subjects
o Caldicott Guardian
o SIRO
o Chief Officer
o Police and / or Counter Fraud
6.3.3













Identify who is responsible for managing the incident and coordinating separate
but related incidents;
Identify who is responsible for the investigation and performance management;
Identify expected outcomes;
Identify stakeholders;
Develop and implement an appropriate communications plan;
Preserve evidence;
Investigate the incident;
Adopt formal documentation including configuration management and version
control;
Maintain an audit trail of events and evidence supporting decisions taken during
the investigation;
Inform data subjects (e.g. patients, service users, staff), especially whether there
is potential for identity theft which can be avoided or mitigated if the data subject
is notified of the incident;
Institute recovery actions if possible;
Institute counter measures to prevent reccurrence; and
Invoke the CCG’s disciplinary procedure as appropriate and document where a
decision was taken not to take action (if it would be of relevance to a third party).
6.3.4







Managing the Incident
Investigating the Incident
Appoint an investigating officer;
Engage appropriate specialist help (such as Local Counter Fraud Specialist, CSU
Information Governance Manager, CSU IT Manager);
Coordinate investigations conducted across organisational boundaries (such as
Acute Trust, Mental Health, and Social Care);
Conduct a Root Cause Analysis (RCA)
Document the investigation and findings, preserving any evidence such as
minutes of meetings, emails etc.;
Identify lessons learned; and
Update the IG Incident Reporting Tool as appropriate, ensuring that only
information that the CCG wishes to be published by the HSCIC has been
recorded.
6.3.5
Final Reporting, Lessons Learned and Closure of the Incident
Page 8 of 20





7.
7.1
Set target timescale for completing investigation and finalising reports;
Produce a final report and obtain sign-off from Investigating Officer, Chief Officer
and Caldicott Guardian, subject to the severity (i.e. Level 2 IG SIRI);
Disseminate lessons learned to staff and members of the Governing Body;
Ensure that all investigations have been completed, affected parties notified and
any disciplinary action against staff has been settled to enable the IG SIRI to be
closed; and
Complete all fields within the IG Incident Reporting Tool including “action taken”
and “lessons learned” to enable the incident to be closed and the HSCIC External
IG Delivery Team to be notified via email.
Reporting and Publication
The reporting of personal data incidents in the Annual Report should observe the
principles listed below:



The information provided on personal data related incidents must be complete,
reliable and accurate;
All public statements made in relation to personal data incidents, particularly in
response to requests under the Freedom of Information Act (FOI) 2000, should
be reviewed to ensure that they are consistent with the information to be
published in the Annual Report; and
All exemptions under the FOI Act should be reviewed to establish whether details
of a personal data incident are unsuitable for inclusion in the Annual Report. For
example where the incident is sub judice i.e. cannot be reported publicly pending
the outcome of legal proceedings.
7.2
Details of all level 2 IG SIRIs should be included in the SIRO’s written advice to the
Chief Officer, as detailed in the Annual Governance Statement, and using the
template in Appendix 4.
7.3
Reports of Level 2 IG SIRIs extracted from the IG Incident Reporting Tool should be
published on the NNCCG website.
7.4
Details of all level 1 IG incidents should be aggregated and reported in the Annual
Report using the template in Appendix 4.
8.
Monitoring
8.1
The policy will be reviewed on a biennial basis and in accordance with the following
as and when required:




Legislative changes;
Good practice guidance;
Case law;
Changes to CCG infrastructure
Page 9 of 20
Appendix 1 - IG SIRI High Level Process
Potential SIRI
Make an initial assessment on IGT Incident
Reporting Tool and provide early warnings, if
appropriate
Manage in accordance with
local procedures
Yes
IG SIRI Level
0 or 1?
No
IG SIRI Level
2?
Yes
Reported to ICO and DH via
IG Incident Reporting Tool
Initiate Incident
Response
Plan
Review IG SIRI level in light of
findings. Update IG Incident
Reporting Tool
Investigation
Final Report
Close incident, note lessons learned and publish in
accordance with local procedure and on IG
Incident Reporting Tool
Page 10 of 20
Appendix 2 - Assessing the Severity of the Incident
The main factors for assessing the severity level of an incident are:






The number of individual data subjects affected;
The potential for significant distress or damage to the data subject;
The type of personal data breach of the Data Protection Act;
The potential for media interest;
The potential for reputational damage; and/or
The potential for litigation
Where the number of individuals potentially affected is unknown, the likely worst case
scenario should be used to inform the initial assessment of the SIRI level. However the level
should be re-assessed as soon as more information is known.
Categorising the level of an IG SIRI
Establish the scale of the incident. If this is not known it will be necessary to estimate the
maximum potential scale point.
Baseline Scale
0
Information about less than 10 individuals
1
Information about 11-50 individuals
1
Information about 51-100 individuals
2
Information about 101-300 individuals
2
Information about 301-500 individuals
2
Information about 501-1,000 individuals
3
Information about 1,001-5,000 individuals
3
Information about 5,001-10,000 individuals
3
Information about 10,001-100,000 individuals
3
Information about 100,001 + individuals
Identify which sensitivity characteristics may apply and the baseline scale point will adjust
accordingly.
Low:
For each of the following factors reduce the baseline score by 1
No clinical data at risk
-1 for each
Limited demographic data at risk e.g. address not included, name not
included
Security controls / difficulty to access data partially mitigates risk
Medium:
The following factors have no effect on baseline score
Basic demographic data at risk e.g. equivalent to telephone directory
0
Limited clinical information at risk e.g. clinic attendance, ward handover
sheet
High:
For each of the following factors increase the baseline score by 1
Detailed clinical information at risk e.g. case notes
Particularly sensitive information at risk e.g. HIV, STD, Mental Health,
Children
One or more previous incidents of a similar type in past 12 months
Failure to securely encrypt mobile technology or other obvious security
failing
+1 for each
Celebrity involved or other newsworthy aspects or media interest
A complaint has been made to the Information Commissioner
Individuals affected
embarrassment
are
likely to
suffer
significant
distress
or
Individuals affected have been placed at risk of physical harm
Individuals affected may suffer significant detriment e.g. financial loss
Incident has incurred or risked incurring a clinical untoward incident
Identify the adjusted scale and report as appropriate.
Final Score
Level of IG SIRI
1 or less
Level 1 IG SIRI (Not Reportable)
2 or more
Level 2 IG SIRI (Reportable via the IG Incident Reporting Tool)
Example Incident Classification
A
Health Visitor data inappropriately disclosed in response to an FOI request. Data
relating to 292 children, detailing their client and referral references, their ages, an
indicator of their level of need and details of each disability or impairment that led to
their being in contact with the health visiting service e.g. autism, chromosomal
abnormalities etc.:
Baseline scale factor
2
-1 Limited demographic data
0 Limited clinical information
Sensitivity factors
+1 Particularly sensitive information
+1 Parents likely to be distressed
Final scale point 3 = Level 2 IG SIRI (Reportable)
Page 12 of 20
B
A filing cabinet containing CDs with personal data relating to several thousand
members of staff sent to landfill in error during an office move.
Baseline scale factor
3
-1 no clinical data at risk
-1 Landfill unlikely to be accessed
Sensitivity factors
0 Basic demographic data
+1 Security failure (no encryption and poor disposal)
Final scale point 2 = Level 2 IG SIRI (Reportable)
c
Loss of an individual’s medical records. The records were found to be missing
when the patient concerned made a subject access request (SAR).
Baseline scale factor
0
0 Basic demographic data
+1 Detailed clinical information
Sensitivity factors
+1 Patient distressed
+1 Complaint to the ICO
Final scale point 3 = Level 2 IG SIRI (Reportable)
Page 13 of 20
Appendix 3 – Definition of Breach Types
Breach Type
Corruption or inability to recover
electronic data
Examples / incidents covered within this definition
Avoidable or foreseeable corruption of data or an issue
which otherwise prevents access which has quantifiable
consequences for the affected data subjects e.g.
disruption of care / adverse clinical outcomes.
E.g.



Disclosed in error
The corruption of a file which renders the data
inaccessible;
The inability to recover a file as its method / format of
storage is obsolete;
The loss of a password, encryption key or the poor
management of access controls leading to the data
becoming inaccessible
This category covers information which has been
disclosed to the incorrect party or where it has been sent
or otherwise provided to an individual or organisation in
error. This would include situations where the information
itself hasn’t actually been accessed.
E.g.








Lost in transit
Letters / correspondence / files sent to the incorrect
individual;
Verbal disclosures made in error (however, wilful
inappropriate disclosures / disclosures made for
personal or financial gain will fall within the reporting
requirements pertaining to Section 55 of the DPA unlawfully obtaining access to personal data);
Failure to redact personal data from documentation
supplied to third parties;
Inclusion of information relating to other data subjects
in error;
Emails or faxes sent to the incorrect individual or with
the incorrect information attached;
Failure to blind carbon copy (‘bcc’) emails;
Mail merge / batching errors on mass mailing
campaigns leading to the incorrect individuals
receiving personal data; and
Disclosure of data to a third party contractor / data
processor who is not entitled to receive it
The loss of data (usually in paper format, but may also
include CDs, tapes, DVDs or portable media) whilst in
transit from one business area to another location.
E.g.
Page 14 of 20




Lost by a courier;
Lost in the ‘general’ post (i.e. does not arrive at its
intended destination);
Lost whilst on site but in situ between two separate
premises / buildings or departments;
Lost whilst being hand delivered, whether that be by a
member of the data controller’s staff or a third party
acting on their behalf
Generally speaking, ‘lost in transit’ would not include data
taken home by a member of staff for the purpose of home
working or similar (please see ‘lost or stolen hardware’ and
‘lost or stolen paperwork’ for more information).
Lost or stolen hardware
The loss of data contained on fixed or portable hardware.
E.g.










Lost or stolen laptops;
Hard-drives;
Pen-drives;
Servers;
Cameras;
Mobile phones containing personal data;
Desk-tops / other fixed electronic equipment;
Imaging equipment containing personal data;
Tablets; and
Any other portable or fixed devices containing personal
data;
The loss or theft could take place on or off a data
controller’s premises. For example the theft of a laptop
from an employee’s home or car, or the loss of a portable
device whilst travelling on public transport. Unencrypted
devices are at particular risk.
Lost or stolen paperwork
The loss of data held in paper format. Would include any
paperwork lost or stolen which could be classified as
personal data (i.e. is part of a relevant filing
system/accessible record).
E.g.





Medical files;
Letters;
Rotas;
Ward handover sheets; and
Employee records
The loss or theft could take place on or off a data
controller’s premises, so for example the theft of
Page 15 of 20
paperwork from an employee’s home or car or a loss
whilst they were travelling on public transport would be
included in this category.
Work diaries may also be included (where the information
is arranged in such a way that it could be considered to be
an accessible record / relevant filing system).
Non-secure disposal – hardware
The failure to dispose of hardware containing personal
data using appropriate technical and organisational
means.
E.g.





Failure to meet the contracting requirements of the
Seventh Data Protection Principle* when employing a
third party processor to carry out the removal /
destruction of data;
Failure to securely wipe data ahead of destruction;
Failure to securely destroy hardware to appropriate
industry standards;
Re-sale of equipment with personal data still intact /
retrievable;
The provision of hardware for recycling with the data
still intact
*Appropriate technical and organisational measures shall be taken
against unauthorised or unlawful processing of personal data and
against accidental loss or destruction of, or changes to, personal data.
Non-secure disposal – paperwork
The failure to dispose of paperwork containing personal
data to an appropriate technical and organisational
standard.
E.g.



Uploaded to website in error
Failure to meet the contracting requirements of the
Seventh Data Protection Principle* when employing a
third party processor to remove / destroy / recycle
paper;
Failure to use confidential waste destruction facilities
(including on site shredding); and
Data sent to landfill / recycling intact – (this would
include refuse mix ups in which personal data is placed
in general waste);
This category is distinct from ‘disclosure in error’ as it
relates to information added to a website containing
personal data which is not suitable for disclosure.
E.g.


Failures to carry out appropriate redactions;
Uploading the incorrect documentation;
Page 16 of 20


Technical security failing (including
hacking)
The failure to remove hidden cells or pivot tables when
uploading a spread-sheet; and
Failure to consider / apply FOIA exemptions to
personal data
This category concentrates on the technical measures a
data controller should take to prevent unauthorised
processing and loss of data:
E.g.





Failure to appropriately secure systems from
inappropriate / malicious access;
Failure to build website / access portals to appropriate
technical standards;
The storage of data such as Card Verification Data
(CVD) alongside other personal identifiers in defiance
of industry best practice;
Failure to protect internal file sources from accidental /
unwarranted access (for example failure to secure
shared file spaces); and
Failure to implement appropriate controls for remote
system access for employees (for example when
working from home).
In respect of successful hacking attempts, the ICO’s
interest is in whether there were adequate technical
security controls in place to mitigate this risk.
Unauthorised access / disclosure
The offence under section 55 of the DPA - wilful
unauthorised access to, or disclosure of, personal data
without the consent of the data controller.
Example (1)
An employee with admin access to a centralised database
of patient details, accesses the records of her daughter’s
new boyfriend to ascertain whether he suffers from any
serious medical conditions. The employee has no
legitimate business need to view the documentation and is
not authorised to do so. On learning that the data subject
suffers from a GUM related medical condition, the
employee than challenges him about his sexual history.
Example (2)
An employee with access to details of patients, who have
sought treatment following an accident, sells the details to
a claims company who then use this information to
facilitate lead generation within the personal injury claims
market. The employee has no legitimate business need to
view the documentation and has committed an offence in
Page 17 of 20
both accessing the information and in selling it on.
Other
This category is designed to capture the small number of
occasions on which a Principle Seven breach occurs
which does not fall into the aforementioned categories.
E.g.



Failure to decommission a former premises of the data
controller by removing the personal data present;
The sale or recycling of office equipment (such as filing
cabinets) later found to contain personal data; and
Inadequate controls around physical employee access
to data leading to the insecure storage of files (for
example, failure to implement a secure desk policy or a
lack of secure cabinets).
This category also covers all aspects of the remaining data
protection principles as follows:





Fair processing;
Adequacy, relevance and necessity;
Accuracy;
Retention of records;
Overseas transfers
Page 18 of 20
Appendix 4 – IG SIRI Annual Report Templates
Summary of Level 2 Information Governance Serious Incident Requiring Investigation (IG
SIRI) Involving Personal Data as Reported to the Information Commissioners Office (ICO)
Date of Incident
[Month / Year]
Nature of Incident
[Table 1]
Nature of Data
Involved
[List of data items involved i.e. name, address, date of birth, NHS number]
Number of Data
Subjects
Potentially
Affected
[An estimate of the number of individuals should be provided if no precise
figure is available]
Notification Steps
[Individuals notified by post / email / telephone / in person]
[Details of media statement released]
[Details of law enforcement / health and social care agencies notified]
[Details of lessons learned disseminated to staff]
Further Action on
Information Risk
[Summary of any disciplinary action taken as a result of the incident / any
remedial action to prevent/mitigate reoccurrence]
Table 1
A – Corruption or inability to recover electronic data
B – Disclosed in error
C – Lost in transit
D – Lost or stolen hardware
E – Lost or stolen paperwork
F – Non-secure disposal – hardware
G – Non-secure disposal – paperwork
H – Uploaded to website in error
I – Technical security failing (including hacking)
J – Unauthorised access / disclosure
K – Other (refer to Appendix 3)
Page 19 of 20
Summary of Other Personal Data Related Incident (Level 1)
Category
Breach Type
A
Corruption or inability to recover electronic data
B
Disclosed in error
C
Lost in transit
D
Lost or stolen hardware
E
Lost or stolen paperwork
F
Non-secure disposal – hardware
G
Non-secure disposal – paperwork
H
Uploaded to website in error
I
Technical security failing (including hacking)
J
Unauthorised access / disclosure
K
Other (refer to Appendix 3)
Total
Page 20 of 20