Accessibility Information

Users of assistive technologies such as screen readers should use the following link to activate Accessibility Mode before continuing: Learn more and Activate accessibility mode.

D--Request for Information - Mobile Device Management

Please contact Hamilton Cunningham at hamilton.d.cunningham@us.army.mil for accompanying excel document.

Solicitation Number: W91WAWPMNES2
Agency: Department of the Army
Office: Army Contracting Command
Location: NCR-ACC - WAW
  • Print

Note:

There have been modifications to this notice. You are currently viewing the original synopsis. To view the most recent modification/amendment, click here
:
W91WAWPMNES2
:
Special Notice
:
Added: Oct 25, 2011 4:35 pm
Request for Information (RFI) for
Program Management
Network and Enterprise Services (PM NES)
Establishment of
Mobile Device Management Services




Army Contracting Command National Capitol Region
200 Stovall Street
Alexandria, Virginia 22331-1700












THIS REQUEST FOR INFORMATION (RFI) SUPPORTS THE ESTABLISHMENT OF A MOBILE DEVICE MANAGEMENT SYSTEM SERVICING THE DEPARTMENT OF DEFENSE TO FACILITATE ENTERPRISE MANAGEMENT OF MOBILE DEVICES.
Table of Contents
1.0 Background 4
2.0 Introduction 4
3.0 Vendor Instructions 5
4.0 Request for General Information 6
5.0 Objective 7
6.0 Request for Technical Information 9
7.0 Constraints 14
8.0 Transition and Transformation 15


1.0 Background

The use of commercial mobile devices (CMDs), such as devices and tablets, offers an unprecedented amount of opportunity for advanced mobile computing and communications within the Department of Defense (DoD). However, the importance of adapting to these newly emerging technologies while also adhering to existing security policies and requirements poses major challenges moving forward. In the realm of CMDs, it is widely known that most mobile operating systems (OS) lack the basic functionality necessary to meet minimum DoD security requirements for protecting personal, military, and enterprise data. Therefore, the need to augment existing systems with additional administrative components as part of a greater architecture becomes paramount to ensuring security and functionality across a variety of mobile device platforms.

Some of the hurdles include, but are not limited to, the securing, monitoring, and management of CMDs. In addition, the provisioning and updating of these devices at an enterprise-level poses great challenges as DoD moves towards wide proliferation of devices and tablets. Overall, the obstacles faced by the DoD community can be potentially mitigated by utilizing a mobile device management (MDM) system capable of providing a central administrative framework for tracking and monitoring CMDs as well as ensuring security policy compliance among end-point devices.

2.0 Introduction

This RFI is issued as a means of technical discovery and information gathering. Program Management Network and Enterprise Services (PM NES) seeks to (1) become familiar with the current state of the MDM market, specifically to validate available MDM features and capabilities in existence today, (2) identify those MDM companies which are exceeding the inherent supported baseline functionality of current device platforms and applying innovative approaches to providing a greater security and enterprise management model in their MDM platforms. PM NES seeks this information from industry, particularly from MDM vendors who specialize in the following types of mobile device management:

Software Distribution - The ability to manage and support mobile application use including deploy, install, update, delete or block.

Policy Management - Development, control and operations of DoD enterprise mobile access, connectivity, and security policy.

Inventory Management - Software, firmware, hardware, and peripheral device inventory management, this includes provisioning and support.

Security Management - The implementation and enforcement of DoD-level device security, authentication, validation and encryption functionality.

3.0 Vendor Instructions

DISCLAIMER
THE GOVERNMENT DOES NOT INTEND TO AWARD A CONTRACT ON THE BASIS OF THIS RFI OR OTHERWISE PAY FOR INFORMATION RECEIVED IN RESPONSE TO THE RFI.

This RFI is issued for information and planning purposes only and does not constitute a solicitation. All information received in response to the RFI that is marked Proprietary will be handled accordingly. The Government shall not be liable for or suffer any consequential damages for any proprietary information not properly identified. Proprietary information will be safeguarded in accordance with the applicable Government regulations. Responses to the RFI will not be returned nor will the Government confirm receipt of the RFI response. Whatever information is provided in response to this RFI will be used to assess tradeoffs and alternatives available for determining how to proceed in the acquisition process. In accordance with FAR 15.201(e), responses to this RFI are not offers and cannot be accepted by the Government to form a binding contract.

The anticipated North American Industry Classification System Code (NAICS) for this requirement is 541519 (size standard $25M).

Small businesses are strongly encouraged to provide responses to this RFI, in order to assist PM NES in determining the potential levels of interest, competition and technical capability to provide the required services within the Small Business community. In addition, this information will also be used to assist PM NES in establishing a basis for developing any subsequent potential subcontract plan small business goal percentages.

Submission Instructions

Responses should include the (1) business name and address; (2) name of company representative and their business title; (3) contract vehicles that would be available to the Government for the procurement of the product and service, to include General Service Administration (GSA) Federal Supply Schedules (FSS), or any other Government Agency contract vehicle.

The responses should be in a white paper format, no longer than fifty (50) pages in length. Responses to this RFI are due NLT Tuesday 8 November 2011 at 5:00 PM Eastern (EST). Contact POC's are Gregory Clark (Gregory.clark5@us.army.mil) and Hamilton Cunningham (hamilton.d.cunningham@us.army.mil).

Proprietary Statement

Proprietary information and trade secrets, if any, must be clearly marked on all materials. All information received that is marked Proprietary will be handled accordingly. Please be advised that all submissions become Government property and will not be returned. Responses will be reviewed by government personnel and PM NES PMSS support contractor personnel from SNVC, Inc. All government and contractor personnel reviewing RFI responses will have signed non-disclosure agreements and understand their responsibility for proper use and protection from unauthorized disclosure of proprietary information as described in 41 USC 423. The Government shall not be held liable for any damages incurred if proprietary information is not properly identified.


Contracting Office Address:
200 Stovall Street
Hoffman Building 1
10th Floor, Room 10S67
Alexandria, Virginia 22331-1700
United States
Place of Performance:
Non-U.S.
United States
Primary Point of Contact.:
Gregory Clark,
Contracting Officer
Gregory.clark5@us.army.mil
Phone: 703.325.6542

4.0 Request for General Information

1. Describe your organization. The term "mobile device management" can describe a wide range of products and services that enables organizations to deploy and support enterprise applications to mobile devices with various areas of functionality, such as security, provisioning, software and inventory management, and decommissioning. What types of MDM products and services do you provide?
2. Describe your organization's experience with and expertise in the MDM industry.
3. If possible, please describe client organizations/agencies within the DoD and federal government community who have either previously used or currently use your MDM product(s)/service(s). If not applicable, please describe any commercial companies who use your MDM product(s)/service(s). What was the size and scope of their mobile device deployments?
4. What is your current year-to-date (YTD) revenue in the MDM industry?
5. Please provide market penetration and level of financial funding to meet product improvement and marketing goals in the next 5 years.
6. Does your MDM solution have DoD Information Assurance Certification and Accreditation Process (DIACAP) accreditation, Certificate of Networthiness (CoN), Security Technical Implementation Guide (STIG), and/or equivalent qualifications which permit use of your product on the DoD network? Please list all relevant certifications.
7. Please describe a future roadmap for your organization as well as your MDM product. What features and/or capabilities to you plan to integrate in future versions of your product? Please provide a tentative timeline of capability milestones, if applicable.
8. What are your standard contract terms and conditions?
9. Please provide any additional information about your organization which you feel distinguishes you as a provider of, or authority on, MDM technology.

5.0 Objective

Ideally, the vendor should discuss how their solution addresses the following capabilities which are of interest to the U.S. Army and the Department of Defense:

Support for iOS 5.x, Android 2.x and 3.x, Blackberry 6.x and 7.x, and Windows Phone 7 (WP7) mobile device platforms
Support for Microsoft Exchange, Blackberry Enterprise Server, and Oracle Sun Java Unified Communication Suite messaging server platforms
Security and Policy/Compliance Enforcement
o Complex password enforcement (strong alphanumeric password)
o Remote device wipe (both selective and total)
o Remote device lock
o Device lock (after a given period of inactivity)
o Administrator/remote reset of device password
o CAC/PIV device authentication
o Administer policies as groups
o Administer policies as individuals
o Support complex group policies (multi-layered, hierarchical, etc.) and/or individual policies
o Disable infrared (IR) port
o Disable Wi-Fi radio
o Disable automatic connection to Wi-Fi networks
o Disable cellular radio
o Disable Bluetooth radio
o Bluetooth profile whitelist/blacklist by vendor
o Bluetooth profile whitelist/blacklist by peripheral type
o Disable camera(s)
o Disable microphone(s)
o Disable removable media port
o Disable USB/serial port (i.e. 30-pin dock connector, MicroUSB, MiniUSB, etc.)
o Support restrictive management of USB/serial access by vendor and/or peripheral type
o Disable screen capture
o Disable voice dialing
o Disable access to public app repositories (i.e. App Store, Android Market, etc.)
o Support granular restrictive access to specific public app repositories and/or specific applications on specific public app repositories
o Disable use of preinstalled browser
o Enforce URL and web content filtering
o Enable browser enforcement through DoD proxy
o Disable Location-based services (GPS)
o Disable SMS/MMS messaging
o Policy compliance reporting
o Query for compliance and security information
o Alert system for users and IT administrators when device policies are violated, which includes the ability to "kill" devices when they become noncompliant
o Force exclusive use of VPN for all IP traffic
o Enforce DoD Logon Banner or custom text to device lock
o FIPS 140-2 level 1data-at-rest encryption
o FIPS 140-2 level 1 data-in-transit encryption
o FIPS 140-2 level 1 encrypted certificate store on device
o Forced and/or optional FIPS 140-2 level 1 encryption of removable media
o Jailbreak/Root detection mechanism
o Device integrity monitoring
o Trusted boot sequence
o Remote device health monitoring
o Location-based policy enforcement
o Log device activity and message archiving and retrieval (incoming/outgoing calls, messages, data, etc.) natively on device
o Log device activity and message archiving and retrieval (incoming/outgoing calls, messages, data, etc.) from administrative server
o Restrict access to enterprise servers
Application Management
o Application blacklisting
o Application whitelisting
o Restrict/manage application "sideloading"
o Application management/deployment by security or policy groups/types
o Disable preinstalled applications
o Deny removal of applications
o Remotely push applications to device
o Remotely uninstall applications on device
o Quarantine protection for rogue applications
o Query for application information
o Server-side backup of application information installed on device
o Device backup of application information on removable media
o Application validation at download, installation, run-time, and device boot-up
Malware Control Management
o Antivirus and malware detection
o Spam protection
o Phishing protection
Email
o S/MIME capability
o Integrated calendaring
o DoD Global Address List (GAL) integration
o CAC/PIV encryption and signing integration
o Plain text only native email enforcement
VPN Management
o PKI-based authentication
o Disable Split Tunneling
o IPSec/SSL end-to-end encryption
o FIPS 140-2 data-in-transit encryption
Inventory/Asset Management
o Query support for device and network information
o Device activation and deactivation
o Device configuration and imaging
o Trouble ticket and tracking management
o Enforce mobile communication expense policies, such as disabling cellular data or access to servers when roaming internationally
Software Distribution
o Access to private application repository
o Push and/or pull over-the-air (OTA) software updates for applications and Operating Systems (OSes)
o Trusted controls for over-the-air (OTA) or tethered provisioning and updating process
o Backup/restore of configuration data
o Backup/restore of software
Administration and Reporting
o Business intelligence, analytics, and reporting tools
o Access to management server via single or web-based console Role-based access
o Group-based action management
o Enterprise platform integration (i.e. LDAP, Blackberry Enterprise Server, Good Mobile Messaging, certificate authority, trouble ticketing and help desk, such as Remedy)
o FIPS 140-2 level 1 encryption of administrative (MDM) communications
A Certificate of Networthiness (CoN)
Integration of hard and/or soft token user authentication, i.e. Common Access Card (CAC), microSD, near-field communication (NFC), etc.
Suite B certification of cryptographic modules for processing classified information up to Secret level
Integration of virtualized operating systems and/or hypervisor architecture for mobile devices
An MDM solution scalable to support all potential DoD users

6.0 Request for Technical Information

Please answer the following questions with as much detail as possible. Please note that some questions are to be interpreted simply as guidelines and can be used to include any additional information related to the topic which may differentiate or better explain your product's functionality.

MDM Platform

1. What is your company's technical approach to mobile device management? Do you take a lightweight approach where a mobile agent is installed on the device to call native APIs on the mobile platform or a heavyweight approach where client-side management software on the device can enforce policies beyond the native APIs, such as local data encryption and selective wipe?
2. What is the delivery model for your MDM platform? (i.e. on-premises, cloud, managed services, hybrid, etc.)
3. Describe your MDM network architecture. Graphics or diagrams are acceptable.
4. For securing data, does your MDM solution allow separation of personal and corporate content on the device? If so, how do you achieve and protect data separation? Is your separation based on virtualization technology (i.e. VMware MVP)? How and where are encryption keys and authentication data stored?
5. Can you host a private app repository using your MDM solution? If so, does your app repository support bundling and/or app-level access rules for specific user groups/types?
6. Does your MDM solution include an email component? If so, does it support S/MIME, calendaring, and/or Global Address List (GAL) lookup? What messaging server platforms does your MDM solution support? (i.e. Microsoft Exchange, Sun Java, etc.)
7. Describe your MDM solution's failover capabilities. For example, if your MDM server fails, does it revert elegantly to a backup?
8. Does your MDM solution provide database and server redundancy? Please describe.
9. List any dependencies on externally provided infrastructure, e.g. Apple Push Notification Service (APNS).
10. Do you have any hard and/or soft token(s) integrated with your MDM solution? If so, to what extent? Can you require hard/soft token authentication upon unlocking of the device?
11. Can your MDM solution integrate with an e-Policy Operator (ePO) or Host Based Security System (HBSS) to provide host-based intrusion detection?
12. Does your MDM solution integrate with virtualized OSes and/or hypervisor architecture on mobile devices?
13. Describe how your MDM solution would be configured to support the following user population sizes: (a) 25k users (b) 100k users (c) 250k users (d) 500k users (e) 1million users
14. For each population size listed in Question 12, provide the number of yearly man-hours and labor skills required to staff and maintain the system as an enterprise solution.
15. For each population size listed in Question 12, what is the time table for standing up a MDM solution? Estimated times should include user data provisioning and testing. Provide any assumptions made.

Device

16. What mobile OS platforms (specify by version number) do you support? Does your MDM solution provide equal functionalities across all supported mobile platforms? If not, what particular feature sets are not available on what particular mobile platforms? Please explain.
17. Are there limitations to what device manufacturers and/or carrier service providers your product supports as well? If so, please describe.
18. Can your MDM resident mobile application be removed or modified by the user? If this answer varies by OS or device, please specify for each major variant.
19. What are the possible detection and/or failure scenarios if your MDM application is corrupted by malware?
20. Can your MDM solution enforce major and minor releases of an approved software version (OS, MDM client, third-party application, etc.) installed on the device before granting the user access to it? Please explain.
21. What methods does your MDM solution implement to protect devices from malware and viruses? For example, does your MDM solution provide a device-level firewall, malware, and/or intrusion detection system (IDS) protections for the connection path between the infrastructure and/or MDM and the device? Please explain.
22. Can your MDM solution backup and restore configuration data and software on the device? Please explain.
23. Can your MDM solution monitor device status such as battery life, memory usage, and CPU? Please explain.

Security

24. To what extent can you determine if a user is complying with security policy? Is it real-time or periodic? Is the compliance performed on the backend and/or on the device? Does your MDM solution allow for both active and passive compliance and security checking? What types of alerts are available for the user and the administrator when policies have been violated? What are the available courses of action, both at an administrative and at a device level, when an alert is triggered?
25. Is the communication and data handling of your MDM solution FIPS 140-2 compliant and/or validated by NIST? Please describe the cryptographic modules used in your product to support data-at-rest, data-in-motion, and data-in-transit encryption.
26. Is the communication and data handling of your MDM solution Suite B compliant and/or validated by NSA? Please describe the cryptographic modules used in your product to support data-at-rest, data-in-motion, and data-in-transit encryption.
27. Does your MDM solution include a jailbreak/root detection mechanism? If so, please describe how it is implemented. Can it detect both tethered and OTA jailbreak methods? Is your detection mechanism proprietary or open-source? Can you prevent and/or detect manual override of this feature by the user?
28. To what extent can you enforce complex password configuration on the device? (i.e. number of characters, at least 2 complex characters, etc.) Can you prevent and/or detect manual override of this feature by the user?
29. Please describe your method(s) of triggering a remote wipe on a device. Do you leverage any native remote wipe capability of the device or use a proprietary method? Are you able to perform any form of selective remote wipe? If so, what types of data can be selectively wiped and by what method?
30. To what extent can you administratively control Wi-Fi? For example, can you blacklist/whitelist certain Wi-Fi networks? Can you disable the automatic connection of the device to a Wi-Fi network? Can you prevent and/or detect manual override of this feature by the user? Please explain.
31. To what extent can you administratively control cellular communication? For example, can you force devices to use 3G service over LTE? Can you impose carrier-based or location-based restrictions on service and/or roaming access? Can you prevent and/or detect manual override of this feature by the user? Please explain.
32. To what extent does your MDM solution manage VPN communication? Can you disable split tunneling? What method are you using to encrypt network communication from end-to-end? Can you prevent and/or detect manual override of this feature by the user?
33. To what extent can you administratively control the Bluetooth communication? For example, can you blacklist/whitelist connecting devices by vendor or peripheral type?
34. To what extent can you disable location-based services? Can you disable the location of your device either by GPS and/or cellular triangulation? Can you prevent and/or detect manual override of this feature by the user?
35. To what extent can you administrative control the camera(s)? Can you disable both the front and rear cameras independently of each other? Can you prevent and/or detect manual override of this feature by the user?
36. To what extent can you administrative control the removable media port? For example, can you restrict the port so that the device allows only the removable media inserted upon provisioning to communicate with it? Can you prevent and/or detect manual override of this feature by the user?
37. To what extent can you administrative control the USB/serial port? Can you restrict the port so that it can only be used for charging the device? Can you restrict the use of the port by vendor and/or peripheral type? Can you prevent and/or detect manual override of this feature by the user?
38. Can you disable screen capture? Can you prevent and/or detect manual override of this feature by the user?
39. Can you disable the ability to access speech recognition functionality on the device? If so, explain.
40. To what extent can you manage browser access to the web? Can you restrict the browser management of passwords/form history/search history/cookies? Can you force all web traffic through a DoD proxy? Can you prevent and/or detect manual override of this feature by the user?
41. Can you display a custom banner upon unlocking the device that states "I've read and consent to the terms of the IS agreement"?
42. Does your MDM solution perform some type of device health and/or integrity monitoring? If so, please describe.
43. Can your MDM solution provide intelligent reporting and trend analysis on security-related events to recognize unusual, and potentially malicious, patterns with devices within the enterprise? Please explain.

Application

44. What unique features does your MDM solution have to support application policy management?
45. Does your MDM solution have an application blacklisting/whitelisting capability?
46. To what extent can your MDM solution monitor the access, download, installation, and execution of applications?
47. Can your MDM solution disable some/all preinstalled applications that come with a commercial device?
48. Can your MDM solution prevent the user from removing installed applications? If so, to what extent? Can you prevent and/or detect manual override of this feature by the user?
49. Can your MDM solution restrict or manage the "sideloading" of applications to prevent unapproved installation of applications by removable media and/or USB connection?
50. Can your MDM solution place prohibited applications installed on the device in quarantine?
51. Can your MDM solution administratively push or uninstall applications on a device?
52. Can your MDM solution query a device for a list of installed and/or running applications?
53. In the event a user loses their device, does your MDM solution back up application information so that it can be restored on the user's next device?
54. Does your MDM solution validate the integrity of applications when they are downloaded, installed, executed, and displayed at device boot-up? Please explain.

Policy

55. Can your MDM solution create administrative policies based on user group? What about creating policies for multi-layered hierarchical user groups that require different levels of security and compliance? For example, an infantry group could set its own policies in addition to any policy that it inherits from the Army, which also inherits policies from the DoD. Consequently, setting policies of any group in the multi-tiered hierarchical path would have no effect on any group outside that path, nor could it allow a lower tier group to delete any higher level group set policies.
56. Can your MDM solution restrict lower tiered managers from changing/deleting policies enacted by higher level managers? Conversely, would it allow lower tiered managers the ability to enforce stricter policies than those enacted by higher level managers?
57. Can your MDM solution manage policies based on particular hardware model?
58. Can your MDM solution leverage location-based services to enforce compliance policies? For example, if a user worked in a Sensitive Compartmented Information Facility (SCIF), could your solution trigger the user's device to turn off all radios upon proximity of the building? Please explain.
59. To what extent can you restrict access to network resources? Can you establish group/individual privileges to specific network resources?
60. To what extent can you restrict access to public app repositories?
61. How does your MDM solution handle software updates for applications and the OS?
62. Can you enforce mobile communication expense policies using your MDM solution?
63. Does your MDM solution have a component for managing device inventory? Please describe in detail how your MDM solution solves this issue.
64. Can your MDM solution provide designated alerts to another enterprise network management application using SNMPv3 or SNMPv2 with IPSec tunnel?
65. Can your MDM solution create acceptable use policies for using an enterprise device for personal use?
66. Can your MDM solution create different policies for employee-owned devices and company-owned devices?

Service

67. Can your MDM solution allow for multi-tiered helpdesk support? For example, an Army civilian would get helpdesk support from the Army but it is the same application supporting all of the various helpdesks. Additionally, the Army helpdesk profile would allow them to only view Army devices and not the other Services, but the OSD level profile would have access to all helpdesk information.
68. Can your MDM solution provide centralized administration and a single management repository for all devices managed by the enterprise but provide multi-tier management/role capability (managing hierarchal groups) in accessing mobile device information and setting policies?
69. What type of reporting and business intelligence (BI) tools do you offer with your MDM product? Please provide a description of what kinds of device status reports can be produced using your tools? Are they comprised of both text and statistical graphics? Are they canned reports or can they be customized by the client?
70. Can your MDM solution provide helpdesk functionality troubleshooting tools, report generation, historical analysis, and problem triage?
71. Can your MDM solution provide reports and trend analysis on mobile service usage to view calls made/received, data download/upload usage, SMS usage, application downloads, toll calls, overages, inactive phones, and roaming charges?
72. Can your MDM solution provide device monitoring, alarms, error logs, inventory tracking, and customizable reports?
73. Can your MDM solution retrieve asset-tracking information such as serial number and asset tags?
74. Can your MDM solution provide users the ability to perform self-service configuration for capabilities such as device procurement, device registration, service activation, application download/configuration, locate device, lock/wipe device, and user-contact information changes?
75. Can your MDM solution support over-the-air (OTA) provisioning to which OS and version type devices?
76. Can your MDM solution create configuration profiles (sometimes referred to as templates) that simplify the process of provisioning based on vendor, operating system, or model type?
77. Can your MDM solution provide an audit trail capability? Many enterprises must comply with government regulations (e.g., Payment Card Industry Data Security Standard [PCI-DSS] and Health Insurance Portability and Accountability Act [HIPAA]) and must demonstrate their compliance with these regulations. Some MDM systems provide the ability to produce a provisioning audit trail and a resultant compliance report that can assist enterprises with their regulatory compliance-reporting obligations. Please describe in detail.
7.0 Constraints
The following constraints should be identified and mitigation processes defined in industry responses.

Compliance with Army security policies, guidelines and architectures including Top Level Architecture (TLA), Information Assurance Vulnerability Alert (IAVA) reporting, monitoring, etc.
DIACAP Authority to Operate (ATO)
Certificate to Operation (CTO)
Certificate of Networthiness (CON)
Army Interoperability Certification (AIC)
IPv6 Transition Preparation
Clinger-Cohen Act (CCA) Compliance
Information Assurance Strategy (AIS) - Required for CCA compliance and the others
Global Information Grid Bandwidth Expansion (GIG BE) connectivity
Continuity of Operations (COOP) and Disaster Recovery (DR)
Army Environmental/Facilities requirements (if applicable), specifically:
o Infrastructure
o Physical Security
o Survivability
o Time lines
o Required footprint/floor space
o Approvals and Ownership
8.0 Transition and Transformation
In any organization, change is always challenging. It is the Army's intent to transition and transform the user community to the MDM as transparently, seamlessly, and expeditiously as possible. As such, it is requested that industry address the following additional items in their response to this RFI.
A successful mitigation plan for past transitions in the commercial or Federal marketplace.
Any capabilities that exist for users to perform a "Self-Service" migration
Any issues and mitigation techniques related to migrating devices into the new Enterprise solution.
Levels of service currently being provided in the commercial or Federal marketplace and their key performance parameters
Strategies for identifying and resolving recurring and systemic problems with the MDM system
Current methodology for providing Tier 2/Tier 3 level support services
An expected "start up" period of time in calendar days, from date of award through service provision, including installation, Information Assurance (IA) accreditations and certifications.
How would the transition of data to a new service provider (commercial or government) at the end of the contract be performed?
:
Contracting Center of Excellence (NCR-CC), 200 Stovall Street, 11TH Floor, Alexandria, VA 22331-1700
:
Hamilton D. Cunningham, 703.325.1987

Contracting Center of Excellence (NCR-CC)