addendum1-attachment10-rfp-appendixb-revised.pdf

Template V7.0 – 02/2025

STATE OF NEW HAMPSHIRE

New Hampshire Department of Transportation:

RFP DoIT # 2025-067 Managed Security Service Provider (MSSP)

RFP ISSUED July 13, 2026, 11:00 AM ET

ADDENDUM 1 ISSUED August 27, 2026

VENDOR CONFERENCE August 7, 2026, 10:00 AM ET

LOCATION DEPARTMENT OF TRANSPORTATION

JOHN O. MORTON BUILDING

7 HAZEN DRIVE

CONCORD, NH 03302

Room 114

STATE AGENCY POINT OF CONTACT Name: Nicholas King email: Nicholas.H.King@dot.nh.gov

Tel: 603-731-5973

CONTRACT TYPE Not to Exceed

PROPOSAL DUE DATE October 13, 2026 3:00 PM ET

STATE OF NEW HAMPSHIRE

DEPARTMENT OF TRANSPORTATION

RFP DoIT #2025-067 - Managed Security Service Provider (MSSP)

APPENDIX B: BUSINESS/TECHNICAL REQUIREMENTS AND DELIVERABLES

1. Statement of Work

The State of New Hampshire, acting through the NHDOT has released this Managed Security

Service Provider (MSSP) RFP to support the cybersecurity, monitoring, and protection of the

Department’s operational technology (OT) environment and transportation technology assets.

These assets include, but are not limited to, Intelligent Transportation Systems (ITS) infrastructure, traffic signal infrastructure, construction technologies including Smart Work Zones (SWZ) and hardware, communications networks (wired and wireless), field devices, and other operational systems deployed to support the safe and efficient operation of the State’s transportation network.

The qualified and selected MSSP Vendor – through and in coordination with the NHDOT Bureau of

Transportation Systems Management and Operations (TSMO) and the NH Department of

Information Technology (NH DoIT) - shall be responsible for delivering comprehensive managed cybersecurity services including real-time network security monitoring, threat detection, network protection, incident response, and vulnerability assessments, and ongoing technical support and coordination with NH DoIT and NHDOT stakeholders.

The MSSP Vendor shall operate across a diverse and evolving operational environment that includes both centralized data systems and a growing array of field-deployed devices such as dynamic message signs (DMS), closed-circuit television cameras (CCTV), radar sensors, weather stations, and traffic signal controllers. These devices operate across a communication network of fiber, wireless, and cellular VPN tunnels. As such, the MSSP Vendor will be responsible for ensuring security across both the ITS enterprise network and edge network.

The MSSP Vendor’s responsibilities will include identifying and addressing vulnerabilities, securing remote access to field equipment, monitoring system events for anomalies, and supporting incident response efforts in close coordination with NHDOT personnel. The MSSP Vendor will also be required to maintain a current inventory of network devices, including connectivity mapping and baseline traffic flow analysis, to assist in identifying intrusions or unauthorized activity.

In addition to work with network operations, the MSSP Vendor may be asked to provide compliance and governance support including federal, state, and local regulatory compliance. This may include review and recommendations for policy and procedures as well as alignment with the NIST

Cybersecurity Framework.

Hands-on support will be required for ITS network equipment in the field, and the MSSP Vendor will be expected to maintain field service readiness. While the TSMO Bureau will maintain a central inventory of network hardware, the MSSP Vendor must be able to respond to incidents within clearly defined service level agreements (SLAs), which may range from four-hour resolution for critical equipment failures to longer timelines for lower-priority issues. The MSSP Vendor must be available to support network design, architecture, and consulting services at the direction of

NHDOT. The MSSP Vendor will be expected to support the TSMO Bureau’s transition from a Layer 2 to a Layer 3 network. It will also assist with the integration of new traffic signal systems and connected vehicle infrastructure (V2I/V2X).

The MSSP vendor will not be responsible for operating and maintaining the ITS field devices themselves. The MSSP vendor’s responsibilities will be restricted to the network and communications infrastructure that connects these ITS field devices to the state system.

The qualified MSSP vendor shall demonstrate experience with state-level cybersecurity operations, and familiarity with transportation sector systems and security practices. The qualified MSSP vendor shall have expertise in working with various ITS hardware vendors and platforms.

Additionally, the qualified MSSP vendor shall follow strict cybersecurity practices and possess staff with relevant credentials including but not limited to: CCNA, CompTIA Network+, CompTIA A+, CISSP, CEH, GICSP. Field personnel are expected to hold or be supervised by staff with relevant industry certifications. The qualified MSSP vendor shall support log retention for a minimum of 365 days and offer optional pricing for longer retention periods. All work shall comply with federal and state cybersecurity standards and policies, including NIST, FedRAMP/StateRAMP, and will require close coordination with NH DoIT, including during any security incidents or investigations.

The MSSP Vendor will be required to provide security awareness and training to NHDOT and

NHDoIT personnel who are responsible for maintaining the NHDOT ITS network. This may include regular phishing simulations and on-line and in person security awareness training.

The MSSP will be expected to propose and operate within clear escalation protocols, deliver regular reporting and status updates, attend coordination meetings with NHDOT and NHDoIT leadership, coordinate change management procedures, and support future system upgrades and expansions. All services shall be delivered in alignment with NHDOT’s operational objectives, cybersecurity risk mitigation priorities, and support for uninterrupted transportation system operations.

2. Business and Technical Requirements

Please utilize the following instructions to complete all tables under 2.1 Business Requirements and 2.2 Technical Requirements and submit with your Proposal in Section III: Responses to System

Requirements and Deliverables.

Criticality Column:

(M) Indicates a requirement that is "Mandatory." The State considers it to be of such great importance that it must be met for the Proposal to be accepted. If the proposer believes that there is something about their Proposal that either obviates the need for this requirement or makes it of less importance this must be explained within the comments. The State retains the right to accept a Proposal if the need of the requirement is reduced or eliminated by another feature of the

Proposal.

(E) Indicates a requirement which is "Expected." This requirement is considered by the State to be of great usefulness, but the lack of this feature is not considered serious enough to disqualify the

Proposal.

(O) Indicates a requirement which is "Optional." This requirement is considered by the State to be one which is useful or potentially useful but not a central feature of the Project.

Vendor Response Column:

Enter “Yes” if the Solution can fully support ALL the functionality described in the row, without special customization. “Yes” can only be used if the delivery method is Standard (see delivery method instructions below).

Otherwise, enter "No"; "No" can only be used with delivery method Future, Custom, or Not

Available/Not Proposing (see delivery method instructions below).

Vendor Delivery Method Column:

Complete the delivery method using Standard, Future, Custom, or Not Available/Not Proposing (as defined below) that indicates how the requirement will be delivered.

Standard – Feature/Function is included in the proposed Solution and available in the current

Solution release.

Future – Feature/Function will be available in a future release. (Provide anticipated delivery date, version, and service release in the comment area.)

Custom – Feature/Function can be provided with custom modifications. (Respondent must provide estimated hours and average billing rate or flat cost for the modification in the comment area.

These cost estimates should add up to the total cost for modifications found in the cost summary table in Appendix E, Table E-2.2 of the RFP).

Not Available/Not Proposing – Feature/Function has not been proposed by the Vendor. (Provide brief description of why this functionality was not proposed.)

Vendor Comments Column:

For all Delivery Method responses, vendors must provide a brief explanation of how the requirement will be met. Free form text can be entered into this column.

2.1. System Requirements

System Requirements are identified in Table B-2.1 System Requirements (due to the size of the table, an Excel spreadsheet file has been provided with this RFP for responses). Vendor shall review the instructions above, complete the Table, and submit the completed Table as part of their Proposal. The Vendor shall provide a response to every requirement; failure to respond to any requirement shall be considered non-conforming and may result in rejection of the

Proposal.

Requirements in Table B-2.1 are marked Mandatory (M), Expected (E), and Optional (O).

Mandatory requirements are critical to the functionality of the MSSP and shall be met by the

Proposed Solution. The Vendor shall provide a justification for not meeting a Mandatory requirement by filling out the Comments column in the Table. The State has the sole authority to determine whether to consider a Proposal that does not strictly meet any Mandatory requirement. Expected requirements are considered to be useful to the functionality of the

MSSP and should be met by the Proposed Solution. The Vendor shall provide a justification for not meeting an Expected requirement by filling out the Comments column in the Table. The

State has the sole authority to determine whether to consider a Proposal that does not meet at least 80 percent of the Expected requirements. Optional requirements are additional features that the State may find useful but are not required to be part of the Proposed Solution.

Optional requirements are discussed in more detail in Appendix E-2.

2.2. Technical Requirements

Technical Requirements are identified in Tables B-2.2.1 through B-2.2.7 . The Vendor shall review the instructions above, complete the Tables, and submit the completed Tables as part of their Proposal. The Contractor shall provide a response to every requirement; failure to respond to any requirement shall be considered non-conforming and may result in rejection of the Proposal.

Table B-2.2.1 Prohibited Technologies

Req # State Requirement Description Criticality Vendor

Response

Vendor

Delivery

Method

Vendor

Comments

PT1

No equipment or services on the State of

New Hampshire's Prohibited Technologies

List found here: Prohibited Technologies List and

No equipment or services on the FCC

Covered List found here: FCC Section 2 List of Equipment and Services

M

PT2

It is the Vendor’s responsibility to check for the parent company for any equipment, products or services. Visit SAM.gov to search for prohibited companies.

M

Table B-2.2.2 Security Compliance Requirements

Vendor

Response

Vendor

Delivery

Method

Vendor

Comments

T1.1

Comply with controls required by NIST

Special Publication 800-171 R3, Protecting

Controlled Unclassified Information in

Nonfederal Systems and Organizations to achieve the Baseline

SP 800-171 Rev. 3, Protecting Controlled

Unclassified Information in Nonfederal

Systems and Organizations | CSRC (nist.gov)

T1.2

Comply With Moderate level controls as defined by NIST Special Publication 800-53

Revision 5, Security and Privacy Controls for

Information Systems and Organizations -

BaseLine Plus

SP 800-53 Rev. 5, Security and Privacy

Controls for Information Systems and

Organizations | CSRC (nist.gov)

E

Table B-2.2.3 StateRAMP Authorization (Also known as GovRAMP)

Vendor

Response

Vendor

Delivery

Method

Vendor

Comments

T2.1 StateRAMP Ready/Authorized Certification

Home - StateRAMP E

T2.2

If StateRAMP Ready, you agree to attain

StateRAMP Authorized within 12 months of the effective date of a resulting contract.

M

T2.3

If StateRAMP Active, you agree to attain

StateRAMP Authorized within 24 months of the effective date of a resulting contract.

M

T2.4

If StateRAMP In Process, you agree to attain

StateRAMP Authorized within 24 months of the effective date of a resulting contract.

M

T2.5

If StateRAMP Pending (Under review with

StateRAMP PMO awaiting a determination for a verified status), you agree to attain

StateRAMP Authorized within 24 months of the effective date of a resulting contract or prior to contract renewal.

M

T2.6

If Not StateRAMP Progressing, Not

StateRAMP Ready, or Not StateRAMP

Authorized the vendor shall initiate and provide a StateRAMP Security Snapshot with their response. You agree to attain

StateRAMP Authorized within 24 months of the effective date of a resulting contract.

T2.7

Continuous Monitoring – For any resulting award(s) and subsequent contract(s), the awarded contractor(s) will grant access to continuous monitoring and reporting upon receiving award for StateRAMP Security

Snapshot, Ready status and Authorization status through the life of the contract. The

State reserves the right to request and review all Third-Party Assessment Organization

(3PAO) audits, risk assessments, vulnerability assessments, and penetration tests of the contractor's environment. The contractor shall respond to all flaws discovered by providing a mutually agreed upon timeframe to resolve the issue and/or implement a compensating control.

Table B-2.2.4 Other Certifications in Lieu of StateRAMP

Vendor

Response

Vendor

Delivery

Method

Vendor

Comments

T3.1

FedRAMP Authorized https://www.fedramp.gov/How to Become

FedRAMP Authorized | FedRAMP.gov

O

T3.2

HITRUST (HITRUST is common for Health

Care related products and services.)

HITRUST Alliance | Information Risk

Management and Compliance

O

Table B-2.2.5 Hosted Platform

Vendor

Response

Vendor

Delivery

Method

Vendor

Comments

T4.1

The following Hosting Platforms are

FedRAMP/StateRAMP Authorized and are pre-approved to host any SaaS or other

Software Product. If your platform is included in the list below identify the platform in the

Vendor Comments.

• AWS US East/West

• AWS GOVCLOUD

• AZURE Commercial Cloud

• AZURE Government (Includes Dynamics

365)

• GOOGLE Services (Cloud Platform

Products and Underlying Infrastructure)

• ORACLE Government Cloud – Common

Controls

• ORACLE Federal Managed Cloud

Services

Table B-2.2.6 Individual Agency Compliance Requirements (Not Applicable)

Table B-2.2.7 Information Technology Accessibility Compliance

Vendor

Response

Vendor

Delivery

Method

Vendor

Comments

T6.1 Web content and mobile applications must comply with WCAG 2.1, Level AA.

M

T6.2

Hardware that transmits information or has a user interface, such as display screens, variable message signs, and kiosks, must comply with ICT Accessibility Standards and

Guidelines, Chapter 4: Hardware.

M

T6.3

Vendor shall complete the VPAT 2.5 WCAG

(November 2023) and submit with their proposal in Section III: Responses to

Requirements and Deliverables ITI

Accessibility Policy

2.3. Service Level Agreement (SLA)

By submitting a Proposal in response to this RFP, the Vendor agrees to the Service Level

Requirements described in Table B-2.3.

Table B-2.3 State Service Level Requirements

SLA -1 The Vendor’s System support and maintenance shall commence upon the

Effective Date and extend through the end of the Contract term, and any extensions thereof.

M

SLA -2 The Vendor shall maintain the system monitoring in accordance with the specifications, terms, and requirements of the Contract, including providing upgrades and fixes as required.

M

SLA -3 The Vendor shall repair or replace the hardware or software, or any portion thereof, so that the System operates in accordance with the Specifications, terms, and requirements of the Contract.

E

SLA -4 All hardware and software components of the Vendor hosting infrastructure shall be fully supported by their respective manufacturers at all times. All critical patches for operating systems, databases, web services, etc., shall be applied immediately upon availability of the patch. Patches for high vulnerabilities shall be applied within fifteen (15) calendar days from vulnerability publication date. All other patches shall be applied within sixty (60) calendar days from vulnerability publication date. (RA-5)

M

SLA -5 The State shall have unlimited access, via phone or email, to the Vendor technical support staff between the hours of 6:30am to 5:00pm- Monday through Friday ET.

M

SLA -6 The critical networking and communication equipment issues and incidents for the several service levels are defined in Supplemental Appendix B-2.3.1 Incident

Response.

M

SLA -7 As part of the maintenance agreement, the Vendor shall commit to the timeline for critical networking and communication equipment issues and incidents for the several service levels in accordance with Supplemental Appendix B-2.3.1 Incident

Response.

M

SLA -8 The hosting server for the State shall be available twenty-four (24) hours a day, 7 days a week except for during scheduled maintenance.

M

SLA -9 A regularly scheduled maintenance window shall be identified (such as weekly, monthly, or quarterly) at which time all relevant server patches and application upgrades shall be applied.

SLA -10 If the Vendor is unable to meet the uptime requirement of SLA-8 or the time-based requirements under SLA-2, SLA-4, SLA-5, and SLA-7, the Vendor shall credit the

State’s account in an amount based upon the following formula:

(Total Contract Item Price/365) x Number of Days Contract Item Not Provided.

The State must request this credit in writing.

SLA -11 The Vendor shall use a change management policy for notification and tracking of change requests as well as critical outages.

M

SLA -12 A critical outage will be designated when a business function cannot be met by a nonperforming application and there is no work around to the problem.

M

SLA -13 The Vendor shall maintain a record of the activities related to repair or maintenance activities performed for the State and shall report quarterly on the following:

• Service up-time

• All change requests implemented, including operating system patches

• All Vulnerabilities reported including corrective action plan

• All Incidents reported including actual issue and resolution

• Number of incidents reported by level with initial response time, service time, and resolution time.

M

SLA -14 The Vendor will give two-business days prior notification to the State Project

Manager of all changes/updates and provide the State with training due to the upgrades and changes.

M

SLA -15 The Vendor shall make available to the State the latest program updates, general maintenance releases, selected functionality releases, patches, and

Documentation that are generally offered to its customers, at no additional cost.

M

SLA -16 For all maintenance Services calls, the Vendor shall ensure the following information will be collected and maintained:

1. Nature of the Incident Response.

2. Current Status of the Incident Response.

3. Recommended Action plans, dates, and times.

4. Expected and actual completion time.

5. Incident resolution information.

6. Resolved by.

7. Identifying number i.e., work order number.

8. Issue identified by.

9. Development of After Action report.

M

SLA -17 The Vendor must work with the State to identify and troubleshoot system failures, incidents and vulnerabilities by collecting the following information:

1. Diagnosis of the root cause of the failure, incident, or vulnerability.

2. Identification of repeat calls or repeat problems.

3. Action item to minimize future repeats.

SLA -18 The State may assign specific assignments, tasks, and milestones throughout the life of the Project. When assignments are established with documented tasks and milestones, the Vendor shall be required to complete the assignments and tasks within the agreed upon milestones. Failure to complete assignments and tasks within the agreed upon time is subject to supplemental liquidated damages in accordance with NHDOT Standard Specifications Section 108. For assignments and tasks associated with this project, supplemental liquidated damages shall be at the rate of $260.00 per calendar day, which amount the Vendor shall credit the

State’s account.

The State must request this credit in writing for each failure to complete assignments and tasks or to meet agreed upon milestones.

M

SLA -19 If the State determines that the Vendor is at fault for failure to meet SLA-2 or SLA-

12 based on identified vulnerabilities and/or due to intrusions and exploits that result in damage (system damage, equipment damage and/or financial damage) to the State’s network, the Vendor shall be liable for the following:

1. Correct/repair the damage and address the vulnerability, intrusion, or exploit at no additional cost to the State; AND

2. The Vendor shall credit the State’s account in an amount equal to 120% of the financial cost or damage created by the failure.

The State must request this credit in writing.

SLA -20 The State may assign specific tasks as part of this Project. For example:

1. The Vendor shall work with the State to support the TSMO Bureau’s transition from a Layer 2 to a Layer 3 network (nearing completion).

2. The Vendor shall support the integration of new traffic signal systems into the TSMO Bureau’s network.

3. The Vendor shall support the Department’s integration of connected vehicle infrastructure (V2I/V2X).

4. The Vendor shall support expanding the Department’s use of Cisco

ISE, Catalyst Center and Cyber Vision on the ITS network.

Failure to complete tasks at the agreed upon milestones throughout the life of the

Project is subject to supplemental liquidated damages as described in SLA-18.

M

SLA -21 Failure to perform/submit/complete any other requirements of the Contract, including but not limited to System Requirements of Table B-2.1 and Deliverables from Table B-3, will be subject to supplemental liquidated damages as described in SLA-18.

3. Activity, Deliverable, or Milestone

Vendor shall be responsible for meeting the Deliverables, Activities and/or Milestones identified in

Table B-3: Deliverables.

Table B-3: DELIVERABLES

PLANNING AND PROJECT MANAGEMENT

1 Conduct Project Kickoff Meeting Non-Software

2 Implementation/Deployment Work Plan Written

3 Project Status Reports (submitted Monthly) Written

Infrastructure Plan, including Desktop and Network Configuration

Requirements Written

Security and Cybersecurity Plan, including an Incident Management and

Response Plan Written

6 Project Communications Plan Written

7 Change Management Plan Written

8 Software Tools and Systems Interface Plan Written

9 System Audit and Testing Plan Written

10 Data Storage and Archive Plan Written

11 Quality Management Plan Written

12 Business Continuity Plan Written

13 Documentation of Operational Procedures Written

INSTALLATION

14 Provide Software and Tools Licenses, if needed

Provide Software and Tools; Installed, Configured, and Operational to Satisfy State

Requirements

TESTING

16 Conduct Integration Testing Non-Software

17 Conduct User Acceptance Testing Non-Software

18 Perform Production Tests Non-Software

19 Test In-Bound and Out-Bound Interfaces Software

20 Conduct System Performance (Load/Stress) Testing Non-Software

Certification of 3rd Party Pen Testing and Application Vulnerability

Scanning.

Non-Software

SYSTEM DEPLOYMENT

22 Risk Matrix Written

23 System Restoration Plan Written

24 Conduct System Start-up Meeting Non-Software

25 Migration/Transition Plan Written

26 Begin Primary System Monitoring Non-Software

27 Develop ITS Vulnerability Assessment and Mitigation Plan Written

28 Provide Documentation Written

29 Execute Security and Cybersecurity Plan Non-Software

CLOSE OUT

30 Transition Primary System Monitoring to NHDOT Non-Software

31 Turn-Over all System Logs to NHDOT Written

32 Conduct Project Exit Meeting Non-Software

4. Data Location

The Vendor shall provide its Services to the State and its end users solely from data centers within the Continental United States. All storage, processing and transmission of State Data shall be restricted to information technology systems within the Continental United States. The Vendor shall not allow its personnel or sub-contractors to store State data on portable devices, including personal computers, except as specified and allowed by the Contract, and then only on devices that are used and kept at its data centers within the Continental United States. The Vendor shall permit its personnel and contractors to access State data remotely only to provide technical support and as specified or required by the Contract.

5. Background Checks

The Contractor shall conduct criminal background checks and not utilize any staff, including subcontractors, to fulfill the obligations of the Contract who have been convicted of any crime of dishonesty, including but not limited to criminal fraud, or otherwise convicted of any felony or misdemeanor offense for which incarceration for up to 1 year is an authorized penalty. The

Contractor shall promote and maintain an awareness of the importance of securing the State’s information among the Contractor’s employees and agents.

The State may, at its sole expense, conduct reference and background screening of the

Contractor’s Project Manager and Key Project Staff. The State shall maintain the confidentiality of background screening results in accordance with the Contract Agreement.

Remainder of this page intentionally left blank.