5-step technical approach to practical privacy protection

5-minute read

At a very high level, I see two reactions when privacy regulations are mentioned. One is the ostrich stance, i.e., they refuse to look at it in hopes it will go away (which, BTW, even ostriches know won’t work). The other is the classic FUD (fear, uncertainty, and doubt) reaction, which is more akin to the ostrich approach given that looking the problem square in the I’s and T’s will dispel most of those responses. To be honest, there is a third reaction that is actually much more prevalent: the “I got this covered” reaction, which is usually far from the truth. If all this sounds a bit cynical, it isn’t meant to be. It is meant to get the attention of those that are either cynical or complacent about privacy and invoke another reaction: hope.

If wishes were results …

Hope sometimes comes with wishes, and my wish is that more enterprises approach privacy holistically. It is a wish because those three groups I mentioned in the first paragraph (and, to be fair, there is a fourth group that is completely and competently managing privacy … and I don’t get to meet them because of the nature of my job) all have something in common beyond being exposed to current and future regulations: they take a very siloed approach to addressing the issue.

Some companies will come at it from the legal point of view, deciding what their risk and exposure is and coming up with mitigation strategies that are focused mostly on dealing with the issue after it has happened. Others will come at it from a process perspective, drafting terabytes of documents that no one will read beyond the small team tasked with “documenting our privacy stance,” and expect that fulfilling only those parts of the regulations will be sufficient to protect them from the brunt of an audit.

Note that most large fines are a result of a major event, so none of the strategies applied by these silos will succeed in the event of a real issue.

As an architect, I may be biased in thinking that the last silo is most effective, even though it is still not sufficient by itself: the technical solutions. The IT silo (often siloed itself, which is fodder for another post) will look at ways to solve issues that could result in an event and tackle them as projects. In most enterprises, this will result in point-in-time solutions jumping from application to application and system to system that will cease to be fully effective no later than the third major project (again, there is a subset of organizations where this is not the case, and I never get to work with them).

All together now

The real solution is acknowledging that the silos exist and then insisting that they collaborate and combine their strengths to become compliant privacy-related regulations. The legal team can focus on understanding the laws and how they relate to the business. The compliance groups can create trainings and internal audit processes that ensure both people and technology do their part in maintaining data privacy. Finally, though certainly not lastly, IT puts into place patterns to protect privacy through architectural principles, testing procedures, change management controls, and diligent monitoring with alerts.

So, back in the real world, what prevents fulfilling my wishes? Money. Well, this is another area where collaboration can save the day. Bring in the analysts and the marketing folks and figure out how having better data management, a more reliable picture of the customer behaviors, and a goodwill marketing campaign about caring for customer data can improve margins and pay for these efforts … and probably the bonuses necessary to make them happen before a privacy audit.

The 5 steps

Now, my particular silo is IT, where I have learned the value of this type of collaboration. One key approach to collaborating with the non-technical stakeholders is to pull back the curtain and show that (at least at a high level) the technical aspects are not all that complicated. They can be covered in just five steps:

Step 1: Take ISO 27001 (information security standard) as a guideline for where to focus. Bonus points for adding in ISO/IEC 27701:2019 (an extension focused on privacy). For each section of these standards, map an architectural principle. A business with a robust enterprise architecture group will probably be able to apply existing principles and only have to generate a few more to cover the full standard.

Step 2: Work with the application, technical, and solution architects to establish patterns of compliance.

Step 3: Train the change management, project management, technical management, and quality management teams in the application of the patterns while emphasizing the business advantages.

Step 4: Conduct an audit of current assets and establish a remediation roadmap.

Step 5: Establish and curate a repository of the assets generated by steps 1 through 4.

I said it would be easy to understand; I did not say it would be easy to accomplish. But it is achievable. And worthwhile.

Step 6

Stepping an inch out of my lane here, it is just as important to train all those who have access to data on its proper management and the reasons behind it. Most highly regulated businesses already require all personnel to be trained in data privacy, and for good reason. It is a shame to put in good planning, effort, and execution on policies and programs supporting areas that handle the data as part of their necessary processes, only to have them side-swiped by groups that only handle data through secondary access such as sales, support, and marketing. Knowing how and with whom data can be shared and why it is important to limit how it is used will help those whose regular duties may not be as focused on the impact of copying data from one place or person to another.

Senior Technical Architect Scott S. Nelson has over 20 years’ experience consulting on robust and secure solutions in areas such as multi- and hybrid-cloud, system integrations, business process automation, human workflow management, and quality assurance innovation.