view foster care licensing system · web viewdevelopment platform force.com workflow management...

NOTICEThis opportunity is being released to Contractors pre-qualified as a result of Salesforce RFP #0A1194. Only Contractors pre-qualified for Supplement 2 are eligible to submit proposal responses and to submit inquiries. The State will not respond to inquiries submitted by organizations not pre-qualified under RFP 0A1194.

An alphabetical listing of Contractors pre-qualified to participate in this opportunity are as follows:

Supplement Two Contractors

Accenture

CGI

Coastal Cloud

DevCare Solutions

EightCloud

Persistent Systems, Inc.

Sogeti USA, LLC

Vertiba

E N T E R P R I S E I T C O N T R A C T I N G | S OW S o l i c i t a t i o n 1

Solicitation of Work (SOW)

State of Ohio

Department of Job and Family Services

Project Name: Foster Care Licensing System

Project Solicitation of Work

Solicitation ID No.Solicitation Release Date

SFJFS-18-00-001 5/2/2018

Section 1: Purpose

The Ohio Department of Job and Family Services (ODJFS) is soliciting proposals to identify a Department ofAdministrative Services (DAS)-Office of Information Technology (OIT) Request for Proposals (RFP) 0A1194 pre-qualified Contractor who will supply the services as stated within this Solicitation of Work (SOW).

This solicitation is for pre-qualified Contractors under Contract 0A1194.

Table of ContentsSection 1: PurposeSection 2: General Solicitation InformationSection 3: Scope of Work and ConditionsSection 4: Deliverables ManagementSection 5: SOW Response Submission RequirementsSection 6: SOW Evaluation CriteriaSection 7: SOW Solicitation ScheduleSection 8: Inquiry ProcessSection 9: Submission Instructions and LocationSection 10: Limitation of LiabilitySection 11: Insurance Terms

Attachment 1: Statement of Work and RequirementsAttachment 2: JFS – DAS Security Supplement Addendum


Section 2: General and Solicitation Information

2.1 Agency Information

Agency Name Ohio Department of Job and Family Services

Contact Name Maureen Ahern-Wantz Contact Phone 614-387-8810

2.2 Project Information

Project Name Ohio Foster Care Licensing (OFCL)

Expected Project Duration

The expected duration of this project is from 6/19/18 – 1/17/19 and the contractor based on their experience in developing Salesforce application of this type may propose an alternative schedule and timeline.

2.3 Contractor’s Work Effort RequirementThe Contractor’s team (as contracted with subcontractors, if applicable) must perform 100% of the effort required to complete the Work of which no more than 70% can be subcontracted.

2.4 Ohio Certified MBE Set-Aside Requirement

As part of our objectives on this Project, the State is committed to improving the number of minority-owned enterprises that do business with the State of Ohio. A "minority-owned enterprise" is an individual, partnership, corporation or joint venture of any kind that is owned and controlled by U. S. Citizens and residents of Ohio, who are and have held themselves out as members of the following socially and economically disadvantaged groups: Blacks, American Indians, Hispanics and Asians.

While it is not a condition of award of the SOW, the Contractor must use its best efforts to seek and set aside work for Ohio certified minority business enterprises (MBEs). The MBE must be certified by the Ohio Department of Administrative Services pursuant to ORC 123.151. For more information regarding MBE and MBE certification requirements please refer to the DAS Equal Opportunity Division Web site at:

http://das.ohio.gov/Divisions/EqualOpportunity/MBEEDGECertification.aspx

In addition, to search for Ohio MBE-Certified Providers, utilize the following search routine published on the DAS Equal Opportunity Division website:

Select “MBE Certified Providers” as the EOD Search Area selection;

On the subsequent screen, at minimum, select the appropriate Procurement Type, e.g., “Information Technology Service” as a search criterion;

Select “Search”; and

A list of Ohio MBE Certified Service Providers will be displayed.

Section 3: Scope of Work and Conditions

3.1 See Attachment 1

Assumptions System will be configured and developed in one engagement.


http://das.ohio.gov/Divisions/EqualOpportunity/MBEEDGECertification.aspx

Section 3: Scope of Work and Conditions

The Contractor is expected to revise and or modify previously approved and accepted functions, documentation and related code due to iterations within subsequent sprints that discover the need to modify previously accepted deliverables for the application. These changes will not be considered or subjected to a change order that results in increased costs for the project. Changes that impact the project timeline will be reviewed with the State and the schedule adjusted as mutually agreed upon.

3.2 Work Location(s)ODJFS will provide cubicle space as mutually agreed upon with access to network connections, desktops, and access to printers.

3.3 Detailed Description of Deliverables1. Deliverables must be provided on mutually agreed upon dates. Any changes to the delivery date must have prior

approval (in writing) by the Agency contract manager or designate.

2. All deliverables must be submitted in a format approved by the Agency’s contract manager.

3. All deliverables must have acceptance criteria established and a time period for testing or acceptance.

4. If the deliverable cannot be provided within the scheduled time frame, the Contractor is required to contact the Agency contract manager in writing with a reason for the delay and the proposed revised schedule. The request for a revised schedule must include the impact on related tasks and the overall project.

5. A request for a revised schedule must be reviewed and approved by the Agency contract manager before placed in effect.

6. The Agency will complete a review of each submitted deliverable within specified working days of the date of receipt.

7. A kickoff meeting will be held at a location and time selected by the Agency where the Contractor and its staff will be introduced to the Agency.

Deliverable Name Deliverable Description

1. Analysis of eLicense Ohio code and framework and Project Plan, Project Schedule and Weekly Status Reports

1. Conduct an Analysis of eLicense Ohio code and framework to leverage the existing code base and build Foster Care Licensing system using the technology stack as described on attachment #1.

2. A proposed iteration/sprint plan must be used to create a consistent, coherent management plan of action to guide, control and execute the Project.

3. The plan must contain detail, sufficient to provide an understanding of how the Project will be managed, document planning assumptions, facilitate communication, define key review points, and provide a baseline for schedule control.

4. The project schedule must be updated in conjunction with the weekly and monthly reporting requirements throughout the project.

5. Weekly meetings must be conducted and Project Status Reports must be presented to the project team, Office of Information Services (OIS) and Bureau of Foster Care



Licensing project managers on the first Monday of each week.

6. The reports must follow a preset agenda and must include at a minimum documentation of the progress, accomplishments, outstanding issues, issue resolution, next steps and risks.

7. All electronic status reports must be stored in a SharePoint project repository, using version control, indexing, and storage of all communications media, and must be accessible by ODJFS staff.

8. Meeting status reports must contain, at a minimum, descriptions of the following:

a. An Executive Summary;

b. Any issues encountered and their current disposition;

c. Anticipated tasks to be completed in the next week;

d. Tasks percentage completed between 0% and 100%;

e. Updated Project schedule;

f. A list of all change requests;

g. Updated risk and mitigation planning.

9. The Contractor’s proposed format and level of detail for the status report will be subject to State approval.

2. System Documentation

Design documentation must contain at a minimum the following sections:

1. Requirements Specification Document1. The Contractor must develop and maintain a System Requirements Specification

Document.

2. This System Requirements Specification Document must include system functional, and non-functional requirements (e.g., quality attributes, legal and regulatory requirements, standards, performance requirements, and design constraints).

3. The base requirements must be further refined to arrive at the detailed design requirements and traced throughout the system development life cycle.

4. The Contractor must conduct requirements and (/or) user stories refinement sessions to finalize requirements and ensure that responses to all the requirements are acceptable to ODJFS;

5. The Contractor must evaluate and document future state business processes that are identified as part of the detailed requirements gathering.

6. The specification for each requirement must include a means of measuring that the requirement has been satisfied. This measurement will be used to generate the necessary test cases for system and acceptance testing

2. Architecture and Infrastructure The Contractor must provide description of all the hardware, system software and tools necessary for the deployment of the system. Provide logical and physical architecture diagrams depicting the different components of the system that interface with one



another.

3. Requirements Traceability Matrix The Contractor must develop and maintain a requirements traceability matrix to track all requirements. Requirements must be tracked throughout the project from requirement specification through production implementation utilizing a tool approved by ODJFS. The primary objective is to ensure continuity and detail tracking of requirements to system functionality.

4. Data DesignThe Contractor must provide logical data model and data attribute definitions and related use cases.

5. Business Process/Workflow Management The workflow documentation must be detailed and comprehensive enough to clearly define how the system will function.

6. Design, Configuration, Reporting and Integration DocumentThe Contractor presents the final designs and configuration specifications that, at a minimum, include: key processes and workflows, user interaction and user interfaces, user input edit/validation, reporting, and any required interfaces.

The reporting specifications must include report definitions to be generated within the Salesforce environment to meet fundamental and basic reporting requirements supporting federal and state reporting requirements.

Develop specifications and recommendations for business intelligence analytics.

7. System Test and User Acceptance Test1. Test scenarios must be developed with ODJFS’ assistance.

2. All defect tracking and resolution must be documented.

3. Security Plan 1. The Contractor must utilize the OIT Identity management service for employees and providers.

2. This plan must include, among other things, details describing the system’s adherence to and compliance with ODJFS’ security regulations, policies, and procedures, security aspects of the system’s physical architecture, detailed descriptions of all user access roles and their corresponding security levels.

3. This plan must receive final approval from the ODJFS System Security Officer. All updates and revisions to the plan must be approved by the State.

4. Deployment Plan 1. The Contractor must develop a Deployment Plan that details how the system will be deployed.

2. The Plan must contain user documentation, deployment process and state staff training.



5. Software Configuration & Release Management Plan

1. The Contractor must incorporate the use of configuration processes using mutually agreed upon standards, conduct reviews, develop audit trails and release controls.

2. Contractor’s configuration must include the creation and testing for procedures and job scheduling requirements for systems operation.

3. The Contractor must configure solution components to support approved design.4. The Contractor must complete Configuration and customization of solution user

interfaces.5. The Contractor must provide Configuration and customization of solution reports and

forms.6. The Contractor must configure and customize any integration components and

interfaces to external systems;7. The Contractor must utilize build, prototyping and test environments as required to

perform the development work. 8. The build environments must be designed and maintained by the Contractor so that

build activities will not adversely affect the production environment and otherwise be representative of the production environment to minimize issues associated with production release of the solution.

9. The Contractor must perform unit test for solution components and assess quality and completeness of results.

10. The Contractor must document solution and refine applicable acceptance criteria as mutually agreed upon.

11. The Contractor must compile and maintain issue lists, risk and action lists for resolution.

12. The Contractor must develop the Application in accordance with the State’s strategies, principles, and standards for security, data management, systems design and architecture.

13. Contractor must contribute to the ongoing development of such strategies, principles and standards through, at a minimum, advising the State of developments in technology which may be applicable to the State’s business requirements.

14. The Contractor must conduct Build progress reviews with appropriate State personnel.

6. Environment Setup 1. Contractor must consider using the existing ODJFS Salesforce ORG for this solution. If the Contractor determines that the current ORG does not support the development then they must provide documentation defining the reasons why the current ORG will not support the application and will be responsible for creating at a minimum DEV, SYS, UAT, PROD orgs.

2. Develop plan to migrate the code to OIS Code repository.

7. System Test Plan The Contractor must develop the System Test Plan that includes, at a minimum, the following:

1. The scope of the tests including regression testing, load testing and balancing that clearly describe how the plan will fully test the system functions, features and performance.

2. The inputs to the test, performance testing scripts, the steps and procedures in the testing process, timelines and the expected results.

3. A description of the Contractor and State staff roles and responsibilities during testing.



4. Test Plan must identify the approach used for defect identification, tracking and resolution.

5. All test scripts must be fully automated using HP Unified Functional Tester (UFT).

8. Conduct System Testing

The Contractor must test all system functionality as per documented test scenarios. System testing must occur in an established test environment that mirrors the production environment. To complete System Test the Contractor must perform the following:

1. Execute the system test plan.

2. Function as system users during system testing and evaluate and validate all test outcomes.

3. Provide system output and test outcomes to ODJFS project staff as requested.

4. Analyze and evaluate performance of all systems, hardware, and software.

5. Perform all system modifications required to ensure system performance meets the approved requirements.

6. Document and resolve any defects encountered during system testing. If major defects are found during system testing, the entire test script must be re-initiated and the test period must begin again (e.g., a major defect is anything that stops the system/application from functioning or fails to deliver required functionality).

7. Provide adequate staff dedicated to testing support and problem resolution.

8. The Contractor must maintain a defect and resolution log within ALM.

9. System Test Results Document

1. System Test Results document must include all system test results and system recommendations.

2. The document must contain sufficient information to permit ODJFS to validate that the test has been successfully executed in accordance with the approved system test plan. The tests performed must prove that the system meets the approved requirements. All defects encountered during the system test and their resolutions must also be reported in the system test results document.

3. Systems test must include performance testing that measures response time for online and batch processes and must ensure that response time and or processing time is acceptable to the State as mutually agreed upon.

4. If test results are deemed unacceptable by ODJFS, the Contractor must make modifications to appropriate systems and repeat the testing and approval process.

10. User Acceptance Test Plan

Contractor must develop, with assistance from ODJFS, a UAT plan that includes, at a minimum, the following:

1. A description of the Contractor and State staff roles and responsibilities during testing.

2. The scope of UAT, which includes the inputs to the test, the steps and procedures in the testing process, timelines and the expected results.

3. A description of the defect identification and resolution processes to be executed



during UAT.

11. Conduct User Acceptance Testing

The user acceptance testing (UAT) must verify the full functionality and technical usability of the system;

1. Contractor responsibilities for UAT include managing and supporting the user acceptance testing.

2. Contractor must train all designated State staff for successful execution of User Acceptance Testing.

3. The Contractor must utilize relevant Ohio test data to execute the user acceptance test.

4. The Contractor must analyze and evaluate performance of all systems.

5. The Contractor must document, track, remediate and report to ODJFS all defects encountered during UAT. If major defects are found during UAT, the entire test script must be re-initiated and the test period must begin again (e.g., a major defect is anything that stops the system/application from functioning or fails to deliver required functionality).

6. The Contractor must perform all system modifications required to ensure system meets approved requirements as specified in the System Design document.

7. The Contractor must maintain defect and resolution log using ODJFS standard tools.

12. User Acceptance Report

1. The UAT Final Report must contain sufficient information to validate that UAT has been successfully executed in accordance with the approved UAT plan and that the tests performed adequately meet the approved requirements. All defects encountered during UAT and their resolutions must be reported in the UAT Final Report.

2. If test results are deemed unacceptable by ODJFS, the Contractor must make modifications to appropriate systems and repeat the testing and approval process.

13. Training and Implementation

The Contractor must propose either a phased or a single-implementation approach to meet project timelines. The Contractor must develop and complete the training in a manner that ensures training occurs prior to implementation. The Contractor will be responsible for the development and delivery of various methods of training such as but not limited to, Web based online tutorials, electronic documentation (e-documentation), and printed materials. The Contractor will be available for on-site training as determined by ODJFS.

At a minimum, the Contractor activities of this task must include the following;

1. Establish Training plan/schedule.

2. The Contractor must develop a training curriculum for each role.

3. The Contractor must develop a User Manual and training material.

4. Provide training to the Ohio Foster Care Licensing staff approximately 30 members at a ODJFS facility located in Columbus, OH.

5. Provide training to OIS staff for approximately 10 members to enable application



maintenance, testing, configuration & release management.

6. Implementation Plan must demonstrate to ODJFS how the Contractor will implement the system. The plan, at a minimum, must detail the approach for coordinating the following:

a. Implementation approach;

b. Technical preparation;

c. Implementation activities check list; and

d. Implementation schedule.

14. Final Acceptance and Handoff to ODJFS Salesforce team (post development support period commencement)

The Final Acceptance and Handoff to ODJFS Salesforce team must include the following:

1. Completion and Acceptance of all deliverables.

2. Resolution of all Severity 1 and 2 Defects and other defects as mutually agreed with the State.

Severity 1 defect is an issue where the States use of a function in the system has stopped or is so Resolution severely impacted that personnel cannot reasonably continue to work.

Severity 2 defect is an issue that results in partial or intermittent outage or unavailability, causes undue delay in processing that impacts the business cycle, or creates a processing backlog. A temporary workaround exists but does not support the pre-issue processing time.

3. Transition solution support responsibility to ODJFS Salesforce team.

4. Obtain a final acceptance from ODJFS confirming that all of the above has been delivered and solution is accepted.

15. Performance Period and Break / Fix Support

For a period of ninety (90) days following the deployment to production the Contractor must: 1. Track, monitor and provide remediation for solution defects and incidents requiring

system configuration changes.

2. Maintain solution documentation (technical specifications and testing documentation) as well as a compendium of common problems, root causes and remedy to aid in the identification and remediation of underlying system incidents.

3. Conduct all related testing for any configuration changes resulting from defect resolution.

4. Support ODJFS in performing testing or review of any changes arising due to defects and enhancements.

5. Ensure compliance with any State security or SalesForce.com mandated patches and report to the State in writing any risks or issues that the Contractor becomes aware of in providing Service to the State. Patches designed to address immediate or active Security issues may be scheduled for a near-real-time release, where other less pressing releases may be implemented during a scheduled maintenance or outage

E N T E R P R I S E I T C O N T R A C T I N G | S OW S o l i c i t a t i o n 1 0


period.

3.5 Roles and Responsibilities

Project or Management Activity/Responsibility Description

Contractor Agency

Acquisition of software licensing X

Responsible for all aspects of requirements gathering, documenting high-level business processes, use cases, high-level and detailed business requirements and related design documentation.

X

Responsible for all aspects of project management and development to include but not limited to Project documentation such as project plan, status reports, WBS, Gantt charts, schedules, risk assessments, mitigation plans, tracking of timelines and work tasks and scheduling and facilitating meetings.

X

Responsible for all aspects of development, application testing, performance testing, co-ordination of user acceptance testing, defect tracking and problem resolution.

X

Responsible for user acceptance testing and verify requirements have been met. X X

Responsible for deployment, production implementation and training. X

3.6 Restrictions on Data Location and Work

The Contractor must perform all Work specified in the SOW solution and keep all State data within the United States. The State shall reject any SOW response that proposes to perform work or make State data available outside the United States. (off shore)

Section 4: Deliverables Management

4.1 Submission/Format

PM Artifact/Project Work Product Submission Format

Project Delivery Artifacts (Plan, Issues/Risk, Reports)

By Contractor Microsoft Office Suite

Deliverables (non-code based) By Contractor Microsoft Office Suite

Deliverables (code based) By Contractor As Mutually Agreed

Deliverable Acceptance By Contractor Microsoft Office Suite


4.2 Status Reporting 1. The Contractor must provide the Agency contract manager with WEEKLY written progress reports of this project.

These are due to the Agency contract manager by the close of business on FRIDAY each week throughout the life of the project.

2. The progress reports must cover all work performed and completed during the week for which the progress report is provided and must present the work to be performed during the subsequent week.

3. The progress report must identify any problems encountered or still outstanding with an explanation of the cause and resolution of the problem or how the problem will be resolved.

4. The Contractor must be responsible for conducting weekly status meetings with the Agency contract manager. The meetings will be held on MONDAY at a time and place so designated by the Agency contract manager – unless revised by the Agency contract manager. The meetings can be in person or over the phone at the discretion of the Agency contract manager.

4.3 Period of PerformancePerformance period starts at the point of acceptance of production implementation of the agreed upon deliverable for the respective phase. When there are multiple phases the period is from the last phase implemented and any defects or issues identified are subject to remediation by the Contractor irrespective of such defects or issues arising from implementation in a prior phase and which were not discovered. Performance period ends upon a mutually agreed upon timeframe.

4.4 State Staffing PlanThe State will assign Subject Matter Experts as needed and will assign a project manager to assist with the project coordination and efforts that require State assistance.

Staff/Stakeholder Name Project Role Percent Allocated

OFC Deputy Director Project Sponsor 5%

BFCL Bureau chief, Supervisor SME 50%

OIS Relationship Manager 5%

OIS Project Manager Co-Lead 25%

OIS ODJFS Salesforce Lead 20%

Section 5: SOW Response Submission Requirements

5.1 Response Format, Content RequirementsAn identifiable tab sheet must precede each section of a Proposal, and each Proposal must follow the format outlined below. All pages, except pre-printed technical inserts, must be sequentially numbered.

Each Proposal must contain the following:

Cover Letter (include email address)


Pre-Qualified Contractor Experience Subcontractor Letters (if applicable) Proof of Insurance Contract 0A1194 Signature Page Contractor Proposal in Response to the Statement of Work and Requirements (Sections 1 through 4) Assumptions Staffing plan, personnel resumes, time commitment, organizational chart Project Plan & Project Schedule (WBS using MS Project or compatible) Cost Summary Solicitation of Work – (See Statement of Work Section 5)

Cover Letter

The cover letter must include a brief executive summary of the solution the Contractor plans to provide. The letter must also have the following:

Must be in the form of a standard business letter; Must be signed by an individual authorized to legally bind the Pre-Qualified Contractor; Must include a list of the people who prepared the Proposal, including their titles; and Must include the name, address, e-mail, phone number, and fax number of a contact person who has the authority

to answer questions regarding the Response.Pre-Qualified Contractors Experience Requirements

a. Each proposal must include a brief executive summary of the services the Pre-Qualified Contractor proposes to provide and one representative sample of previously completed projects as it relates to this proposal (e.g. detailed requirements documents, analysis);

b. Each proposal must describe the Pre-Qualified Contractor’s experience, capability, and capacity to provide Project Management. Provide specific detailed information demonstrating experience similar in nature to the type of work described in this SOW for each of the resources identified in Section 5.2.

c. Mandatory Requirements: The Pre-Qualified Contractor must possess the following:

The prime Contractor, is prequalified under RFP 0A1194

Subcontractor Letters

This requirement only applies, if Contractor will be working with a subcontractor that was not named as part of its initial response to RFP 0A1194. For each proposed subcontractor, the Contractor must attach a letter from the subcontractor, signed by someone authorized to legally bind the subcontractor, with the following included in the letter:

The subcontractor's legal status, federal tax identification number, D-U-N-S number, and principal place of business address;

The name, phone number, fax number, email address, and mailing address of a person who is authorized to legally bind the subcontractor to contractual obligations;

A description of the work the subcontractor will do; A commitment to do the work if the Contractor is selected; and A statement that the subcontractor has read and understood the SOW and will comply with the requirements of the

SOW.

Proof of Insurance

The Contractor must provide the certificate of insurance in the form that Section 11 requires. The policy may be written on an occurrence or claims made basis.

Contract 0A1194 Signature Page


Any Contractor submitting a response to this Solicitation of Work must submit a copy of its one-page contract signed by the State.

Contractor Response to the Statement of Work and Requirements (Attachment 1, Sections 1 through 3)

These instructions describe the required format for a responsive submission. The Contractor may include any additional information it believes is relevant. The Contractor’s response submission must be submitted using the Microsoft Word® version of the SOW to provide an in-line response to the SOW. An identifiable tab sheet must precede each section of the Proposal. All pages, except pre-printed technical inserts, must be sequentially numbered. Any material deviation from the format outlined below may result in a rejection of the non-conforming Response.

Contractor responses should use a consistent contrasting color (blue is suggested to contrast with the black text of this document) to provide their response to each requirement so that the Contractor response is readily distinguishable to the State. To aid Contractors in the creation of the most favorable depiction of their responses, alternative formats are acceptable that use typefaces, styles or shaded backgrounds, so long as the use of these formats are consistent throughout the Contractor’s response and readily distinguishable from the baseline SOW. Alterations to the State provided baseline SOW language is strictly prohibited. The State will electronically compare Contractor responses to the baseline SOW and deviations or alterations to the State’s SOW requirements may result in a rejection of the Contractor’s response.

Assumptions

The Pre-Qualified Contractor must list all assumptions the Pre-Qualified Contractor made in preparing the Proposal. If any assumption is unacceptable to the State, the State may at its sole discretion request that the Pre-Qualified Contractor remove the assumption or choose to reject the Proposal. No assumptions may be included regarding the outcomes of negotiation, terms and conditions, or requirements. Assumptions should be provided as part of the Pre-Qualified Contractor response as a stand-alone response section that is inclusive of all assumptions with reference(s) to the section(s) of the SOW that the assumption is applicable to. The Pre-Qualified Contractor should not include assumptions elsewhere in their response.

Staffing Plan

Contractor must submit a Staffing Plan inclusive of all Contractor Staff, Contractor Staff locations (e.g., State premise or Contractor premise) and requirements for State personnel involvement for the duration of the project, for each phase of the project, regardless of implementation methodology that includes all requirements elaboration, design, development, system and acceptance testing and production deployment work elements.

Proposed Contractor team inclusive of 1-2 page biographical resumes for all team members that will be on State premise, or interact with State personnel as applicable to perform and complete the Work.

Cost Summary Solicitation of Work

The Contractor’s total cost for the Project must be represented as the Not-To-Exceed Fixed Price.

The State will not be liable for any costs incurred by any Contractor in responding to this SOW. The State may decide not to award a contract at the State’s discretion.

5.2 Additional Requirements

Pre-Qualified Contractors Experience Requirementsa. Each proposal must include a brief executive summary of the services the Pre-Qualified Contractor proposes to


provide and one representative sample of previously completed projects as it relates to this proposal (e.g. detailed requirements documents, analysis);

b. Each proposal must describe the Pre-Qualified Contractor’s experience, capability, and capacity to provide Project Management and provide specific detailed information demonstrating experience similar in nature to the type of work described in this SOW for each of the resources identified in Section 5.2 (d).

c. Mandatory Requirements: The Pre-Qualified Contractor must possess the following:

The prime Contractor, is prequalified under RFP 0A1194

d. Staff Experience and Capabilities

Proposals are to demonstrate significant expertise by assigning staff to key leadership roles for this project. Key positions will require profiles and resumes. The vendor is to, at minimum:

1. Identify, by position and by name, those staff who are considered key to the project’s success such as Project Manager, Technical Lead and others.

2. Document that key staff have at least (degree, discipline, and/or other professional experience). Include resumes of key staff expected to work on the project, education and experience of staff in key positions, based on documentation presented and discussed in the vendor’s proposal.

Candidates offered will be evaluated by JFS according to the position classification and job experience qualifications as follows:

Project Manager

A minimum of 60 months’ full-time experience as a project manager.

Experience as the project manager on a minimum of two projects of similar size and complexity that encompassed the full system development life cycle from initiation through post implementation on a large scale project where one of the projects lasted a minimum of 12 months.

Experience following a standard PM methodology and in using Clarity or Microsoft Project.

Technical Architect

A minimum of 60 months’ full-time experience as a Technical Architect.

Experience as a Salesforce Architect for a minimum of 2 years.

Experience Architecting Mobile Solutions with offline capability using the Salesforce Platform.

Experience with Data Modelling and Data Management for a duration of 2 years.

Experience with cross-platform integration.

Lead Developer

A minimum of 60 months full-time experience as a Lead Developer.

Experience as a Lead Salesforce Developer for a minimum of 2 years on a minimum of two projects of similar size and complexity.

Experience implementing Mobile Solutions using the Salesforce Platform.

Experience developing dashboards and reporting utilizing Salesforce data.

Assumptions

The Pre-Qualified Contractor must list all assumptions the Pre-Qualified Contractor made in preparing the Proposal. If any assumption is unacceptable to the State, the State may at its sole discretion request that the Pre-Qualified Contractor remove the assumption or choose to reject the Proposal. No assumptions may be included regarding the outcomes of


negotiation, terms and conditions, or requirements. Assumptions should be provided as part of the Pre-Qualified Contractor response as a stand-alone response section that is inclusive of all assumptions with reference(s) to the section(s) of the SOW that the assumption is applicable to. The Pre-Qualified Contractor should not include assumptions elsewhere in their response.

Staffing Plan

Contractor must submit a Staffing Plan inclusive of all Contractor Staff, Contractor Staff locations (e.g., State premise or Contractor premise) and requirements for State personnel involvement for the duration of the project, for each phase of the project, regardless of implementation methodology that includes all requirements elaboration, design, development, system and acceptance testing and production deployment work elements.

Proposed Contractor team inclusive of 1-2 page biographical resumes for all team members that will be on State premise, or interact with State personnel as applicable to perform and complete the Work.

Payment Address: The Pre-Qualified Contractor must provide the address to which the State should send payments under the Contract.

Staffing plan, personnel resumes, time commitment, organizational chartIdentify Contractor and sub-contractor staff and time commitment.

Include Contractor and sub-contractor resumes for each resource identified and organizational chart for entire team.

Contractor Name Role Contractor or

Sub-contractor?

No. Hours

Contingency Plan A contingency plan that shows the ability to add more staff with the appropriate subject matter expertise if needed to ensure meeting the Project’s due date(s).

Project Schedule (WBS using MS Project or compatible)Describe the Project Schedule including planning, defining goals, including milestones, and time for writing, editing and revising. Using MS Project or compatible, create a deliverable-oriented grouping of project elements that organizes and defines the total work scope of the project with each descending level representing an increasingly detailed definition of the project work.

Communication Plan Describe the methods to be used to gather and store various types of information and to disseminate the information, updates, and corrections to previously distributed material. Identify to whom the information will flow and what methods will be used for the distribution. Include format, content, level of detail, and conventions to be used. Provide methods for


accessing information between scheduled communications.

Risk Management Plan Describe the Risk Management Plan requirements including the risk factors, associated risks, and assessment of the likelihood of occurrence and the consequences for each risk. Describe your plan for managing selected risks and plan for keeping people informed about those risks throughout the project.

Quality Management PlanDescribe your quality policies, procedures, and standards relevant to the project for both project deliverables and project processes. Show examples of the Quality Assurance and Quality Control for documentation, processes, and procedures.

Fee Structure for each DeliverablePre-qualified Contractors must submit a Cost and expected delivery date for each Deliverable identified in the cost table below:

Cost Element Deliverable Title Scheduled Due Date Cost

The Deliverables and costs identified in this section are based on an iterative approach for implementation and must contain the content that is described below. The contractor based on their experience in developing this application using Agile methodology may propose a different approach for deliverables and timeline.

Deliverable 1 Analysis of eLicense Ohio code and frameworkProject Plan, Project Schedule, Weekly Status Reports

10 Days from Award

Not eligible for payment

Deliverable 2 Security PlanDeployment PlanSystems Test Plan

User Acceptance Plan

Software Configuration & Release Management PlanEnvironment Setup

Salesforce Orgs Document Storage and Retrieval

Document Migration of existing cases from ODJFS FileNet SystemCertify, Re-Certify Agencies Business Functions (Refer Business Capability Model on Pg. 24)Deliver the following information and conduct System Testing and User Acceptance Testing for the Business Functions listed above.

System Documentation System Test Results

User Acceptance Results

Estimated 40 Days from Award


Deliverable 3 Perform Additional Visits, Perform PCSA Reviews, Amendments (Refer Business Capability Model on Pg. 24)Deliver the following information and conduct System Testing and User Acceptance Testing for the Business Functions listed above.



15% of Not to Exceed Fixed Price



Deliverable 4 Address Complaints, Manage Inquiries, Recommend Enforcement, Technical Assistance(Refer Business Capability Model on Pg. 24)Deliver the following information and conduct System Testing and User Acceptance Testing for the Business Functions listed above.





Deliverable 5 Deliver the following information and conduct System Testing and User Acceptance Testing for all the Interfaces.





Deliverable 6 Deliver the following information and conduct System Testing and User Acceptance Testing for Operational Reporting.



Develop specifications and recommendations for Business Intelligence Analytics.



Deliverable 7 Deliver the following information and conduct System Testing and User Acceptance Testing for the On-Site Visits Mobile Application

System Documentation

System Test Results




Deliverable 8 Deliver the following information and conduct System Testing and User Acceptance Testing for the Foster Care Agency Mobile Application





Deliverable 9 Training and Implementation

Training Documentation

Conduct User Training

Conduct OIS Training



Deliverable 10 Final AcceptanceTechnical knowledge transfer


25% of Not to Exceed Fixed


Systems Documentation

Solution Architecture Documentation in Abacus

Overall Solution Description document

Interface management planTraining planData model and data dictionaryWorkflow repository and functional design document

Environment Set up/Modify Salesforce Orgs

Implementation includes the following:Mobile Friendly Web Application Document Storage and Retrieval Conversion of existing FileNet casesBackup & RecoveryCPI & Audit Logging InterfacesReportingTwo Mobile Applications (If included by ODJFS)

Price

Deliverable 11 Performance Period and Break / Fix Support Estimated 263 Days from Award


Not to Exceed Fixed Price $On-Site Visits Mobile Application Implementation OptionsThis deliverable is optional for ODJFS and depending on the offeror’s Cost Proposal ODJFS will decide whether or not to include this deliverable. If this deliverable is not included the duration of the project will reduce accordingly.

Option 1 – Salesforce Field Service Lightning Mobile App $Option 2 – Kony Visualizer and Kony Mobile Fabric $

Foster Care Agency Mobile ApplicationThis deliverable is optional for ODJFS and depending on the offeror’s Cost Proposal ODJFS will decide whether or not to include this deliverable. If this deliverable is not included the duration of the project will reduce accordingly.Use Kony Visualizer and Kony Mobile Fabric for development and implementation.

$


Section 6: SOW Evaluation Criteria

Mandatory Requirements: Accept/Reject

Pre-qualified Contractor or Subcontractor cover letter(s) included in Section 5.1

Pre-qualified Contractor or Subcontractor(s) submitted properly formatted proposal by submission deadline

Scored Requirements Weight Does Not

Meet

Meet Exceeds

Contractor or Subcontractor Summary show(s) company experience in developing Salesforce applications for similar projects.

6 0 5 7

Contractor or Subcontractor Documentation shows that the Technical Architect and the Lead Developer have at least 2 years’ experience on a minimum of two projects developing case management systems of similar size and complexity.

7 0 5 7

Provided three (3) references of projects where the Contractor or Subcontractor provided services and successfully developed and implemented a Salesforce project using Force.com platform for case management system of similar size and complexity.

8 0 5 7

Contractor demonstrates understanding of the requirements detailed in the SOW and the ability to successfully design, build and deploy a Salesforce application.

5 0 5 7

Project approach and timeline proposed demonstrates the ability to complete the project within the desired timeline presented defined by ODJFS.

4 0 5 7

Price Performance Formula. The evaluation team will rate the Proposals that meet the Mandatory Requirements based on the following criteria and respective weights.

Criteria PercentageTechnical Proposal 70%

Cost Summary 30%To ensure the scoring ratio is maintained, the State will use the following formulas to adjust the points awarded to each Contractor.

The Contractor with the highest point total for the Technical Proposal will receive 700 points. The remaining Contractors will receive a percentage of the maximum points available based upon the following formula:

Technical Proposal Points = (Offeror’s Technical Proposal Points/Highest Number of Technical Proposal Points Obtained) x 700

The Contractor with the lowest proposed total Not to Exceed Fixed Price for evaluation purposes will receive 300 points. The remaining Contractors will receive a percentage of the maximum cost points available based upon the following formula:


Cost Summary Points = (Lowest Not to Exceed Fixed Price/Offeror’s Not to Exceed Fixed Price) x 300

Note: On-Site Visits Mobile Application Implementation Options will be excluded from the Not to Exceed Fixed Price for evaluation purposes.

Total Points Score: The total points score is calculated using the following formula:

Total Points = Technical Proposal Points + Cost Summary Points

Note: For evaluation purposes, On-Site Visits Mobile Application Implementation Options will be included by the State when determining the lowest proposed total Not to Exceed Fixed Price.

Section 7: SOW Solicitation Calendar of Events

Dates

SOW Solicitation Released to Pre-Qualified ContractorsMay 2, 2018

Inquiry Period BeginsMay 2, 2018

Inquiry Period EndMay 16, 2018, 8 am

Proposal Response Due DateMay 22, 2018, 3 pm

Section 8: Inquiry Process

Pre-Qualified Contractors may make inquiries regarding this SOW Solicitation anytime during the inquiry period listed in the Calendar of Events. To make an inquiry, Pre-Qualified Contractors must use the following process:

Access the State’s Procurement Website at http://procure.ohio.gov/; From the Quick Links menu on the right, select “Bid Opportunities Search”; In the “Document/Bid Number “field, enter the SOW number found on the first page of this SOW Select “IFP” from the Opportunity Type dropdown; Click the “Search” button; On the Opportunity Search Results page, click on the hyperlinked Bid Number; On the Opportunity Details page, click the “Submit Inquiry” button; On the document inquiry page, complete the required “Personal Information” section by providing:

o First and last name of the prospective Contractor’s representative who is responsible for the inquiry, o Name of the prospective Contractor, o Representative’s business phone number, and o Representative’s email address;

Type the inquiry in the space provided including: o A reference to the relevant part of this SOW o The heading for the provision under question, and o The page number of the SOW where the provision can be found; and

Enter the Confirmation Number at the bottom of the page


Click the “Submit” button. A Pre-Qualified Contractor submitting an inquiry will receive an acknowledgement that the State has received the inquiry as well as an email acknowledging receipt. The Pre-Qualified Contractor will not receive a personalized response to the question nor notification when the State has answered the question.

Pre-Qualified Contractors may view inquiries and responses on the State’s Procurement Website by using the “Bid Opportunities Search” feature described above and by clicking the “View Q & A” button on the document information page.

The State usually responds to all inquiries within three business days of receipt, excluding weekends and State holidays. But the State will not respond to any inquiries received after 8:00 a.m. on the inquiry end date.

The State does not consider questions asked during the inquiry period through the inquiry process as exceptions to the terms and conditions of this SOW.

Section 9: Submission Instructions & Location

Each Pre-Qualified Contractor must submit one copy complete, sealed and signed of its Proposal Response and each submission must be clearly marked “Foster Care Licensing system” on the outside of its package along with Pre-Qualified Contractor’s name. It is the Contractor’s sole responsibility to ensure that all copies and all formats of the technical proposal are identical. Any pages or documents omitted from any or all copies can negatively affect the vendor’s score and possibly result in disqualification. In the event of any discrepancies or variations between copies,

A single electronic copy of the complete Proposal Response must also be submitted with the printed Proposal Responses. Electronic submissions should be on a DVD/CD.

Each proposal must be organized in the same format as described in Section 5. Any material deviation from the format outlined in Section 5 may result in a rejection of the non-conforming proposal. Each proposal must contain an identifiable tab sheet preceding each section of the proposal. Proposal Response should be good for a minimum of 60 days.

The State will not be liable for any costs incurred by any Pre-Qualified Contractor in responding to this SOW Solicitation, even if the State does not award a contract through this process. The State may decide not to award a contract at the State’s discretion. The State may reject late submissions regardless of the cause for the delay. The State may also reject any submissions that it believes is not in its interest to accept and may decide not to do business with any of the Pre-Qualified Contractors responding to this SOW Solicitation.

Proposal Responses MUST be submitted to the State Agency’s Procurement Representative:

Ohio Department of Job and Family ServicesOffice of Contracts and AcquisitionsOhio Foster Care Licensing Project30 E Broad Street, 31st floor Columbus, OH 43215

Proprietary informationAll Proposal Responses and other material submitted will become the property of the State and may be returned only at the State's option. Proprietary information should not be included in a Proposal Response or supporting materials because the State will have the right to use any materials or ideas submitted in any quotation without compensation to the Pre-Qualified Contractor. Additionally, all Proposal Response submissions will be open to the public after the contract has been awarded.

The State may reject any Proposal if the Pre-Qualified Contractor takes exception to the terms and conditions of the Contract.


Waiver of DefectsThe State has the right to waive any defects in any quotation or in the submission process followed by a Pre-Qualified Contractor. But the State will only do so if it believes that is in the State's interest and will not cause any material unfairness to other Pre-Qualified Contractors.

Rejection of SubmissionsThe State may reject any submissions that is not in the required format, does not address all the requirements of this SOW Solicitation, or that the State believes is excessive in price or otherwise not in its interest to consider or to accept. The State will reject any responses from companies not pre-qualified in the Technology Category associated with this SOW Solicitation. In addition, the State may cancel this SOW Solicitation, reject all the submissions, and seek to do the work through a new SOW Solicitation or other means.

Section 10: Limitation of Liability

(Identification of Limitation of Liability applicable to the specific SOW Solicitation. Unless otherwise stated in this section of the SOW Solicitation, the Limitation of Liability will be as described in Attachment Four, Part Four of the Contract General Terms and Conditions.

Section 11: Insurance Terms

The Contractor must provide the following insurance coverage at its own expense throughout the term of this Contract:

Insurance.

Contractor shall procure and maintain for the duration of the contract insurance against claims for injuries to persons or damages to property which may arise from or in connection with the performance of the work hereunder by the Contractor, its agents, representatives, or employees. Contractor shall procure and maintain for the duration of the contract insurance for claims arising out of their professional services and including, but not limited to loss, damage, theft or other misuse of data, infringement of intellectual property, invasion of privacy and breach of data.

MINIMUM SCOPE AND LIMIT OF INSURANCE

Coverage shall be at least as broad as:

1. Commercial General Liability (CGL): written on an "occurrence" basis, including products and completed operations, property damage, bodily injury and personal & advertising injury with limits no less than $1,000,000 per occurrence. If a general aggregate limit applies, either the general aggregate limit shall apply separately to this project/location or the general aggregate limit shall be twice the required occurrence limit. Defense costs shall be outside the policy limit.

2. Automobile Liability: covering Code 1 (any auto), or if Contractor has no owned autos, Code 8 (hired) and 9 (non-owned), with a limit no less than $1,000,000 per accident for bodily injury and property damage.

3. Workers' Compensation insurance as required by the State of Ohio, or the state in which the work will be performed, with Statutory Limits, and Employer's Liability Insurance with a limit of no less than $1,000,000 per accident for bodily injury or disease. If Contractor is a sole proprietor, partnership or has no statutory requirement for workers’ compensation, Contractor must provide a letter stating that it is exempt and agreeing to hold Entity harmless from loss or liability for such.

4. Technology Professional Liability (Errors and Omissions) Insurance appropriate to the Contractor’s profession, with limits not less than $2,000,000 per occurrence or claim, $2,000,000 aggregate. Coverage shall be sufficiently broad to respond to the duties and obligations as is undertaken by Contractor in this agreement and shall cover all


applicable Contractor personnel or subcontractors who perform professional services related to this agreement.

The Insurance obligations under this agreement shall be the minimum Insurance coverage requirements and/or limits shown in this agreement. Any insurance proceeds in excess of or broader than the minimum required coverage and/or minimum required limits, which are applicable to a given loss, shall be available to the State of Ohio. No representation is made that the minimum Insurance requirements of this agreement are sufficient to cover the obligations of the Contractor under this agreement.

The insurance policies are to contain, or be endorsed to contain, the following provisions:

Additional Insured Status

Except for Workers’ Compensation and Professional Liability insurance, the State of Ohio, its officers, officials and employees are to be covered as additional insureds with respect to liability arising out of work or operations performed by or on behalf of the Contractor including materials, parts, or equipment furnished in connection with such work or operations. Coverage can be provided in the form of an endorsement to the Contractor’s insurance.

Primary Coverage

For any claims related to this contract, the Contractor’s insurance coverage shall be primary insurance. Any insurance or self-insurance maintained by the State of Ohio, its officers, officials and employees shall be excess of the Contractor’s insurance and shall not contribute with it.

Umbrella or Excess Insurance Policies

Umbrella or excess commercial liability policies may be used in combination with primary policies to satisfy the limit requirements above. Such Umbrella or excess commercial liability policies shall apply without any gaps in the limits of coverage and be at least as broad as and follow the form of the underlying primary coverage required above.

Notice of Cancellation

Contractor shall provide State of Ohio with 30 days written notice of cancellation or material change to any insurance policy required above, except for non-payment cancellation. Material change shall be defined as any change to the insurance limits, terms or conditions that would limit or alter the State’s available recovery under any of the policies required above. A lapse in any required insurance coverage during this Agreement shall be a breach of this Agreement.

Waiver of Subrogation

Contractor hereby grants to State of Ohio a waiver of any right to subrogation which any insurer of said Contractor may acquire against the State of Ohio by virtue of the payment of any loss under such insurance. Contractor agrees to obtain any endorsement that may be necessary to affect this waiver of subrogation, but this provision applies regardless of whether or not the State of Ohio has received a waiver of subrogation endorsement from the insurer.

Deductibles and Self-Insured Retentions

Deductibles and self-insured retentions must be declared to and approved by the State. The State may require the Contractor to provide proof of ability to pay losses and related investigations, claims administration and defense expenses within the retention. The policy language shall provide, or be endorsed to provide, that the deductible or self-insured retention may be satisfied by either the named insured or the State.

Claims Made Policies

If any of the required policies provide coverage on a claims-made basis:

1. The Retroactive Date must be shown and must be before the date of the contract or the beginning of contract work.


2. Insurance must be maintained and evidence of insurance must be provided for at least five (5) years after completion of the contract of work.

3. If coverage is canceled or non-renewed, and not replaced with another claims-made policy form with a Retroactive Date prior to the contract effective date, the Contractor must purchase "extended reporting'' coverage for a minimum of five (5) years after completion of contract work. The Discovery Period must be active during the Extended Reporting Period.

Verification of Coverage

Contractor shall furnish the State of Ohio with original certificates and amendatory endorsements or copies of the applicable policy language effecting coverage required by this clause. All certificates and endorsements are to be received and approved by the State of Ohio before work commences. However, failure to obtain the required documents prior to the work beginning shall not waive the Contractor’s obligation to provide them. The State of Ohio reserves the right to require complete, certified copies of all required insurance policies, including endorsements required by these specifications, at any time.

Subcontractors

Contractor shall require and verify that all subcontractors maintain insurance meeting all the requirements stated herein, and Contractor shall ensure that State of Ohio is an additional insured on insurance required from subcontractors.

Special Risks or Circumstances

State of Ohio reserves the right to modify these requirements, including limits, based on the nature of the risk, prior experience, insurer, coverage, or other special circumstances.


Attachment 1:

Statement of Work and Requirements

Table of Contents

1. Business Background and Overview........................................................271.1. Background and Introduction...................................................................27

2. Technology Stack..................................................................................293. Solution Requirements...........................................................................30

3.1. Ohio Foster Care Agency Application.......................................................303.2. Ohio Foster Care Agency Application Business Requirements.....................30


1. Business Background and Overview

Background and IntroductionThe ODJFS, Office for Families and Children (OFC), Bureau of Foster Care Licensing (BFCL) develops and oversees the state’s child protective services programs. These include programs that prevent child abuse and neglect; provide services to abused and/or neglected children and their families (birth, foster and adoptive); and license foster homes and residential facilities. BFCL is responsible for ensuring the adequate and competent management of agencies that offer care to children in out‐of‐home settings. BFCL evaluates the fitness of agencies that provide foster care, adoption, and residential services to children and/or their families. Public Children Service Agencies (PCSA), Private Noncustodial Agencies (PNA), and Private Child Placing Agencies (PCPA) are monitored by ODJFS to ensure compliance with administrative, governance, fiscal, child services and treatment, and operational standards as prescribed by the Ohio Revised Code (ORC) and Ohio Administrative Code (OAC). Compliance is measured against applicable Codes that govern the functions for which each agency is certified or approved to operate.

BFCL desires to procure a web-based Ohio Foster Care Licensing System with mobile capabilities to replace the existing system. This new system will enable Ohio’s Foster Care Licensing staff to conduct requisite work activities, store, receive and disseminate information to license Ohio Foster and adoptive agencies.


The following Foster Care Licensing Business Capability Model is provided to Contractors to understand the scope of work involved in developing the OFCL system.


2. Technology Stack

The following Technology Standards listed below needs to be followed:

IT Capability Technology & Technology Platform

Web Brower UI Salesforce Lightning Experience (LEX)

Cloud Platform Salesforce Gov Cloud – Current ODJFS Salesforce Orgs to be considered

Development Platform Force.Com

Workflow Management Salesforce

Mobile Application for Internal Users

Salesforce Field Service Lightning Mobile App Kony Visualizer & Kony Mobile Fabric

Mobile Application for External Users

Custom built using Kony Visualizer & Kony Mobile Fabric

Document Generation & Distribution

Drawloop

Reports & Dashboards SalesforceOrg Checker report

Platform Encryption Shield

Backup ODJFS OwnBackup

CPI Logging Informatica /Oracle

Document Storage and Retrieval Existing ODJFS FileNet Service

Requirements Management / Quality AssuranceIntegrated System Testing

Microsoft Visual Studio Team Foundation Server or Atlassian JIRA & Confluence

Version Control (Code Repository) & Deployment

Git (BitBucket) & Jenkins

Application Integration – For all Data inquires and updates to the SACWIS system

IBM Integration Bus

Monitoring ODJFS Splunk & DAS’s QRadar SIEM

Project Documentation SharePoint

Antivirus McAfee

Enterprise Architecture Abacus

Automated Testing HP Unified Functional Tester (UFT)


3. Solution Requirements

Contractor must be responsible for implementing the CPI logging feature for PROD and non-PROD environments. CPI Logging is not a part of the Audit logging capabilities of Salesforce. It is a process developed by ODJFS that utilizes Salesforce custom object, Infomatica ETL and Oracle.

Contractor must be responsible to setup audit logging for monitoring purposes. Contractor must be responsible to work with State security team for implementing the security features. Contractor must be responsible to work with State Database team for implementing the backup and recovery

strategies using Ownbackup backup technology. Contractor is responsible for migrating the software source code using ODJFS’s processes into OIS defined

repository. Contractor is responsible for ensuring that all the software, Salesforce components and any other secondary

software products are implemented in the current version.

Ohio Foster Care Agency ApplicationContractors are required to design and develop a licensee mobile friendly web application and websites(s) that serves the following purpose:

(1) To accept applications from external parties who are interested in providing foster care agency services and allow them to interact with the State in the pursuit of such licenses,

(2) Thereafter, (should a license be granted), follow State required compliance and filing requirements associated with the license, license maintenance, renewals and other facets as of the Ohio Foster Care Licensing Program as required by the State.

1. Ohio Foster Care Agency – The system must provide access to entities for the purpose of applying and reviewing status of licensing application.

2. Bureau of Foster Care Licensing – The system must provide access to enable BFCL to process licensing requests, provide ability to generate correspondences, produce reports to manage and measure program compliance to adhere to BFCL goals.

Ohio Foster Care Agency Application Business Requirements The system must be designed, implemented and deployed to accomplish the following requirements:

3.2.1 Authentication & Authorization

1. The system must display a security notice or banner at the start of the logon process.2. The system must display, upon log-on, the last date and time the authorized user logged onto the system.3. Each user account must have a unique identifier, which may be system generated or user assigned.4. The system must automatically log a user off the system after a pre-defined inactivity period.5. The system must automatically prompt users to change their password based on password management policies.6. The system must provide one central login page for all users.7. The system must allow the system security administrator to set the allowed maximum number of unsuccessful

login attempts before the user account is locked.8. All system authentications must follow State Security standards9. The system must verify a user's identity when completing password management activities such as resets.10. Single Sign-On

Configure Salesforce SAML Federated Single Sign-On settings


Consume the State of Ohio Identity Provider OH IDs (Workforce, Business, & Citizen) for identity and authentication

Provide Salesforce.com start/login and sign out pages for Client use in configuring customer identify provider information

Setup Identity Provider URLs as part of User setup in Salesforce.com Verify/Validate SAML assertions Provide Authorization-Based Assertion Attributes — This will provide SAML 2.0 Token assertions to

determine appropriate authorizations (roles/permissions) for the individual, upon sign-in, based upon supplied SAML attribute(s) (such as group memberships).

Client will provide Single Sign-On Identity Provider and any related Authentication Certificate (DAS) 11. Provisioning/De-provisioning

Application must support a SOAP or REST Service(s) available via Salesforce’s Enterprise API that the Identity Governance Application can call to automatically perform provisioning and de-provisioning tasks. (creating and removing users/identities)

Provisioning Tasks that must be available: • Create, or associate, an identity in the application for authentication and single sign-on. • Assign and Change an identity’s assignment to specific Roles/Permissions within the application for

authorization. De-provisioning Tasks that must be available:

• Delete, or un-associate, an identity in the application to revoke the person’s ability to authenticate. • Remove or alter specific Roles/Permissions per identity within the application to remove

authorization(s).12. The system must allow an authorized user to apply field level security at the user, role, department, direct report,

or organizational level.13. The system must allow an authorized user to create templates for user profiles (i.e. roles) so that individual user

accounts may inherit privileges.14. The system must allow an authorized user to create hierarchical security controls to enforce access to specific

data in the reporting tool applying to ad hoc reporting capabilities: by group of users, individual report, time of day, and/or data element (ex: cannot view data in bank account field, SSN, etc.).

15. The system must allow an authorized user to immediately suspend access temporarily of a certain function to all users due to support circumstances (i.e., all current usage and future usage of the function be halted temporarily until the circumstance is rectified).

3.2.2 Inquiries, License Management & Renewals

1. Inquirers who are interested in providing Foster Care services must have the capability to access the Certification Survey Form from the system without credentials since this is prior to the registration process.

2. Email notification must be generated to notify the Licensing Supervisors of the submission. This data can also be used to generate reports in the system to identify trends.

3. The system must allow an external user to register for system access to the application portal and as part of this registration, create their own User ID and password and submit the application.

4. The system must allow an authorized internal user to capture, store and maintain (adding, modifying, deleting) license information about each license type including, but not limited to: unique ID, licensee name, license description, application form name, application form number and date, link to a downloadable application form, and a link to the on-line application form, when functional.

5. Each license and registration created must have a unique identifier, which may be system-generated or user assigned as defined by business rules.

6. The system must allow an authorized user to add, edit and deactivate entities and their related licenses.7. When establishing a new entity or individual the system must be able to perform a search using name, address

and related information to determine if the entity or individual already exists within the system to avoid generating duplicates. When a match is found from the search, the system must allow an authorized user to choose the existing record.


8. The system must be able to store an unlimited number of addresses associated with a licensee or registrant; the system must maintain the previous address of each agency as defined by business rules.

9. The system must maintain current and historical records for all past and present licensees, including record of all license applications, renewals, and updates by date and license type.

10. The system must allow an authorized user to issue or terminate a license to an entity as defined by business rules.

11. The system must allow an authorized user to update the status of a license at any point in the license period.12. The system must identify incomplete, un-submitted applications that have had no activity for a predetermined

period of time and notify the applicant that the application will be closed if not completed within a specified period.13. For a group of shopping cart transactions initiated by a licensee, the system must process each transaction

independently such that the processing of one transaction does not affect the processing of another transaction, and such that each transaction is represented to the department as if it occurred independently.

14. The system must prompt the user to verify all associated addresses when the Licensee changes an address associated with their license.

15. The system must maintain license types for foster care agencies.16. The system must allow an authorized user to search, sort, filter, and view licenses.17. The system must maintain and display an ongoing history of changes including, at a minimum:

the date of change; the change (add, modify, or delete); the user initiating the action; the reason for change.

18. For all online application licensees, the system must default to "yes" so all applicants are enrolled for opt in email communications.

19. The system must have the capability to store appointments that must be pushed to Outlook and the mobile app.20. The system must allow an authorized user to modify the system terminology (for example, titles and labels on

screens and or forms), thus empowering them to reflect the updates to Ohio administrative code and (or) Ohio revised code.

21. The system must allow an authorized user to define license and registration renewal rules for each license and registration type including: Time period that the license is valid for; Time period prior to expiration date to trigger renewal notifications; Time period that the application is available to applicant; Renewal limits;

22. The system must send Notifications to the agencies prior to license expiration based on user defined parameters. 23. The system must allow an authorized user to generate additional renewal notices at user-defined time periods if a

license or registration has not been renewed within a specified time period, as defined by business rules.24. When the license is closed, the system must generate mail / email notifications to the Agencies.25. The system must either notify the user or must trigger a workflow when entered information does not match

existing information already stored in the system as defined by business rules.26. The system must enforce the integrity of submitted data by utilizing data input masks and calculating amounts on

user input screens to support the entry and submission of correct and adequate information.

3.2.3 Documents & Files

1. The system must be developed to allow the authorized users to perform the following functions by utilizing the existing ODJFS FileNet service. Delete documents, files, records, action items or rename documents. Retrieve and view stored documents. Specify the maximum file size and the file types accepted as attachments. Store photos of licensees and display with the licensee record as defined by business rules. Rename attachments. Retrieve and send authorized documents in response to an Ohio Public Records Act request and perform

overlay redaction as needed. Categorize all license-related documents, images, and audio/video files.


View history for each document (in all areas of the system) including when uploaded, modified, accessed, deleted, and include date and user identification.

Categorize a document as sensitive and prevent all but specifically authorized users to view, retrieve, save, or send due to sensitive or confidential information.

Hide specific data items, such as personal identifiers, on application documents for blind review by the department or others.

2. The system must perform virus scans on all external files.3. Document retrieval and upload performance must be within acceptable limits per industry standard.4. The existing cases that reside in the ODJFS FileNet application must be migrated to the new system. The existing

case documents must continue to reside in FileNet. The vendor is required for conversion activities which includes data scrubbing and formatting. They are to work with the ODJFS FileNet team for this conversion effort.

3.2.4 Application & Data Integration

1. Background check Interface: The Foster and Adoptive Caregivers, Direct care Staff and Administrators perform background check prior to

employment at an agency or sheriff or a different organization. The request for background check information is then sent to the AG’s office for processing.

The system must allow, tracking of requests to the AG office for background checks and must allow storing the results returned from the AG’s office.

The AG’s office will send the background check results to the Agency and the OFCL system must allow the Agency to upload the background check results.

The system must not allow employment or approval/certification until the requested background check is complete.


2. SACWIS Interface: The OFCL system allows the Inquirers to apply for Initial Certification by uploading the documents and

creating the application online. After the review process is completed successfully, the certificate is created and stored in the OFCL system. The system must export the license span and license type of Foster Care agencies to SACWIS. SACWIS must then assign an Agency Provider id and send it to OFCL system.

The OFCL system allows the licensed Foster Care Agencies to apply for Re-Certification online. After the review process is completed successfully, the certificate is generated with the new license span and stored in the OFCL system. The system must export the license span and license type of Foster Care agencies to SACWIS.

If a ban is placed for 5 years during the Initial Certification process, SACIWS is not notified of the ban since the provider id may not exist if the inquirer is applying for certification for the first time. In this case, the ban information is stored in OFCL system only. During the Re-Certification process, if a ban is placed then this information is sent to SACWIS.

If a temporary license is issued, then the license span is a maximum of 364 days and SACWIS is notified the license span and type.

The license span and license types must be captured in the OFCL system and automated expiration notices must be sent to the agencies via email or mail as a reminder to re-apply for certification.

All Data Integration with the SACIWS database must utilize IIB.


3. Ohio Administrative Code (OAC) & Ohio Revised Code (ORC) website Interface: The system must integrate with Lawriter and eManuals and display the current and previous versions of OAC

and ORC as a reference within the OFCL system. The system must display the current OAC and ORC regulations on the On-Site review forms and record

review forms corresponding to the review questions. This enables the licensing specialists to accurately determine compliance for the specific item.

3.2.5 Enforcement

1. After the Specialists conduct on-site reviews, if a corrective action plan is needed then the system must allow an authorized agency user to submit corrective action plans and compliance statuses for each case.

2. The system must allow an authorized user to maintain violations, corrective actions, and disciplinary actions for a licensee or entity.

3. The system must manage compliance data and compliance process workflows for compliance activities as defined by business rules.

4. The system must notify the department and the licensee or registrant of an overdue compliance action.5. The system must allow an authorized user to maintain pre-hearing and post-hearing actions such as proposed

adjudication orders, adjudication orders, certified mailings, appeal letters, court entries, and any other documentation associated with the enforcement process.

6. The system must allow an authorized user to assign individuals as members of an investigation committee.7. The system must allow an authorized user to maintain hearing information for each session of the hearing

including date, participants and results.8. The system must prevent final adjudication orders from being modified based on user-defined business rules.9. The system must allow an authorized user to view previous inspection/investigation information for a selected

applicant/customer.10. The system must allow an authorized user to maintain tracking logs for enforcement actions performed (i.e. five-

year ban).11. The system must allow an authorized user to maintain workflows specific to cases.


12. The system must automatically route hearing results or pertinent communications to the relevant party as defined by business rules.

13. Each case must have a user-defined unique identifier, as defined by business rules.14. The system must associate each enforcement activity to an agency or and/or its licensed providers.15. The system must allow an authorized user to close a study.16. The system must allow an authorized user to provide the reason an agency was closed.17. The system must track the timeframe for which an agency is prohibited from ODJFS licensure.18. The system must capture the dates associated with each enforcement activity in order for an authorized user to

search, display and request reports.19. The system must restrict access to certain fields of case information based upon the access privileges of the

authorized user viewing the case.20. The system must maintain a complete history of enforcement activities.21. The system must allow an authorized user to review enforcement history based on user-specified criteria such as

address or agency.22. The system must allow an authorized user to manage all activities including submission of corrective action plans

and compliance statuses for each case associated with the enforcement process.23. The system must allow an authorized user to trigger an interactive workflow to process and approve enforcement

information as defined by business rules.24. The system must capture compliance data upon inspections and automate compliance process workflows as

defined by business rules.25. The system must send email notifications to the department and the licensee or registrant of an overdue

compliance action.26. The system must track enforcement history from the time the BFCL notifies the enforcement officer of the decision

to seek revocation or denial of a certified agency or applicant or an agency notifies the enforcement officer of its decision to seek revocation or denial of a foster caregiver or applicant and when the enforcement action is completed.

3.2.6 Mobile User AccessInternal Users (State Employees)

1. The system must allow licensing specialists to view, capture, store, print, scan, and maintain licensee and/or registrant compliance information in the system using a wireless internet-enabled mobile computer or handheld device.

2. The system must allow an authorized user to record inspection or compliance information on a mobile device and provide the necessary validations.

3. The system must allow an authorized user to suspend an inspection or compliance activity and save the entered compliance information on a mobile device as work in progress.

4. The system must allow an authorized user to schedule the follow-up appointments that are displayed in the Calendar App from the field using a mobile device.

5. The mobile app must generate the following push notifications: When the foster care agencies send correspondences to their assigned licensing specialist When the licensing specialist’s complete activities requiring supervisor approval, send notification to the

supervisorNotifications can be added or deleted based on the requirements gathering sessions.

6. The mobile app must enable the licensing specialist to locate foster care homes using the Maps App and help navigate to the offsite location.

7. The mobile app must have the capability to speed up the process of uploading photos by accessing the camera app after consolidating them using Cam Scanner App.

8. The system must allow remote field staff to print notices, violations, and licenses using a wireless internet-enabled mobile computer or handheld device via Wi-fi and Bluetooth.

9. The system must allow inspected licensees the ability to digitally sign to acknowledge the receipt of an inspection report using the mobile device to capture the signature.

10. The Mobile Application must provide the necessary performance monitoring features as approved by ODJFS such as page load times and crash diagnostics.

11. The necessary reports on behavioral analytics must be provided which enables ODJFS to determine the features that are being utilized frequently.


12. The Mobile Application must support Microsoft Windows platform at a minimum and must be fully functional and tested in Microsoft Surface Pro.

External (Public/Private) Agencies

1. The Mobile App for external agency users must have the capability to send the following push notifications to Agency users:

Agency user receives reminders several months prior to expiration. The number of months must be captured as a user defined variable.

Annual reminder to conduct a fiscal year audit Quarterly reminders the agency needs to submit background checks to BFCL

2. The Mobile Application must provide the necessary performance monitoring features as approved by ODJFS such as page load times and crash diagnostics.

3. The necessary reports on behavioral analytics must be provided which enables ODJFS to determine the features that are being utilized frequently.

4. The Mobile Application must support Microsoft Windows platform at a minimum and must be fully functional and tested in Microsoft Surface Pro.

3.2.7 Reporting, Forms, Correspondences & Audit1. The system must allow an authorized user to configure and send mass e-mailings.2. The system must allow an authorized user to add comments to each correspondence item. The system must

capture the date and user id at the time any comment is added to a correspondence item.3. The system must store all notifications and correspondence, whether system-generated or user-generated,

including data such as Subject, To, From, Date, correspondence body, etc.4. The system must assign a unique identifier for each correspondence item generated within the system.5. The system must allow an authorized user to view, resend and print correspondence items whether system-

generated or user-generated.6. The system must allow authorized users to define correspondence letters using pre-defined templates that when

printed must automatically pull in system data based on the parameters defined in the form.7. The system must allow an authorized user to print mailing labels, post cards, and letters.8. The system must allow an authorized user to print documents such as license certificates in batches.9. The system must allow an authorized user to produce a report displaying full license history, including the

applicant's actual responses, in a format that can be certified and admitted as evidence in a disciplinary hearing.10. The system must allow an authorized user to request a report containing operations control statistics such as

average number of days to process an initial application, average number of days to process a recertification, common reasons for denial, certification span, the number of days prior to expiration that the notification is generated, and comments.

11. The system must allow an authorized user to request a report summarizing a licensee's complete application history, including new and renewal applications.

12. The system must provide predefined reports. 13. The system must allow an authorized user to create and save reports, images, and photos in the following

formats: Hypertext Markup Language (.html), Adobe Acrobat Portable Document Format (.pdf), Microsoft Word, Rich Text Format (.rtf), Delimited text by tab or comma, fixed length text, Microsoft Excel Spreadsheet format, XML or image file.

14. The system must allow an authorized user to save report layouts and ad-hoc report definitions for future use.15. The system must allow an authorized user to schedule automatic generation and distribution of reports as defined

by business rules (e.g., daily, weekly, monthly).16. The system must allow an authorized user to create reports without needing advanced technical knowledge using

a robust, user-friendly reporting tool that allows for report design/execution and ad-hoc queries of all system data for example, user should not have to know SQL to create a report.

17. The system must send annual email notifications or ticklers to agencies to conduct fiscal year audits.18. The system must maintain an audit trail of any action that occurs as part of an automated workflow.19. The system must maintain logs for each user access, time of entry and activity and enable an authorized user to

query access through a user-friendly interface.


20. The system must record the user name, date, and time of configuration changes made to the system as well as the previous values and new values entered.

21. The system must archive audit logs after a defined period of time.22. The system must archive all audit, access, history and violation of logs; these logs must be accessible to an

authorized user.

3.2.8 Security/Privacy1. The system must adhere to the State of Ohio IT Standard ITS-SEC-02 and Privacy Policies Framework which

may be retrieved from http://www.privacy.ohio.gov2. The system must adhere to CJIS policy

https://www.fbi.gov/file-repository/cjis-security-policy-v5_5_20160601-2-1.pdf/viewThe system must conform to State of Ohio Revised Code. The system must provide customizable event auditing and must log all access to Confidential Personal Information (CPI) with the user's ID, the data accessed, and the date and time of access. All CRUD (Create, Read, Update, Delete) functions must be logged for information classified and Confidential Personal Information (CPI, see http://codes.ohio.gov/orc/1347.15) For example, it must log user information when a social security number is viewed, updated, or removed.

3. The system must encrypt data in transit with either session-based encryption or message-based encryption using FIPS 140-2 compliant modules or algorithms.

4. The system must encrypt sensitive Personally Identifiable Information (PII) at rest in both structured and unstructured data using FIPS 140-2 compliant modules or algorithms.

3.2.9 Usability Configuration & Supportability1. The system must provide system upgrade processes and support for future released versions of the application

including migration of custom code (as applicable).2. The system must provide a clearly defined patch management process and provide patch management support

(including custom code as applicable.)3. The system must provide an interface or mechanism so that a system administrator can monitor the health of the

application or system and trigger alerts in case of failure.4. The system must allow, but not require, a user to select dates using a graphical calendar tool for all date fields

within the system.5. The system must allow a user to reset his or her own password without intervention by the system administrator.6. The system must adhere to the State of Ohio IT Policy IT-08 Executive Branch Cabinet Agency Web Site

Standardization which may be retrieved from http://das.ohio.gov/Portals/0/DASDivisions/DirectorsOffice/pdf/policies/informationtechnology/IT-08.pdf

7. The system must adhere to the State of Ohio IT Policy ITP-F.3 Web Site Accessibility which may be retrieved from http://das.ohio.gov/Portals/0/DASDivisions/DirectorsOffice/pdf/policies/informationtechnology/IT-09.pdf


https://www.fbi.gov/file-repository/cjis-security-policy-v5_5_20160601-2-1.pdf/view

Attachment 2:

JFS-DAS Security Supplement Addendum


Identity Access Management

The Ohio Digital Experience (ODX) provides a secure digital identity experience including an intuitive and interactive user experience for Ohio’s citizens, businesses, and employees. The program provides centralized administration and synchronization of user identities to enable user provisioning and de-provisioning of identity and access for state systems. The Application or Service must, for all State/County employees, Businesses (Providers), and Citizens, provide single sign-on capabilities through integration with the State's Enterprise Identity Management system called Ohio Digital Experience (ODX) leveraging IBM’s Identity Federation.

ODX is aligned around four distinct pillars that support a consistent user experience for State of Ohio services constituents:

Enterprise Identity Pillar: Enterprise ID Management Framework having the following capabilities:

User Provisioning 2-Factor Authentication (2FA)

Single Sign-on Federation

Identity Proofing Logging and Monitoring

Fraud and Risk Analytics Pillar: A comprehensive, risk-focused fraud detection and analytics service that can detect, prevent, analyze, and report on fraudulent activities in real time.

This enterprise, thin-layer tool is built upon the Federal Data Science Framework and provides:

Continuous Machine Learning Real-time Detection

Scalable and Accessible Big Data Key Graphics

User Experience Pillar: The User Experience Pillar supports an enhanced user and agency experience through consistent look and feel, optimized flows and functionalities and reduced redundancy.

User Interface: (To the extent possible) standardized look and feel, navigation, and presentation of web sites, portals, and applications using a standard digital interface.

User Experience: User-centric design, processes, tasks, and functions that support quicker, easier, and more secure access to and interaction with state agencies.

Agency Experience: State-wide, centralized access point that adheres to the desired user experience and user interface, supported by standard tools, methods, and digital tool kits.

Platform and Portal Services Pillar: Provide an experience that promotes privacy, choice, and flexibility for citizens, businesses, and employees by:

Enabling better, more secure access to an ever-growing set of digital services and self-help features across the state through a single proofed identity

Enabling the state as an organization to consolidate historical transactions and cross-program / agency data to lead a better user experience


An internal ODX Portal acts as the platform by which portal services are provided to agencies. The service portfolio includes:

Design Portal Framework

Personalization Integration

Multitenant and Enterprise Hosting Content Management

Portal and Application Cloud Deployment Control

Portlet and Service Consumption and Publishing

Required Interfaces with ODX(where authentication and authorizations are required for applications or services):

Federated Single Sign-on: Application must support federated single sign-on using SAML 2.0 Tokens for identity assertion to authenticate the user to the Application.

Authorization-Based Assertion Attributes: Application, optionally but preferred, would support SAML 2.0 Token assertions to determine appropriate authorizations (roles/permissions) for the individual, upon sign-in, based upon supplied SAML attribute(s) (such as group memberships).

Automation of Provisioning / de-provisioning: Application must support either:

1. A connector that is available within the IBM Identity suite (ISIM) to automate Agency provisioning and de-provisioning tasks.

2. The Application has SOAP or REST Service(s) available that the IBM Identity suite (ISIM) can call to automatically perform provisioning and de-provisioning tasks.

Provisioning Tasks that must be available:

Create, or associate, an identity in the application for authentication and single sign-on. Assign and Change an identity’s assignment to specific Roles/Permissions within the application for

authorization.

De-provisioning Tasks that must be available:

Delete, or un-associate, an identity in the application to revoke the person’s ability to authenticate. Remove or alter specific Roles/Permissions per identity within the application to remove authorization(s).

Device Authentication: Tracking device information (IP Address, OS, etc.) is required by the application. Application, optionally but preferred, would support device authentication in conjuncture with the ODX Framework above. This will support the ability to prompt for additional security validation /authentication to user in the event the device is not recognized. Such as prompting for two-factor authentication, or having the user submit to ID Proofing, or challenge response questions for additional identity validation. Once the device is identified and tied to User identity, these questions can optionally not be presented or can periodically be reaffirmed based on business requirements.

Encryption

Personally identifiable information (PII), or confidential personal information (CPI - as defined in Ohio Revised Code 1347.15), as used in information security and privacy laws, is information that can be used on its own or


with other information to identify, contact, or locate a single person, or to identify an individual in context. One of the key security controls to protecting PII/CPI is Encryption. Encryption is to be utilized for PII/CPI data on all three states of existence:

Data at Rest: Data at Rest refers to inactive data which is stored physically in any digital form. This refers to both Structured (databases) and unstructured Data (files).

PII/CPI Data at Rest must be protected in one of the following methods:

Encrypt the Entire Database with Transparent Data Encryption (TDE) Table/ Column or Field Level Encryption can be used within the Database Tables to encrypt just the PII/CPI

Ensure that any temporary representations (temp files or folders/ exports/ backups / reports, etc.) of PII/CPI is encrypted in that current state.

o Applying newer encryption technologies and techniques, such as “homomorphic encryption” can be used to meet this requirement.

Encryption methods must use compliant NIST FIPS 140-2 Encryption Algorithms.

Data in Motion: Data in Motion refers to data which is being transferred across some network or transmission media.

PII/CPI Data in Motion must be protected in one of the following methods:

Encrypt the Entire transmission using HTTPS or IPSEC (or equivalent protocols) between all devices and tiers (such as UI > APP > DB Tiers)

Encrypt the PII/CPI data only in transmission (Example: SOAP message using WS-Security)

Encryption methods must use compliant NIST FIPS 140-2 Encryption Algorithms / Modules. When using the Transport Layer Security (TLS), TLS version 1.2 or higher must be used.

Data in Use: Data in Use refers to data actively being used across the network or temporarily residing in memory, or any data not currently “inactive”.

PII/CPI Data in Use must be protected in the following methods:

Implement Memory protections, at a minimum, of Data Execution Prevention (DEP) and Address Space Layout Randomization (ASLR) within Hardware and/or Software.

Sessions must be unique to each authenticated user, and be protected in way that meets the Open Web Application Security Project (OWASP)’s Application Security Verification Standard (ASVS).

Application will use per user or session indirect object references where possible. All direct object References, from an untrusted source, must include an access control check to ensure the user is authorized for the requested object.

Ensure that authentication /authorization checks are performed at each object at the controller and business logic levels, and not just at the presentation layer.

Prevent Injection attacks by using a parameterized API or escape special characters using the specific escape syntax for that interpreter. Also in addition, positive or “white list” input validation must be used.

Device configurations must confirm to industry best practices for hardening (CIS Benchmarks). Components, such as libraries, frameworks, or other software modules used in development must be

identified and a list provided to ODJFS at the conclusion of the project. A supported version of these components must be used at time of the contract.


Autocomplete must be disabled on forms collecting PII/CPI, and caching must be disabled for pages that contain PII/CPI.

Avoid the use of redirects and forwards as much as possible. When used, any such destination parameters must be a mapped value, and that server side code translates this mapping to the target URL.

Audit Logging

A log is a record of the events occurring within an organization’s systems and networks. Logs are composed of log entries; each entry contains information related to a specific event that has occurred within a system or network. Many logs within an organization contain records related to computer security. These computer security logs are generated by many sources, including security software, such as antivirus software, firewalls, and intrusion detection and prevention systems; operating systems on servers, workstations, and networking equipment; and applications.

The number, volume, and variety of computer security logs have increased greatly, which has created the need for computer security log management—the process for generating, transmitting, storing, analyzing, and disposing of computer security log data. Log management is essential to ensuring that computer security records are stored in sufficient detail for an appropriate period of time. Routine log analysis is beneficial for identifying security incidents, policy violations, fraudulent activity, and operational problems. Logs are also useful when performing auditing and forensic analysis, supporting internal investigations, establishing baselines, and identifying operational trends and long-term problems. (Source NIST SP 800-92 “Guide to Computer Security Log Management”)

ODJFS is required, for compliance to Federal and State Laws, codes, standards, and guidelines, to perform audit logging and management of those logs for its information systems.

Logging Requirements

The following Application Events must be record in the audit log(s) for the Information System.

REQUIRED AUDIT EVENTS:

1. User account management activities (user creation, deletion, modification),2. Application shutdown,3. Application restart,4. Application errors,5. Failed and successful log-on(s),6. Security policy modifications, 7. Use of administrator privileges, 8. All changes to logical access control authorities (e.g., rights, permissions, role assignment), 9. All system changes with the potential to compromise the integrity of audit policy configurations, security policy

configurations and audit record generation services,10. Access to Personally Identifiable Information (PII – Also known as Confidential Personal Information (CPI) by

Ohio Law),11. Modification to Personally Identifiable Information (PII) - Also known as Confidential Personal Information (CPI)by

Ohio Law),


12. File creation, deletion, or modification by the application (PDF, CSV, etc. - if Applicable).

Minimum Logging Requirements for Each Event

The following are the minimum required details that must be captured with each recorded event:

1. Identity of any user/subjects associated with the event (Who – user/group/device/system), 2. Event Information (What happened), 3. What Time the event occurred (When), 4. Subsystem or application the event occurred in (Where),5. And the success/failure of the event (if applicable).

Audit Record Generation Services

All Applications, in the event of audit log processing failure (the application is unable to write to the security log/ log service) shall:

1. Notify appropriate personnel of the audit log processing failure, and2. shall either:

a. Stop all processing of further request s until the audit log processing is restored, orb. Queue all audit events to disk, until such time as audit log processing is restored or the storage allocation is

filled.

If storage allocation is full, the application shall stop all processing of all further requests until the audit log processing is restored.

Audit Retention, Aggregation, and Analysis

Applications are required to send the Audit Event Log information, through standard processes (such as SYSLOG) or through add-ons, to the Agencies Enterprise Log Management (ELM) Tool – Splunk and Enterprise Security Information and Event Management (SIEM) – QRadar.

Any required third-party tools or services to achieve this requirement, the vendor must acquire, purchase, and setup.

Audit Log information must be sent security to ODJFS ELM and/or SIEM tools and CPI Log repository (when applicable), using encryption methods that use compliant NIST FIPS 140-2 Encryption Algorithms / Modules.
