<div dir="ltr"><a href="https://www.computing.co.uk/ctg/news/3019682/gdpr-what-will-happen-in-the-first-72-hours-after-a-data-breach" target="_blank">https://www.computing.co.uk/<wbr>ctg/news/3019682/gdpr-what-<wbr>will-happen-in-the-first-72-<wbr>hours-after-a-data-breach</a><br><br>While the countdown began more than a year ago, it's only now that many organisations are preparing in earnest for GDPR - with the EU regulation coming into full force in just eight months.<br><br>Many are still unprepared for GDPR and the CIOs and CISOs at most organisations don't believe they will be fully prepared in time, leaving them open to fines of up to €20m or four per cent of revenue.<br><br>Yet, for organisations with limited IT security resources - and sometimes only employing security staff part-time - the most pressing concern is often around the reporting timeline itself, and whether it is even possible for them to detect and report a data breach within 72 hours.<br><br>To help with this dilemma, let's break down the practical steps involved in dealing with a breach, and propose a rough order in which to tackle them.<br><br>Preparation<br><br>By far, the most important step in meeting GDPR requirements is to lay the groundwork, and ensure that your organisation has put all the necessary policies and procedures in place well before May 2018, and also documented them, so that it can demonstrate the steps it has taken to achieve compliance.<br><br>Realistically, it is only if you have these systems already set up that you will be able to react quickly enough to hit the 72-hour deadline.<br><br>The first step is to identify and locate your organisation's assets. In terms of GDPR, this means understanding where your customer data is stored, or could be accessed, including when it is used and processed by cloud applications.<br><br>It is also important to identify how your organisation stores and uses customer records, such as the information acquired when a customer signs-up for a mailing list or fills out a form to download a white paper.<br><br>The next step is to set up security alerts that will warn you if there are any potential risks to this data. Security teams often complain about being bombarded with these sorts of alerts, but after next May, there will be no excuses for missed alerts or mistakes.<br><br>To help cut through the noise, alerts can be grouped by assets, such as people, and those involving customer data could be labelled as relevant to GDPR. This will help you to spot more quickly when a breach has occurred and save you valuable time when you need it.<br><br>Another aspect of preparation is to clarify the reporting procedures that your organisation will use to inform shareholders, customers and regulators about a potential breach. For this process to work effectively, it's vital to have communications, legal and management teams looped in and briefed in advance, so that they are ready to work together.<br><br>Such preparations should include drafting a blog and letter template, and clarifying the process for sharing these communications to the public so that everyone is clear on their responsibilities in the event of a breach.<br><br>Indeed, the public response to a data breach should now be part of any disaster recovery planning if it isn't already.<br><br>The clock starts ticking<br><br>Provided that you have set up security alerts as outlined above, and monitor them carefully, you should be notified almost immediately when a data breach occurs. In the immediate aftermath of an attack, your primary focus should be on containing the incident by isolating the affected systems to prevent further damage. If you can identify some of the elements that contributed to your breach, such as an individual laptop, then you can take that section off the network and do some forensic analysis.<br><br>Once you've contained the incident, you need to find and eliminate the root cause. Attackers may have used a specific vulnerability such as HeartBleed, sent a phishing email, or cracked a weak password - but to undo its effects, you will probably need to remove the malware, and then wipe and reinstall affected machines.<br><br>The deadline looms<br><br>Once you have a decent understanding of the breach, you must involve the legal, communications and management teams within your organisation. Together, you must identify the level of risk to the customers or clients that might have been caught up in the breach.<br><br>If it is likely to result in a high risk to the rights and freedoms of individuals - such as the compromise of hospital records - you must notify those people concerned directly, as well as notifying the relevant supervisory authority.<br><br>Any breach notification should include:<br><br>- The approximate number of individuals affected by the data breach;<br>- Details on the type of personal data records concerned;<br>- The name and contact details of someone within your organisation who can provide more information;<br>- A description of the likely consequences of the breach for individuals; and,<br>- The measures taken (or proposed to be taken) to mitigate it.<br><br>These communications will need to be drafted (based on the earlier templates), approved by management tiers, and then distributed to your customers, shareholders and regulators. In the case of a significant breach, this communication will likely trigger an avalanche of incoming calls from worried customers, interested parties and the media.<br><br>The aftermath<br><br>While it's relatively easy to identify and contain a data breach within 72 hours, it can take significantly longer to fully eradicate and recover from the incident.<br><br>Reinstalling and recovering from back-up could take several days, depending on the amount of data involved and the testing required to make sure that systems are working successfully. During this recovery process, affected systems can gradually be put back onto the network, but it's vital to keep a very close eye on them and monitor for any errors.<br><br>The final important step is to review and analyse what happened, work out why it happened, and consider how such a breach could be prevented in the future.<br><br>Unfortunately, security breaches are so common that it is really a case of when rather than if a breach will occur, but understanding how an attack took place and learning lessons from it can help an organisation improve its overall security posture.<br><br>Finally, it's important to share technical information about the breach among your peer group and threat-sharing sites, so that the wider community can prepare their systems to detect similar attacks - and you, likewise, can learn from their experience, too.<br></div>