Data Stewards as Risk Managers and Champions of Information Security

In early 2007, as the information security officer at a health insurance company, I began to consider how to build better connections between information security goals and business goals. I had observed for some time that the closest that the business units generally got to the question of data security was, "Who has access to this application or screen or function within an application?" Most concerns were about data confidentiality, and using screen-level access reviews was a convoluted and confusing proxy for directly addressing access to and uses of data.

During this same time period I developed a few notions. First, that process controls serve primarily integrity-oriented goals that are important for narrowing activities, such as for financial audits culminating in a single audited financial statement. Data controls inherently serve confidentiality-oriented goals that prevent the uncontrolled spread of data, such as preventing information leaks about mergers and acquisitions in the pre-merger period. Data controls would be a poor, work-intensive way to determine if the financial statement was accurate. Process controls don’t really apply when a board member accidentally sends merger due-diligence emails to the mailing list for a different board. Keeping in mind that most applications at the time were designed with process controls in mind ("Can this person initiate or approve certain transactions?”), we didn’t have the right approach for the concern. The question of data security got lost in process control thinking - but because so many were “brought up” on process controls, the disconnect wasn’t obvious.

Many organizations experience (i.e. they design) one or more of the following situations:

1. Supervisors are responsible for getting work done, and are simultaneously responsible for defining and authorizing access for their employees. If production is the primary goal and incentive for the supervisor, it would be safer for the supervisor to avoid providing too little access, rather than avoid providing too much access. This situation creates a perverse incentive.

2. People in key business roles may have a general sense that they have a leading organizational role in regards to certain types of data. However, that may only go as far as involvement in a big data initiative, or other large but targeted projects. What is commonly missed is the general accountability, including for data security and risk management. Even if the security role is explicit, there is often little clarity as to how applications, requests for access, business processes, data exchanges, and system configurations affect the accessibility, security and use of the data. This is what I’d call opaque.

3. IT is expected to protect data, even under an access authorization process which places supervisors in a role of authority. IT is expected to intuitively know when to push back on a request. It is also too often the case in projects where security design considerations of technical solution components happen too far downstream, and IT is left “accepting” the risk or seemingly a roadblock. A good word for IT's situation in these examples is untenable.

4. Level-only classification systems (i.e. those of the sort that use only classifications such as Secret, Confidential, Internal Use Only, Public) fail to establish accountability-aligned ways to classify and declassify, and provide no clear path to making either consistent policy decisions or making nuanced decisions about data. Different people make different decisions about the same data, due in part to individual risk temperaments, a variety of personal experiences, profession-driven leanings, and role-specific incentives. This is a broken model.

A Starting Principle

"The person who benefits from accepting a risk on behalf of the organization should also be individually accountable for the consequences."

The importance of the prior statement seems almost too obvious but many organizations fail to consistently make a connection between risk-taking benefits and risk-taking consequence management. Larger organizations, often by design, create separate processes for accepting risk versus managing risk. Those two intricately tied decisions often happen at different times and in different venues and contexts. This is less than ideal.

An Accountability Model

I developed a model in response to the organizational challenges mentioned above, building on my initial notions, and using the principle of aligned accountability. I will explain a few of the key roles and then how they work together.

Data stewards are responsible for establishing organization-wide policies for a specific type of data. They are also responsible for considering policy exceptions and making ad-hoc decisions when policy is unclear or a situation requires analysis. Depending on size and industry, an organization can have anywhere from a few to 30 data stewards. Generally the data steward is a leader who is close to the organization’s data intake point (e.g. members/customer operations, business partner relations), or resides over the production of the data (e.g. finance, strategy). Among the classically recognizable data stewards are the head of HR (employee demographic and performance information), the head of payroll (salary, benefit, and garnishment information), the CFO (financial performance prior to reporting), and the head of research and development.

Data gatekeepers are aligned to external stakeholders, may handle a variety of data, and are responsible for following and enforcing the data access and use rules created by the data stewards. Generally, every type of audience or external recipient of data has a related data gatekeeping function. Long-established examples include the Legal department acting as the gatekeeper to law enforcement and the courts; Compliance acting as the gatekeeper to regulatory bodies; and Corporate Communication acting as gatekeepers to the media and the general public. It is a familiar approach, but usually only rigorously applied in specific contexts. It is quite possible, and also useful, to extend the concept to other areas. Almost every function with external touch-points acts in some capacity as a gatekeeper, but in many organizations they are not able to perform that function effectively because of unclear responsibilities and a lack of guidance.

Application sponsors are, as the name implies, those who request, convince the organization to pay for, and provide ongoing demand for a technical capability that supports a business need. Essentially, their business needs are what drive application and system implementations. In their roles, they are accountable to the data stewards for developing requirements that support data policies, and deploying configurations that enforce those policies. They are also accountable to process owners for things such as uptime and process controls such as segregation of duties.

Process owners are responsible for end-to-end processes. General examples include order to ship and procure to pay. Industry-specific examples exist as well, such as admit to discharge and enroll to dis-enroll in healthcare. Process owners establish business requirements for up-time, integrity of transactions, integrity of reporting, authorization of specific transactions, and segregation of duties.

Data custodians are those that hold data on the behalf of the stewards, but have no policy-level say over the direct management of the data. The prime internal example of a custodian is the Information Technology department for electronic data and facilities for paper record storage. A more subtle example is Finance acting as a custodian for payroll data on behalf of HR. Externally, Cloud service providers are custodians.

Each of the roles represent unique business goals, and it is expected that they also have different perspectives and intrinsic motivations related to certain types of decisions. These responsibilities are designed so that a fundamental tension exists between the data stewards, process owners, and system sponsors. Note that all three are business roles. Also note that Compliance, IT, and Legal have been removed from the middle of the decision making process.

Benefits of the Model

In short, the primary benefit is that the business units can focus on risk decisions in a more business oriented context. The discussion is no longer focused on security, control gaps, or regulatory issues as a proxy for business concerns; it is actually about those business concerns. This makes decision making more straightforward, better designed for long term planning, and more responsive to changing business and operating realities.

Contrast this model against how risk decisions often happen... indirectly and inefficiently mediated through specialized IT, Audit, or Compliance contexts.

Which would you choose?