Norfolk Airport IDMS RFP.pdf

NORFOLK AIRPORT AUTHORITY

REQUEST FOR PROPOSALS

FOR

IDENTITY MANAGEMENT SYSTEMS

RFP ISSUE DATE: January 17, 2024

Questions Due By: January 31, 2024 (by 2:00 PM EST)

Proposal Due Date: February 20, 2024 (by 2:00 PM EST)

Vendor Demonstrations (if required): March 5 and 6, 2024.

Contract Award Date: May 1, 2024

NORFOLK INTERNATIONAL AIRPORT (ORF)

IDENTITY MANAGEMENT SYSTEM (IDMS)

Contents

SECTION 1.0

1.1 INTRODUCTION

1.2 OBJECTIVE

1.3 BACKGROUND

1.4 SCOPE

1.4.1 ENVIRONMENTS

1.4.2 IMPLEMENTATION APPROACH

1.4.3 WARRANTY, SUPPORT AND MAINTENANCE

1.5 PRICING AND PAYMENT SCHEDULE

SECTION 2.0

2.1 LENGTH OF CONTRACT

2.2 MINIMUM QUALIFICATIONS REQUIREMENTS

2.3 EVALUATION CRITERIA

2.4 EVALUATION CRITERIA DEFINITIONS AND EXPECTATIONS

2.4.1 PROJECT APPROACH

2.4.2 EXPERIENCE, QUALIFICATIONS AND REFERENCES

2.4.3 FUNCTIONAL AND TECHNICAL REQUIREMENTS

2.4.4 EXECUTION PLAN

2.4.5 PRICING PROPOSAL

2.5 PROPOSAL PREPARATION OUTLINE

2.5.1 TRANSMITTAL LETTER

ATTACHMENT A: EXISTING SYSTEMS, TECHNOLOGIES & BUSINESS PROCESSES

ATTACHMENT B: FUTURE BUSINESS PROCESSES

ATTACHMENT C – FUNCTIONAL REQUIREMENTS

ATTACHMENT D – TECHNICAL REQUIREMENTS

ATTACHMENT E - COST PROPOSAL WORKSHEET

ATTACHMENT F: SERVICE PROVIDER AGREEMENT

ATTACHMENT G: ACKNOWLEDGEMENT FORM - SERVICE PROVIDER AGREEMENT

SECTION 1.0

1.1 INTRODUCTION

Norfolk International Airport (ORF) is soliciting responses to this Request for Proposal (RFP) from qualified firms for a comprehensive and automated Identity Management System (IDMS) at the

Norfolk International Airport (“Airport” or “ORF”).

The received proposals will be utilized to select and award the contract to One (1) Contractor who is experienced in the deployment of an Identity Management System (IDMS) at US Airports. All submissions received prior to the submission deadline which meet the minimum requirements will be evaluated by the evaluation committee at Norfolk International Airport (ORF). At the Airport’s discretion, a select group of shortlisted Contractors will be asked to provide a demonstration of their product. Those submissions not selected will be eliminated from further consideration.

1.2 OBJECTIVE

Norfolk International Airport (ORF) primary objectives for seeking an automated Identity

Management System (IDMS) are:

- reduce manual, time consuming, error prone, and duplicate data entry in multiple standalone systems and excel sheets.

- improve customer service; and achieve paperless process.

- enforce business rules for badge issuance.

- comply with the Transportation Security Administration (TSA) regulations and Security

Directives (SD).

- provide data integrity and security for the airport employee’s information.

1.3 BACKGROUND

There are approximately 2,500 active badged airport employees and approximately 180

Authorized Signatories (AS). The Airport employees and AS represent airport employees, airline, tenants, contractors, vendors, concessionaires, and government (local, state, and federal) agencies at ORF. The Airport Badging Office handles approximately 10-12 transactions per day.

These transactions include processing new and renewal applicants, fingerprinting, and issuing replacement badges.

The current process entails paper application forms (filled by the employee / badge applicant, reviewed, and signed by the AS) to be then entered by the badging office staff in multiple systems that provide specific functions for background checks, training, financial (Point of Sale and receipt printer) and access control.

1.4 SCOPE

The scope of this project includes the procurement, configuration, installation, support & maintenance of a new IDMS for ORF. The proposed solution will be configured and installed on the ORF environment provisioned for use by ORF.

Significant coordination with IT, Security and other Airport departments will be required to further define current software versions, configuration limitations, project phasing and training. This solution will be configured in a test environment and then rolled into the production environment.

Environments are defined later in this document.

Existing Business Process: The Contractor will refer to the existing business processes for standard systems and specialized system interfaces, badging office setup, badge types and privileges in Attachment A of this document.

Future (Proposed) Business Process: The Contractor will refer to the future (proposed) business processes, system architecture and badging office setup in Attachment B of this document.

Functional and Technical Requirements: The Contractor will respond to all the functional and technical requirements identified in Attachment C & D of this document. Requirements left blank or with no responses will be considered a non-compliant response.

1.4.1 ENVIRONMENTS

ORF will provide the server, server operating system, SQL server, workstations, network infrastructure and badge stock. The Contractor will provide the software and hardware required for successful IDMS implementation. The Contractor will provide detailed server and network requirements based on the minimum specifications and quantities.

Environment Name Description

Testing and Training

(Pre-production)

1) Development environment will host a “working out-of-the-box” IDMS with sample database installed by the IDMS Contractor.

2) ORF will provide a database server for where source data repositories will be made available. The Contractor will use this setup for data analysis, reconciliation reports generation, and data migration activities. The Contractor will run as many iterations as possible of data analysis, reconciliation and data migration required to provide ORF with confidence in migrated data.

3) This environment will be used for system acceptance testing, system performance evaluation, and training.

4) This environment will be a complete replica of the Production system.

5) All hot fixes, patches, upgrades will be applied to this environment to keep in sync with the Production environment.

Production

1) This environment will be the production setup.

Changes will be implemented in the Testing and Training Environment first and only after approvals from ORF will the changes be installed in the Production Environment.

1.4.2 IMPLEMENTATION APPROACH

The IDMS implementation is to be performed in a single phase. However, the Contractor may recommend an alternate implementation strategy that will reduce implementation timeframes without compromising the functionality and performance of the expected IDMS, as per the requirements.

Below is a list of Contractor responsibilities, tasks, and deliverables to be included in the project implementation.

1. The Contractor will within thirty (30) days of the Notice to Proceed (NTP) submit for ORF to review the Project Charter to include the following:

a) Project schedule

b) Communications Plan should address at a minimum the following topics:

i. Weekly and monthly project status meetings followed by minutes.

ii. Monthly executive summary reporting including financial statuses, tasks completed, 30-60 look ahead reporting, project risks and schedule impacts / changes.

iii. Forms and templates to track ongoing open items, issues, actions, decisions, and statuses.

c) Change Management Plan should include at a minimum:

i. Request for Information (RFI) process, form templates, and method to document resolutions.

ii. Change control process for raising change requests, review and approval methods, form templates, and cost analysis impacts.

d) Business process workflows, system design and technical documentation

i. Business process workflows (swim lanes) for handling:

1. Company onboarding, de-activation, exception scenarios such as name change and mergers.

2. AS onboarding, off boarding, pre-enrollment, renewals, audits, etc.

3. Applicant portal functions.

4. Badge holder pre-enrollment, badge issuance including exceptions such as background checks fails, re-fingerprinting, adjudications, Rapback, etc.

5. All business rules that are necessary for the functioning of the IDMS.

ii. System Architecture: Physical and logical design indicating all internal and external systems connectivity for Testing and Training Environment and

Production Environment.

iii. System Software & Hardware Requirements: Server, OS, Database, Network, Firewalls, Workstations, service accounts (server, databases, 3rd party systems), badging equipment including quantities for servers, workstations, and badging peripherals.

iv. External Systems Interface Control Documents

e) Data Migration Plan should include:

i. impact analysis of certain data fields that are mandatory for the normal performance of the IDMS.

ii. The contractor will submit reports of preliminary analyses from the data repositories identifying missing or incorrect data elements.

iii. The contractor will recommend the priorities for critical and mandatory data elements that need to be cleaned up by ORF including implications and associated timeline(s) per the project plan. Additionally, the Contractor is to provide suggestions for clean-up priority for non-critical/ non-mandatory data elements.

iv. The Contractor will perform data migration into the test environment such that the system is test ready.

2. The Contractor will first install and configure the system in the Testing and Training

Environment (pre-production) and perform the system acceptance testing and training in this environment.

3. The Contractor will perform readiness testing and submit testing results to:

a) ensure that the system components meet business and process requirements as established in this RFP,

b) ensure system software has been configured such that it meets the functional and technical requirements and future business processes as established in this RFP,

c) ensure system acceptance can commence by the ORF users.

4. The Contractor will provide for the system acceptance testing the following:

a) Test Plan to include test timeline, staff and equipment resources required.

b) Test scripts / Test cases: Scenario based and mapped to the Functional Specifications

Requirements established.

c) Online Issue Tracking System: Method to log, identify issues (bug/missing functionality/ not in scope/ other) and track testing results for actions.

5. The Contractor will receive System Acceptance Approval in the Testing and Training

Environment from the ORF after all requirements are demonstrated and tested, there are no open items, and ORF has provided explicit acceptance of the system.

6. The Contractor will be required to conduct training for the system users – Trusted Agents, Authorized Signatories, and other Airport users.

7. The Contractor will provide User Manuals – electronic copies (pdfs) and hard copy, bound user manuals for all training sessions. The user manuals and “Help” will be made available within the IDMS application such as Authorized Signatory portal or application portals.

8. The Contractor will be required to perform the implementation and roll out of the system into the Production Environment. The installation in the Production Environment must take place after ORF has approved the System Acceptance Testing.

9. The Contractor will provide an Implementation Plan or Run Book for ORF’s review and approval which will include – step-by-step guide for installation, configuration, database migration, 3rd party integration sequence and production sanity testing details. Each step will include the resource responsible, and time taken for each step. The Contractor will provide details of all the resources required on-site from the Contractor, ORF Security, IT and any 3rd party systems.

10. The Contractor will provide two (2) full time engineering resources familiar with ORF’s implementation and will be on-site for two (2) weeks post go-live for support and system stabilization.

11. The Contractor will provide details, before the IDMS go-live, for ORF’s review and approval, of the maintenance and support system. The details should include the ticketing system information. The Contractor will train key ORF staff to use the ticketing system that will allow ORF to report and track production issues.

12. There will be a system stabilization period of a minimum of thirty (30) calendar days after the IDMS is working in the Production Environment. During this period, the Contractor will monitor and report system health checks to include - performance metrics, integration or network issues, database growth, or other system (functionality) related issues that impact the badging operations. The Contractor will work with ORF for corrective actions on any of the items identified during this period. The exact start and end date of the stabilization period or if the stabilization period will be reset due to critical issues (as defined in section

1.7 of this document) encountered will be agreed upon with ORF.

13. ORF will provide final system acceptance in Production Environment once all phases are complete. ORF is experiencing beneficial use of the system, and there are no critical open issues. The Warranty period will begin only after ORF has accepted the system in the

Production environment.

1.4.3 WARRANTY, SUPPORT AND MAINTENANCE

The Contractor will be responsible for maintaining the software components procured as part of the IDMS contract. The maintenance period is defined in the length of contract section of this document.

For the purposes of this section the “IDMS” represents all components of the software including functionality modules, 3rd party or external integrations, badging equipment hardware and firmware, and any add-on modules installed by the Contractor.

The one (1) year warranty period and subsequent maintenance years for all components

(software and hardware) will commence after the Final System Acceptance in Production

Environment by ORF.

1. The Contractor will provide a one (1) year manufacturer-based warranty on all components (software and hardware) provided by the Contractor. The Contractor warrants that the IDMS will be free of defects in workmanship and materials for a period consistent with industry standards and the nature of the (“Warranty Period”). The

Contractor includes an explanation of the system’s warranty coverage and includes optional extended maintenance agreement\warranty options.

2. The Contractor will develop and submit a maintenance plan required under the IDMS contract. The Contractor will document service levels including, but not limited to, coverage time, maintenance request response time and acceptable system downtime. All software upgrades during the warranty period and subsequent maintenance years will be performed at no additional cost to ORF and will be as part of a maintenance agreement.

All system maintenance will be completed in coordination with ORF.

3. After ORF has initiated the warranty and maintenance phase, the Contractor will provide updates, enhancements, and/or bug fixes to all systems at no additional charge during the term of any maintenance/service agreements. All system changes will be conducted in coordination with ORF.

4. The Contractor will provide all (software and hardware) upgrades in the first-year warranty and included in subsequent years as part of maintenance agreements. The Contractor will provide methods for version and periodic upgrades to support changes in platform operating systems, support applications and security requirements. The Contractor will provide during the warranty period, and any period thereafter, where the IDMS is covered by an annual maintenance agreement, no-charge updates to maintain compliance with

CCURE and TSC upgrades.

5. During the warranty period, if the IDMS does not perform in accordance with the Contract, then the Contractor will take such steps as necessary to repair or replace the defective portion at no additional cost to ORF for material and labor. Such warranty service will be provided at the Contractor’s expense.

6. If any defect in the IDMS is not rectified by the Contractor before the end of the Warranty

Period, the Warranty Period will be extended until, in the opinion of ORF, the defect has been corrected; and the IDMS functions in accordance with the Contract are operational for a reasonable period. Once the defect has been rectified, it is at the sole discretion and option of ORF to request that the acceptance testing for the IDMS be reperformed.

7. Despite any other provision, ORF may return a defective IDMS to the Contractor within thirty (30) days of delivery of the IDMS and the Contractor will immediately provide full exchange or refund.

• For this section, “defective Solution” includes, but is not limited to: (1) IDMS has not met contractual obligations during acceptance testing or during the valid

“Warranty Period”. (2) IDMS causes significant impact and disruption to ORF operations and requires excessive downtime and interaction of ORF staff.

Excessive downtime is defined when IDMS is non-operational for more than sixteen (16) business hours or two (2) full business days.

8. The ORF staff reporting the issue will describe and categorize the support issues as follows:

1.4.3.1 Service Level Agreement (SLA)

Critical Issues & Response Times:

Critical issues are defined as catastrophic failures which affect the overall operations at ORF.

For example, the failure of a server, or the loss of integration or errors in the integration between the IDMS and external systems. Critical issues require the Contractor to respond per the response times indicated below.

Critical Issues Response Times:

• Initial response and acknowledgement within 15 minutes (business or non-business working hours) of reported issue(s).

• Follow up contact with ORF representative within thirty (30) minutes (business or non-business working hours) to understand the issue and to start the trouble shooting process.

The Contractor will establish a conference line and hourly status calls.

• Within two (2) hours (business working hours) of the issue being reported, the Contractor will provide the next steps to fix the issue or advise and initiate restoring system(s).

• Within eight (8) hours (business working hours) of the issue being reported, the Contractor will restore the system back to operational status.

Liquidated Damages:

• Failure to fix the Critical issue and restore the IDMS to a fully operational state within eight

(8) hours from the issue being reported, ORF will result in the imposition of liquidated damage of $250 per hour, to be specified in the Authority’s Professional Services Agreement to be entered into by the Contractor and the Authority. The Contractor will reduce the monthly invoice by the amount assessed by ORF.

• Failure to fix the Critical issue and restore the IDMS to fully operational state after two (2) business days will result in liquidated damages of up to 5% of the monthly invoice.

• The Contractor will not be charged with delay, or assessed Liquidated Damages for delay or failure, which occurs for reasons beyond the reasonable control of the Contractor or subcontractors, as determined by ORF.

Non-critical Issues and Response Times:

Non-critical issues are defined as failures or problems which do not affect the operations at ORF. For example, the failure of a non-critical redundant piece of server, or the issue with report generation would usually be considered non-critical.

Non-critical Issues Response Times (Service level agreement):

• Initial response and acknowledgement within 15 minutes (business working hours) of reported issue(s).

• Follow up contact with ORF representative within two (2) hours (business working hours) to understand the issue and start trouble shooting process.

• Within twenty-four (24) hours (business working hours) or two (2) business days of the issue having been reported, the Contractor will provide status and next steps to fix the issue. The Contractor will diagnose and remedy the problem during normal working hours of the next working day.

Liquidated Damages:

• Failure to fix the non-critical issue within twenty-four (24) hours (business working hours) or two (2) business days of the issue having been reported will result in liquidated damages of $100 per issue. The Contractor will reduce the monthly invoice by the amount assessed by ORF.

• The Contractor will not be charged with delay, or assessed Liquidated Damages for delay or failure, which occurs for reasons beyond the reasonable control of the Contractor or subcontractors, as determined by ORF.

Business working hours are defined as 7:00 AM to 5:00 PM Eastern Time, Monday through Friday.

9. The initial status of a given outage will be communicated to the Contractor during initial notification. Should a “non-critical” outage be escalated to “Critical” status, the response time or service level agreements defined above will begin from the notification of the escalation of status to “Critical”, and not from the initial notification of the non-critical event. If the resolution to the reported incident is within the control and responsibility of the Contractor, these SLA liquidated damages will apply. If the outage or incident is caused by something outside the reasonable control of the Contractor, then liquidated damage for failure to meet SLAs will not be assessed. The determination of responsibility resides with

ORF Security Manager and Authority management.

10. The Contractor will provide escalation procedures including contact name, direct phone number and email address.

11. The Contractor will provide a detailed process including toll-free telephone and support email to ORF representative(s) to report any production issues encountered.

12. The Contractor must provide an online portal for support ticket requests. While reporting the issues ORF must be able to select the currently installed configuration options for the software and services being supported. The online support portal must provide the customer details such as:

o Software installed with versions.

o Knowledge base of previous support cases.

o Technician assigned to support request.

o Status updates on support tickets – via e-mail.

o Listing all support tickets and who initiated the tickets.

o Support category: warranty, out of warranty, covered, not covered.

o Designate issue criticality (Critical or Non-Critical) and designate priority: Low, Medium, High.

o Ticket resolution with details.

1.5 PRICING AND PAYMENT SCHEDULE

Below is a proposed payment scheduled based on project milestone completion. The Contractor will be paid as per the breakdown below.

# Milestone Name Software

Licenses %

Professional

Services % Hardware

(1) Project Initiation (Kick-off and

Workshop);

(2) Install IDMS COTS in Airport Test and Training environment

25% 15%

Test

Quantity costs

(1) Data Analysis and Data Migration

Configure IDMS

(2) Contractor performs System

Acceptance Readiness Testing

15%

System Acceptance Testing in Test

Environment 25% 25%

Production

Quantity costs

4 Completion of Training 10%

5 Go-Live 25% 15%

Final System Acceptance in Production

Environment & Project Close Out 25% 20%

SECTION 2.0

2.1 LENGTH OF CONTRACT

This contract will run for the base project implementation period of no more than twelve (12) months upon Notice to Proceed (NTP) with a 1-year warranty commencing upon final IDMS acceptance. The Contractor’s response must provide a baseline schedule as part of the proposal containing sufficient detail to complete the installation within the specified timeframe with their proposal. The Contractor is encouraged to make recommendations regarding improvement to the anticipated project schedule.

• IDMS Implementation and Go-live.

• Year 1: Warranty, Support & Maintenance (No cost to ORF)

• Years 2, 3, 4 & 5: Maintenance and Support

• Years 6 & 7: Maintenance and Support (Option Periods extended by the

Authority)

2.2 MINIMUM QUALIFICATIONS REQUIREMENTS

The minimum requirements for the Contractor to be eligible for proposal evaluation consideration is as follows:

• The Contractor should have qualified and experienced IDMS personnel on staff and be assigned to this project.

• The IDMS product version, proposed in the Contractor’s proposal, must have been installed and operational in three (3) or more airports in the United States of similar size as ORF.

• The IDMS must have established and operational software interfaces with Physical Access Control System (Software House C•CURE 9000) AND Designated Aviation Channeling (DAC) service provider (TSC) in three (3) or more airports in the United States of similar size as ORF.

2.3 EVALUATION CRITERIA

The Team will use the criteria noted below for the final selection of the Contractor for contract award. The Team, after scoring the proposals, may decide to short list specific Contractors for

IDMS product demonstrations. The product demonstrations will be scored separately from the evaluation criteria defined below. The Airport will send communications to the shortlisted

Contractors with details for the product demonstration and requirements.

Based on the results of the proposals and if required product demonstrations, one (1) IDMS

Contractor will be selected for further action, such as contract negotiations and contract award.

If, however, it is decided that no response is sufficiently advantageous, the Airport proposal evaluation team may take whatever further action is deemed necessary to fulfill its needs. If, for any reason, a proposal is selected, and it is not possible to finalize a subcontract with the

Contractor, the Airport may begin contract negotiations and discussions with the next qualified

Contractor or determine that no such alternate proposal exists.

Criteria Points

Project Approach 15

Experience, Qualifications and References 20

Functional and Technical Requirements Specifications Response 25

Execution Plan including Project Schedule 10

Pricing Proposal (implementation costs, software licenses, hardware and maintenance)

TOTAL POINTS 100

2.4 EVALUATION CRITERIA DEFINITIONS AND EXPECTATIONS

2.4.1 PROJECT APPROACH

The Project Approach must be divided into sections as described below. Every point made in each section should be addressed in the order given with the question first stated followed by the

Contractor’s response. The same outline numbers should be used in the response. RFP language may be referenced but should not be repeated within the response.

2.4.1.1 Overview of Proposed Method

This overview must consist of a concise summary of the requested services proposed by the

Contractor in response to this RFP. By reading the overview, the Team must be able to gain a comfortable grasp at a general level of the services to be provided and the methods proposed by the Contractor to provide them.

2.4.1.2 Approach Description

The description must indicate the methodology the Contractor will follow to fulfill the requirements of the scope. A detailed explanation should be included to understand how the proposed services comply with the technical components of this RFP. The Team intends that each Contractor provide a detailed and comprehensive description of all services that the Contractor will provide if it enters into a contract with the Authority pursuant to the RFP.

The Project Approach should detail how the Contractor will work with the Team and the Airport to ensure there are no operational impacts to the Airport’s badging office during the implementation.

It will detail how the existing security systems will be maintained and transitioned during the implementation, how operators will work with the existing and new solution prior to final cutover, and how users will be trained on the solution. Approach will detail how business rules and processes currently in place in the Airport’s badging office will be implemented and potentially automated within the new solution.

Approach will detail the Contractor’s experience managing IDMS implementation projects in and around an active airport airfield and terminal sterile facilities. Specific reference should be included as to how a safe and secure environment will be maintained throughout the implementation.

2.4.1.3 Identification of Anticipated Risks

The proposal should identify and describe any anticipated potential problems, the Contractor’s approach to solving these problems, and any special assistance that will be requested from the

Airport.

This section should specifically reference the Contractor’s experience with IDMS, specifically interfaces with standard systems, and the lessons learned which will be utilized in implementing this project.

2.4.2 EXPERIENCE, QUALIFICATIONS AND REFERENCES

2.4.2.1 Experience

The Team seeks proposals from Contractors who can provide an IDMS and all components including warranty, support and maintenance as described in this RFP.

Describe the Contractor’s experience in IDMS design, system interface design and development with Software House CCURE 9000, Transportation Clerance house (TSC). Describe projects that illustrate the Contractor’s experience in managing implementations of a similar scope and size relative to the systems and interfaces described in this RFP.

2.4.2.2 Qualifications

The Contractor will provide qualification information as indicated below for the proposed Project team and their qualifications:

- Include a project organizational chart identifying the Project Manager and key staff needed to perform and manage the scope of work described in this RFP.

- Include the names, titles and task responsibilities of key staff and general staff who will be involved in this project.

- Provide a responsibility matrix indicating the reporting structure related to the scope of this project.

- Once a contract is awarded and executed, the Airport must approve any change(s) to the key staff assigned to the project.

- Provide resumes for all names listed above as key and general staff members. Indicate on resumes previous experience with IDMS projects. Limit resumes to one page and describe:

• IDMS professional qualifications and years of experience.

• Customer and project along with the start and end dates.

• Related education, training, and applicable certifications.

• Staff member’s experience level. Example: Staff member’s experience was as a Project Manager, Business Analyst, Programmer (include the name of software application) interfaces, training, etc.

At a minimum, the Contractor’s Project Manager and technical lead staff assigned to this project should have previous experience with implementing IDMS’s at up to three (3) similar size airports or similar facilities as indicated in this RFP.

2.4.2.3 References

Contractor’s previous experience in implementing an IDMS at similar size US Airports – Provide up to three (3) airport references. Airport reference contacts provided by the Contractor should have direct knowledge of the Contractor’s experience with similar work defined in this RFP.

The Team, in its sole discretion, reserves the right to contact all references and to request additional supporting information from the Contractors as necessary.

Airport References must include at a minimum:

i. Airport name.

ii. Airport contact person name and title (Project Manager or principal individual) with direct knowledge of contract and service performance.

iii. Telephone number.

iv. E-mail address.

v. ID count and quantity of badging workstations.

vi. Standard interfaces.

2.4.3 FUNCTIONAL AND TECHNICAL REQUIREMENTS

The Contractor will respond to all the functional and technical requirements listed in the RFP.

2.4.4 EXECUTION PLAN

The proposal will include an Execution Plan and schedule that includes consideration of coordination with the Airport’s badging office staff, authorized signatories, operations staff, IT staff, any other required representatives, and the Transportation Security Administration (TSA).

The proposal will include a Work Breakdown Structure (WBS) to the most detailed task level. The

WBS should specifically highlight the responsible party (IDMS Contractor, Airport, IT etc.) that will be executing the work.

The WBS will detail the parts of the project that Airport personnel will be required to have internal deliverables ready. This includes, specifically, the server and storage environment required for the implementation of the IDMS.

2.4.5 PRICING PROPOSAL

The pricing proposal will include all fees, costs, charges, and other amounts, associated directly or indirectly, with providing all things necessary to perform the implementation of this project as indicated in this RFP. Failure to comply fully with the requirements will be cause for the rejection of a proposal, as non-compliant, from further consideration.

Pricing Sheet: The Contractor will provide the cost detailed proposal as per the format provided in Attachment E of this document.

2.5 PROPOSAL PREPARATION OUTLINE

To facilitate the timely evaluation of the proposal, a standard format for proposal submission has been developed and is documented in this section. All Contractors are required to format their proposals in a manner consistent with the guidelines described below:

• The proposal must be no longer than fifty (50) pages of 10 pt. type with margins at a minimum of one inch.

• Proposals should include an original, five (5) copies, and one electronic sent to sdward@norfolkairport.com. Hard copies must include the proposal and all attachments in an envelope which shall be sealed, conspicuously endorsed with the Offeror's name, the words "Airport IDMS”, the date, time and place the Proposal is to be received.

• The Norfolk Airport Authority (NAA) is soliciting proposals from qualified firms for a comprehensive and automated Identity Management System (IDMS) at the Norfolk

International Airport, to be delivered to Shelia D. Ward, Vice President and Chief

Operations Officer, at sward@norfolkairport.com. Proposals must be accepted by 2:00 p.m. on February 20, 2024.

• ORF may, at their option, allow all Contractors a five-calendar-day period to correct errors or omissions to their proposals. Should this necessity arise, ORF will contact each

Contractor affected. Each Contractor must submit written corrections to the proposal within five (5) calendar days of notification. The intent of this option is to allow proposals with only minor errors or omissions to be corrected. Major errors or omissions, such as the failure to include prices, may result in disqualification of the proposal from further evaluation.

• The transmittal letter should be in the form of a letter. The proposals must be organized under the specific section titles as listed below:

PROPOSAL OUTLINE

1 TRANSMITTAL LETTER

2 PROJECT APPROACH

3 EXPERIENCE, QUALIFICATIONS AND REFERENCES

RESPONSE TO ATTACMENT C AND D - FUNCTIONAL

AND TECHNICAL REQUIREMENTS SPECIFICATIONS

RESPONSE

5 EXECUTION PLAN INCLUDING PROJECT SCHEDULE

ATTACHMENT E - PRICING PROPOSAL

(IMPLEMENTATION COSTS, SOFTWARE LICENSES,

HARDWARE AND MAINTENANCE)

ATTACHMENT G – ACKNOWLEDGEMENT FORM FOR

SERVICE PROVIDER AGREEMENT

2.5.1 TRANSMITTAL LETTER

The Transmittal Letter must address the following topics, except those specifically identified as

“optional.”

mailto:sdward@norfolkairport.com mailto:sward@norfolkairport.com

Summary of Ability to Supply the Required Services

The transmittal letter must briefly summarize the Contractor’s ability to supply the requested services that meet the requirements defined in Section One of this RFP.

The letter must also contain a statement indicating the Contractor ‘s willingness to provide the requested services subject to the terms and conditions set forth in the RFP.

Summary of Compensation

Contractor should specifically state the proposed fee for the services described in this RFP. If there are any services described in the proposal and scope section that would not be included in such compensation, the Contractor will state these deviations specifically, along with an indication.

of any proposed additional charges. See “disclosure” statement below for further information in completing the response regarding fee proposal and overall compensation.

The contractor should also include a detailed summary of any additional services including the price for all such services, if any, rendered that would be considered outside of the fee proposal.

Proposal Life

A statement must be included that indicates the length of time during which the ORF may rely on all proposal commitments. The ORF requires that this period not be less than ninety (90) days from the due date for submission of proposals. Any proposal accepted by the ORF for contract negotiations must remain as committed through the contract negotiation period.

Signature of Authorized Representative

An individual person legally authorized to act on behalf of and commit the Contractor to its representations must sign the transmittal letter. Written evidence of this authorization must be provided as part of the Proposal.

Other Information

This item is optional. Any other information the Contractor may wish to briefly summarize will be acceptable.

All other proposal outline topics are defined in Section 2.4

ATTACHMENT A: EXISTING SYSTEMS, TECHNOLOGIES &

BUSINESS PROCESSES

Airport Badging Office Systems / Applications

The Airport Badging Office uses various disparate and standalone systems. Below is a representation of the systems in places that are not interconnected or integrated with each other.

LiveScan

(IDEMIA)

DACS

(TSC)

Access Control System

Software House

C CURE 9000 v2.7

Finance System

(PoS)

Mass Notification System

(EverBridge)

Systems Lack

Data Integration

Access Control System (ACS) – The Airport ACS consists of a Software House C•CURE 9000 v2.7 application operating on physical servers within the Airport credentialing office. The Airport uses the C•CURE ID badging functionality to design badges, store badge holder information, capture photos and print badges using existing badge printers. The clearance codes are defined in the ACS and then assigned to badge holders. The Airport manages a Company clearance code binder. The clearance codes are defined at the time of company approval by the Chief Operations

Officer (COO) working with the company representative or AS and based on the type of business at the Airport. This binder lists all the Companies at the Airport, and the clearance codes that can be assigned for a Company.

Card Technologies & Badge#- The Airport issues iClass Prox cards. The badge number (hot stamp) printed on the back of the badge by HID is programmed in C•CURE and used for access control. This number is entered in the C•CURE system, printed on the front of the badge and used by the access control system for opening /closing doors. The badge # changes every time the badge is issued including for renewal, lost, stolen or damaged scenarios.

Fingerprint Live Scan Systems – The Airport uses one (1) IDEMIA (4100XDFS- M95) to capture airport employee 10-prints for the Criminal History Records Checks (CHRC). The airport is satisfied with the performance of the IDEMIA finger printing machines and plans to extend the contract with IDMEIA as well as add a second fingerprint setup in the badging office as future expansion and integration with single unified IDMS badging workstation.

Designated Airport Channeling Service (DAC) – The Airport badging office enters all the new applicant’s biographic information in to the TSC system (via web portal login) for submission to the TSA for Security Threat Assessment and Livescan fingerprints to the FBI for the Criminal

History Records Checks (CHRC). The badging office daily monitors (some more than once a day) for changes or updates to the STA or CHRC. The CHRC results are reviewed in the FBI system.

The applicants are enrolled in the RapBack program.

The Airport currently does not fingerprint all SIDA badge holders (one Airline submits case file and

CHRC Results letter). However, the Airport is in the process of 100% fingerprinting and adjudication to be performed in the Airport badging office.

Financial Systems – The Airport currently uses a combination of monthly invoicing, escrow payments and Point of Sale (PoS) devices for credit / debit card transactions for badge related fees. The Airport is investigating the option to include the PoS devices to be installed in the badge office for collecting badge related fees.

Point-of-Sale (PoS) - Standalone Point of Sale devices in the finance department for processing credit / debit cards. The printed receipt from the PoS and the transaction # are documented. The paid receipt is printed in the Finance department and the applicant / badgeholder hand carries the receipt (proof of payment) to the Airport badging office.

Training Systems – The Airport implements manual and in-class setup for all training using DVD players. The applicants or badgeholders requiring training schedule with the badging office via email/ phones communications. The training courses included are SIDA, Movement and Non-

Movement. The operations (Driver) training is currently managed by the Airport Operations team with some tenant trainers. The Airport is planning to make modifications to the program where all training, review and (check-ins) approvals will be performed by the Airport Operations team. More details in the later sections.

Mass Notification – The Airport uses the Everbridge mass notification system for critical operational notifications to all the Airport employees. Currently, a file is exported from the CCURE system on a weekly basis. The badging office staff reviewed the file for quality and formatting then the file is uploaded into the Mass Notification system. The Airport would like to eliminate this manual step with the IDMS platform. The intent for the IDMS is to capture and push active cardholder contact information to the Everbridge and when the badge is inactivated then remove the employee from Everbridge system.

Badging Office & Training Room Layout

The ORF Airport Badging Office, located in the main terminal, is accessible to all Airport employees. The Airport Badging Office is configured with a waiting area in the vestibule/lobby.

The badging station is equipped with a total of 3 standalone computers performing various functions. There is one (1) workstation (CCURE 9000) for badge productions, one (1) ORF issued workstation for background checks entry and retrieval (TSC), other NAA applications (Outlook, etc.) and third standalone single workstation for fingerprinting (IDEMIA). The CCURE 9000 workstation is equipped with badging equipment – camera and badge printer.

Within the badging office is the Training room set up with four (4) stations that have monitors and

DVD player for security and driver trainings.

# BADGING EQUIPMENT QUANTITY

1 Camera 1

2 Badge Printer 1

3 Laminate – Custom or Standard 1

4 Standard Paper Printer 1

Existing User Roles and Business Process

This section documents user roles, the employee badge issuance workflow, the company financial setup, and the citation program.

User Roles

There are multiple users managing the various badging business processes at ORF. A list of the users and responsibilities is provided below.

# USER ROLE RESPONSIBILITIES

1 Authorized Signatory Fill paper forms, review and authorize new badge applications, authorization of renewals (badge), respond to badge audits and involved with citations hearings and coordinating trainings for applicants.

2 Applicant Coordinate with Authorized User to complete badge application process.

3 Trusted Agents / Badging Office Staff

Badge applicant data entry in various disparate systems, fingerprinting, document verification and scanning, badge production, payment collection, receipt generation, tracking RAP back enrollment and removal in DAC system, paper log for keys, ramp permits and badge holder paper records.

4 Badging Office - Admin Analyst Manage all tasks of Trusted Agents and management of keys, ramp permits, CHRC adjudication notifications, STA clearance, DAC provider contract maintenance, citations program, finance department coordination.

5 Badging Office - Supervisor Manage all tasks of Admin. Analyst II, review of CHRC Rap sheets and security check adjudication, coordinate hearings for CHRC appeals, manage review of, issuance, adjudication and interview process for citation and violations (in lieu of Airport Security Manager).

6 Airport Security Manager Manage the above tasks for Supervisor and be decision maker for citations and rap sheets adjudications, 7 Airport Operations Conduct practical movement area training and coordinate with Badging Office for appropriate driver endorsement on the applicant badge. Update citation information (see citation workflow).

Business Processes / Workflows

This section describes various workflow processes.

Company Setup

The company contacts the Chief Operating Officer and provides details of the business name, business purpose at the airport, contract details, areas of access and the designated Authorized Signatory for the company. The COO will review all the details and send a letter of approval with various details including badge types, privileges, etc. to the ID Office.

The Finance Department has categories for badge fee payment methods based on the type of the company. For example: Airlines will be billed monthly.

The letter of approval is sent to the company representative and the ID Office which is then filed for future reference.

Employee Badge Issuance

The new badge request is explained below. The applicant submits paper application, the financial payment form to finance and the badging office for payment, then the badging office performs identity

& document validation, fingerprinting and then again for required training and badge pickup.

[A] Paper Application: The Authorized Signatory and the applicant work together to fill the paper badge application. The Authorized Signatory based on the applicant’s job requirements requests the driving and unescorted/ escorted privileges.

[B] Badging Fees: The applicant submits financial payment form to finance and the badging office for payment and issues a receipt of payment.

[C] Badging Office Visit 1: The applicants take the paper application, i9 documents and the payment receipt to the badging office.

NOTE: Currently, the I9 verification documents are not scanned, or copies preserved with the paper application.

[D] Fingerprint Process: The Trusted Agent and the applicant complete the fingerprinting process.

Note: The applicant leaves the badging office after successfully completing the fingerprinting capture process.

[E] Back Office Process (DACS and CCURE):

The Trusted agent enters applicants’ biographic information in DACS. Then the same information is entered in the CCURE system. The CCURE system generates a badge # that is then entered in the DACS.

After that, the Trusted Agent initiates the STA, CHRC and subscribes to Rapback.

The Trusted Agent will monitor the DACS daily for times for changes / updates to the applicant’s STA, CHRC statuses. If there are any errors/ issues those are corrected by the Trusted Agent in DACS and security checks reprocessed.

[F]: Background Check Adjudication Process:

The Trusted agent confirms the STA is passed, then logs in to the FBI FPRD website to check the CHRC status. The Trusted agent will download and adjudicate the rap sheets and any other information available in the FBI FPRD system.

If the rap sheet has disqualifying crimes, then the Airport will notify via email (sent manually) to the

Authorized Signatory of failure of background checks and the badge will not be issued.

If the applicant has no disqualifying offenses, then the Trusted Agent notifies the Authorized Signatory that the applicant has cleared the background checks, and the applicant should visit the ID office to complete the mandatory SIDA Trainings and other driver trainings as required.

[G]: Training:

The Applicant visits the ID office to complete the required trainings. If driver training is required, then the Applicant and Authorized Signatory coordinate with the Operations team to complete the necessary drivers’ trainings. Once all training is completed, including the Operations approval (check-ins) then the

ID office will issue the badge.

[H]: Badge Issuance:

The applicant in the ID office will capture the applicant’s photo, set up the 4-digit PIN and print the badge.

[I]: Update DACS:

The Trusted Agent updates the badge expiration date in DACS.

Badge Audit

The Airport conducts 10% and 100% badge audits. The airport sends an email /letter to the authorized signatory asking them to fill and provide list of all active badges. Sample file attached in Appendix.

The Airport then reviews the completed audit spread sheet provided by the AS and reconciles the badge records manually against the CCURE report. If there is a discrepancy the airport informs the authorized signatory asking for an explanation.

The Airport conducts 100% badge audit annually in July and 10% in January every year. In addition, the

Airport conducts badge audit spot checks for select companies (company with over 50 badges) and inspect the badge physically and visually.

NORFOLK INTERNATIONAL AIRPORT (ORF) IDENTITY MANAGEMENT SYSTEM (IDMS)

ATTACHMENT B: FUTURE BUSINESS PROCESSES

1.0 Company Onboarding

The IDMS will provide capability for the ID badging office to enter and configure company prior to processing any badge applications. The high-level workflow shows the approvals that will be required prior to activating a company. Once the company is onboarded then the badge application for the first employee or designated Authorized Signatory can begin.

2.0 Badge Application Workflow – AS Badge application (Pre-Enrollment)

The AS will submit the application via the AS portal in this IDMS. The IDMS shall have capability for the applicant (via URL OR in the badging office) to respond to the Disqualifying Crimes questionnaire, Privacy Act, SSN wording and other airport specific cardholder responsibilities.

NEW APPLICANT ENROLLMENT Via AS PORTAL (Proposed)

A U

TH

O

R

IZ

ED

S

IG

N

A

TO

R Y

A P

PL

IC

A N

T

ID

M S

START

LOGIN TO

AUTHORIZED SIGNATORY (AS)

WEB PORTAL

ENTER APPLLICANT BIOGRAPHIC

INFORMATION -

NAME, ALIAS, ADDRESS, EMAIL AND PII,

SELECT BADGE TYPE AND REQUEST

BADGE PRIVILEGES.

BROWSE TO THE URL

EMAIL

NOTIFICATION TO

APPLICANT

EMAIL

INCLUDES URL

TO THE

APPLICANT

PORTAL

EMAIL NOTIFICATION TO

AS

REVIEW, ACKNOWLEDGE THE

AS CERTIFICATION .

EMAIL NOTIFICATION TO

1) Badging Office of…