Technical Proposal Packet Sp-21-0031

TECHNICAL PROPOSAL PACKET SP-21-0031

Technical Proposal Packet Solicitation No. SP-21-0031

PROPOSAL SIGNATURE PAGE

Type or Print the following information. PROSPECTIVE CONTRACTOR’S INFORMATION Company: Management Services of Educational Data Address: 7540 HWY 107 City: Sherwood State AR Zip Code: 72120 Business ☐ Individual ☐ Sole Proprietorship ☐ Public Service Corp Designation: ☐ Partnership ☒ Corporation ☐ Nonprofit ☒ Not Applicable ☐ American Indian ☐ Service-Disabled Veteran Minority and ☐ African American ☐ Hispanic American ☐ Women-Owned Women- Owned ☐ Asian American ☐ Pacific Islander American Designation*: AR Certification #: ______* See Minority and Women-Owned Business Policy

PROSPECTIVE CONTRACTOR CONTACT INFORMATION Provide contact information to be used for RFP solicitation related matters. Contact Person: Kati Gordon Title: Secretary Phone: 501-801-2500 Alternate Phone: 501-516-7966 Email: [email protected] CONFIRMATION OF REDACTED COPY ☐ YES, a redacted copy of submission documents is enclosed. ☒ NO, a redacted copy of submission documents is not enclosed. I understand a full copy of non-redacted submission documents will be released if requested. Note: If a redacted copy of the submission documents is not provided with Prospective Contractor’s response packet, and neither box is checked, a copy of the non-redacted documents, with the exception of financial data (other than pricing), will be released in response to any request made under the Arkansas Freedom of Information Act (FOIA). See RFP Solicitation for additional information. ILLEGAL IMMIGRANT CONFIRMATION By signing and submitting a response to this RFP Solicitation, Prospective Contractor agrees and certifies that they do not employ or contract with illegal immigrants and shall not employ or contract with illegal immigrants during the term of a contract awarded as a result of this RFP. ISRAEL BOYCOTT RESTRICTION CONFIRMATION By checking the box below, Prospective Contractor agrees and certifies that they do not boycott Israel and shall not boycott Israel during the term of a contract awarded as a result of this RFP. ☒ Prospective Contractor does not and shall not boycott Israel.

An official authorized to bind the Prospective Contractor to a resultant contract shall sign below. The signature below signifies agreement that any exception that conflicts with a Requirement of this RFP Solicitation may cause the Prospective Contractor’s proposal to be rejected. Authorized Signature: ______Title: Use Ink Only.

Printed/Typed Name: Date:______2

Technical Proposal Packet Solicitation No. SP-21-0031

SUBMISSION REQUIREMENTS CHECKLIST

Per the solicitation, the following items must be submitted with the Prospective Contractor’s proposal:  Proposal Signature Page  Proposed Subcontractors Form  Information for Evaluation  Exceptions Form, if applicable  Official Solicitation Price Sheet, sealed separately It is strongly recommended that the following items are also included with the Prospective Contractor’s proposal:  EO 98-04: Contract and Grant Disclosure Form  Copy of Prospective Contractor’s Equal Opportunity Policy  Voluntary Product Accessibility Template (VPAT), if applicable  Signed addenda, if applicable

Technical Proposal Packet Solicitation No. SP-21-0031

PROPOSED SUBCONTRACTORS FORM

• Do not include additional information relating to subcontractors on this form or as an attachment to this form.

o Prospective Contractor shall complete and submit the Proposed Subcontractors Form included in the Technical Proposal Packet.

o Additional subcontractor information may be required or requested in following sections of this RFP Solicitation or in the Information for Evaluation section provided in the Technical Proposal Packet. Do not attach any additional information to the Proposed Subcontractors Form.

o The utilization of any proposed subcontractor is subject to approval by the State agency.

PROSPECTIVE CONTRACTOR PROPOSES TO USE THE FOLLOWING SUBCONTRACTOR(S) TO PROVIDE SERVICES.

Type or Print the following information Subcontractor’s Company Name Street Address City, State, ZIP

☒ PROSPECTIVE CONTRACTOR DOES NOT PROPOSE TO USE SUBCONTRACTORS TO PERFORM SERVICES.

Technical Proposal Packet Solicitation No. SP-21-0031

INFORMATION FOR EVALUATION

• Provide a response to each item/question in this section. Prospective Contractor may expand the space under each item/question to provide a complete response.

• Do not include additional information if not pertinent to the itemized request.

E.1 Prospective Contractor Qualifications 1. Describe your experience providing Migrant Education Databases and how your company meets 5 the minimum requirements set forth in Section 2.2 of the RFP. Include description of the points Contractor’s experience as a whole, as well as the experience of any proposed key staff members who will be assigned to the contract.

We are an Arkansas based company, with over twenty years of experience providing Migrant Education Data systems for statewide migrant education programs across thirty states. We have advanced experience in providing flexible and customizable software along with robust services.

We designed the system as a Microsoft Windows- and web-based solution to the information needs of states serving migrant children. The system design focuses on a state database as opposed to a national database. This allows the system to be tailored to the unique information needs of a given state.

The uniqueness of the system consists mainly in the following three features:

1. We are the only migrant data system customized to the needs of each state. 2. We are the only migrant data system that offers separate, integrated, and complete web and native/desktop applications. The entire MSIX MDE can be entered and maintained solely through either the desktop application or the web application. Any combination of the two is also an option. 3. We are the only migrant data system that combines a web-based system and a tablet system capable of full operation when disconnected from the internet. Our tablet system is designed to function at remote field locations such as farms where no internet is available.

The system is tailored to the exact needs of each state. Currently, the system is used by thirty states and no two states maintain the same data. Each state can define information relative to their program without regard to whether other states maintain this information. The alternative is to utilize the “one size fits all” approach where information is the same for all states irrespective of their unique needs. Tailoring of the system is a unique feature not offered by competing software vendors.

With a senior developer/president having over twenty-three years of experience and each staff member bringing at least ten years each of related experience, we are supported by a skilled workforce.

1. Provide contract details for at a least three (3) government entities in the United States for whom 5 you have successfully provided services of a similar size and scope as those described in this RFP points in the last five (5) years. Government entities should be identified generically, for example, “State Government Agency”, “Federal Government Agency” “City Government”, etc. a. We are contracted with State Agency A for September 1st, 2020 – August 31st, 2021 to provide a Migrant Education Data system, 37 regional work stations, and 96 web users. b. We currently are contracted with State Agency B to provide a migrant education data management system and services for the state. This Contract begins on January 01, 2021 and ends January 01, 2023. 5

Technical Proposal Packet Solicitation No. SP-21-0031

c. We currently are contracted with State Agency C for January 16th, 2020 – January 15th, 2021 to provide a Migrant Education Data system for the state MEP. The core system is provided along with, 86 workstation/tablet users, 45 web users and a yearly hosting service. d. We are contracted with State Agency D to provide a Migrant Education Data system and services for the state March 1, 2020 through February 28, 2022. e. We are contracted with State Agency E for July 1st, 2020 – June 30th, 2021 to provide a Migrant Education Data system, 42 regional workstations, 64 web users and AWS GovCloud hosting. f. We are contracted with State Agency F for October 1st, 2020 – September 30th, 2021 to provide a Migrant Education Data system, 17 workstations/tablets, 4 web users and tablet server license fee. g. We are contracted with State Agency G for May 22nd, 2020 – May 21st, 2021 to provide a Migrant Education Data system, 42 regional workstations, 45 web users and AWS GovCloud hosting. h. We are contracted with State Agency H for December 31st, 2020 – January 1st, 2023 to provide a Migrant Education Data system, 10 regional workstations, web user license, tablet system server and AWS GovCloud hosting. i. We are contracted with State Agency I for August 1st, 2020 – July 31st, 2021 to provide a Migrant Education Data system and support. j. We are contracted with State Agency J for May 24th, 2018 – May 23rd, 2021 provide a Migrant Education Data system, 85 workstations/tablets, 125 web users, tablet system server and AWS GovCloud hosting.

E.2 System Performance Requirements 1. Describe the proposed system’s ability to meet the system uptime and response times laid out in 5 Section 2.3 of the RFP. Include a description of how the system will meet these requirements points without negatively impacting other ADE systems. We meet the system uptime and response times through our hosting contract with Amazon Web Services (AWS) in which minimum uptime and response times are guaranteed. We are committed to maintaining at a minimum a 99 percent uptime for the system, excluding scheduled downtime for maintenance. The system provides a minimum of 90 percent or greater sub 400 millisecond page response time including for API calls. We provide dedicated bandwidth to ensure the system does not negatively impact or interfere with services from ADE’s existing system. The system is designed to alert users and administrators to issues impacting system performance. A monitoring system is in place to proactively generate system performance notifications as well as to identify any potential causes to prevent future failure. Monthly reports related to load times and usage are produced as part of ongoing system monitoring.

2. Describe how scheduled downtime for maintenance will be handled outside of ADE’s normal 5 business hours. points In order to be responsive to customer needs, our staff work with state agency staff to schedule enhancements and maintenance during times state agency staff are available to ensure changes are satisfactory. This allows us to provide timely improvements that do not negatively impact the day-to-day activities of the state agency. The system is designed to provide redundancy and allow for maintenance that does not require scheduled downtime. If time is required for the system to be completely down, our staff contact ADE staff to schedule downtime outside of normal business hours.

3. Describe how System Usage and Performance Reporting will be handled, and how the report will 5 be delivered to ADE by the required deadline. Include a sample report. points System usage and performance logs are kept in order to facilitate scheduled periodic reporting as well as on-demand requests. Statistics collected include response times, feature usage and user access. These reports are delivered monthly via email.

Technical Proposal Packet Solicitation No. SP-21-0031

E.3 Hosting 1. Describe in detail the hosting platform for the proposed System and how it meets the requirements 5 set forth in Section 2.4 of the RFP. Include details concerning the location of data centers and how points the system will only be accessed from the continental United States. The system is offered as a Software as a Service solution. All servers and data associated with the system instance of the Contractor Hosted Solution reside in the Eastern Region of the United States. We utilize AWS to provide a virtual private cloud. Staff are required to conduct work related to the system within the continental United States. We provide services to support the operation of hardware, software, and network support related to the hosting of the system. We are committed to providing direct network communications to allow access and the exchange of data via approved industry standard protocols as necessary for interfacing with ADE and other State of Arkansas systems. We provision all environments including at a minimum: • Development • Testing • Production

2. Describe how all hosting related software will be kept current and up to date. 5 We are committed to keeping all related hosting software and hardware up to date. This is done by points ensuring the system is hosted in environments that meet industry standards for security and performance. Services are monitored and upgrades applied when deemed necessary to ensure the performance of the system. We make use of Windows Update to ensure the OS and associated software is up to date.

3. Provide an optional proposal for the State hosting of the proposed system. Include at minimum the Not information required in Section 2.4.K. of the RFP. Score We fully support hosting of the system within the state data center. This is a common solution used d in many states for our system. We require a single dedicated VM instance running Windows Server 2012 R2 or better. E.4 System Access 1. Describe how users will access the system in accordance with requirements set forth in Section 2.5 5 of the RFP. points We are the only widely used migrant data system that offers separate, integrated, and complete web and native/desktop applications. Recruiters and migrant education staff can make use of the system regardless of internet connectivity. Users access the web app through a secure, web-based portal. The web app is completely browser based and can be accessed through all modern browsers without the use of additional browser plug-ins or add-ons. Recruiters needing to collect

Technical Proposal Packet Solicitation No. SP-21-0031

data in remote places can do so with a tablet device and the native application without needing cellular or wireless connectivity.

2. Describe how the system will be accessible via a downloadable mobile app and how the full 5 system will be accessible in offline mode. Include details on the types of devices and operating points systems the mobile application will be accessible on.

The system can be installed on a Surface tablet operating Windows for remote or offline use. The system can be installed on any desktop operating up-to-date Windows software for offline use as well.

3. Describe how the proposed system is browser neutral and will be accessible and function 5 accurately when accessed from various device types. points The web app is routinely checked for compatibility with all modern browsers. The system is designed to be run in any browser by following industry protocols. Users will have similar experiences and be able to access the web app from any modern browser. We specifically test against Firefox, Chrome, Edge, IE, and Brave regularly. We support Safari but do not test regularly. We support responsiveness on devices down to roughly iPad sized. It can be used on phones, but we do not recommend it or support it.

4. Describe the proposed system’s User Management System and how it meets the requirements set 5 forth in Section 2.5.F. of the RFP. points The system provides functionality related to user management in the following ways: a. System administrators can create, activate and disable user accounts. b. System administrators can generate account activation emails. c. System administrators can identify and assign roles with restricted access and permission levels, enforcing access to only certain student data for instance. d. Users are required to set strong passwords. e. Self-service access is available to users to reset passwords and retrieve forgotten username and information.

E.5 Student Identification Numbers

1. Describe the system’s ability to generate a unique identification number for students without the 5 use of Social Security Numbers as described in Section 2.6 of the RFP. Include details about how points the system will be compatible with the State’s existing ten-digit identification numbers and the system’s ability to push identification numbers back into ADE’s Student and Financial Management Systems. We work closely with the state agency to support student identity management in accordance with state protocols. The system generates unique identification numbers not based on social security numbers. The system can be designed to support the exchange of data across systems based on industry standards. Currently, we provide exchange of data through practices such as flat files and APIs. The system supports any number of IDs per student from any number of originating systems. We routinely customize as needed to meet any unusual state requirements. 2. Describe how the system will accommodate Migrant Student Information Exchange (MSIX) IDs. 5 Include details on support for reporting and resolving duplicates. points The system is designed to support Migrant Student Information Exchange. Each night the system processes MSIX IDs, identifying duplicates and using logic to resolve the duplication. If a duplicate student cannot be resolved through the automatic process, notifications are sent to the support team as well as the state agency. ADE staff are then able to review the relevant student data and determine if students should be merged. No system has been certified for use by MSIX in more states than ours.

3. Describe the system’s ability to resolve duplicate records and the process by which ADE can 5 review the records for accuracy. points ADE staff can resolve duplicate records by generating several different kinds of potential duplicate reports and reviewing related data within the system. Demographic information such as names and birthdates are included for review. A process to merge student records retains alternative student identifications and identifies a preferred ID.

Technical Proposal Packet Solicitation No. SP-21-0031

E.6 System Requirements 1. Describe how the proposed system meets the System Requirements set forth in Section 2.7 of the 5 RFP. points The system is designed to fully support the MEP by providing functionality to collect, access, retain and maintain all related data. This includes data on the national certificate of eligibility, signatures for families and MEP personnel, all data required by MSIX, all service provision data, and any other data deemed relevant by the MEP.

We work with each state agency to identify data collection needs and design an interface to support day-to-day operations of the program as well as federally mandated reporting. Recruiters using tablet devices can go into the field to collect all required data and signatures. AED staff can review data related to each student by viewing the student record. COE data can be viewed from the COE record page.

Customizable reports allow ADE staff to review the data at any time. Data can be manipulated by designated users through the system. We work closely with state agency staff to identify needs and create processes for bulk imports of course history and assessment related data. Processes are designed for either nightly imports such as for updates for all eligible students from Triand or for periodic imports of course history, assessment and demographic data from the statewide information system.

When an import process is implemented, a system for logging of all data changes via the import is also implemented. ADE staff can validate data of all elements through the interface and reports can be requested at any time to further support data validation efforts.

E.7 COE Requirements 1. Describe in detail how the system will meet the COE requirements set forth in Section 2.8 of the 5 RFP. points We work with each state agency to identify what data elements are required for their COE. The interface is designed to support the input of the required data based on the needs of the state agency. Code tables are built to validate data entered and can be managed by system administrators. COEs can also be printed from the system based on the desired design of the MEP.

Workflow logic is implemented to support the review of COEs. The workflow is designed based on the needs of the MEP. This allows system administrators to identify routing for the review process. For example, it can be designed so that COEs are routed to the appropriate user based on the status of the COE and the district in which it is was generated. Each transition in the approval process is logged with opportunities for users to add comments.

The COE data collection process uses logic based on the needs of the MEP, to enable or disable features of the user interface based on data entered. Users can scan and attach electronic documents within the user interface. Opportunities to capture signatures exist throughout the process with the system supporting the display of specific wording including English, Spanish, Marshallese, Vietnamese, Chinese, Karen, Tai, Hmong, Arabic, and Laotian.

As part of the COE approval process, users can generate electronic signatures to be reused. The COE data collection process is designed to meet the needs of the MEP, so any data elements deemed necessary can be added to the user interface. Below is an example of the COE record

Technical Proposal Packet Solicitation No. SP-21-0031

demonstrating the types of data that can be collected.

E.8 Student Data Requirements 1. Describe how the system will capture the Student Data required in Section 2.9 of the RFP. 5 Like the COE data collection process, we work with the MEP to identify what student data needs to points be collected and design the user interface to support the business processes of the MEP. New student records can be generated in advance of creating COEs or while in the process of creating a COE. Types of student data collected can be in addition to data collected on the COE. For instance, the system facilitates the collection of a current address or names of parents that are different than what is included on the COE. Reports can be generated to display the appropriate data based on the needs of the user.

The student record supports collection of data related to schooling and services provided. Data such as associated schools and programs, dates, enrollment types, course history, assessments, services, and at-risk indicators can be collected. Historical lists of all associated data are maintained and can be reported on as needed. Below is an example of a student record and the type of data that can be collected.

Technical Proposal Packet Solicitation No. SP-21-0031

E.9 User Roles & Permissions 1. Describe the User Roles & Permissions functionality of the proposed system and how it meets the 5 requirements set forth in Section 2.10 of the RFP. points The customizability of the system means user roles and permissions can be designed to fit the exact needs of the MEP. Roles can be designed to allow complete administration of the system or administration of specific resources. Permissions can be identified to support different levels of access for state, district or regional users. This allows the MEP to assign roles to users based on the responsibilities of the individual user. While we work closely to create and refine roles, designated users of the MEP also have access to create and edit roles based on desired permissions and access levels. At a minimum the following user roles can be provided, administrator, resource administrator, state level user, verifier, district recruiters, district users, and regional recruiters.

The flexibility of the system means that it can support very granular permissions such as identify what districts an individual user can view, what facilities can be altered, or which reports can be run. Permissions can be assigned to individual users as well as sets of permissions. Users can have multiple roles made up of existing sets of permissions allowing for more efficient user manager. The granularity at which permissions can be set in the system means that access can be controlled at the level of report filters such as operators and values supplied in the filter. For instance, a role can be designed to only allow users access to facilities within their region meaning that when running a report only facilities within that district will be available from the drop-down list. Other examples include limiting access to view only for a specific class of students or COEs or providing view only access to certain classes of COEs and alter access to other classes of COEs.

E.10 MSIX Requirements

Technical Proposal Packet Solicitation No. SP-21-0031

1. Describe how the system will meet the MSIX requirements set forth in Section 2.11 of the RFP. 5 We have worked with nearly thirty state agencies to achieve MSIX certification of the system. The points system includes an interface with the Migrant Student Information Exchange operated by the federal Office of Migrant Education. The system is designed to process complete information for all students who have been updated since the last submission. These processes run on a nightly basis. The system processes all MSIX response files and alerts the appropriate personnel for all reported errors. While the system allows users to quickly identify and resolve issues based on errors identified in the MSIX response files, we work closely with the MEP and officials from MSIX to resolve errors. The system supports the merge of MSIX files and logs information related to merges for review by the MEP. Our staff work with the MEP to provide custom and on demand reporting to assist in the analysis of discrepancies between student counts for the state agency and MSIX. E.11 Reporting 1. Describe how the system will produce the reports required in Section 2.12.A. of the RFP. 5 With over twenty years of experience assisting MEP staff meet federally mandated reporting points requirements, we are well equipped to meet reporting needs. Report specialists work with the MEP to identify data elements and report parameters. Report specialists then write queries using the built-in reporting tools to meet requirements. As part of our commitment to being a service-oriented organization, unlimited report requests are part of every engagement with a MEP.

2. Describe the number of canned reports available in the system out of the box. 5 Specialized reports guaranteed to be provided include EdFacts Reports (054, 121, 122, 145, 165), points COE logs as well as credit deficiency reports, free lunch eligibility reports, enrollment lists by grade, enrollments with no services lists, funding formula counts, K-12 enrollment lists, migrant enrolled and residing lists, migrant family counts, child count reconciliation reports, priority for service list, random student samples, secondary student lists, state assessment summary reports, students missing enroll date reports, students with new enrollment reports, and students without a specific SP reports.

3. Describe the ad-hoc reporting capabilities of the proposed system. 5 In addition to being able to request custom reports, the system provides a user-interface to create points customized reports.

4. Describe the ability of the proposed system to export reports in a variety of file formats as 5 described in Section 2.12 of the RFP. Include information on batch printing and customized points printouts as well as electronic file formats. Reports can be exported in a variety of formats including in a portable document (PDF) format and a comma-separated value (CSV) format. Excel and txt are also supported.

5. Describe the audit functionality of the proposed system and how it meets the requirements set forth 5 in Section 2.12.H. of the RFP. points In order to ensure, data integrity the system includes audit functionality that tracks data inquiries and changes and logs information such as date and time of inquiry/modification, type of activity, the identification of the user and the fields that were requested and/or modified. Logs containing this information are retained and available to view from online by authorized users. A typical change record in the logging system looks like this: Changes by User 24 to schlhist SHKEY=MI0-1739-318843 APPROVALSTATUS:from=R:to=V OWNER_USER_ID:from=24:to=8 CONDITION:from=Reviewed:to=Verified E.12 Required Interfaces 1. Describe how the proposed system will interface with the systems required in Section 2.13 of the 5 RFP. points Our staff works with the MEP and DOE to identify needed data flows. In the case of an automated import from the statewide information system (SIS) or Triand, a task would be established that identifies data needed, mapping it to incoming data elements and ingesting requested data each

Technical Proposal Packet Solicitation No. SP-21-0031

night. We have done many integrations using various technologies like CSV, XML, ODBC, RESTful web services, SFTP, and EdFi. We can accommodate any industry standard interface. E.13 Data Conversion 1. Describe the process by which historical data from ADE’s current system will be converted into the proposed system and available at time of Go Live as if it had been originally captured in the 5 system. points We are intimately familiar with the state’s current solution and can have our proposed system up and running within minutes of award. As part of any new implementation, our staff work closely with the MEP to migrate data and retain data integrity. Through an iterative process, data elements are mapped from the old system to the new system. Data in our system is stored in a Firebird Database. As part of the migration process, our staff work with the MEP to identify type of database systems used in the past and make the necessary accommodations to convert the data. The system can support the migration of 3G of historical data including scanned electronic documents. The flexibility of the system ensures all data needs can be met and when deemed necessary older data elements can be retired to reflect new business processes and requirements. Data validation training for the MEP is part of the iterative process ensuring data is available as if it had been originally captured in the system at the time of Go Live.

E.14 Ongoing Maintenance 1. Provide a proposed Maintenance Plan detailing the approach to ongoing maintenance of the 5 proposed system that meets or exceeds the requirements set forth in Section 2.15 of the RFP. points Our Maintenance Plan is based on ensuring the performance of the system through monitoring, testing, and applying upgrades in a timely fashion. a. Monitoring systems are in place to alert our staff of performance issues requiring maintenance or updates to the environment via Windows Update. b. Using the model of a development, testing and production environment, upgrades are taken through a quality assurance process. Upgrades are made available in the testing environment for users to test prior to approving the change in the production environment. All communications regarding upgrades take place through email to ensure designated MEP staff are aware and approve of changes. c. Periodic upgrades of the system and environment are completed to ensure the system and environment stay up-to-date. Our staff work with the MEP to schedule any required downtime and remove chances of negatively impacting day-to-day activities and interfaced systems. Our business model of providing continuance feature enhancement at no additional costs means we are committed to a maintenance plan that includes enhancements, additions, changes or customization relevant to the MEP. d. Practices are in place to ensure maintenance includes any necessary changes to maintain compatibility with MSIX, ADE systems or Triand.

E.15 Ongoing User & Technical Support 1. Provide a plan for Ongoing User and Technical Support beginning at Go Live and continuing for 5 the life of the contract. Include details on how this plan will meet or exceed the requirements set points forth in Section 2.16 of the RFP. Committed to providing exceptional service, our staff provides ongoing user and technical support including 24/7 emergency support should there be a complete system failure, as well as standard training and support during regular business hours. Our plan for ongoing user and technical support includes the following: a. Live assistance is available for technical support via phone, email and web-conferencing during regular business hours. Our team monitors system notifications as well to proactively provide technical support by researching issues and reaching out to users to provide resolutions. b. Our team uses an issue tracking system that allows the MEP to identify issues as Emergency, High, Medium, or Low Priority. Issues are responded to accordingly based on the requirements of the MEP. E.16 Training 1. Provide a Training Plan that meets or exceed requirements set forth in Section 2.17 of the RFP. 5 The Training Plan should demonstrate that the Prospective Contractor has a thorough points

Technical Proposal Packet Solicitation No. SP-21-0031

understanding of all activities required to effectively train staff on how to use the proposed system. Include sample training materials that have been used in past implementations of similar size and scope to the one described in the RFP. Our plan for training includes opportunities at all points of the process from system adoption to ongoing usage and system enhancements with the goal of equipping the MEP to successfully use the system at the time of “Go-Live”. a. Training resources are made available and training is scheduled at key times in the process. b. Data validation, Student and COE management, Report Management, Report Writing, and System Administration training take place over the course of introducing the new system. For instance, users are trained on how to navigate the system and verify accurate data as part of the iterative process for migrating data. c. Trainings are held either face-to-face or via teleconference based on the needs of the MEP. d. Training aids and live training sessions are available to users at each step of adopting and using the system. e. Training sessions are provided as needed and by request. f. Training sessions are provided either to a group or one-on-one. g. Annual trainings are available that include demonstration environments and training resources for as many users as the MEP requires. h. Train-the-trainer sessions and resources are made available to the MEP. i. All training and resources are customized to fit the needs of the MEP. E.17 Staffing and Key Personnel 1. Provide a Staffing Plan. Include key staff members required by Section 2.18 of the RFP and any 5 additional key staff being proposed by the Contractor. Provide resumes for all key staff members. points Proposed plan must at minimum meet all requirements set forth in Section 2.18 of the RFP. Our staff have expert experience working with migrant education data and are well-equipped to support the MEP. We shall include the following in our staffing plan: a. A project manager. The project manager has over twenty-five years of experience working with state agencies to support migrant education data. The project manager has overseen over thirty implementations of our system. They shall serve as the primary point of contact, will provide a project timeline, coordinate between stakeholders, manage the entire lifecycle of the project and ensure synchronization of all activities of the project. b. A technical team made up of two developers, a user support specialist and a report specialist. Each member of this team has been involved in migrate education data for more than 16 years and brings a wealth of knowledge to ensure the success of each project. This team is responsible for determining operating feasibility, preparing solutions and implementing the system based on the needs of the MEP. c. An account manager. The account manager has served the MEP community for over twenty-five years. Providing expert service and support. The account manager will be the primary point of contact for the MEP after the implementation is complete and the system is operational. d. A customer success advocate. This person brings nearly 15 years’ experience working with information technology systems and users to support the success of the organization and its mission. The customer success advocate will be available to support the MEP in successful use of the system. e. Our staff are cross trained to ensure redundant skill sets and knowledge. Should any one of our exceptional staff not be available to serve the MEP, an equally skilled individual is ready to step in and take their place.

E.18 Implementation 1. Provide an Implementation Plan. The Implementation Plan should demonstrate that the 5 Prospective Contractor has a thorough understanding of all activities required to seamlessly points implement the proposed system. The proposed Implementation Plan must meet or exceed all requirements set forth in Section 2.19 of the RFP. Due to our intimate knowledge of Arkansas’ current system, an implementation will be a simple continuation. There will be absolutely no downtime whatsoever. Our implementation plan draws upon over twenty-five years of experience working in migrant education data. We work closely with

Technical Proposal Packet Solicitation No. SP-21-0031

the MEP to ensure a smooth experience. We begin by identifying the data elements and business practices of the MEP. Our system is customized to suit the needs of the MEP. The process is as follows: a. Historical data is mapped, validated and imported into the new system. b. Functionality in the system is built out to support the business processes of the MEP. c. MEP Staff are trained. d. Iterative testing takes place to ensure quality. e. Continuous improvements are implemented based on needs of the MEP. E.19 Testing 1. Provide a Testing Plan. The Testing Plan should demonstrate that the Prospective Contractor has 5 a thorough understanding of all activities required to effectively test the proposed system. Testing points Plan must at meet or exceed all requirements set forth in Section 2.20 of the RFP. Testing of the system takes place throughout to implementation process. The system was designed to be flexible and customizable, but the core of the system has been proven time and time again in the twenty-five years and thirty implementations it has been part of. The plan for testing is as follows: a. Our staff test functionality of initial build. b. Imported historical data is validated by the MEP. c. Base functionality is tested by the MEP. d. Issues identified are assigned to the proper staff member. e. Issues are resolved according to the priorities of the MEP. f. Corrective action plans to resolve the issue in a timely fashion are provided by our staff and approved by the MEP. E.20 Disaster Recovery 1. Provide a Disaster Recovery Plan. The proposed Disaster Recovery Plan should demonstrate that 5 the Prospective Contractor has a thorough understanding of all activities necessary for disaster points recovery and meet or exceed all requirements in Section 2.21 of the RFP. We follow industry best practices for disaster recovery. All instances of the system and state data are backed-up nightly. Should a disaster take place, we would restore the system into a stable environment and restore all data. Each night a process is run that backs-up the entire system along with the back-up of the database. Monitoring services are in place to alert our staff of system issues via email. When issues are identified, our staff are prepared to respond promptly and restore services. E.21 Data Security 1. Provide a Data Security Plan. Provide details on how the proposed plan meets or exceeds the 5 requirements set forth in Section 2.22 of the RFP. points Our Data Security Plan is based on our Information Security Policy which outlines expectations of employees when dealing with data and our PII Policy (attached). Policies related to data in motion, as well as at rest as they pertain to the various formats encountered are outlined. Industry standards for data security are implemented throughout.

Regarding the primary contact for notification, an individual is assigned and available to assist the State, twenty-four (24) hours per day, seven (7) days per week in the event of a security breach. This person is prepared to provide detail explanations as well as resolution that will prevent the breach from being repeated. An automated security alert system is in place that sends emergency emails to any list of recipients the State requires as well as Our staff.

As outlined in our Information Security Policy, all data located on servers is physically and virtually secured where applicable. Access to data is restricted to authorized users using strict security protocols. For instance, • access to any web page that that displays restricted data must be secured with a unique username and password, • all web pages displaying restricted data or being used to upload or download restricted data must use the https:// protocol, • all host servers are in AWS using EBS volumes. EBS volumes are to be encrypted at all times, • our Duplicati backup system automatically encrypts all data in the backup. Each machine using Duplicati must have it own unique encryption key. 15

Technical Proposal Packet Solicitation No. SP-21-0031

• all portable production machines must be encrypted using BitLocker.

Should a security breach take place, our staff will notify the State within four (4) hours after the event is identified. No third parties or our staff not directly involved with the development are allowed access to information related to statistics or demographics of the State of Arkansas. Only with a need to know have access to such data.

Our staff adhere to the National Institute of Standards, Guidelines for Media Sanitization, when removing a hard drive from service of the contract. Data is erased, destroyed and rendered unrecoverable within thirty (30) days of the termination of the agreement.

Any PPI related to Arkansas citizens is only maintained for the time required by the state. The system is designed to support privacy and security standards such as the Family Education Rights and Privacy Act (FERPA). Encryption of data logs adhere to AES-256.

Only authorized users can access the system and must do so using a unique user-id and password. Role-based access levels can be defined based on the needs of the MEP. The MEP is the final authority to grant access to any user from other state entities. The system can be configured to lock out an operator after a State-assigned number of failed attempts to log in. A strong and complex password is required. The system can be configured to lock the user ID out after five (5) sequential incorrect passwords attempts, to prohibit reuse for six (6) generations, set to expired after a state-defined amount of time and reset if password has not been changed after a period defined by the State.

E.22 Data Ownership and End of Contract Transition 1. Describe how the State shall maintain ownership of all data in the Contractor’s proposed system, 5 and how that data will be transferred back to the State at the end of the contract. Include plans for points destroying copies of State-owned data in the Contractor’s possession at end of contract. We do not claim ownership of any data in the AR system and recognize that all such is owned by the state of Arkansas. Data is stored only on encrypted EBS volumes within AWS that only our staff has the key to. The data is only made available to authorized state employees and the federal MSIX system as required by this RFP. These volumes will be deleted at the end of the contract period. Any data downloaded for development and debugging purposes is handled according to the attached documents.

2. Describe the approach to end of contract transition. Include details on how Prospective Contractor 5 will cooperate with the State and/or the next contractor to assure a smooth transition of services at points end of contract. This should include transfer of State owned back to ADE or their designee. We will turn over complete backup copies of the full AR database upon request by the state at the end of the contract and will support the incoming vendor in the interpretation and use of this data.

Technical Proposal Packet Solicitation No. SP-21-0031

EXCEPTIONS FORM

Prospective Contractor shall document all exceptions related to requirements in the RFP Solicitation and terms in the Standard Services Contract and “Solicitation Terms and Conditions” located on the OSP website. See Section 1.8 and 1.9 of the RFP Solicitation.

REFERENCE ITEM (SECTION, DESCRIPTION PROPOSED LANGUAGE # PAGE, PARAGRAPH) 1. 2. 3.

Additional Information from Specifications:

Project Team Roles and experience Kevin Donn, President, lead developer, project manager, over twenty-five years of experience BA Computer Science, University of California, Berkeley MS Computer Science, University of Arkansas, Fayetteville Jeff Gaiche, senior developer, over fifteen years of experience BS Computer Engineering, University of Arkansas, Fayetteville Jay Dickerson, technical support, over twenty years of experience BA Architecture and Design, University of Arkansas, Fayetteville Marcy Trogdon, user and report specialists, over fifteen years of experience BS Computer Information Systems, University of Central Arkansas, Conway Kati Gordon, Secretary, training and customer support, over ten years of experience BA Political Science, University of Calgary, Alberta MS International Studies, Oklahoma State University, Stillwater MLIS Library and Information Studies, University of Oklahoma, Norman

Personally Identifiable Information (PII) Policy This PII policy discloses the PII handling practices for our organization. This policy applies to information collected on the website as well as information collected via our licensed systems.

Information Collection, Use, and Sharing We do not own any of the information collected by our customers. We will not disclose any such information to any third party without the express written consent of authorized state personnel. This includes PII about state employees or the students and families in our systems.

Web We transfer all PII in a secure manner. All PII that moves within our systems is encrypted and restricted to authorized personnel. All PII that moves to and from our company website is also encrypted and restricted to authorized personnel.

Access to all of our web systems is restricted to HTTPS only. All access to PII requires an account authorized by state personnel. All accounts are in the name of a specific person only. All accounts require user name and password authentication. Passwords are required to be at least 8 characters long and contain at least 2 non-alpha characters.

All of our hosted web systems are behind firewalls restricting traffic to only the protocols served, generally HTTP for redirects, HTTPS, and RDP. Our firewalls restrict protocols to a specific IP whenever practical. None of our hosted web systems support either SSL or TLS 1.0. Only TLS 1.1 and better is currently supported. None of our hosted web systems support RC4 cipher suites. All of our hosted web systems are secured with a CA certificate using a SHA-2 hash.

Our systems undergo vulnerability testing weekly using OpenVAS. Routinely pass with no vulnerabilities above a “Low” severity.

Email We do not transfer any PII in emails. Our email server supports TLS encryption in the event that anyone inadvertently sends PII to us.

Disposal All the PII within our immediate care is stored on hard drives. When one of our hard drives reaches the end of its service life, we wipe it within 45 days according to US Dept. of Defense 5220-22.M specifications before disposing of it.

Any PII in our care printed to paper is confetti shredded within 45 days after use. Information Security Policies Updated 02/05/2021.

Employee Requirements Using this policy This policy outlines behaviors expected of employees when dealing with data and provides a classification of the types of data with which they should be concerned.

1.0 Purpose To protect restricted, confidential or sensitive data from loss to avoid reputation damage and to avoid adversely impacting our customers and the people they serve. The protection of data in scope is a critical business requirement, yet flexibility to access data and work effectively is also critical. The primary objective is user awareness and to avoid accidental loss scenarios. This policy outlines the requirements for data leakage prevention, a focus for the policy and a rationale.

2.0 Scope 1. Any employee, contractor or individual with access to systems or data. 2. Definition of restricted data to be protected • User Information – We often have information about the users of our software including their email addresses, phone numbers, etc. • Student Information – The information we store in our system about students, their families, their educational records, their membership in the migrant education program, and the services they have received are all examples of student information. • Student PII – Student information that can be related back to a specific person. This may be contrasted with information that cannot be related back to a specific person, for example aggregated information or anonymous information like “enrollment on 7/25/2019”.

3.0 Policy 1. Visitors must be escorted by an authorized employee at all times. If you are responsible for escorting visitors, you must restrict them to appropriate areas. 2. You are prohibited from communicating any User Information or Student Information publicly. 3. You are prohibited from communicating any Student PII via a non-secured channel like email. 4. You are prohibited from communicating Student PII even over a secured channel to anyone not authorized to have such information.

Data Leakage Prevention – Data in Motion Using this policy This policy applies to the handling of all restricted data that is being moved from one device to another over a network. It outlines the requirements for all employees to safely moving restricted data in this way. 1.0 Purpose Protecting data in motion is generally a simple matter of recognizing when it’s happening and then either encrypting it or obfuscating it.

2.0 Scope The main ways data is moved are: • Viewing web pages • Uploading or downloading files to or from a web server • Moving files to or from an FTP server • Moving files across a LAN file server • Copying files via RDP • Moving data to or from a backup service • Sending data via email 3.0 Policy 1.0 Viewing web pages Encryption occurs automatically when using https. Before working with any restricted data in a web browser, ensure that the url begins “https://” and that your browser shows the lock symbol. If you discover that any restricted data seems to be available via a url that does not begin with “https://”, report it immediately to your security contact. Access to any web page that displays restricted data must also be secured with a username and password, at a minimum. If you discover that any restricted data seems to be available in a web browser without requiring authentication, report it immediately to your security contact. 2.0 Uploading or downloading files to or from a web server The same rules for viewing restricting data in a web page applies to uploading or downloading files that contain restricted data via a web page. The url must begin with “https://” and the page must require authentication. If you see any violations of these rules, report immediately to your security contact. 3.0 Moving files to or from an FTP server Data may occasionally be moved to or from an FTP server. FTP stands for File Transfer Protocol and requires some kind of client software to interact with it. FTP is itself also intrinsically not secure. Never send restricted data to server using only the FTP protocol. There are variations of the FTP protocol that have been designed to be secure. The most common is SFTP. The others are somewhat more complicated and are not to be used except by trained security personnel. SFTP may be used by all employees who are authorized to work with restricted data. SFTP is also somewhat complicated to use safely because it doesn’t support the use of CA-issued certificates. The first time you connect to an SFTP server, the client will tell you if it has never seen the certificate before, and it should show you the thumbprint of the certificate. If you have not already received the thumbprint via a secure mechanism (such as https), or if the thumbprint doesn’t match what you’ve already received, your connection to the SFTP must not be regarded as secure. Report it to your security contact. If after establishing a secure connection with an SFTP server, your client then on a subsequent connection reports that it has never seen the certificate, do not go forward with the connection until establishing why the certificate has changed. 4.0 Moving files across a LAN file server Moving data across a LAN file server is generally just copying a file to or from a network drive to another network drive or a local drive using something like Windows Explorer. Moving data across a LAN must never be considered secure unless the LAN itself is considered secure as a whole. Confirm that the LAN is secure with your security contact before using it in this manner. 5.0 Using RDP Remote Desktop Protocol (RDP) is a common mechanism for working on a machine remotely. It is a proprietary Microsoft protocol and should only be used with a genuine Microsoft Remote Desktop Connection client. RDP has an issue with certificates similar to SFTP – it routinely creates certificates that are not signed by a CA. If your RDP client mentions that your connection is using an untrusted certificate, disconnect and alert your security contact. It may still be an acceptable connection, but it must be evaluated by an expert. If your RDP client doesn’t mention anything about the connection using an untrusted certificate, you may assume that the connection is safely encrypted. 6.0 Copying files via RDP Files may be copied and pasted from the remote machine to the client machine using RDP. These transfers are subject to the same restrictions as RDP itself in 5.0 above. If the connection is secure, files containing restricted data may be copied safely using RDP. 7.0 Moving data to or from a backup service We use Duplicati for our backups across unsecured networks. Duplicati itself encrypts all blocks transmitted to the data store, so all data is encrypted to start with. We use Amazon’s S3 service as our data store. When setting up a Duplicati backup job to S3, always select “Use SSL” to provide a second layer of encryption during transmission. 8.0 Sending data via email Sending data via email is sufficiently complicated to warrant its own section. See section “Data in Emails and Other Electronic Communication” below.

Data Leakage Prevention – Data at Rest Using this policy This policy applies to the handling of all restricted data that is stored on a device. It outlines the requirements for all employees to safely handle restricted data on devices. 1.0 Purpose Protecting data at rest is generally a simple matter of recognizing it and then either encrypting it or obfuscating it.

2.0 Scope The main ways data is at rest are: • On the host server machine • On portable production machine • On a stationary production machine • On a stationary development machine • On a portable demo machine • Copied in backup system • Printed hardcopy 3.0 Policy Our general policy to have restricted data at rest encrypted at all times on machines that are not physically secured. 1. On the host server machine Our host servers are in AWS using EBS volumes. EBS volumes are to be encrypted at all times. 2. On portable production machine Our software detects whether machines run on battery power. If detected, they are assumed to be portable machines and will automatically report in to HQServices whether they have BitLocker active on the main drive. If we get a report of a portable machine not using BitLocker, we will immediately initiate contact with the user to get the machine encrypted. 3. On a stationary production machine Stationary production machines are assumed to be under physical security. We do not monitor whether or not they are encrypted. 4. On a stationary development machine Stationary development machines are physically secured in our work environment and are not required to be encrypted. 5. On a portable demo machine Portable machines that may be carried out of our secure environment may not contain restricted data of any kind. 6. Copied in backup system Our Duplicati backup system automatically encrypts all data in the backup. Each machine using Duplicati must have its own unique encryption key. 7. Printed hardcopy Restricted data that has been printed must not be left out visible or permanently stored anywhere. Immediately after use, it must be shredded.

Portable Device Encryption Using this policy This policy applies to the use of encryption on portable devices.

1.0 Purpose Portable devices are at greatly increased risk of being lost, stolen, or connecting to hostile networks, thereby putting all data on these devices at much greater risk of exposure. However, these devices are also typically much less powerful than servers and desktop machines, so encryption far more greatly impacts performance. This policy is intended to take these factors into account.

2.0 Scope The policy applies to all devices that are commonly moved about outside of a single secure location either by our employees or our users.

3.0 Policy No employee should ever put restricted data of any kind on a portable device. Our portable devices do not need to be encrypted. Restricted data on portable user devices must be protected by full disk encryption. Our software will attempt to determine whether a device is portable and, if so, whether the device has full disk encryption by checking for the use of BitLocker. If it finds a portable device that is not secured with BitLocker, it will report this to HQServices and we will immediately work to get the device properly encrypted. If for some reason the device cannot be encrypted, we must report this in writing to our IT contact for the state and get written acknowledgement that they will take responsibility for securing the device. At that time, we can configure an override for BitLocker detection.

Password Management Using this policy This policy outlines the practices for management of passwords used by all our employees.

1.0 Purpose Passwords are the single most important aspect of security for our company, and the management of them is critically important to ensure the security of restricted data. This policy must be strictly adhered to.

2.0 Scope Every password used in connection with our work is within scope. This includes • Passwords created for accounts specifically for yourself • Passwords created to be shared among multiple employees • Passwords created to utilized by an automated process 3.0 Policy Every account that is secured with a password should have a unique password that is not used with any other account. There are very few exceptions to this rule, and they must be approved by the security officer in writing. We use KeePass to secure our passwords. Every employee must have his own KeePass database for storing personal passwords. Every KeePass database must have two forms of encryption: a key file and a password. The password must have at least 8 characters. The key file must not be accessible via any kind of sharing mechanism (networked drive, OneDrive, DropBox, Web Server, etc.). If the key file must be transmitted to another machine, it must be done so via a mechanism that does not retain copies. Mechanisms like OneDrive, DropBox, or email keep copies of files that are transmitted; do not use these mechanisms for transmitting a key file. Mechanisms like a shared folder on a LAN, a web server (via HTTPS only, not HTTP), or an SFTP server typically do not keep copies. The key file must immediately be removed from the mechanism after being transmitted. Passwords created must, of course, conform to the requirements of the host system, but in general should contain at least 8 characters and include a mix of letters, numbers, and symbols. Whenever practical, use much longer and more complex passwords. Multi-factor authentication should be used whenever it is available. When passwords must be communicated, either to us or to our users, they should never be put in visible form. Use telephone if possible. When it is necessary to use a password to connect to a remote system, consider whether the system on which you will type the password is more or less secure than the remote system. If it is less secure, consult with your security contact before making the connection.

Data in Emails and Other Electronic Communication Using this policy This policy addresses practices for sending restricted data in emails.

1.0 Purpose Emails are terribly difficult to secure when it comes to restricted data. If possible restricted data should simply never be sent via email. Other approaches such as sharing via a secured website or SFTP server are always preferable. But these mechanisms are often simply not available or are impractical for a variety of reasons, and email is almost always an option. This policy is about how to be aware of sending restricted data in an email, and how to do it reasonably securely.

2.0 Scope All restricted data that is included in an email sent by an employee is in scope.

3.0 Policy The most common way to include restricted data in an email is to copy from a controlled source and paste it into the email. Whenever pasting data into an email, consider whether it is restricted. It is often sufficient to simply replace PII in the data with Xs to mitigate the restricted nature of the data. Sometimes the copy paste is an image of restricted data rather than the restricted data itself. This is still not acceptable to send. Most screen capture tools allow the image to be altered before being used, so be sure to mark over any PII or other restricted data in the image before pasting it into the email. The final common way to include restricted data in an email is to attach a file which includes restricted data, such as a spreadsheet, pdf, or text file. It is common practice, but unacceptable, to zip the file with restricted data using a password, and then to send the password in a separate email. This makes the restricted marginally more secure. If the encrypted zip file is later left in an insecure location, it might be somewhat secure. But it’s much more likely for the entire email to be intercepted. If one can be intercepted, then the one with the password can likely be intercepted as well, and the encryption does no good whatsoever. If you simply must send an email with an attached file that has restricted data, zip the file with a password, and then communicate the password via a separate secure channel like a phone call or a text message. This is reasonably secure.

Physical Media Using this policy This policy addresses practices for handling physical media that contains restricted data.

1.0 Purpose The better part of keeping restricted data safe on physical media is to keep it encrypted or, better yet never let leave a secure area.

2.0 Scope All restricted data that is stored on physical media in the presence of an employee is in scope. This includes paper, optical disks, hard drives, thumb drives, etc.

3.0 Policy We will cover handling the major types of media separately. 1. Paper – Restricted data that been printed or written on paper should be kept track of until it is no longer needed. When it is no longer needed, it should be shredded immediately. 2. Optical disks – Since these cannot generally be erased, optical disks should be treated just like paper. They should be kept track of until they are no longer needed. When no longer needed they should be shredded immediately. 3. Hard drives – Hard drives, including SSD drives, containing restricted data that are taken outside the offices should be encrypted. It is permissible for them to be unencrypted if they never leave a secured location. Once a hard drive has been reached the end of its usefulness it must be wiped using Eraser using the US DoD 5220.22-M (3 passes) standard. 4. Thumb drives – Thumb drives should be treated exactly like hard drives. It is generally not practical to encrypt them, so they should never leave the secured location with restricted data. When they are no longer useful, it is not enough to format them, they must be wiped using the US DoD 5220.22-M (3 passes) standard.

Section 1194.22 Web-based Internet information and applications – Detail VPAT™

® Voluntary Product Accessibility Template

Supporting Criteria Remarks and explanations Features There are very few non-text (a) A text equivalent for elements in the system, but for every non-text element shall those that do exist, there is be provided (e.g., via "alt", Supported. always a corresponding text "longdesc", or in element element that will generally be content). rendered by text-to-speech systems. (b) Equivalent alternatives for any multimedia There are no multimedia presentation shall be N/A presentations in the system. synchronized with the presentation. (c) Web pages shall be designed so that all There is no information in the information conveyed with Supported. system conveyed exclusively by color is also available color. without color, for example from context or markup. All pages in the system can be read without a style sheet, but (d) Documents shall be we recognize there are varying organized so they are levels of readability. We don’t Supported readable without requiring think any information or an associated style sheet. functionality in the app is completely dependent upon CSS. (e) Redundant text links shall be provided for each There are no server-side image N/A active region of a server- maps in the system. side image map. (f) Client-side image maps shall be provided instead of server-side image maps There no client-side image N/A except where the regions maps in the system. cannot be defined with an available geometric shape. Telerik’s RadGrid is used extensively and exclusively for data tables in the system. Its WCAG and Sec. 508 (g) Row and column compliance is demonstrated headers shall be identified Supported here: for data tables. http://demos.telerik.com/aspnet- ajax/grid/examples/accessibility- and- internationalization/accessibility- compliance/defaultcs.aspx (h) Markup shall be used to associate data cells and As above, we use Telerik’s header cells for data tables Supported RadGrid exclusively for tabular that have two or more data. logical levels of row or column headers. There can be a good bit of (i) Frames shall be titled subjectivity about what with text that facilitates Supported constitutes a frame, but we feel frame identification and that every region within the app navigation is appropriately titled. (j) Pages shall be designed to avoid causing the screen to flicker with a frequency Supported greater than 2 Hz and lower than 55 Hz. (k) A text-only page, with equivalent information or functionality, shall be provided to make a web site We don’t know of any pages comply with the provisions that cannot comply, but we’ll of this part, when Supported provide text-only pages compliance cannot be whenever needed. accomplished in any other way. The content of the text-only page shall be updated whenever the primary page changes. (l) When pages utilize Scripting is used extensively scripting languages to within the system. While we display content, or to create aren’t aware of any cases in interface elements, the which information embedded in Largely information provided by the a script is not also rendered in a supported. script shall be identified with way accessible to assistive functional text that can be technology, we acknowledge read by Assistive there may be cases we’re Technology. unaware of. (m) When a web page requires that an applet, plug-in or other application be present on the client the system doesn’t require any system to interpret page N/A applets, plug-ins, or other content, the page must applications to function. provide a link to a plug-in or applet that complies with §1194.21(a) through (l). (n) When electronic forms are designed to be completed on-line, the form shall allow people using Assistive Technology to We periodically review the app access the information, field Supported. with JAWS to test whether all elements, and functionality form elements are accessible. required for completion and submission of the form, including all directions and cues. (o) A method shall be The header menu at the top of provided that permits users Not fully each page may be regarded as to skip repetitive navigation supported repetitive. links. (p) When a timed response The only functionality like this is is required, the user shall the auto-logout, but it displays be alerted and given Supported an alert and gives five minutes sufficient time to indicate before logging the user out. more time is required.

Management Services

EQUAL OPPORTUNITY POLI CY

July 13, 2017

Objective We are an equal opportunity employer. In accordance with anti-discrimination law, it is the purpose of this policy to effectuate these principles and mandates. We prohibit discrimination and harassment of any type and affords equal employment opportunities to employees and applicants without regard to race, color, religion, sex, national origin, age, disability or genetic information. We conform to the spirit as well as to the letter of all applicable laws and regulations. Additionally, we will take action to employ, advance in employment and treat qualified Vietnam-era veterans and disabled veterans without discrimination in all employment practices.

Scope The policy of equal employment opportunity (EEO) and anti-discrimination applies to all aspects of the relationship between the organization and its employees, including:

· Recruitment.

· Employment.

· Promotion.

· Transfer.

· Training.

· Working conditions.

· Wages and salary administration.

· Employee benefits and application of policies.

The policies and principles of EEO also apply to the selection and treatment of independent contractors, personnel working on our premises who are employed by temporary agencies and any other persons or firms doing business for or with us.

Dissemination and Implementation of Policy The officers of our organization will be responsible for the dissemination of this policy. Directors, managers and supervisors are responsible for implementing equal employment practices within each department. The HR department is responsible for overall compliance and will maintain personnel records in compliance with applicable laws and regulations.

Procedures Our administers our EEO policy fairly and consistently by:

· Posting all required notices regarding employee rights under EEO laws in areas highly visible to employees.

· Advertising for job openings with the statement “An Equal Opportunity Employer—M/F/D/V.”

· Posting all required job openings with the appropriate state agencies.

· Forbidding retaliation against any individual who files a charge of discrimination, opposes a practice believed to be unlawful discrimination, reports harassment, or assists, testifies or participates in an EEO agency proceeding.

· Requires employees to report to a member of management, an HR representative or the general counsel any apparent discrimination or harassment. The report should be made within 48 hours of the incident.

· Promptly notifies the general counsel of all incidents or reports of discrimination or harassment and takes other appropriate measures to resolve the situation.

Harassment Harassment is a form of unlawful discrimination and violates our policy. Prohibited sexual harassment, for example, is defined as unwelcome sexual advances, request for sexual favors and other verbal or physical conduct of a sexual nature when:

· Submission to such conduct is made either explicitly or implicitly a term or condition of an individual’s employment.

· Submission to or rejection of such conduct by an individual is used as the basis for employment decisions affecting such individuals.

· Such conduct has the purpose or effect of substantially interfering with an individual’s work performance or creating an intimidating, hostile or offensive working environment.

We encourage employees to report all incidents of harassment to a member of management or the HR department. We conduct harassment prevention training for all employees and maintains and enforces a separate policy on harassment prevention, complaint procedures and penalties for violations. We investigate all complaints of harassment promptly and fairly, and, when appropriate, takes immediate corrective action to stop the harassment and prevent it from recurring.

Remedies Violations of this policy, regardless of whether an actual law has been violated, will not be tolerated. We will promptly, thoroughly and fairly investigate every issue that is brought to its attention in this area and will take disciplinary action, when appropriate, up to and including termination of employment.