Establish A Business Context
Often overlooked, this is a vital beginning step to assure business relevance and promote meaningful dialogue with company leadership. Examine the business basics of your company, specifically who you are and what you do. Answering the following types of questions can help you document those business basics:

• What are your core products and services?
• What are your key strategic objectives (i.e., capital accumulation, liquidity, reputational excellence, service leadership, etc.)?
• How does leadership and other stakeholders measure value (i.e., revenue, earnings, stock appreciation, sales volume leadership, brand recognition, to name a few)?
• How is this value created?
• What places strategic objectives, operating performance, and resulting value at risk?
• What is the scope of your risk program (enterprise, organizational unit, business segment, other)?

Once you’ve done this evaluation, examine the content. Pay particular attention to the terminology and language that works best to communicate these answers clearly. Take some time to vet your responses with others to assure they are clear, concise, and accurately reflect your company and its business. These should be terms you continually reference when describing, reporting, and discussing risk in all your communications. Words matter. Everyone needs to be on the same page with regard to risk.

Define Risk
There is art and craft to effectively doing this. If defined at too granular a level of specificity, it become unmanageable; and conversely, if done too broadly, the definition evaporates into meaningless messaging. This is where your business context becomes a helpful tool. One solid definition could be the “effect of uncertainty on the achievement of objectives.” You may also find it useful to look at each core objective and ask, “what events or situations might hinder or thwart the achievement of this objective?” You may think of other questions to help you explore risks. For instance, consider value chains. These are situations where one operational event or outcome may lead to a series of others that result in a negative impact upon a seemingly unrelated area. An example would be:

Scheduled maintenance updates to patch a group of data servers fall behind plan, leading to a short term outage in scheduling software and requiring manual operation. This, in turn, results in delayed and missed product deliveries contributing to a decline in product revenue for the period.

Generally, server maintenance isn’t viewed as an item that is clearly linked to revenue. But such linkage can occur and the circumstance cited is actually a reflection of one company’s past experience. Having stakeholders with a deep knowledge of your operations and their process integration can help reveal some of these risk situations. Understanding and identifying such relationships in value chains can also assist in the development of mitigation plans to help address either likelihood and/or severity (in this case, by completing patch updates to servers). In some disciplines, this kind of thinking is referred to as “systems thinking”.

Expressing risks in terms of their impact upon operational achievement of objectives is a way of establishing clear relevance to senior leadership, those individuals who are responsible for allocating resources to your program to help mitigate and manage identified risks, and sponsor remediation efforts to manage them. They are the key decision-makers who establish budgets and allocate resources.

Once you’ve built your preliminary set of risks to objectives, you will then be in a position to enlist operational stakeholders as actual risk owners, individuals who are subject matter experts (SMEs) and who can add detail and specificity with respect to core disciplines. These should include, but not specifically be limited to, IT, Finance, Audit, Operations, Product Development, Support Services, Procurement, Third Party Management, Regulatory Compliance, and Facilities. Their input, aligned to your business practices and culture, will form the basics of your Risk Register. A crucial part of the risk survey process will be to ask what’s actually in place now to mitigate these risks. Keep those answers for consideration of controls, which you may map against regulatory or contractual obligations.

Process – Integrate The Register From the Bottom Upward
Make no mistake – your risk register is the foundational pillar for establishing an Enterprise Risk Management (ERM) program. It needs to be installed, embedded and thoroughly integrated throughout an organization in order to:

• Assure the active management of risks as a process
• Set priorities and actionable resource allocation to address risk
• Uncover and oversee the mitigation of the universe of risks
• Expose any hidden, value-adding opportunities
• Demonstrate itself as a usable, independent but integral regimen (not as a stand-alone, ivory-tower hypothesis), in order to maximize its contribution to the company’s mission

Very simply, consistent with the establishment of the risk register, the mission statement for an ERM program can be stated as

“…the process to identify, assess, mitigate and monitor all enterprise-wide risks that might impair the company’s ability to achieve its strategic business objectives.”
We’ve talked about the functions, processes and features of an ERM solution in many of our other blogs. A vital point: your ERM solution should clearly be understood as stand-alone and not a mere adjunct to other corporate functions, like compliance or internal audit. It is a discipline of its own and needs to be strategically designed and tactically executed, on an iterative (day-in-and-day-out) basis, using a risk register vehicle that is:

Going one step further, this Risk Register is not just a “nice to have” choice but rather a corporate initiative that is:

• Urgent – tomorrow is not soon enough
• Mandatory – avoids potential catastrophe and/or dereliction of duty
• Foundational – risk register “buckets” (causes, consequences, controls and key risk indicators) and metrics (severity, likelihood, and velocity) inform the components of ERM actionability – identification, assessment, mitigation and monitoring
• Collaborative – content provides operating managers and staff with a consistent framework and language to structure risk related actions and report accomplishments, issues, and recommendations.
• Connected – to the success of strategic objectives
• Value-oriented – satisfying myriad needs across a wide spectrum of stakeholders, such as:

Content – Applying Controls and Frameworks

Examining the all the attributes of the risks you’ve identified in your register allows you to accomplish two important tasks. First, you can readily see the reliance on, or the impact of, mitigation, for each risk. The sum total of mitigation serves to reduce inherent likelihood and severity to its current residual level. Secondly, you can use a framework to see if there are any significant gaps in your register you might want to address.

Process and Product – Enter The Risk Assessment
If there is only one activity to be used most often to define the core of ERM, the one aspect that is most readily identifiable and recognized, it’s the risk assessment! This is the action step that drives mitigation and helps prioritize monitoring. This is where your risk “health” is determined. If your risk register is a thermometer, this is where you take your company’s temperature. The register can critically evaluate which of the risks in your universe are appropriately addressed and where additional mitigation is most urgently needed. The findings of the assessment define your current state in the context of your business’ needs and goals, and drive your program’s response. The features of the tools you use to do this, through your GRC platform or whatever else you might use, are all focused upon a review of the content of the register, a determination of risk to your business by designated risk owners, with stated accountability. The information needs to be intentionally focused on a select few attributes (likelihood, severity, direction and velocity) and metrics need to be straightforward and clearly understood. Very importantly, you also need reporting tools to organize, analyze, and present the data into meaningful messages.

Product – Reporting
You’ve built your register, supplemented content, assessed your risk, and now you need to share what you’ve learned with decision makers and stakeholders. If you are working with a GRC tool where reporting is embedded within, where standard reporting, such as the generation of heat maps, counts and lists of most critical risks and such is generated right from your assessment data, that’s a strong beginning. If not, you want to generate visual and narrative statements of findings that answer some basic questions:

• What are our most significant risks?
• Which are most likely to have significant events occur?
• Where are they located?
• How are they prioritized, using enterprise-wide rating scales
• What is the current residual state (after controls) for each risk?
• What will it take, in terms of additional resources, to further mitigate them?

There are countless, additional questions that can be asked, based on the fulsome risk surveys received from subject matter experts. These further inquiries are healthy and will drive further conversation. Visualization is important to helping non-technical executives understand your assessment findings in business terms. It’s exactly why you built your register in the context of the business’ goals and mission. Further, you need a means of securing, publishing, and distributing this important information to key stakeholders, within control, in a secure manner. Risk assessment findings reports often contain highly confidential information, and you need the capability to manage publication and distribution carefully. Your Board of Directors, as well as your Executive Committee, are accountable for addressing and managing risk to their shareholders, regulators, customers, and other stakeholders. ERM is the discipline, and the risk register is the most valuable tool, that provides all of these varied stakeholders with the information and guidance to make quality decisions to manage and mitigate risk effectively

Product—Process—Content: The DoubleCheck Standard
While this, and many other blogs here, offer guidance on many risk management issues, they all point towards the benefit of utilizing a quality GRC tool to support execution. DoubleCheck understands that these three attributes of a GRC (Process, Product, and Content) are essential to delivering the critical services, tools, and capabilities companies require to tactically execute upon the four elements of day-to-day risk management (Identify, Assess, Mitigate, and Monitor) with efficiency and effectiveness. Further, services and features are highly integrated into one package. Reporting is embedded to rather than independently aligned to content and processes, making the risk management practice a seamless effort rather than a disjointed one. Whether out-of-the-box core functionality, or serving as a streamlined front-end to a larger enterprise (ERP) offering, or to an expansive, dedicated, tailored through configuration, custom fit to your company’s needs, DoubleCheck offers product, processes, and content designed to support all your enterprise risk management needs.

The next blog will expand upon the various use cases that can greatly benefit from a pre-populated, fully integrated ERM solution.

About the Author:
Simon Goldstein is an accomplished senior executive blending both technology and business expertise to formulate, impact, and achieve corporate strategies. A retired senior manager of Accenture’s IT Security and Risk Management practice, he has achieved results through the creation of customer value, business growth, and collaboration. An experienced change agent with primary experience in financial, technology, and retail industries, he’s led efforts to achieve ISO2700x certification and HIPAA compliance, as well as held credentials of CRISC, CISM, CISA.

The post Building A Risk Management Program—The Risk Register first appeared on DoubleCheck Software.

No company is an island. Organizations are a complex and diverse network of business relationships in which risk and compliance challenges do not stop at traditional organizational boundaries. Organizations struggle to identify, manage, and govern business relationships. The challenge is: “Can you attest that risk and compliance are managed across extended business relationships?” An organization can face reputation and economic disaster by establishing or maintaining the wrong business relationships, or by allowing good business relationships to sour because of weak oversight. This is true across industries, but some, like financial services, are seeing greater regulatory oversight of third party/vendor risks (e.g., US OCC).

Across industries, organizations are facing global regulatory pressure in 3rd party oversight and due diligence in the context of anti-bribery and corruption (e.g., US FCPA, UK Bribery Act, OECD Principles) and conflict minerals (e.g., Dodd Frank Act, Europe’s Conflict Mineral Regulation). Major brands have focused efforts on social accountability in the context of international labor standards (e.g., child labor, forced labor, working hours, health and safety). There is significant pressure in 3rd party management in the context of PCI DSS and protection of credit card data. The Target breach is a case in point in which an air-conditioning vendor was the doorway into the largest credit card breach of a POS system to date.

Third party relationships are critical to business today but introduce a significant exposure to risk. Organizations fail when they look at the formation of a business relationship and do not foresee that issues cascade and cause severe damage to reputation, and exposure to legal and operational risk throughout the ongoing relationship. They make two common mistakes:

• Risk is only considered during the on-boarding process. Risks in extended business relationships are often only analyzed during the on-boarding process to validate the organization is doing business with the right companies. This approach fails to recognize that additional risk is incurred over the life of the business relationship.
• Partner performance evaluations neglect risk. Metrics and measurements often fail to fully analyze and monitor risk. Often, metrics are focused on vendor delivery of products and services but do not include monitoring risks such as compliance and ethical considerations.

Risk and compliance issues and corresponding processes constantly bear down on these relationships. Business processes and corresponding technologies that operate autonomously introduce further risk, as there is no view into the range of risk issues that a single business relationship brings to the organization.

Organizations need an integrated approach to third-party risk and compliance management that brings together people, process, and technology to deliver not only efficiency and effectiveness but also agility. Ignoring an integrated view of extended business relationships can result in business relationships that behave like leaves blowing in the wind, with no one monitoring the ever-changing risks in a dynamic business environment.

The building blocks of an effective, efficient, and agile third-party risk management program are:

1. Define Your Program. The first step is to define the third-party management program. While an individual needs to lead the program, it also necessitates that different parts of the organization work with this role. Defining your program includes understanding board oversight and reporting for third-party risk and compliance, and a cross functional team to ensure that the operational, reputational, and compliance risks in business relationships are appropriately addressed. This team needs to work with the relationship owners to ensure a collaborative and efficient oversight process is in place.
2. Establish Framework. The third-party management framework is used to manage and monitor the ever-changing relationship, risk, and regulatory environments in extended business relationships. The framework starts with developing a list of third-party relationships cross-referenced to risks and regulations affecting those relationships. A framework is an organized set of controls used to measure compliance against multiple risks, regulations, standards, and best practices.
3. Onboarding. Evaluation of risk and compliance needs to be integrated with the process of procurement and vendor/supplier/partner relations. A business relationship is to be evaluated against defined criteria to determine if the relationship should be established or avoided. When there is a high degree of inherent risk, but the relationship still is necessary, manage the risk within tolerance level by establishing compensating controls and monitoring requirements.
4. Ongoing Monitoring. A variety of environmental and geo-political factors can affect the success or failure of any given business relationship. This includes the potential for natural disasters, disruptions, commodity availability and pricing, industry developments, and geopolitical risks. The potential risks relevant to each business partner should be taken into consideration to monitor the health and success of business relationships on an individual and aggregate level. This also involves monitoring relevant legal and regulatory environments in corresponding jurisdictions to identify changes that could impact the business and its extended relationships.
5. Resolve Issues. Even the most successful business relationships encounter issues. These may arise from quality, health and safety, regulatory, environmental, business continuity, economic, fraud, or legal and regulatory mishaps. The fallout from incidents is exacerbated when everyone scrambles because nobody developed defined action and resolution plans ahead of time. Management of risk across extended business relationships should account for issues and plan for containment, mitigation, and resolution.

The challenge is that many organizations try to manage all of this with spreadsheets, documents and email. These approaches are prone to failure as they bury the organization in mountains of data that is difficult to maintain, aggregate, and report on, consuming valuable resources. The organization ends up spending more time in data management and reconciling as opposed to active risk monitoring of ex¬tended business relationships.

Bottom Line: Third-party risk management is enabled at an enterprise level through implementation of an integrated third-party risk management platform. This offers the adaptability needed as a result of the dynamic nature and geographic dispersion of the modern enterprise. The right third-party risk management platform enables the organization to effectively manage risk across extended business relationships and facilitate the ability to document, communicate, report, and monitor the range of assessments, documents, tasks, responsibilities, and action plans.

Third-party risk management is enabled at an enterprise level through implementation of an integrated third-party risk management platform.

Effectively managing and monitoring risk across third party relationships requires a centralized platform to document, communicate, report, and monitor the range of assessments, documents, tasks, responsibilities, and action plans. The ideal platform engages extended business partners and employees as well as internal staff. Ideally, these systems provide capabilities that help the organization:

• Ensure ownership and accountability are clearly established and understood
• Manage the on-boarding and the ongoing risk and compliance scoring and assessment processes
• Conduct initial and ongoing assessments
• Actively monitor all business partners for adherence to code-of-conduct and related policies
• Make changes in risk profiles based on targeted risk assessments
• Leverage built-in question sets to streamline surveys and questionnaires
• Initiate and manage incident follow-ups and investigations
• Use verifiable evidence to readily attest to “in compliance” status

The post The Building Blocks Of An Effective, Efficient & Agile Third-party Risk Management Program first appeared on DoubleCheck Software.

Having completed a full controls test management solution implementation from inception to user rollout in approximately 30 weeks, KBR reports an overall high level of satisfaction. This assessment is derived from reports with respect to a number of outcomes related to implementation processes and objectives, including:

• Timing: KBR completed its SOX compliance solution deployment and hit a go-live date that was delayed only one week from the target date. Given the aggressive timeline and lack of substantive impact on supported business operations, KBR considered the delay to be well within the margin of success.
• User Adoption and Acceptance: KBR reports 100% adoption at go-live, as use of the solution became required to perform controls test and review tasks. However, business users reported high satisfaction with the new SOX compliance solution and reported no major issues, bugs, or errors that interfered with their ability to use the tool. In a few rare cases, users indicated a reluctance to adopt the new process. These were addressed by Financial Controls via one-on-one walkthroughs.
• Business User Impact: Business satisfaction reported ranges from “Excellent” to “Extremely High”. KBR received no negative comments about system functionality or usability. Users reported increased ease of use and reduced errors or confusion resulting from the increased usability and clarity provided by the DoubleCheck platform compared to the prior, dual-system model. KBR indicated that this resulted in improved efficiency and time savings in data entry compared to the prior solution.
• SOX Controls Assessment Administration and Management Impact: KBR reported satisfaction with the DoubleCheck system’s impact on SOX controls assessment as “very high”. The organization identified some minor change in the effort required to make system changes and maintain cleanliness of data in the new system versus the legacy system. KBR reports that this change is a consequence of added complexity resulting from the flexibility of the new system and the addition of features such as the automated workflow, increase in data properties captured, and enhanced reporting capabilities. However, the organization finds that the impact is minimal, and “well worth” the added capabilities of the system.
• Report Creation and Consumption: Satisfaction with the DoubleCheck platform’s reporting capabilities is “very high”. KBR reports that significantly more information can be retrieved by users, with greater flexibility and accuracy, than previously. Report creation is faster, easier to use, and pulls from a wider range of data than previously available. KBR reports that this has almost eliminated manual report creation activities. The system now runs certain reports automatically every weekend with no manual involvement by the Financial Controls Group and distributes them to designated users. Report production frequency and self-service access have also increased, as more ad hoc reports are being created, analyzed, and used for status reporting. Finally, the organization reports increased use of data visualization aids, such as scorecards and dashboards to support executive consumption.

“User satisfaction is extremely high. Users were elated with the new application because the prior solution was very inefficient and cumbersome to use. It required duplicate entry into two systems, and neither system had all the data that a user needed to see at one time. Almost all reports were manual prior to DoubleCheck, as well, and those that were not were very limited, partly because the data captured in the system was limited. We are able to report much more information from the new system.”

Patricia Pavlick
Project Manager, Financial Controls, KBR

As noted above, the 7.5-month implementation cycle reported by KBR ranks well within the Best-Case implementation scenarios benchmarked in Blue Hill Research’s July 2015 Benchmark Report Contributors to GRC Implementation Success: Avoiding Worst-Case Scenarios (Table 5).

In terms of technical deployment alone, KBR accomplished its core operations within fourteen weeks, with only one week of delay beyond its planned go-live date. This closely matches the experiences of Best-Case implementation scenarios, where technical deployment time falls between three and four months. By contrast, Worst-Case implementation scenarios benchmarked by Blue Hill Research involved technical deployment times that fell between 11 and 16 months in length, which well exceed the total implementation cycle reported by KBR. In addition, the levels of user satisfaction reported by KBR match or exceed those reported in Best-Case scenarios.

Blue Hill Analysis: Implementation Best Practices Demonstrated

KBR’s ability to achieve an implementation within a time cycle and at levels of organizational satisfaction that match the Best-Case Scenario benchmarked by Blue Hill resulted from a number of aspects of the organization’s approach. These aspects include, among others:

• The level of detail and connection to business and operational needs employed in requirements planning
• The use of requirements to guide all subsequent stages of the investment and implementation process
• A rigorous approach to project management throughout deployment
• Selection of an offering whose architectural characteristics supported implementation goals and a vendor that prioritized the same goals

Many of the practices demonstrated by KBR echo practices employed in Best-Case implementations identified in Blue Hill Research’s July 2015 Benchmark Report Contributors to GRC Implementation Success: Avoiding Worst-Case Scenarios.

Practices identified in this report include:

• An implementation scope focused on support for established business operations, rather than using the software investment as an agent of process change
• Primary responsibility for the implementation rests with the functional line of business owner
• IT stakeholders are involved at early stages of solution, evaluation and investment planning
• A preference for configurable applications driven by attention to both present and anticipated change to application needs

Blue Hill’s assessment of KBR’s strategic decisions, methodology, and outcomes reveal additional contributing factors that resulted in the success of its implementation. Table 6 summarizes these contributing factors as they related to organizational components, strategic planning considerations, operational excellence, and technical aspects of the DoubleCheck solution itself.

Based on its analysis of these factors, Blue Hill has identified six best practices in the organization’s implementation that directly contributed to the results realized, which are summarized in the following sections.

Define Precise And Complete Business Requirements

Arguably the most important step taken by KBR was the creation of detailed, specific, and written business requirements.

At every stage of the implementation process, the 75 business requirements defined by the vendor played a role in narrowing attention to the underlying operational needs driving the investment. As such, these requirements became KBR’s primary tool for solution selection as well as implementation planning. In the former, the organization’s requirements document helped to define its RFP questionnaire as well as its demo script and evaluation framework. In defining the solution itself, the requirements document influenced the shape of KBR’s configuration specifications as well as its UAT test plans. The requirements document even assisted in KBR’s efforts at user role definition, workflow design, and data property models, all factors that are often left to deployment stages and can substantially slow the implementation. While KBR did not have these elements of the solution complete prior to implementation, the early identification of requirements and processes provided an established framework that anticipated much of the effort involved in this later stage.

At each stage, KBR was able to take advantage of prior efforts to identify both the functionality it needed as well as the non-functional architectural and delivery methods that would permit it to effectively achieve its goals. Its ability to quickly work through vendor selection and to adhere to an ambitious deployment cycle also rolled out, directly and indirectly, from the adherence to clear and unchanging requirements.

From this standpoint, it is important to recognize that the technology investment was not a transformation vehicle. Rather, KBR had already analyzed its SOX controls test and review processes and made the strategic changes it identified. The technology layer was implemented solely as an enabler to those changes. This approach is consistent to the implementation planning practices highlighted among Best-Case implementations in Blue Hill’s Contributors to GRC Implementation Success: Avoiding Worst-Case Scenarios Benchmark Report.

Companies planning similar investments will benefit from modeling their own approaches on KBR’s requirements planning process. The organization dedicated significant time to this aspect of the implementation (approximately one month), prior to any major review of software options. Special note should be taken of KBR’s “no surprises” approach, which attempted to identify factors that would impact the success of the implementation. The impact of this step on subsequent activities cannot be overemphasized.

“If your requirements are really precise, the rest flows from there. You’ll have a roadmap that you will use all the way through the implementation. I recommend creating detailed, specific written business requirements that identify all the data elements you want to capture and the values you need for each. Everything else starts from there. You’ll have your roadmap for everything from system selection to design to acceptance testing.”

Patricia Pavlick
Project Manager, Financial Controls
KBR

Locate Primary Implementation Responsibility With The Business Operation Owner And Seek Guidance From Other Stakeholders Early

A recurring theme throughout KBR’s implementation was the identification of the Financial Controls Group as the primary owner of the program. The Financial Controls Group possesses the authority and responsibility for SOX controls assessment and thus represents the natural owner for determining the solution requirements that would best support those operations.

Often, a functional line of business owner will be only one member of a committee responsible for an implementation. In other scenarios observed by Blue Hill, other stakeholders are brought in last minute when approvals are needed, rather than at times when they have the ability to influence planning or strategy. For example, consider situations where line of business stakeholders identify a desired solution and then attempt to “farm it out” to IT or other departments that may understand the organization’s technological ecosystem but lack deep insight into the business processes to be supported.

By contrast, KBR primarily located implementation decision making and execution with a single team: Financial Controls. The Financial Controls Group held primary responsibility for a wide array of activities, including business requirements definition, solution evaluation, project management, user acceptance management, training, rollout strategy, and other activities. Where other stakeholders were involved, it was most often to provide guidance on the decision, rather than to take responsibility for elements of decision making or execution of implementation activities. It should be noted that involvement of outside stakeholders, be it business users, KBR’s Chief Financial Officer, or IT, occurred early in the process to set constraints or guidelines, such as budget or technical requirements. This approach effectively served to empower the Financial Controls Group to act within boundaries that served the larger organizational needs, while preserving its ability to identify a solution that would best fit its business operations.

As noted above, Blue Hill Research identified this “early advisory” approach as a key practice in Best-Case implementations in the Contributors to GRC Implementation Success: Avoiding Worst-Case Scenarios Benchmark Report. However, for a variety of reasons, the exact approach employed may not fit all organizations. Organizational boundaries or procurement policies may require the use of a different process. Alternatively, aspects of the solution or process change considered may insert limitations. For example, if the organization does not opt for a vendor-hosted offering, considerably more involvement from IT will be required. Whatever the options available, however, early solicitation of guidance and alignment of requirements to organizational constraints will play a key role in effective scoping of the implementation.

“We were trying to plan a new system for our users. It was important for us to have a simplified, user-friendly approach to the system interface and our workflows. We have hundreds of users and frequent changes in those user roles. The system needed to be intuitive and capable of being picked up by a new user quickly and without extensive training. Both early in the process and toward its end, we involved key business users to understand their needs. That went a long way to getting us to the right place.”

Steve Vontur
Director of SEC Reporting and Financial Controls, KBR

Secure Executive-Level Support And Championship For The Project

In addition to obtaining guidance from key stakeholders in early stages of its investment and implementation planning, KBR also secured executive-level support from the CAO. In part, support of the CAO, along with the CFO, represented a gating requirement for the initial investment approval. However, the involvement of the CAO in this implementation went deeper. The CAO worked at early stages of the process to help align and gain support for the investment business case. Throughout the process, the CAO also helped to support the implementation by helping to identify strategic needs and prioritization as well as provide feedback on data elements and workflow components to be addressed by the DoubleCheck controls management platform.

The involvement of an executive champion is a frequent component of a successful implementation of a major enterprise technology investment. The role taken by the CAO here provides a prime example of the impact that executive stewardship provides, by securing support and buy-in from other organizational stakeholders and helping to define the importance of the investment to the business. Continuing involvement also helps to maintain focus on the implementation effort.

This is particularly important where an implementation is led by a business operation owner, as momentum for the implementation effort is often at risk of taking a backseat to the owner’s primary responsibilities. Involvement of the executive champion thus often assists in ensuring that implementation activities are accomplished “to spec” and on schedule.

Identify The Solution And Vendor Delivery Options That Align To Your Priorities

Several contributors to KBR’s success resulted from characteristics of the solution and deployment model that they selected. Similarly, the ability to successfully operate to a tight implementation schedule was a result of the selection of a vendor that was able to align on project goals and to collaborate to meet them.

The DoubleCheck GRC platform selected by KBR is vendor-hosted and rests on a highly configurable application architecture. These factors alone removed two major time investments of an implementation: the application environment provisioning and the customization of the application. Blue Hill Research’s August 2015 Solution Landscape GRC Vendor Implementation Success Strategies identified these factors as key vendor contributors to implementation success (see sidebar). Similarly, the selection of a vendor that provided a flat fee for implementation services and demonstrated a willingness to embrace KBR’s requirements and implementation plan helped to ensure that the implementation could be executed to plan without scope creep or unexpected delays.

Vendor Contributions to Implementation Success

Blue Hill Research’s August 2015 Solution Landscape GRC Vendor Implementation Success Strategies identified vendor and solution capabilities that correlated to Best-Case implementations, including:

• Rapid Deployment Programs
• Application Configurability
• Availability of Out-of-the-box Functionality
• Software as a Service (SaaS) or hosted delivery models
• Subscription-based pricing

Blue Hill’s prior research has identified how these sorts of factors represent vendor supplied contributors to effective implementation. However, these characteristics are not ultimate guarantors of success in and of themselves. Solution attributes such as configurability or hosted deployment are factors to assess and trade off against other benefits and drawbacks of a solution. As such, KBR’s selection of these capabilities does not represent a best practice.

Rather, the best practice to be emulated is the organization’s attention to aligning solution architecture and delivery considerations to business and operational needs in planning the implementation. This has been mentioned above with reference to requirements definition. It bears repeating in the context of solution selection.

KBR identified its business requirements, operational preferences, and a go-live target intended to permit use of the platform to support its 2016 controls test review. It then identified non-functional attributes, such as the application architecture and hosting model, that would help further these needs. In so doing, KBR ensured that the solution and vendor that it identified possessed attributes that would facilitate its implementation objectives, rather than present compromises or challenges to work around.

Adopt A “Show Me” Approach To Vendor Claims

In addition to including factors with an impact on implementation, KBR demonstrated a strong emphasis in solution evaluation on ensuring that vendors provided concrete demonstrations of their ability to meet KBR’s needs. To this end, one may observe the emphasis that the organization put on vendors’ ability to demonstrate how it would address requirements in RFP answers and in the demo script and evaluation methodology. KBR disfavored pre-packaged presentations and sought concrete demonstrations of how the offering could address KBR’s requirements.

“We required the vendors we evaluated to provide specific responses regarding our business requirements, not only whether or not the system met them, but how. When you get an RFP response from a vendor, most give you ‘yes’ or ‘no’ for an answer. The truth is a vendor can often answer ‘yes’ honestly when the way that it is done makes you want to say ‘no’.”

Patricia Pavlick
Project Manager, Financial Controls, KBR

This “show me” approach plays a crucial role in ensuring that an organization is able to evaluate a vendor’s true capabilities and enabled KBR to gauge not only what functionality the vendor could effectively deliver, but also how much effort would be required to implement that functionality as a working solution for KBR. A solution that looks good in a “canned” demo or “checks all the boxes” in an RFP might require extensive work and application-level customization in order to adapt it to the buyer’s needs. Uncritical acceptance of vendor answers and a lack of attention to the concrete details of how a solution delivers its functionality will result in scope creep, compromises, and workarounds that retro-fit processes to the limitations of a tool. All of these outcomes work to lengthen deployment and erode value, sometimes by dramatic margins.

KBR found that the willingness and ability of DoubleCheck to configure its platform to meet its requirements within the demonstration provided a clear signal of the vendor’s ability to effectively accommodate its needs within its implementation window. In assessing other vendors, KBR observed an unwillingness to attempt to demonstrate the specific functionality required by KBR, as set forth in KBR’s demo script, which left open questions about whether the systems could be configured to KBR’s specifications quickly and easily. In this way, how a vendor responded to KBR’s requests provided qualitative indications regarding the potential working relationship with a vendor and limitations in its system. To this end, KBR observed that the insights it obtained into the DoubleCheck architecture and vendor relationship in the demo proved to represent key attributes that helped drive the speed and success of its deployment effort.

Once again, readers should observe how KBR’s development of detailed and complete requirements that attached to both functional and non-functional attributes of the solution permitted KBR to apply this level of scrutiny.

Without a clear articulation of its requirements, KBR could not assess how a vendor was able to track to these needs. Nor would a vendor have sufficient information with which to provide meaningful responses.

Adopt Formalized Project Management Practices To Manage The Implementation

No matter that the technical attributes of the DoubleCheck solution required less labor than a less configurable solution, KBR’s 3.5 month technical deployment cycle did not happen on its own. Rather, KBR identified a comprehensive project plan that accounted for all steps necessary to achieve its implementation goals and made effective use of standard project management practices to ensure that plan was followed.

Two major project management practices can be credited with the most impact of the operational effectiveness that KBR demonstrated in its technical deployment:

“Our approach was classic project management. You need a dedicated project manager, where the project is clearly that person’s first priority, on both the client and vendor side. You need to develop and use a detailed, task-level project plan and timeline. This is your project ‘bible’. You will adjust it when necessary, but it helps you to know what is needed to do and see where you need to adjust efforts to make your target.”

Patricia Pavlick
Project Manager, Financial Controls, KBR

• The Project Plan and Schedule: The organization developed a detailed, task level project plan and timeline to serve as the project timeline and “bible” maintained by the Financial Controls Group. As at other stages, KBR’s prior definition of business requirements played a role, guiding the scope of the implementation and setting milestones based on objectives. It was reviewed weekly and kept up-to-date and evolved over time. In this way, changes to the project schedule served both to reflect changes and to help direct steps that were needed to keep the project on course. Use of the plan in this way ensured that deployment stakeholders maintained an eye on future tasks and prevented potential slippage and ensured that all parties remained aligned.
• A Dedicated Project Manager: Rather than designate a professional project manager to the project, KBR assigned primary responsibility for project management to a member of the Financial Controls Group. This meant that the stakeholder responsible for moving the project forward did so with a clear sense of the business objectives and operational context involved. The designation of an internal stakeholder within the Financial Controls Group is particularly important as the individual was thus able to bring a thorough understanding of the business requirements that an outsider would not have been able to bring. As such, the project manager could both define the project plan and schedule and drive the execution and progression of tasks with close scrutiny and an eye toward the ultimate business objective. In addition, the project manager was able to work closely with the peer project leader at DoubleCheck in close partnership to drive a mutual focus on project dependencies, keeping pace with the project schedule, and communicating potential issues.

Organizations are unlikely to require extensive reminders of the value of good project management. However, several elements of KBR’s strategy deserve particular attention:

• The rigorous attention by which the project schedule remained a living document and a planning resource, rather than a reporting instrument
• Thorough understanding of underlying business operations and objectives provided context that guided the project management effort, accomplished by designating project management authority within the Financial Controls Group. (However, it should be noted that it is not a best practice to assign a functional owner with no project management experience)
• Clear and transparent communication and partnership with vendor stakeholders, on a regular basis, was crucial to ensuring all parties remained on track

Key Observations and Takeaways

Within a 7.5 month cycle, KBR was able to progress from the identification of a solution investment need and developing a business case for the replacement of its legacy SOX controls system to running a live replacement. By any measure that Blue Hill has tracked, KBR’s implementation stands out as a model of success. This impression is echoed in the organization’s own assessments of its experiences and resulting satisfaction with its platform and its implementation experience.

The steps that enabled KBR to accomplish its objectives represent a mix of careful and rigorous planning, vendor evaluation, vendor partnership, and disciplined focus on business process and needs as well as familiar best practices related to executive sponsorship and project management. Organizations that look to KBR’s example to extract lessons for their own implementations will benefit from each of the best practices identified in this report. However, the importance of the development of precise and comprehensive business requirements cannot be understated. The organization’s effectiveness at all subsequent stages of the implementation resulted, directly or indirectly, from the efforts that KBR put into these requirements at the outset of its project. While Blue Hill has identified effective requirements generation as a best practice previously, the forethought and level of detail seen in KBR’s example is rare. While organizations are not guaranteed to see the same results in their own implementations, learning from these practices will help them to prevent issues related to scope creep, downstream compromises, and budget and schedule overruns that cause GRC implementations to become failures before any solution goes live.

The post SOX Compliance Solution Implementation Outcomes first appeared on DoubleCheck Software.

To place these experiences in context, Blue Hill Research’s July 2015 Benchmark Report Contributors to GRC Implementation Success: Avoiding Worst-Case Scenarios identified the median time for technical deployment alone as 10.5 months.

By contrast, the organization’s experiences are comparable to Blue Hill’s benchmarked Best-Case Scenario, which measured three month technical deployment cycles at the shortest edge of its range. KBR’s ability to successfully complete the full implementation without reducing scope within such short cycles is an outcome of good planning and project management, selection of a solution that could accommodate its needs, and effective decision making throughout this process.

“Our main objectives came down to ensuring we had an integrated solution. We were overburdening our user community with multiple ancillary applications that we couldn’t bring together in the legacy solution. There were two key components to this objective: because of our adoption of a peer-review process, we had to have a well integrated workflow from the various tester to peer reviewer roles and other administrative type functions. We also needed to be able to store all related test results and supporting documentation within the new solution, bypassing the need to extract information from multiple systems of record.”

Steve Vontur
Director of SEC Reporting and Financial Controls
KBR

The following sections will trace the considerations and choices made by KBR at each of the major stages of the implementation process, including:

• Business Case & Requirements Definition
• Vendor Evaluation & Selection, and
• Deployment and Rollout

Figure 3 summarizes the key stakeholders and their corresponding roles and activities at each of these major stages.

Review of the approach taken by the organization and the outcomes that resulted in its implementation process will permit organizations planning similar investments to extract best practices and structure their strategies to help generate similar levels of success.

Business Case And Requirements Definition

KBR dedicated approximately one month to developing a list of approximately 75 business and technical requirements for the new platform. It then identified approximately fifteen of these items as “key requirements”, resulting from a systematic review of SOX test and review processes and related reporting needs.

These requirements are illustrated in Table 2 below, based on their alignment to the major technological challenges identified by the organization.

The Financial Controls Group, as stakeholder responsible for the accuracy of SOX assessment, served as the primary decision maker in this process. However, it gave weight to the needs of business users and executive management that would use the tool. The process was characterized by the following priorities:

• The business process and information needs of the peer review process was given high priority
• Information consumption patterns and reporting demands of business leadership was given high priority
• Technical requirements, such as compatibility with KBR’s IT infrastructure, received low priority once KBR determined it would be using a vendor-hosted offering
• Flexibility to accommodate change in organization, process, and control wordings received high priority

KBR adopted what it describes as a “no surprises” approach to its business requirements definition and evaluation of vendor responses to its RFP. This approach resulted in a set of highly specific business requirements, which would later inform the solution specifications, and a high degree of scrutiny given to vendor responses and demos.

In parallel with requirements generation, the Financial Controls Group created a business case justification for its investment, using a standard form used for organizational IT purchases. Development of the business case itself, which echoes the challenges identified above, resulted from consultations between the Financial Controls Group, the CAO, the CFO, and select business users of the platform.

Approval of the investment required disclosures to and consultation with IT as well as the sign-off of the CAO and CFO. KBR reports that IT involvement at this stage was minimal due to the selection of a vendor-hosted option. The investment approval required the satisfactory review of the written business case. This involved analysis of the following factors:

• Intended business benefits related to SOX controls risk
• Operational scope of the implementation and the intended use case
• Success criteria
• Expected cost of the investment based on preliminary quotes sourced from sample vendors

Once the business case was approved, KBR identified a set budget for the investment based on the range of expected costs presented. Further financial approval was not required as long as the cost remained within the margins of the approved budget.

Solution Discovery And Selection

The Financial Controls Group led KBR’s initial vendor discovery. This process involved a series of informal online searches and review of analyst reports, consultations with business associates using similar systems, and initial phone conversations with known vendors. After the discovery period, a select set of vendors demonstrating roughly comparable functionality was identified for a request for proposal (RFP) process.

“We invested a significant amount of time up-front on requirements, knowing they would be the key to selecting the right solution. The relationships we built with vendors in the early phases of the search were less important than what the system could deliver. If the vendor didn’t show how a specific requirement would be met in a demo, we went back and asked them to try again. If they couldn’t, it was an ‘X’ on the scorecard. It was clear to us from the final scorecard which vendors would be able to deliver.”

Steve Vontur
Director of SEC Reporting and Financial Controls
KBR

RFP Process

The Financial Controls Group worked with the organization’s Procurement Office to initiate and execute the RFP process. KBR gave vendors approximately six weeks to submit responses to questions addressing:

• Functionality
• Application cost and total cost of ownership
• Financial viability of the vendor
• Support offerings and processes
• Technical platform and maturity
• Customer retention and reviews
• Length of vendor experience in SOX support

KBR determined the assessed non-functional factors based on the risks it foresaw in implementing a new solution and entering a new vendor relationship. Again, the Financial Controls Group played the primary role in determining these factors and in reviewing the RFP submissions of vendors. In addition, IT identified key questions to include with respect to technical characteristics to be assessed. In drafting its RFP questions and reviewing the responses of the vendors, KBR placed primary focus on how vendors identified their ability to meet its 75 requirements. As such, KBR ensured that its vendor review would focus on how effectively the vendor would be able to deliver a solution that satisfied its needs, rather than simply stating their solution possessed the capabilities desired.

Vendor Demonstrations

Approximately two weeks after vendors submitted their responses, KBR scheduled demonstrations of the solutions with four vendors based on their evaluation of the RFPs. The demonstration process was intended to permit KBR to see how the vendor would structure and configure its application to meet the organization’s requirements. For this reason, KBR developed a detailed “demo script” design to show KBR specifically how each system would address each of the organization’s business requirements. KBR instructed each vendor to follow the script as closely as possible. To create a formalized and consistent evaluation methodology, KBR developed an evaluation template and ranking system that its demo participants would use.

KBR’s evaluation factors and priorities at this stage closely mirrored those of the business case and RFP evaluation processes, albeit at a more granular level of detail. Primary factors for review included:

• Functionality
• Ease of use
• Implementation process
• First-year cost
• Total cost of ownership

KBR favored vendors that could demonstrate, in person, how its requirements could be implemented and configured in the product. For this reason, the organization disfavored slide-based presentations or a prefabricated “standard” demo presentation. Again, KBR gave significant consideration to how changes to controls, business processes and organizational structure would be handled by the system and the projected resulting impact on a closed assessment cycle.

After dedicating two weeks to demonstrations, KBR spent a day compiling evaluation results. The organization then identified the top two performers in the demonstration phase for additional discussions, which occurred over several weeks. As with the RFP evaluation, the Financial Controls Group was the primary reviewer in the vendor demonstration stage. IT stakeholders participated as well to assess technical issues and identify potential concerns, such as platform instability, system design obstacles, and other contributors to negative performance.

Solution Selection

On the balance of its evaluation factors at each stage, the organization selected DoubleCheck to provide its SOX management platform. KBR reports that this decision reflected its assessment that the vendor demonstrated its ability to address its 75 business requirements, but stood out by demonstrating within the confines of the demonstration how to configure the solution to meet those needs, where other vendors indicated that weeks or months would be required to customize their offerings to meet the organization’s requirements and use case. The selection was made by the Financial Controls Group, as the cost of the solution was within the approved budget and IT involvement would be minimal to deploy a vendor-hosted platform.

Deployment And Rollout

Translating KBR’s business requirements and the raw capabilities of the DoubleCheck platform into a working solution supporting SOX controls testing constituted the major component of the deployment process. As KBR would be adapting a new tool for existing operations, items such as controls definitions, tester and reviewer assignments, and major process requirements had already been established.

Responsibility for the remaining effort would be split between KBR and DoubleCheck and executed in parallel. KBR was responsible for defining its user roles, workflows, data models, and reporting schema. The Financial Controls Group bore primary responsibility for developing proposed models for these system attributes, with review and feedback from the CAO and guidance on implementation from DoubleCheck.

In addition, DoubleCheck bore direct responsibility for provisioning the underlying application environment and configuring the application to KBR’s specifications. The Financial Controls Group retained primary responsibility for overall project management, user acceptance testing (UAT), and rollout and training.

Table 3 summarizes these respective roles and responsibilities for each of these set of activities within a RACI matrix.

Table 4 summarizes the approaches taken by KBR with respect to key components of the implementation process. KBR’s objective was to use the platform to support 2016 SOX controls testing. Accordingly, it set out to complete these steps within a four month window. When completed, the organization had run over its target by one week. The definition of clear, detailed requirements at the program’s outset provided the groundwork for the items in Table 4, as well as a basis from which the vendor and KBR could execute to these goals.

“We had a collaborative relationship with DoubleCheck. They gave us diagrams of proposed system workflows for controls tests and issue management, which we modified to align with our business processes. The starting point was the old process, but we were open to changing if it made sense, and we did make some changes. DoubleCheck performed the configuration of the system according to our specifications. They were easy to work with and didn’t have the budget creep issues of some vendors. They were focused on making sure we were happy with what they sold us. That’s a big success factor.”

Patricia Pavlick
Project Manager, Financial Controls
KBR

Additional contributors to success resulted from both the vendor and KBR’s approach to deployment, such as:

• Application Contributors: The DoubleCheck application is highly modular and supports a deep level of in-application configuration of most aspects of the implementation with little to no customization or changes to code. The use of a vendor-hosted delivery model contributed, as well, by eliminating the need for new infrastructure and environment creation by KBR.
• Vendor Relationship Contributors: DoubleCheck also executed its aspects of the implementation under a flat service fee, rather than by hourly or labor-based pricing. This worked to prevent budget creep in the implementation as well as incentivized efficiency on the part of the vendor. This model also has the advantage of minimizing mid-project negotiations regarding the respective parties’ responsibilities and the scope of billable work.
• Project Planning Contributors: The Financial Controls Group managed the execution of all parties’ activities and project schedule. At the outset of the implementation, the Financial Controls Group created a detailed project plan, which fixed responsibility for each task and set a target due date. The Financial Controls Group identified its necessary milestones and implementation scope based on the functional capabilities it needed to support its core supported business operations on the go-live date.
• Project Scope Contributors: Capabilities that KBR required in the platform but did not need to use on the go-live date, such as reporting features, were reserved for updates that would follow the primary implementation. After setting the scope and major milestones, KBR worked with DoubleCheck to get input about the nature, timing and sequence of tasks that were specific to an implementation of their system. It then plotted tasks accordingly to fit its milestones. Where possible, activities were scheduled to run simultaneously.
• Project Management Contributors: KBR closely managed all aspects of the project plan under formal project management practices. KBR designated a formal project manager from the Financial Controls Group with a peer on the DoubleCheck configuration team. KBR held standing project meetings twice a week. In addition, it held periodic project plan review meetings where the project management leaders from both KBR and DoubleCheck could meet. These meetings were used to identify gaps in execution, identify potential issues or obstacles, and reassess milestones or refocus priorities. Accordingly, the organization reports that it was able to remain aware of crucial needs and respond accordingly to prevent slippage or unforeseen delays.

The post SOX Compliance Solution Investment and Implementation Process Review first appeared on DoubleCheck Software.

“When we talk about efficiencies that DoubleCheck has added, we have cut preparation from two weeks to a day. In the past, for us to audit a quarter of data, we would take four to five weeks to gather all transactions that take place. Now we’re able to audit a full month’s worth of data in just ten days. Over the course of an entire quarter, we go from having to take three months to audit a quarter to just thirty days.”

Compliance and Audit Director
Automotive Retailer

Audit process automation, by contrast, places these separate, siloed solutions into a single, integrated solution. This saves time, effort, and ultimately frees the audit team to engage in more value-adding tasks beyond simply developing reports to comply with regulatory requirements, such as assisting with training or correcting other issues as they arise during the normal course of business. Addressing the complex audit environment with the proper solution is not just about assurance, risk avoidance, internal overhead, and speed of business operations, but it is about creating a stronger and more efficient organization.

The profiled organizations reported a range of benefits as they engaged in audit process automation. Both organizations needed a system that would provide them with better control of the audit process and needed better tools to manage the process. Prior to adopting a single, consolidated solution, neither organization had the ability to efficiently and accurately control the audit process and were either dependent on others to provide assistance throughout the process or otherwise struggling to control unwieldly datasets with tools poorly suited to the tasks.

Blue Hill Research found that audit process automation leads to a higher level of accuracy and efficiency in the way audits are conducted, which has multiple spillover effects. Primarily, a more accurate and efficiently-conducted audit is going to assist an organization with maintaining regulatory compliance. Additionally, the time saved (as the audit department does not need to spend as much time confirming datasets or otherwise searching for information) provides the audit department with the capacity to engage in providing additional value to the larger organization, either through conducting additional audits or through the completion of additional tasks. For example, the auto retailer has been able to assume more quality control tasks, such as providing more real-time information to dealerships to correct issues or problems early in the process; likewise, the audit department of the insurance company has been able to engage in additional audits.

Blue Hill Research observed three main value propositions associated with the automated audit process and one value proposition that resulted from the automation even if arguably outside the scope of automation. The value propositions of audit process automation are the improved efficiency and the associated increased speed to complete the audit; accuracy and the associated reduction in errors occurring during the audit assessment; and finally the organization’s ability to respond to regulatory changes.

The other observed benefit by Blue Hill Research is the ability of the audit to drive business improvement. With the time saved through the automation process, the audit departments of the observed organizations were able to engage in additional tasks, such as by providing additional guidance to the organization to correct problematic areas or assist with the creation of training modules.

Key Observations and Takeaways

Blue Hill Research found process automation allows organizations to successfully navigate complex workflow environments. Audit process automation, which is one such example, provides the organization with the tools to manage data spread through large datasets and to manage diverse stakeholders with competing interests. A complex audit environment is defined differently by every organization and is dependent on the interconnection of factors faced by organizations, multi-faceted regulatory environments, and facing a diversity of subject matters. Within a complex workflow environment, an organization is going to need a solution that will have both the robustness to handle the amount of data required by the organization and the flexibility to handle changes within the regulatory environment.

DoubleCheck Software solution for audit process automation addresses the complexity of the audit environment by providing a solution that can by modified to meet the requirements of the organization. The solution allows the organization to efficiently track the matters and stakeholders involved in large, complex audits, develop questionnaires within the solution, and verify the accuracy of answers early in the audit process. By automating as much of the process as possible and freeing up resources that would otherwise be tied up in labor-intensive manual data entry, organizations have the ability to assure the accuracy and quality of the audit.

Further, Blue Hill Research observed the organizations within the study utilized the DoubleCheck application to assist in the further development of the best practices. The solution provides the organizations with the ability to modify and set workflows to match their requirements. Both organizations reported that after setting the workflows to match prior workflows, they were able to identify inefficiencies in their practices and modify the workflows to create a more efficient process. With the increased efficiencies, the audit departments had the further ability to confirm the accuracy of the audit and engage in additional value-adding tasks.

As a reflection of the growing maturity within the field of GRC and Audit, organizations are not satisfied with simply looking to GRC solutions as assurance of compliance. There is a growing pressure in the market that these solutions have the flexibility to also assist organizations with assessing the risks they face and take measures to address those risks. Both the insurance provider and the automotive retailer reflect the growing maturity of the market both through their current use of the DoubleCheck GRC solution platform and for their future plans. For example, the automotive retailer has begun the process of developing a compliance-monitoring program within the DoubleCheck GRC solution platform. A successful GRC solution will need to be highly configurable to meet the constantly-shifting regulatory and compliance needs of an organization and must have a full audit process automation component integral to the platform.

The post Business Value Observed In Audit Process Automation first appeared on DoubleCheck Software.

To provide organizations with concrete best practices for their own investments, this Case Study reviews the experiences of KBR, Inc. (KBR), a public, global professional services and technology provider, as it installed a new compliance system dedicated to supporting its Sarbanes Oxley (SOX) controls testing and review processes. After determining a new solution was required, the organization began to search for a replacement in September 2015. KBR completed user rollout in time to begin using the solution for its 2016 SOX controls review, a total project period of approximately 7.5 months, with 3.5 months of post-contract implementation work.

AT A GLANCE

Organization Profiled

KBR, a public, U.S.-based services and technology provider with over $4 billion in revenue and over 27,000 employees

Implementation

Replacement of a legacy SOX controls management platform with a new system from DoubleCheck Software intended to support core controls management and a peer-review approach to controls test review involving 400 testers and reviewers.

Implementation Experience

• Total Project Time: 7.5 months
• Deployment & Rollout: 3.5 months
• “Extremely high” end-user satisfaction
• “Very high” satisfaction with business impact

Best Practices

• Precise & comprehensive business requirements
• Project leadership by the Financial Controls Group
• Executive-level support and championship for the project
• Solution delivery options aligned to business priorities
• A “show me” approach to vendor claims
• Formalized project management

By reviewing KBR’s strategic decisions and tactical approach to key aspects of (1) business case and requirements definition, (2) solution evaluation and selection, and (3) deployment and rollout, Blue Hill identifies crucial best practices which will enable organizations to achieve similar results in their own implementations.

Controls Test and Review Business Context and Needs

KBR is a public, U.S.-based global provider of differentiated professional services and technologies across the asset and program life cycle within the hydrocarbons and government services sectors. Its operations extend across over 40 countries and more than 27,000 employees. Annual revenues exceed $4 billion, generated from customers distributed across approximately 80 countries. As with any company with this scope of operations, Sarbanes Oxley (SOX) controls management, assessment, and testing represent a complex and wide-ranging effort.

Management of KBR’s controls development and testing is centralized under its Chief Accounting Officer (CAO) and its Financial Controls Group, a team of five individuals. Controls were established by major business segment and pushed down to the underlying business groups. Although control owners performed self-assessments of control effectiveness, a significant amount of reliance was placed on quality assurance reviews and independent testing performed by an internal audit team.

“Our CFO drove the focus on peer review. It was a major initiative intended to decentralize ownership of the internal control process and reduce overhead costs associated with SOX assessment. We looked at the amount of time the audit department spent on testing and we thought we could cut that back. Peer review was a way to do that, by distributing the man-hours across our business groups.

Perhaps the biggest benefit of the new process has been that it embedded an understanding of SOX controls into the day-today thinking of the business. We’ve made huge gains.”

Patricia Pavlick
Project Manager, Financial Controls

Within the past several years, the organization made two changes to embed engagement with controls more deeply within its business operations:

• Adoption of a peer review approach as an added step to evaluate the quality of control tests performed by the control owners themselves, whereby the control tests applied to a particular group would be reviewed by organizational peers independent of control operation
• Assignment of “SOX Champions”, a designated stakeholder within a business group responsible for providing input on tests and controls and managing remediation of identified issues

The inclusion of peer review added a new step to the organization’s controls testing and review operations model, while also adding to the stakeholders involved (Figure 1).

Peer reviewers are generally manager-level and above employees. These stakeholders generally fell within the same business group as the control tester and reviewer, but were not associated with the operation of the controls under the relevant peer review.

The new process involved approximately 400 testers, reviewers and peer reviewers, an increase of approximately 150 stakeholders. While reducing the concentration of labor on Internal Audit, this expansion added to the complexity of the testing and review and raised a need to ensure that a consistent, high-level of audit quality was maintained.

Key Technology Challenges and Investment Drivers

At the time that the organization began to implement its new peer review process, KBR was using a legacy controls management system that was over ten years old and no longer supported. Due to the age of the application and changes in KBR’s processes, the organization had identified several limitations of the legacy platform, including:

• It could not store or manage documents supporting control tests
• It lacked the capability to support the management of deficiencies, requiring the use of external spreadsheets
• It did not possess the functionality needed to support the distributed file and information exchange, and reporting demands of the peer review process
• The vendor no longer supported the platform, so functional expansions and application support were unavailable, while security risks would increase over time

“We’ve used the same system since SOX was introduced, but our approach to assessment had changed. We added a peer review to the controls test and review process. Our system could not handle that second level of review, so we tried to manage it using a file share application. However, data integrity issues are common when sharing files among many users. We were now dealing with multiple copies of the same file that had to be combined into a centrally controlled ‘master’ copy. This was very inefficient and risky from an accuracy standpoint.”

Patricia Pavlick
Project Manager, Financial Controls
KBR

KBR determined that an investment in a new platform was needed to replace the legacy platform and support its changes in the control test and review process.

KBR identified a need for a new investment in an integrated SOX controls platform that could maintain a master library of risks and associated controls as well as provide a centralized platform to support controls tests, peer review, and reporting across the organization. Ultimately, KBR implemented this solution by partnering with DoubleCheck Software to implement and configure the DoubleCheck Governance, Risk, and Compliance (GRC) platform according to their identified needs. Table 1 identifies the key features and characteristics of this platform, as reported to Blue Hill Research.

The post SOX Controls Management and Best Practices in Compliance System Implementation first appeared on DoubleCheck Software.

AT A GLANCE

To assess the impact of audit process automation on complex audit environments, Blue Hill Research analyzed the reported experiences of two organizations with respect to key audit challenges, corresponding investments in audit process automation, and the resulting impact for the organization.

Characteristics of Complex Audit

• Volume
• Transaction-Driven
• Diversity of Subject Matter
• Diversity of Requirements

Solution Characteristics

• Platform Configurability
• Reporting & Analytics
• Workflow Automation
• Process Management
• Requirements Library

Benefits Realized

• Profiled Organizations reported a 70-90% reduction in time to complete pre-audit preparation
• Profiled Organizations reported a 40-60% reduction in time to complete quarterly audit
• Increased capacity to drive new strategic initiatives

Governance, Risk, and Compliance (GRC) software provider DoubleCheck Software offers a vision and software solution for audit process automation developed uniquely for complex audit environments that emphasizes a combination of requirements management, process management, workflow automation, and analytics capabilities. Unlike best-of-breed audit tools, specific to work paper management, the DoubleCheck strategy emphasizes the integration of these capabilities within a highly configurable suite to support the full scope of the audit process as well as provide the flexibility to support evolving needs. In order to assess the potential business value of this strategy in complex audit environments, Blue Hill Research investigated the investments of two organizations demonstrating key attributes of DoubleCheck’s strategy. This report summarizes the observed complex audit business cases and investment characteristics, and the resulting improvement in efficiency and accuracy reported over legacy approaches, including a 60% reduction in the time to complete quarterly audits.

Defining the Complex Audit Environment

In contrast to periodic or intermittent audit needs typically targeted at validation of controls, process audits (such as an AP audit), or a financial report audit that might be familiar to non-practitioners, the complex audit environment is characterized by a multitude of interconnected circumstances between an organization and its regulatory requirements. Blue Hill Research divides those circumstances into four basic categories (Table 1). These characteristics are not absolute values, but should be viewed as a matrix by which organizations can evaluate the relative complexity of their own audit requirements.

To greater and lesser degrees, all organizations confront these factors. Determining whether an organization’s circumstances rise to the level of complex audit depends on the interaction of these factors and the scope of operational and business impact. To this end, the occasional, customer-driven audit does not give rise to the same scope of organizational demand as on-going audits against a variety of requirements. In particular, Blue Hill observes that complex audit environments frequently possess a decentralized aspect. Rather than being driven down through a central functional area, such as compliance or risk departments, the complex audit emerges out of ongoing business operations and discrete business units and sites, such as various regional branches or storefronts, spread across multiple geographic locations and, often, jurisdictions. Management of a complex audit thus necessitates balancing the requirements, needs, and frankly, desires of disparate stakeholders—both within the business structure of the organization and outside of the business environment.

Examples of organizations facing complex audit environments are:

• Insurance companies for policy audits
• Mortgage lenders or other lenders engaged in similar secured transactions
• Multi-location banks
• Multi-location large chain stores for inventory control and regulatory compliance
• Multi-location chemical manufacturers to verify environmental compliance
• Research organizations engaged in clinical trials or studies using controlled substances.

In these environments, traditional audit methods are often unsatisfactory, as these approaches are generally intended to support particularized and detailed (but intermittent) inquiries, rather than diverse, ongoing assurance efforts. In a complex audit environment, management is about more than just organizing and completing a single audit, but it is incumbent on the organization to ensure that the various audits facing an organization are completed simultaneously and with a high degree of accuracy—assuring the value of the audit. In that vein, the organization must confirm that all necessary steps are completed and that efficiency is maintained. In addition, due to a lack of resources and strategic IT focus, audit departments are frequently left to perform their functions with legacy, siloed tools that have resulted from prior best-of-breed investments. Ultimately, these factors lead to slower audit processes, overloaded audit backlogs, and an increased likelihood of inaccuracies or errors that contribute to overall risk exposure.

DoubleCheck Software

DoubleCheck balances its software on four key pillars: use case personalization, configurable workflows, analytics reporting, and data visualization capabilities.

Use-Case Personalization

• “Workbench” environment tailored to provide each role with information relevant to their responsibilities
• Centralized data management structure

Analytics Reporting

• Customizable options to meet client needs

Data Visualization Capabilities

• Heat map, graphs, and dashboard views

Configurable Workflows

• Robust workflow and process management framework
• Highly configurable to match customer process

Audit Process Automation: Capabilities and Articulated Value Proposition

DoubleCheck’s audit process automation solution set is, in part, a response to the needs of the complex audit. To this end, the software provider articulates a comprehensive vision of the integrated coordination of audits from audit requirements management to execution and reporting. Core functionality sets included in the scope of DoubleCheck’s approach include a requirements library, process management capabilities, workflow automation and alerting, and reporting and analytics capabilities provided via an integrated Jaspersoft business intelligence engine, which supports advanced reporting, analytics, and visualization. In addition to these core capabilities, the DoubleCheck platform supports audit process automation through dedicated audit capabilities, such as auto-sampling and compliance template question mapping.

Individually, the functionality components included in this approach are not unique to audit management or the demands of complex audit environments. As such, two non functional attributes of the DoubleCheck platform are crucial to this approach: the degree of suite integration with other key GRC components and the degree of platform configurability. Both the integrated nature of the applications and the platform configurability represent core elements of the DoubleCheck audit process automation strategy. Standalone, best-of-breed audit applications, such as work paper management or transaction monitoring software, address specific functionality as discrete tools, creating application and data silos which contribute to inefficiencies in the audit management process as well as exacerbate the potential for error.

By contrast, the DoubleCheck approach is intended to maintain centralized management and continuity as the audit progresses through activity stages. Further, the high degree of configurability within the platform permits a high degree of persona- and project-based interface, data, and process exposure, and flexibility of workflow and data models. The flexibility of the solution permits a high degree of personalization to assist with the simplification of work environments as well as to enable self-service and self-reporting by audit stakeholders. Further, the adaptability of processes and data models offers organizations the ability to tailor the platform to varying sets of requirements and audit workflows, as well as preserve flexibility to adapt the solution to changing needs. Figure 1 provides an illustration of the functional components and non-functional aspects of this strategy.

The core value proposition of audit process automation in the context of complex audit is the capability to coordinate diverse sets of requirements, enforcing centralization and continuity of data within a single source of truth, and automation of manual and repetitive efforts. The articulated benefits of these changes primarily derive from: (1) reduced time to audit completion, (2) increased accuracy and reliability of audit, (3) increased efficiency of audit personnel, and (4) consistent and precise repeatability.

Nothing in these value propositions is unique to either the notion of audit process automation or complex audit. To this end, Blue Hill observes that a similar mix of process efficiency and risk mitigation objectives generally drives audit management investments. The distinct value enhancement offered by audit process automation in the complex audit context results from repeatable, efficient process that removes manual, ad hoc, and unnecessary steps while preserving the flexibility to map a coherent solution to a diversity of audit needs and stakeholders. Further, the removal of the silos between the solutions and centralized management of the platform provides the stakeholders with greater control over the individual audit and provides the stakeholder with greater control to meet evolving challenges.

The post The Impact of Audit Process Automation in Complex Audit Environments first appeared on DoubleCheck Software.

Summary of Cases: Business Context and Investment Patterns

Both organizations faced multi-faceted and multi-functional audit requirements common to complex audit environments. Some of these requirements focused on the regulatory framework in which the organizations exist, while others were in response to internal and external business pressures. As such, the organizations required the ability both to complete audits for the various regulatory authorities at the federal, state, and local levels. Further, audit departments were required to support various stakeholders inside and outside the organization (e.g. board members, shareholders, potential investors, etc.) while supplying result information in a rapid fashion to address real-time issues within the organization.

• Case 1: Automotive retailer with more than 140 locations and business operations reaching across the United States. The automotive retailer has approximately 1400 employees and revenue of more than $500 million. In addition to automotive sales, the organization is engaged in direct financing of vehicle sales and repair.
• Case 2: Insurance provider primarily engaged in personal life and casualty insurance provision across the United States and other continents. The insurance provider has total annual revenue of more than $2 billion and approximately 15,000 employees.

Table 2 summarizes the key characteristics of complex audit demonstrated by each organization. Table 3 summarizes the key functionality elements of the DoubleCheck audit process automation strategy demonstrated by the organizations. While Table 3 only addresses the integrated functionality components of the investment, Blue Hill found that the participants made full use of the platform configurability characteristics identified as well. The sections that follow highlight key aspects of the business case, investment decision, and resulting impact reporting in each case.

Automotive Retailer

Business Need:

The organization possesses multiple lines of business associated with the sale of cars requiring strict compliance with various regulatory agencies; including the sale of used vehicles, the financing of these sales, financing repairs to the vehicles, contract modifications, and car repossession. Audits were completed through spreadsheets that were distributed by email. Compiling and reporting audit information thus constituted a highly painstaking process, requiring a great deal of manual manipulation of data with an accompanying heightened risk of error either accidental or intentional. Per interviews with the organization, the disparate data sources made it difficult to quickly and efficiently identify errors or otherwise verify the accuracy of the audits.

In addition, the manual audit process was slow, inefficient, and disorganized. Quarterly audits took three months to complete, which limited the ability of the audit department to engage in additional elective, but value-added activity. The automotive retailer needed a solution capable of performing regular, periodic audits and a solution capable of completing unscheduled audits triggered by events—such as the sale or financing of a vehicle.

Investment Objective:

Remove manual audit activity, ensure compliance with multiple requirements, and reduce the risk of error.

Key Audit Process Automation Functionality:

• Platform configurability to maintain an efficient and organized workflow
• Customizable reports capable of encapsulating the entire corporate structure or honing down to the dealership level
• Compliance control and auto-sampling

Business Impact:

With the adoption of the DoubleCheck GRC solution platform, the organization was able to consolidate its process into a single, unified system and greatly improve the efficiency and accuracy of the audit process. For example, the auto retailer observed a 60% reduction in time to complete the quarterly audits. The time saved both in the periodic quarterly audits and the transactionally-driven audits allowed the retailer to experience additional business-driven value, such as assisting with the compliance efforts of the organization. Additionally, the retailer received advanced notification if any of the data included in the audit did not match expectations. The early error detection allowed the auto retailer to confirm or correct the data as necessary and guarantee a more accurate audit, which improved their level of compliance.

Insurance Provider

Business Need:

The organization sells property and casualty insurance across the United States and is required to maintain strict compliance with various regulatory agencies. Audits were completed through the use of three discrete solutions, requiring the data to be manually moved from solution to solution. Audits were completed through the cooperation of multiple stakeholders throughout the organization. Per interviews with the organization, the disparate stakeholders made the completion of audits a slow and painstaking process.

Investment Objective:

To gain control of the audit process, remove manual audit activity, ensure compliance with multiple requirements, and reduce the risk of error.

Key Audit Process Automation Functionality:

• Library of audit questions customizable by state
• Notifications if answers are blank or incomplete
• Automatic email-based alerts to verify issues found in audit are addressed prior to issuance of a policy
• Robust, customizable reporting capabilities that allow the user to create reports at the granular level whether based on individual or state-by-state

Business Impact:

With the adoption of the DoubleCheck GRC Solution platform, the organization was able to obtain control of its process and consolidate the process into a single, unified system to improve the efficiency of the audit process. Prior to adopting the platform, the audit department was required to secure the assistance of parties outside of its control for assistance with placing audit questions into the audit platform, data-entry of the audit questionnaire results, and the subsequent generation of reports. Additionally, the insurance provider gained efficiencies through the creation of customizable reports that reflected the reporting requirements of the insurance provider, including the automation of a report that synthesized the answers from separate reports to create a risk profile of an insurance candidate.

The post Investigating And Analyzing The Impact And Business Value Of Multi-Functional Audit Process Automation Strategy first appeared on DoubleCheck Software.

Governance, risk, and compliance (GRC) solutions evolved in response to growing information and process complexity of compliance and risk management. Initially launched in large part by Sarbanes-Oxley requirements, GRC has evolved into a full enterprise application for compliance and risk management. While the GRC vendor landscape remains fragmented, the space has largely evolved toward the development of “enterprise GRC,” or the cross-organization and cross-functional management of governance, assurance, risk, and compliance activities. These expansions have brought a variety of stakeholders into GRC, creating demand for tailored insight and workflow for diverse users, while maintaining a centralized information architecture.

GRC providers have responded, to greater and lesser degrees, by developing capabilities and refining their architecture to balance individual user productivity and insight with cross-enterprise information and process management. This report explores four major areas of differentiation that have emerged as a result: (1) use-case sensitive work environments, (2) the incorporation of analytics, (3) data visualization capabilities, and (4) configurable workflows. This report, and subsequent blog reports in the series, explores the dynamics of each differentiator and identifies potential market needs in light of growing demands for cross-enterprise insight into compliance and risk.

THE RISK MANAGEMENT & REPORTING STUDY AT A GLANCE

As GRC evolves from a functionally orientated solution to a true enterprise risk management platform, the number and diversity of enterprise stakeholders that provide or apply enterprise risk management data has expanded significantly. This has created new needs and new areas of differentiation for GRC.

This report draws from Blue Hill Resarch analysis and research interviews with fifteen senior risk management executives to identify and profile four key differentiators in the maturing enterprise GRC landscape:

• Tailoring to use- case contexts
• Incorporation of business intelligence analytics
• Data visualization
• Configurability of workflows

The Core Functionality and Value of GRC

Compliance and risk management professionals are responsible for identifying issues, maintaining corporate tolerances and standards, responding to incidents, and reporting to other business leaders as well as external stakeholders and authorities. GRC solutions are largely aimed at these functions, often with permutations adapted to particular industries, risks, or roles. The most common specializations of GRC relate to financial, IT, legal, and compliance functions, while enterprise GRC combines these views into a comprehensive vision of corporate risk and compliance efforts.

As a matter of product functionality, the core components of GRC generally involve the following capabilities:

1. Centralized data management
2. Process and incident management
3. Workflow management
4. Automated monitoring and alerting
5. Automated reporting

Depending on the scope of an implementation, these capabilities may be deployed in support of a single unit, a full compliance or risk department, or as a comprehensive enterprise solution.

In keeping these capabilities, GRC’s first source of value manifests in terms of operational efficiency. In the absence of GRC, organizations often rely on manual and spreadsheet-based processes, which often results in significant time demands related to information collection, aggregation, analysis, and reporting. This has an impact on the compliance and risk staff tasked with these processes, as well as other business units that must respond to requests or wait on compliance and risk management staff approval to execute processes. As such, the most basic applications of GRC primarily contribute value in terms of staff productivity. In this light, organizations participating in Blue Hill research generally report that GRC contributes between 25% to 30% reductions in time required to execute compliance and risk tasks.

The most basic applications of GRC primarily contribute value in terms of staff productivity, with Blue Hill research interviews typically revealing between 25% to 30% reductions in staff time required to execute compliance and risk tasks.

However, these gains largely represent table stakes, with the larger value contributed by improved speed and quality of insight into changing compliance and risk status.

GRC’s second source of value emerges from the central collection, management, and analysis of data related to compliance and risk. In this light, GRC increases an organization’s ability to monitor performance, rapidly identify risks, and obtain insight into historical trends and changes. This improved compliance and risk visibility can, in turn, help to control an organization’s exposure, as well as mitigate the harm of adverse events. Advanced GRC capabilities, such as automated monitoring, alerting, and analytics capabilities, tend to benefit this area. The reach of GRC to the various risk owners distributed across the organization, as well as their acceptance and ability to effectively use GRC, are also factors that impact how accurately data within GRC represents the actual exposures and performance of the organization.

The first source of value (efficiency) represents table stakes for GRC investments, and has a clear impact on the operational effectiveness and overhead associated with compliance and risk. This second area impacts the speed and quality of insight into changing risk and compliance status, as well as the effectiveness of the organization’s ability to respond. Because the business value of this insight generally manifests in reduced risk or avoided incidents or costs, rather than direct contributions to overhead, it can be difficult for organizations to quantify the impact of this aspect of GRC, even where they report substantial improvement. Nonetheless, organizations participating in Blue Hill research interviews uniformly reported that increased visibility into enterprise risks and operational performance constituted the most valuable benefit of GRC.

Table 1 summarizes the impact of core GRC functionality and related benefits as reported by research participants.

The post Components Of An Enterprise Risk Reporting And Management Platform first appeared on DoubleCheck Software.

The various delays and costs that result from these factors ultimately serve not only to prolong time to value, they also erode the ultimate gain provided to the organization. Organizations undergoing Best-Case GRC implementations exhibited roughly a quarter of the deployment time and one-third of the cost of those involved in Worst-Case scenarios. Given the cost-avoidant nature of many of the business contributions made by GRC platforms, the pain and cost of implementation often become some of the most transparent impacts of the solution investment. As a result, extended or expensive implementations can create long delays in the time to adoption and value, eroding organizational support for and perceptions of value. To this end, some participants reported the most difficult implementations found the solutions ultimately went unused by the organization or were abandoned mid-deployment.

“We have over 150 locations across different countries and functional stakeholders to support. We selected a solution with a stable and scalable architecture that could be configured to fit each location’s needs. Once the infrastructure was in place, we rolled out to each location in place one-by-one. The whole process was done in 10 to 11 months.”

Systems Engineer
Process Manufacturer

Where implementations proceed painlessly and organizations can identify quick benefits and successes, it becomes easier to build support and adoption for the solution. This pattern can be observed in the correlation between time and cost to implement with high levels of satisfaction among both end-users and business owners among organizations experiencing Best-Case implementations.

As organizations plan their own GRC implementations, four core recommendations to consider may be extracted from a comparison of Best-Case and Worst-Case scenarios:

• Build from a clear vision of business needs and process change – A review of the practices of organizations experiencing Best-Case and Worst-Case implementations reveals a significant disparity in the allocation of time between business planning and technical implementation. Organizations with Best-Case experiences place a large amount of focus and effort on assessing business needs and process development. Organizations should begin with an understanding of the most fundamental business objectives that relate to GRC processes and build from there, rather than permitting implementations to be determined by functional requirements or impending risk events. This helps these organizations to lay out a prioritized strategy for the implementation and maintain discipline as scope creep or differing visions for functionality and workflow are inserted in the process.
• Align implementation milestones to business value requirements – the approach used by organizations that experience Best-Case implementation could be described as “start small and scale.” In this way, they help ensure they take the shortest path to value which can be used a proof of concept and build support for the investment as well as work out potential issues with relatively low stakes. The crucial factor in making this approach work is to prioritize the project by business objectives, organizational need, and the ability to show value. By identifying needs and measurable benefits at each stage of the roll-out, the organization can ensure that the solution is providing the value desired, or identify potential problems or changes that need to be made. This will help ensure that the organization continues to show value, which can be used to justify additional projects and expansions to the solution. Line of Business stakeholders can play a crucial role in identifying these needs, while financial and executive business management can help set the necessary goals and value thresholds.

“We already had defined processes and a proprietary risk management framework. An off-the-shelf system wasn’t going to cut it and we didn’t want to have to change to meet the needs of the system. The system needed to be able to meet our process. Out of the six vendors in our RFP, we found one that could walk in the door and configure the system to make it work in front of us. When it got to implementation, we only saw a few problems…and those were solved in minutes.”

Chief Operating Officer
Utilities Provider

• Involve IT at the earliest stage of the investment – The extent and timing of IT’s involvement with the implementation process represent another key area of difference between Best-Case and Worst-Case implementations. Where Worst-Case implementations saw IT become involved in at later stages of solution identification and planning, Best-Case implementations exhibited close partnership between IT and line-of-business stakeholders from the earliest stages. As IT is in the position to identify major technical problems that can occur in the implementation, early involvement is key to helping the organization avoid and mitigate these issues with minimal impact on the process.
• Seek configurability over customization, where possible – of all factors considered, Blue Hill Research found that software customization had the most direct impact on the length and cost of implementation. While customization is not always avoidable, organizations must pay careful attention to the flexibility and scalability of the options a GRC solution provides. While configurability does not eliminate the effort that is required to plan and tailor the solution, it minimizes the technical aspects of the implementation significantly and preserves flexibility to make changes as project requirements change or when GRC needs evolve in the future.

The post Best Case And Worst Case Scenarios In GRC Implementations first appeared on DoubleCheck Software.