Having the pre-considered controls and processes in place for your information is more and more important every day. While I’m no fan of the 999 page specification, I am in favor of having spent the mental time on things prior to needing them. This is true of disaster recovery, it’s true of management of systems.
Data governance is just a fance name for how you’ll manage data in your organization. Having a plan in place for what is OK, what isn’t, can save you time and effort and can make an audit of your compliance structure more straightforward to understand.
By no means are the following all inclusive, but here are some ideas and mileposts that may help get you there.
What Information is allowed/tracked?
This is a big heading for an incredibly broad track of functionality. You don’t necessarily need to have every data dictionary called out, and every column and view, but you do want to have a good level of detail showing what types of things you’re supporting.
This isn’t necessarily a “not in my backyard” type of document, where you’re saying it’s not your job to track x, y, or z, but it’ll give you planning points and hopefully budget and resource allocations to do the job of managing the information you’re expected to manage. I’ve seen these be as simple as defining the systems that are supported (purchasing, payroll, office systems, etc.) or as detailed as going into specific functional pieces that are supported.
I’ve always felt like the more specific this is (like getting down to column-level, data-element style specifications) the more unruly and out of hand it’s getting. There’s a happy medium somewhere between
“We track all the data for the company”
and
“We track firstname, lastname, social security number for our customers in Globe, Arizona.”
Too specific and it’s out of date instantly as someone adds a related item. Too broad and it’s not a good definition of expectations. Clear as mud, I know. But you want to have a good understanding of the objectives of your data management.
How will that information be stored and accessed?
This requirement has evolved to the point where you have to count on access from third party applications, from outside tools, from query tools, reporting, etc. When you think about access, to save your sanity, start with the input, who can do it, how it’ll likely be done (again, too specific is painful, “our web site applications” is probably a good start), and whether they need training and authorization for access.
Move to storage, talk about access controls, key management, whether you give global access or masked data output or… What is your anticipation for data use? What about stroage outside the purvue of the database systems?
Some of this is just thinking things through and providing guidance – some is where you need to flex muscles a bit to help provide some controls.
What types of permissions, security and controls are going to be used?
This item will help you establish where security and permissions originate (Managers? IT? HR?) and what types of security are provided for and enforced. Think about access controls not only from a user ID standpoint, but also from the view of third party applications, mobile devices, etc. All of the things that will need the information you’re managing.
Ongoing data management
I think many people forget to include ongoing management of systems in the data governance plan. This includes archived access, backup management, response time expectations for both active and archived information, deletion and archive expectations.
In each of these, you may find specifics for applications vary from the norm. That’s ok too. The thought process and planning that goes into this can make executing on managing things much more clear.
Do you have a governance plan? How do you approach a broader-basis scope on the work you do and are expected to do?