Addressing Governance and Regulatory requirements

In our last post, Evaluating threats against and vulnerabilities of critical assets, we discussed the second of six processes we need to implement a data security practice: evaluating threats against and vulnerabilities of critical digital assets. We looked at the SEI’s OCTAVE and the ISO/IEC 27001, both of which describe assessments that fit our needs. Now we will delve into the third process, assessing our governance and regulatory requirements.

Addressing Governance and Regulatory requirements.pngThese two concepts, governance and regulation, are linked. By governance, we infer a specific meaning used for management purposes, namely that our organization exhibits “accountability for consistent, cohesive policies, processes and decision rights.” And by regulation, we mean both public laws and private policies imposed by external parties, such as governments and trade associations, that require compliance from our organization. These concepts are intertwined of course, as part of governance includes the ability to show we are complying with our regulatory environment.

And some regulations are easier to comply with than others. Specifically, private policies imposed by trade associations, such as the Payment Card Industry (PCI) Security Standards Council (SSC) Data Security Standard (DSS) imposes the same requirements on all credit card processors regardless of geographic location. Government laws, policies, and regulations? The short answer is good luck with that!

When public law is involved, regulations are woefully complex. For example, under US federal law, citizens have had privacy torts since 1890.[1] A tort requires that the plaintiff prove he or she was damaged. However in California, residents received privacy rights in 2018. Rights do not require proof of damage, only proof of violation. When we assess regulatory requirements, federal, sub-federal, and local, geography of where we operate demands consideration.

Having legal counsel involved in this process is crucial to success. We will need as inputs the list of critical digital assets from our first process and the vulnerability assessment from the second. Counsel should provide another key input: a list of the known government laws, policies, and regulations impacting us. We would expect either information security or IT—or better yet both—to provide another key input: a list of the private policies requiring our compliance as well.

The main activity for this process is to discover every government law or private practice that levies any requirement against any of our critical digital assets. Also include weighting factors for future use. Two factors that seem reasonable are measures of compliance complexity and cost.

A complexity rank, that rating how reasonable it is to comply with the law or practice, might be green-yellow-red where green is reasonably complex, yellow is more complex yet achievable, and red is overly burdensome. Cost of compliance could be a scale of one to five where one is inexpensive and five is financially burdensome, something like restaurant cost ratings.

A secondary activity, one derived from weighting factors, is to create a failure risk assessment for each law or practice. This can be on a green-yellow-red scale as well, perhaps green if we passed the last audit, yellow if we are overdue for an audit or passed with exceptions, or red if we failed the audit.

This process’s main output is documentation describing each law or regulation applying to our critical digital assets along with the weighting factors and risk assessment. A key reminder for this process is to merely measure risk and weights without prejudice. In our next post, we will describe a process for developing an information security strategy and prioritize its application on our critical digital assets.

What are your thoughts on assessing governance and regulatory compliance? Have you participated in such an assessment? Did you follow a formally documented process? If so, which one? Or did you use a more informal process like the one we described here? We’d love to hear from you in the comments below.


[1] Brandeis, L. and Warren, S., 1890. The right to privacy. Harvard law review, 4(5), pp.193-220.


Data security and encryption