This article is not a guide about how to handle a notifiable breach. By now, you’re all familiar with the ICO Guidance on that. This piece is about the day to day handling of incidents based on over a decade of first-hand experience about what works, and what doesn’t.
- Keep it simple.
If the breach/incident handling process issued to staff at ’ground level’ is 50 pages long, you may want to re-think it. There is zero benefit to staff, the management team and definitely not the organisation if no-one is going to read the document, and long laborious documents are never a top priority for anyone. If it’s anything more than 3 pages, and preferably only 1 page, it is unlikely to be read. If no-one reads it, how will they know what to do if they find abandoned documents on the printer containing personal data, or if they inadvertently share personal data with the wrong colleague?
Your staff need a quick and simple procedure to follow. You could have a downloadable breach form (an example of this is in the Protecture Members Area) they can complete and email to a designated data protection email address, or a simple checklist with the information needed. However you do it, let staff know what information is needed and where to report it.
You could use the 5 W’s as your guide:
Who – who do they report it to? Who were the actors involved?
What – what happened?
Why – was it deliberate or accidental?
Where – where was data compromised? Was is on a server, was it in-house, was it offsite?
When – when did the incident happen and when was it discovered?
You will need robust documentation for the management team detailing what is/isn’t reportable, and you may need to link to regulator information if your organisation works in an area that requires separate reporting, but it is very unlikely that this level of detail is needed for all staff. Obviously, make it available to them, but have a quick reference guide available for the day to day reporting.
2. Don’t be bureaucratic about it – cut the red tape
Art 33(5) states “The controller shall document any personal data breaches, comprising the facts relating to the personal data breach, its effects and the remedial action taken. That documentation shall enable the supervisory authority to verify compliance with this Article. “
Statements such as “I didn’t record the incident on our log because they wouldn’t fill the form in”, actively cause a non-compliance with this requirement because not all breaches are being recorded. Don’t slavishly follow internal process at the expense of common sense and accurate reporting. As well as keeping it simple, keep it easy too. If a member of staff has spotted a risk to personal data, or they have witnessed, or even caused, an incident, let them call you and you can take the details over the phone as you fill in the breach log. Let them report it in person by your desk, in a corridor, or in the staff restaurant. How you get the information into the Incident log isn’t important, but it is important to record all the incidents. How will you gain an accurate insight into the trends within your organisation if you only record the incidents reported via the ‘correct process’? This isn’t just about fulfilling a legal requirement, it’s about ensuring the organisation has the full picture, that metrics are accurate, and your teams have an easy reporting route.
3. Keep Staff Informed
“We have a log that is available to the management team and data protection lead”. Great! Keeping the management team informed about incidents is a good thing. Risk registers can be updated, focussed data protection training planned, and resources allocated to where they are most needed to prevent re-occurrence of incidents.
It is also vital to keep staff informed about incidents. Is the incident log available on your intranet in a redacted form? Are metrics or incident trends fed back to staff during team meetings so that they are aware of what they can do from a personal perspective to prevent incidents? If you’re not feeding back to staff, you’re missing a free training opportunity, as well as depriving staff of vital information relating to the running of the organisation.
4. Have Useful KPIs
Good KPIs (Key Performance Indicators) take time to develop. A KPI is a measure of performance, often used to help an organisation define and evaluate how successful it is, typically in terms of making progress towards its long-term organizational goals. They’re not just dreamt up in a meeting by someone demanding to know X, Y or Z. KPIs need to be developed using SMART objectives. There are a few variations on the SMART theme, but a common one is:
Different personnel in the organisation will need to see different metrics, so make sure that your KPI’s are audience specific. Your staff will need to see different information from that presented to the Board, so bear this in mind when developing KPIs for incident reporting
There are lots of good resources available online for Incident KPI development, but whatever KPIs you select, make sure they add value to the organisation and the people in it.
5. Don’t Play the Blame Game
Anecdotal evidence suggests many people try to cover up a low-level incident, or just don’t report it because they are concerned about potential repercussions to themselves.
Create a positive culture in the organisation where staff can report incidents without worrying about negative consequences. Most incidents are caused by humans, and as humans are fallible, we will always make mistakes. Creating an environment where people can own up to mistakes, has the added bonus of encouraging people to be accountable for their actions, and over time, this culture will permeate the whole organisation because people’s expectations of themselves and their colleagues will change for the better.
We’re not suggesting that wilful acts of negligence or sabotage are not acted upon using appropriate disciplinary action by the way, if organisation policy is just ignored, then internal disciplinary processes will probably apply.