Systems holding personal confidential information - part 1 (4.1.1 - 4.2.4)

Personal data, in the context of health and care, is confidential information that is held (in paper format in some instances, but increasingly digitally) about staff and patients/service users.

This type of information would be held in systems such as:

• electronic patient record systems (EPR)
• picture archiving and communication systems (PACS)
• digital social care record 
• patient administration systems
• staff rostering systems
• payroll
• data warehouses
• a clinical correspondence system

Your organisation should keep a staff repository (normally within a HR department) of current staff and their roles. This repository should be up to date and reflect when staff are recruited, their change of roles and if they have left the organisation. Typically, in NHS organisations, this information can be found in the ESR (Electronic Staff Record). 

One of the biggest challenges for any organisation is tracking role changes of staff, especially when they remain on the same grade or have multiple roles.

Your organisation can strengthen its approach by implementing and monitoring a strong joiners, movers and leavers policy.

Your organisation should keep a register of all its systems. This encompasses systems that hold personal data, and those that do not, such as those holding corporate information.

Access to systems

There should be access controls within your organisation’s systems, and staff members should understand how and why these have been applied. Access to the system might be managed by the system itself, such as where you will enter your username and password, biometrics (fingerprint or facial) or insert a Smartcard to gain access to that system, or alternatively a form of federated access might be used in which a single account is trusted across multiple IT systems, as is the case with Single Sign On (SSO).

Regardless of how this is managed, you should know who has access to the information within systems, with this responsibility normally falling to the Information Asset Owner (IAO). If that information is shared with another system (such as through interfacing), you should know who has access to that system too. This Data Security Standard is not interested in how access works (such as username and password, smartcard or biometric), but uniquely who has access to the information in the systems.

Individual logins are important to use so that you can detect inappropriate access and apply specific access restrictions where needed. If a system does not have the capability for individual logins or they are not used for another reason, you must have a way of managing who has access to the system, and you must consider the mitigations for the associated risks.

Role-based access controls

One of the principles of data protection law is that you ensure that the data you use is adequate, relevant and the minimum necessary for your purpose. This ensures that confidentiality is maintained as access is granted on a need to know basis, whilst ensuring that staff have access to the data needed for their role. 

Role-based access controls are key to achieving these requirements. You should ensure that all staff members are granted exactly the right level of access to fulfil their roles. 

For each of your systems that have role-based access controls applied, you should list the type of role (such as admin) and the number of users who have been set up with that type of account.

A simple example is given below:

‘Least privilege’ should be at the centre of who has access to which roles. Referring to the table above, if a user only needs to view records, there is no need for them to have an elevated role such as ‘admin’ or ‘super user’. The ‘view user’ role will give them the level of access they require.

As organisations become larger, it can be more difficult to track staff roles (especially staff with multiple roles) across several systems.

The important factor is to grant access based upon what staff need for their roles today, not what role they previously had or what role they may have do in the future. Staff should not have too many access rights or too few. They should have just the right amount to fulfil their role. 

Managing access should be a continuous process.

As well as your regular processes for dealing with joiners, movers and leavers, there should be an intermittent user account audit (at least annual).

The audit should look at your user lists and roles for each system and reality, identifying changes or deleting/disabling.

You would expect such an audit to generate a work list as the simple example below:

Audit scope

The audit of systems should be scoped around those that contain personal sensitive information as defined in this document.

Where a user has inappropriate or incorrect system access rights in relation to their role, this sometimes can lead to an incident. As mentioned, these can be when there are too many or too few rights. The organisation should have an open and honest culture, which encourages staff reporting of incidents and near misses so that the organisation can learn valuable lessons.

Examples of the type of incidents that could occur include:

• a clinician is unable to order blood tests due to insufficient rights
• a junior member of IT deletes various groups within Windows active directory accidentally due to too many rights, in this case domain administrator role
• a disgruntled ex-member of staff manages to log on remotely and make several offensive postings - this could happen due to leaving employee accounts not being revoked in a timely fashion
• a member of staff sends a sensitive report to what is thought to be a printer located nearby but it goes to a printer in the staff member’s old department - this could be due to the account details of a member of staff not changing when they moved to a different department
• all members of staff can see a sensitive executive document - this could be due to staff having too many rights or the document too few

System logs are a vital part of security, allowing you to trouble shoot system performance and help alert and identify any anomalies that may indicate malicious activity. As such, logs are important records that need protecting.  

In generating logging information, it should be recognised that the logs themselves are records in their own right. They can contain information that is just as sensitive (if not sometimes more sensitive) than the originating records.

They should have their own retention schedule and security considerations. This should be explained in a corporate policy on logging (though this can be encompassed in another policy).

The policy should consider:

• security of logs for authenticated users only
• ensuring that logs cannot be tampered with
• offline backup
• log files for servers and workstations
• internet access
• mobile devices and tablets
• out of area lookup (physical or IP address)
• out of hours lookup
• logins from multiple devices with one account

The policy should be organisational aware. That is, A&E will not have a concept of out-of-hours or remote users may login from various devices if using virtual desktops.

Organisational policy should set out the rules defining log retention. The average time to detect a cyber attack is over three months and it is not uncommon for incidents to take significantly longer to detect. The most important logs for identifying malicious activity should be held for six months as a minimum. Organisations should consider the ability to trace an incident end to end, such as network address translation.

Guidance is available from the National Cyber Security Centre which will help you devise an approach to logging for security purposes.

It’s important to recognise that just retaining logs is of little value if they are not acted upon.

Many operating systems and information systems have categories and specific user accounts that by default provide access. These tend to have the same default identifier and password (if one exists at all).

A good example of this type of account is the guest account within Windows Active Directory or the guest session account in Ubuntu or Linux.

NCSC - Windows guidance

NCSC - Ubuntu guidance

As well as those system accounts, user accounts which are no longer needed (such as leavers) should be disabled or removed. This should be in conjunction with having a reviewed starters, movers and leaver process/policy as described in Guide 5 - Process Reviews.