A gap analysis can be a helpful way to keep your company compliant, but these complicated procedures often lay the groundwork for errors. Some mistakes are small and easily fixed with more attention to detail. Others will take longer to work out, largely because they require a full overhaul of the process.
However, there are universal truths about compliance that are relevant regardless of the size of the mistake. The longer it goes unchecked, the more likely you are to land the company in an imbroglio. So before you assume your gap analysis is a well-oiled machine, we’ll look at nine things you shouldn’t do.
A data controller and a data processor play two different roles. The controller is there to determine why the data is being processed. It’s the controllers that that bear the full burden of compliance. The processor will follow the controller’s instructions. They do bear some responsibility, but the liability is relatively limited.
Controllers and processors are often the same people on different days, depending on how data is distributed and stored. This can make it difficult to protect the data subject’s privacy, which in turn increases the odds of a violation or breach. A successful gap analysis will take a deep dive into the responsibilities of each controller and processor, so everyone understands what’s expected of them.
Data processing agreements are meant to clearly define the responsibilities of different parties and clarify everything from auditing procedures to subcontract conditions. When these agreements are made or amended, the temptation is to use standard legalese designed to cover a multitude of potential events.
Yet rushing through the process only makes it more likely that the details will be incomplete, leading to confusion should anything be called into question. From mismatching clauses to unclear lines of consent, the main risk is that these contracts will become null and void due to their illegitimacy.
Processing details require a real discussion and while this takes time, it’s a necessary step of the process. You should be going through line by line, especially if the scale or nature of the data processing changes.
The remediation documents are supposed to address the issues raised in your gap analysis. However, it’s all too common for the information in the language in one to look different from the other. This could be because different employees are drafting the documents or because the company assumes that the existing remediation protocol will fix the inherent problems with data processing.
In the worst-case scenario, the remediation plan might actually contradict the gap analysis results. Your privacy policy will have a lot to do with syncing your strategy, so you need to show that the remediation plans are specific to the analysis results.
If your individual processing approach isn’t aligned with your general governance strategy, you’ll eventually see your privacy policies start to unravel. Even if processors are being exceptionally cautious and following every protocol, this won’t mean anything if your general information security is lacking. For downstream compliance to work, it needs to be structured correctly at the top.
A gap analysis is an excellent time to examine not only how the standard hierarchy functions, but also how horizontal data sharing works. From Sales to Accounting, employees on the same level (e.g., senior managers, etc.) are often given the same information, but it’s shared for very different reasons. A gap analysis won’t work if these discrepancies are never acknowledged.
The data for one person can span from job experience to criminal convictions to access credentials. To figure out the definition of what qualifies, you need to be well-versed in GDPR law. Unsurprisingly, it’s common for employees to underestimate just how much relevant data there is to sift through.
This step is an arduous one when you’re already slogging through a gap analysis, but it typically means taking a fine-tooth comb to every detail and then figuring out which category it falls into. HR is going to be very different data than a CRM, but both sets are equally important to ensure that no data goes overlooked.
Many data controllers misinterpret what counts as a lawful basis, which can lead to questions of whether data subject consent is valid. It’s why the National Data Protection Commission (CNPD) is more likely to require proof that a balance test was done before declaring legitimate interest.
Whether you’re collecting data in the name of public health or to give underprivileged people an opportunity to borrow for a new home, these tests show that you’ve done your homework. When you’re justifying your collection, make sure your logic is easy to follow. You should also resist the urge to use more than one basis, as adding more reasons can quickly confuse your rationale. The main thing to remember is that you’re not using blanket consent as a means to keep you from potential prosecution.
Data subjects have inalienable rights when it comes to knowing how their data is used, and the GDPR wants it to be easy for them to voice concerns. If you’re not prepared to handle these requests, the larger consequences will be felt throughout the company.
You should have a very clear policy about which situations merit different responses. Your company needs to organise the technical aspects of each request, regardless of where and how it originated. For example, after you’ve received the request, the company should acknowledge it in some form (e.g., email, letter, etc.) within a short timeframe. It should then be given to the appropriate parties for further processing.
Your company will need to verify the identity of the subject data and assess whether the request is valid. (Certain requests may not have to be fulfilled if they’re made for illegitimate reasons, such as a personal vendetta against a specific employee.) There should be an official response within a month, unless there are extenuating circumstances.
Much like consent, companies might view certifications from business partners as a way to protect them. In fact, it’s not uncommon for companies to request certifications even if its leaders don’t have one to supply in return.
However, certification for companies has become more complicated these days, with more organisations claiming to have the power to bestow them. In some cases, these claims might be overblown or even outright lies. A certification does not necessarily reduce the responsibility of the data controller, and is unlikely to be taken as sufficient proof in the case of a compliance dispute. You need to be taking measures to ensure your business partners are implementing safety metrics to keep data from slipping through the cracks.
Data breaches take a tremendous amount of time and energy to handle, and this is true even for companies that are prepared for them. If you’re not planning ahead, you’re going to make the issue that much harder on the company.
As with data subject requests, there needs to be a very clear policy on the internal actions of each department. Action needs to be taken immediately to either prevent a data leak or at least mitigate the adverse effects of one. A risk charter can go a long way toward defining the categories of threats and laying out different expectations for each one. Notification templates can also improve communications during a chaotic time.
Implementing better policies takes a lot of time, and it’s not always easy for a company to coordinate schedules for these often painstaking tasks. However, as difficult as it is at first, the process will become much more streamlined as long as you’ve laid the right foundation.
You can also look into integrating a compliance software with your programs to automate as much as possible. This can free up your employee’s to-do list to focus on the details of the data collection. From who’s being told to how the data is being mapped, streamlining the flow has a lot to do with avoiding lengthy investigations and hefty fines.