This supplemental contains additional requirements under Section 2 of the solicitation.

[[This supplemental is an additional requirement within Section 2 of your base solicitation template, titled "Supplemental Category of Work Requirements and Responsibilities". A supplemental is unique and specific to the procurement and its respective category of work. Complete this supplemental by following the instructions herein and referencing it accordingly within your solicitation before finalizing the document for publication.]]

[[PRIOR TO PUBLICATION: Delete an instruction (found in red text) as it is only for the purposes of providing instructions to the Procurement Officer.]]

Deliverables

[[Adjust the standard language for your RFP. Generally speaking, a deliverable is something that has acceptance criteria (e.g., Timesheets are not deliverables). For SaaS and IaaS, deliverables would include anything produced during the Startup period and monthly reports.

Agencies must remain cognizant that acceptance of a deliverable in order to facilitate payment to a Contractor leaves the Agency with limited recourse if the deliverable is sub-par.]]

Deliverable Submission

[[Carefully read the boilerplate below for applicability to this RFP. If you specify that certain paperwork must be completed, then it can be an audit finding if the RFP is not run according to the defined expectations.]]

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.

[[Revise this paragraph if you do not wish to use a Deliverable Product Acceptance Form. Check other paragraphs for applicability.]] 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://doit.maryland.gov/contracts/Documents/_procurementForms/DeliverableProductAcceptanceForm-DPAFsample.pdf

Unless specified otherwise, written deliverables shall be compatible with Microsoft Office, Microsoft Project or Microsoft Visio within two (2) versions of the current version. At the Contract Monitor’s discretion, the Contract Monitor may request one hard copy of a written deliverable.

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.

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.3 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.3 Minimum Deliverable Quality.

Deliverable Acceptance

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.4 Deliverable Descriptions/Acceptance Criteria.

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.

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.

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.

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:

Be presented in a format appropriate for the subject matter and depth of discussion.

Be organized in a manner that presents a logical flow of the deliverable’s content.

Represent factual information reasonably expected to have been known at the time of submittal.

In each section of the deliverable, include only information relevant to that section of the deliverable.

Contain content and presentation consistent with industry best practices in terms of deliverable completeness, clarity, and quality.

Meets the acceptance criteria applicable to that deliverable, including any State policies, functional or non-functional requirements, or industry standards.

Contains no structural errors such as poor grammar, misspellings or incorrect punctuation.

Must contain the date, author, and page numbers. When applicable for a deliverable, a revision table must be included.

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.

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.

[[Identify every deliverable expected from your Contractor.For staff augmentation RFPs, do not expect all deliverables to be listed in the deliverables table. There should be sufficient requirements to describe the job expectations, and include here typically status reports and maybe one or two other key deliverables.]]

Deliverables Summary Table*

ID #	Deliverable Description	Acceptance Criteria	Due Date / Frequency
Integrated Project Schedule	Microsoft Project schedule demonstrating tasks, task estimates, resource assignments, and dependencies for both Agency and Contractor Personnel, with tasks no less than 8 hours and no greater than 80 hours.	Initial Delivery: NTP+ <<x>> Business Days Updates: Weekly [[Be clear if a due date is Business Days or calendar days.]]
[[You can specify “as identified in the approved project schedule.”]]

*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.

Optional Features or Services, Future Work

[[Put in optional work that might occur in the future here; otherwise remove the section. Use this section to more clearly define scope but not have an “option” with associated pricing, or to actually describe an option that can be exercised by the State.]]

<<Potential Future Work>> (Fixed Price / T&M) [[Place any unconfirmed work here. If the work is a priced option, label it as OPTION. Otherwise, it should be considered a further description of potential scope, or “potential future work” that qualifies the scope but isn’t something with enough information to ask for pricing.]]

1.3 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.

[[Review for applicability, confirm with DoIT or end-user]]
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 Contractor may operate in the production environment upon authorization to operate (ATO) from the State.

F. 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. [[Adjust this section to clearly state your expectations for any equipment furnished under the contract. For instance, you may specify that you want a warranty for a period coinciding with the duration of the Contract. Note that equipment warranty is associated with a PURCHASE, not SaaS or IaaS. ]] 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 at no additional cost to the State.

1.4 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: As described in Section 1.6.5.B 15) Data Protection and Controls, Bidders/Offerors are advised that any processing or storage of data outside of the continental U.S. is strictly prohibited.

D. Consistent expiration dates: Licenses/services purchased under the Contract shall expire coterminously with the earliest licenses/services delivered. As appropriate, charges shall be prorated. [[This is intended to allow you to make additional incremental purchases for things such as licenses without having expiration dates that are tied to the date you asked for more licenses. Delete if inapplicable.]]

E. 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.

F. 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.5 Maintenance

Maintenance and support, and Contractor’s ongoing maintenance and support obligations, are defined as follows:

[[For all requirements, review for applicability.]]

A. Maintenance commences at the <<___________.>> [[For instance, this could be at State acceptance of initial startup activities.]] Billing for such maintenance and support shall commence after _________________. [[Clearly indicate when maintenance begins. For instance, maintenance could start at State acceptance of initial startup activities. If there is an activity that must be complete before maintenance (and associated billing) can begin, clearly indicate it’s when the State ACCEPTS the deliverable.]]

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. [[Delete if inapplicable. If this is SaaS, then this can be tweaked because there are no software support contracts but there may be updates and upgrades.]]

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 <<[[Insert commencement OR cross reference where commencement is already referenced in these requirements.]]>>:

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 in Reference B of the Table in Section 1.2.

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.

[[List Contractor duties and responsibilities. Adjust as appropriate. Review boilerplate text in other sections to ensure consistency and avoid duplication between sections.]]

E. Activity reporting

1.5.1 Technical Support [[Note: technical support and help desk are not the same.]]

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. Technical Support shall be available during Normal State Business Hours. [[The Procurement Officer should include any other hours that are required beyond Normal State Business Hours here. Remember, Normal State Business Hours is a defined term that includes State Holidays (see Appendix 1).]]

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). [[Adjust as appropriate. Support that isn’t sent to a general queue may cost more.]]

E. Contractor shall return calls for service of emergency system issues within one (1) hour or per the Service Level Agreement.

F. Calls for non-emergency IT service requests will be returned within three (3) hours or immediately the following day if after Normal State Business Hours. [[Adjust to match B “Technical Support” above.]]

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 <<Named solution should be stated here >>.

2) Help Desk services are available during Normal State Business Hours. [[The Procurement Officer should include any other hours that are required beyond Normal State Business Hours here. Remember, Normal State Business Hours is a defined term that includes State Holidays (see Appendix 1).]]

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.

4) <<Help Desk services shall be furnished using resources familiar with the State’s account (i.e., calls shall not be sent to a general tier 1 call queue)>>. [[Revise or delete as desired.]]

1.5.2 Backup

[[Decide how backups will be performed, and if you’re interested in having pricing from the Offeror for performing backups, include it as an option in your Financial Proposal/Bid Form that you might exercise. Insert information here regarding what the Contractor is expected to perform with regard to Backup/Disaster Recovery (DR).

SaaS contracts typically do not offer backup and DR as part of its service, leaving the agency responsible for performing backups.

Note that backup time periods need to be synchronized with data retention requirements associated with ending the Contract; see Section 3.2.

Example language (verify all the language in each sentence is applicable to your Contract):]]

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 (1) month and weekly backups shall be retained for two (2) years;

C. Store daily backups off-site.

[[OR]]

D. Provide backups of the configuration and data on a regular basis as a Contract option. Contractor shall describe backup services offered, and shall offer pricing for this option in the Financial Proposal Form (Attachment B);

E. Meet the Recovery Time Objective (RTO) and Recovery Point Objective (RPO) metrics defined in Section 1.6 Service Level Agreement. [[Note: if you use this as a requirement in the SLAs, be sure to define the terms RTO and RPO in the definitions and also define how they are measured. ]]

[[ALTERNATIVE REQUIREMENTS for backups:]]

F. Perform backups for all application and configuration data that is necessary to restore the application to full operability on suitable hardware. The backup shall consist of at least:

1) Incremental daily backups, retained for one (1) month,

2) Full weekly backups, retained for three (3) months, and

3) Last weekly backup for each month maintained for two (2) years;

G. Maintain one annual backup for at least <<10>> years;

H. Send the weekly backup electronically to a facility designated by the State;

I. Encrypt the backups using a pre-shared key;

J. Perform a backup recovery at least semi-annually; and

K. Provide on demand support for the State’s recovery of a backup set.

1.6 Service Level Agreement (SLA)

[[If this section is inapplicable to this RFP, insert the following sentence:]]

THIS SECTION IS INAPPLICABLE TO THIS RFP.

1.6.1 Definitions

[[In order to use Problem and Problem resolution time, a help desk and help desk ticketing requirements must be defined in the RFP.]]

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.

C. Monthly Charges: for purposes of SLA credit calculation, Monthly Charges are defined as the charges set forth in Attachment B, Financial Proposal Form, invoiced during the month of the Problem for the monthly fixed services, or, in the event of annual billing, 1/12 of the annual invoice amount Financial Proposal Form.

1.6.2 SLA Requirements

The Contractor shall:

[[Adjust this list as appropriate.]]

A. Be responsible for complying with all performance measurements, 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.6.7.

C. Provide a monthly report to monitor and detail response times and resolution times.

D. Log Problems into the Contractor-supplied tracking tool or other help desk software and assign an initial severity level (i.e., Emergency, High, Normal, or Low as defined in Section 1.6.8).

E. 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.

F. The State of Maryland shall make the final determination regarding Problem severity as defined in Section 1.6.8.

G. Contractor shall review any Problem with the State of Maryland to establish the remediation plan and relevant target dates.

1.6.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 <<[[Pick one: Transition-In Period OR implementation OR a definition developed for this solicitation.]]>>.

1.6.4 Service Level Reporting

[[Measurements do not have to be by month, although the default language in this section is by month. Tailor the time period appropriate to contract needs, and verify all instances of “monthly” in this Section are appropriate.]]

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>>. [[Procurement Officers you can configure this to say that they must be delivered on a regular schedule in advance of the invoice.]]

1.6.5 SLA Service Credits

[[If the Offeror/Bidder furnishes the performance measurements, update the language to indicate that the information is in the Contract and add a corresponding requirement in the Technical Proposal instructions (Section 5.3) to request the service level metrics, reports, and SLA 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 Monthly 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 OR the entire Solution>>, in addition to all other rights and remedies available to the State, all affected SLAs shall be credited to the State.

[[Include only if specifying service level metrics:]]<<In no event shall the aggregate of all SLA credits paid to the State in any calendar month exceed 25%>> of the Monthly Charges.

Example: If the Monthly Charges were $100,000 and one SLA were missed, with an applicable 4% credit, the credit to the monthly invoice would be $4,000, and the State would pay a net Monthly Charge of $96,000.

The parties agree that any assessment of service credits shall be construed and treated by the parties not as imposing a penalty upon the Contractor, but as compensation to the State for the Contractor’s failure to satisfy its service level obligations.

1.6.6 Root Cause Analysis

[[Delete if inapplicable.]]

The State has the right, at its sole discretion, to direct the Contractor to perform and deliver a root cause analysis in connection with any SLA measurement that yields an SLA credit. Such root cause analysis shall be provided within 30 days of the request.

In addition, for each ‘Emergency’ or ‘High’ priority Problem, the affected parties will perform a root cause analysis and institute a process of problem management to prevent recurrence of the issue.

1.6.7 Service Level Measurements Table (System performance)

[[OPTION 1 – Offeror identifies metrics. Use the table format so offers are more consistent.]]

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%

[[OPTION 2 – State identifies metrics.]]

The Contractor shall comply with the service level measurements in the following table:

[[Select a SUBSET of the service measurement table below and tailor the ones you select to match your need. Add other metrics suitable for your RFP.]]

No.	Service Requirement	Measurement	Service Level Agreement (SLA)	SLA Credit
1	Problem Response Time – High	Average Response Time for High Priority Problems.	98% - Less than 15 minutes	1%
2	Problem Response Time - Normal	Average Response Time for Normal or Low Priority Problems	98% - Less than 2 hours	1%
3	Problem Resolution Time - High	Resolution Time for each High Priority Problem	98% - Less than 4 hours	1%
4	Problem Resolution Time - Normal	Resolution Time for Normal Priority Problems	98% - Less than 24 hours	1%
5	Problem Resolution Time - Low	Resolution Time for Low Priority Problems	98% - Less than 72 hours	1%
6	Scheduled Downtime/ Maintenance	Scheduled maintenance and downtime shall only occur during non-business hours*. The Contractor shall provide 14 calendar days’ notice prior to any scheduled downtime.	Less than 6 hours each month	<<X%>>
7	Service Availability	All application functionality and accessibility shall be maintained at 99.5% uptime performance levels. Contractor shall minimize or eliminate unscheduled network downtime to .5% or less.	Less than 99.5%	<<X%>>
9	Disaster Recovery	Contractor shall provide recovery and continuity of operations within <<X>> hours of a System/network failover.	<<xx hours>>	<<X%>>
10	Notification of Security Incident	Notification of a Security Incident within <<X>> minutes of occurrence	<<xx hours>>	<<X%>>
11	Security Incident Reporting	Security incident reporting requirement in <<X>> minutes or <<X>> hours	<<xx hours>>	<<X%>>
12	Escrow Update	Update escrow within <<X>> days of a change. Failure to update escrow	<<xx days>>	<<X%>>

The State shall have the unilateral right to reallocate percentages among the various SLAs annually on the anniversary of the Contract, provided that such reallocation will not exceed the cap identified in Section 2.6.5. [[End of OPTION 2.]]

1.6.8 Problem Response Definitions and Times

[[If no service level metrics are desired, this table can be used to describe the State’s basic expectations without metrics or SLA credits.]]

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.

[[Review the table and revise the metrics and text below. Make sure these times align with any help desk or technical support hour requirements elsewhere in the RFP. ]]

Service Priority	Response Time	Resolution Time	Response Availability	Work Outage	Users Affected
Emergency	Less than 15 minutes	Within 2 hours of first report	24 hours per day, seven days per week	Major portions of the System are inaccessible Systems or users are unable to work, or to perform some portion of their job.	Users or internal System functionalities are impaired. To include <<Claimants and Employers>>
High	Less than 30 minutes	Within 4 hours after first report	24 hours per day, seven days per week	Major portions of the System are inaccessible Systems or users are unable to work, or to perform some portion of their job.	Affects the majority of users to include public facing users <<Claimants & Employers>> Affects high profile users (i.e. executive management)
Normal	Within 2 hours	Within 1 day (24 hours) after the first report. If the outage is not resolved a resolution plan must be in place.	Mon-Fri, 7AM-7PM	Specific non-critical features are not operating as specified Systems or users are unable to perform a small portion of their job, but are able to complete most tasks.	Affects a number of users
Low	Within 2 hours	Within 3 days (72 hours) after the first report. If the outage is not resolved a resolution plan must be in place.	Mon-Fri, 7AM-7PM	Lower priority features that can be done manually are not operating as specified Often a request for service with ample lead time.	Affects a number of users

1.6.9 Service Level Measurements Table (Help Desk Calls)

[[Contact your oversight analyst if you have needs for extensive help desk SLAs. Remove heading if not required.]]

1.7 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.8 Disaster Recovery and Data

1.8.1 Redundancy, Data Backup and Disaster Recovery

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.

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.

The Contractor shall furnish a DR site.

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.

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 in order to avoid unacceptable consequences due to the unavailability of services.

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.

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.8.2 Data Export/Import

The Contractor shall, at no additional cost or charge to the State, in an industry standard/non-proprietary format:

perform a full or partial import/export of State data within 24 hours of a request; or

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.

Any import or export shall be in a secure format per the Security Requirements.

1.8.3 Data Ownership and Access

[[If data is part of the Contract’s scope, AAG must approve any changes to below language.]]

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.9 Security Requirements

[[Review this section for applicability and tailor as appropriate:]]

The following requirements are applicable to the Contract:

Employee Identification

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.

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.

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.

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.

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.

[[Use only one of the Criminal Background Check paragraphs below, as applicable; delete the others. If no background check is required insert the following sentence:]]

A criminal background check is not required for Contractor Personnel.

A security clearance is not required for Contractor Personnel.

[[Otherwise adjust the paragraphs to meet IFB needs.

Contractor Is Responsible for Background Checks. Note: If only certain functions to be performed under the Contract necessitate a background check, the following background check requirement may be changed to designate those functions and limit background checks to Contractor and subcontractor personnel performing those designated functions, e.g., personnel in contact with vulnerable populations, personnel handling State funds, personnel conducting bookkeeping functions, personnel with access to Sensitive Data.]]

A criminal background check for each << Pick one: for any Contractor Personnel providing <<on-site OR any OR list specific services/roles impacted>> shall be completed << Pick one: prior to each Contractor Personnel providing any services under the Contract OR within four (4) months of Contract award OR describe what is appropriate.>>.

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.

[[OR]]

[[Department Is Responsible for Background Checks.]]

The Contractor shall obtain from each individual assigned to work on the Contract a statement permitting a criminal background check. The State will obtain a criminal background check for each individual using a source of its choosing. The Contract Monitor reserves the right to reject any individual based upon the results of the background check.

[[OR (for Temporary Personnel Contracts)]]

The Contractor shall obtain criminal background checks on candidates it sends for employment under the Contract. At a minimum, these checks must contain convictions and probation before judgment (PBJ) pleadings within the State of Maryland. This check may be performed by a public or private entity.

[[Keep when Contractor Performs the check, otherwise delete this paragraph:]]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.

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.

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:

§§ 6-101 through 6-104, 6-201 through 6-205, 6-409 (various crimes against property);

any crime within Title 7, Subtitle 1 (various crimes involving theft);

§§ 7-301 through 7-303, 7-313 through 7-317 (various crimes involving telecommunications and electronics);

§§ 8-201 through 8-302, 8-501 through 8-523 (various crimes involving fraud);

§§9-101 through 9-417, 9-601 through 9-604, 9-701 through 9-706.1 (various crimes against public administration); or

a crime of violence as defined in CL § 14-101(a).

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.

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.

On-Site Security Requirement(s)

[[If this section is inapplicable to this IFB, insert the following sentence:]]

THIS SECTION IS INAPPLICABLE TO THIS IFB.

[[If this section is applicable to this IFB, adjust as appropriate for this IFB:]]

For the conditions noted below, Contractor Personnel may be barred from entrance or leaving any site until such time that the State’s conditions and queries are satisfied.

Contractor Personnel may be subject to random security checks when entering and leaving State secured areas and may be barred from entrance or exit until such time that the State’s conditions and queries are satisfied. The State reserves the right to require Contractor Personnel to be accompanied while in secured premises.

Some State sites, especially those premises of the Department of Public Safety and Correctional Services, require each person entering the premises to document and inventory items (such as tools and equipment) brought onto the site, and to submit to a physical search of his or her person. Therefore, Contractor Personnel shall always have an inventory of tools being brought onto a site and be prepared to present the inventory, as well as the tools or equipment, to the State staff or an officer for review and inspection. Before leaving the site, the Contractor Personnel may again be required to present the inventory list and the tools or equipment for inspection. Upon both entering and exiting the site, State staff or a correctional or police officer may search Contractor Personnel. Depending upon facility rules, specific tools or personal items may be prohibited from being brought into the facility.

Any Contractor Personnel who enters the premises of a facility under the jurisdiction of the <<typeofAgency>> may be searched, fingerprinted (for the purpose of a criminal history background check), photographed and required to wear an identification card issued by the <<typeofAgency>>.

Further, Contractor Personnel shall not violate Md. Code Ann., Criminal Law Art. Section 9-410 through 9-417 and such other security policies of the agency that control the facility to which the Contractor Personnel seeks access. The failure of any of the Contractor Personnel to comply with any provision of the Contract is sufficient grounds for the State to immediately terminate the Contract for default.

1.9.4 Information Technology Security

[[The following Information Technology Security provisions are to be included in Contracts where there is the collection, accessing, usage, storage, processing, disposition, and/or disclosure of State data, including “Sensitive Data” such as PII, PHI, Federal Tax Information (FTI),or other protected private/confidential data classes. These provisions are designed to coincide with the SOC 2 Type 2 Audit Report provisions in the solicitation, and should always be included when the SOC 2 Type 2 Audit Report requirement is included. If your solicitation does not have any requirements that relate to these Information Technology provisions, delete this Information Technology section and revise subsection numbering accordingly.]]

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.9.5. Data Protection and Controls [[Review for applicability.]]

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.

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.

The Contractor shall supply a copy of such policy to the State for validation, with any appropriate updates, on an annual basis.

If any Security Plan information, including procedures, are different based on a Task Order, Contractor shall furnish such differences to the respective TO Manager.

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):

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).

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.

Ensure that State data is not commingled with non-State data through the proper application of compartmentalization Security Measures.

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.

Apply data encryption to all Contractor managed or controlled State data when the data is in transit over untrusted network segments.

Utilize encryption algorithms for encrypting data that comply with current Federal Information Processing Standards (FIPS), “Security Requirements for Cryptographic Modules.”

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.

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.

Ensure system and network environments are separated by properly configured and updated layer seven firewalls.

Restrict network connections between trusted and untrusted networks by physically or logically isolating systems from unsolicited and unauthenticated network traffic.

By default “deny all” and only allow access by exception.

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.

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.

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.

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.

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.

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 [agency should be more specific as to what routine means (e.g., weekly, monthly, etc.)]] vulnerability scans and take corrective actions for any findings.

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.9.6 Security Logs and Reports Access [[Review for applicability.]]

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.

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.9.7 Payment Card Industry Compliance [[Review for applicability.]]

Contractor shall at all times comply, and ensure compliance with, all applicable Payment Card Industry ("PCI") Data Security Standards (“DSS”), including any and all changes thereto. Contractor shall provide the Contract Monitor with documented evidence of current compliance to PCI DSS within 30 days of request.

The Contractor shall annually furnish to the Contract Monitor evidence of the PCI Security Standards Council’s (SSC) acceptance or attestation of the Contractor’s conformance to the relevant PCI DSS requirements by a third party certified to perform compliance assessments.

The Contractor shall ensure that the scope of the annual SOC 2 Type II Audit Report specified under Section 1.7 includes testing to confirm the PCI assessment results.

1.9.8 Security Incident Response

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:

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);

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

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.

Contractor’s notice shall identify:

the nature of the unauthorized use or disclosure;

the State data used or disclosed,

who made the unauthorized use or received the unauthorized disclosure;

what the Contractor has done or shall do to mitigate any deleterious effect of the unauthorized use or disclosure; and

what corrective action the Contractor has taken or shall take to prevent future similar unauthorized use or disclosure.

The Contractor shall provide such other information, including a written report, as reasonably requested by the State.

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.

The Contractor shall comply with all applicable system security breach laws.

1.9.9 Data Breach Responsibilities

[[This section only applies when a data breach occurs with respect to State data within the possession or control of the Contractor.]]

If the Contractor reasonably believes or has actual knowledge of a Data Breach, the Contractor shall, unless otherwise directed:

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;

Cooperate with the State to investigate and resolve the data breach;

Promptly implement commercially reasonable remedial measures to remedy the Data Breach; and

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.

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.

The public disclosure of a cybersecurity incident shall be pursuant to Guidelines for the Public Disclosure of Cybersecurity Incidents or any successor thereto..

1.9.10 Additional security requirements may be established in a Task Order or a Work Order. [[Delete if Task Orders or Work Orders are not allowed in this solicitation.]]

1.9.11 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.9.12 Provisions in Sections <<1.9.1 – 1.9.10>> shall survive expiration or termination of the Contract. Additionally, the Contractor shall flow down the provisions of Sections <<1.9.4 - 1.9.10>> (or the substance thereof) in all subcontracts.

1.10 SOC 2 Type 2 Audit Report

[[Contact your oversight analyst for language if there is the potential for FUTURE Sensitive Data handling. If a Contractor SOC 2 Type 2 Report is not required for this Contract, enter only the following sentence for this section and delete the rest.]]

A SOC 2 Type 2 Audit Report is not a Contractor requirement for this Contract.

[[Include the following SOC 2 Type 2 Report clause when the Contractor will collect, process, transmit, store, organize, maintain, or dispose of critical or sensitive information on behalf of the State as part of its Contract responsibilities.]]

A SOC 2 Type 2 Audit Report applies to the Contract. The applicable trust services criteria are: << Choose from the following controls, as applicable: Security, Availability, Processing Integrity, Confidentiality, or 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.

Such audits shall be performed in accordance with audit guidance: Reporting on an Examination of Controls at a Service Organization Relevant to Security, Availability, Processing Integrity, Confidentiality, or Privacy (SOC 2) as published by the American Institute of Certified Public Accountants (AICPA) and as updated from time to time.

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.

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.

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, including the Security Requirements identified in Section 1.6, relevant to the trust services criteria identified in Section 1.7.1: as defined in the aforementioned Guidance.

The audit scope of each year’s SOC 2 Type 2 Audit Report may need to be adjusted (including the inclusion or omission of the relevant trust services criteria of Security, Availability, Processing Integrity, Confidentiality, and Privacy) to accommodate any changes to the environment since the last SOC 2 Type 2 Audit Report. Such changes may include but are not limited to the addition of Information Functions and/or Processes through modifications to the Contract or due to changes in Information Technology or the operational infrastructure. The Contractor shall ensure that the audit scope of each year’s SOC 2 Type 2 Audit Report engagement shall accommodate these changes by including in the SOC 2 Type 2 Audit Report all appropriate controls related to the current environment supporting the Information Functions and/or Processes, including those controls required by the Contract.

The scope of the SOC 2 Type 2 Audit Report shall include work performed by any subcontractors that handle, store or process Sensitive Data 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 shall ensure their subcontractors obtain a SOC 2 Type 2 Audit Report as described in this Section.

All SOC 2 Type 2 Audits shall be completed at the Contractor’s expense, including those of the Contractor, shall be performed at no additional expense to the State.

If the Contractor fails during the Contract term to obtain an annual SOC 2 Type 2 Audit Report by the date specified in Section 1.7.2.A, the State shall have the right to retain an independent audit firm to perform an audit engagement to issue of a SOC 2 Type 2 Audit Report of the Information Functions and/or Processes utilized or provided by the Contractor and under the Contract. The Contractor agrees to allow the independent audit firm to access its facility/ies for purposes of conducting this audit engagement(s), and will provide the necessary support and cooperation to the independent audit firm in the performance of the engagement.that is required to perform the audit engagement of the SOC 2 Type 2 Audit Report. The State, at its option, will invoice the Contractor for the expense of the SOC 2 Type 2 Audit Report(s), or deduct the cost from future payments to the Contractor.

Provisions in Section 1.7.1-2 shall survive expiration or termination of the Contract. Additionally, the Contractor shall flow down the provisions of Section 1.7.1-2 (or the substance thereof) in all subcontracts.

1.11 Nonvisual Access

[[If this solicitation does not require Nonvisual Access Information Technology (IT) provisions, enter only the following sentence for this section and delete the rest:]]

This solicitation does not contain Information Technology (IT) provisions requiring Nonvisual Access.

[[If this solicitation does require Nonvisual Access Information Technology (IT) provisions, enter the following language for this section.]]

1.11.1. Definitions

For purposes of this provision, the phrase ‘equivalent access' means the ability to receive, use, and manipulate information and operate controls necessary to access and use information technology by nonvisual means. Examples of equivalent access include keyboard controls used for input and synthesized speech, Braille, or other audible or tactile means used for output.

1.11.2 Requirements applicable to bidders and offerors.

The bidder or offeror warrants that the information technology offered under this bid or proposal:

(1) provides equivalent access for effective use by both visual and nonvisual means consistent with the standards of the US Department of Justice Americans with Disabilities Act Title II final rule, § 508 of the federal Rehabilitation Act of 1973, and Code of Maryland Regulations 14.33.02;

(2) provides an individual with disabilities with nonvisual access in a way that is fully and equally accessible to and independently usable by the individual with disabilities so that the individual is able to acquire the same information, engage in the same interactions, and enjoy the same services as users without disabilities, with substantially equivalent ease of use;

(3) will present information, including prompts used for interactive communications, in formats intended for both visual and nonvisual use;

(4) if intended for use in a network, can be integrated into networks for obtaining, retrieving, and disseminating information used by individuals who are not blind or visually impaired; and

(5) is available, whenever possible, without modification for compatibility with software and hardware for nonvisual access. The bidder or offeror further warrants that, if any, the cost of modifying the information technology for compatibility with software and hardware used for non-visual access will not increase the cost of the information technology by more than 15 percent.

1.11.3 Requirements applicable to Contractors.

1.11.3.1 If the information technology procured under this solicitation does not meet the nonvisual access standards set forth in the Code of Maryland Regulations 14.33.02, the State will notify the Contractor in writing that it, at its own expense, has 12 months after the date of the notification to modify the information technology in order to meet the nonvisual access standards. If the Contractor fails to modify the information technology to meet the nonvisual access standards within 12 months after the date of the notification, it may be subject to a civil penalty of a fine not exceeding $5,000 for a first offense, and a fine not exceeding $10,000 for a subsequent offense.

1.11.3.2	The Contractor shall indemnify, defend, and hold harmless the State for liability resulting from the use of information technology that does not meet the applicable nonvisual access standards.

1.11.3.3 Prior to any IT solution being pushed to production or going live (ideally prior to user acceptance testing), the Contractor shall submit to the Contract Monitor and the Department of Information Technology (DoIT) at accessibility.doit@maryland.gov a comprehensive accessibility audit report demonstrating conformance with Web Content Accessibility Guidelines (WCAG) 2.1 A & AA Success Criteria that includes the results from automated and manual testing tools, such as the screen readers Job Access With Speech (JAWS), VoiceOver and NonVisual Desktop Access (NVDA). The Contractor shall leverage a variety of commonly used accessibility testing procedures, including accessing the site through mainstream web browsers and evaluating accessibility, and performing comprehensive mobile accessibility testing using physical iOS and Android devices (not mobile emulators) to ensure the native accessibility features work with the respective IT solution. The Contractor may use an independent third-party accessibility testing company to conduct this work.

1.11.3.4	Where conformance to the foregoing standards is not satisfied, the Contractor must provide a testing and remediation plan to bring the IT solution into compliance as directed by the Contract Monitor. If the Contractor will use any subcontractors as part of its plan, the Contractor must name the subcontractors in this plan. The Contractor shall remediate any accessibility issues identified in the accessibility audit or by the State. The Contractor must conduct validation testing on all remediated accessibility issues and provide a copy of the validation testing results as an Excel or Word file. Contractor shall submit the comprehensive testing and remediation plan and validation testing results to the Contract Monitor and DoIT at accessibility.doit@maryland.gov.

1.11.4 The use of out-of-the-box or third-party source code does not waive a Contractor’s obligation to ensure that a product complies with the requirements of this Section. Furthermore, the Contractor bears sole responsibility to determine if any out-of-the-box source code or third-party code is accessible and to remediate any noncompliance with the State’s nonvisual access requirements or cause any noncompliance to be remediated to ensure compliance with such requirements.

1.11.5 Ten percent (10% ) of all invoiced amounts shall be held back from each payment (the “Retention Amount”), as retention money to guarantee Contractor’s performance of the obligations set forth in this clause. Contractor may invoice the State for release of the Retention Amount upon DoIT’s written approval to place the IT solution into production. DoIT reserves the right to use the Retention Amount to pay for third-party solutions to remediate WCAG 2.1 Level A and AA accessibility issues if the Contractor is unable to remediate after 90 days following launch of the website or application.

1.12 Mercury and Products That Contain Mercury

[[If this solicitation does not include the procurement of products known to likely include mercury as a component, enter only the following sentence for this section and delete the rest.]]

This solicitation does not include the procurement of products known to likely include mercury as a component.

[[If this solicitation does include the procurement of products known to likely include mercury as a component, choose and enter the following “Option” language for this section, as applicable). Note for IT purchases, Option 3 is typically the only one selected.]]

[[Option 1. This clause provides a price preference to only those products that are mercury-free. Enter the percentage preference for “X.”]]

A price preference of <<X >>percent (X%) (not to exceed 5%; see COMAR 21.05.08.09) shall be given to Bids/Proposals for products or equipment that are mercury-free. The Bidder/Offeror must submit a Mercury Affidavit in the form of Attachment J with its Bid/Proposal.

[[Option 2. This clause provides a price preference to those products that are mercury-free or which provide the least amount of mercury. Enter the percentage preference for “X.”]]

A price preference of <<X >>percent (<<X>>%) (not to exceed 5%; see COMAR 21.05.08.09) shall be given to Bids/Proposals for products or equipment that are mercury-free or, if mercury-free products or equipment are not offered, to the Bids/Proposals for products or equipment containing the least amount of mercury necessary to meet performance requirements. The Bidder/Offeror must submit a Mercury Affidavit in the form of Attachment J with its Bid.

[[Option 3. This clause requires that all products be mercury-free.]]

All products or equipment provided pursuant to this solicitation shall be mercury-free products. The Bidder/Offeror must submit a Mercury Affidavit in the form of Attachment J with its Bid/Proposal.

1.13 Location of the Performance of Services Disclosure

[[If this procurement is not anticipated to have an estimated value of $2,000,000.00 or more, enter only the following sentence for this section and delete the rest.]]

This solicitation does not require a Location of the Performance of Services Disclosure.

[[If this procurement is anticipated to have an estimated value of $2,000,000.00 or more and includes services, enter the following language for this section:]]

The Bidder/Offeror is required to complete and submit with the Bid/ Proposal the Location of the Performance of Services Disclosure. A copy of this Disclosure is included as Attachment K.

<<Services under this Contract must be performed in the United States.>> [[Mandatory if this is one of the four categories of: architectural services, construction-related services, engineering services, and energy performance services. Optional for other types of services but the rationale given in Attachment L must meet the standards listed at the end of the Attachment. Also, double check the security boilerplate for consistency.]]

1.14 HIPAA - Business Associate Agreement

[[If a HIPAA Business Associate Agreement is not required for this solicitation, enter only the following sentence for this section and delete the rest.]]

A HIPAA Business Associate Agreement is not required for this procurement.

[[If a HIPAA Business Associate Agreement is required for this solicitation, enter the following language for this section, and select the appropriate Contract clause option in the Contract – Attachment M.]]

In the event the State determines that the functions to be performed in accordance with this solicitation constitute Business Associate functions as defined in the Health Insurance Portability and Accountability Act of 1996 (HIPAA), the recommended awardee shall execute a Business Associate Agreement as required by HIPAA regulations at 45 C.F.R. §164.500 et seq. and set forth in Attachment J. This Agreement must be provided within five (5) Business Days of notification of proposed Contract award. However, to expedite processing, it is suggested that this document be completed and submitted with the Bids/Proposals. Should the Business Associate Agreement not be submitted upon expiration of the five (5) Business Day period as required by this solicitation, the Procurement Officer, upon review of the Office of the Attorney General and approval of the Secretary, may withdraw the recommendation for award and make the award to the responsible Bidder with the next highest overall-ranked Bid/Proposal.

1.15 Additional Clauses

[[This section may be used for agency-specific clauses that are not included elsewhere in the RFP. Sections 1.15.1 - 1.15.5 are specific to IT solicitations. Section 1.15.6 pertains to purchasing environmentally preferred products and services that include IT. Section 1.15.7 should be included in all solicitations. If sections are inapplicable or added, delete and renumber sections accordingly.]]

The Contractor is subject to the requirements in this section and shall flow down the provisions of Sections 1.15.1 – 1.15.5 (or the substance thereof) in all subcontracts.

1.15.1 Custom Software

[[If custom software is part of the Contract’s scope, do not change this language without AAG approval.]]

A. As described in the sample contract (Exhibit 2), the State shall solely own any custom software, including, but not limited to application modules developed to integrate with a COTS, source code, maintenance updates, documentation, and configuration files, when developed under the Contract.

A. Upon a Contractor's voluntary or involuntary filing of bankruptcy or any other insolvency proceeding, Contractor’s dissolution, Contractor’s discontinuance of support of any software or system, the Contractor shall convey to the State all rights, title, and interests in all custom software, licenses, software source codes, and all associated System Documentation that comprises any solutions proposed as a part of the Contract These rights include, but are not limited to, the rights to use, and cause others to use on behalf of the State, said software, software documentation, licenses, software source codes, and System Documentation.

1.15.2 Custom Source Code

[[If custom software is part of the Contract’s scope, do not change this language without AAG approval.]]

A. For all custom software provided to the State pursuant to any Contract, the Contractor shall either provide the source code directly to the State in a form acceptable to the State, or deliver two copies of each software source code and software source code documentation to a State-approved escrow agent at no additional cost to the State following the terms set forth in the sample contract (Exhibit 2) and in Section 1.15.3 below.

B. The State shall have the right to audit custom software source code and corresponding software source code documentation for each software product that comprises the solution as represented by the Contractor. This audit shall be scheduled at any time that is convenient for the parties to be present. The State shall be provided with software or other tools required to view all software source code.

C. The Contractor shall provide the current source code and documentation for all custom software to the State at the time of Contract termination.

1.15.3 Source Code Escrow

[[If source code escrow is part of the Contract’s scope, do not change this language without AAG approval. Keep this section if the Contract might include source code escrow. Delete this clause if inapplicable, and revise the numbering of the clauses in the Contract accordingly. Otherwise, delete this section and its heading, renumbering any subsequent sections.]]

Source Code Escrow applies to the Contract. The Contractor shall perform source code escrow as described herein.

A. The State will be named as a beneficiary under an escrow agreement (“Escrow Agreement”) that shall be entered into between the Contractor and an escrow agent (“Escrow Agent”) within <<xxx>> days of the Contract Effective Date hereof pursuant to which Contractor shall deliver a Source Code Escrow Package to Escrow Agent. The term “Source Code Escrow Package” means: a) a complete copy in machine-readable form of the source code and executable code of the software licensed to the State under the Contract; b) a complete copy of any existing design documentation and user documentation; and/or c) complete instructions for compiling and linking every part of the source code into executable code for purposes of enabling verification of the completeness of the source code as provided below. The Escrow Agreement shall govern the maintenance and release of the Source Code Escrow Package, and Contractor agrees to update, enhance, or otherwise modify such Source Code Escrow Package promptly upon each release of a new version of any component thereof. Contractor shall pay all fees and expenses charged by Escrow Agent, including, but not limited to, fees and expenses related to the State being a named beneficiary under the Escrow Agreement. The State shall treat the Source Code Escrow Package as Contractor’s confidential information. Under all circumstances, the Source Code Escrow Package shall remain the property of the Contractor. The State shall only use the Source Code Escrow Package as contemplated in the Contract (including, but not limited to confidentiality provisions and usage restrictions). The Escrow Agent shall maintain the Source Code Escrow Package in a repository located in the United States.

B. In the event that the Escrow Agent either ceases providing escrow services to Contractor or the Contractor determines in its reasonable business judgment that the Escrow Agent is no longer providing acceptable services, Contractor shall replace the Escrow Agent with another escrow agent, using an agreement which provides the State with rights no less advantageous than those in the Escrow Agreement. In such case, the new escrow agent shall be substituted in all ways for the incumbent Escrow Agent with respect to Section 1.15.3.A above and all references herein to Escrow Agent shall be deemed to include such substitute escrow agent.

C. Contractor shall inform the State of the availability of an escrow for any third party software solutions it provides to the State.

D. In addition to the rights and obligations contained in the Escrow Agreement referenced in Section 1.15.3.A, the State shall have the Software Escrow Package released by the Escrow Agent to the State’s possession immediately upon any voluntary or involuntary filing of bankruptcy or any other insolvency proceeding, including but not limited to a general assignment for the benefit of including but not limited to a general assignment for the benefit of creditors, the appointment of a receiver for business or assets; creditors, the appointment of a receiver for business or assets; Contractor’s dissolution or liquidation, voluntary or otherwise; the State has compelling reasons to believe that such events will cause Contractor to fail to meet its obligations in the foreseeable future; or Contractor’s discontinuance of support or failure to support in accordance with the Contract any software system or if the Contractor is otherwise unable or unwilling to provide the Source Code Escrow Package. This condition will also be considered met if after repeated email and phone requests by the State for service, the State makes a request for service in writing to the Contractor's last known address served by certified signed receipt required mail delivery by U.S. Post Office or by a nationally recognized (in the United States) overnight carrier, and the Contractor remains unresponsive, meaning that the Contractor is unable to acknowledge message receipt, unwilling or otherwise unable to satisfy the request for a period longer than 45 days from attempt to deliver the written request.

1.15.4 Purchasing and Recycling Electronic Products

[[If this solicitation does not include purchases or removal of electronic products, enter only the following sentence for this section and delete the rest.]]

This section does not apply to this solicitation.

[[If this solicitation does include purchases or removal of electronic products, enter the following language for this section:]]

State Finance and Procurement Article, Md. Code Ann. § 14-414, requires State agencies purchasing computers and other electronic products in categories covered by EPEAT to purchase models rated EPEAT Silver or Gold unless the requirement is waived by the DoIT. This information is located on the DGS web site: https://dgs.maryland.gov/Pages/GreenPurchasing/index.aspx

Guidelines provided by DGS require planning and coordination of the proper disposition of Information Technology equipment. State Finance and Procurement Article, Md. Code Ann. § 14-415, requires State agencies awarding contracts for services to recycle electronic products to award the contract to a recycler that is R2 or e-Stewards certified. This information is located on the DGS web site: https://dgs.maryland.gov/Pages/GreenPurchasing/index.aspx

Guidelines provided by DoIT discuss information and guidance on the proper disposition of IT equipment, media sanitization, and protecting confidential information stored on media. This information is located in the State's Information Technology (IT) Security Policy https://doit.maryland.gov/policies/Pages/20-07-IT-Security-Policy.aspx . Section 6.5 Media Protection provides guidance on proper precautions to protect confidential information stored on media.

1.15.5 The State of Maryland’s Commitment to Purchasing Environmentally Preferred Products and Services (EPPs)

Maryland’s State Finance & Procurement Article §14-410 defines environmentally preferable purchasing as “the procurement or acquisition of goods and services that have a lesser or reduced effect on human health and the environment when compared with competing goods or services that serve the same purpose.” Accordingly, Bidders/Offerors are strongly encouraged to offer EPPs to fulfill this contract, to the greatest extent practicable.

Change Control and Advance Notice

Unless otherwise specified in an applicable Service Level Agreement, the Contractor shall give seven (7) days advance notice to the State of any upgrades or modifications that may impact service availability and performance.

Contractor may not modify the functionality or features of any SaaS provided hereunder if such modification materially degrades the functionality of the SaaS.

1.16 Considerations for IT Technical Proposals

1.16.1	As part of the Offeror’s Technical Proposal under the Offeror Technical Response to RFP Requirements and Proposed Work Plan, submit under TAB F the following information:

1)	The Offeror shall provide a Voluntary Product Accessibility Template (VPAT) or an Accessibility Conformance Report (ACR) for any pre-existing digital technology, software, or source code proposed to be provided under the Contract containing a comprehensive analysis of the Offeror’s conformance to accessibility standards in Code of Maryland Regulations 14.33.02 (See RFP §4.33). The completed VPAT (VPAT 2.5 WCAG or most recent) must adhere to the current published standards. Failure to supply a VPAT or ACR for any pre-existing coded solution may result in the Offeror’s Proposal being deemed not reasonably susceptible for award.[1] [2]

2)	The Offeror shall provide a Backup solution/ strategy recommendation as part of its Proposal. [[Optional language; amend or delete if inapplicable.]]

3)	Disaster Recovery and Security Model description - For hosted services, the Offeror shall include its DR strategy, and for on premise, a description of a recommended DR strategy. [[Optional language; amend or delete if inapplicable.]]

4) The Offeror shall include a deliverable description and schedule describing the proposed Deliverables as mapped to the State SDLC and the Deliverables Summary Table in Section 1.1.4. The schedule shall also detail proposed submission due date/frequency of each recommended Deliverable. [[Optional language; delete if inapplicable.]]

5)	The Offeror shall include an SLA as identified in Section 1.6 of this Supplemental, including service level metrics offered and a description how the metrics are measured, any SLA credits should the service level metrics not be met, and how the State can verify the service level. The Offeror shall describe how service level performance is reported to the State. [[Optional language; delete if inapplicable.]]

6)	Description of technical risk of migrating from the existing system. [[Optional language; delete if inapplicable.]]

7)	Product Requirements

[[Carefully review the items below for applicability and delete if inapplicable.]]

a) Offerors may propose open source software; however, the Offeror must provide operational support for the proposed software.

b) Details for each offering: The Offeror shall provide the following information for each offering:

i) Offering Name;

ii) Offeror relationship with manufacturer (e.g., manufacturer, reseller, partner);

iii) Manufacturer;

iv) Short description of capability;

v) Version (and whether version updates are limited in any way);

vi) License type (e.g., user, CPU, node, transaction volume);

vii) Subscription term (e.g., annual);

viii) License restrictions, if any;

ix) Operational support offered (e.g., customer support, help desk, user manuals online or hardcopy), including description of multiple support levels (if offered), service level measures and reporting;

x) Continuity of operations and disaster recovery plans for providing service at 24/7/365 level;

xi) Ability of the offering to read and export data in existing State enterprise data stores. Offerors in their Proposals shall describe the interoperability of data that can be imported or exported from the Solution, including generating industry standard formats;

xii) Any processing or storage of data outside of the continental U.S;

xiii) Any limitations or constraints in the offering, including any terms or conditions, e.g., terms of service, ELA, AUP, professional services agreement, master agreement;

xiv) Compatibility with the State’s existing single sign-on system, SecureAuth or other single sign-on approaches;

xv) APIs offered, and what type of content can be accessed and consumed;

xvi) Update / upgrade roadmap and procedures, to include: planned changes in the next 12 months, frequency of system update (updates to software applied) and process for updates/upgrades;

xvii) Frequency of updates to data services, including but not limited to, datasets provided as real-time feeds, and datasets updated on a regular basis (e.g., monthly, quarterly, annually, one-time);

xviii) What type of third party assessment (such as a SOC 2 Type II audit) is performed, the nature of the assessment (e.g., the trust services criteria and scope of assessment), and whether the results of the assessment pertinent to the State will be shared with the State. See also Section 1.10;

xix) Offeror shall describe its security model and procedures supporting handling of State data. If more than one level of service is offered, the Offeror shall describe such services. Include, at a minimum:

(1) procedures for and requirements for hiring staff (such as background checks),

(2) any non-disclosure agreement Contractor Personnel sign,

(3) whether the service is furnished out of the continental U.S. (see security requirements in Section 1.9),

(4) Certifications such as FedRAMP,

(5) Third party security auditing, including FISMA,

(6) Published Security Incident reporting policy, and

(7) Cybersecurity insurance maintained, if any.

1.16.2	As part of the Offeror’s Technical Proposal under the Experience and Qualifications of Proposed Staff, submit under TAB G the following information:

[[Remove this Section if key resources are not sought as part of the Proposal. DoIT enforces a maximum of four proposed personnel during the evaluation process, who are presumed to be key personnel. ]]

As part of the evaluation of the Proposal for this RFP, Offerors shall propose exactly <<three (3)>> key resources and shall describe in a Staffing Plan how additional resources shall be acquired to meet the needs of the State. All other planned positions shall be described generally in the Staffing Plan and may not be used as evidence of fulfilling company or personnel minimum qualifications.

1.16.3	As part of the Offeror’s Technical Proposal under the Required Forms and Certifications, in addition to the forms listed in Table A, submit under TAB P the following information:

Offerors shall furnish any and all agreements and terms and conditions the Offeror expects the State to sign or to be subject to in connection with or in order to use the Offeror’s services under this Contract. This includes physical copies of all agreements referenced and incorporated in primary documents, including but not limited to any software licensing agreement for any software proposed to be licensed to the State under this Contract (e.g., EULA, Enterprise License Agreements, Professional Service agreement, Master Agreement) and any AUP. The State does not agree to terms and conditions not provided in an Offeror’s Technical Proposal and no action of the State, including but not limited to the use of any such software, shall be deemed to constitute acceptance of any such terms and conditions. Failure to comply with this section renders any such agreement unenforceable against the State.

For each service, hardware or software proposed as furnished by a third-party entity, Offeror must identify the third-party provider and provide a letter of authorization or such other documentation demonstrating the authorization for such services. In the case of an open source license, authorization for the open source shall demonstrate compliance with the open source license.

A Letter of Authorization shall be on letterhead or through the provider’s e-mail. Further, each Letter of Authorization shall be less than twelve (12) months old and must provide the following information:

i) Third-party POC name and alternate for verification

ii) Third-party POC mailing address

iii) Third-party POC telephone number

iv) Third-party POC email address

v) If available, a Re-Seller Identifier