GDPR applies to controllers who are established in the EU, as well as those organisations who are not established in the EU but offer goods or services to, or monitor the behaviour of, data subjects within the EU. Therefore, it substantially extends the territorial scope of organisations who must comply with data protection laws (in comparison to the UK Data Protection Act 1998 (DPA).
The focus is no longer on the use of equipment located within an EU member state; instead, the focus is on those who are targeting EU citizens. This means that non-EU organisations not previously caught under the DPA for targeting an EU market or EU citizens, will now be caught by the GDPR, despite lack of presence or use of equipment in the EU.
For the first time, the GDPR also introduces statutory obligations for processors. Under current data protection laws, the controller party has statutory responsibility for the processing of the personal data. However, GDPR introduces statutory obligations for processors.
The ‘controller’ is the party who determines ‘why’ the personal data will be processed (i.e. the purpose of the processing) and, where the controller appoints a processor, the processor determines ‘how’ the personal data will be processed (i.e. the method of the processing). Typically, an IT services provider (like us) will be a processor and its customer will be the controller (Local Authority and CCG).
The new processor obligations relate to the requirement to put in place GDPR compliant processing clauses (see section 2.6), security measures, security breach notification (see section 3), international transfers, data protection impact assessments (see section 2.8), data protection officers (see section 2.9) and record-keeping. Fines may be imposed on processors (see section 4). Other enhanced supervisory authority powers such as auditing also apply to processors.
GDPR defines ‘personal data’ as: ‘...any information relating to an identified or identifiable nature person (‘data subject)’; and identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person’.
The GDPR definition of ‘personal data’ is broader than under the DPA and includes IP addresses, device IDs, location data and genetic and biometric data.
The information we hold is not patient identifiable and is only given to us by the providers themselves based on a pre-authorised set of criteria by the data controller. The providers do list their registered managers in post with relevant phone numbers for that position, and although in most cases this is not personally identifiable (i.e. [email protected]) in others it can be (i.e. [email protected]).
We don’t process the information for our controllers we only display the information the provider lists as a summarised format, the wide spread date processing of the information does not occur.
We have taken a blanket approach to provider updates in BedStateTracker.co.uk and declared ourselves as a small scale data processor on behalf of your local authority and CCG (The data controller) and thereby comply with all elements relating to us within the GDPR. We have also been through the DPIA screening check list and although we are a data processor we are not on a large enough (or sensitive enough) scale to warrant a DPIA check.
This DPIA Screening output can be found at the bottom of this page.
The ‘controller’ is the party who determines ‘why’ the personal data will be processed (i.e. the purpose of the processing) and, where the controller appoints a processor, the processor determines ‘how’ the personal data will be processed (i.e. the method of the processing). Typically, an IT services provider will be a ‘processor’ and its customer will be the ‘controller’.
In this regard your CCG and Local Authority are "the controller" and they dictate how we "the processor" handle your data.
Just to be clear, Sundown Solutions are a Data Processor of the information that the controller (Local authority and CCG) has asked us to gather - namely your occupancy information. We are contractually bound as a provider to your Data Controller, in most cases this is via a standard G-Cloud 10 contract
We only hold the information that a home provides to us, this is typically the contact information for the home, the CQC categories for the home, links to the relevant CQC reports on the CQC website and of current generic vacancy numbers (i.e. Nursing Bed 0)
The data is supplied by the providers via app, email, phone, Web Portal or Web Chat and updates our system directly. There is no additional processing of the information, other than listing the data in order of occupancy availability to the pre-determined audience with a vested interest in occupancy information
The data is accessed by the providers during update and our BedStateTracker.co.uk administrators who update on their behalf if a provider chooses to update via email, phone or Web Chat.
The Local authority CHC team and CCGs have access to the information as the processors and they then grant access to other parties with a vested interest in occupancy via a Discharge Co-Ordinator account. The recipients of this account are usually local hospitals, social workers and other staff that require the ability to view occupancy and contact homes.
Our internal IT Administrators have access to the IT systems that hold the data, as do all IT companies in a similar scenario. Our administrators are fully UK resident and DBS checked.
All access to all records is logged, audited and monitored - at no time can any authorised (or unauthorised) individual access the data with full auditing taking place.
The data is stored in our two main data centres in the United Kingdom. At no time does any part of the data (or backup data) leave the United Kingdom.
All data is fully encrypted in-flight and at rest as is all backups and backup repositories.
The GDPR defines a personal data breach as a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed’. This means that a personal data breach is more than just being hacked or losing personal data.
Breaches will be reported to the ICO unless they are unlikely to result in a risk to the rights and freedoms of individuals. The examples of notifiable breaches provided by the ICO are where breaches may result in discrimination, damage to reputation, financial loss, loss of confidentiality, or any other significant economic or social disadvantage.
Many people also don’t consider that simply emailing details of one home to somebody outside the chain of communication by accident also constitutes a breach.
In any case if a data breach does occur the corresponding member of staff will report this to their line manager and they will inform the effected party by email, phone or letter based and if necessary inform the ICO within 72 hours of initial detection.
The nature of the personal data breach including, where possible, the categories and approximate number of both the individuals and personal data records concerned the name and contact details of our representative and where more information can be obtained, a description of the likely consequences of the ‘personal data breach’ a description of the measures – proposed or taken – to deal with the ‘personal data breach’ and where appropriate, of the measures taken to mitigate any possible adverse effects.
As a provider you will have the right the understand what data we hold about you and how this is processed. To do this you can send us a Subject Access Request (SAR) at any time by emailing us at [email protected] with the Subject of SAR and the details of your request.
You will have to pass security checks for authentication purposes but we will endeavour to provide the following information
The information that should be supplied includes:
This documented risk assessment is known as a ‘data protection impact assessment’ or ‘DPIA’. A DPIA is a process designed to describe the processing, assess the necessity and proportionality of processing, and to help manage the risks to the privacy of the data subjects resulting from the processing of personal data (by assessing those risks and determining the measures to address them). DPIAs are important tools for accountability, as they help controllers not only to comply with requirements of the GDPR, but also to demonstrate that appropriate measures have been taken to ensure compliance with the GDPR – a DPIA is a process for building and demonstrating compliance
The following screening checklist was provided by the ICO to determine if BedStateTracker.co.uk requires a DPIA. We do not fall into any other these categories so a DPIA is not required (as of 2018, reviewed quarterly)
We are not subject to a DPIA based on the criteria check below - we do not: