GDPR Guidance

Lawful Basis

You must have a valid lawful basis in order to process personal data.

There are six available lawful bases for processing. No single basis is ’better’ or more important than the others – which basis is most appropriate to use will depend on your purpose and relationship with the individual. The six are:

• Consent: the individual has given clear consent for you to process their personal data for a specific purpose. On the system you are able to use record based consent rules and referral/case based consent rules (Contact and Consent Rules)
• Contract: the processing is necessary for a contract you have with the individual, or because they have asked you to take specific steps before entering into a contract.
• Legal obligation: the processing is necessary for you to comply with the law (not including contractual obligations).
• Vital interest: the processing is necessary to protect someone’s life.
• Public task: the processing is necessary for you to perform a task in the public interest or for your official functions, and the task or function has a clear basis in law.
• Legitimate interest: the processing is necessary for your legitimate interests or the legitimate interests of a third party unless there is a good reason to protect the individual’s personal data which overrides those legitimate interests. (This cannot apply if you are a public authority processing data to perform your official tasks.)

For most users of Charitylog/Crossdata the first two are probably the most relevant but you should be aware of the others as they may well apply to some services offered by the organisation.

Individuals' Rights

The GDPR provides the following rights for individuals:

1. The right to be informed. You must tell someone what their data is being used for and by whom.
2. The right of access. If a person asks what data is held about them you must provide a copy of it. On the GDPR tab you will find the ability to export a portable record (see GDPR Changes) or you can use the Print Record facility to view on screen.
3. The right to rectification. If person advises that the data held about them is incorrect you must correct it.
4. The right to erasure. If a person asks you to remove their data you must do this (within 28 days). On the GDPR tab you will find the 'Forget me feature' (see GDPR Changes)
5. The right to restrict processing. If a person asks you to stop processing their data (ie withdraws consent) you must stop processing it further. This will be available shortly on the system, which will lock the record, until consent is then received or destruction of the record is required.
6. The right to data portability. You must be able to provide a copy of their data in a 'commonly used' format. On the GDPR tab you will find the ability to export a portable record (see GDPR Changes).
7. The right to object. This normally applies to processing based on legitimate interest, for direct marketing and for research or statistical purposes. Unless you can demonstrate that you have an overriding reason you must stop processing.
8. Rights in relation to automated decision making and profiling. This relates to automated processes - for example where a person is automatically sent marketing information based on their buying patterns. GDPR has strict guidelines about this type of processing.

These rights are intended to allow a person to determine where their data is held and what it is used for.

Sensitive Data

GDPR distinguishes between 'personal data' such as name, address, telephone number and 'sensitive data' which would include medical information, religion, sexuality for example. Only collect and process sensitive data if you have good reason to and ensure that it is only used for the reason for which it has been collected.

Data Controllers and Data Processors

GDPR recognises two key roles in data processing:

Data Controller: This is a person or organisation that determines the purposes for processing the data and the means by which the data is to be processed.

Data Processor: A person or organisation responsible for processing personal data on behalf of a controller.

In most organisations the Data Controller will be the senior management who determine why the data is needed and the mechanisms that will be used to do this. The Data Controller would make decisions on the type of data that is collected and how it is processed and should be able to justify the need to collect personal data, especially if it is classed as sensitive, in the event of a security breach.

The Data Processors will therefore be the people who input and report on data at the behest of the data controllers. They should maintain records of their processing activities as they too will be legally responsible if there is a security breach.

Role of Dizions as a Data Processor

Dizions provides users with access to the Charitylog/Crossdata systems and creates the initial databases.

For the most part, Dizions staff will not have access to the data stored in the clients' databases as users are forced to change the initial passwords when logging in for the first time.

However, Dizions support staff will have access to personal data in the following circumstances:

1. If data migration is requested, staff will need to be able to view the data being migrated during the process.
2. If a remote desktop session is arranged to assist with technical support, Dizions staff will be able to view personal data displayed on-screen during the remote desktop session.

It may be prudent as part of the consent information given to clients to advise them that Dizions, as the owner of the data processing system, may be given temporary access to personal data in order to carry out these required support tasks.

In terms of data security, Dizions and its sub-contractors, apply high standards of physical and electronic security to ensure that data is not vulnerable to failures of hardware or software. Regular automated backups are made and stored for fourteen days.

In the event that a customer ceases to use Charitylog/Crossdata and does not request transfer of the data to another system or instruct Dizions otherwise, Dizions will destroy the database and any associated backups after a period of six months.

Use of the system to achieve GDPR compliance

Centralised Data Processing

1. Meeting GDPR requirements is easier if all data is stored in one system and not spread across numerous office computers, filing cabinets, spreadsheets, etc. Use the system for recording all client data as far as possible so that your stored personal data in the one system.

This includes:

• recording all contacts in the system;
• using uploaded documents where appropriate to ensure all information is held against the single client record;
• where standard fields are not sufficient, using Extension Databases - again to keep all data linked to the one record.

This will greatly assist you to deal with (i) client requests to know what data is held about them, (ii) requests for a copy of the data in electronic format, (iii) requests for data to be corrected, (iv) requests to cease processing and (v) requests for data to be erased.

The latest versions of the system have simple functions which enable you to meet each of these requirements, but they cannot include any data you hold in separate systems such as spreadsheets, other databases and paper files. Try to minimise, or eliminate altogether, additional copies of client data.

2. Charitylog/Crossdata data is stored on a server accessed via the internet so all users are accessing the same client record. Information is not stored on the computer used to access this record so your data is safe in the event of computer failure, theft, fire etc.

3. Access to the system is through a two-stage login process. Provided you have effective electronic security measures in place you can assure your clients that their data can only be accessed by authorised users.

Privacy by Design

The ICO emphasises that 'Privacy by Design' should be considered at all stages of data processing. Within the system this is achieved in a number of ways.

1. Tailored screen layouts. All screens can be comprehensively redesigned to suit individual requirements. Data fields not required to deliver your services can be removed from the screens altogether. This is reversible so, if your data requirements change, you can reinstate fields at any time. This can be achieved by using Field Sets on projects, tailoring a user account by specifying which projects they can access (see User Account Details).
2. General and Personal tabs - sensitive data fields are normally located on the Personal tab of a client record. These can be made visible on a user-by-user basis so that users who do not need to view sensitive data fields can be barred from seeing them. See User Account Details for on how this is achieved.
3. Field sets (new function). In addition, data fields can be grouped together in fieldsets. The fieldsets can be associated with projects so it is possible for more sensitive data to only be visible to users who have access to the relevant projects. See Field Sets and Project Set Up for further details.
4. User identification. Ensure each Charitylog/Crossdata user has their own personal login - no use of shared "Reception" or "Volunteer" logins for example. This means that users' actions are all automatically logged so, in the event of a data breach for example, a log of a user's activities is available.
5. Restricted user access. Users can be set to have restricted login days and times. If there is no reason for a user to have access to data outside of the working day the user settings allow administrators set the access days and times to (for example) 09:00 to 17:00 Monday to Friday. See User Account Details.
6. Restricted IP addresses. If your internet provider gives you a static IP address (or addresses) you can make it impossible for groups of users to gain access outside of the workplace. See Restricted IP Addresses to setup and Group Access to activate per security group.

Different organisations may make different use of these capabilities but it should be possible to ensure that data is both secure and accessible to those who need to process it.

It should be apparent that Users must be made inactive immediately on leaving the organisation.

Consent

Consent has much greater significance under GDPR. It must be:

• Explicit - no default 'Yes' boxes, no automatic opt-ins and a very clear and specific statement of what activities or services the client has given consent to.
• Granular - you must have separate consents for different services or to pass details to other organisations. You cannot have consent to pass details to other organisations in general - there must be separate consents for each one. See Consent Rule Text Entry for further details.
• Separate from other terms and conditions.
• As easy for an individual to withdraw consent as to grant it.
• Evidenced - copies of signed and dated forms or dated emails granting consent. Verbal consent should be backed up by physical evidence. This can be placed in Uploaded Documents.
• Reviewed periodically and refreshed whenever situations change.

The system has extensive consent functionality which can be linked to organisations and services. You can schedule consent reviews and remove consent at any time. The ability to refer clients to another organisation is now dependent on a record of consent from the client to do this. Consent Rule Text Entry and Consent for External Referrals for further details.

The advantage of keeping all client information in one system makes management of consent much simpler than if the consent records are stored in various different systems.

Rights of Individuals

The Right to Know What is Held

Clients have a right to know what information you hold on them - the system has a function that can provide a printout or file of all this information. See Print Record for details.

The Right to Data Portability

The system has a function allowing you to export all of a client's records into an Excel spreadsheet that can be passed on to another organisation. See GDPR Changes for further details.

The Right to be Forgotten

The system has a function that allows a client record to be fully anonymised thus removing all personal data from the system. The record is not normally removed completely as this would also remove associated contact records for staff, thus deleting data that may be needed for staff timesheets, etc. The records would show that a member of staff had contacts with a person but would no longer be able to identify that person. The degree of anoymisation can be specified by the system administrator. See GDPR Changes and Cleanse or Anonymise Records for details.

These functions will obviously only process records within the system. Records stored in other systems will need to be processed separately.

Summary

By keeping all your client data in the system you can more easily meet the GDPR requirements of

• data security, as the data is stored in a single, secure system that is not on your premises;
• privacy, as it is protected by appropriate levels of access
• consent, as a comprehensive record of consents is maintained and
• requests from individuals for sight of data, accuracy, portability and erasure.

In the event of a data breach, you will have a full record of all users’ activities which may be invaluable in a subsequent investigation.