Before we go, however, it behooves us to summarize our journey with some key takeaways. What were the most important lessons learned throughout the entire exercise? I’ve had the opportunity to ponder this for about a month now. Here are my thoughts:
Data Security Is A Team Sport: Data security is a cross-discipline endeavor. By adopting data protection as a central tenant of our IT security policy, we move away from a “it’s security’s problem, not mine” philosophy to one where security is a shared responsibility: the application, database, and networking teams work together. Each team executes on its own security responsibilities. No longer can a team blame someone else for security problems: all teams are part of the solution.
Data Security Is More Than IT: How many groups were involved in carrying out this practice? The accounting, legal, governance, security, and risk teams all had key roles in one or more of the six processes. More notably, the first four processes were not IT responsibilities: absolutely yes, IT contributed throughout. However these four processes produced documents to help with further planning. Implementation didn’t begin until the fifth process!
Data Security Reuses Existing Processes: One surprising thing is how many of these six processes actually “piggybacked” on an (or should be) existing process. Identifying critical digital assets, for example, reused accounting complying with the IRS requirements to valuate intangible assets. Our vulnerability and governance processes followed practices our organization already uses.
Technology Solutions Must Take Risk Into Account: During implementation, we selected a technology from the data protection stack based on our prioritized risk assessment. We noted the need to balance the simplicity of using solutions towards the bottom of the stack versus the risk of traversing the resulting security gaps. When sufficient risk warranted, we used more complex solutions higher in the stack to avoid said gaps.
Data Security Is Straight Forward: Building a data security practice is objective. We benefit from a “waterfall” model where the outputs from one process is fed forward as inputs into the subsequent process. This helps us capture maximum value from our work in applying a data security practice.
Avoiding Data Security Is Not Frugal: When we consider all of these factors together; data security is a team effort; it reuses existing processes and activities; it factors risk into the solution equation; and it is objective; we understand avoiding data security costs more than diving in. After all, if we leverage existing work in our practice, we receive more receiving value from those efforts.
As this is our last post in the data security practice series, we’d love to hear from you on any subject we’ve covered. What are your key takeaways from implementing data security? Is the likelihood of implementing data security in your organization less, about the same, or more based on what you’ve learned from this series? Please leave your thoughts in the comments below.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.