SRCSGT | 70 | Integrated Governance, Risk and Compliance Application (iGRC)

FBO DAILY ISSUE OF JUNE 14, 2009 FBO #2757
SOURCES SOUGHT

70 -- Integrated Governance, Risk and Compliance Application (iGRC)

Notice Date: 6/12/2009
Notice Type: Sources Sought
NAICS: 541511 — Custom Computer Programming Services
Contracting Office: Department of the Treasury, Departmental Offices/Procurement Services Division (DO/PSD), Procurement Services Division (PSD), 1425 New York Avenue, Suite 2100, Washington, District of Columbia, 20220
ZIP Code: 20220
Solicitation Number: TOFS-09-S-0012
Archive Date: 7/11/2009
Point of Contact: Nicholas Olson, Phone: 2026229639, Joshua Galicki, Phone: 2026226418
E-Mail Address: Nicholas.Olson@do.treas.gov, Joshua.Galicki@do.treas.gov
(Nicholas.Olson@do.treas.gov, Joshua.Galicki@do.treas.gov)
Small Business Set-Aside: N/A
Description: Solicitation Number: TOFS-09-S-0012 Notice Type: Sources Sought Synopsis: Sources Sought Notice for an integrated Governance, Risk and Compliance Application (iGRC) This is a sources sought notice. This announcement is for market research and preliminary planning purposes. No proposals are being requested or accepted in response to this notice. THIS IS NOT A SOLICITATION FOR PROPOSALS AND NO CONTRACT WILL BE AWARDED AS A RESULT OF THIS NOTICE. No reimbursement will be made for any costs associated with providing information in response to this notice or any follow up information requests. 1 Introduction The Troubled Assets Relief Program (TARP) was established under the EESA with the specific goal of stabilizing the United States financial system and preventing a systemic collapse. This program is managed by the Office of Financial Stability (OFS), which consists of numerous programs that facilitate restoring the flow of credit to consumers and businesses, and tackling the foreclosure crisis to keep millions of Americans in their homes. For a complete list of programs, please refer to the Treasury's Financial Stability the ability Website: http://www.financialstability.gov/roadtostability/programs.htm Additionally, the OFS is comprised of various offices that support the activities of each program. They include the Office of the Assistant Secretary, Risk and Compliance, Finance, Investments, Operations, Chief Counsel, Financial Agent Management, Homeownership Preservation as well as the Capital Purchase Program and the Auto Program. The Office of Risk and Compliance within OFS is seeking an integrated COTS solution to ensure it addresses risks, controls and compliance in a unified and coordinated manner. Commercial and federal best practices call for a disciplined approach to converge the governance, risk and compliance (GRC) functions. Being a start-up organization it is important to avoid white spaces where information is not exchanged and accountability is not established among the various groups. In such situations, each group develops its own standards, methodologies, and bodies of knowledge and best practices. The obvious problem with overlap is inefficiency as these groups often assess the same issues, wasting resources and management time. The purpose of the iGRC is to integrate the responsibilities of the various OFS offices with the aim of creating and maintaining a sustainable framework for consistent risk management and performance improvement flows using an enterprise-wide approach that is consistent, repeatable, and measurable. The application is intended to strategically address the expanding scope of business, operational, financial, regulatory, technology and market risks, eliminate redundancies, improve collaboration across groups, assisting with risk management activities, and address regulatory and other inquiries. Also, an integrated GRC solution such as this will help manage risk at a strategic and operational level addressing requirements of the internal (OFS senior management) and external (Special Inspector General for TARP (SIG TARP), GAO, and the Congressional oversight committees) stakeholders. 1.1 Overview The purpose of this document is to describe the application requirements of the Governance, Risk Management and Compliance (iGRC) System with the objective of developing an integrated application to address the audit, financial controls, enterprise risk, operational risk, IT governance and compliance. The key objectives of this application are to: • eliminate information silos and redundant data, • address regulatory challenges in a holistic manner, • fulfill OFS enterprise risk management goals. • improve collaboration, and • reduce the time and resource costs associated with responding to queries from multiple sources. Essentially, this application will enable OFS to break down the walls between audit, risk and compliance requirements and provide expanded value as the software is deployed across the enterprise. 2 High Level Features The features described below outline the desired functionality for the iGRC at a high level (See Attachment 1 for specific application requirements). The following features layout OFS' Office of Risk and Compliance requirements. The application should provide a modular and integrated approach to governance, risk and compliance, enabling OFS to: • Manage risk and compliance to comply with applicable laws and regulations, • Identify the interdependencies between processes, risks and controls that are shared across departments and business units, • Implement a unified and simplified approach to enterprise risk management to reduce redundancy, minimize complexity and maximize efficiency, Specific components of the application should include: • Enterprise Risk Management: the COTS application should enable OFS to assess strategic risks and objectives across the enterprise, link strategic objectives with enterprise risks, and enhance the decision-making process. In addition, the enterprise risk management functionality should provide a clearer understanding of businesses objectives and associated risks, offer more focused management information, and deliver a better understanding of the trade-offs between risk and reward. In addition, in order to reduce IT-related risks associated with purchasing a GRC application as well as mitigating time-to-delivery risks, the OFS is seeking a CobiT 4.0 framework with a preference towards the newer CobiT 4.1 framework. It is expected that OFS will be able to leverage the CobiT framework and readily adapt their policies and procedures. ISO/IEC 27002 is also an acceptable IT Governance framework if CobiT 4.0 or higher is not adopted. • Compliance: the application should have the ability to manage the costs and complexities associated with adhering to the laws, the regulations and OFS' internal policies and procedures. In addition, it should be able to organize large volumes of content from disparate functional groups and direct the exchange of information between various internal and external stakeholders including regulatory agencies. • Financial Controls: the application should provide accountability and visibility with real time internal controls monitoring and reporting functions. Application should have the ability to streamline documentation and process automation with a flexible framework and allow process and control owners to manage their control environment. • Policies and Procedures: Functionality should include: o Central library of laws/regulations and policies, o Policy lifecycle management, o Collaborative review and authoring, o Top-down policy risk assessment, o Electronic signatures, o Integrated regulatory content. • Performance measurement and management: The application should be able to monitor performance measurements that assess operational and strategic organizational goals. It must do so in a timely, relevant, and concise manner, for all the relevant decision makers. • Operational Controls: The operational risk management functionality should enable OFS to track and quantify risk, reduce the costs and losses associated with risk, and improve and empower business processes by providing greater accountability. The application should offer a consistent and sustainable framework for identifying and managing operational risks resulting from failed processes, people, systems or external events. • IT Governance: The application should establish the control, risk management and oversight of IT related processes and controls. This includes helping provide oversight of the IT practices, assets and resources to demonstrate that risks are managed and corporate objectives are supported and achieved, ensuring the proper use of IT resources. • Reporting: The application should be able to report performance metrics in a dashboard format and also have the ability to generate production and ad hoc reports as needed by the user- community. 3 Key Design Principles Treasury is focusing on the following key design principles in structuring a program to meet these needs: • Information security • Scalability • Ease of use • Ease of system modification • Auditability • Cost effectiveness • Quality assurance • Implementation schedule • Portability 4 Stakeholders It is envisioned that various offices will be key users of this application. These offices include the Office of Risk and Compliance, Office of the Chief Operating Officer, Office of the Chief Financial Officer, Office of the Chief Investment Officer, Office of Chief Counsel, the Middle Office, Program offices such as Capital Purchase Program and the Homeowner Preservation Program. 5 Sources Sought Response Requirements Treasury is interested in structuring a program for iGRC application that maximizes opportunities for small business participation. The purpose of this notice is to gain knowledge of potential solutions, interest, capabilities, and qualifications of prospective offerors for this requirement. Treasury is particularly interested in understanding the capabilities and qualifications of interested small business concerns, including woman- and minority-owned small businesses, and service-disabled veteran-owned small businesses (SDVOSB). Interested vendors are requested to provide a written response to this notice which shall be limited to three pages. The response should include the following: 1. Vendor's name, address, point of contact, phone number, and e-mail address; 2. Vendor's small business size status, including whether the vendor is a woman-owned, minority-owned, or SDVOSB. Applicable NAICS code is 541511. 3. Whether the vendor is interested in working as a prime contractor or a subcontractor, or anticipates significant teaming arrangements*; 4. A description of the vendor's capabilities to meet some or all of the required services; and 5. A recommendation for how to structure a program to meet the needs identified above. * Please Note: Treasury will maintain a list of any vendor that represents that it has an interest in being a subcontractor or part of a teaming arrangement for purposes of any future procurement. The list may be posted at the government point-of-entry (http://www.fedbizopps.gov/) and/or Treasury's web site (http://www.treasury.gov/). As a result, any firm that responds to this sources sought notice should indicate whether it consents to its inclusion on such a publicly-available list. Interested prospective offerors shall respond to this sources sought notice no later than 12:00 Noon ET on June 26th, 2009. Responses shall be sent via e-mail to Nicholas.olson@do.treas.gov and Joshua.galicki@do.treas.gov. Telephone inquiries shall be considered non-responsive. All information in response to this notice must be sent via e-mail. Contracting Office Address: 1425 New York Avenue, Suite 2100 Washington, DC 20220 Place of Performance: Department of the Treasury Office of Financial Stability Washington, DC 20220 Primary Point of Contact: Nicholas Olson Contract Specialist Nicholas.olson@do.treas.gov Phone: (202) 622-9639 Secondary Point of Contact: Joshua Galicki Contracting Officer Joshua.galicki@do.treas.gov Phone: (202) 622-6418 Attachment 1 6 Application Requirements in Detail The following outlines in detail what is required for this application being supplied by the outside vendor. It is expected that the application will be able to perform all events and functionality listed below. 6.1 Platform Below outlines the platform requirements for the application being supplied by the outside vendor. The application shall: 6.1.01 Be a COTS GRC application that will allow a rapid integration of risk, compliance, governance, internal controls, performance management and measurement principles in one integrated package. It is expected that minimal to no coding effort is required in order for the application to be a true COTS package. 6.1.02 Utilize a COSO framework for all GRC requirements 6.1.03 Utilize a CobiT 4.0 or higher frame for IT Governance standards. ISO/IEC 27002 is also an acceptable IT Governance framework if CobiT 4.0 or higher is not adopted 6.1.04 Have the ability to be accessed via web browser over a network utilizing DO's intranet (Microsoft Active Directory) 6.1.05 Store information on US Treasury servers; exact server location and set up to be supplied by the US Treasury. For server configuration, please refer to: http://checklists.nist.gov/chklst_detail.cfm?config_id=221 6.1.06 Be Federal Desktop Core Configuration Compliant (FDCC) - this entails Firewall, Operating System and Web Browser requirements to be dictated by the US Treasury. For further details, please refer to: http://nvd.nist.gov/fdcc/index.cfm 6.1.07 Be able to seamlessly integrate with Microsoft Office 2007 6.1.08 Be able to seamlessly integrate with Microsoft Outlook 2007. This entails synchronization of MS Outlook address books as well as email generation for any US Treasury user 6.1.09 Be able to seamlessly integrate with Adobe Acrobat Reader or Writer (Version 8). 6.1.10 Be scalable for unlimited future functionality. Any known restrictions on functionality to be conveyed by vendor 6.1.11 Be scalable for unlimited future fields. Any known restrictions on number of fields per field type (string, numeric, integer, flag, date, memo, etc) to be conveyed by vendor 6.1.12 Be scalable for unlimited future tables. Any known restrictions on number of tables to be conveyed by vendor 6.1.13 Be scalable for unlimited future dashboards. Any known restrictions on number of dashboards to be conveyed by vendor 6.1.14 Be scalable for unlimited future user groups. Any known restrictions on number of user groups to be conveyed by vendor 6.1.15 Have a documented methodology for vendor and US Treasury to enhance, upgrade and debug application 6.1.16 Have intuitive error messages when human or system errors occur. 6.1.17 Guide the user to the next step required to return functionality and system integrity as error messages occur 6.1.18 Have staging environments available to allow testing of new enhancements, workflow events and functionality 6.1.19 Have the ability to migrate enhancements, workflow events and functionality from the staging environment(s) to production as scheduled by the US Treasury 6.1.20 Have the ability to provide hover text capability to define fields throughout the application so user will know the OFS definition of the field being represented 6.1.21 Have the ability to alias existing fields to be consistent with OFS nomenclature 6.1.22 Have the ability to import information into the application in bulk to expedite the creation of tasks and functionality 6.1.23 Allow multiple instances of the application to be running per user in case they wish to view multiple dashboards/screens at the same time 6.1.24 Allow only one person to edit information at a time 6.1.25 Allow all users to read any information at any point in time regardless if someone else is editing the information 6.1.24 Automatically refresh dashboards as information is changed and saved 6.2 Workflow Elements - Automatic and Manual Below outlines the workflow element requirements for the application being supplied by the outside vendor. The envisioned workflow elements will be supplied by the US Treasury upon reward of the vendor contract. The application shall: 6.2.01 Have the ability to add new workflow elements to all areas of the application as needed; for example a new risk item has been identified - Have the ability to add it easily and track it 6.2.02 Have the ability to easily clone existing workflow elements within the environment 6.2.03 Have the ability to export or list all workflow events occurring in application for auditing purposes 6.2.04 Have manual or automatic email notification as certain events occur 6.2.05 Provide a case management structure for workflow management amongst internal groups 6.2.06 Track transactional information from outside sources for dashboard calculations and reporting 6.2.07 Have the ability to assign a case or event to a user or user group 6.2.08 Have the ability to assign a case or event to multiple users as needed 6.2.09 Have a means of escalating events to a user, multiple users or a user group as needed 6.2.10 Allow date driven events 6.2.11 Allow numeric-value driven events 6.2.12 Allow multiple flag driven events and prioritization based on those flags 6.2.13 Allow pre-populated drop-down lists 6.2.14 Allow the user to type into a drop down list and the list will begin to filter to the value being typed 6.2.15 Allow cascading filters for drop down lists 6.2.16 Allow highlighting of fields as dictated once certain date driven events occur 6.2.17 Allow highlighting of fields as dictated once certain numeric driven events occur 6.2.18 Allow highlighting of fields as dictated once certain flag driven events occur 6.2.19 Have manual button click events such as Edit, Save, Close, Email, Return, Add, etc 6.3 Record Retrieval and Management Below outlines the record retrieval and management requirements for the application being supplied by the outside vendor. The application shall: 6.3.01 Automatically take flat files delivered by the custodian containing financial data. Location of the flat files will be hosted by the US Treasury; exact location to be supplied by the US Treasury 6.3.02 Automatically take XML files delivered by the custodian containing financial data, upload to the system and relay that information to the users. Location of the XML files will be hosted by the US Treasury; exact location TBD 6.3.03 Allow users and different user groups to manually view/add/edit/delete records based on their permissions 6.3.04 Allow users and different user groups to manually view/add/edit/delete documents based on their permissions 6.3.05 Allow the aggregation and calculation of data across tables as needed. Calculations and aggregations to be supplied by the US Treasury 6.3.06 Allow unlimited comments against any record within the application 6.3.06 Keep track of latest comment as well as previous ones 6.4 Document Retrieval and Management Below outlines the document retrieval and management requirements for the application being supplied by the outside vendor. The application shall: 6.4.01 Retrieve documentation being housed in Microsoft SharePoint. Documents may take any MS Office application format as well as Adobe file formats 6.4.02 Allow users to create and/or upload documents to the Microsoft SharePoint document library 6.4.03 Allow users to create 'Save As' versions of any document in the Microsoft SharePoint document library 6.4.04 Systematically tag new documents being saved to the Microsoft SharePoint document library with all required fields. Required document library fields to be supplied by the US Treasury 6.4.05 Be able to consistently apply naming conventions to each document saved to the Microsoft SharePoint document library. Naming convention pr document to be supplied by the US Treasury 6.4.06 Generate workflow events against outside documentation in order to categorize and quantify the document received 6.4.07 Generate workflow events against outside documentation that has been categorized and relay that information to various teams within OFS 6.4.08 Have the ability to export list of documents be stored in the Microsoft SharePoint document library and any data tags associated with each file 6.4.09 Allow fields or tags within documents to be queried or leveraged by other areas of the application for audit, performance or tracking purposes 6.4.10 Automatically version documents to keep track of changes made 6.4.11 Provide a summary of what sections or fields were changed within the document 6.4.12 Provide a method of retrieving all versions of a document from within the application 6.5 Auditing Below outlines the auditing requirements for the application being supplied by the outside vendor. The application shall: 6.5.01 Maintain an audit trail against fields specified by the client; field list that will be audited will be supplied by the US Treasury 6.5.02 Maintain an audit trail of required fields in a grid view for presentation purposes 6.5.03 Allow the audit trail to be exported to Excel, PDF or Word upon request. The export must be formatted in the same grid view presented within the application for audit comparison purposes 6.6 User Access Rights Below outlines the user access requirements for the application being supplied by the outside vendor. The actual user access groups will be supplied by the US Treasury upon reward of the vendor contract. The application shall: 6.6.01 Require system log-in credentials per user 6.6.02 Allow 3 log-in attempts before system lockout 6.6.03 Will allow a period of 15 minutes of no activity before logging the user out automatically 6.6.04 Grant admin access rights to certain users at client for user permissioning and setup 6.6.05 Allow different user groups with different permissioning rights 6.6.06 Have permissioning rights at the dashboard level per user group 6.6.07 Have permissioning rights granular enough to permit certain fields on a dashboard to be write, while other fields be read only per user group 6.6.08 Have permissioning rights allowing viewing access rights for various documentation in document library per user group 6.6.09 Have permissioning rights different viewing access rights to different reports per user group 6.6.10 Have the ability to export user groups which users are associated with each user group for audit purposes 6.6.11 Not allow unregistered users into the application 6.6.12 Track unsuccessful log-ins as well where they are being attempted from 6.6.13 Keep user IDs in the application indefinitely unless approved and manually removed 6.7 Dashboards Below outlines the dashboard requirements for the application. The actual dashboard design and layout will be supplied by the US Treasury upon reward of the vendor contract. The application shall: 6.7.01 Be menu-driven per user group to the maximum extent possible. 6.7.02 Allow user friendly interactions with the system via pre-populated dropdowns menus, autosuggest textboxes, type-ahead textboxes and type-ahead dropdown menus. 6.7.03 Allow various formats per field contingent on dashboard requirements including decimal precision, date formats, comma delimited, etc 6.7.04 Be able to provide a detailed dashboard of real time financial data per institution; dashboards and fields per dashboard TBD by client. 6.7.05 Be able to provide a detailed dashboard of historical financial data per institution; dashboards and fields per dashboard TBD by client. 6.7.06 Be able to provide a detailed dashboard of static institution information; dashboards and fields per dashboard TBD by client. 6.7.07 Allow users to export information from dashboard into Excel, PDF or Word format. Formats per dashboard TBD. 6.7.08 Allow users to add/edit/delete/save/view information on dashboards as dictated by user group permissions. 6.7.09 Allow users to upload and tag new documents to document library. 6.7.10 Allow most current comment against record(s) being shown contingent no dashboard set up. 6.7.11 Allow all comments against record(s) being displayed. 6.8 Reporting Below outlines the reporting requirements for the application. The actual report design and layout will be supplied by the US Treasury upon reward of the vendor contract. The application shall: 6.8.01 Allow the design of new defined reports. 6.8.02 Allow users within user groups to have their set of defined reports. 6.8.03 Allow unlimited number of report templates for each user group. 6.8.04 Allow users to modify the defined reports aspects. The report aspects include the header, footer, fields displayed, sorting, grouping, summations, and numeric formatting such as commas and decimal precision and font formatting such as size, bolding, underlining and italicizing. 6.8.05 Allow users to create ad hoc reports. 6.8.06 Allow reporting on all fields deemed necessary; list of reportable fields for each office to be supplied by the US Treasury. 6.8.07 Have the ability to export reports to MS Word, Excel or PDF. 6.8.08 Have the ability to interact with other reporting mechanisms such as Crystal reports. 6.8.09 Have the ability to create additional calculations on fields as needed. 6.8.10 Have the ability to design charts and graphs for summary level reporting.
Web Link: FBO.gov Permalink
(https://www.fbo.gov/spg/TREAS/DOPSD/PSD/TOFS-09-S-0012/listing.html)
Place of Performance: Address: Department of the Treasury, Office of Financial Stability, Washington, District of Columbia, 20220, United States; Zip Code: 20220
Record: SN01843751-W 20090614/090612235813-5d4f68abcc2e4a826cfaeac1314fa062 (fbodaily.com)
Source: FedBizOpps Link to This Notice
(may not be valid after Archive Date)

| FSG Index | This Issue's Index | Today's FBO Daily Index Page |

Loren Data's SAM Daily™

70 -- Integrated Governance, Risk and Compliance Application (iGRC)