Workiva advert TeamMate Ideagen advert

Data breach incidents and response plans

The HM 2015 Information Security Breach Survey report shows that there has been an increase in the number of organisations experiencing breaches. This means a member of the senior executive team should own and regularly review an organisation's incident response procedure. The procedure should enable responses to be effectively managed, including staff and any key third parties or contractors. Response plans will vary between organisations. 

Internal audit's role should be to support the business in preparing for a breach and understanding the lessons learned where one occurs but not managing or generally being involved in a breach, unless absolutely necessary.


What is a data breach?

The Information Commissioner’s Office (ICO) defines a 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 in connection with the provision of a public electronic communications service.'

Examples of a breach include databases being corrupted, data being released inappropriately (accidentally or deliberately), and unauthorised perpetrators accessing data (often known as hacking). They may be carried out accidently or deliberately by someone internal or external to the organisation. 

The Information Commissioner’s Office believe that serious breaches should be reported to them and service providers are required to notify the ICO if a ‘personal data breach’ occurs. They must also notify customers if the breach is likely to adversely affect customers’ privacy, and keep a breach log. In Ireland the Data Protection Commissioner has approved a personal data security breach Code of Practice to help organisations to react appropriately when they become aware of breaches of security involving customer or employee personal information.


How are data breaches discovered?

Data breaches are discovered through a number of different channels, for instance:

  1. Automated system monitoring - detecting  a potential data breach; this is usually reviewed manually prior to action being taken.

  2. Whistleblowing facilities for groups such as staff, customers and suppliers to report concerns anonymously. End users may report breaches to the IT helpdesk, however be aware that issues reported in this way may not be logged as breaches. To report incidents, staff need to be aware of the process; this should be included in both initial staff training and refresher training.

  3. After details are published by the hackers, or when members of the public find IT equipment and report it to news outlets. On occasions it may be that the breach is in the public domain before the organisation learns of it. It is then harder to control the flow of information and control the incident.

  4. When an incident comes to light, the actual report of the breach itself may contain sensitive and/or personal data which should be subject the organisation’s information classification policy and protected appropriately.

Information security policy

The organisation should have an information security policy that reflects the organisation’s objectives for security which is formally agreed by executive management.

The information security policy should include:

  • an acceptable use policy
  • details of how employees will be educated about protecting the organisation’s assets
  • how security measurements will be carried out and enforced
  • procedures for evaluating the effectiveness of the security policy.

The policy should also include how to record near-misses and how these are monitored.  Any incident may need a manual back-up and some way to invoke it without the use of IT systems, including communication with others.  


Response

Preparing for an incident

It is important to create an incident response plan in advance, before a breach occurs. It cannot be an afterthought. Where internal audit reviews readiness, the following points could be considered:

  1. Responsibilities and authorities should be defined to key individuals (the response team) along with contact details.

  2. The response team may include the head of IT, information security, head of corporate communications and senior executives. 

  3. Training should be conducted; exercises and scenarios should be practised to ensure that people are aware of their roles in an incident and the plan updated if need be.

  4. The internal escalation process for incident responses should be documented and tested periodically. It may be that other bodies need to be notified depending on the industry in which the organisation operates.

    Examples of bodies which may need to be notified include the Information Commissioner’s Office (ICO), Financial Conduct Authority (FCA), Prudential Regulation Authority (PRA), Care Quality Commission (CQC). Organisations may already have a documented process for approaching regulators, and these principals will need to be incorporated and the necessary individuals involved in planning.

  5. The breach may affect more than one physical or virtual site and the people on the response team need to have the relevant permissions to make decisions or enforce actions on these sites. This could include issues such as ensuring that response team members have passes which allow them access to all relevant sites, or ensuring that passwords are in place to allow them access to the relevant IT equipment.  
     
  6. The response team may need to secure the site(s) physically to ensure people’s safety. This may involve facilities management or using contractors. Again, ensuring that the response team have access to critical contacts and the ability to place order during an incident is critical.

  7. In responding to an incident, management need to be aware that while ensuring the integrity of critical systems, they should also consider any investigation and how this might be affected by the focus and actions of returning to business as usual as quickly as possible. A decision like this, and which takes priority if they cannot be done together, should be agreed by the board or sub-committee prior to the event.

  8. Prior to any incident, the policy should define system response times and the relative priority they have over business as usual processes.

  9. It may be that damage limitation is needed both physically on-site and with customers and the corporate communications team will be invaluable in assisting with this. Pre-agreed scripts for certain scenarios along with when and to who may save time in the event of an incident as well as communication method if normal tools (email, network, etc.) were compromised or unavailable because of the incident.

  10. A key point is that the organisation should test various scenarios periodically to ensure that the response is rehearsed and roles are known.

Responding/reacting to an incident

The predefined response should only allow defined and authorised staff to be involved in the response. Bear in mind that any continuing response could be time-consuming and potentially last for months.  

The response team need to be called together as soon as the data breach is known. (If the organisation employs media monitoring, this notification may happen at any time and the key individuals would have to be available out of hours.) Initially the meeting may be virtual; however getting the team together in person is an important step. An initial meeting should be held with the response team to establish the next steps and who to involve at that stage along with:

  1. The value of the data which has been breached needs to be understood so that the recovery can be prioritised. The organisation may have an incident categorisation model, such as minor, moderate, severe, crisis. This may depend not only on the volume of data but the nature of data (for example personal sensitive data as defined by the data protection act). 

  2. A decision on record keeping – both relating to organisational logs and records that the team create during the response. It is good practice to note down the timing of events, such as when individuals were informed, when decisions were made and who was involved in making them.

  3. A review of whether external bodies, including regulators need to be involved and initiate this, using the appropriate process.

  4. Whether a forensic expert is needed to understand what needs to be searched for, collect any/all items related to the incident as well as deciding whether the police, etc. need to be informed. The procedure should detail who can be contacted and who authorises the appointment.

  5. Ensuring any internal investigation is kept as confidential as possible; not only to protect the data but also because the source of the breach may be an insider who subsequently has a role in the response.

  6. Work to prevent any further breach and stop the current breach (if it’s ongoing) and mitigate the damage that the breach, and any leaked data, can cause. This might include the public relations team and the issuing of press releases. Ensure that the response team contains people with the authority to initiate this.

  7. Giving instructions to isolate the affected systems and equipment. These may be needed for any subsequent investigation. Ensure the chain of custody remains intact. Bear in mind that closing down or isolating a system could have a huge impact on the organisation.

  8. Beginning to investigate the cause of the incident. This may take a lower priority whilst the team firefight initially, but establishing how it happened may assist with stopping the current breach.

  9. How to recover systems in line with contracts/SLAs. This may involve invoking the business continuity or disaster recovery plans if key systems are unusable. IT should ensure that any secondary sites/systems are not also affected by the breach prior to rerouting critical systems. (There may be conflicts between the investigation and the recovery plans; the business tries to recover but the investigation is ongoing.)

  10. Establish who should be informed, both internally and externally; this could include the information security officer, IT, HR, facilities management, legal team, compliance team, internal audit, public relations/press office, security, regulators , police, insurers, alarm company and so on.

  11. Advising the information owner that data they are responsible for has been breached.

  12. It is likely that the proper investigation of an incident will delay the recovery to business as usual.

  13. Being aware of false alerts – these could potentially close down parts of the business.

  14. The temptation to launch a counter-offensive if the source is identified, but this is likely to be illegal.

Lessons learned (after the incident)

  1. Once the incident is brought under control the organisation has to consider how to learn from it and how to prevent further breaches going forward. As independent and objective providers of assurance internal audit is placed to be involved in this process as part of a team that has the overall expertise to perform this function. Internal audit should not accept involvement where it does not have the skills or experience. This also applies to the provision of assurance set out in the next section.

  2. This may also involve monitoring near misses at an appropriate committee or board (which should already be clarified as part of the organisation's information security policies and procedures).

  3. The organisation may find there are later repercussions from the initial incident and may find further leaked data in the public domain which requires an additional response. It may be that the attack ‘repeats’ and the cycle of responding to an incident continues. If this happens, the organisation’s resources can be heavily depleted and in extreme circumstances could cause the business to close down.

What can internal audit do?

Include the incident plan in the audit universe

Internal audit should incorporate the incident/breach response plan within the audit universe and periodically review the incident/breach response plan as part of the annual audit plan process. This will help ensure that the incident/breach response plan:

  • contains accurate and current information
  • is assessed and fine tuned
  • identifies potential issues in advance – before the breach occurs
  • allows the process to operate more efficiently – if a breach subsequently occurs
  • provide assurance that risks are addressed

Monitor and review activity

As part of the testing of the incident/breach response plan, internal audit can monitor and review the activity undertaken and confirm whether any lessons learned have been reflected in the plan.

Assess whether risk management is effective

Internal audit has an important role to play in evaluating whether risk management processes in this area is working effectively, that the reporting of risks is complete and accurate and that risk mitigation has been applied and is working in line with industry standards.

Review risk registers 

To begin with, internal auditors can review risk registers to ensure that risks in relation to data security and privacy have been adequately identified and assessed, according to the risk management process within the organisation, and that managers are working to and within risk tolerances.

Participate in internal/external forums

This is to ensure awareness of emerging security threats and practices for protecting against them.

Consider data security

Ensure that data security is considered and included generally during all types of audit work. 

Download PDF
Content reviewed: 2 May 2017