More

    Achieving GRC Convergence Platform Requirements

    Integration of multiple governance, risk and compliance (GRC) disciplines on a single platform is a laudable goal, and the effort to achieve it by both vendors and their customer organizations is increasing. Notably, within the enterprise GRC (eGRC) space, integration occurs most often among the internal audit, financial controls and enterprise risk assurance functions. Conversely, the compliance function has been less inclined to integrate, due in part to the specific subject-matter expertise required for each of the compliance functions, which makes the broader risk and control sets documented by other groups less relevant to compliance teams.

    Still, the Institute of Internal Auditors’ (The IIA) position paper, “The Three Lines of Defense In Effective Risk Management and Control” (January 2013), offers valuable insight into why it makes sense to bring these functions together, at least on an aggregated level, even if subsets of information are contained in other source systems. According to the paper, convergence will enable the three lines (operational/business-line managers, risk and compliance functions, and internal audit) to coordinate activities, map assurance functions and perform independent validation.

    But significant barriers to the comprehensive and successful integration of GRC technology across numerous groups remain. For example, many organizations continue to depend on multiple GRC technologies to fulfill different and specific departmental needs, and most organizations use different platforms for IT GRC and eGRC. Other obstacles include the lack of a unified GRC framework or a common language, the complexity of existing technologies, the lack of effective change management, and a lack of demonstrable return on investment (ROI).

    Achieving convergence in the face of these obstacles requires technology capable of unifying an organization’s policies, processes and infrastructure. In this slideshow, Protiviti has identified the key elements of a technology platform capable of doing so.

    Real-World GRC Convergence: Platform Considerations - slide 1

    Convergence Platform Requirements by Domain

    Click through for the key elements required to unify an organization’s policies, processes and infrastructure and achieve GRC convergence, as identified by Protiviti.

    Real-World GRC Convergence: Platform Considerations - slide 2

    Enterprise Risk Management (ERM) Requirements

    ERM platforms enable companies to execute business strategies while managing enterprise and operational risks. ERM platforms should help organizations:

    • Establish a risk model or framework that documents a common risk language across the organization.
    • Deploy risk assessments through an integrated workflow and survey engine, helping risk managers identify and focus on the right risks at the right time.
    • Develop response strategies to address identified risks and manage the implementation and execution of the strategies.
    • Identify key risk indicators (KRIs) and establish acceptable thresholds that generate alerts to stakeholders and executives.
    • Manage incidents and their impact on the business through data collection, reporting, root cause identification and accountability.

    Real-World GRC Convergence: Platform Considerations - slide 3

    Compliance Management Requirements

    Compliance platforms enable companies to incorporate laws, regulations and internal policies into an enterprise risk profile. Compliance platforms should help organizations:

    • Manage policies, including documentation, review, communication and attestation.
    • Integrate policies with other enterprise content and records management systems such as Microsoft SharePoint.
    • Monitor external regulations via third-party content provider feeds, and involve business-line representatives in the impact assessment via streamlined workflows.
    • Associate regulations and risks with policies and controls so organizations can apply rationalized compliance efforts to multiple regulatory and risk management activities.
    • Utilize eLearning modules that communicate corporate brand and ideals, promote employee education, and comply with legal and regulatory training requirements.
    • Prioritize and manage compliance projects in the context of broader corporate initiatives and resource allocation, balancing profit-driving strategies with regulatory imperatives.

    Real-World GRC Convergence: Platform Considerations - slide 4

    Information Technology (IT) Governance Requirements

    IT governance platforms enable companies to align IT strategy with business needs via IT-centric risk and compliance processes. IT Governance platforms should help organizations:

    • Inventory the IT landscape, including assets, processes, services, applications and infrastructure elements.
    • Prioritize and manage IT projects based on balancing strategic objectives with compliance requirements.
    • Develop, maintain, communicate and monitor adherence to IT policies.
    • Implement standard frameworks, including ITIL, COBIT, ISO27002, PCI, GLBA and HIPAA.
    • Highlight the results of IT risk assessments, incidents and threshold breaches in the context of related business products, services and processes.
    • Develop business continuity plans, including checklists, workflow templates, questionnaires, assessments and planning guidance.
    • Test general computing controls and assess the impact of these controls on key business processes.
    • Remediate issues and risks through action plans and tasks generated through automatic email notifications and workflows.
    • Integrate with third-party IT monitoring tools to identify potential IT vulnerabilities that require remediation.

    Real-World GRC Convergence: Platform Considerations - slide 5

    Financial Controls Requirements

    Financial controls platforms improve corporate governance and facilitate cost-effective compliance with reporting regulations. Financial controls platforms should help organizations:

    • Complete a financial risk-based scoping exercise and prioritize key risks and controls that affect compliance with reporting regulations.
    • Create process, risk and control documentation in a central repository, allowing for analysis of entities, processes and IT systems.
    • Deploy design and operating-effectiveness assessments to control owners through an integrated survey engine to drive accountability and simplify the user experience.
    • Validate controls through independent testing and continuous monitoring, providing assurance about the control environment.
    • Facilitate disclosure certification of gaps and weaknesses through dashboards and reports that compile information based on internal analysis and testing of controls.

    Real-World GRC Convergence: Platform Considerations - slide 6

    Internal Audit (IA) Requirements

    IA GRC platforms help companies integrate IA into their GRC programs. IA platforms should help organizations:

    • Automate the audit process, from risk assessment through reporting.
    • Identify and assess risks through integrated surveys, simplifying the feedback process and tying risks to key processes and organizations feeding the audit planning process.
    • Schedule audits and allocate audit resources based on availability and skills profile.
    • Track projects, report on resource utilization, and manage budgets through time and expense tracking.
    • Manage electronic work papers offline through an audit workbench, including field-level synchronization and conflict management.
    • Remediate issues identified during the audit process and follow them through to completion to ensure gaps are addressed.
    • Compile audit information and create final audit reports quickly, reducing the time and effort required to provide management and the board with key risk information.

    Real-World GRC Convergence: Platform Considerations - slide 7

    GRC Convergence Platform

    Key cross-domain elements of a GRC convergence platform include:

    • Data modeling supports the establishment of a consolidated GRC framework and entity hierarchy within which detailed business records (e.g., objectives, risks, controls, incidents, indicators, action plans) are managed. This core component is used across all GRC domains. Flexibility and configurability of the data modeling architecture are essential in integrated GRC deployments.
    • Content management of individual business records supports authoring, rich-text editing, cross-referencing, tagging, workspace/file collaboration with version control, change history and archiving. This core component is prominently featured in compliance (policy management) and audit management solution areas.
    • Project management is used to manage project scheduling, activities and work papers related to multiple GRC efforts, most notably audit and case management. It is also important for IT project portfolio management and is becoming more useful for the management of regulatory projects stemming from regulatory change management processes.

    Real-World GRC Convergence: Platform Considerations - slide 8

    GRC Convergence Platform

    Key cross-domain elements of a GRC convergence platform also include:

    • Workflow management automates business logic and facilitates enterprise communication, collaboration, notification, accountability and assurance, and review. It is used across all GRC contexts and includes a business rules engine, tasking and notification, and distributed communication.
    • Reporting and analysis capabilities should include several types of reporting formats that provide flexible query analysis and data download capabilities, information summaries, drill-down dashboard reporting, and heavy-text and editable reporting (e.g., via Microsoft Word).
    • Advanced analytics and modeling capabilities include varying degrees of advanced analysis or integration with various operational, transactional and analytical tools used to consolidate analysis within the GRC taxonomy and drive enterprise action planning. Types of advanced and external analytics capabilities include regulatory change management, data analysis, and data modeling and integration.

    Real-World GRC Convergence: Platform Considerations - slide 9

    Core Supporting Architecture

    The key elements of a GRC platform should be underpinned by a core architecture that supports:

    • Configuration to meet unique requirements related to the data model, data input and visualization, and reporting.
    • Data integration for third-party systems via a web-based application program interface (API) as well as automated common-data-format (.xml, .csv) uploads.
    • Data security, typically a role-based security architecture that supports enterprise, entity, record and field-level security. Most vendors also offer lightweight directory access protocol (LDAP) integration and single-sign-on capabilities.
    • Contextualization in order to present different navigation and input screens depending on the context.
    • Multiple language support that translates navigation, field labels, and drop-down categorizations, and provides reporting of results by reading multiple language inputs.
    • High performance relative to a company’s particular use cases.
    • Offline and mobile support for distributed and offsite review processes, e.g., conducting an audit or branch review.

    Real-World GRC Convergence: Platform Considerations - slide 10

    Key Software Evaluation Considerations

    • Configurability: Does “configurability” also require significant customization? How will the vendor manage maintenance and upgrades for the client?
    • Time to value: Can the vendor produce a plan for delivering value for at least two stakeholder groups within six months?
    • Multi-stakeholder integration: Can the vendor produce a plan for providing individual stakeholder groups with their own workspaces devoid of clutter from other stakeholder groups, while also consolidating information into corporate risk profiles? How many modules are required initially and how much will additional modules cost?
    • Development: Can the vendor configure core functionality from licensed modules into new solutions, or will each new targeted solution on the vendor’s development roadmap require additional modules or licensing?
    • Reporting: Can configurations flow through to ad hoc reporting analysis without requiring significant technical effort on the part of the client or intervention by the vendor?
    • Implementation team and customer support: Can the vendor demonstrate its commitment to applying its functionality to a customer’s specific program? What functional guidance is included in the baseline support? How are support resources trained and how is the knowledge gained during implementation transferred to the future support team?

    Latest Articles