SERVICE STC
SPECIAL TERMS AND CONDITIONS FOR SYSTEM INTEGRATION SERVICETO IMPLEMENTIoT SENSOR-BASEDMONITORING OF RURAL WATER SUPPLY SYSTEMS

A. All Hiring of System Integration (SI) serviceto implementSensor Based monitoring of Rural Water Supply Systems related contracts placed through GeM shall be governed by the following set of Terms and Conditions:

I. General terms and conditions for Goods and Services (“GTC”).

II. Service specific terms and conditions (“STC”) contained in this document.

III. BID / Reverse Auction specific Additional Terms and Conditions (“ATC”) as specified by the Buyer

B. The above terms and conditions are in reverse order of precedence i.e. ATC shall supersede Service specific STC which shall supersede GTC, whenever there are any conflicting provisions. 

C. This document represents the Special Terms and Conditions (“STC”) and the Service Level Agreement (SLA) governing the contract between the Buyer and Service Provider. The purpose of this document is to outline the scope of work, stakeholders’ obligations and terms and conditions of all services covered as mutually understood by the stakeholders.

1. Objectives and Goal

The objective of this document is to ensure that all the special terms and conditions are in place to ensure consistent delivery of services to the Buyer by the Service Provider. The goal of this document is to:

⦁ Provide clear reference to service ownership, accountability, roles and responsibilities of both parties

⦁ Present a clear, concise and measurable description of services offered to the Buyer

⦁ Establish terms and conditions for all the involved stakeholders, it also includes the actions to be taken in case of failure to comply with conditions specified

⦁ To ensure that both the parties understand the consequences in case of termination of services due to any of the stated reasons
This document will act as a reference document that both the parties have understood the above-mentioned terms and conditions and have agreed to comply by the same. 

2. Stakeholders

The main stakeholders associated are:

1. Buyer: The Buyer is responsible to provide clear instructions, approvals and timely payments for the services availed as per the contractual terms

2. Service Provider: The Service Provider is responsible to provide all the required services to the satisfaction of Buyer in timely manner. The Service Provider may also include seller, supplier/bidder/contractor, any authorized agents, permitted assignees, successors, and nominees as per the context and as described in the document
The responsibilities and obligations of the stakeholders have been outlined in this document. The document also encompasses payment terms and deduction in case of non-adherence to the defined terms and conditions. 

4. Service Scope

The scope of System Integrator/Service Provider (SI) would be to implement the IoT sensor- based monitoring of rural water supplysystem covering supply, installation, testing, commissioning and operation and maintenance. The following activities will be included in scope of work of system integrator ; 

i. Survey, design and formulation of Detailed Project Report (DPR) - In consultation with the tenderer/ Engineer-in-charge, conduct a detailed survey of the existing water supply system in each village/ rural water supply scheme in the specified geographies to collect the details viz; site conditions, location and size of existing infrastructure like filtration plants/ service reservoirs/ supply lines, and the details of the newly proposed infrastructure shall be taken from the approved Detailed Project Reports prepared/ under execution of each village. The DPR should cover an as-is assessment analysis of power availability, feasible network connectivity, size & type of the device to be provided along with the type of power set up and communication system feasible to be provided, location of gateway, number and location of repeaters.

ii. Supply and installation of sensors, network devices and any other related hardware - For each scheme/village, the devices and sensors will be supplied according to technical specifications specified by the Buyer, network architecture and the prescribed data format for output (including frequency of data transmission). Supply, laying & termination of instrumentation, control, power & any other special cables as required for entire system are under SI scope. Factory acceptance test and calibration is in scope of the SI. 
iii. Operation and Maintenance – The SI is responsible for end-to-end O&M support of the system for Buyer specified number of years from the date of go-live. During O&M, SI shall keep necessary spares of all sensors and devices and be responsible for repair, replacement, maintenance etc. to meet the specified SLAs.

 iv. Design and go-live of MIS dashboard– If required by the Buyer, SI shall develop an integrated dashboard for reporting monitoring data collected by the sensor-based system, real-time status of all devices and any other metrics as per specifications provided in detailed scope of work. 

v. Setting up of Command-and-Control Centre –  If required by the Buyer, the SI shall set up a war-room like environment for centralized visualization, monitoring and review of Key Performance Indicators.

5. Terms and Conditions

5.1 Buyer’s Obligations

i. The Buyer shall nominate a nodal officer to coordinate with the SI to facilitate approvals, sharing of data etc. The nodal officer shall facilitate clearances and approvals that may be required by the SI (e.g., right of way, location for placement of gateway device, power connection on). The Buyer shall provide district wise approximate number of water supply and any other details such as maps that maybe available. 

ii. The Buyer shall accompany SI during site visits to develop solution design and provide necessary on-field support to enable installation, testing, commissioning,  conduct periodic inspection and certification related activities. 

iii. The Buyer shall provide timely administrative approvals for DPR and related project reports so that SI may carry out implementation as per specified timelines. 

iv. The Buyer shall facilitate tripartite agreement, if needed, between the District/Block, the SI, and the GPs in the cluster of villages (block/district) – which may clearly include responsibility for GPs (e.g., ensure prevention on of any vandalism/theft, providing power supply and location for gateway at GP office or pump cabin/elevated surface reservoir from existing power connection or apply for new power connection, etc. 

v. Any documentation/guidelines with respect to the scope of the project and necessary work permits to access buyers’ premises are to be provided by buyer. The Buyer agrees shall provide (or cause others to so provide) Information, resources and assistance (including access to records, systems, premises and people) that the Service Provider required to perform the services.

vi. The Buyer shall notify the Service Provider of any dishonest, wrongful or negligent acts or omissions of the Service Provider ’s employees or agents in connection with the Services as soon as possible after the Buyer becomes aware of them.

5.2 Service Provider’s Obligations

Survey, design and formulation of Detailed Project Report (DPR)

i.    The survey shall be conducted in coordination/ the supervision of the Engineer-In-Charge (JE/AEE) of the area concerned.  

ii.  The solution design proposed in the DPR must be as per guidelines provided in the ii. Expert Technical Committee Report of Na tional Jal Jeevan Mission and any other guidelines  issued by National Jal Jeevan Mission from time to time.

iii.  The solution should be modular, open, and inter-operable.

iv.   Infrastructure and application design should incorporate high availability, fault tolerance at all levels. 

v.  IoT technology as developed should be in a technology-neutral manner so as to avoid captivity to a specific product or implementation method.

vi.  IoT sensors are suitably designed and developed so as to be future proof, not requiring frequent revisions with the advent of every new technology.

vii.  Open Standards should be adopted in the design and implementation of all IoTwater sensor implementation. Legacy systems are incentivized to migrate to open standards, where required.

viii. IT Infrastructure for IoT water sensors should be shared to ensure optimal utilization and effective maintenance.

ix. The information systems along with the applications for IoT water sensors and services should be made available 24 x 7.

x. IoT devices should have ETL layer in-built to translate or convert the sensor data into meaningful information as per the standards prescribed and provide the same to the designated IP directly.

xi. The communications to cloud/servers can be done via several IoT compatible and specialized protocols (e.g., MQTT, AMQP, HTTPs, CoAP). Device connectors and device agents should use standard transport layer security (TLS) or Datagram transport layer security (DTLS) protocols for network security. Device management should be based on LWM2M protocol which in turn uses DTLS for network security and device connector libraries should use SSL/TLS connections to make calls to services such as ‘Sensor Services’

xii. It shall be the sole responsibility of the SI to clear any observations/ clarifications sought/ modifications suggested to the DPR or the System design before it is approved by the Competent Authority of the Buyer Department/Organization.

xiii. No supply or installation or any other activity shall be undertaken before the administrative approval of the DPR is accorded by the Competent Authority of the Buyer Department/Organization.

Supply, testing and installation of sensors, network devices and any other related hardware

xiv. Provision of any other instrumentation and control equipment not specifically mentioned in this document but required for trouble free and safe operation of the system, is also covered in scope. SI shall supply, install, test, and commission the entire solution including sensors and other devices on the field. 

xv. Prior to factory acceptance test, all the equipment shall be fully assembled, wired, and properly connected & tested to establish all the specified features & functional requirements of the systems. During functional acceptance test, functional integrity of the system hardware and software shall be tested & demonstrated.  All the necessary simulation kits as may be required for testing of software shall be arranged by the SI. The factory acceptance tests shall include visual and mechanical testing to establish correctness, completeness, good workmanship, and functional testing. It shall also include data payload testing by sending test data from device simulations to the central servers.  

xvi. All the sub-systems shall be interconnected to simulate, as close as possible, the total integrated system. Each test carried out shall be documented. Simulators shall be used for simulating field inputs. Any deficiency or problem faced shall be clearly brought-out and corrected.

xvii. The solution components shall be shipped to site only after successful completion of factory acceptance test and receipt of dispatch clearance from Buyer. 

xviii. At site, the system shall be properly installed taking care of manufacturer's recommendation. A log of all failed/ mal-operating components/ modules in sub-systems shall be maintained with description of the affected components/ modules, cause of failure, effect of failure on the sub-system and number of hours of operation before it failed. This will start from the date of power on of the system for cold commissioning. 

xix. The SI is required to calibrate all the sensors and other devices and ensure that the reading as is being reported in the central database of the Buyer is accurate. 

xx. For each sensor, the SI is required to measure the actual reading using conventional methods and match it against the reading reported in central database. 

xxi. Both factory acceptance and system acceptance test must be performed in the presence of an authorized representative of the Buyer who will oversee the integrity of the test and sign the system generated certificate as defined above. 
Each device must be certified in this manner before dispatch and on-site before commissioning. 

xxii. Standard measuring devices are to be used for calibration. These devices must be marked by Indian standards like ISI, BIS etc. or calibration certificates for test instruments shall be produced from a NABL Accredited laboratory.

xxiii. In case the desired range for RTUs, Repeaters, and Gateway is not achieved and a need for additional Repeaters/ Gateways, the SIshall provide the same at no additional cost to the Buyer.  

xxiv. Inspection and certification by Buyer’s representative does not free the SI from any of his obligation to ensure quality of material supplied and overall functioning of the system. 

xxv. SI shall ensure that installation is done in best possible manner to maximize the functional life of the sensors, ease operation & maintenance and avoid any disruption including but not limited to water leakage, pipe burst, water contamination, etc.

xxvi. The SI must deploy sufficientnumber of team members to execute the work simultaneously/ parallel necessary number of locations as specified by the Buyer so that specified timelines are met.

xxvii. The SI is also responsible for any civil work including but not limited to digging and creating lockable protective chambers. The SIshall be responsible to place appropriate locks for the safety and security of sensors and other devices.The SI shall geo-tag all the sensors and other devices installed. The SI shall share all the geo-locations along the images in the prescribed format with the Buyer.

xxviii. During the un-installation and re-installation period the water disruption to the community should be minimized. 

xxix. The prices quoted by the SI shall be inclusive of license software required for actual running of solution including the gateway (e.g., codebase for RTUs, devices, gateway, router etc.). While passing on the rights (license) of using any software/software tool by the SI to the Buyer, the SI shall ensure that such rights are inclusive of the use of that software for development in addition to deployment.

xxx. All entities which are offering/providing the M2M services based on SIM/ LAN shall register as M2MSP and entities which use WPAN/WLAN technologies for providing M2M connectivity, operating in unlicensed spectrum, shall register as WPAN/WLAN Connectivity Providers.

xxxi. All Annual Maintenance Contracts, licenses, ownership, etc. of assets (hardware or software) should be in the name of Buyer. 

xxxii. All Hardware, Software, Applications, Database, Utility, Tools (as applicable) along with applicable licenses for implementing the solution shall have sufficient support engineer for supporting Hardware/Software related issues. Support shall be backed by End-to-End Back-End Support Agreement with the respective OEM, as applicable.

xxxiii. The materials/equipment supplied under this Contract will conform to the Standards mentioned in the Technical specifications, and, when no applicable standard is mentioned, the appropriate Authoritative standards applicableto the Materials / equipment, shall be applicable in such cases. All material will be of the best class and will be capable of satisfactory operation under tropical conditions without distortion or deterioration.

xxxiv. Manufacturers/ Vendors of all the hardware/ software elements should have maintenance and support facilities in India. The Service Provider has to provide documentary evidence for the maintenance and support facilities and personnel along with the contact address for the same.

xxxv. Any material, to be used for design work, should be light weight, fire-retardant, easy to carry and adjustable according to the space available.

xxxvi. In case of electrical installations undertaken by Service Provider, all the electrical cables and wires shall be properly insulated. There shall not be any loose wires. 

xxxvii. While testing use error code 99 to send data to state/ central servers. Once the reading on sensors/ devices is matched against the physical reading and/ observation using a standard measuring device, the physical reading data must be updated on the portal created by central government. If the payload sent via device matches with the physical reading data updated on the portal manually, a certificate will be issued automatically for each device. If it doesn’t match, a detailed error report will be generated. The entire test for that device will have to be repeated post correcting the issue.

xxxviii. External sensors should have enclosures with lightning and surge protection.

INSURANCE

xxxix. The SI shall, without limiting its or the Buyer’s obligations and responsibilities, insure: 
i. The work together with material and system for incorporation therein, to the fullreplacement cost (term "cost" in this context shall include profit).  

ii. The SI’s equipment and other things brought onto site, for a sum sufficient to provide for their replacement at the site.  

iii. Insurance of both equipment and personnel shall be in the name of the Buyer atthe cost of the SIand the SI shall cover the Buyer against all losses or damagesfrom whatsoever cause arising from the start of the O&M until the date of completion of O&M in respect of the facility or any section or part thereof as the case may be. 

iv. Any amount not insured or not recovered from the insurer shall be borne by the SI.

v. Above insurance need not necessarily cover physical damage (excluding those caused by the SI and its personnel) and theft post commissioning of the project (during the O&M phase). In such cases: 

a. Buyer will be responsible for procuring and providing the sensors and other devices to be replaced. The SI can be asked to supply such sensors and the other devices, at the sole discretion of the Buyer, at the same rate asquoted in response to this RFP.

 b. The SI will be responsible for installing the new sensors and other devices as part of O&M responsibilities at no additional cost to the client.

DELIVERABLES 

The following reports shall need to be submitted by SI

a. Survey report, System design and Detailed Project Report. 
b. Solution design specifications (SDS) with village/ scheme wise variations highlighted (if any). 
c. Architecture deployed with village/ scheme wise variations highlighted (if any) 
d. Integration plan with central server and database Integration test cases & results. Security audit clearance certificate 
e. Complete source code including but not limited to codebase of sensors and other devices as applicable (e.g., for gateway) 
f. Testing documentation (including details of defects/bugs/errors and their resolution) . Installation guide 
g. Training manuals 
h. O&M SOPs e.g., battery change, periodic maintenance, repair, replacement, calibration etc.  
i. Geo-tagged locations and images of all sensors and other devices

PROTECTION, HADNLING AND STORAGE OF DATA 

a. Definition of data asset - Data is an asset that has a specific and measurable value to the Government and is managed accordingly
b. Data from IoT device should be directly flow to Government Cloud and should not travel via any other external medium or third-party server
c. Any Cloud Service Provider (“CSP”)whose services will be utilized by the Service Provider under the project, must be empanelled with MeitY and the CSP must be compliant with all the guidelines thereof issued by MeitY from time to time.
d. Archive and preserve all information exchanged (both in raw and aggregated form), for future reference and if needed, for resolution of disputes. The Archival and preservation must be in accordance with the applicable requirements prescribed.
e. Data from IoT water sensors will be shared across the Government and various offices, subject to rights and privileges, so as to prevent creation and maintenance of duplicative sets of data by different agencies. Data sharing shall be subject to conformance with the principles of security & privacy.
f. Data availability to concerned users at the required time should be assured. Each dataset has a trustee accountable for data quality and security.
g. Data is protected from loss, unauthorized use and corruption, through adoption of international standards and best practices, duly protecting the privacy of personal data and confidentiality of sensitive data.
h. Security has to be built into all stages and all aspects of architecture development. Security concerns extend to all the IT activities of the enterprise, including anti-spoofing measures to be adopted wherever required
i. Data has to be shared in encrypted format only. Encryption should be done on data at Rest and Transit.
j. Device Hardening, Asset Management, Configuration Assurance, Digital Certificates for securing Device Identity should be undertaken
k. Network Segmentation should be undertaken. 
l. Appropriate security controls should be put in place, where the field network, IT network and control network converge or interface with each other. In case of a security incident/compromise, the affected network should be isolated from the overall architecture.
Weak Cipher Suites and Encryption protocols should not be used anywhere in the setup.
m. Role Based Access Control should be adopted for access to the infra, application, service, database and other resources.
n. Multi-Factor Authentication should be used.Principle of least privilege access should be adopted.
o. Administrative Access/ Control should be distributed, and any changes/action executed by Administrators and other users should be logged.
p. Firewall, IDS/IPS, Log Analysis and other threat detection and mitigation controls should be used for overall threat visibility.
q. Periodic Audit and Risk Assessment should be done to assess the overall security posture of the setup

EXIT MANAGEMENT

 xli. Exit Management plan shall be furnished within time period specified by Buyer. The plan will need to be approved by the Buyer. The plan should consist of provisions of providing training to the Buyer personnel to take over the responsibilities of SI.

MANPOWER DEPLOYMENT 

xlii. Service provider will ensure adequate deployment of manpower to meet project timelines and nominate a senior-level representative to report project progress and overall coordination. 
xliii. If required by the Buyer, the Service Provider shall provide suitable documentary proof for the qualifications and experience of the personnel deployed by them. The biodata, qualification, and experience of personnel deployed with Buyer should be certified by the Service Provider for subsequent verification by the buyer on case-to-case basis.

CLOUD HOSTING (Only if included in Scope of Work by Buyer)

i. Develop, deploy, and maintain a cloud hosted centralised IoT platform to ingest telemetry data from on-field devices and gateways (direct from device). 
ii. Define a scalable solution architecture and deploy and maintain key cloud services successfully running IoT service (device to cloud telemetry and cloud to device commands) and an IoT-enabled analytical engine – including ingestion, storage, compute, and IoT services such as device management, bulk device provisioning, security, data processing, analytics etc.
iii. Define data standards (e.g., data payload format) for each type of sensor so that data from every village in the State is consistent and compliant with Cloud requirements
iv. Define standardised and scalable data formats across multiple secure protocols for IoT networking such as MQTT, AMQP, CoAP, HTTPs etc. to support edge devices as well as constrained environments 
v. Develop a framework to ensure data formats are extensible for new sensors to be added over time and supports variations across States 
vi. Develop a self-service based seamless registration, review, and approval of devices to enable a plug-n-play deployment on ground 
vii. The Service Provider shall be responsible for deploying the entire Solution on MEITY empaneled CSP. 
viii. The Service Provider should architect solution as Cloud Native based on services of CSP
ix. Service Provider shall assess the infrastructure requirements (including OS Instances, Storage, Networking, Security etc.) for hosting and maintaining all required applications/services. 
x. The Service Provider should ensure that all peripherals, accessories, sub-components required for the functionality and completeness of the solution, including software, licenses, tools, etc. should also be provisioned according to the requirements of the solution. 

Specifications for Cloud

⦁ The CSP should be empaneled with the Ministry of Electronics & Information and Technology, Government of India. 
⦁ Solution should have database as a service. The DBaaS should have native high availability (Active - Active) and scalability certified by DBMS OEM. Service provider also need to demonstrate the high availability (Active - Active) feature on cloud and the same should be achieved during demo. 
⦁ Solution should offer self-provisioning features (for VMs of different configurations, Storage, etc.). It should provide options to configure flexible shapes where one can get option to select vCPU/Core, Memory (RAM) independently for intel, AMD & ARM processors. CSP should be able to be provided latest processors of Intel, AMD, ARM. 
⦁ Solution should provide a robust, fault tolerant infrastructure with enterprise grade SLAs with an assurance of uptime of 99.9%. 
⦁ Cloud of the CSP / Service provider should be available on pay as per usage model and Fixed-Billing model and should be sized by CSP / Service provider basis the Guiding principles of IT infrastructure design section (On-Demand vs Fixed Billing). However, from Buyer perspective, the billing would be done periodically irrespective of Fixed/On-Demand model with the CSP.
⦁ The Service Provider shall not delete any data at the end of the agreement (for a maximum of 90 days beyond the expiry of the Agreement) without the express and written approval of the Buyer.

Compute

⦁ The service must be an end-to-end fully managed platform with built-in infrastructure maintenance, security patching & scaling along with the ability to Auto-Scale (Horizontal) on demand. The service should support automatically launching or terminating instances based on parameters such as CPU utilization or other factors basis the demand. The solution should also be able to do continuous monitoring and optimization of auto-scaling rules and limits.
⦁ The Service Provider must ensure that the services that are deployed are required in cluster and/or load-balancing mode, shall be deployed in such a manner that the load sharing/failover is across the instances and NOT amongst partitions of the same OS instance. In case of a hardware or software component failure in one partition, other partitions must not be shut down or rebooted.

Hosting Platform

⦁ Web hosting platform must have security, load balancing, autoscaling, and automated management.
⦁ Have support for continuous deployment from DevOps, GitHub, Docker Hub, and other sources, package management, staging environments, custom domain, and TLS/SSL certificates as well as ASP.NET, ASP.NET Core, Java, Ruby, Node.js, PHP, or Python
⦁ Managed production environment - Automatic OS & patch management and language frameworks. Must promote updates through test and staging environments. Should also support management of apps using cross-platform command-line interface (CLI).
⦁ It must be capable of scale up or out manually or automatically with an uptime of 99.95 %.
⦁ Platform must support for RESTful API scenarios, and simplify mobile app scenarios by enabling authentication, offline data sync, push notifications, and more.

Block and Object storage

⦁ Storage should be able to service multiple petabytes of information while sustaining hundreds of gigabits of throughput
⦁ There should be facility to define permissions on directories or individual files and should support ACL and permissions
⦁ Cloud compute service should support local storage for transient block storage requirements.
⦁ Processing should be executed at near-constant per-request latencies.
⦁ Offer secure, durable, highly scalable object storage for storing and retrieving any amount of data on demand. The place where the objects would be stored should be configurable and all objects should stay in India.
⦁ The service provider should be able to provide audit logs on object storage buckets/ container which should include details about access request and error code.

Networking

⦁ Cloud service must be able to support multiple (FQDN and IP Address) network options. Cloud service should be able to support dedicated IP addresses per instance.
⦁ Support IP addresses associated with a customer account, not a particular instance. The IP address should remain associated with the account until released explicitly.
⦁ Cloud service should support multiple routing mechanism including round-robin, failover, sticky session etc.
⦁ Cloud service must support a front-end load balancer that takes requests from clients over the Internet and distributes them across the instances that are registered with the load balancer. Cloud service should support an internal load balancer that routes traffic to instances within private subnets.
⦁ The Cloud Services  should have the following service available
⦁ IPv4,IPv6
⦁ DHCP
⦁ IPSec VPN Tunnel Creation
⦁ SSL VPN
⦁ Geo load Balancer (Balancing between multiple sites).
⦁ Load Balancer.
At least L3,4 Anti-DDoS solution

Backup

⦁ Offer a service with ability to take regular and scheduled backup. Service Provider shall provision cloud native solution as backup software.
⦁ The Service Provider should configure, schedule and manage backups of all the data including but not limited to files, folders, images, system state, databases and enterprise applications
⦁ An Initial Full Backup
⦁ Daily Incremental with 7 days retention
⦁ Weekly full with 30 days retention
⦁ Monthly Full with 30 days & 12 months retention on storage
⦁ Yearly Full with 30 days and 7 Years retention on storage
⦁ Different Tiers of Backup storage should be chosen depending upon the reads/restore that would be required

Disaster Recovery

⦁ In addition to the Primary DC, the service provider is responsible for Disaster Recovery Services to ensure continuity of operations in the event of failure of the primary data center and meet the RPO and RTO requirements. RPO should be <=15 minutes for application and RTO shall be <=1 hr. The key transaction data shall have an RPO of 15 minutes.
However, during the change from DC to DRC or vice- versa (regular planned changes), there should not be any data loss. There shall be asynchronous replication of data between Primary DC and DRDC and the service provider will be responsible for sizing and providing the DC-DR replication link to meet the RTO and the RPO requirements.
⦁ The DRC can only be offered from the same cloud solution provider from a traditional Data Center Facility and all the relevant mandatory requirements defined for the Primary Data Center as indicated below apply for the Disaster Recovery Center
⦁ Deployment Model Specific Requirements General Requirements
⦁ Service Level Agreement Management Operational Management
⦁ Data Management
⦁ User/Admin Portal Requirements
⦁ Integration Requirements
⦁ LAN / WAN Requirements
⦁ Data Center Facilities Requirements
⦁ Security Requirements
⦁ Legal Compliance Requirements
⦁ Management Reporting Requirements
⦁ Exit Management and Transition Requirements
⦁ In case of any disaster, the security posture of the DR site shall be identical to the posture provided in the DC.
⦁ The disaster recovery site shall have a similar environment (physical & IT), processes, and controls (security, etc.) as that of the primary DC. During normal operations, the Primary Data Center has been serving the requests or follows a multi-availability zone architecture. The Disaster Recovery Site has not been performing any work but has been remained on standby unless following active-active mode in a multi-availability zone architecture. During this period, the computing environment for the application in DR shall be available but with minimum possible compute resources required for a functional DR as per the solution offered or follows an active-active architecture across multi-availability zone. The application environment shall be installed and ready for use. DR Database Storage shall be replicated on an ongoing basis and shall be available in full (100% of the PDC) as per the designed RTO/RPO and replication strategy. The storage should be 100% of the capacity of the Primary Data Center site.

Security in Cloud

Cloud solution to offer assurances of effective physical and logical security controls through the third-party certifications (e.g., ISO 27001, ISO 27701, ISO 27017, ISO 27018) and provide a host of security services (e.g., encryption, web application firewall). It is the responsibility of the service provider to define the security architecture and implement the security services. Service Provider should implement the following security services to meet the desired security objectives concerning visibility, auditability, controllability, and agility.

a. Strong encryption capabilities for data in transit or at rest. 
b. Firewalls – instance and subnet levels. 
c. Identity and Access Management (IAM): Control users' access to cloud services. Create and manage users and groups, and grant or deny access. 
d. Managed Threat Detection: Managed threat detection service that provides you with a more accurate and easy way to continuously monitor and protect your cloud accounts and workloads. 
e. Managed DDoS Protection: Managed Distributed Denial of Service (DDoS) protection service that safeguards web applications running on cloud.
f. Web Application Firewall: Helps protect your web applications from common web exploits that could affect application availability, compromise security, or consume excessive resources.
g. Key Management Service (KMS): Managed service that makes it easy for you to create and control the encryption keys used to encrypt your data. 
h. Certificate Manager: Easily provision, manage, and deploy Secure Sockets Layer/Transport Layer Security (SSL/TLS) certificates.
i. Cloud HSM: Meet regulatory compliance requirements for data security by using dedicated Hardware Security Module (HSM) appliances within the Cloud. 
j. Inspector: Automated security assessment service that helps improve the security and compliance of applications deployed on Cloud. 
k. Organizations: Policy-based management for multiple customer accounts. With Organizations, you can create groups of accounts and then apply policies to those groups.
l. Cloud dashboards: Collect and track metrics, collect and monitor log files, and set alarms to gain system-wide visibility into resource utilisation, application performance, and operational health, using these insights to react intelligently and keep applications running smoothly.
m. Personal Health Dashboard: Provides a personalised view into the performance and availability of the services customers are using, as well as alerts that are automatically triggered by changes in the health of those services.
n. Audit Trail: Provides logs of all user activity within an account. The recorded information includes the identity of the API caller, the time of the API call, the source IP address of the API caller, the request parameters, and the response elements returned by the cloud service. The log history produced should enable security analysis, resource change tracking, and compliance auditing.
o. Security Compliance Advisor: Monitors cloud resources and alerts customers to security configuration gaps such as overly permissive access to certain ports, minimal use of role segregation using IAM, and weak password policies.
p. Configuration Manager: Discover all of your cloud resources and view the configuration of each and receive notifications each time a configuration changes, as well as dig into the configuration history to perform incident analysis.
q. Systems Manager: Provides a unified user interface so that customers can view operational data from multiple cloud services and allows customers to automate operational tasks across their cloud resources.
r. Managed Services: Automates common activities such as change requests, monitoring, patch management, security, and backup services, and provides full-lifecycle services to provision, run, and support your infrastructure.
s. Cost and Budget Management: Manage and monitor usage of cloud offerings and mechanism to set up alarms with notifications to alert users when their spending has crossed a specific threshold. If the actual cost of the cloud consumption is less than the quoted, the actual cost will be paid.

5.3 Standard Terms and Conditions.

i. Complete ownership of source code lying with Buyer. Buyer shall have right to add, alter, modify either by its own resources or by engaging any IT solution provider or by any developers, post implementation of this Contract. Buyer may share the source code with Central Govt./ Other State Govts. for their use. 
ii. All rights to any intellectual property conceived or produced by the Service Provider for the Buyer in the course of performing services and all information (including information that is in electronic form), any design, data, drawing, specification, or other documents collected or produced by the Service Provider for the purpose of providing the services are the property of the Buyer from the date that property is created or developed and the Service Provider waives in favour of the Buyer any moral rights that the Service Provider may have. 
iii. Existing intellectual property: Despite anything to the contrary contained in this Agreement, it is understood and agreed that the Service Provider shall retain all of its rights in its proprietary information including, without limitation, its methodologies and methods of analysis, ideas, concepts, expressions, know how, methods, techniques, skills, knowledge and experience possessed by the Service Provider prior to, or acquired by the Service Provider during, the performance of this Agreement and the Service Provider will not be restricted in any way with respect to the same. 
iv. On termination or completion: Not more than five (5) Business Days following the date of termination of this Agreement (for whatever reason) or completion of the services, the Service Provider will deliver to the Buyer all information (including information that is in electronic form), Confidential Information, intellectual property, working papers, reports or other papers that are the property of the Buyer.
v. The Service Provider shall not be allowed to transfer, assign, pledge or subcontract its rights and liabilities under this Agreement to any other agency or organization by whatever name be called without the prior written consent of the Buyer. 
vi. The Service Provider shall at all times ensure that the services being provided under this Contract/ Agreement are performed strictly in accordance with all applicable laws, orders, byelaws, regulations, rules, standards, notifications, guidelines, recommended practices etc, and no liability in this regard will be attached to the Buyer.
vii. The Service Provider shall be fully responsible for the acts of their representatives / consultants/ team members/ CSP and shall fully indemnify the Buyer for any kind of losses or damages caused by its team members/ consultants/ CSP. The Buyer shall not be responsible for any claim from any consultant / team member/ CSP employed by the Service Provider. The Service Provider shall wholly and fully be responsible for any such claims.
viii. The Service Providers shall be deemed to have studied the items, specifications, and details of work to be done within the time schedule attached and to have acquainted with the conditions prevailing at site.
ix. Service Provider shall have to keep the Buyer totally indemnified against all claims, damages, dues, payments, fines, penalties, compensation demands, liabilities and other losses, if any, that may arise on account of any non-compliance or violation of any contractual or statutory provisions by the Service Provider.
x. The persons deployed by the Service Provider shall solely be the responsibility of the Service Provider and Buyers shall have no obligation for any sort of claims raised by the Service Provider’s employees/personnel. For all intents and purposes, the Service Provider shall be the “Employer” within the meaning of different Labour Legislations in respect of manpower so employed and deployed in the Buyer’s premises and shall be responsible to fulfil all obligations under applicable laws without any recourse to the Buyer.
xi. The Service Provider shall maintain the confidentiality of the information received or obtained or gathered by them during rendering of its services. The Service Provider shall ensure that the privacy of the user data must be protected all the time. Under no circumstances whatsoever, the Service Provider shall reveal such confidential information to any other party without the prior written approval of the Buyer.

6. Payment Schedule

i. The Payment procedure shall be in as specified in the General Terms and Conditions (GTC) of GeM. 
ii. Payment schedule to be as per selection specified in bid document.
a. In case Buyer has selected capex model–100 % of contract value excluding O&M is paid during the capex phase as per milestones specified by the Buyer and O&M is paid. 
b. In case Buyer has selected hybrid mode, part of the contract value excluding O&M is paid during the capex phase and remaining as quarterly payments along with the O&M invoices. 
iii. The milestones are as follows; the percentage payment will be specified by Buyer in payment terms document 
a. Detailed Survey Report, Solution Design and Detailed Project Report (after approval)
b. Supply of ICT & Non-ICT infrastructure like sensors and other devices at location;
c. Installation of ICT & Non-ICT infrastructure 
d. Unit Testing by System Integrator.
e. Final acceptance testing
f. Go-live
g. Quarterly O&M

7. Formula used 
Total Price = A
A =  Total device cost + Survey related cost for finalizing solution design + Year-wise O&M costand maintenance cost for application software(if applicable)+Cost of civil works + Cost for developing application software and deployment (if applicable) + Cost for setting up command and control centre (if applicable)

Required price break-up format maybe uploaded by the Buyer.

8. Deduction and Termination

For purposes of the SLA, the definitions and terms as specified in the document along with the following terms shall have the meanings set forth below:
a. “Total Time” - Total number of hours in the quarter (or the concerned period) being considered for evaluation of SLA performance. SLA period of measurement hours: 24x7x1 month
b. "Uptime" – Time period for which the specified services/ outcomes are available in the period being considered for evaluation of SLA. Formulae for calculation of Uptime: Uptime (%) = {1-[(Downtime)/(Total time- scheduled maintenance time)]}*100. . For example, if 10 number of sensors are deployed at various locations, and 2 sensors does not work for 5 hours, the total non-working device hours will be 10-unit hours (and the uptime would be {1-((2*5)/(10*30*24)}, 10 being the number of units, for 30 days on a 24 hour basis.
c. “Downtime”- Time period for which the specified services/ components/ outcomes are not available in the concerned period, being considered for evaluation of SLA, which would exclude downtime owing to Force Majeure & Reasons beyond control of the successful bidder.
d. “Scheduled Maintenance Time” - Time period for which the specified services/ components with specified technical and service standards are not available due to scheduled maintenance activity. The successful bidder is required to take at least 10 days prior approval from the Authority for any such activity. The scheduled maintenance should be carried out during non-peak hours (like post mid-night and should not be for more than 2 hours. Such planned downtime would be granted max 2 times a year.
e. “Incident” - Any event / abnormalities in the service being rendered, that may lead to disruption in normal operations and services to the end user.
f.  “Response Time” - Time elapsed from the moment an incident is reported in the Helpdesk over phone or by any applicable mode of communication, to the time when a resource is assigned for the resolution of the same. 
g. “Resolution Time” - Time elapsed from the moment an incident is reported to Help Desk either in person or automatically through the system, to the time by which the incident is resolved completely and services as promised are restored.
h. For every solution security-breach/vulnerability attack with severity level of 1, 2, 3 & 4 (as defined below)  

a. Severity 1: Solution down for more than 70% users 
b. Severity 2: Solution down for more than 30% users but less than 70% users. 
c. Severity 3: Control Centre down for more than 10% users but less than 30% users. 
d. Severity 4: Minor functionality
Any planned downtime for maintenance shall be with prior written permission from Buyer and must be intimated to all users in writing. Sensors and other devices undergoing a planned downtime will also be considered non-functional for the purpose of evaluating SLAs. Any availability/uptime requirements under SLA shall be subject to standard downtime outside the control of contractor, the time lost due to any of the following reasons will not be considered while calculating the availability/ uptime requirement ;

a. Time lost due to environmental disasters and time taken to recover the system because of environmental disasters. 
b. Scheduled shutdowns as required by SI including time taken forreconfiguration from such downtime situations. 
c. Time lost to recover the system owing to power supply failures (this is applicable only in case where power supply is not the responsibility of SI i.e., this exception is not valid for solar based implementations or where a dedicated power supply has been taken for the IoT solution as part of the contract by the SI). 

d. Downtime caused by failure at State’s or Centre’s servers/ applications.