MCSS IT-Supplemental.docx
DOCX document 2 MB Posted
- Attached to
- Event Management Platform
- Solicitation number
- BPM058710
- Issued by
- Maryland
About this file
This is an Information Technology Supplemental document for the Maryland State Department of Education's Contract Monitoring and School Support (MCSS) division, detailing requirements for an Event Management Platform Software as a Service (SaaS) procurement. The project involves implementing a customizable event management platform to support MCSS's annual School Safety Conference held in July, with functionality encompassing registrations, kiosks and check-ins, badge printing, attendance tracking, surveys, speaker portfolio management, and exhibitor profile management. Key deliverables include an in-person or virtual kick-off meeting within five business days of Notice to Proceed, comprehensive training services and documentation, monthly status reports with dashboard metrics, transition and implementation plans due within ten business days of NTP, post-implementation support plans before go-live, support process maps, accommodations reports, technical error tracking reports, data files following each assessment administration window, quality assurance documentation, detailed project schedules due within 30 days of NTP, and meeting minutes posted within three days of status meetings. The Contractor is responsible for acquiring all hardware, software, and network support, with cloud-based applications accessible via web browser or program interface, and must stage software releases in the State's testing environment.
The Contractor must provide 24-hour technical support, seven days per week, 365 days per year, with emergency system issues responded to within one hour and non-emergency requests within three hours or by the next business day. Help Desk services are available during normal State business hours with ticketing system requirements including date, timestamp, and full audit trails. The Contractor shall perform daily incremental and weekly full backups, retaining daily backups for one month and weekly backups for three years. Service Level Agreements (SLAs) are effective upon completion of the Transition-In Period, with the Contractor required to provide monthly SLA performance reports by the 15th of the following month, and service credits applied cumulatively for any missed performance measurements. Maintenance commences upon State acceptance of initial startup activities and includes software changes, modifications, updates, patching, bug fixes, vulnerability fixes, and enhancements for current and one previous software version at no additional charge. No international storage or processing of State data is permitted, and any open-source software proposed must include operational support for maintenance and security updates.
View the file
Other files
Show all 23
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Information Technology (IT) Supplemental
This supplemental contains additional requirements under Section 2 of the solicitation.
1.1 Deliverables
1.1.1 Deliverable Submission
A. For every deliverable, the Contractor shall request the Contract Monitor confirm receipt of that deliverable by sending an e-mail identifying the deliverable name and date of receipt.
B. For every deliverable, the Contractor shall submit to the Contract Monitor, by email, an Agency Deliverable Product Acceptance Form (DPAF), an example of which is provided on the DoIT web page here:
https://procurement.maryland.gov/wp-content/uploads/sites/12/2024/07/Exhibit-3.-Deliverable-Product-Acceptance-Form-DPAF.docx C. Unless specified otherwise, written deliverables shall be compatible with Microsoft Office, Microsoft Project or Microsoft Visio within two versions of the current version. At the Contract Monitor’s discretion, the Contract Monitor may request one hard copy of a written deliverable.
D. A standard deliverable review cycle will be elaborated and agreed-upon between the State and the Contractor. This review process is entered into when the Contractor completes a deliverable.
A. For any written deliverable, the Contract Monitor may request a draft version of the deliverable, to comply with the minimum deliverable quality criteria listed in Section 2.4 Minimum Deliverable Quality. Drafts of each final deliverable, except status reports, are required at least two weeks in advance of when the final deliverables are due (with the exception of deliverables due at the beginning of the project where this lead time is not possible, or where draft delivery date is explicitly specified). Draft versions of a deliverable shall comply with the minimum deliverable quality criteria listed in Section 2.4 Minimum Deliverable Quality.
1.1.2 Deliverable Acceptance
A. A final deliverable shall satisfy the scope and requirements of this RFP for that deliverable, including the quality and acceptance criteria for a final deliverable as defined in Section 2.4 Deliverable Descriptions/Acceptance Criteria.
B. The Contract Monitor shall review a final deliverable to determine compliance with the acceptance criteria as defined for that deliverable. The Contract Monitor is responsible for coordinating comments and input from various team members and stakeholders. The Contract Monitor is responsible for providing clear guidance and direction to the Contractor in the event of divergent feedback from various team members.
C. The Contract Monitor will issue to the Contractor a notice of acceptance or rejection of the deliverable in the DPAF (see online sample). Following the return of the DPAF indicating “Accepted” and signed by the Contract Monitor, the Contractor shall submit a proper invoice in accordance with the procedures in Section 3.3. The invoice must be accompanied by a copy of the executed DPAF or payment may be withheld.
B. In the event of rejection, the Contract Monitor will formally communicate in writing any deliverable deficiencies or non-conformities to the Contractor, describing in those deficiencies what shall be corrected prior to acceptance of the deliverable in sufficient detail for the Contractor to address the deficiencies. The Contractor shall correct deficiencies and resubmit the corrected deliverable for acceptance within the agreed-upon time period for correction.
1.1.3 Minimum Deliverable Quality
The Contractor shall subject each deliverable to its internal quality-control process prior to submitting the deliverable to the State.
Each deliverable shall meet the following minimum acceptance criteria:
A. Be presented in a format appropriate for the subject matter and depth of discussion.
B. Be organized in a manner that presents a logical flow of the deliverable’s content.
C. Represent factual information reasonably expected to have been known at the time of submittal.
D. In each section of the deliverable, include only information relevant to that section of the deliverable.
E. Contain content and presentation consistent with industry best practices in terms of deliverable completeness, clarity, and quality.
F. Meets the acceptance criteria applicable to that deliverable, including any State policies, functional or non-functional requirements, or industry standards.
G. Contains no structural errors such as poor grammar, misspellings or incorrect punctuation.
H. Must contain the date, author, and page numbers. When applicable for a deliverable, a revision table must be included.
C. A draft written deliverable may contain limited structural errors such as incorrect punctuation, and shall represent a significant level of completeness toward the associated final written deliverable. The draft written deliverable shall otherwise comply with minimum deliverable quality criteria above.
1.1.4 Deliverable Descriptions/Acceptance Criteria
In addition to the items identified in the table below, the Contractor may suggest other subtasks, artifacts, or deliverables to improve the quality and success of the assigned tasks.
Deliverables Summary Table*
| ID # |
| Deliverable Description |
| Acceptance Criteria |
| Due Date / Frequency |
| 1.1.4.1 |
| In-Person or Virtual Kick-off meeting with agenda and Contractor’s contact list |
| Format: Microsoft Word or PDF |
Agreed upon agenda and presentation materials in Microsoft Office formats for kick-off meeting. The kick-off meeting materials shall cover:
· Introduction of personnel from the Contractor team and MCSS
· Review of work plan
· Discussion of assumptions, risks, and issues Logistics for communications.
· Additional topics as determined necessary
Planned within five Business Days of Notice to Proceed (NTP)
| 1.1.4.2 |
| Training Services and Related Documentation |
| Deliver Professional Training Services and training materials for use of the System and all its functionality. |
The Contractor shall deliver the Training documentation. The Training Plan includes the following sections at a minimum:
· In-depth administrator-level training for MCSS administration team.
As outlined in the Contractor’s proposed development increments and updated as the initial RFP fixed scope of work progresses.
| 1.1.4.3 |
| Monthly Status Report (Pre-production /Go- Live) |
| A monthly status report that includes: |
· Dashboard that provides charts on credits usage, number of communications, registration stats and overall project progress.
· High level summary of the overall project status, including accomplishments for the reporting period.
· Description of project milestones achieved in the reporting period, and status of upcoming milestones.
· Summary of risks and issues impacting the project Monthly – date determined by the Contract Monitor
| 1.1.4.4 |
| Transition & Implementation Plans |
| The Implementation Plan shall be delivered in MS Word format to the Contract Monitor and shall provide a description of all the work to be performed throughout the project. |
The Transition Plans shall include the following:
· Transition from current Event Management vendors
· Transfer of user data, metadata, exhibitor and speaker data, and associated materials
· Transfer/remapping of MCSS owned domain used in conference website.
· Plan for measuring Metrics/Outcomes
· Interface Control Document
· Security Plan & Disaster Recovery Plan
· Infrastructure Plan
· Outage Communication plan
· Field Training Roadmap and plans Initial Delivery:
NTP + 10 Business Days, and updates as needed or requested.
Updates for Project Schedule: Weekly
| 1.1.4.5 |
| Post Implementation Plan |
| · The Post Implementation Plan shall be delivered in MS Word/PDF format to the Contract Monitor before go-live and the plan shall include: |
· Description of the process to be used by MCSS to obtain operational system support for the System;
· A description of the Contractor’s support organization with contact names, e-mail addresses and telephone numbers;
· A description of the SLA between the Contractor and MCSS, plus the process to be used by the Contractor to ensure that these service levels are maintained;
· Trouble Ticket escalation procedures;
· A description of pre-scheduled maintenance policies and windows for operation;
· Backup and restore procedures As outlined in the Contractor’s proposed development increments and updated as the initial RFP fixed scope of work progresses.
| 1.1.4.6 |
| Support and Technical Assistance process map |
| The contractor will develop with MCSS’s input a process map that will triage support and technical requests made by the MCSS administrative users. |
| Throughout the contractual period. |
| 1.1.4.7 |
| Accommodations reports |
| User feedback (multiple stakeholders); improvement suggestions |
| Following each month of development and testing. |
| 1.1.4.8 |
| Technical error tracking reports |
| Performance metrics in real time, including lags in performance and error codes |
| Following each support incident. |
| 1.1.4.9 |
| Ad hoc reports |
| To support reporting results |
| As needed |
| 1.1.4.10 |
| Data files |
| According to file layout as specified by MCSS or other transmission guidelines; complete information about attendees within the legal guardrails that govern data collection. This includes demographics, including gender, gender race/ethnicity, multilingual learner status, economically disadvantaged status, and disability status. |
| Following each of the assessment administration window |
| 1.1.4.11 |
| Report of discrepancy resolution |
| Documenting score recalibration, revising equating methods, or providing supplemental analyses to clarify findings |
| Before each summer conference |
| 1.1.4.12 |
| Document repository |
| Role-based access control; revision tracking and change logs |
| Planned within four months of Notice to Proceed (NTP) |
| 1.1.4.13 |
| Detailed project schedules |
| Must include timelines for key functional areas such as development, administration, registrations, onboarding, communications, and reporting. |
| NTP + 30 |
| 1.1.4.14 |
| Quality assurance process |
| Must document version control and change log; show evidence of auditing test form construction, administration, and reporting |
| Ongoing throughout contract term |
| 1.1.4.15 |
| Meeting agendas, status updates, and meeting minutes with action items. |
| Regular updates; also, to accommodate adjustments to item targets |
| Minutes posted within three days of status update meetings starting with the initial planning meeting. |
| 1.1.4.16 |
| Training and Technical Support |
| Training for admins, and if needed, MCSS staff; all materials and meeting coordination; evaluation survey |
| Prior to registration |
*The deliverables summary table may not list every contractually required deliverable. Offerors and Contractors should read the RFP thoroughly for all Contract requirements and deliverables.
| 1.2 | Contractor-Supplied Hardware, Software, and Materials |
| A. | The Contractor is responsible for the acquisition and operation of all hardware, software and network support related to the services being provided. However, the State has the right to purchase hardware, software, and hosting services from a source other than the Contractor if it is determined to be in the best interest of the State based on value and price. |
| B. | Cloud-based applications shall be accessible from various client devices through a thin client interface such as a Web browser or a program interface. |
| C. | For projects that require Contractor supplied materials, the costs for the materials shall be passed through to the State with no mark-up by the Contractor. |
| D. | The Contractor shall prepare software releases and stage each release in the system testing environment at the State for validation. The State will have the ability to manage the distribution of these releases to the appropriate sites. (Note: To support this requirement, the Offeror shall propose, provide and fully describe their solution for updating all sites with any new software releases.) |
| E. | The State shall receive the manufacturer or provider’s standard warranty for hardware and software provided under the Contract, the details for which must be described in the Offeror’s Technical Proposal. Any warranty period for goods and services will not commence until acceptance of the products or services by the State of Maryland. Notwithstanding anything to the contrary, all defective items must be replaced within a reasonable time at no additional cost to the State. |
| 1.3 | Product Requirements |
| A. | Open-source software may be proposed; however, operational support for the proposed software must also be proposed. Operational support shall include maintenance and updating of code to address software dependencies, software updates and security vulnerabilities. |
| B. | Bidders/Offerors proposing to resell services of another entity must be authorized by such other entity. |
| C. | No international storage or processing for State Data: Bidders/Offerors are advised that any processing or storage of data outside of the continental U.S. is strictly prohibited. |
| D. | Any terms of use or other agreement applicable to the Bidder’s/Offeror’s proposed services must be contained in the Bidder’s/Offeror’s Technical Proposal. The State is not subject to any terms of use or other agreement applicable to the Bidder’s/Offeror’s proposed services unless the same are explicitly agreed to by the State during the Proposal evaluation process. |
| E. | The State does not recognize and is not subject to any auto-renewal of services provision that may be contained or provided for in any Contractor agreements. |
| 1.4 | Maintenance |
Maintenance and support, and Contractor’s ongoing maintenance and support obligations, are defined as follows:
| A. | Maintenance commences at the State acceptance of initial startup activities. Billing for such maintenance and support shall commence after State acceptance of initial startup activities. | Comment by Hoover, Lydia: When does this being and where/how is this reflected on the price form? | Comment by Jenna Meinl: Program to confirm. Procurement to check on. |
| B. | Software maintenance includes all software changes, modifications, updates, patching, bug fixes, vulnerability fixes, and enhancements applicable to all system modules licensed without further charge to all licensed users maintaining a renewable software support contract. | ||
| C. | Maintenance shall be provided for superseded releases and back releases still in use by the State. | ||
| D. | For the first year and all subsequent Contract years, the following services shall be provided for the current version and one previous version of any Software provided with the Deliverables, commencing upon commencement: | ||
| 1) | Error Correction. Upon notice by the State of a problem with the Software (which problem can be verified), reasonable efforts to correct or provide a working solution for the problem. | ||
| 2) | Material Defects. Contractor shall notify the State of any material errors or defects in the Deliverables known, or made known to Contractor from any source during the life of the Contract that could cause the production of inaccurate or otherwise materially incorrect results. The Contractor shall initiate actions as may be commercially necessary or proper to effect corrections of any such errors or defects. | ||
| 3) | Vulnerabilities. Contractor shall notify the State of any vulnerabilities of which it is or becomes aware, that could allow unauthorized access, disclosure, or modification of data, applications, or systems. The Contractor shall fix all vulnerabilities in accordance with the State’s IT Security Manual. | ||
| 4) | Updates. Contractor will provide to the State at no additional charge all new releases and bug fixes (collectively referred to as “Updates”) for any software Deliverable developed or published by the Contractor and made available to its other customers. | ||
| E. | Activity reporting | ||
| 1.4.1 | Technical Support | ||
| A. | Technical Support” means Contractor-provided assistance for the services or Solution furnished under the Contract, after initial end-user support confirms a technical issue that requires additional troubleshooting capabilities; sometimes referenced as Tier II – IV support. | ||
| B. | The Contractor shall provide 24-hour IT technical assistance | ||
| C. | The State shall be able to contact a Technical Support team member 24 hours per day, 7 days per week, 365 days per year, based on the Tier defined in the Service Level Agreement. | ||
| D. | Contractor Personnel providing technical support shall be familiar with the State’s account (i.e., calls shall not be sent to a general queue). | ||
| E. | Contractor shall return calls for service of emergency system issues within one hour or per the Service Level Agreement. | ||
| F. | Calls for non-emergency IT service requests will be returned within three hours or immediately the following day after Normal State Business Hours. | ||
| G. | The State shall be provided with information on software problems encountered at other locations, along with the solution to those problems, when relevant to State software. | ||
| H. | User support (Help Desk) |
1) Contractor shall furnish Help Desk services for the Event Management Platform.
2) Help Desk services are available during Normal State Business Hours.
3) Contractor shall utilize a help desk ticketing system to record and track all help desk calls. The ticketing system shall record with a date and timestamp when the ticket was opened and when the ticket was closed as well as which personnel at the organization handled and resolved the ticket with a full audit trail of activity as well as which personnel at the organization handled and resolved the ticket with a full audit trail of activity.
1.4.2 Backup
The Contractor shall:
| A. | Perform backups of the web, application, and database servers on a regular basis. This shall include daily incremental backups and full weekly backups of all volumes of servers; |
| B. | Retain daily backups for one month and weekly backups shall be retained for three years. |
| 1.5 | Service Level Agreement (SLA) |
| 1.5.1 | Definitions |
| A. | A “Problem” is defined as any situation or issue or breach or potential breach related to the system operation and is not an enhancement request that is reported to the Contractor. The Contractor shall utilize a tracking system, e.g. help desk ticket system, to track, update, and report the status of all reported problems. |
| B. | “Problem resolution time” is defined as the period of time from when the issue was reported to the Contractor to when it is resolved to the satisfaction of the State. |
| 1.5.2 | SLA Requirements |
The Contractor shall:
| A. | Be responsible for complying with all performance measures and shall also ensure compliance by all subcontractors. | |
| B. | Meet the Problem Response Time and the Problem Resolution Time requirements as defined in Section 1.5.8 | |
| C. | Provide a monthly report to monitor and detail response times and resolution times. | |
| D. | Respond to and update all Problems, including recording when a Problem is resolved and its resolution. Appropriate State of Maryland personnel shall be notified when a Problem is resolved. | |
| E. | The State of Maryland shall make the final determination regarding Problem severity as defined in Section 1.5.8. | |
| F. | Contractor shall review any Problem with the State of Maryland to establish the remediation plan and relevant target dates. | |
| 1.5.3 | SLA Effective Date (SLA Activation Date) | |
| SLAs set forth herein shall be in effect beginning with the commencement of services as of the completion of the Transition-In Period. | Comment by Hoover, Lydia: What is the transition in period? That needs to be defined somewhere. | Comment by Jenna Meinl: Program |
| 1.5.4 | Service Level Reporting | |
| A. | Contractor performance will be monitored by the State of Maryland. | |
| B. | The Contractor shall provide summarized SLA performance and detailed monthly reports evidencing the attained level for each SLA. All monthly reports shall highlight any SLA performance criteria that did not meet the compliance requirement designated in the SLA provided in Section 2.6.7. The Contractor shall provide an explanation of why any SLA was not met. For any problems not resolved the Contractor shall provide an explanation of how and when it will be met in the future. | |
| C. | Monthly reports shall be delivered via e-mail to the Contract Monitor by the 15th of the following month. | |
| 1.5.5 | SLA Service Credits |
Beginning on the SLA Activation Date, for any performance measurement not met during the monthly reporting period, the SLA credit for that individual measurement shall be applied to the overall Charges.
Service credits will be cumulative for each missed service requirement. The State, at its option for amounts due to the State as service credits, may deduct such from any money payable to the Contractor or may bill the Contractor as a separate item. In the event of a catastrophic failure affecting all services, in addition to all other rights and remedies available to the State, all affected SLAs shall be credited to the State.
1.5.6 Service Level Measurements Table (System performance)
Offeror shall complete the table below with its proposed service level metrics and SLA credits.
No. Service Requirement Measurement Service Level Agreement SLA Credit
| No. |
| Service Requirement |
| Measurement |
| Service Level Agreement |
| SLA Credit |
| 1 |
| Problem Response Time – High (example) |
| (Example) Average Response Time for High Priority Problems. |
| 98% <15 minutes |
| 1% |
The Contractor shall comply with the service level measurements in the following table:
| No. |
| Service Requirement |
| Measurement |
| Service Level Agreement (SLA) |
| SLA Credit |
| 1 |
| Overall System Availability |
| Percentage of time the core application is operational and accessible, excluding scheduled maintenance. |
| 99.95% Monthly Uptime |
| 2% of Monthly Fee for every 0.1% drop below 99.95% |
| 2 |
| Peak Transaction Response Time (Check-ins/Registration) |
| Average API latency for critical write operations (e.g., 'submit registration', 'check-in attendee') during the event's highest traffic periods. |
| Average Response Time (95th Percentile) |
| 1% of Monthly Fee if 95th percentile exceeds 750ms for more than 6 consecutive hours. |
| 3 |
| Event Page Load Time (End-User) |
| Average time taken to fully load the primary Event Landing Page and Registration Forms, measured across three locations. |
| Average Fully Loaded Time < 2.0 seconds (un-cached) |
| 1% of Monthly Fee if average load time exceeds 3.0 seconds for more than 12 hours |
| 4 |
| High-Volume Capacity (Concurrent Users) |
| Maximum number of concurrent users (attendees/staff) the platform can support without experiencing degradation in service (response time > 500ms). |
| Guaranteed capacity of 1000 concurrent active users per event. |
| 5% of Monthly Fee if the system fails at < 90% of the guaranteed capacity during load testing or a live event. |
| 5 |
| Core Data Transaction Success Rate |
| Percentage of successful data commits for critical back-end actions (e.g., saving a speaker bio, confirming payment status, logging a check-in). |
| 99.99% Success Rate (1 error per 10,000 transactions) |
| 3% of Monthly Fee if the success rate drops below 99.9% in any calendar day. |
| 6 |
| Real-time Report Generation |
| Time taken to generate and display complex operational reports (e.g., full attendee list, custom data filter reports) with >10,000 records. |
| Report generation time < 30 seconds. |
| 1% of Monthly Fee per instance where report generation exceeds 60 seconds (Max 5% monthly credit). |
| 7 |
| Content Retrieval Latency |
| Average time to retrieve and display essential content (session descriptions, materials, exhibitor profiles) within the mobile/web app. |
| Average retrieval time < 1.0 second. |
| 1% of Monthly Fee if average retrieval time exceeds 2.0 seconds for more than 24 consecutive hours. |
| 8 |
| Scheduled Maintenance Downtime |
| Total time required for planned system updates, deployments, or database maintenance. |
| Max 4 hours per month, to be scheduled outside of peak usage times (e.g., 8 AM - 8 PM client's primary time zone). |
| 1% of Monthly Fee for every additional hour over the 4-hour limit without 48 hours prior notification. |
| 9 |
| Post-Event Data Processing & Availability |
| Time taken to process and make aggregated and raw survey/training data available for export and analysis after the event concludes. |
| All aggregated data available within 4 hours of the survey |
| Post-Event Data Processing & Availability |
| 10 |
| Critical System Failure Time to Restore (TTR) |
| Time elapsed from the service provider confirming a P1 System Failure (e.g., inability to process any check-ins) until the service is fully restored. |
| Time to Restore (TTR) < 60 minutes. |
| 5% of Monthly Fee for every additional 30 minutes of P1 downtime beyond the 60-minute TTR. |
1.5.7 Problem Response Definitions and Times
The Contractor shall meet the Problem Response Time and Problem Resolution Time requirements.
The Contractor shall provide a monthly report to monitor and detail response times and resolution times.
1.6 Required Project Policies, Guidelines and Methodologies
The Contractor must comply with all applicable laws, regulations, policies, standards and guidelines affecting Information Technology projects, which may be created or changed periodically. These include, but are not limited to:
| Reference |
| Regulations, Policies, Guidelines and Methodologies |
| A |
| The State of Maryland System Development Life Cycle (SDLC) methodology https://doit.maryland.gov/SDLC/Pages/agile-sdlc.aspx |
| B |
| The State of Maryland Information Technology Security Policy and Standards at: https://doit.maryland.gov/policies/Pages/ContractPolicies.aspx |
| C |
| The State of Maryland Information Technology Non-Visual Standards at: https://doit.maryland.gov/policies/Pages/nva.asp |
| D |
| The State of Maryland Information Technology Project Oversight at: https://doit.maryland.gov/epmo/Pages/ProjectOversight.aspx |
| E |
| The Contractor shall follow project management methodologies consistent with the most recent edition of the Project Management Institute’s Project Management Body of Knowledge Guide. |
| F |
| Hardware and Software hardening procedures by Center for Internet Security (CIS) guides https://www.cisecurity.org/ or Security Requirements Guides (SRG) http://www.nist.gov |
| G |
| Federal Information Processing Standards (FIPS), “Security Requirements for Cryptographic Modules”, FIPS PUB 140-3: |
https://csrc.nist.gov/publications/detail/fips/140/3/final https://csrc.nist.gov/Projects/cryptographic-module-validation-program/fips-140-3-standards
| H |
| Purchasing and Recycling Electronic Products https://dgs.maryland.gov/Pages/GreenPurchasing/Resources/Electronics.aspx |
| 1.7 | Disaster Recovery and Data |
| 1.7.1 | Redundancy, Data Backup and Disaster Recovery |
a) Unless specified otherwise, throughout the Contract term, the Contractor shall maintain or cause to be maintained disaster avoidance procedures designed to safeguard State data and other confidential information, Contractor’s processing capability and the availability of hosted services. Any force majeure provisions of the Contract do not limit the Contractor’s obligations under this provision.
b) The Contractor shall have robust contingency and disaster recovery (DR) plans in place to ensure that the services provided under the Contract will be maintained in the event of disruption to the Contractor/subcontractor’s operations (including, but not limited to, disruption to information technology systems), however caused.
1) The Contractor shall furnish a DR site.
2) The DR site shall be at least 100 miles from the primary operations site, and have the capacity to take over complete production volume in case the primary site becomes unresponsive.
c) The contingency and DR plans must be designed to ensure that services under the Contract are restored after a disruption within 24 hours from notification, with a recovery point objective of one hour or less prior to the outage to avoid unacceptable consequences due to the unavailability of services.
d) The Contractor shall test the contingency/DR plans at least twice annually to identify any changes that need to be made to the plan(s) to ensure a minimum interruption of service. Coordination shall be made with the State to ensure limited system downtime when testing is conducted. At least one annual test shall include backup media restoration and failover/fallback operations at the DR location. The Contractor shall send the Contract Monitor a notice of completion following completion of DR testing.
e) Such contingency and DR plans shall be available for the State to inspect and practically test at any reasonable time, and subject to regular updating, revising, and testing throughout the term of the Contract.
1.7.2 Data Export/Import
a) The Contractor shall, at no additional cost or charge to the State, in an industry standard/non-proprietary format:
1) perform a full or partial import/export of State data within 24 hours of a request; or
2) provide to the State the ability to import/export data at will and provide the State with any access and instructions which are needed for the State to import or export data.
b) Any import or export shall be in a secure format per the Security Requirements.
1.7.3 Data Ownership and Access
As set forth in the Contract, data, databases and derived data products created, collected, manipulated, or directly purchased as part of the solicitation are the property of the State. The purchasing State agency is considered the custodian of all State data. The use, access, and distribution of all data shall comply with the requirements of the Data Use Agreement (Attachment Y).
The Contractor may not access State data other than as necessary to perform the services under this Contract.
The Contractor shall limit access to and use of State data to Contractor Personnel whose responsibilities require such access or use and shall train such Contractor Personnel on the confidentiality obligations set forth herein.
At no time shall any data or processes – that either belong to or are intended for the use of the State or its officers, agents or employees – be copied, disclosed or retained by the Contractor or any party related to the Contractor for subsequent use in any transaction that does not include the State.
The Contractor shall not use any information collected in connection with the services furnished under the Contract for any purpose other than fulfilling such services.
Provisions in Sections 1.8.1 - 1.8.3 shall survive expiration or termination of the Contract. Additionally, the Contractor shall flow down the provisions of Sections 1.8.1 - 1.8.3 (or the substance thereof) in all subcontracts.
1.8 Security Requirements
The following requirements are applicable to the Contract:
1. Employee Identification
a) Contractor Personnel shall display his or her company ID badge in a visible location at all times while on State premises. Upon request of authorized State personnel, each Contractor Personnel shall provide additional photo identification.
b) Contractor Personnel shall cooperate with State site requirements, including but not limited to, being prepared to be escorted at all times, and providing information for State badge issuance.
c) Contractor shall remove any Contractor Personnel from working on the Contract where the State determines, in its sole discretion, that Contractor Personnel has not adhered to the Security requirements specified herein.
d) The State reserves the right to request that the Contractor submit proof of employment authorization of non-United States Citizens, prior to commencement of work under the Contract.
2. Security Clearance / Criminal Background Check The State reserves the right to refuse any individual Contractor Personnel to work on State premises, based upon certain specified criminal convictions, as specified by the State.
1. A criminal background check for each for any Contractor Personnel providing on-site or for any specific services shall be completed prior to each Contractor Personnel providing any services under the Contract.
1. The Contractor shall obtain at its own expense a Criminal Justice Information System (CJIS) State and federal criminal background check, including fingerprinting, for all Contractor Personnel listed in sub-paragraph A. This check may be performed by a public or private entity.
The Contractor shall provide the Contract Monitor with certification of completion of the required criminal background check described in this IFB for each required Contractor Personnel prior to assignment, and that the Contractor Personnel have successfully passed this check.
1. Persons with a criminal record may not perform services under the Contract unless prior written approval is obtained from the Contract Monitor. The Contract Monitor reserves the right to reject any individual based upon the results of the background check. Decisions of the Contract Monitor as to acceptability of a candidate are final.
1. The CJIS criminal record check of each Contractor Personnel who will work on State premises shall be reviewed and documented by the Contractor for convictions of any of the following crimes described in the Annotated Code of Maryland, Criminal Law Article:
a) §§ 6-101 through 6-104, 6-201 through 6-205, 6-409 (various crimes against property);
b) any crime within Title 7, Subtitle 1 (various crimes involving theft);
c) §§ 7-301 through 7-303, 7-313 through 7-317 (various crimes involving telecommunications and electronics);
d) §§ 8-201 through 8-302, 8-501 through 8-523 (various crimes involving fraud);
e) §§9-101 through 9-417, 9-601 through 9-604, 9-701 through 9-706.1 (various crimes against public administration); or
f) a crime of violence as defined in CL § 14-101(a).
1. Contractor Personnel that would have access to systems supporting the State or to State data who have been convicted of a felony or convicted of a crime involving telecommunications and electronics or convicted within the past five (5) years of a misdemeanor from the above list of crimes shall not be permitted to work on the Contract.
1. A particular on-site location covered by the Contract may require more restrictive conditions regarding the nature of prior criminal convictions that would result in Contractor Personnel not being permitted to work on those premises. Upon receipt of a location’s more restrictive conditions regarding criminal convictions, the Contractor shall provide an updated certification regarding the Contractor Personnel working at or assigned to those premises.
1. On-Site Security Requirement(s)
THIS SECTION IS INAPPLICABLE TO THIS IFB.
| 1.8.4 | Information Technology Security | |
| A. | Contractors shall comply with and adhere to the State IT Security Manual, Policies and Standards. These policies may be revised from time to time and the Contractor shall comply with all such revisions. Updated and revised versions of the State IT Policy and Standards are available online at: Policies, Standards, and Guidelines. | |
| B. | The Contractor shall not connect any of its own equipment to a State LAN/WAN without prior written approval by the State as directed and coordinated with the Contract Monitor. |
The Contractor shall:
| 1) | For IT Security Policies and Standards that are no covered by the State IT Security Manual, the Contract shall Implement administrative, physical, and technical safeguards to protect State data that are no less rigorous than accepted industry best practices for information security such as those listed below (see Section 1.6.5) | |
| 2) | Ensure that all such safeguards, including the manner in which State data is collected, accessed, used, stored, processed, disposed of and disclosed, comply with applicable data protection and privacy laws as well as the terms and conditions of the Contract; and | |
| 3) | Ensure compliance with all applicable federal, State, and local laws, rules and regulations concerning security of Information Systems and Information Technology. | |
| 1.8.5. | Data Protection and Controls |
A. Contractor shall ensure a secure environment for all State data and any hardware and software (including but not limited to servers, network and data components) provided or used in connection with the performance of the Contract according to a written security policy (“Security Plan”) no less rigorous than that of the State and using best practices that comply with an accepted industry standard, such as the NIST cybersecurity framework.
1) The Security Plan shall detail the steps and processes employed by the Contractor as well as the features and characteristics which will ensure compliance with the security requirements of the Contract. Such Security Plan shall be provided to the State for its review with solicitation response. If awarded a contract, the Security Plan shall be provided on an annual basis or whenever updates are made.
2) The Contractor shall supply a copy of such policy to the State for validation, with any appropriate updates, on an annual basis.
3) If any Security Plan information, including procedures, are different based on a Task Order, Contractor shall furnish such differences to the respective TO Manager.
B. To ensure appropriate data protection safeguards are in place, the Contractor shall implement and maintain the following controls during the Contract Term (the Contractor may augment this list with additional controls):
1) Establish separate production, test, and training environments for systems supporting the services provided under the Contract and ensure that production data is not utilized in test or training environment(s).
2) Apply hardware and software hardening procedures as recommended by Center for Internet Security (CIS) guides, Security Technical Implementation Guides (STIG), or similar industry best practices to reduce the systems’ surface of vulnerability, eliminating as many security risks as possible and documenting what is not feasible or not performed according to best practices. Any hardening practices not implemented shall be documented with a plan of action and milestones including any compensating control. These procedures may include but are not limited to removal of unnecessary software, disabling or removing unnecessary services, removal of unnecessary usernames or logins, and the deactivation of unneeded features in the Contractor’s system configuration files.
3) Ensure that State data is not commingled with non-State data through the proper application of compartmentalization Security Measures.
4) Apply data encryption to protect Sensitive Data at all times, including in transit, at rest, and also when archived for backup purposes. Unless otherwise directed, the Contractor is responsible for the encryption of all Sensitive Data.
5) Apply data encryption to all Contractor managed or controlled State data when the data is in transit over untrusted network segments.
6) Utilize encryption algorithms for encrypting data that comply with current Federal Information Processing Standards (FIPS), “Security Requirements for Cryptographic Modules.”
7) Enable appropriate logging parameters to monitor user access activities, authorized and failed access attempts, system exceptions, and critical information security events as recommended by the operating system and application manufacturers and information security standards, including the Maryland Department of Information Technology’s Information Security Manual.
8) Retain the aforementioned logs and review them at least daily to identify suspicious or questionable activity for investigation and documentation as to their cause and remediation, if required. The State shall have the right to inspect the logs and the Contractor or subcontractor’s performance to confirm the effectiveness of these measures for the services being provided under the Contract.
9) Ensure system and network environments are separated by properly configured and updated layer seven firewalls.
10) Restrict network connections between trusted and untrusted networks by physically or logically isolating systems from unsolicited and unauthenticated network traffic.
11) By default “deny all” and only allow access by exception.
12) Review, at least annually and after changes, the aforementioned network connections, documenting and confirming the business justification for the use of all service, protocols, and ports allowed, including the rationale or compensating controls implemented for those protocols considered insecure but necessary.
13) Perform regular internal and external vulnerability testing of operating system, applications, and all network devices utilized in this Contract. Such testing is expected to identify outdated software versions; missing software patches; device or software misconfigurations; and to validate compliance with or deviations from the security policies applicable to the Contract. Contractor shall evaluate all identified vulnerabilities for potential adverse effect on security and integrity and remediate the vulnerability no later than 30 days following the earlier of vulnerability’s identification or public disclosure, or document why remediation action is unnecessary or unsuitable. The State shall have the right to conduct vulnerability testing and inspect the results of similar Contractor performed vulnerability testing to confirm the effectiveness of these measures for the services being provided under the Contract.
14) Enforce strong user authentication and password control measures to minimize the opportunity for unauthorized access through compromise of the user access controls. At a minimum, the implemented measures should be consistent with the most current Maryland Department of Information Technology’s Information Security Policies, including specific requirements for password length, complexity, history, and account lockout.
15) Ensure State data is not processed, transferred, or stored outside of the continental United States (“U.S.”). The Contractor shall provide its services to the State and the State’s end users solely from data centers in the U.S. Unless granted an exception in writing by the State, the Contractor shall not allow Contractor Personnel to store State data on portable devices, including personal computers, except for devices that are used and kept only at its U.S. data centers. Contractor Personnel may access State data remotely only as required to provide technical support and with the prior approval of the State.
16) Ensure Contractor Personnel shall not connect any of their own equipment to State IT assets without prior written approval by the State. Any such approval may be revoked, rescinded, or curtailed at any time for any reason. The Contractor shall coordinate requests for approval with the Contract Monitor and is subject to all State approval processes as they may be revised from time to time.
17) Ensure that anti-virus and anti-malware software is installed and maintained on all systems and end points supporting the services provided under the Contract; that the anti-virus and anti-malware software is automatically updated; and that the software is configured to actively scan and detect threats to the system for remediation. The Contractor shall perform routine weekly vulnerability scans and take corrective actions for any findings.
18) Conduct regular external vulnerability testing designed to examine the service provider’s security profile from the Internet without benefit of access to internal systems and networks behind the external security perimeter. Evaluate all identified vulnerabilities on Internet-facing devices for potential adverse effect on the service’s security and integrity and remediate the vulnerability promptly or document why remediation action is unnecessary or unsuitable. The State shall have the right to inspect the Contractor’s processes and the performance of vulnerability testing to confirm the effectiveness of these measures for the services being provided under the Contract.
1.8.6 Security Logs and Reports Access
a) For any cloud hosted, or Contractor, or third party hosted solution, the Contractor shall provide security logs and reports to the State in a mutually agreeable format.
b) Reports shall include latency statistics, user access, user access IP address, user access history and security logs for all State data, systems, and software data, systems, and software related to the Contract.
1.8.7 Security Incident Response
A. The Contractor shall notify the State when any Contractor system that may access, process, or store State data or State systems experiences a Security Incident or a Data Breach as follows:
1) notify the State within twenty-four (24) hours of the discovery of a Security Incident by providing notice via written or electronic correspondence to the Contract Monitor, State Chief Information Security Officer and Maryland Security Operations Center (MD-SOC);
2) notify the State within seventy-two (72) hours if there is a threat to Contractor’s solution as it pertains to the use, disclosure, and security of State data; and
3) provide written notice to the State within one (1) Business Day after Contractor’s discovery of unauthorized use or disclosure of State data and thereafter all information the State requests concerning such unauthorized use or disclosure.
B. Contractor’s notice shall identify:
1) the nature of the unauthorized use or disclosure;
2) the State data used or disclosed,
3) who made the unauthorized use or received the unauthorized disclosure;
4) what the Contractor has done or shall do to mitigate any deleterious effect of the unauthorized use or disclosure; and
5) what corrective action the Contractor has taken or shall take to prevent future similar unauthorized use or disclosure.
6) The Contractor shall provide such other information, including a written report, as reasonably requested by the State.
C. Discussing Security Incidents with the State should be handled on an urgent as-needed basis, as part of Contractor communication and mitigation processes as mutually agreed upon, defined by law or contained in the Contract. The Contractor shall obtain approval from the State prior to communicating with outside parties regarding a Security Incident, which may include contacting law enforcement, fielding media inquiries and seeking external expertise.
D. The Contractor shall comply with all applicable system security breach laws.
1.8.8 Data Breach Responsibilities
A. If the Contractor reasonably believes or has actual knowledge of a Data Breach, the Contractor shall, unless otherwise directed:
1) Notify the appropriate State-identified contact within 24 hours by telephone and email to the Maryland Security Operations Center (MD-SOC) in accordance with the agreed upon security plan or security procedures unless a shorter time is required by applicable law;
2) Cooperate with the State to investigate and resolve the data breach;
3) Promptly implement commercially reasonable remedial measures to remedy the Data Breach; and
4) Document responsive actions taken related to the Data Breach, including any post-incident review of events and actions taken to make changes in business practices in providing the services.
B. With respect to State data within the possession or control of the Contractor, the Contractor shall bear the costs associated with (1) the investigation and resolution of the data breach; (2) notifications to individuals, regulators or others required by State law; (3) a credit monitoring service required by State or federal law; (4) a website or a toll-free number and call center for affected individuals required by State law; and (5) complete all corrective actions as reasonably determined by Contractor based on root cause; all [(1) through (5)] subject to the Contract’s limitation of liability.
C. The public disclosure of a cybersecurity incident shall be pursuant to Guidelines for the Public Disclosure of Cybersecurity Incidents or any successor thereto.
1.8.8.1 The State shall, at its discretion, have the right to review and assess the Contractor’s compliance to the security requirements and standards defined in the Contract.
1.8.8.2 Provisions in Sections 1.8.1 – 1.8.8 shall survive expiration or termination of the Contract. Additionally, the Contractor shall flow down the provisions of Sections 1.8.4 - 1.8.8 (or the substance thereof) in all subcontracts.
1.9 SOC 2 Type 2 Audit Report
A SOC 2 Type 2 Audit Report applies to the Contract. The applicable trust services criteria are: Security, Availability, Processing Integrity, Confidentiality, and Privacy. The Contractor shall cause an SOC 2 Type 2 audit report to be conducted annually covering the previous 12- month period of the contract.
1. The Contractor shall provide to the Contract Monitor, within thirty (30) calendar days of the issuance of the final SOC 2 Type 2 Audit Report, the audit results and a documented corrective action plan that addresses each audit finding or exception contained in the SOC 2 Type 2 Audit Report, identifying in detail the remedial action to be taken by the Contractor along with the date(s) when each remedial action is to be implemented. The scope of the SOC 2 Type 2 Audit Report shall include work performed by any subcontractors that handles, store or process Sensitive Data or are responsible for security controls and provide essential support to the TO Contractor for or essential support to the Information Functions and Processes for the services provided to the State under the Contract. The Contractor shall ensure the audit includes all such subcontractors operating in performance of the Contract or, in the case the subcontractor’s services are covered by a separate SOC 2 Type 2 Audit, that separate SOC 2 Type 2 Audit reports are obtained from all subcontractors and submitted to the Contract Monitor via the Contractor’s primary point of contact.
1. All SOC 2 Type 2 Audit Reports shall be submitted to the Contract Monitor as specified in Section a above. The initial SOC 2 Type 2 Audit shall be completed within a timeframe to be specified by the State. The audit period covered by the initial SOC 2 Type 2 Audit shall start with the Contract Effective Date unless otherwise agreed to in writing by the Contract Monitor. All subsequent SOC 2 Type 2 Audits after this initial audit shall be performed at a minimum on an annual basis throughout the Term of the Contract, and shall cover a 12-month audit period or such portion of the year that the Contractor furnished services.
1. The SOC 2 Type 2 Audit shall report on the suitability of the design and operating effectiveness of controls over the Information Functions and Processes to meet the requirements of the Contract,…
This is the start of the file's text. The full file is on GovTribe.
File details come from the government source that posted it. Updated .