Implementing and Managing the Process

With the data access information compiled, profiled, and the results available, the gatekeeper should do some final validation checking and process testing before going live with the new process. Don't overlook the need to do sufficient data validation and testing with the functional area data stewards. They should be your first line of support where any local communications or data access issues need to be addressed. You certainly don't want these data stewards or the local managers and users to be surprised when new data access management processes and audits are implemented. Like any broad business process, a good validation and test plan is necessary. And because the user group mapping that has been compiled can also be nicely leveraged in other monitoring and quality management processes, you want to be sure this profile information is accurate and can become a familiar point of reference with the data stewards.

Testing and Launching the Process

The data validation process should essentially consist of reviewing the various data points and results from the profiling process. With a good cross section of managers and data stewards, explain and verify the type of data and results as shown in our examples in Tables 7.1 through 7.4. From this there may likely be some new insights gained and corrections needed with the underlying access requirements, profiling logic, or group mapping. Gaining the feedback and support from the managers and data stewards is critical to the execution, adoption, and effectiveness of this process.

Once the data has been validated and the user groups have sufficiently acknowledged the process expectations, you should conduct a few test runs to validate the actual execution and run time of the process. The frequency with which the underlying employee access data can be refreshed, the turn-around time for the data profiling tasks, and the ability for the gatekeeper to review and initiate actions will all play into the timing and repeatability of the process. Repeatability on a weekly or monthly cycle would be optimal to ensure that any changes in employee status, user group dynamics, or assignment of privileges are accounted for in a timely manner with the monitoring and audit steps. Inconsistency or too much latency with the underlying reference information can negatively impact the accuracy and effectiveness and diminish the stakeholder perception of the process. As a control process, it's important to maintain a regular pulse of monitoring and corrective action so that the user groups are continually aware of the process and its purpose.

Once testing has concluded, complete all necessary process and administrative documentation and begin communicating the process go-live date. Any general information about this process should be posted with other governance process information.

Resolve Issues Immediately

From the profiling and testing, you may have already noticed some privilege assignment or alignment issues, such as those illustrated in Table 7.4. If you haven't already corrected this, immediately begin resolving these issues with the appropriate data stewards or user groups. Whether lingering or newly identified, issues should be addressed as quickly as possible.

In a shared customer master environment, a user or group can, without realizing it, change data that can negatively impact another group or process. For example, multiple groups may have the ability to enter or update customer addresses. One of these addresses is likely to be considered the customer's primary address, billing or shipping address, or possibly all of these. These types of addresses should be highly controlled by a central customer data management team. If there are not sufficient rules, awareness, and constraints in place, it is very possible that other teams such as customer service, marketing, or sales, who also may have access privileges that allow changes or updates to the address, will cause problems for invoicing, shipping, or other account management functions that are not expecting the change. Unmanaged, these types of issues can reflect underlying risk and compliance issues that can turn into severe and costly problems further down the line.

Auditing and Monitoring

Key to the effectiveness of this gatekeeper process is the ability to regularly monitor and address the user access requests and changes in relation to current policies, rules, requirements, and access assumptions. Periodic audits are needed to continue to ensure that the user requirements, job expectations, user status, group names, and so on, are still valid, or that any lingering violation issues and expected actions have been formally addressed. Monitoring and auditing activities may also be necessary to meet SOX or ISO requirements.

A well-implemented gatekeeping process with the type of data and insights we have covered in this chapter can make the auditing process very straightforward and easy to manage, because much of what is audited is part of the ongoing monitoring and corrective actions on which the gatekeeper is already focused. In other words, with a robust gatekeeper process in place and good housekeeping already occurring on a regular basis, auditing can be a simple and well-aligned process without any major surprises for the gatekeeper or users.

We briefly mentioned already that the user group mapping, as shown in Table 7.2, can also be nicely leveraged in other monitoring and quality management processes involved in the customer data governance process. For example, a data quality monitor that is tracking customer name changes could also leverage this user group mapping to indicate what functional groups are performing customer name changes. This can enable the ability to easily check what authority and data access privileges the group has—such as a cross-check with the data shown as with Tables 7.1 and 7.4 —to determine if the name change activity is appropriate or not. Similarly, the data touch-point matrix we discussed in Chapter 4 (Table 4.1) could be augmented to also include the names of the groups who are responsible for entering or updating these specific master data attributes.

Expanding the use of this user group mapping will help increase the ability of the governance process to uniformly recognize who is interacting with the data along with how and where this interaction is occurring. Doing this is also a sign of a maturing governance model, something we will cover more in Chapter 9.

Segregation of Duty (SoD) Management

Complying with SOX rules and regulations requires users who have various types of authority with certain data, such as ability to access and create customer accounts, to be restricted from having similar authority with other types of data, such as contract or financial data. In an integrated environment with shared master data, segregation of duties must be very carefully managed and can involve fairly complex sets of rules and violation combinations that need to be clearly understood.

Violations can often stem from user groups or support functions that are engaged in cross-functional activity, or simply because more specific user access monitoring is now occurring. Similar to what we mentioned regarding the names used for access privileges, SoD definition and violation messages can be rather cryptic. In such cases, it may be necessary to map the unique violation messages to a simple code that will be much easier to utilize in the monitoring and reporting of the violations.

Table 7.5 shows an example of a simple codification approach for the SoD violation messages. Table 7.6 shows how this is used in a violation report that a gatekeeper can use to quickly zero in on the types of violations and where they are concentrated.

Table 7.5 Codification of Segregation of Duties (SoD) Violations.

Table 7.6 Segregation of Duties (SoD) Violation Report.

Again note how these examples use the common user group name to maintain consistency and alignment with the other user access report examples we have previously shown. Doing this enables the ability to consistently evaluate how these groups are doing across all the monitoring and reports involved in this data access management process.