But how, exactly, are those people stewarding data? If you have a fuzzy definition of what a data steward is, or if the data steward job description or charter at your organization is basically nonexistent, there's a good chance that your stewards are left with no option but to make it up as they go along. Now, we don't think they need to move in lockstep: data steward responsibilities are broad, and each steward will be facing different challenges, and will have different resources available to handle those challenges. But it would be best, wouldn't it, if they had consistent directives that reflected actual data practices.
In our experience, as we noted previously, data stewards are most visible in organizations as people who decide who can have access to data, and how. For example, can a user log into the ERP and view customer data? Or, can users see customer data, but only in certain reports? Or can users only see aggregated data? Sometimes data stewards represent functional areas that have clear legal or industry standards about data security: finance, or health care patient records, or information about certain aspects of students, etc. Even in those cases, however, there's often room for interpretation about what constitutes least privilege access. More to the point, perhaps, is the unspoken question here: if person A can see data about entity B, so what? The concern is, what are they going to do with it? Will they share it with an unauthorized third party? What happens if they do that?
If the data in question is proprietary research, or a trade secret, or something similarly valuable, then the consequences for the organization could be severe. This strikes us as an even stronger argument for a rigorous system of classifying data into security categories, and managing access based on which categories a user needs to see, and under which circumstances.
Data stewards can identify data that ought to be protected, or to which access should be limited, and they can surely speak to potential consequences of a breach or careless sharing. But very little in their training has allowed them to determine what people in other departments should be able to see, or what purposes downstream users might have.
Let's think through a couple of scenarios.
First, as we know, data goes through a lifecycle of sorts, and there are going to be varying security regimes and considerations at different points in that cycle. A data steward's area might be responsible for acquiring data, but eventually its possession, maintenance, and potentially disposition might well end up somewhere else. Perhaps a patient comes in for a procedure, and data around that visit is controlled by medical records. After the procedure, billing might get involved, and so some information about the visit needs to be shared out. Further down the road, some kind of quality control research might be conducted, in which patient visits during a certain period are plotted against some other data points. And so on. What is reasonable to expect our patient records data steward to know? Presumably they'll know that an invoice gets sent to the patient or insurer. But they might never learn about other downstream uses of data unless data quality issues or other questions make their way back upstream.
Second, data can be combined from multiple domains, and what might be relatively innocuous in domains a and b might become problematic or even risky when made available together in data set c or report d. This might result in an inverted situation from above, where a data steward grants wide access to some data because it's not controversial, or it's basically anonymous, and then somewhat later on it's discovered that embarrassing or sensitive or otherwise inappropriate data has been made available in some fashion.
There may be times when stewards must act as gatekeepers, given the data elements, business needs, and technologies involved. Knowing the law, or industry regulations, or even just being the repository of institutional practice is certainly helpful here, but it's not sufficient. If you're the data steward for HR, you're well aware that much of the data your office maintains is confidential, or at least highly sensitive. Does that mean the CEO can have access to detailed personnel records? What about a hiring manager who's looking for a certain type of candidate based on what they think they've seen in other units? How deep should data stewards probe into these requests for access before determining whether to grant them?
We commonly hear from analysts, researchers, and data scientists that data stewards change their data collection and storage practices, and that those changes don't get communicated broadly enough. It's not until a report breaks, or a metric is wildly outside a norm, that the effects of these changes become visible. Much of the time, this discovery results in an investigation about what changes have been made, how data sets have been affected, and which data products or analytics outputs need to be altered to accommodate this change. An inconvenience, to be sure, and it takes time away from other work that could be done, but most of the time not catastrophic. But sometimes maybe this is a catastrophe.
Again, as with security and access decisions foisted on managers without a proper context, we don't see this as a failing of data stewards. When you're responsible for a given domain's data operations, you make decisions about data in order to make operations go as smoothly as possible. Do your data stewards have a job description that specifically mentions taking into consideration potential downstream effects of data decisions? Do they have a framework or process to share their planned changes and to collect feedback about the reverberations of those changes?
Too many organizations give data stewards tasks for which they're not suited, and around which they've likely received minimal training. Some of these same organizations find themselves in a pickle when data changes are not communicated, but for some reason they fail to set up a standard procedure that includes the right stakeholders and shares work and responsibility equitably. At the same time, organizations with a security-first approach to data stewardship fail to leverage the actual strengths and knowledge of their stewards, such as explaining how data came to be in the organization's possession, what data-related terminology means in a business context, how data quality standards are applied in a given area and how to recognize low-quality data, and so on.
Our data intelligence and governance solution, the Data Cookbook, has been organized since its release around making data stewards' knowledge more accessible, providing stewards with additional opportunities to collaborate, freeing stewards (and everyone) up to do more valuable work, and in general elevating the discourse around understanding, utilizing, and deriving benefit from organizational data.
We hope you found this blog post useful. Also check our our data governance spotlight resources (including one on data stewardship) located at https://www.datacookbook.com/spotlights. IData has a solution, the Data Cookbook, that can aid the employees and the organization in its data governance, data intelligence, data stewardship and data quality initiatives. IData also has experts that can assist with data governance, reporting, integration and other technology services on an as needed basis. Feel free to contact us and let us know how we can assist.
Image Credit: StockSnap_AKSM11WW9N_DataStewardsSucceed_GroupHelping_BP #1331