The recently published "Strategic Privacy by Design" by R. Jason Cronk, CIPP/US, CIPM, CIPT, FIP, is an excellent overview of how to develop a privacy framework. By going through several practical examples, the book helps the reader think about ways to “bake in” privacy when developing almost any application, process or service offering. In addition, it gives the reader a better understanding of how to ensure you’re keeping an individual’s privacy in mind.   

The book is nicely divided into four sections: First, a broad introduction and overview of privacy along with its history — starting as far back as the 16^th century with the origin of the word “eavesdropper." Second, a discussion on frameworks that form the basis for identifying and mitigating privacy risks. Third, a description of how to analyze and assess your privacy model. And finally, the details of how it all comes together and how to build privacy into the business model.

Privacy by design is “all the rage” the last few years, especially with the recent implementation of the EU General Data Protection Regulation, but it is important to note that this book is not about the GDPR, although it can be used to help comply with privacy by design and default. The GDPR is not the purpose of the book, and in fact, it is not a “how-to” comply with any law in particular. It is more abstract and actually goes above and beyond any one specific privacy law and acts as a useful tool and knowledge base for anyone looking to build a privacy framework or bolster an existing one. 

Much to my delight, the author uses many real-life examples that we’re all familiar with (some of them his own personal experiences) and then expands on them to help us “think outside the box.” The book examines everyday processes, many of which we take for granted, that have privacy impacts. For example, when you give your name to a hostess while waiting for a table at a restaurant. Albeit it’s a minor example, but Cronk makes you think: “Does the host/hostess really need my name?” 

The author also uses many diagrams and flow charts to help the reader clearly see all the data flows and risk points with each flow. They are also valuable in helping the reader to perceive the whole privacy picture and potential vulnerabilities.  

For me, the most valuable takeaway from this book as a chief privacy officer is the way it makes you really think (and rethink) every solution and offering from a different privacy angle. Sometimes we get caught up in the “that’s how we’ve always done it” mantra, which is a dangerous thought track in this day and age. Reading this book gave me a better appreciation for how to best assess data collection, storage and use. By going through several scenarios, the reader can better visualize and make informed decisions on matters like:

• Do I really need to collect that data?
• Can the data be anonymized or pseudonymized?
• What other ancillary data may be collected, and do I need or want that data?
• Who is the threat?
• What categories or classes of data are impacted?

These are all queries that privacy professionals are familiar with, but Cronk’s book makes you see them from a different slant and take into consideration risk and ways to mitigate risk that you may not have thought of in the past. Sometimes, we are so involved in the solution, process or offering that we can’t see the forest for the trees. This book elevates the reader to see the whole solution in connection with the details.

I do have one slight criticism, which should not discourage anyone from reading this book: I love scenarios and find they are a great way to demonstrate how to see things from a different slant. However, I think that the author would have gotten more value from using different and more applicable, real-world cases. For example, seven or eight pages to discuss the privacy concerns surrounding whether to put a lock on the bathroom door of your newly opened restaurant (along with all the calculations of how many times/minutes the restroom is in use by individuals) could have been better served by something a little closer to a true privacy concern. The author did point out that he wanted to purposefully use a low-tech example, but I doubt anyone has (or ever will) crunch the numbers from a privacy perspective to try and determine the cost/risk of adding a $5 lock versus not adding a lock on a bathroom door.

The world is replete with “low-tech” privacy examples, and the reader would have been better served by a different one.