RFP for Raj eSign Digital Signature Platform

RFP for Raj eSign Digital Signature Platform

of 166

Reference No. F4.3(211)/RISL/Tech/2017/105 date: 05-04-2017

Unique Bid No. RISL/17/OCB/230

Mode of Bid Submission Online though eProcurement/ eTendering system at http://eproc.rajasthan.gov.in

Procuring Authority Managing Director, RISL, First Floor, C-Block, Yojana Bhawan, Tilak Marg, C-Scheme, Jaipur-302005 (Rajasthan)

Date & Time of Pre-bid meeting 13-04-2017 at 03:00 PM

Last Date & Time of Submission of Bid 08-05-2017 upto 01:00 PM

Date & Time of Opening of Technical Bid 08-05-2017 at 03:00 PM

Bidding Document Fee: Rs. 5000 (Rupees Five Thousand only)

Name of the Bidding Company/ Firm:

Contact Person(Authorised Bid Signatory):

Correspondence Address:

Mobile No. Telephone & Fax Nos.:

Website & E-Mail:

Request for Proposal (RFP) Document

for Selection of Agency to Implement, Operate and Maintain Raj eSign Digital Signature Platform for

RajCOMP Info Services Limited

RajCOMP Info Services Limited (RISL) First Floor, Yojana Bhawan,

C-Block, Tilak Marg, C-Scheme, Jaipur-302005 (Raj.) Phone: 0141-5103902 Fax: 0141-2228701

Web: http://risl.rajasthan.gov.in, Email: [email protected]

http://eproc.rajasthan.gov.in/

mailto:[email protected]


of 166

ABBREVIATIONS & DEFINITIONS

Act The Rajasthan Transparency in Public Procurement Act, 2012 (Act No. 21 of 2012), its subsequent amendments and Rules thereto

API Application Programming Interface AMC Annual Maintenance Charge APT Advance Persistent Threat ASP Application Service Provider ATS Annual Technical Support Authorised Signatory The bidder’s representative/ officer vested (explicitly, implicitly, or through

conduct) with the powers to commit the authorizing organization to a binding agreement. Also called signing officer/ authority having the Power of Attorney (PoA) from the competent authority of the respective Bidding firm.

BG Bank Guarantee Bid/ eBid A formal offer made in pursuance of an invitation by a procuring entity and

includes any tender, proposal or quotation in electronic format

Bid Security A security provided to the procuring entity by a bidder for securing the fulfilment of any obligation in terms of the provisions of the bidding documents.

Bidder Any person/ firm/ agency/ company/ contractor/ supplier/ vendor participating in the procurement/ bidding process with the procurement entity

Bidding Document Documents issued by the procuring entity, including any amendments thereto, that set out the terms and conditions of the given procurement and includes the invitation to bid

CA Certifying Authority CCA Controller of Certifying Authorities CLI Command line Interface CMC Contract Monitoring Committee CRL Certificate Revocation List CSP Certification Service Provider Competent Authority An authority or officer to whom the relevant administrative or financial

powers have been delegated for taking decision in a matter relating to procurement. MD, RISL in this bidding document.

Contract/ Procurement Contract

A contract entered into between the procuring entity and a successful bidder concerning the subject matter of procurement

Contract/ Project Period

The Contract/ Project Period shall commence from the date of issue of Work order till 36 months of Services after commissioning of the project.

CRL Certificate Revocation List DAS Direct Attached Storage DOS Denial of Service DR Disaster Recovery DSC Digital Signature Certificate Day A calendar day as per GoR. DoIT&C Department of Information Technology and Communications, Government of

Rajasthan. EMS Enterprise Management System ESP eSign Service Provider GoI/ GoR Govt. of India/ Govt. of Rajasthan GIGW Guidelines for Indian Government Websites ICT Information and Communication Technology.


of 166

IFB Invitation for Bids (A document published by the procuring entity inviting Bids relating to the subject matter of procurement and any amendment thereto and includes notice inviting Bid and request for proposal)

INR Indian Rupee IOG Interoperability Guidelines for Digital Signature Certificate by CCA IR Incident Response IT Information Technology ITB Instruction to Bidders IVG Identity Verification Guidelines by CCA LD Liquidated Damages LDAP Lightweight Directory Access Protocol LDIF LDAP Data Interchange Format LoI Letter of Intent NAS Network Attached Storage NCB A bidding process in which qualified bidders only from within India are

allowed to participate NIB Notice Inviting Bid Notification A notification published in the Official Gazette NPL National Physical Laboratory OCSP Online Certificate Status Protocol OEM Original Equipment Manufacturer OTP One Time Password PAN Permanent Account Number PBG Performance Bank Guarantee PC Procurement/ Purchase Committee PKI Public Key Infrastructure PQ Pre-Qualification PR Primary Site

Procurement Process The process of procurement extending from the issue of invitation to Bid till the award of the procurement contract or cancellation of the procurement process, as the case may be

Procurement/ Public Procurement

The acquisition by purchase, lease, license or otherwise of works, goods or services, including award of Public Private Partnership projects, by a procuring entity whether directly or through an agency with which a contract for procurement services is entered into, but does not include any acquisition without consideration, and “procure” or “procured” shall be construed accordingly

Project Site Wherever applicable, means the designated place or places. PSD/ SD Performance Security Deposit/ Security Deposit Purchaser/ Tendering Authority/ Procuring Entity

Person or entity that is a recipient of a good or service provided by a seller (bidder) under a purchase order or contract of sale. Also called buyer. RISL in this RFP document.

RA Registration Authority RAID Redundant array of independent disks RISL RajCOMP Info Services Limited RSDC Rajasthan State Data Centre, New IT Building, Jaipur RVAT Rajasthan Value Added Tax

Services

Any subject matter of procurement other than goods or works and includes physical, maintenance, professional, intellectual, consultancy and advisory services or any service classified or declared as such by a procuring entity and does not include appointment of any person made by any procuring entity

SAN Storage Area Network


of 166

SI Systems Integrator SIMS Subscriber Information Management System

SLA

Service Level Agreement is a negotiated agreement between two parties wherein one is the customer and the other is the service provider. It is a a service contract where the level of service is formally defined. In practice, the term SLA is sometimes used to refer to the contracted delivery time (of the service) or performance.

SNMP Simple Network Management Protocol State Government Government of Rajasthan (GoR) State Public Procurement Portal

http://sppp.raj.nic.in

STQC Standardisation Testing and Quality Certification, Govt. of India Subject Matter of Procurement

Any item of procurement whether in the form of goods, services or works

TIN Tax Identification Number TPA Third Party Auditors UDP User Datagram Protocol UIDAI Unique Identification Authority of India URL Uniform Resource Locator VAPT Vulnerability Assessment and Penetration Testing VAT/ CenVAT Value Added Tax/ Central VAT WO/ PO Work Order/ Purchase Order

http://sppp.raj.nic.in/


of 166

1. INVITATION FOR BID (IFB)& NOTICE INVITING BID (NIB)


of 166


of 166

2. PROJECT PROFILE &BACKGROUND INFORMATION 2.1 Project Profile

Information technology sector in India has developed at very rapid pace which has resulted in the IT sector’s increased contribution to India's GDP. This in turn has led to e-commerce and e-governance being an integral part of the social and economic life. E-government is the cornerstone of the next-generation of government. Citizens, businesses, and government agencies are already benefiting from their ability to access services and conduct transactions online. E-government programs allow government organizations to deliver services, distribute resources, and administer programs more efficiently, which drives operational costs down. Traditional identification credentials are neither robust enough to protect against cyber fraud, nor can they enable the next generation of applications, such as digitally signed tax returns, electronic tenders, and seamless border control. Instead, the need of the hour is a strong authentication, encryption, and digital signatures that are part of a comprehensive and scalable Public Key Infrastructure (PKI) platform. PKI is the foundation on which secure and trusted transactions can be executed. Whether between individuals and governments; businesses and governments; or inter-government relationships, PKI allows entities to securely authenticate all participants in a transaction. eSign Electronic Signature Service is an innovative initiative for allowing easy, efficient, and secure signing of electronic documents by authenticating signer using Aadhaar eKYC services. With this service, any Aadhaar holder can digitally sign an electronic document without having to obtain a physical digital signature dongle. Application Service Providers can integrate this service within their application to offer Aadhaar holders a way to sign electronic forms and documents. The need to obtain Digital Signature Certificate through a printed paper application form with ink signature and supporting documents will not be required.

2.2 Brief of the Project

A Certifying Authority is a trusted body whose central responsibility is to issue, revoke, renew and provide directories of Digital Certificates. In real meaning, the function of a Certifying Authority is equivalent to that of the passport issuing office in the Government. A passport is a citizen's secure document (a "paper identity"), issued by an appropriate authority, certifying that the citizen is who he or she claims to be. Any other country trusting the authority of that country's Government passport Office will trust the citizen's passport. The IT Act 2000 gives details of who can act as a CA. Accordingly a prospective CA has to establish the required infrastructure, get it audited by the auditors appointed by the office of Controller of Certifying Authorities, and only based on complete compliance of the requirements, a license to operate as a Certifying Authority can be obtained. The license is issued by the Controller of Certifying Authority, Ministry of Information Technology, Government of India. Similar to a passport, a user's certificate is issued and signed by a Certifying Authority and acts as a proof. Anyone trusting the Certifying Authority can also trust the user's certificate. For operating as a licensed Certifying Authority under the IT Act, 2000 an application has to be made to the Controller of Certifying Authorities as stipulated under Section 21 of the IT Act. The application form for grant of license prescribed under Rule 10 of the IT Act has to be submitted to the Controller of Certifying Authorities. Before submitting the application however, the applicant is expected to have the entire infrastructure - technical, physical, procedural and manpower - in place. On receipt of the application and after examination of the same along with the supporting documents, CCA will depute an empanelled auditor based on whose audit report a decision will be taken on whether a license can be granted to the applicant to operate as a Certifying Authority under the IT Act 2000.


of 166

eSign online Electronic Signature Service can be effectively used in scenarios where signed documents are required to be submitted to service providers – Government, Public or Private sector. The agencies which stand to benefit from offering eSign online electronic signature are those that accept large number of signed documents from users. RISL intends to become a Certifying Authority (CA). According to Section 24 of Information Technology Act 2000 "a Certifying Authority means an agency that has been granted a license to issue Digital Signature Certificates”. A Certifying Authority is a trusted body whose central responsibility is to issue, revoke, renew and provide directories of Digital Certificates. Additionally, a CA may also provide electronic signing (e-Sign) services. An electronic signature offers a mechanism to replace manual paper-based signatures with digital ones. By integrating this service within their applications and enabling an UID (Aadhaar) holder to electronically sign a form/document anytime, anywhere, and on any device, the Application Service Providers (ASPs) authenticate a user. e-Sign can significantly reduce costs, improve efficiency, and offer convenience to citizens. They shall also indirectly contribute to the environment by reducing the usage of paper considerably. eSign Online electronic signature service, offers applications a mechanism to replace manual paper based signatures by integrating this service within their applications. An Aadhaar holder can electronically sign a form/document anytime, anywhere, and on any device. eSign service facilitates significant reduction in paper handling costs, improves efficiency, and offers convenience to customers. RajCOMP intends to provide Digital Signature Certificates (DSC) to the employees and residents, for promoting e-governance, by building a ‘trusted’ digital environment in the usage of cyber space, leading towards good and efficient Governance. Besides issuing Digital Signature Certificates in G2G domain, Online Directory Services for Digital Signature Certificates and Certificate Revocation Lists (CRL), RajCOMP also intends to provide e-Sign (as an ESP or e-Sign Provider), OCSP and Time stamping Service through implementation done with this RFP. The recent modifications in the IT Act have provided for recognition of Aadhaar based e-Sign, this has made it possible to use e-Sign technology for a large number of applications. It is expected that over the next few years e-Sign will be the mainstream authentication tool in the Digital world.

2.3 Purpose of the RFP RISL intends to implement Certificate Authority solution. For the above purpose, RISL solicits proposals from qualified bidders for providing services for Design, Supply, Installation, Commissioning, Implementation and support for CA solution as per CCA guidelines. For the above defined purpose, RISL intends to use its existing Data Centre and shall comply to CCA norms including but not limited to DC and DR Sites. Any work/activity that needs to be conducted in order to use the implemented technology/functionality shall also be a part of this project, e.g. Integration with any portal, customizing any script, API or DLL etc. NOTE: Bidders are advised to study this RFP document carefully before submitting their proposals in response to this RFP. Submission of a proposal in response to this RFP shall be deemed to have been done after careful study and examination of this document with full understanding of its terms, conditions and implications. Failure to furnish all information required as mentioned in the RFP documents or submission of a proposal not substantially responsive to the RFP documents in every respect will be at the Bidder's risk and may result in rejection of the proposal.


of 166

3. PRE-QUALIFICATION/ ELIGIBILITY CRITERIA A bidder participating in the procurement process shall possess the following minimum Pre-

qualification criteria

S. No.

Basic Requirement

Specific Requirements Documents Required

1 Legal Entity

The bidder should be a Proprietorship firm duly registered either under the Rajasthan Shops & Commercial Establishments Act, 1958 or any other Act of State/ Union, as applicable for dealing in the subject matter of procurement (Note: A self-certified declaration regarding the non-applicability of registration to any Act should be submitted by the bidder) OR A company registered under Indian Companies Act, 1956 OR A partnership firm registered under Indian Partnership Act, 1932. OR A Limited Liability Partnership registered under Limited Liability Partnership Act, 2008.

Copy of valid Registration Certificates

Copy of Certificates of incorporation

2 Years of Existence

The bidder should be in existence for not less than preceding 5 years as on 31.3.2017.

Copy of valid Registration Certificates

Copy of Certificates of incorporation

3 Financial: Turnover from IT/ ITeS

Average Annual Turnover of the bidder from IT/ ITeS during the last three financial years, i.e., from 2013-14 to 2015-16 (as per the last published audited balance sheets), should be at least Rs. 25,00,00,000, i.e. INR Twenty Five Crores Only

CA Certificate with CA’s Registration Number/ Seal

4 Financial: Net Worth

The net worth of the bidder, as on March 31, 2016 should be Positive.

CA Certificate with CA’s Registration Number/ Seal

5 Technical Capability

The bidder should have Implemented / Operationalized at least 1, i.e. One IT Project in the domain of Digital Signatures/DC/ DR with a project value of minimum INR 2,00,00,000 i.e. INR Two Crore Only. OR The bidder should have Implemented / Operationalized 2, i.e. Two IT Projects in the domain of Digital Signatures/DC/ DR with a joint/combined project value of minimum INR 3,00.00.000 i.e. INR Three Crore Only

Annexure-7 per project reference

And Work Completion

Certificates from the client; OR

Work Order + Self Certificate of Completion (Certified by the Statutory Auditor); OR

Work Order + Phase Completion Certificate from the client


of 166

S. No.

Basic Requirement

Specific Requirements Documents Required

6 Tax registration

The bidder should have a registered number of i. Service Tax

ii. Income Tax / Pan number iii. Sales Tax iv. VAT Registration and VAT Clearance

till December 31, 2016 v. PF

Copies of relevant certificates of registration

7 Certifications

The bidder must possess, at the time of bidding, all of the following valid Certification

i. ISO 9001:2008 or ISO 9001:2015 ii. ISO 20000

iii. ISO 27001 iv. CMMI L3 or higher

Copy of a valid certificate

8 Declaration

The bidder should not be a CA licensed by the CCA for providing CA operations in India. Bidder should not have conflict of interest, or potential conflict of interest; or any incident that materially and adversely affects the RajCOMP Certification Authority's operations.

Declaration on Non Judicial Stamp Paper of minimum value of INR 1000 Only

9 Mandatory Undertaking

Bidder should: - a. not be insolvent, in receivership, bankrupt

or being wound up, not have its affairs administered by a court or a judicial officer, not have its business activities suspended and must not be the subject of legal proceedings for any of the foregoing reasons;

b. not have, and their directors and officers not have, been convicted of any criminal offence related to their professional conduct or the making of false statements or misrepresentations as to their qualifications to enter into a procurement contract within a period of three years preceding the commencement of the procurement process, or not have been otherwise disqualified pursuant to debarment proceedings;

c. comply with the code of integrity as specified in the bidding document.

A Self Certified letter as per Annexure-3: Self-Declaration

In addition to the provisions regarding the qualifications of the bidders as set out in (1) above: - 1. the procuring entity shall disqualify a bidder as per the provisions under “Clause: Exclusion/

Disqualification of bids in Chapter-5: ITB”; and 2. the procuring entity may require a bidder, who was pre-qualified, to demonstrate its qualifications in

accordance with the same criteria used to pre-qualify such bidder. The procuring entity shall disqualify any bidder that fails to demonstrate its qualifications, if requested to do so. The procuring entity shall promptly notify each bidder requested to demonstrate its qualifications as to whether or not the bidder has done so to the satisfaction of the procuring entity.


of 166

4. SCOPE OF WORK, DELIVERABLES & TIMELINES 4.1 Need and Benefits

RISL becoming a Certifying Authority will be hugely beneficial to the public for availing government services through digitally signing and also with the facility of e-Sign as this will cut short the turnaround time for processing applications on paper. For offering fully paperless citizen services, mass adoption of digital signature is necessary. A simple to use online service is required to allow everyone to have the ability to digitally sign electronic documents. In current scenario where lots of government services are moving towards online mode, digital signatures are required for ease of operation. Different stakeholders in various services viz G2G, G2B, G2C, G2E require digital signatures for electronic authentication. Further DoIT&C, GoR as a State Registrar of UIDAI has already commenced Aadhaar e-KYC services. In lieu of future landscape of services offered by government (G2G, G2B, G2C, G2E), it will be pertinent that RISL takes initiative to become Certifying Authority under Controller of Certifying Authorities, MeitY, GoI and offer Digital Signatures to applicants including e-Sign services which are electronically signed based on Aadhaar authentication. Also Time stamping & OCSP services shall be a part of the project.

4.2 Stakeholders and their involvement

4.2.1 Application Service Provider- An organization or an entity using eSign service as part of their application to electronically sign the content. Example: Govt. Departments, Banks, other public/ private organizations.

4.2.2 End User- Any individual using the application of ASP and represents himself/ herself for signing the document under legal framework. Also a resident holding the Aadhaar number and applicant/ subscriber for digital certificate.

4.2.3 Certifying Authority- An organization (RISL) licensed under CCA which issues Digital Signature Certificate and carries out allied CA operations. RISL shall engage with CCA authorized auditors for Audit and obtain approval for ESP/CA system to start eSign & time stamping services and CA operations.

4.2.4 Digital Signature Issuance authority & e-Sign service provider- Trusted Third Party as per the definitions of Second Schedule of Information Technology Act to provide eSign service. To begin with ESP is a Licensed Certifying Authority (CA). RISL intends to become CA to provide digital signature issuance authority, e-Sign service provider & time stamping services.

4.2.5 Controller of Certifying Authorities (CCA) - CCA shall conduct an audit before providing license of certifying Authority (CA) to RISL based on compliance on security guidelines for CA operations.

4.2.6 UIDAI- Provide unique identity to all Indian residents. Provides e-KYC authentication service to registered KUAs. Authentication services shall be provided by DoIT&C (State Registrar) which is KUA under UIDAI.


of 166

4.3 Scope of Work 4.3.1 Logical Framework

The Scope of the work for the project “Raj eSign Digital Signature Platform” has been divided broadly into multiple components, as represented below:-

Raj eSign Platform – Logical Framework

4.3.2 Geography The geographical scope of the Project will be at Rajasthan State Data Centre site in Jaipur, Rajasthan and a DR site in Jodhpur. The solution should consist of a minimum of all components described in this document.


of 166

4.3.3 Logical Setup of Primary Site at RSDC

4.3.4 Logical Setup of DR Site at Jodhpur


of 166

4.3.5 Infrastructure Setup The Raj eSign Platform infrastructure design shall be done with a perspective of securing the infrastructure in a multi zone manner. The idea is to secure the facility from a physical and logical security. To ensure physical security separate zones shall be created with independent access controls for each zone corresponding to class of security required. To ensure logical security, each such zone shall have independent systems, logical separation and security using inter-zone Firewall devices with zone wise management control. This would ensure that personnel required to work on a specific zone would have to physically access that zone and work exclusively in that zone. Zones shall be interconnected but are not remotely accessible from other zones. Each Zone shall be separated by a set of NGFW. The Network shall hop from the web zone to Secure Zone to the Core Zone in a layered manner. Each zone shall have its own firewalls and finally reduces visibility for the core zone to the most filtered traffic.

The Infrastructure shall be divided in Zones as below: o Primary Site

Core CA Zone Secure Zone Web/Monitoring Zone Test Zone

o Disaster Recovery Site CA/eSign Zone Other Zone

4.3.6 Common Infrastructure

The following components are common across all zones. Each zone will have zone specific components of the following services / hardware.

• LDAP / Authentication Server • Antivirus Server • Log Collector / Storage / Forwarder • EMS Collector / Storage / Forwarder • DB Server instances of the above systems • Backup Server • Tape Backup System (Standalone / Library) • NGFW • Switches

4.3.7 Core CA Zone

The core CA zone shall be the most secure zone in the infrastructure. This zone shall house the most critical systems of the infrastructure. Components of the Core Zone shall be as below:

• eSign CA • Traditional CA • SSL CA • HSM • NPL Time Devices • Telephone Link for Time Devices • CA related Servers( LDAP / DB / OCSP / TSA )


of 166

4.3.7.1 Suggestive List of VM in Core CA Zone Primary Site - CA Zone VM Cluster CA VMs Traditional CA VMs Common Servers

CA and Signing Server MySQL Database for CA MySQL Database for RA MySQL Database for OCSP

and TSA CA Offline

RA Server LDAP Server OCSP and TSA Server

Master LDAP Server for Sitewise Authentication

Backup LDAP Server for Authentication

Virtual Machine Management System

Anti-Virus VM EMS Server Collector Log Collector Server Database Server for Log / EMS

Collector

4.3.8 Secure/eSign Zone The Secure/eSign zone shall house eSign-connected servers and Subscriber data related systems and Subscriber Data, Accounting Systems, etc. Components of the eSign Zone shall be as below:

• eSign Servers • HSM • DB Servers for the above systems

4.3.8.1 Suggestive List of VM in Secure/eSign Zone Primary Site - eSign Zone VM Cluster eSign CA VMs Traditional CA VMs Common Servers

CA and Signing Server

MySQL Database for CA

MySQL Database for eSign

eSign Server CA Offline

eSign Server LDAP Server

Zone LDAP for Authentication

Virtual Machine Management System

Anti-Virus VM EMS Server Collector Log Collector Server Database Server for Log /

EMS Collector

4.3.9 Web Zone The Secure Zone is the outward facing zone and sits at the perimeter. External world or systems facing and connecting to the outside world terminate on this zone. The Secure Zone houses: • eSign Application Server • CA Application Server • CA Application DB • Email Server


of 166

4.3.9.1 Suggestive List of VM in Web Zone Primary Site – Web Zone VM Cluster

Web Facing Servers Common Servers

CA Application Server eSign Application Server Database Server for CA eSign DB Server Mail Server

Zone LDAP for Authentication Virtual Machine Management System Anti-Virus VM EMS Server Collector Email Server Log Collector Server Database Server for Log / EMS Collector

4.3.10 Monitoring Zone

The monitoring zone accumulates all the information from zone level systems and presents them to a single Interface. All logs and EMS related data accumulates here. This Zone contains the highest amount of data.

• Central Log Server • Central EMS Server • Internal Help Desk Systems • SLA Monitoring • Master AV Server • Firewall Management Server • CCTV Monitoring • Access Control Server • Dual Drive Tape Library

4.3.10.1 Suggestive List of VM in Monitoring Zone Primary Site – Monitoring Zone VM Cluster

Monitoring related Servers Common Servers

Master EMS Server Master Log Server Database Server for EMS / Log Server /

Ticketing etc. Help Desk / Support Ticketing Server Centralized UTM / Firewall Management Server Central Switch / Storage / Mgmt Server

Zone LDAP for Authentication Virtual Machine Management System Anti-Virus VM

4.3.11 Disaster Recovery Site

To reduce the footprint, the DR site envisages consisting of two zones instead of the three zones as at the Primary site. The database replication shall be in the log shipping method or automated via tool and shall be configured accordingly, while the VM will need to be migrated using appropriate technologies as supplied by the bidder. To crunch the three zones from the Primary site to Disaster recovery the two zones are envisaged to be segregated by differentiating critical servers and other servers. The critical servers shall include all data and content related to CA, eSign, Subscriber Data, etc. All data as well as database has to be replicated to the Core Zone at the DR Site.


of 166

The other zone shall contain replicated data of all logs, EMS, Service desk, etc. 4.3.11.1 Indicative list of Virtual Machines in DR Site – CA Zone

Disaster Recovery Site – CA Zone VM Cluster Status

VM Cluster Live / Standby

Replicated / Sync

eSign CA VMs eSign CA Server Standby Replicated OCSP Server Standby Replicated Time Stamping Server Standby Replicated Database Server for eSign CA Live Sync Separate LDAP Server for eSign CA (OpenLDAP / MS AD) Live Sync Traditional CA VMs CA Server Standby Replicated SSL CA Server Standby Replicated OCSP Server Standby Replicated Time Stamping Server Standby Replicated Database Server for CA and SSL CA Server Live Sync Separate LDAP Server for CA ( OpenLDAP / MS AD ) Live Sync Common Servers Zone LDAP for Authentication Live Sync Virtual Machine Management System Live Local Anti-Virus VM Live Local EMS Server Collector Live Local Log Collector Server Live Local Database Server for Log / EMS Collector Live Local

4.3.11.2 Indicative list of Virtual Machines in DR Site – CA Zone

Disaster Recovery Site – Other Zone VM Cluster Status

VM Cluster Live / Standby

Replicated / Sync

eSign VMs eSign Server Standby Replicated Database Server Live Sync CA related VMs ( Replicated VMs from Primary ) Subscriber Information Management Server Standby Replicated Token Management Server Standby Replicated Accounting Server Standby Replicated Database Server Live Sync Common Servers Zone LDAP for Authentication Live Sync Virtual Machine Management System Live Local Anti-Virus VM Live Local EMS Server Collector Live Local Log Collector Server Live Local Database Server for Log / EMS Collector Live Local Web Facing Servers Website Standby Replicated User Login / User Management for Traditional CA Standby Replicated Database Server Live Sync Mail Server Standby Replicated


of 166

Help Desk / Support Ticketing Server Standby Replicated Master Log Database Replication Database Server for EMS / Log Server Live Sync

4.3.12 Test Environment

A test environment shall be created at the Primary site for testing of all technologies, testing of patches, updates, upgrades, etc. before they are deployed in the production setup. One system/component of each type shall be installed in the Test Environment. As it would not contain any critical data or uptime requirements, the test environment shall be the least secure and shall be housed outside the enclosure housing the other four zones.

4.3.13 NOC All zones for the Raj eSign Platform shall be unmanned except the NOC area. This area shall be earmarked at both the Primary as well as DR Sites. There shall be an arrangement of 10 personnel to be seated at the Primary site and 4 personnel to be seated at DR Site. LED screens with appropriate switcher shall be installed at Primary Site and one at DR site in this zone for the convenience of the monitoring team to view alerts, graphs, system status, etc.

4.3.14 Key Design Criteria The infrastructure has been designed to have no single point of failure for critical components. Each component shall be virtualized and shall support the following: • No Single Point of Failure • High Availability • Complete Redundancy • Scalability by adding components • Tuning the system for best Performance • Failover and Load Balancing • Replication for Backup and Recovery • Business Continuity and Disaster Recovery • Other components of the system • Database Security, Interoperability and replication • Log Collection, Management and Monitoring • Infrastructure Monitoring and Management ( EMS ) • Unrestricted License for CA The entire infrastructure shall be designed to work on a Virtualized environment. All components quoted by the bidder should adhere to and be certified to work on the virtual infrastructure that the bidder is quoting. All components, viz. servers, network equipment, CA software, Database, etc. quoted for the Raj eSign Platform should support a centralized authentication mechanism. All components quoted by the bidder should be compatible to this centralized authentication mechanism. All components in the environment shall have to be appropriately hardened for security purposes. These components include, but are not limited to, UTM, Routers, Switches, Servers, Hyper-converged infrastructure, backup subsystems, Databases, Applications, CA Software, Web applications, Mail Servers, etc. Applications and modules which are not part of a standard offering of an OEM and not certified by the Principal OEM, in writing, as a readymade product offering shall be considered as developed exclusively for Raj eSign Platform. In such case, such applications and modules shall be considered as specifically developed for the purpose of this project. All documentation pertaining to such applications and


of 166

modules along with the entire SDLC Lifecycle and source code shall be provided to RISL. The source code will be the sole property of RISL and should be versioned, labeled and base lined appropriately.

4.3.15 CA Solution The Certifying Authority components must be supplied with an unrestricted license. These components include Digital Certificate Lifecycle management software solution, Time Stamping solution and OCSP solution. As each Certifying Authority solution has different components, any other component other than those described above which enable the working of the CA solution should also come with an unrestricted license. As each CA has to be implemented separately, there should be no limitation in terms of number of hosts which can be installed, number of certificates that can be generated and number of instances per CA which can be hosted in future for the purpose of failover or load balancing. Each CA and components thereof shall be replicated to DR site in either or all of the three methods, Database Replication, VM Replication or Storage Replication. The CA Solution should adhere to all requirements stipulated by the CCA and it shall be the responsibility of the bidder to make respective and relevant changes, to the CA software and components thereof, as and when the CCA guidelines change. This shall be within the scope of the bidder for the entire duration of the Project. 4.3.15.1 CA Software

The software need to manage the entire lifecycle of a digital certificate such as SSL certificates, Digital Signature Certificates etc., starting from applicant’s request, scrutiny of the applicant, its acceptance or rejection by the Registration Authority (RA), the certificate generation, its final signature by the CA and its acceptance by the applicant.

4.3.15.2 Time Stamping Authority Independent and irrefutable proof of time for transactions, documents and digital signatures which can be used to provide legal sanctity to the business transactions occurring at a point in time, that e-document existed at a given time and has not been subsequently altered. The solution should also be able to prove independently when a digital signature was applied by the signer such that its validity can be verified in the long-term, even after expiry or revocation of signer’s digital credentials.

4.3.15.3 Online Certificate Status (OCS) Before relying on a digital certificate it’s important to check its current status to ensure it’s not revoked (e.g. security compromise, lost keys, cessation of operations etc.). The Online Certificate Status Protocol (OCSP, RFC 2560) is the most accepted approach for efficiently checking a certificate’s revocation status. OCSP client-side functionality is widely implemented in browsers, operating systems, networking devices and document software like Adobe Reader. RISL needs to setup a OCSP responder, which will not only check whether or not a certificate is included on a CRL, but also determine if the certificate was actually issued by the CA by looking at the CA’s database of issued certificates. The browsers should be able to obtain the revocation status of an X.509 digital certificate. Online Certificate Status Protocol (OCSP) server should enable applications to determine the revocation status of identified certificates and should satisfy such operational requirements of providing


of 166

timely revocation and other additional status information.

4.3.15.4 Customized / Custom Developed Solution For the Software development bidder shall follow the processes as per Software Development Life Cycle (SDLC) and would submit an SRS document to RISL. There would be some modules, as required to be implemented for the purposes of this project, which may be available with the Bidder while some may need to be developed from scratch. For any module(s) specifically developed for the purpose of this project, all documentation with the SDLC Lifecycle and source code shall be provided to RISL. The source code will be the property of RISL and should be versioned, labeled and base lined appropriately.

4.3.15.5 eSign Solution The government has introduced ‘Electronic Signature or Electronic Authentication Technique and Procedure Rules, 2014’ wherein e-authentication using ‘Aadhaar e-KYC services’ have been introduced as e- authentication technique, to eliminate the stumbling block in widespread usage of Digital Signature in electronic environment. This service has been termed as “eSign Service”. eSign Service facilitates digitally signing a document by an Aadhaar number holder, using an online service. While authentication of the signer is done using Aadhaar e-KYC services, the signature on the document is done on a backend server which is the ESP. The service can be provided by a trusted third party, like a Certifying Authority. This is an integrated service that facilitates issuing of Digital Signature Certificate and signing of data by authenticating the Aadhaar number holder. The certificate thus issued will have limited validity period and is only for one-time signing of data, in a single session. eSign service shall be implemented in line with e-authentication guidelines issued by Controller of Certifying Authorities (CCA). The entire solution has to be provided by the bidder. Integration with HSM, Third Party portals / websites / applications as well as internal connectivity to the CA system will be part of the deliverable. All regulations as prescribed should be followed while delivering the solution. Future changes in regulations and changes / modifications required to this component will remain part of the bidder’s scope for the duration of the project.

4.3.16 Raj eSign Portal

As a standard, the bidder would be expected to design and maintain the Raj eSign portal as per GIGW guidelines during the entire project period.

4.3.17 SIMS, Inventory Management and Cost Accounting The requirements are provided for Subscriber Information Management System, media inventory (Token) and fee accounting management modules. These modules should be inter-connected such that entry made in one module will reflect in context-sensitive mode in other modules. Entries will need to be done only once in any module and there should be no need for repeating entry in another module after it is done in one module. Moreover, changes made through one module should automatically and immediately (in real time) be reflected in other modules. Reports and search results should be exportable in .xls format and .pdf format from the application itself. The application should be web based to allow access from anywhere and have the following main modules with features as listed below. These modules will be for


of 166

exclusive use of Raj eSign trusted roles and not accessible to Raj eSign platform subscribers.

4.3.17.1 SIM (Subscriber Information module) Module shall store all information related to applicants which is available in the form of dynamic queries and reports for the users (Raj eSign Platform trusted roles). The module shall generate Ref. No. which is unique and used to track applicant details. In addition to personal details, it shall also hold payment history and dispatch details of media.

a. Search queries required on at least the following data values and combinations thereof:-

i. Name ii. Department

iii. City iv. State v. Project details (name or id)

vi. Type of User (Govt., PSU, Registered Company) vii. Class of Certificate (Class I, Class II, Class III)

viii. Type of Certificate (Signing, Encryption, Code Signing, SSL etc.) ix. Media dispatch details (Date, mode, person collecting etc.) x. Payment details (Draft details, bank name, branch, date of

submission to RR section) xi. Date of entry creation in system

b. Complete history of applicant requests including renewal tracking and across all types of certificates.

c. RAs will have access to their own reports only. d. Super admins will have access to all reports. e. All reports should be able to display details RA-wise or for whole of Raj

eSign Platform. f. Monthly / Yearly reports for DSCs issued. g. Count of DSCs issued State-wise, RA Office. h. Project-wise DSCs issued list, Type-wise DSCs issued. i. User-wise reports of entry (user here refers to all users of MIS from any

RA). j. Payment reports – payments received, payments pending and

payments utilized. k. Module should allow a single user to submit multiple drafts for a single

DSC issuance. l. Module should allow multiple users to submit a single common draft.

Tracking for same and usage beyond the limit should be available as standard feature.

m. Proper handling of renewal requests by users should be available. n. Modification of certain details such as payment etc. should be available. o. Deletion of records will not be allowed. p. Data should be segregated RA wise. One RA should not have access to

data from another RA. Viewing may be an option (upon specific request enabled manually) but not editing in any case.

q. A super-admin mode to view all data from a single location across all RAs.

r. Populated lists for State names, Departments, Type of Certificate, Class of Certificate and Projects will be available to (SIM) users. These can be updated only by super admins.

s. Password complexity must strictly be implemented for MIS users. t. Option to mark persons leaving the organization due to any reason

such as retirement, death or otherwise.


of 166

4.3.17.2 Inventory Management The module should have exhaustive information for all stocks held by Raj eSign Platform including all RA Offices. i. An inventory database where tracking of all inventory on hand, what

has been dispatched and when reorder is required. ii. Add stock at Raj eSign Platform as main entry. iii. Stock entered at Raj eSign Platform should be transferrable to RA

office. Stock thus transferred must be accepted by RA (after receipt of the physical package) before issuance.

iv. Add stock received through direct delivery to RA. Inventory reconciliation should be available as standard feature.

v. Alerts for low stock levels and critical stock levels should be flashed to respective RAs and super admins.

vi. Critical and low stock level must be customizable. vii. Stock transfer between RAs should be available but only with the

approval of super admin. viii. Monthly and yearly stock reports should be available. ix. Reports should have option for both reconciled and un-reconciled

entries. x. Super admin user should have facility to generate consolidated report

for specific or all RAs combined. xi. Stock levels at all RAs should be reported at month and year end. xii. All RAs should be able to generate reports for their respective offices

only. xiii. Reports must be compatible to GFR-41 format. xiv. Inventory must be automatically adjusted based on issuance of media

by RA. xv. Issuance of media by RA should not be possible till receiving stock

entry is done. xvi. As in SIM, a type of super admin mode should be available for

monitoring the whole stock from a single admin login at Raj eSign Platform.

xvii. Provision to record returned defective media and its replacement. xviii. Generate reports for printing, including items purchased, items

dispatched and total cost of items.

4.3.17.3 Cost Accounting The cost accounting module should take care of all requirements related to costing and payment. Entries will first be made here for new purchases done and will reflect in other modules in real-time. i. Store all details related to purchase of media like PO No., PO Date,

Description, Amount, Vendor details, Date of Delivery, Location, Stock No., Quantity, per item cost.

ii. Extensive search options should be available for all fields with on the fly customization of results.

iii. Generate reports for printing, including items purchased, items dispatched and total cost of items.

iv. May also keep track of schedules based on purchasing time-line. v. Keep track of bidder information and their contact details etc. vi. May also have feature to display scanned copies of purchase orders. vii. Should have some customization facility for adding new product at later

stage. viii. Monthly and yearly reports based on RA and for all of Raj eSign Platform

displaying total expenditure category-wise.


of 166

4.3.18 Supply Installation & Commissioning of IT Infrastructure (Servers, , Backup Tape Library Systems, Network devices, UTM/Firewalls devices) The primary scope of the project is to implement/roll out and end-to-end CA and eSign Solution and would include installation and commissioning of Hardware, Network & Security components and all associated services as mentioned in the RFP. Bidder shall provide system integration services to procure and commission the required hardware, software etc. at RISL RSDC PR at Jaipur and Disaster Recovery Site at Jodhpur as part of deployment of CA Solution. Bidder shall be completely responsible for the installation, commissioning and testing of the necessary software licenses and hardware required to deploy the CA solution at the RSDC PR site and at the Disaster Recovery Site. Bidder shall ensure that support, maintenance, performance and uptime levels are compliant with SLAs.

4.3.19 Server, Standalone Tape and Tape Library Compute, Tape and Tape Library are to be implemented in zones as guided by RISL at the time of implementation. The entire infrastructure is though on a Hyper-converged infrastructure. Which shall have integrated virtualization and storage functionality. Tape backup systems are standalone for low storage capacity zones and Dual drive tape library for high capacity zones. These drives would be connected using SAS/FC to the physical backup host. The backup host will have required software to back up the entire environment which could comprise of File System, VM backup, DB Backup, etc.

4.3.20 Operating System/Licenses

The operating system supplied should be able to use Directory Services for Centralized as well as Zone Wise Authentication and Authorization mechanisms. The system should be able to create policies based on user groups, roles, levels, etc. and should be able to associates based on security, management, etc. on all servers / systems across the RSDC environment. It should be open LDAP v3 complaint for integration and interoperability, security and management. It should be able to enable centralized logon, in other words Single-Sign on, for all devices in the environment. All devices supplied should be compliant to be integrated with this Directory. The same directory will be able to cater to all Policy requirements of the Client workstations also, which will be installed for Raj eSign Platform day to day operations and management.

4.3.21 Database Server / Licenses Database servers are to be configured for replication from Primary to Disaster recovery with the minimum time configuration available in the Database Server Software. All three CA Database replication will be configured as instant replication while other databases will be configured for log shipping with the minimum allowable time to ship logs to the DR Site. The proposed database management system should be applicable to all systems across all devices of the data center. A single Database management system should be deployed across all components of the infrastructure. The system should be compatible with rights and policies flowing down from the centralized LDAP server. It should provide monitoring connect to the EMS system for detailed monitoring of all critical parameters of the Database. There will be different VM Clusters created, each with its own licenses and each cluster has multiple DB licenses. The DB can be licensed per VM or with a core count. Bidders have to make sure the product they quote should be able to move across physical Hosts in each respective Virtualized Cluster without any license restriction. The database should be licensed so that it can move around in the entire virtual environment on any physical server without any license restriction.


of 166

4.3.22 Backup and Recovery

The Backup and Recovery solution quoted should be in the leader’s position in the Gartner magic quadrant. The backup and recovery solution should have enterprise class features such as advanced snapshots, data archiving and replication. The solution should support the entire infrastructure platform components, viz. file systems, virtual, physical, storage, etc. with support for all the latest operating systems. The backup subsystems should be licensed by number of hosts, CPUs, VM, databases, etc. but not licensed on storage size. A Certifying Authority project requires a lot of audit logging and the storage requirements may escalate rapidly as soon as the eSign regime becomes mainstream. The backup solution will be operated from individual zones and each zone will have its own backup device as well as local storage. A separate physical host is allocated for the backup subsystem. An indicative list of the set of components/features that the backup software should support:

• Encryption • Backup Bandwidth Throttling • Support for online backup of applications like Database Servers, LDAP Server,

Live VM backup, etc. • Automated Scheduling of backups • Virtual machine backup / Virtual machine snapshots • Should have agents for all the operating systems, virtual machines, databases,

etc. which the bidder quotes • Independent Backup operations per zone as well as centralized console to

operate all backup with a common data centre policy • Bare Metal recovery, physical to physical, physical to virtual, virtual to physical • Should support granular restore options like complete VM, Databases, files,

folders, etc. • Should support all leading Standalone tape drives as well as tape libraries.


of 166

4.3.23 Business Continuity Solution A solution for automation and management of failover at DR is required. This solution should allow automated and manual override of failover to the DR. The system should enable workflow based management of DR automation. The systems should monitor and generate alerts on parameters related to Business Continuity and DR. The parameters like RTO, RPO, Database replication, replication status, etc. should be monitored and alerts to be generated based on any deviations. The solution should be a single dashboard to track the entire Business Continuity system. The system should be integrated with the LDAP solution provided by the Bidder. The system should provide automation for doing DR drills at predefined intervals.

4.3.24 Log Management A CA environment requires an immense amount of log collection, retrieval and storage. eSign requirements for logging are equally enormous. The software to be implemented should be a distributed log collection system where multiple independent log collectors can be configured to collect, store and forward to a central master log server. The software to be implemented at RISL is to be hierarchical by design where each zone will be operating a Log collect/store/forward system which will report / connect / operate to a defined master Log server. All logs finally accumulate at one Central Log Server which is in turn DB replicated to the DR Site. • Each zone to have separate Log servers configured to collect, store and forward

data to the Central Log server • Each zone would require a separate Database for zone wise log collection • The Central Log server is replicated via the DB replication method to the DR Site. • In case of the Central Server failure, the zone log collectors should be able to store

and retain logs for a minimum of four weeks • Once the Central Log Server is re-connected, the zone log collectors should

automatically push the logs to the Central Servers. • Log servers should be able to query logs from the entire database at any time. • The Central Log server should be capable to push logs before a user defined

interval to a separate but active database. Automated Archival rules / plans should be user configurable.

• User Configurable with real time alerts based on syslog message. • User configurable to trigger alerts, run scripts, log to a separate system, generate

SNMP trap, forward messages based on syslog messages. • The log servers should support all features via web based administration panel. • Automated, prescheduled, template based report generation on a periodic basis • Reporting / Analysis / Web Based Admin / user interface for all log servers.

4.3.25 Enterprise Management System This is a centralized system and an important requirement of the project. The solution should have an integrated dashboard providing a single view of all the assets / components / issues related with the functioning of all individual components of the entire Raj eSign Platform infrastructure. This should also have an integrated Service Desk as well as an SLA monitoring, management and reporting tool. The software to be implemented at RISL is to be hierarchical by design where each zone will be operating a software which will report / connect / operate to a defined master server. An indicative list of the set of components/features:

• Asset Management • Network Performance Monitoring • System Performance Monitoring • Website Performance Monitoring • Application performance Monitoring • Virtualization Performance Monitoring


of 166

• Helpdesk / Service Desk • SLA and Contract Management • Should support SNMP OID import / customization • Integrated Solution • User definable Reporting

4.3.26 Network Solution

All zones have two pairs of L2 switches and one pair of UTM/NGFW. One pair of switches connect to the servers as a Virtualization backbone. The other pair of switch is used for network communication. UTM/NGFW is used to connect the zone to the next available zone. Hyperconverged solution require L2/L3 access switches having 10Gpbs port and 1Gbps support. Each hyperconverged node will be requiring minimum 2no. 10Gbps (Production and Internal Network Traffic) and 1no. of 1Gbps ( Management ) for per node. Per Node is scalable to have 4No. 10Gbps Ports There are four components of the Network:

• Dual Gateway routers which connects the external world. • Dual Enterprise UTMs at the Gateway • Dual L3 type gateway switch both at PR and DR. • Dual L2 type switches in for connecting internal zones • Dual UTMs between each zone

4.3.27 NPL Receiver

The Time Stamping Service uses time values in the time-stamp token, which are traceable to a Standard Time Source in India. National Physical Laboratory, India (NPLI) is the national time keeper and is responsible for maintenance of Indian Standard Time (IST). NPLI maintains the time scale of IST with the help of a commercial cesium atomic clock. The dissemination of IST is done through VSAT link, telephone line or mobile network depending on the type of receiver. Bidder must ensure that the server clocks and all equipment related to the Raj eSign Platform project are in sync with IST provided by NPLI for the Time Stamping Service. The NPL approved time data receiver (two units) will be stationed at Primary site at Jaipur and one units at DR site. Bidder will be wholly responsible for procurement (Three units), maintenance and proper functioning of the overall time solution. All coordination with NPLI shall be taken care of by Bidder. Costs incurred whatsoever will be borne by Bidder. Each NPL device would require a telephone / mobile connection to the NPL HQ for acquiring the Time Information. To maintain accurate time information, the NPL device connects to the NPL server on a predetermined interval. The bidder is expected to factor in costs for a telephone / mobile connectivity which will be connected to these devices throughout the period of the contract.

4.3.28 EMS components The solution should provide for 24x7 monitoring and alerting system for all components of the Raj eSign Platform Infrastructure. The implementation should be a distributed implementation where each zone will have its own EMS log collector/storage/forwarder mechanism. All the EMS logs will finally be forwarded to the Central EMS system in the Monitoring zone. Bidder has to provide 24X7 monitoring &Alerting of the infrastructure. Solution should be consisting of hardware, software, operating system, database, online / offline storage etc. as per the technical specifications specified in the RFP. The security


of 166

solution for the CA & eSign services should be capable of working as a subset under the existing RISL Security Infrastructure. The software should be certified to work on the virtual environment that the bidder quotes. Bidder will be responsible for providing monitoring and alerting services. The functions required are as follows:

4.3.28.1 Monitoring: 24x7 Infrastructure monitoring and rule based alerting system

to identify unusual traffic coming into and leaving RISL eSign network as well

as identify usual and unusual internal-to-internal traffic, aggregated from

data collected from devices such as intrusion detection / prevention systems,

firewalls, routers, servers and all such devices.

4.3.28.2 Alert Notification: User definable rule based 24x7 notifications to multiple

RISL staff members based on calling trees which are dependent on the

criticality and service affected. Notifications will include nature of the event

in order to reduce the impact to the environment.

4.3.28.3 Ongoing Reporting: The bidder shall provide with a periodic report of all the

components of the infrastructure within the purview of RISL. These reports

include, but are not limited to, UTM attack patterns, Network performance,

Server and storage performance, etc.

4.3.29 Anti-Virus

An Enterprise grade Antivirus system has to be supplied. The Anti-Virus solution should have a centralized management console. This console should be able to manage and monitor the entire hierarchy of Antivirus related components. The centralized management system will also handle reporting, policy management, Application management, AV Server deployment control, etc. The software to be implemented at RSDC is to be in distributed manner where each zone will be operating an AV Server software which will report / connect / operate to a defined master server. All components of the software should be certified to operate as a Virtual Machine. An indicative list of the set of components/features:

• Antivirus / Antimalware /Anti-Spam / Anti Phishing • Host based Intrusion Prevention System • Anti-virus for servers and endpoints • HTTP / Web Filtering • Policy based management • Comprehensive Reporting and logging

4.3.30 UTM/NGFW

NGFW/UTM to be deployed between each zone of the environment. Each zone is separated by a pair of UTMs. The device implemented at the Gateway would require more hits, the capacity of that particular device pair would be higher than the inter zone devices. UTM appliance should have the following:

Administration, Authentication & General Configuration Multiple ISP Load Balancing And Failover High Availability Firewall Intrusion Prevention System Gateway Anti-Virus Web Filtering Solution VPN


of 166

Logging And Reporting Application Filtering Solution Web Application Firewall Comprehensive UTM management dashboard to manage all UTMs from a

single pane of glass

4.3.31 Patch Management Patch management reduces the ongoing and upcoming risks to an IT infrastructure by patching vulnerabilities as well as improves performance due to enhancements provided by the OEMs via such patches and updates from time to time. Maintaining a healthy patch management cycle requires a mix of automated and manual approach. The bidder shall implement an automated patch management system for patching majority of the systems in the environment. Many systems, components and procedures do not have the option of an automated system. For e.g. HSM updates, firmware updates, patching storage systems, Network switch updates, firewall/ UTM updates, etc. As these components cannot be automatically patched / updated the bidder will have to maintain a periodic schedule of no longer than 15 days to carry out a manual patch / firmware / update search for the complete infrastructure in the RSDC environment. All patches, including automated patches, will have to be applied and tested in the test environment under the same configuration as the production systems before implementing them, before any patch is installed, a backup of data and server configuration information must be made. The patch management should be executed efficiently for all kinds of software such as Windows and Linux and Data bases like DB2, PostgreSQL, MS SQL, Oracle, My SQL, different virtualization Platforms, as well as all hardware such as Firmware / BIOS version updates for Servers, Switches, UTM, Firewalls, Storage, etc. The Bidder shall make a provision for offline update of the systems in the internal LAN.

4.3.32 Reporting Bidder shall be preparing and submitting the daily, weekly, monthly and quarterly reports along with the MIS adhering to the SLAs as mentioned in “Service Level Agreement”. Bidder shall provide the MIS reports for all the devices installed in RISL PR & DR Site in a prescribed format and media as mutually agreed with RISL on a weekly / Monthly / Quarterly & Annual basis. Whenever required, bidder should be able to provide additional reports in a pre-specified format.

The following is an indicative list of Monthly / Quarterly MIS reports/ documents which shall be submitted by the successful Bidder: • IMAC (Install, Move, Add, Change) Report. • Availability of different category of equipment • SLA Reports • Exception report indicating all calls completed beyond SLA, with calculation of

non- performance deduction. • Report on planned Preventive Maintenance schedules • Uptime Report and Utilization Report of Equipment’s. • Intrusion detection report. • Periodic Internal Vulnerability Assessment & Penetration Testing Reports • Patch release update report(s) • Any other report as desired by RISL will also be provided by Bidder as and when


of 166

required.

4.3.33 Development of documentation Bidder shall develop the operating procedures for Certificate Lifecycle Management and eSign services in consultation with RISL and applicable policies, guidelines and regulations. Bidder would provide documentation for all activities, hardware/software, policies and procedures of carrying out all activities within the RSDC infrastructure. This documentation should be submitted as the project undergoes various stages of implementation. Bidder shall have to create Certificate Policy & Certification Practice Statement document (for the CPS structure sample document &RISL policy shall be provided by RISL). The CPS must describe how logical and physical access to the PKI and data is restricted to authorized individuals, how the continuity of key and certificate management operations is maintained, and how CAs development, maintenance and operations are properly authorized and performed to maintain PKI integrity and controls Regulatory requirements for operating a CA require lot of processes which are audited by the regulator on a periodic and ongoing basis. The maintenance of these processes and audits require a fairly large number of documentation. The Bidder is responsible to develop and maintain all such documents for RISL including, but not limited to the following: PKI policy/CPS Security policy for Raj eSign Platform Asset management Personnel security Raj eSign Platform Operations standard operating procedure(SOP) Raj eSign Platform systems development and maintenance manual Business continuity management Monitoring and compliance Auditing Data Archiving Policy Backup Policy Indicative list of documents includes: 4.3.33.1 Project plan with detailed WBS including activities with milestones,

dependencies and deadlines. 4.3.33.2 Original manuals and CDs from OEMs. 4.3.33.3 Training material which will include the presentations used for trainings

and also related white papers of the topics. 4.3.33.4 Process documentation related to the operation and maintenance of each

and every component of the CA Operations after being formally signed off by RISL, before completion of final acceptance test.

4.3.33.5 Documentation of all the installation and commissioning procedures to be provided within one week of the commissioning of CA Solution along with final configuration dumps and implemented solution details.

4.3.33.6 Device configuration procedure and configuration files backup procedure so as to enable quick recovery in case of failure of devices.

4.3.33.7 The above documentation is a prerequisite for audit by the regulator.


of 166

4.3.34 Audit Regulatory audit of Raj eSign infrastructure will be a continuous process as stipulated by the CCA. To be able to remain compliant to the regulatory audits, the bidder will ensure a periodic audit of the infrastructure on a quarterly basis in coordination with the RISL Team. This audit shall include all areas stipulated by the regulator, including but not limited to, VAPT, Network security, catalogue existing security policies and control and examine risks for IT assets including physical security. An indicative list of outcomes from the periodic Audit:

4.3.34.1 IT infrastructure vulnerability scanning 4.3.34.2 Web application scanning 4.3.34.3 Remediation and reporting 4.3.34.4 Policy compliance This service will help RISL to centrally assess and mitigate the security risks in its network, servers & devices on a continuous basis.

4.4 Other Services Related to the Project 4.4.1 Project Management & providing related services to RISL

The complete implementation and rollout shall be carried out under direct project management by Bidder. Project Management shall include

Project Plan with timeline Major milestones Risk Factors Escalation matrix Dependencies and pre-requisites Resource management Site readiness tracking and follow-ups Change management Installation and successful deployment at RISL PR & DR site.

Bidder shall provide architectural diagram, as-built documents along with sizing of infrastructure and all required infrastructure.

4.4.2 Customization & Integration

Bidder shall customize and Integrate different products being procured under this RFP as per Raj eSign Platform. Applications and modules which are not part of a standard offering of an OEM and not certified by the Principal OEM, in writing, as a readymade product offering shall be considered as developed exclusively for Raj eSign Platform. In such cases such applications and modules shall be considered as specifically developed for the purpose of this project. All documentation pertaining to such applications and modules along with the entire SDLC Lifecycle and source code shall be provided to RISL. The source code will be the sole property of RISL and should be versioned, labeled and base lined appropriately.

4.4.3 Supply of Crypto Token

Crypto Tokens shall be supplied at local RA location as provided by RISL.

4.4.4 Testing Before the deployment of the CA solution, Bidder will perform its Functional Testing, Performance Testing, Acceptance Testing, Security audit- and load testing. The different testing tools and equipment’s required for this testing are to be taken care by Bidder. The performance should be equal to or more than the SLA requirements.

4.4.5 Technical Support


of 166

Bidder will provide 24X7 technical Support to RISL. In addition to providing on-site manpower as asked for in the RFP, Bidder should also have telephonic support as well as on-call onsite support for all kinds of issues/problems including DSC/eSign subscriber related issues. Bidder should also highlight the Support capabilities in India and the escalation matrix.

4.4.6 Regulatory requirements

Bidder shall also provision for following periodic audits: • Bidder shall get the CA operations audited annually by a CCA empanelled

auditor and such audit shall include security policy and planning, physical security, technology evaluation, CA's services administration, compliance to CPS, contracts/agreements, regulation prescribed by CCA, policy requirement of CA Rules, 2000 and amendments thereof.

• Bidder shall facilitate the internal audit of CA operations, half yearly internal audit of security policy, physical security and planning of its operation.

4.4.7 Training

Bidder is expected to provide training to the identified RISL team on the services and product architecture, functionality and the solution design. 4.4.7.1 Pre-Implementation: Provide training to the identified participating RISL

personnel on the service and product architecture, functionality and the design for each solution under the scope of this RFP.

4.4.7.2 Post Implementation: Bidder and OEM are required to provide hands-on training to the participating RISL personnel on managing day to day operations, handling emergency scenarios, alert monitoring and policy configuration for all solutions.

4.4.7.3 Bidder is required to provide all trainees with detailed training material. This training material should cover installation, operation, integration, maintenance, troubleshooting and other necessary areas for each solution.

4.4.7.4 Key personnel of the Raj eSign CA Team shall be provided training for the respective products from the OEM and shall be OEM Product Certified. All personnel are to be OEM certified on the CA product Suite.

4.5 Key Recourses

Bidder is expected to provide technical and operational support for Raj eSign Platform for the agreed duration of Operation and maintenance phase. Bidder is required to provide minimum resource persons as mentioned in the RFP. An indicative list of activities to be performed by various resources is also specified. Should the assignment require any travel (such as for carrying out DR operations) by any Bidders personnel outside their respective base location, Bidder should factor the same in their Bid as RISL will not provide Out of Pocket Expenses (To-and-fro airfare, boarding-and-lodging expenses, as well as local transportation for all such travels) for maintaining SLA’s & running CA operations / services agreed, carrying business as usual & managing disaster site & operations. An indicative list of activities to be performed by deployed resources for existing system support is: Project Manager who shall be the SPoC to RISL for the implementation of the project. The team deployed by bidder shall function based on the scope of work of the RFP and

contract signed between bidder &RISL. Qualification and experience requirements of these resource persons are mentioned in the

RFP. Bidder will ensure that all the resources deployed at any location are easily approachable

over mobile phones. Bidder will provide the contact details of the manpower at the time of commencement of operations. Bidder will also ensure that the proposed resources will


of 166

not be changed during project implementation without explicit approval of RISL. RISL reserves the right to evaluate the performance of the resource persons deployed on

the project by bidder and ask for a suitable replacement in case of unsatisfactory performance by any of the resource persons deployed to support the project. 4.5.1 Required Manpower with Skills and Experience:

S.No. Contractor’s Manpower PR DR

1. Project Manager 1 2. Monitoring Engineer: PKI Operations 3 2 3. Engineer PKI Solution 3 4. Systems Engineer 1 1 5. Website Maintenance 1 6. Operations Server/Storage/Network & Security L1 3 7. Helpdesk (Two Shifts) 4 8. Office Assistance 2 1

Total 18 4

4.5.1.1 Project Manager (S.No.1)

Description Project Manager Total Location Jaipur 1(One) 1 Skills, Requirements

B.E. /B.Tech/MCA. Total 10 Years of experience out of which, minimum 3

years’ experience in CA & PKI services Solution administration & management

Certification such as CISA/CEH/CISSP/CISM/CRISC. Minimum two years ‘experience with current

employer Certified from OEM’s product certification scheme Certification in PMP/PRINCE2 preferred

4.5.1.2 CA/PKI Skilled Manpower Requirement (S.No.2)

Description CA Solution Support Engineers (24x7x365 operations)

Total

Location Jaipur & at DR Site

3 (1 per shift) at RSDC, Jaipur 2 at DRsite.

5

Skills, Requirements

B.E./B.Tech/MCA. Minimum of three years’ experience in CA/PKI

services Solution administration & management, with at least one person at PR site with 5 3 years of experience.

Experience in Indian environment will get more points

Must be OEM certified.

4.5.1.3 Operations Monitoring Skilled Manpower Requirement (S.No.6) Description Support Engineers Total Jaipur/__ Location

3(PR)/1(DR) 4 3


of 166

Skills, Requirements

B.E. /B.Tech/ MCA. Minimum of three years’ experience in services

related to security device administration & management.

Minimum 2 year experience of specific security device.

OEM Certification preferred.

Role 1. 24X7 monitoring basis with onsite personnel. 2. At PR Site four engineers and two engineers at DR site 3. Reporting of operational problems, security alerts

&Incidents. 4. At least one resource with experience on storage

solution offered 5. Detecting internal and external attacks on Raj eSign

infrastructure. 6. Capturing data from all devices on real-time basis. 7. Providing security reports to RISL on daily, weekly,

monthly, quarterly and yearly basis.

4.5.2 Terms and Conditions for Manpower Required

Bidder is not only expected to provide the numbers asked for, he must ensure that the manpower provided has the requisite skills. It is further expected that:

a. The technical manpower provided will have at least a technical degree like B.Tech., BE or MCA or Technical Diploma or Certified in respective field.

b. The L1engineers will have minimum three years of relevant experience and L2engineers are expected to have minimum 5 years of experience.

c. The selected engineers may preferably be certified by the OEM for the products for which he is expected to provide support.

d. Before selecting the engineers/manpower for deployment, the bidder must study the requirements given in the section “The Activities to be carried out by the Bidder’s Personnel”. This will help him select the most suitable candidates. In addition to these requirements, the engineers must have experience and technical skills in the following areas: Networking: including network security, switches, routers, firewalls, UTM

devices, antivirus technologies, IPS, IDS etc. Systems: Thorough grounding in operating systems like Windows, Linux Servers: Servers Configurations, Virtualisation technologies Hyper-converged and Backup Devices Knowledge and working experience of operations of the above mentioned

devices and equipment, exposure to commonly occurring problems and troubleshooting techniques

Sufficient and relevant work experience with online technologies and mission critical applications. They are expected to be exposed to systems and network monitoring tools.

Good exposure to different techniques like load balancing, debugging, OS hardening, replication techniques, DB optimisation techniques as relevant to the quoted products etc.

The resources are required to have exposure to common internet attacks and security breaches and their mitigation techniques.

The selected engineers may preferably have work experience under situations where formal security policy and procedures exist.

The OEM certified resources will be preferred for each functional area. The helpdesk resources required must have sufficient experience of

handling helpdesk requirements of the nature of this project. Out of the four


of 166

people required two must have minimum experience of 4 years in similar functions. The balance 2 may have minimum two years of experience.

4.5.3 Activities to be carried out by Bidder’s personnel for IT Operations

The selected bidder will provide 24x7x365 operating and maintaining services for a period of 5 years from the date of final acceptance test. The scope of the services as per ITIL framework during this period and shall include 24x7x365 Monitoring, Maintenance and Management of the entire Raj eSign Infrastructure, along with providing Helpdesk services. The scope of work during the operations phase is divided into following are as which are listed below: • System Administration, Maintenance and Management Services • Network Management Services including Security Incident Lifecycle

Management • Server and Storage Administration and Management Services • Security Administration and Management Services • Physical security services • Backup & Restore Services • Physical Infrastructure Management and Maintenance Services • Helpdesk Services • Database Management • Preventive Maintenance Services • Corrective Maintenance Services • Asset Management Services • Configuration/Reconfiguration Management Services • OEM Management Services • Security Incident Lifecycle Management • Patch management 4.5.3.1 System Administration, Maintenance & Management services

The objective of this service is to efficiently and effectively support and maintain all the Systems, Servers and equipment provided as a part of this RFP, and will include: • 24x7x365 monitoring and management of Hyper-converged

infrastructure in the Raj eSign Infrastructure. • Operating System administration, including but not limited to

management of users, processes, preventive maintenance and management of servers including updates and patches to ensure that the system is properly updated at any given time.

• Installation and Re-installation of the server hardware in the event of system crash/ failures.

• Regular analysis of events and logs generated in all the sub-systems including but not limited to servers, operating systems, security devices, etc. to identify vulnerabilities. Action shall be taken in accordance with the results of the log analysis.

• Adoption of policies as defined by RISL and conforming to standards wherever applicable.

• Provide integration and user support on all supported servers and data storage systems.

• Troubleshoot problems with overall aspects of IT & security equipment and Infrastructure. Problems shall be logged in at the Helpdesk and resolved as per the SLAs defined in this document.

• Manage and monitor server configuration, steady performance and activity of all servers

• Document for all equipment/ components configurations. • OS Hardening to address security weaknesses in operation

systems by implementing the latest OS and application patches,


of 166

hot fixes and updates and following procedures and policies to reduce attacks and system downtime.

4.5.3.2 Network Management Services including Security Incident Lifecycle Management The objective of this service is to ensure continuous operation and security of the Raj eSign infrastructure at Primary & DR sites. The scope excludes maintenance of WAN links, which shall be provisioned by RISL. However, for overall functioning of the Raj eSign, the selected bidder shall be responsible to coordinate with RISL team for WAN link related issues. The services to be provided for Network Management include: • Ensuring that the network is steady andavailable24x7x365 as per

the prescribed SLAs. • Attending to and resolving network failures and snags. • Attending to and resolving network security incidents. • Support and maintain the overall network infrastructure Security

Components, Switches etc. • Configuration and backup of network & security devices including

documentation of all configurations. • 24x7x365 monitoring of the network to spot the problems

immediately. • Installation and Re-installation of the network devices in the

event of crash/ failures. • Tuning of various parameters to optimize performance and to

ensure industry standard QoS with customization is being delivered.

4.5.3.3 Backend Services The selected bidder is required to maintain and support all the Backend Services implemented at Raj eSign. The backend services include Directory Services for Raj eSign which comprises of the following services: • Domain management • Group management • User management • Implementation of domain policies and standards etc. Note: Directory services are to be used within Raj eSign only.

4.5.3.4 Hyper-converged Infrastructure Administration and Management Services The bidder shall be responsible for the management of the Hyper-converged solution and shall provide the following services: • Identify key resources in the Hyper-converged solution • Identify interconnects between key resources in the solution • Receive notification that the configuration of the solution has

changed • Identify the health of key resources in the solution • Identify the available performance of interconnects in the solution • Receive notification that the performance of the interconnect

solution has changed • Identify the zones being enforced in the solution • Create/ delete and enable/disable zones in the solution • Identify the storage volumes in the solution • Create/ delete/modify storage volumes in the solution • Identify the connectivity and access rights to Storage Volumes in

the solution • Create/delete and enable/disable connectivity and access rights


of 166

to Volumes in the solution • Hyper-converged administration-facilitates the UT

Administration in connecting to the solution later and gives them access rights as required.

4.5.3.5 Security Administration and Management Services The objective of this service is to provide a secure environment through the implementation of the security policy (to be laid down by RISL with the assistance from the Bidder).This service includes: • Addressing the on-going needs of security management including,

but not limited to, monitoring of various devices/ tools such as firewall, IPS/IDS, content filtering and blocking, virus protection spam protection and vulnerability protection through implementation of proper patches and rules.

• Maintaining an updated knowledge base of all the published security vulnerabilities and virus threats for related software and microcode etc.

• Ensuring that latest patches/ work around for identified vulnerabilities are applied immediately.

• Preventing & responding to security breaches or other security incidents and coordinate with respective OEM in case a new threat is observed to ensure that work around/ patch is made available for the same.

• Maintenance and management of security devices, including, but not limited to maintaining firewall services to restrict network protocols and traffic, detecting intrusions or unauthorized access to networks, systems, services, applications or data, protecting data, email, gateways, firewalls, servers, from viruses.

• Ensuring that the security policy is maintained and updates to the same are made regularly as per ISO270001, BS7799 andBS15000 guidelines.

• Compliance of security regulations defined by GoI or any other Govt. Authorized agency such as CERT-IN etc.

4.5.3.6 Backup and Restore Services • Backup of storage as per the defined policies (to be framed by RISL

with assistance from the bidder). • Monitoring and enhancing the performance of scheduled backups,

Schedule regular testing of backups and ensuring adherence to related retention policies as defined by RISL.

• Prompt execution of on-demand backups of volumes and files whenever required or in case of upgrades and configuration changes to the system.

• Real-time monitoring, log maintenance and reporting of backup status on a regular basis.

• Media management tasks, including, but not limited to, tagging, cross-referencing, storing, logging, testing, and vaulting in fire proof cabinets(onsite).

• 24x7x365supportsfor file and volume restoration requests at the Primary Site & DR Site.

• All consumables in terms of Tapes/ Ink cartridges etc. needs to be provided by the bidder in line with backup and data retention policy.

4.5.3.7 Helpdesk Services The help desk service will serve as a single point of contact for all ICT related incidents and service requests. The service will provide a


of 166

Single Point of Contact (SPoC) and also resolution of incidents. The scope of work includes: • 24x7x365 Helpdesk facility for reporting issues/ problems with

the IT infrastructure. • To provide a service desk facility and setup all necessary channels

for reporting issues to helpdesk. The incident reporting channels will be the following:

• Specific E-Mail account • Dedicated Phone Numbers • Fax • To implement a call logging system in line with the severity levels

as mentioned in the SLA. • The Helpdesk shall undertake the following activities: • Log issues/complaints related to IT infrastructure at the Raj eSign

under the scope of work and issue an ID number against the issue /complaint.

• Assign severity level to each issue /complaint. • Track each issue /complaint to resolution. • Escalate the issues/ complaints, to Raj eSign, if necessary, as per

the escalation matrix defined in discussion with Raj eSign. • Provide feedback to the callers. • Analyse the issue/complaint statistics • Creation of knowledgebase on frequently asked questions to aid

the users of the IT infrastructure. • Provisioning of requisite number of Help Desk software licenses

for operating the Helpdesk facilities. 4.5.3.8 Preventive Maintenance Services

• Conduct preventive maintenance every month or as directed by RISL (including inspection, testing, satisfactory execution of diagnostics and necessary repairing of the equipment).

• Preventive Maintenance Activities of components as per their manufactures’ recommendation/advice.

• The Preventive Maintenance shall be carried out in Non-Prime Hours only under intimation to RISL.

4.5.3.9 Corrective Maintenance Services • Warranty and maintenance/ troubleshooting of hardware

problem of all supplied IT Infrastructure including network & security equipment’s etc. and rectification of the same.

• Troubleshooting of problems arising in the network and resolving the same.

• Documentation of problems, isolation, cause and rectification procedures for building knowledgebase for the known problems.

4.5.3.10 Asset Management Services • Bidder shall be required to create database of all the equipment/

software procured/ Installed under Raj eSign Project. The details of all assets like hardware, software, peripherals, manuals, media and other

• Related peripherals, etc., shall be maintained by recording information like make, model, configuration details, serial numbers ,licensing agreements, warranty, place of installation etc.

• Record installation and removal of any equipment from the Raj eSign network and inform RISL even if it is temporary.

• Create Software details with information such as Licenses, Version Numbers and Registration Details.

• Perform software license management, notify RISL on licensing


of 166

contract renewal and assist them in getting the license renewed. 4.5.3.11 Configuration/Reconfiguration Management Services

The selected bidder shall maintain complete configuration including reconfiguration at no cost (on demand)(in hardcopy& softcopy) for all equipment • The selected bidder shall do proper version management of these

configurations as they are bound to change from time to time. • These configurations shallot be accessible in general and must be

kept confidential. 4.5.3.12 Coordination with OEM

• The selected bidder shall coordinate with all the OEM’s for upkeep of equipment deployed in the Primary Site to meet the SLA and shall liaison with various vendors/ OEMS/ Suppliers/ Contractors for related works, equipment &Services.

• The selected bidder shall, if required, escalate and log calls with different OEM’s and internet service providers and coordinate with them to get the problems resolved.

4.5.4 Initial Composition, Fulltime Obligation; Continuity of Personnel

1. Bidder shall ensure that each member of the Key Personnel devotes substantial working time to perform the services to which that person has been assigned as per the proposal.

2. Bidder shall not make any changes to the composition of the Key Personnel and not require or request any member of the Key Personnel to cease or reduce his or her involvement in the provision of the Services during the Term(or agree to any request other than from RISL that would have the same effect): a) Unless that person resigns, is terminated for cause, dies, is long-term

disabled, is on permitted mandatory leave under Applicable Law or retires; and

b) Without RISL's prior written consent. The clauses of non-disclosure agreement shall always operate in any such case.

4.5.5 Replacement of Resource Personnel

4.5.5.1 In case the resource has resigned, then Bidder has to inform RISL within one week of such resignation.

4.5.5.2 Bidder shall promptly initiate a search for replacement and use commercially reasonable efforts (including the expenditure of reasonable sums, such as to engage the services of a recruiting firm)to ensure that the role of any member of the key personnel is not vacant.

4.5.5.3 Before assigning any replacement member of the key personnel to the provision of the Services, bidder shall provide RISL with:

4.5.5.4 A resume, curriculum vitae and any other information about the candidate thatis reasonably requested by RISL; and

4.5.5.5 An opportunity to interview the candidate. 4.5.5.6 Bidder has to provide replacement resource, who scores at least

the same marks as the resource proposed originally on the same evaluation parameters defined in this RFP document.

4.5.5.7 Bidder has to ensure atleast4 weeks of overlap period in such replacements.

If in the first 6month period from the Contract Effective Date or in any rolling 12months period during the Term, 15 percent or more of the members of the Key Personnel cease or reduce their involvement in the Services for any reason other than with RISL's prior written consent, bidder shall:


of 166

• Provide RISL with a reasonably detailed explanation as to the reasons for such change, I including, where applicable and permitted, notes from any exit interviews conducted by bidder with any departing member of the key personnel; and

• If such change to key personnel has or is likely to have any material adverse impact on the provision of the Services or any substantial part thereof, undertake, at its own costs, such remediation acts as are reasonably necessary in order to improve the retention of the Key Personnel including making reasonable changes to the human resources policies and procedures applicable to the Key Personnel (including those related to compensation, benefits and other conditions so that they are competitive with the market)as may be necessary to ensure that such policies and procedures comply with best industry practice.

4.6 Deliverables, Timelines and Payment

S.

No. Task Activity

Time period

Deliverables Payment

1.

Team Mobilization, Preparation of Project Plan, Kick-off meeting

Delivery of e-Sign/Digital Certificate Life Cycle Management (CA) and other S/W Licenses along with all the Hardware, networking & Security Components

Installation and commissioning of complete CA Solution (Digital Certificate Life Cycle Management Solution, e-Sign solution, OCSP Solution, Time Stamping Solution).

Data Centre and DR Site readiness

Submission of Detailed Project Plan

T0 + 15 Weeks

1. Submission of Detailed Project Plan with manpower details.

2. Submission of Organization chart showing the proposed organization/ manpower along with Escalation Matrix

3. Submission of Standard Operating Procedures (SOP) &Exit Management Plan.

4. Delivery challans and acceptance reports for all hardware/ software

5. Generation of test certificates, Demonstration of functionalities of each subsystem of the infrastructure.

6. Completion of CPS and Security Policy

7. Completion of DC and DR non IT infrastructure components

8. Submission of application to the CCA office for the audit of infrastructure

Delivery of CA Solution Components Deployment of CA Project / Solution Resources at RISL’s premises Delivery of Servers and all other IT Components Installation & Configuration of Servers and all other IT Components Installation & Configuration of CA Lifecycle Management Solution Installation & Configuration of Time Stamping Solution Installation & Configuration of OCSP Solution

Installation and Configuration of eSign


of 166

with complete documentation

85% of CAPEX NOTE: Bidder will be penalized for delay due to any discrepancy or deficiency on his part in the deliverables encountered during CCA pre- operations audit.

2.

Complete readiness of the CA and eSign

Go Live and Final Acceptance

30 days from the date of publishing of the first certificate under the CCA Root

Audit Ready Go Live of CA Certificate Life Cycle Management Solution

T0 + 25 Weeks

1. Audit Report by CCA empanelled Auditor

2. CCA License for CA and eSign

3. Final Acceptance Certificate

4. Submission of As-Built Documentation

5. Completion of Training as per the RFP

Audit Ready Go Live of OCSP Solution Audit Ready Go Live of Time Stamping Solution Audit Ready Go Live of eSign UAT of integrated CA Life Cycle, TSA, OCSP, eSign and Network & Security components Pre audit by CCA empanelled auditor before this point

CCA Audit As per CCA

RISL CA Project Go Live

As per CCA

3. O and M Charges Maintenance report

Quarterly, from the date of RISL CA Project Go Live

All maintenance and SLA report

5% of OPEX AND 0.75% of CAPEX per Quarter for 20 quarters, i.e. 5 Years

Capex Cost of equipment, installation, testing, commissioning (All costs

related to implementation of solution till Go Live) Opex Cost of, Operations & Maintenance & Services support(including

ATS, AMC & Manpower charges) for Year 1+ Year 2 + Year 3 + Year 4 + Year 5

Total Cost of Project Capex + Opex Note: All diagrams and the BoQ presented above are indicative and may change during actual implementation.


of 166

5. INSTRUCTION TO BIDDERS (ITB) 1) Sale of Bidding/ Tender Documents

a) The sale of bidding documents shall be commenced from the date of publication of Notice Inviting Bids (NIB) and shall be stopped one day prior to the date of opening of Bid. The complete bidding document shall also be placed on the State Public Procurement Portal and e-Procurement portal. The prospective bidders shall be permitted to download the bidding document from the websites and pay its price while submitting the Bid to the procuring entity.

b) The bidding documents shall be made available to any prospective bidder who pays the price for it in cash or by bank demand draft, banker's cheque.

c) Bidding documents purchased by Principal of any concern may be used by its authorised sole selling agents/ marketing agents/ distributors/ sub-distributors and authorised dealers or vice versa.

2) Pre-bid Meeting/ Clarifications

a) Any prospective bidder may, in writing, seek clarifications from the procuring entity in respect of the bidding documents.

b) A pre-bid conference is also scheduled by the procuring entity as per the details mentioned in the NIB and to clarify doubts of potential bidders in respect of the procurement and the records of such conference shall be intimated to all bidders and where applicable, shall be published on the respective websites.

c) The period within which the bidders may seek clarifications under (a) above and the period within which the procuring entity shall respond to such requests for clarifications shall be as under: -

a. Last date of submitting clarifications requests by the bidder:as per NIB b. Response to clarifications by procuring entity: as per NIB

d) The minutes and response, if any, shall be provided promptly to all bidders to which the procuring entity provided the bidding documents, so as to enable those bidders to take minutes into account in preparing their bids, and shall be published on the respective websites.

3) Changes in the Bidding Document

a) At any time, prior to the deadline for submission of Bids, the procuring entity may for any reason, whether on its own initiative or as a result of a request for clarification by a bidder, modify the bidding documents by issuing an addendum in accordance with the provisions below.

b) In case, any modification is made to the bidding document or any clarification is issued which materially affects the terms contained in the bidding document, the procuring entity shall publish such modification or clarification in the same manner as the publication of the initial bidding document.

c) In case, a clarification or modification is issued to the bidding document, the procuring entity may, prior to the last date for submission of Bids, extend such time limit in order to allow the bidders sufficient time to take into account the clarification or modification, as the case may be, while submitting their Bids.

d) Any bidder, who has submitted his Bid in response to the original invitation, shall have the opportunity to modify or re-submit it, as the case may be, within the period of time originally allotted or such extended time as may be allowed for submission of Bids, when changes are made to the bidding document by the procuring entity: Provided that the Bid last submitted or the Bid as modified by the bidder shall be considered for evaluation.

4) Period of Validity of Bids

a) Bids submitted by the bidders shall remain valid during the period specified in the NIB/ bidding document. A Bid valid for a shorter period shall be rejected by the procuring entity as non-responsive Bid.


of 166

b) Prior to the expiry of the period of validity of Bids, the procuring entity, in exceptional circumstances, may request the bidders to extend the bid validity period for an additional specified period of time. A bidder may refuse the request and such refusal shall be treated as withdrawal of Bidand in such circumstances bid security shall not be forfeited.

c) Bidders that agree to an extension of the period of validity of their Bids shall extend or get extended the period of validity of bid securities submitted by them or submit new bid securities to cover the extended period of validity of their bids. A bidder whose bid security is not extended, or that has not submitted a new bid security, is considered to have refused the request to extend the period of validity of its Bid.

5) Format and Signing of Bids

a) Bidders must submit their bids online at e-Procurement portal i.e. http://eproc.rajasthan.gov.in. b) All the documents uploaded should be digitally signed with the DSC of authorized signatory. c) A Single Two part stage/ cover system shall be followed for the Bid: -

a. Technical Bid, including fee details, eligibility& technical documents b. Financial Bid

d) The technical bidshall consist of the following documents: -

S. No. Documents Type Document Format Fee Details

1. Bidding document Fee (Tender Fee) Proof of submission (PDF) 2. RISL Processing Fee (eProc) Instrument/ Proof of submission

(PDF) 3. Bid Security Instrument/ Proof of submission

(PDF) Eligibility Documents

4. Copy of valid Registration Certificates or Copy of Certificates of incorporation

Instrument/ Proof of submission (PDF)

5. CA Certificate with CA’s Registration Number/ Seal for Financial: Turnover from IT/ ITeS


6. CA Certificate with CA’s Registration Number/ Seal for Financial: Net worth


7. Bidder’s Authorisation Certificate along with copy of PoA/ Board resolution stating that Auth. Signatory can sign the bid/ contract on behalf of the firm.

As per Annexure-2 (PDF)

8. All the documents mentioned in the “Eligibility Criteria”, in support of the eligibility

As per the format mentioned against the respective eligibility criteria clause (PDF)

Technical Documents 9. Certificate of Conformity/ No Deviation As per Annexure-4 (PDF) 10. Declaration by Bidders As per Annexure-3 (PDF)

b) Financial bid shall include the following documents: -

S. No. Documents Type Document Format 1. Financial Bid – Covering Letter On bidder’s letter head duly signed

by authorized signatory as per Annexure-5 (PDF)

2. FinancialBid– Format As per BoQ (.XLS) format available on e-Procurementportal

http://eproc.rajasthan.gov.in/


of 166

c) The bidder should ensure that all the required documents, as mentioned in this bidding document, are submitted along with the Bid and in the prescribed format only. Non-submission of the required documents or submission of the documents in a different format/ contents may lead to the rejections of the Bid submitted by the bidder.

6) Cost & Language of Bidding a) The Bidder shall bear all costs associated with the preparation and submission of its Bid, and the

procuring entity shall not be responsible or liable for those costs, regardless of the conduct or outcome of the bidding process.

b) The Bid, as well as all correspondence and documents relating to the Bid exchanged by the Bidder and the procuring entity, shall be written only in English Language. Supporting documents and printed literature that are part of the Bid may be in another language provided they are accompanied by an accurate translation of the relevant passages in English/ Hindi language, in which case, for purposes of interpretation of the Bid, such translation shall govern.

7) Alternative/ Multiple Bids

Alternative/ MultipleBids shall not be considered at all. 8) Bid Security

Every bidder, if not exempted, participating in the procurement process will be required to furnish the bid security as specified in the NIB. a) In lieu of bid security, a bid securing declaration shall be taken from Departments of the State

Government, Undertakings, Corporations, Autonomous bodies, Registered Societies and Cooperative Societies which are owned or controlled or managed by the State Government and Government Undertakings of the Central Government.

b) Bid security instrument or cash receipt of bid security or a bid securing declaration shall necessarily accompany the technical bid.

c) Bid security of a bidder lying with the procuring entity in respect of other bids awaiting decision shall not be adjusted towards bid security for the fresh bids. The bid security originally deposited may, however, be taken into consideration in case bids are re-invited.

d) The bid security may be given in the form of a banker’s cheque or demand draft or bank guarantee, in specified format, of a scheduled bank. The bid security must remain valid thirty days beyond the original or extended validity period of the bid.

e) The issuer of the bid security and the confirmer, if any, of the bid security, as well as the form and terms of the bid security, must be acceptable to the procuring entity.

f) Prior to presenting a submission, a bidder may request the procuring entity to confirm the acceptability of proposed issuer of a bid security or of a proposed confirmer, if required. The procuring entity shall respond promptly to such a request.

g) The bank guarantee presented as bid security shall be got confirmed from the concerned issuing bank. However, the confirmation of the acceptability of a proposed issuer or of any proposed confirmer does not preclude the procuring entity from rejecting the bid security on the ground that the issuer or the confirmer, as the case may be, has become insolvent or has otherwise ceased to be creditworthy.

h) The bid security of unsuccessful bidders shall be refunded soon after final acceptance of successful bid and signing of Agreement and submitting performance security.

i) The Bid security taken from a bidder shall be forfeited, including the interest, if any, in the following cases, namely: - a. when the bidder withdraws or modifies its bid after opening of bids; b. when the bidder does not execute the agreement, if any, after placement of work order within the

specified period;


of 166

c. when the bidder fails to commence the delivery of service or execute work as per work order within the time specified;

d. when the bidder does not deposit the performance security within specified period after the work order is placed; and

e. if the bidder breaches any provision of code of integrity, prescribed for bidders, specified in the bidding document.

j) Notice will be given to the bidder with reasonable time before bid security deposited is forfeited. k) No interest shall be payable on the bid security. l) In case of the successful bidder, the amount of bid security may be adjusted in arriving at the amount

of the Performance Security, or refunded if the successful bidder furnishes the full amount of performance security.

m) The procuring entity shall promptly return the bid security after the earliest of the following events, namely:- a. the expiry of validity of bid security; b. the execution of agreement for procurement and performance security is furnished by the

successful bidder; c. the cancellation of the procurement process; or d. the withdrawal of bid prior to the deadline for presenting bids, unless the bidding documents

stipulate that no such withdrawal is permitted.

9) Deadline for the submission of Bids a) Bids shall be received online at e-Procurement portal and up to the time and date specified in the NIB. b) Normally, the date of submission and opening of Bids would not be extended. In exceptional

circumstances or when the bidding document are required to be substantially modified as a result of discussions in pre-bid meeting/ conference or otherwise and the time with the prospective bidders for preparation of Bids appears insufficient, the date may be extended by the procuring entity. In such case the publicity of extended time and date shall be given in the manner, as was given at the time of issuing the original NIB and shall also be placed on the State Public Procurement Portal, if applicable. It would be ensured that after issue of corrigendum, reasonable time is available to the bidders for preparation and submission of their Bids. The procuring entity shall also publish such modifications in the bidding document in the same manner as the publication of initial bidding document. If, in the office of the Bids receiving and opening authority, the last date of submission or opening of Bids is a non-working day, the Bids shall be received or opened on the next working day.

10) Withdrawal, Substitution, and Modification of Bids

a) If permitted on e-Procurementportal, a Bidder may withdraw its Bid or re-submit its Bid (technical and/ or financial cover) as per the instructions/ procedure mentioned at e-Procurementwebsite under the section "Bidder's Manual Kit".

b) Bids withdrawn shall not be opened and processes further.

11) Opening of Bids a) The Bids shall be opened by the bid opening & evaluation committee on the date and time mentioned

in the NIB in the presence of the bidders or their authorised representatives who choose to be present. b) The committee may co-opt experienced persons in the committee to conduct the process of Bid

opening. c) The committee shall prepare a list of the bidders or their representatives attending the opening of Bids

and obtain their signatures on the same. The list shall also contain the representative’s name and telephone number and corresponding bidders’ names and addresses. The authority letters, if any, brought by the representatives shall be attached to the list. The list shall be signed by all the members of Bid opening committee with date and time of opening of the Bids.


of 166

d) All the documents comprising of technical Bid/ cover shall be opened & downloaded from the e-Procurement website (only for the bidders who have submitted the prescribed fee(s) to RISL).

e) The committee shall conduct a preliminary scrutiny of the opened technical Bids to assess the prima-facie responsiveness and ensure that the: - a. bid is accompanied by bidding document fee, bid security or bid securing declaration, and

processing fee (if applicable); b. bid is valid for the period, specified in the bidding document; c. bid is unconditional and the bidder has agreed to give the required performance security; and d. other conditions, as specified in the bidding document are fulfilled. e. any other information which the committee may consider appropriate.

f) No Bid shall be rejected at the time of Bid opening except the Bids not accompanied with the proof of payment or instrument of the required price of bidding document, processing feeand bid security.

g) The Financial Bid cover shall be kept unopened and shall be opened later on the date and time intimated to the bidders who qualify in the evaluation of technical Bids.

12) Selection Method: Bidder would be selected on the basis of Least Cost Based Selection Method (LCBS) i.e. L1 method as specified in “Financial Evaluation Criteria” of clause titled “Evaluation & Tabulation of Financial Bids”, wherein an eligible bidder with adequate technical competence and the most competitive (lowest or L1) rates / quote would be selected for the implementation of the project based on NPV defined in RFP.

13) Clarification of Bids

a) To assist in the examination, evaluation, comparison and qualification of the Bids, the bid evaluation committee may, at its discretion, ask any bidder for a clarification regarding its Bid. The committee’s request for clarification and the response of the bidder shall be through the e-Procurement portal.

b) Any clarification submitted by a bidder with regard to its Bid that is not in response to a request by the committee shall not be considered.

c) No change in the prices or substance of the Bid shall be sought, offered, or permitted, except to confirm the correction of arithmetic errors discovered by the committee in the evaluation of the financial Bids.

d) No substantive change to qualification information or to a submission, including changes aimed at making an unqualified bidder, qualified or an unresponsive submission, responsive shall be sought, offered or permitted.

14) Evaluation & Tabulation of Technical Bids a) The bid evaluation committee will evaluate all bids and shortlist the bidders who have qualified as per

the eligibility criteria as laid down.

b) The objective of the Technical Bid evaluation is to short list bidders who have the technical

competency/ experience/ skills / financial strength that are essential to roll out the project.

c) Determination of Responsiveness a. The bid evaluation committee shall determine the responsiveness of a Bid on the basis of bidding

document and the provisions of pre-qualification/ eligibility criteria of the bidding document. b. A responsive Bid is one that meets the requirements of the bidding document without any material

deviation, reservation, or omission where: - i. “deviation” is a departure from the requirements specified in the bidding document;

ii. “reservation” is the setting of limiting conditions or withholding from complete acceptance of the requirements specified in the bidding document; and

iii. “Omission” is the failure to submit part or all of the information or documentation required in the bidding document.

c. A material deviation, reservation, or omission is one that,


of 166

i. if accepted, shall:- 1. affect in any substantial way the scope, quality, or performance of the subject matter of

procurement specified in the bidding documents; or 2. limits in any substantial way, inconsistent with the bidding documents, the procuring

entity’s rights or the bidder’s obligations under the proposed contract; or ii. if rectified, shall unfairly affect the competitive position of other bidders presenting responsive

Bids. d. The bid evaluation committee shall examine the technical aspects of the Bid in particular, to confirm

that all requirements of bidding document have been met without any material deviation, reservation or omission.

e. The procuring entity shall regard a Bid as responsive if it conforms to all requirements set out in the bidding document, or it contains minor deviations that do not materially alter or depart from the characteristics, terms, conditions and other requirements set out in the bidding document, or if it contains errors or oversights that can be corrected without touching on the substance of the Bid.

d) Non-material Non-conformities in Bids a. The bid evaluation committee may waive any non-conformities in the Bid that do not constitute a

material deviation, reservation or omission, the Bid shall be deemed to be substantially responsive. b. The bid evaluation committee may request the bidder to submit the necessary information or

document like audited statement of accounts/ CA Certificate, Registration Certificate, VAT/ CST clearance certificate, ISO/ CMMi Certificates, etc. within a reasonable period of time. Failure of the bidder to comply with the request may result in the rejection of its Bid.

c. Any document submitted by the bidder in response to the provision of subrule (b) should not belong to the period later than the technical bid opening date.

d. The bid evaluation committee may rectify non-material nonconformities or omissions on the basis of the information or documentation received from the bidder under (b) above.

e) Technical Evaluation Criteria Bids shall be evaluated based on the documents submitted as a part of technical bid. Technical bid shall

contain all the documents as asked in the clause “Format and Signing of Bids” and documents

mentioned in the table below for obtaining marks in the respective parameter.

S. No.

Technical Evaluation Parameter Supporting Document

Max Marks

1 Relevant Experience 30

1.1 Bidder’s Average Turn Over from IT / ITeS for the last three financial years (i.e. FY 2013-14, 2014-15 and 2015-16)

>=100 Cr : 5 Marks >=60 Cr and <100 Cr : 4 Marks >=25 Cr and < 60 Cr : 3 Marks

CA Certificate 5

1.2 Bidder’s experience in for core business functions implemented in the domain of Digital Signatures/DC/ DR of value more than Two Crore (Software, Hardware, Security, Development and Managed Services, Maintenance / Annual Maintenance Contract for Compute, Storage and Network Devices component) each during last 5 Financial Years during the period 01st Apr 2011 to 31st Mar 2016. >5 Projects: 5 Marks 3-5 Projects: 4 Marks 1-2 Project 3 Marks

Note: The maximum number of work orders which can be cited for this criteria of TQ is 10.

Project references as per Annexure-11 and Valid copy of Work Order and Completion certificate

5


of 166

1.3 Number of Professionals (Graduate/B. Tech /B.E / M. Tech / M.E. /MCAs/Diploma) on its own roll with at-least 10 CISSP/CISA certified employees as on date of release of RFP Out of 10 CISSP/CISA, 5 should be with organization since last 2 years. >=800 : 5 Marks >=650 and <800 : 4 Marks >=500 and <650 : 3 Marks

Undertaking declaring the number of Professionals (B.Tech/B.E/ M.Tech/M.E./MCAs/Diploma) And specifically Cyber Security Professionals (including category wise numbers) from head of HRD of Bidder.

5

1.4 Product Criteria All OEM whose product Bidder is quoting should be in Gartner’s Magic Quadrant for the following products: Server, Storage, Integrated Systems, Router, Switch, Firewall, UTM and Antivirus First 2 quadrants (Leaders and Challengers) : 10 Marks Any other quadrant : 0 Marks

Copy of Gartner latest Report.

10

1.5 All the OEM’s whose Hardware being quoted must have Certifications ISO 9001:2008 & ISO 14001:2004 : 5 marks Others : 0 marks

Certification details for each OEM

5

2 Technical Proposal, Presentation and Functional Demonstration

30

2.1 Presentation and Project Plan 1. The bidder would submit a detailed project plan understanding the scope, approach

and methodology, work plan and staffing schedule along with CVs of the proposed team as a part of the technical proposal which shall be reviewed by a committee designated by RISL.

a. Marking Criteria i. Scope – 2

ii. Methodology – 2 iii. Work Plan – 3 iv. Quality of CV – 3

10

2.2 The bidder would be intimated to deliver a presentation to showcase the eligibility for the project to a committee designated by RISL.

a. Marking Criteria i. Understanding of Project – 3

ii. Experience – 3 iii. Delivery – 4

10

2.3 The bidder would be intimated to be a part of Personal Interaction/Discussion wherein the following resources shall interact/discuss with RISL the project and other topics in detail: 1. Solution Expert 2. PKI Engineer/Developer 3. Architect 4. Network Engineer 5. DBA Each resource shall be marked individually.

a. Scale:

10


of 166

f) Tabulation of Technical Bids

a. If Technical Bids have been invited, they shall be tabulated by the bid evaluation committee in the form of a comparative statement to evaluate the qualification of the bidders against the criteria for qualification set out in the bidding document.

b. The members of bid evaluation committee shall give their recommendations below the table as to which of the bidders have been found to be qualified in evaluation of Technical Bids and sign it.

g) The number of firms qualified in technical evaluation, if less than three and it is considered necessary by the procuring entity to continue with the procurement process, reasons shall be recorded in writing and included in the record of the procurement proceedings.

h) The bidders who qualified in the technical evaluation shall be informed in writing about the date, time and place of opening of their financial Bids.

15) Evaluation & Tabulation of Financial Bids

Subject to the provisions of “Acceptance of Successful Bid and Award of Contract” below, the procuring entity shall take following actions for evaluation of financial Bids:- a) The financial Bids of the bidders who qualified in technical evaluation shall be opened online at the

notified time, date and place by the bid evaluation committee in the presence of the bidders or their representatives who choose to be present;

b) the process of opening of the financial Bids shall be similar to that of technical Bids. c) the names of the bidders, the rates given by them and conditions put, if any, shall be read out and

recorded; d) conditional Bids are liable to be rejected; e) In order to decide the L1 bidder, NPV (Net Present Value) of the payable amount shall be taken into

account as given below: For calculation of NPV: First Capex Payment = 85% of price quoted for total CAPEX, i.e. A Price quoted for Total OPEX = B Total quarters for which payment to be made = 20 Quarterly payable amount = [{(Balance amount of CAPEX i.e. 15% of Total CAPEX) + B}/20] = C

The PV factor would be 0.75% per quarter (3.0% per year)

NPV = A+ [C/1.0075] + [C/(1.0075)2] + [C/(1.0075)3] + [C/(1.0075)4] + [C/(1.0075)5] + .. . . . . . . .

. . . . [C/(1.0075)20]

NOTE: QGR for 12 quarters have been considered for evaluation purpose only. However, the payment

shall be made as per payment terms and conditions of RFP.

f) the evaluation shall include all costs and all taxes and duties applicable to the bidder as per law of the Central/ State Government/ Local Authorities, and the evaluation criteria specified in the bidding documents shall only be applied; however, the component of VAT in case of bidders quoting from the state of Rajasthan shall not be added, but component of CST in case of bidders quoting from outside the state shall be added;

g) the offers shall be evaluated and marked L1, L2, L3 etc. based on NPV as calculated above. L1 being the lowest offer and then others in ascending order;

Qualification – 3 Overall Experience – 3 Attitude/Response – 4

Total Marks 60 Minimum total marks for technical qualification is 80% or 48 marks.


of 166

h) the bid evaluation committee shall prepare a comparative statement in tabular form in accordance with rulesalong with its report on evaluation of financial Bids and recommend the lowest offer for acceptance to the procuring entity, if price is the only criterion, or most advantageous Bid in other case;

i) The members of bids evaluation committee shall give their recommendations below the table regarding lowest Bid or most advantageous Bid and sign it.

j) it shall be ensured that the offer recommended for sanction is justifiable looking to the prevailing market rates of the goods, works or service required to be procured.

16) Correction of Arithmetic Errors in Financial Bids

The bid evaluation committee shall correct arithmetical errors in substantially responsive Bids, on the following basis, namely: - a) if there is a discrepancy between the unit price and the total price that is obtained by multiplying the

unit price and quantity, the unit price shall prevail and the total price shall be corrected, unless in the opinion of the bid evaluation committee there is an obvious misplacement of the decimal point in the unit price, in which case the total price as quoted shall govern and the unit price shall be corrected;

b) if there is an error in a total corresponding to the addition or subtraction of subtotals, the subtotals shall prevail and the total shall be corrected; and

c) if there is a discrepancy between words and figures, the amount in words shall prevail, unless the amount expressed in words is related to an arithmetic error, in which case the amount in figures shall prevail subject to clause (a) and (b) above.

17) Comparison of rates of firms outside and those in Rajasthan

While tabulating the financial Bids of those firms which are not entitled to price preference, the element of Rajasthan Value Added Tax (RVAT) shall be excluded from the rates quoted by the firms of Rajasthan and the element of Central Sales Tax (CST) shall be included in the rates of firms from outside Rajasthan for financial bid evaluation purpose.

18) Price/ purchase preference in evaluation

Price and/ or purchase preference notified by the State Government (GoR) and as mentioned in the bidding document shall be considered in the evaluation of Bids and award of contract.

19) Negotiations a) Except in case of procurement by method of single source procurement or procurement by competitive

negotiations, to the extent possible, no negotiations shall be conducted after the pre-bid stage. All clarifications needed to be sought shall be sought in the pre-bid stage itself.

b) Negotiations may, however, be undertaken only with the lowest or most advantageous bidder when the rates are considered to be much higher than the prevailing market rates.

c) The bid evaluation committee shall have full powers to undertake negotiations. Detailed reasons and results of negotiations shall be recorded in the proceedings.

d) The lowest or most advantageous bidder shall be informed in writing either through messenger or by registered letter and e-mail (if available). A minimum time of seven days shall be given for calling negotiations. In case of urgency the bid evaluation committee, after recording reasons, may reduce the time, provided the lowest or most advantageous bidder has received the intimation and consented to regarding holding of negotiations.

e) Negotiations shall not make the original offer made by the bidder inoperative. The bid evaluation committee shall have option to consider the original offer in case the bidder decides to increase rates originally quoted or imposes any new terms or conditions.

f) In case of non-satisfactory achievement of rates from lowest or most advantageous bidder, the bid evaluation committee may choose to make a written counter offer to the lowest or most advantageous bidder and if this is not accepted by him, the committee may decide to reject and re-invite Bids or to make the same counter-offer first to the second lowest or most advantageous bidder, then to the third


of 166

lowest or most advantageous bidder and so on in the order of their initial standing and work/ supply order be awarded to the bidder who accepts the counter-offer. This procedure would be used in exceptional cases only.

g) In case the rates even after the negotiations are considered very high, fresh Bids shall be invited. 20) Exclusion of Bids/ Disqualification

a) A procuring entity shall exclude/ disqualify a Bid, if: - a. the information submitted, concerning the qualifications of the bidder, was false or constituted a

misrepresentation; or b. the information submitted, concerning the qualifications of the bidder, was materially inaccurate

or incomplete; and c. the bidder is not qualified as per pre-qualification/ eligibility criteria mentioned in the bidding

document; d. the Bid materially departs from the requirements specified in the bidding document or it contains

false information; e. the bidder, submitting the Bid, his agent or any one acting on his behalf, gave or agreed to give, to

any officer or employee of the procuring entity or other governmental authority a gratification in any form, or any other thing of value, so as to unduly influence the procurement process;

f. a bidder, in the opinion of the procuring entity, has a conflict of interest materially affecting fair competition.

b) A Bid shall be excluded/ disqualified as soon as the cause for its exclusion/ disqualification is discovered.

c) Every decision of a procuring entity to exclude a Bid shall be for reasons to be recorded in writing and shall be: - a. communicated to the concerned bidder in writing; b. published on the State Public Procurement Portal, if applicable.

21) Lack of competition

a) A situation may arise where, if after evaluation of Bids, the bid evaluation committee may end-up with one responsive Bid only.In such situation, the bid evaluation committee would check as to whether while floating the NIB all necessary requirements to encourage competition like standard bid conditions, industry friendly specifications, wide publicity, sufficient time for formulation of Bids, etc. were fulfilled. If not, the NIBwould be re-floated after rectifying deficiencies. The bid process shall be considered valid even if there is one responsive Bid, provided that: - a. the Bid is technically qualified; b. the price quoted by the bidder is assessed to be reasonable; c. the Bid is unconditional and complete in all respects; d. there are no obvious indicators of cartelization amongst bidders; and e. the bidder is qualified as per the provisions of pre-qualification/ eligibility criteria in the bidding

document b) The bid evaluation committee shall prepare a justification note for approval by the next higher

authority of the procuring entity, with the concurrence of the accounts member. c) In case of dissent by any member of bid evaluation committee, the next higher authority in delegation

of financial powers shall decide as to whether to sanction the single Bid or re-invite Bids after recording reasons.

d) If a decision to re-invite the Bids is taken, market assessment shall be carried out for estimation of market depth, eligibility criteria and cost estimate.


of 166

22) Acceptance of the successful Bid and award of contract a) The procuring entity after considering the recommendations of the bid evaluation committee and the

conditions of Bid, if any, financial implications, trials, sample testing and test reports, etc., shall accept or reject the successful Bid. If any member of the bid evaluation committee, has disagreed or given its note of dissent, the matter shall be referred to the next higher authority, as per delegation of financial powers, for decision.

b) Decision on Bids shall be taken within original validity period of Bids and time period allowed to procuring entity for taking decision. If the decision is not taken within the original validity period or time limit allowed for taking decision, the matter shall be referred to the next higher authority in delegation of financial powers for decision.

c) Before award of the contract, the procuring entity shall ensure that the price of successful Bid is reasonable and consistent with the required quality.

d) A Bid shall be treated as successful only after the competent authority has approved the procurement in terms of that Bid.

e) The procuring entity shall award the contract to the bidder whose offer has been determined to be the lowest or most advantageous in accordance with the evaluation criteria set out in the bidding document and if the bidder has been determined to be qualified to perform the contract satisfactorily on the basis of qualification criteria fixed for the bidders in the bidding document for the subject matter of procurement.

f) Prior to the expiration of the period of bid validity, the procuring entity shall inform the successful bidder, in writing, that its Bid has been accepted.

g) As soon as a Bid is accepted by the competent authority, its written intimation shall be sent to the concerned bidder by registered post or email and asked to execute an agreement in the format given in the bidding documents on a non-judicial stamp of requisite value and deposit the amount of performance security or a performance security declaration, if applicable, within a period specified in the bidding documents or where the period is not specified in the bidding documents then within fifteen days from the date on which the letter of acceptance or letter of intent is dispatched to the bidder.

h) If the issuance of formal letter of acceptance is likely to take time, in the meanwhile a Letter of Intent (LOI) may be sent to the bidder. The acceptance of an offer is complete as soon as the letter of acceptance or letter of intent is posted and/ or sent by email (if available) to the address of the bidder given in the bidding document. Until a formal contract is executed, the letter of acceptance or LOI shall constitute a binding contract.

i) The bid security of the bidders whose Bids could not be accepted shall be refunded soon after the contract with the successful bidder is signed and its performance security is obtained.

23) Information and publication of award

Information of award of contract shall be communicated to all participating bidders and published on the respective website(s) as specified in NIB.

24) Procuring entity’s right to accept or reject any or all Bids

The Procuring entity reserves the right to accept or reject any Bid, and to annul (cancel) the bidding process and reject all Bids at any time prior to award of contract, without thereby incurring any liability to the bidders.

25) Right to vary quantity

a) If the procuring entity does not procure any subject matter of procurement or procures less than the quantity specified in the bidding documents due to change in circumstances, the bidder shall not be entitled for any claim or compensation.


of 166

b) Repeat orders for extra items or additional quantities may be placedon the rates and conditions given in the contract. Delivery or completion period may also be proportionately increased. The limits of repeat order shall be as under: - a. 50% of the quantity of the individual items and 50% of the value of original contract in case of

works; and b. 50% of the value of goods or services of the original contract.

26) Performance Security

a) Prior to execution of agreement, Performance security shall be solicited from all successful bidders except the departments of the State Government and undertakings, corporations, autonomous bodies, registered societies, co-operative societies which are owned or controlled or managed by the State Government and undertakings of the Central Government. However, a performance security declaration shall be taken from them. The State Government may relax the provision of performance security in particular procurement or any class of procurement.

b) The amount of performance security shall be 5% of the amount of work order in case of procurement of goods and services. In case of Small Scale Industries (SSI) of Rajasthan, it shall be 1% of the amount of quantity ordered for supply of goods and in case of sick industries, other than SSI, whose cases are pending before the Board of Industrial and Financial Reconstruction (BIFR), it shall be 2% of the amount of supply order.

c) Performance security shall be furnished in any one of the following forms: - a. Bank Draft or Banker's Cheque of a scheduled bank; b. National Savings Certificates and any other script/ instrument under National Savings

Schemes for promotion of small savings issued by a Post Office in Rajasthan, if the same can be pledged under the relevant rules. They shall be accepted at their surrender value at the time of bid and formally transferred in the name of procuring entity with the approval of Head Post Master;

c. Bank guarantee/s of a scheduled bank. It shall be got verified from the issuing bank. Other conditions regarding bank guarantee shall be same as mentioned in the bidding document for bid security;

d. Fixed Deposit Receipt (FDR) of a scheduled bank. It shall be in the name of procuring entity on account of bidder and discharged by the bidder in advance. The procuring entity shall ensure before accepting the FDR that the bidder furnishes an undertaking from the bank to make payment/premature payment of the FDR on demand to the procuring entity without requirement of consent of the bidder concerned. In the event of forfeiture of the performance security, the Fixed Deposit shall be forfeited along with interest earned on such Fixed Deposit.

d) Performance security furnished in the form specified in clause [b.] to [e.] of (c)above shall remain valid for a period of 60 days beyond the date of completion of all contractual obligations of the bidder, including warranty obligations and maintenance and defect liability period.

e) Forfeiture of Security Deposit: Security amount in full or part may be forfeited, including interest, if any, in the following cases:-

a. When any terms and condition of the contract is breached. b. When the bidder fails to make complete supply satisfactorily. c. if the bidder breaches any provision of code of integrity, prescribed for bidders, specified in the

bidding document. f) Notice will be given to the bidder with reasonable time before PSD deposited is forfeited. g) No interest shall be payable on the PSD.


of 166

27) Execution of agreement a) A procurement contract shall come into force from the date on which the letter of acceptance or letter

of intent is despatched to the bidder. b) The successful bidder shall sign the procurement contract within 15 daysfrom the date on which the

letter of acceptance or letter of intent is despatched to the successful bidder. c) If the bidder, whose Bid has been accepted, fails to sign a written procurement contract or fails to

furnish the required performance security within specified period, the procuring entity shall take action against the successful bidder as per the provisions of the bidding document and Act. The procuring entity may, in such case, cancel the procurement process or if it deems fit, offer for acceptance the rates of lowest or most advantageous bidder to the next lowest or most advantageous bidder, in accordance with the criteria and procedures set out in the bidding document.

d) The bidder will be required to execute the agreement on a non-judicial stamp of specified value at its cost and to be purchase from anywhere in Rajasthan only.

28) Confidentiality a) Notwithstanding anything contained in this bidding document but subject to the provisions of any other

law for the time being in force providing for disclosure of information, a procuring entity shall not disclose any information if such disclosure, in its opinion, is likely to: - a. impede enforcement of any law; b. affect the security or strategic interests of India; c. affect the intellectual property rights or legitimate commercial interests of bidders; d. affect the legitimate commercial interests of the procuring entity in situations that may include

when the procurement relates to a project in which the procuring entity is to make a competitive bid, or the intellectual property rights of the procuring entity.

b) The procuring entity shall treat all communications with bidders related to the procurement process in such manner as to avoid their disclosure to competing bidders or to any other person not authorised to have access to such information.

c) The procuring entity may impose on bidders and sub-contractors, if there are any for fulfilling the terms of the procurement contract, conditions aimed at protecting information, the disclosure of which violates (a) above.

d) In addition to the restrictions specified above, the procuring entity, while procuring a subject matter of such nature which requires the procuring entity to maintain confidentiality, may impose condition for protecting confidentiality of such information.

29) Cancellation of procurement process

a) If any procurement process has been cancelled, it shall not be reopened but it shall not prevent the procuring entity from initiating a new procurement process for the same subject matter of procurement, if required.

b) A procuring entity may, for reasons to be recorded in writing, cancel the process of procurement initiated by it - a. at any time prior to the acceptance of the successful Bid; or b. after the successful Bid is accepted in accordance with (d) and (e) below.

c) The procuring entity shall not open any bids or proposals after taking a decision to cancel the procurement and shall return such unopened bids or proposals.

d) The decision of the procuring entity to cancel the procurement and reasons for such decision shall be immediately communicated to all bidders that participated in the procurement process.

e) If the bidder whose Bid has been accepted as successful fails to sign any written procurement contract as required, or fails to provide any required security for the performance of the contract, the procuring entity may cancel the procurement process.

f) If a bidder is convicted of any offence under the Act, the procuring entity may: -


of 166

a. cancel the relevant procurement process if the Bid of the convicted bidder has been declared as successful but no procurement contract has been entered into;

b. rescind (cancel) the relevant contract or forfeit the payment of all or a part of the contract value if the procurement contract has been entered into between the procuring entity and the convicted bidder.

30) Code of Integrity for Bidders

a) No person participating in a procurement process shall act in contravention of the code of integrity prescribed by the State Government.

b) The code of integrity include provisions for: - a. Prohibiting

i. any offer, solicitation or acceptance of any bribe, reward or gift or any material benefit, either directly or indirectly, in exchange for an unfair advantage in the procurement process or to otherwise influence the procurement process;

ii. any omission, including a misrepresentation that misleads or attempts to mislead so as to obtain a financial or other benefit or avoid an obligation;

iii. any collusion, bid rigging or anti-competitive behaviour to impair the transparency, fairness and progress of the procurement process;

iv. improper use of information shared between the procuring entity and the bidders with an intent to gain unfair advantage in the procurement process or for personal gain;

v. any financial or business transactions between the bidder and any officer or employee of the procuring entity;

vi. any coercion including impairing or harming or threatening to do the same, directly or indirectly, to any party or to its property to influence the procurement process;

vii. any obstruction of any investigation or audit of a procurement process; b. disclosure of conflict of interest; c. disclosure by the bidder of any previous transgressions with any entity in India or any other country

during the last three years or of any debarment by any other procuring entity. c) Without prejudice to the provisions below, in case of any breach of the code of integrity by a bidder or

prospective bidder, as the case may be, the procuring entity may take appropriate measures including: - a. exclusion of the bidder from the procurement process; b. calling-off of pre-contract negotiations and forfeiture or encashment of bid security; c. forfeiture or encashment of any other security or bond relating to the procurement; d. recovery of payments made by the procuring entity along with interest thereon at bank rate; e. cancellation of the relevant contract and recovery of compensation for loss incurred by the

procuring entity; f. debarment of the bidder from participation in future procurements of the procuring entity for a

period not exceeding three years.


of 166

31) Interference with Procurement Process A bidder, who: - a) withdraws from the procurement process after opening of financial bids; b) withdraws from the procurement process after being declared the successful bidder; c) fails to enter into procurement contract after being declared the successful bidder; d) fails to provide performance security or any other document or security required in terms of the

bidding documents after being declared the successful bidder, without valid grounds, shall, in addition to the recourse available in the bidding document or the contract, be punished with fine which may extend to fifty lakh rupees or ten per cent of the assessed value of procurement, whichever is less.

32) Appeals

a) Subject to “Appeal not to lie in certain cases” below, if any bidder or prospective bidder is aggrieved that any decision, action or omission of the procuring entity is in contravention to the provisions of the Act or the rules or guidelines issued thereunder, he may file an appeal to such officer of the procuring entity, as may be designated by it for the purpose, within a period of 10 days from the date of such decision or action, omission, as the case may be, clearly giving the specific ground or grounds on which he feels aggrieved: a. Provided that after the declaration of a bidder as successful in terms of “Award of Contract”, the

appeal may be filed only by a bidder who has participated in procurement proceedings: b. Provided further that in case a procuring entity evaluates the technical Bid before the opening of

the financial Bid, an appeal related to the matter of financial Bid may be filed only by a bidder whose technical Bid is found to be acceptable.

b) The officer to whom an appeal is filed under (a) above shall deal with the appeal as expeditiously as possible and shall endeavour to dispose it of within 30 days from the date of filing of the appeal.

c) If the officer designated under (a) above fails to dispose of the appeal filed under that sub-section within the period specified in (c) above, or if the bidder or prospective bidder or the procuring entity is aggrieved by the order passed, the bidder or prospective bidder or the procuring entity, as the case may be, may file a second appeal to an officer or authority designated by the State Government in this behalf within 15 days from the expiry of the period specified in (c) above or of the date of receipt of the order passed under (b) above, as the case may be.

d) The officer or authority to which an appeal is filed under (c) above shall deal with the appeal as expeditiously as possible and shall endeavour to dispose it of within 30 days from the date of filing of the appeal:

e) The officer or authority to which an appeal may be filed under (a) or (d) above shall be :

a. First Appellate Authority: Principal Secretary, IT&C, GoR

b. Second Appellate Authority: Secretary (Budget), Finance Department, GoR f) Form of Appeal:

a. Every appeal under (a) and (c) above shall be as per Annexure-10 along with as many copies as there are respondents in the appeal.

b. Every appeal shall be accompanied by an order appealed against, if any, affidavit verifying the facts stated in the appeal and proof of payment of fee.

c. Every appeal may be presented to First Appellate Authority or Second Appellate Authority, as the case may be, in person or through registered post or authorised representative.

g) Fee for Appeal: Fee for filing appeal: a. Fee for first appeal shall be rupees two thousand five hundred and for second appeal shall be

rupees ten thousand, which shall be non-refundable. b. The fee shall be paid in the form of bank demand draft or banker’s cheque of a Scheduled Bank

payable in the name of Appellate Authority concerned.


of 166

h) Procedure for disposal of appeal: a. The First Appellate Authority or Second Appellate Authority, as the case may be, upon filing of

appeal, shall issue notice accompanied by copy of appeal, affidavit and documents, if any, to the respondents and fix date of hearing.

b. On the date fixed for hearing, the First Appellate Authority or Second Appellate Authority, as the case may be, shall,-

i. hear all the parties to appeal present before him; and ii. peruse or inspect documents, relevant records or copies thereof relating to the matter.

c. After hearing the parties, perusal or inspection of documents and relevant records or copies thereof relating to the matter, the Appellate Authority concerned shall pass an order in writing and provide the copy of order to the parties to appeal free of cost.

d. The order passed under (c) shall also be placed on the State Public Procurement Portal. i) No information which would impair the protection of essential security interests of India, or impede

the enforcement of law or fair competition, or prejudice the legitimate commercial interests of the bidder or the procuring entity, shall be disclosed in a proceeding under an appeal.

33) Stay of procurement proceedings

While hearing of an appeal, the officer or authority hearing the appeal may, on an application made in this behalf and after affording a reasonable opportunity of hearing to the parties concerned, stay the procurement proceedings pending disposal of the appeal, if he, or it, is satisfied that failure to do so is likely to lead to miscarriage of justice.

34) Vexatious Appeals & Complaints Whoever intentionally files any vexatious, frivolous or malicious appeal or complaint under the “The Rajasthan Transparency Public Procurement Act 2012”, with the intention of delaying or defeating any procurement or causing loss to any procuring entity or any other bidder, shall be punished with fine which may extend to twenty lakh rupees or five per cent of the value of procurement, whichever is less.

35) Offenses by Firms/ Companies

a) Where an offence under “The Rajasthan Transparency Public Procurement Act 2012” has been committed by a company, every person who at the time the offence was committed was in charge of and was responsible to the company for the conduct of the business of the company, as well as the company, shall be deemed to be guilty of having committed the offence and shall be liable to be proceeded against and punished accordingly: Provided that nothing contained in this sub-section shall render any such person liable for any punishment if he proves that the offence was committed without his knowledge or that he had exercised all due diligence to prevent the commission of such offence.

b) Notwithstanding anything contained in (a) above, where an offence under this Act has been committed by a company and it is proved that the offence has been committed with the consent or connivance of or is attributable to any neglect on the part of any director, manager, secretary or other officer of the company, such director, manager, secretary or other officer shall also be deemed to be guilty of having committed such offence and shall be liable to be proceeded against and punished accordingly.

c) For the purpose of this section- a. "company" means a body corporate and includes a limited liability partnership, firm,

registered society or cooperative society, trust or other association of individuals; and b. "director" in relation to a limited liability partnership or firm, means a partner in the firm.

d) Abetment of certain offenses: Whoever abets an offence punishable under this Act, whether or not that offence is committed in consequence of that abetment, shall be punished with the punishment provided for the offence.


of 166

36) Debarment from Bidding

a. A bidder shall be debarred by the State Government if he has been convicted of an offence

i. under the Prevention of Corruption Act, 1988 (Central Act No. 49 of 1988); or

ii. under the Indian Penal Code, 1860 (Central Act No. 45 of 1860) or any other law for the time being in force, for causing any loss of life or property or causing a threat to public health as part of execution of a public procurement contract.

b. A bidder debarred under (a) above shall not be eligible to participate in a procurement process of any procuring entity for a period not exceeding three years commencing from the date on which he was debarred.

c. If a procuring entity finds that a bidder has breached the code of integrity prescribed in terms of “Code of Integrity for bidders” above, it may debar the bidder for a period not exceeding three years.

d. Where the entire bid security or the entire performance security or any substitute thereof, as the case may be, of a bidder has been forfeited by a procuring entity in respect of any procurement process or procurement contract, the bidder may be debarred from participating in any procurement process undertaken by the procuring entity for a period not exceeding three years.

e. The State Government or a procuring entity, as the case may be, shall not debar a bidder under this section unless such bidder has been given a reasonable opportunity of being heard.

37) Monitoring of Contract

a) An officer or a committee of officers named Contract Monitoring Committee (CMC) may be nominated by procuring entity to monitor the progress of the contract during its delivery period.

b) During the delivery period the CMC shall keep a watch on the progress of the contract and shall ensure that quantity of goods and service delivery is in proportion to the total delivery period given, if it is a severable contract, in which the delivery of the goods and service is to be obtained continuously or is batched. If the entire quantity of goods and service is to be delivered in the form of completed work or entire contract like fabrication work, the process of completion of work may be watched and inspections of the selected bidder’s premises where the work is being completed may be inspected.

c) If delay in delivery of goods and service is observed a performance notice would be given to the selected bidder to speed up the delivery.

d) Any change in the constitution of the firm, etc. shall be notified forth with by the contractor in writing to the procuring entity and such change shall not relieve any former member of the firm, etc., from any liability under the contract.

e) No new partner/ partners shall be accepted in the firm by the selected bidder in respect of the contract unless he/ they agree to abide by all its terms, conditions and deposits with the procuring entity through a written agreement to this effect. The bidder’s receipt for acknowledgement or that of any partners subsequently accepted as above shall bind all of them and will be sufficient discharge for any of the purpose of the contract.

f) The selected bidder shall not assign or sub-let his contract or any substantial part thereof to any other agency without the permission of procuring entity.


of 166

6. GENERALTERMS AND CONDITIONS OF TENDER &CONTRACT Bidders should read these conditions carefully and comply strictly while sending their bids. Definitions For the purpose of clarity, the following words and expressions shall have the meanings hereby assigned to them: - a) “Contract” means the Agreement entered into between the Purchaser and the successful/ selected bidder,

together with the Contract Documents referred to therein, including all attachments, appendices, and all documents incorporated by reference therein.

b) “Contract Documents” means the documents listed in the Agreement, including any amendments thereto. c) “Contract Price” means the price payable to the successful/ selected bidder as specified in the Agreement,

subject to such additions and adjustments thereto or deductions there from, as may be made pursuant to the Contract.

d) “Day” means a calendar day. e) “Delivery” means the delivery of services from the successful/ selected bidder to the Purchaser in

accordance with the terms and conditions set forth in the Contract. f) “Completion” means the fulfilment of the related services by the successful/ selected bidder in accordance

with the terms and conditions set forth in the Contract. g) “Purchaser” means the entity purchasing the Goods and related services, as specified in the bidding

document. h) “Subcontractor” means any natural person, private or government entity, or a combination of the above,

including its legal successors or permitted assigns, to whom any part of the Services to be delivered or execution of any part of the related services is subcontracted by the successful/ selected bidder.

i) “Supplier/ Successful or Selected bidder” means the person, private or government entity, or a combination of the above, whose Bid to perform the Contract has been accepted by the Purchaser and is named as such in the Agreement, and includes the legal successors or permitted assigns of the successful/ selected bidder.

j) “The Site,” where applicable, means the designated project place(s) named in the bidding document. Note: The bidder shall be deemed to have carefully examined the conditions, specifications of services to be rendered. If the bidder has any doubts as to the meaning of any portion of these conditions or of the specification etc., he shall, before submitting the Bid and signing the contract refer the same to the procuring entity and get clarifications.

1) Contract Documents

Subject to the order of precedence set forth in the Agreement, all documents forming the Contract (and all parts thereof) are intended to be correlative, complementary, and mutually explanatory.

2) Interpretation

a) If the context so requires it, singular means plural and vice versa. b) Entire Agreement: The Contract constitutes the entire agreement between the Purchaser and the

Selected Bidder and supersedes all communications, negotiations and agreements (whether written or oral) of parties with respect thereto made prior to the date of Contract.

c) Amendment: No amendment or other variation of the Contract shall be valid unless it is in writing, is dated, expressly refers to the Contract, and is signed by a duly authorized representative of each party thereto.

d) Non-waiver: Subject to the condition (f) below, no relaxation, forbearance, delay, or indulgence by either party in enforcing any of the terms and conditions of the Contract or the granting of time by either party to the other shall prejudice, affect, or restrict the rights of that party under the Contract, neither shall any waiver by either party of any breach of Contract operate as waiver of any subsequent or continuing breach of Contract.


of 166

e) Any waiver of a party’s rights, powers, or remedies under the Contract must be in writing, dated, and signed by an authorized representative of the party granting such waiver, and must specify the right and the extent to which it is being waived.

f) Severability: If any provision or condition of the Contract is prohibited or rendered invalid or unenforceable, such prohibition, invalidity or unenforceability shall not affect the validity or enforceability of any other provisions and conditions of the Contract.

3) Language a) The Contract as well as all correspondence and documents relating to the Contract exchanged by the

successful/ selected bidder and the Purchaser, shall be written in English language only. Supporting documents and printed literature that are part of the Contract may be in another language provided they are accompanied by an accurate translation of the relevant passages in the language specified in the special conditions of the contract, in which case, for purposes of interpretation of the Contract, this translation shall govern.

b) The successful/ selected bidder shall bear all costs of translation to the governing language and all risks of the accuracy of such translation.

4) Joint Venture, Consortium or Association

Any sort of Joint Venture of Consortium is not allowed.

5) Service of Notice, Documents & Orders a) A notice, document or order shall be deemed to be served on any individual by -

a. delivering it to the person personally; or b. leaving it at, or sending it by post to, the address of the place of residence or business of

the person last known; c. on a body corporate by leaving it at, or sending it by post to, the registered office of the body

corporate. b) When the procedure laid down in (a) above is followed, service shall be deemed to be effected by

properly addressing, preparing and posting the document, notice or order, as the case may be.

6) Scope of Service Delivery a) Subject to the provisions in the bidding document and contract, the services to be delivered shall be

as specified in the bidding document. b) Unless otherwise stipulated in the Contract, the scope of service shall include all such items not

specifically mentioned in the Contract but that can be reasonably inferred from the Contract as being required for attaining delivery and completion of the services as if such items were expressly mentioned in the Contract.

7) Selected Bidder’s Responsibilities

The Selected Bidder shall deliver all the services included in the scope in accordance with the provisions of bidding document and/ or contract.

8) Purchaser’s Responsibilities

a) Whenever the delivery of services requires that the Selected Bidder obtain permits, approvals, and import and other licenses from local public authorities, the Purchaser shall, if so required by the Selected Bidder, make its best effort to assist the Selected Bidder in complying with such requirements in a timely and expeditious manner.


of 166

b) The Purchaser shall pay all costs involved in the performance of its responsibilities, in accordance with the general and special conditions of the contract.

9) Contract Price a) The Contract Price shall be paid as specified in the contract subject to any additions and adjustments

thereto, or deductions there from, as may be made pursuant to the Contract. b) Prices charged by the Selected Bidder for the Services performed under the Contract shall not vary

from the prices quoted by the Selected Bidder in its bid, with the exception of any price adjustments authorized in the special conditions of the contract.

10) Recoveries from Selected Bidder

a) Recoveries of liquidated damages, short supply, rejected articles shall ordinary be made from bills. b) Amount may also be withheld to the extent of short supply and rejected articles and in case of failure

in satisfactory replacement by the supplier along with amount of liquidated damages shall be recovered from his dues and security deposit available with RISL.

c) In case, recovery is not possible recourse will be taken under Rajasthan PDR Act or any other law in force.

11) Taxes & Duties a) The TDS, Raj-VAT, Service Tax etc., if applicable, shall be deducted at source/ paid by RISL as per

prevailing rates. b) If any tax exemptions, reductions, allowances or privileges may be available to the successful/

selected bidder in India, the Purchaser shall use its best efforts to enable the successful/ selected bidder to benefit from any such tax savings to the maximum allowable extent.

12) Copyright/IPR The copyright/IPR in all drawings, design documents, source code and other materials containing data and information furnished to the Purchaser by the Selected Bidder herein shall remain vested in RISL, or, if they are furnished to the Purchaser directly or through the Selected Bidder by any third party, including suppliers of materials, the copyright/IPR in such materials shall remain vested in RISL.

13) Confidential Information

a) The Purchaser and the Selected Bidder shall keep confidential and shall not, without the written consent of the other party hereto, divulge to any third party any drawings, documents, data, or other information furnished directly or indirectly by the other party hereto in connection with the Contract, whether such information has been furnished prior to, during or following completion or termination of the Contract.

b) The Selected Bidder may furnish to its Subcontractor, if permitted, such documents, data, and other information it receives from the Purchaser to the extent required for the Subcontractor to perform its work under the Contract, in which event the Selected Bidder shall obtain from such Subcontractor an undertaking of confidentiality similar to that imposed on the Selected Bidder.

c) The Purchaser shall not use such documents, data, and other information received from the Selected Bidder for any purposes unrelated to the Contract. Similarly, the Selected Bidder shall not use such documents, data, and other information received from the Purchaser for any purpose other than the design, procurement, or other work and services required for the performance of the Contract.

d) The obligation of a party under sub-clauses above, however, shall not apply to information that: - i. the Purchaser or Selected Bidder need to share with other institutions participating in the

Contract; ii. now or hereafter enters the public domain through no fault of that party;


of 166

iii. can be proven to have been possessed by that party at the time of disclosure and which was not previously obtained, directly or indirectly, from the other party; or

iv. otherwise lawfully becomes available to that party from a third party that has no obligation of confidentiality.

e) The above provisions shall not in any way modify any undertaking of confidentiality given by either of the parties hereto prior to the date of the Contract in respect of the service or any part thereof.

f) The provisions of this clause shall survive completion or termination, for whatever reason, of the Contract.

14) Delivery period & Extent of Quantity – Repeat Orders

a) The time specified for delivery shall be deemed to be the essence of the contract and the successful bidder shall arrange service delivery within the period on receipt of the firm order from the Purchase Officer.

b) The selected bidder shall arrange delivery within the stipulated time period. c) If the orders are placed in excess of the quantities, the bidder shall be bound to meet the required

delivery. Repeat orders may also be placed on the rate and conditions given in the bidding document. If the bidder fails to do so, the Purchase Officer shall be fee to arrange for the balance supply by limited tender or otherwise and the extra cost incurred shall be recoverable from the bidder.

15) Liquidated Damages (LD) In case of extension in the delivery of services and completion period with liquidated damages, the recovery shall be made on the basis of following percentages of value of services which successful bidder has failed to deliver / complete: -

Delay up to one fourth period of the prescribed delivery of services & completion of work.

2.5%

Delay exceeding one fourth but not exceeding half of the prescribed delivery of services & completion of work.

5.0%

Delay exceeding half but not exceeding three fourth of the prescribed delivery of services & completion of work.

7.5%

Delay exceeding three fourth of the prescribed delivery of services & completion of work.

10.0%

Note: i. Fraction of a day in reckoning period of delay in services shall be eliminated if it is less than half a day.

ii. The maximum amount of agreed liquidated damages shall be 10%. iii. If successful bidder requires an extension of time in completion of contractual delivery on account of

occurrence of any hindrances, he shall apply in writing to the authority which had placed the work order, for the same immediately on occurrence of the hindrance but not after the stipulated date of completion of supply.

iv. Delivery period may be extended with or without liquidated damages if the delay in the delivery of services in on account of hindrances beyond the control of selected bidder.

16) Settlement of Disputes

As per the provision of the Arbitration and Conciliation Act, 1996.

17) All legal proceedings, if necessary arise to institute may by any of the parties (Government of Contractor) shall have to be lodged in courts situated in Rajasthan and not elsewhere.


of 166

18) Patent Indemnity a) The selected bidder shall, subject to the Purchaser’s compliance with sub-clause (b) below, indemnify

and hold harmless the Purchaser and its employees and officers from and against any and all suits, actions or administrative proceedings, claims, demands, losses, damages, costs, and expenses of any nature, including attorney’s fees and expenses, which the Purchaser may suffer as a result of any infringement or alleged infringement of any patent, utility model, registered design, trademark, copyright, or other intellectual property right registered or otherwise existing at the date of the Contract by reason of: - i. the delivery of services by the selected bidder or the use of the Goods in the country where the

Site is located; and ii. the sale in any country of the products produced by the Goods. Such indemnity shall not cover any use of the Goods or any part thereof other than for the purpose indicated by or to be reasonably inferred from the Contract, neither any infringement resulting from the use of the Goods or any part thereof, or any products produced thereby in association or combination with any other equipment, plant, or materials not supplied by the supplier/ selected bidder, pursuant to the Contract.

b) If any proceedings are brought or any claim is made against the Purchaser arising out of the matters referred to above, the Purchaser shall promptly give the supplier/ selected bidder a notice thereof, and the supplier/ selected bidder may at its own expense and in the Purchaser’s name conduct such proceedings or claim and any negotiations for the settlement of any such proceedings or claim.

c) If the supplier/ selected bidder fails to notify the Purchaser within thirty (30) days after receipt of such notice that it intends to conduct any such proceedings or claim, then the Purchaser shall be free to conduct the same on its own behalf.

d) The Purchaser shall, at the supplier’s/ selected bidder’s request, afford all available assistance to the supplier/ selected bidder in conducting such proceedings or claim, and shall be reimbursed by the supplier/ selected bidder for all reasonable expenses incurred in so doing.

e) The Purchaser shall indemnify and hold harmless the supplier/ selected bidder and its employees, officers, and Subcontractors (if any) from and against any and all suits, actions or administrative proceedings, claims, demands, losses, damages, costs, and expenses of any nature, including attorney’s fees and expenses, which the supplier/ selected bidder may suffer as a result of any infringement or alleged infringement of any patent, utility model, registered design, trademark, copyright, or other intellectual property right registered or otherwise existing at the date of the Contract arising out of or in connection with any design, data, drawing, specification, or other documents or materials provided or designed by or on behalf of the Purchaser.

19) Limitation of Liability

Except in cases of gross negligence or wilful misconduct: - a) neither party shall be liable to the other party for any indirect or consequential loss or damage, loss

of use, loss of production, or loss of profits or interest costs, provided that this exclusion shall not apply to any obligation of the supplier/ selected bidder to pay liquidated damages to the Purchaser; and

b) the aggregate liability of the supplier/ selected bidder to the Purchaser, whether under the Contract, in tort, or otherwise, shall not exceed the amount specified in the Contract, provided that this limitation shall not apply to the cost of repairing or replacing defective equipment, or to any obligation of the supplier/ selected bidder to indemnify the Purchaser with respect to patent infringement.


of 166

20) Force Majeure a) The supplier/ selected bidder shall not be liable for forfeiture of its PSD, LD, or termination for default

if and to the extent that it’s delay in performance or other failure to perform its obligations under the Contract is the result of an event of Force Majeure.

b) For purposes of this Clause, “Force Majeure” means an event or situation beyond the control of the supplier/ selected bidder that is not foreseeable, is unavoidable, and its origin is not due to negligence or lack of care on the part of the supplier/ selected bidder. Such events may include, but not be limited to, acts of the Purchaser in its sovereign capacity, wars or revolutions, fires, floods, epidemics, quarantine restrictions, and freight embargoes.

c) If a Force Majeure situation arises, the supplier/ selected bidder shall promptly notify RISL in writing of such conditions and cause thereof within 15 days of occurrence of such event. Unless otherwise directed by RISL, the supplier/ selected bidder shall continue to perform its obligations under the contract as far as reasonably practical.

d) If the performance in whole or part or any obligation under the contract is prevented or delayed by any reason of Force Majeure for a period exceeding 60 days, either party at its option may terminate the contract without any financial repercussion on either side.

e) In case a Force Majeure situation occurs with RISL, RISL may take the case with the supplier/ selected bidder on similar lines.

21) Change Orders and Contract Amendments

a) The Purchaser may at any time order the supplier/ selected bidder through Notice in accordance with clause “Notices” above, to make changes within the general scope of the Contract in any one or more of the following: -

i. drawings, designs, or specifications, where Goods to be furnished under the Contract are to be specifically manufactured for the Purchaser;

ii. the related services to be provided by the supplier/ selected bidder. b) If any such change causes an increase or decrease in the cost of, or the time required for, the supplier’s/

selected bidder’s performance of any provisions under the Contract, an equitable adjustment shall be made in the Contract Price or in the Delivery and Completion Schedule, or both, and the Contract shall accordingly should be amended. Any claims by the supplier/ selected bidder for adjustment under this clause must be asserted within thirty (30) days from the date of the supplier’s/ selected bidder’s receipt of the Purchaser’s change order.

c) Prices to be charged by the supplier/ selected bidder for any services that might be needed but which were not included in the Contract shall be agreed upon in advance by the parties and shall not exceed the prevailing rates charged to other parties by the supplier/ selected bidder for similar services.

22) Termination

a) Termination for Default i. The procuring entity may, without prejudice to any other remedy for breach of contract, by

written a written notice of default of at least 30 days sent to the supplier/ selected bidder, terminate the contract in whole or in part: - a. If the supplier/ selected bidder fails to deliver any or all quantities of the service within the

time period specified in the contract, or any extension thereof granted by RISL; or b. If the supplier/ selected bidder fails to perform any other obligation under the contract within

the specified period of delivery of service or any extension granted thereof; or c. If the supplier/ selected bidder, in the judgement of the Purchaser, is found to be engaged in

corrupt, fraudulent, collusive, or coercive practices in competing for or in executing the contract.

d. If the supplier/ selected bidder commits breach of any condition of the contract. ii. If RISL terminates the contract in whole or in part, amount of PSD may be forfeited.


of 166

iii. Before cancelling a contract and taking further action, advice of senior most finance person available in the office and of legal adviser or legal assistant posted in the office, if there is one, may be obtained.

b) Termination for Insolvency

RISL may at any time terminate the Contract by giving a written notice of at least 30 days to the supplier/ selected bidder, if the supplier/ selected bidder becomes bankrupt or otherwise insolvent. In such event, termination will be without compensation to the supplier/ selected bidder, provided that such termination will not prejudice or affect any right of action or remedy that has accrued or will accrue thereafter to RISL.

c) Termination for Convenience

i. RISL, by a written notice of at least 30 days sent to the supplier/ selected bidder may terminate the Contract, in whole or in part, at any time for its convenience. The Notice of termination shall specify that termination is for the Purchaser’s convenience, the extent to which performance of the supplier/ selected bidder under the Contract is terminated, and the date upon which such termination becomes effective.

ii. Depending on merits of the case the supplier/ selected bidder may be appropriately compensated on mutually agreed terms for the loss incurred by the contract if any due to such termination.

23) Exit Management

1. Preamble i. The word ‘parties’ include the procuring entity and the selected bidder.

ii. This Schedule sets out the provisions, which will apply on expiry or termination of the Project Implementation and Operations and Management of SLA.

iii. In the case of termination of the Project Implementation and/ or Operation and Management SLA due to illegality, the Parties shall agree at that time whether, and if so during what period, the provisions of this Schedule shall apply.

iv. The Parties shall ensure that their respective associated entities carry out their respective obligations set out in this Exit Management Schedule.

2. Transfer of Assets i. The selected bidder may continue work on the assets for the duration of the exit management

period which may be a six months period from the date of expiry or termination of the agreement, if required by RISL to do so. During this period, the selected bidder will transfer all the assets in good working condition and as per the specifications of the bidding document including the ones being upgraded to the designated agency. The security deposit/ performance security submitted by selected bidder will only be returned after the successful transfer of the entire project including its infrastructure.

ii. The selected bidder, if not already done, will transfer all the Software Licenses under the name of RISL as desired by the procuring entity during the exit management period.

iii. RISL during the project implementation phase and the operation and management phase shall be entitled to serve notice in writing to the selected bidder at any time during the exit management period requiring the selected bidder to provide RISL or its nominated agencies with a complete and up-to-date list of the assets within 30 days of such notice.

iv. Upon service of a notice, as mentioned above, the following provisions shall apply: - a. In the event, if the assets which to be transferred to RISL mortgaged to any financial

institutions by the selected bidder, the selected bidder shall ensure that all such liens and liabilities have been cleared beyond any doubt, prior to such transfer. All documents


of 166

regarding the discharge of such lien and liabilities shall be furnished to RISL or its nominated agencies.

b. All title of the assets to be transferred to RISL or its nominated agencies pursuant to clause(s) above shall be transferred on the last day of the exit management period. All expenses occurred during transfer of assets shall be borne by the selected bidder.

c. That on the expiry of this clause, the selected bidder and any individual assigned for the performance of the services under this clause shall handover or cause to be handed over all confidential information and all other related material in its possession, including the entire established infrastructure supplied by selected bidder to RISL.

d. That the products and technology delivered to RISL during the contract term or on expiry of the contract duration should not be sold or re-used or copied or transferred by selected bidder to other locations apart from the locations mentioned in the this bidding document without prior written notice and approval of RISL. Supplied hardware, software & documents etc., used by selected bidder for RISL shall be the legal properties of RISL.

3. Cooperation and Provision of Information during the exit management period i. The selected bidder will allow RISL or its nominated agencies access to the information

reasonably required to define the current mode of operation associated with the provision of the services to enable RISL or its nominated agencies to assess the existing services being delivered.

ii. The selected bidder shall provide access to copies of all information held or controlled by them which they have prepared or maintained in accordance with the Project Implementation, the Operation and Management SLA and SOWs relating to any material aspect of the services provided by the selected bidder. RISL or its nominated agencies shall be entitled to copy all such information comprising of details pertaining to the services rendered and other performance data. The selected bidder shall permit RISL or its nominated agencies and/ or any replacement operator to have reasonable access to its employees and facilities as reasonably required by RISL or its nominated agencies to understand the methods of delivery of the services employed by the selected bidder and to assist appropriate knowledge transfer.

4. Confidential Information, Security and Data The selected bidder will promptly on the commencement of the exit management period supply to RISL or its nominated agencies the following: i. Documentation relating to Intellectual Property Rights;

ii. Project related data and confidential information; iii. All current and updated data as is reasonably required for purposes of RISL or its nominated

agencies transitioning the services to its replacement selected bidder in a readily available format nominated by RISL or its nominated agencies; and

iv. All other information (including but not limited to documents, records and agreements) relating to the services reasonably necessary to enable RISL or its nominated agencies, or its replacement operator to carry out due diligence in order to transition the provision of the services to RISL or its nominated agencies, or its replacement operator (as the case may be).

v. Before the expiry of the exit management period, the selected bidder shall deliver to RISL or its nominated agencies all new or up-dated materials from the categories set out above and shall not retain any copies thereof, except that the selected bidder shall be permitted to retain one copy of such materials for archival purposes only.

5. Transfer of certain agreements i. On request by Procuring entity or its nominated agencies, the selected bidder shall effect such

assignments, transfers, innovations, licenses and sub-licenses as Procuring entity or its nominated agencies may require in favour of procuring entity or its nominated agencies, or its replacement operator in relation to any equipment lease, maintenance or service provision agreement between selected bidder and third party leasers, operators, or operator, and which


of 166

are related to the services and reasonably necessary for carrying out of the replacement services by RISL or its nominated agencies, or its replacement operator.

ii. Right of Access to Premises: At any time during the exit management period and for such period of time following termination or expiry of the SLA, where assets are located at the selected bidder’s premises, the selected bidder will be obliged to give reasonable rights of access to (or, in the case of assets located on a third party's premises, procure reasonable rights of access to RISL or its nominated agencies, and/ or any replacement operator in order to inventory the assets.

6. General Obligations of the selected bidder i. The selected bidder shall provide all such information as may reasonably be necessary to effect

as seamless during handover as practicable in the circumstances to RISL or its nominated agencies or its replacement operator and which the operator has in its possession or control at any time during the exit management period.

ii. The selected bidder shall commit adequate resources to comply with its obligations under this Exit Management Clause.

7. Exit Management Plan i. The selected bidder shall provide RISL or its nominated agencies with a recommended exit

management plan ("Exit Management Plan") which shall deal with at least the following aspects of exit management in relation to the SLA as a whole and in relation to the Project Implementation, the Operation and Management SLA and SOWs.

ii. A detailed program of the transfer process that could be used in conjunction with a replacement operator including details of the means to be used to ensure continuing provision of the services throughout the transfer process or until the cessation of the services and of the management structure to be used during the transfer; and

iii. Plans for the communication with such of the selected bidder's, staff, suppliers, customers and any related third party as are necessary to avoid any material detrimental impact on RISL operations as a result of undertaking the transfer; and

iv. If applicable, proposed arrangements and Plans for provision of contingent support in terms of business continuance and hand holding during the transition period, to RISL or its nominated agencies, and Replacement Operator for a reasonable period, so that the services provided continue and do not come to a halt.

v. The Bidder shall re-draft the Exit Management Plan annually after signing of contract to ensure that it is kept relevant and up to date.

vi. Each Exit Management Plan shall be presented by the selected bidder to and approved by RISL or its nominated agencies.

vii. In the event of termination or expiry of SLA, Project Implementation, Operation and Management SLA or SOWs each party shall comply with the Exit Management Plan.

viii. During the exit management period, the selected bidder shall use its best efforts to deliver the services.

ix. Payments during the Exit Management period shall be made in accordance with the Terms of Payment Clause.

x. It would be the responsibility of the selected bidder to support new operator during the transition period.

24) Knowledge of Site Conditions

The Bidder’s undertaking of this Contract shall be deemed to mean that the Bidder possesses the knowledge of eSign and CA Solution related requirements as stipulated in the RFP Document including but not limited to environmental, demographic, physical conditions and all criteria required to meet the design of such a system. Bidder shall be deemed to have understood the requirements and have satisfied himself with the data contained in the Bidding Documents, the quantities and nature of the works and materials necessary for


of 166

the completion of the works, etc., and in-general to have obtained himself all necessary information of all risks, contingencies and circumstances affecting his obligations and responsibilities therewith under the Contract and his ability to perform it. It is required of the bidder to visit both the PR and DR sites and spend sufficient time to study and understand the site conditions. However, if during the process of site preparation and installation of the equipment, as required by RISL, Bidder detects any obstructions affecting the work, Bidder shall take all measures to overcome them. Bidder shall be deemed to have satisfied himself as to the correctness and sufficiency of the Contract Price for the works. The consideration provided in the Contract for the Bidder undertaking the works shall cover all the Bidder’s obligation and all matters and things necessary for proper execution and maintenance of the works in accordance with the Contract and for complying with any instructions which RISL’s Representative may issue in accordance with the connection therewith and of any proper and reasonable measures which the Bidder takes in the absence of specific instructions from RISL’s Representative.

25) Adherence to safety procedures, rules regulations and restriction Bidder shall comply with the provision of all laws including labour laws, rules, regulations and notifications issued there under from time to time. All safety and labour laws enforced by statutory agencies and by RISL shall be applicable in the performance of this Contract and Bidder shall abide by these laws. Bidder shall take all measures necessary or proper to protect the personnel, work and facilities and shall observe all reasonable safety rules and instructions. RISL’s employee also shall comply with safety procedures/policy. Bidder shall report as soon as possible any evidence, which may indicate or is likely to lead to an abnormal or dangerous situation and shall take all necessary emergency control steps to avoid such abnormal situations. Bidder shall also adhere to all security requirement/regulations of RISL during the execution of the work. Access to RISL’s sites should be strictly restricted in the following manner: 8. No access to any person except one explicitly authorized by RISL should be allowed entry. Even if

granted, access should be restricted to the pertaining equipment of RISL only and access to any other equipment must be strictly precluded by necessary means, locks, video surveillance, etc.

9. No access to any person (even if authorized by RISL) should be allowed without being unaccompanied by a security staff at all times during his/her presence in the site area and subject to recorded video surveillance. Records of such surveillance shall be maintained by the Bidder for review by RISL as and when required.

10. No access to any employee of the Bidder, except the essential staff who has genuine work- related need, should be given. All such access should be logged in a loss-free manner for permanent record with unique biometric identification of the employee to avoid misrepresentations or mistakes.

26) Intellectual Property Rights

RISL shall own and have a right in perpetuity to use all Intellectual Property Rights which have arisen out of or in connection with the implementation of this Contract, including all processes, products, software, specifications, reports, drawings and other documents which have been developed by the Bidder during the performance of Services and for the purposes of inter-alia use or sub-license of such Services under this Contract. The Bidder undertakes to disclose all Intellectual Property Rights arising out of or in connection with the performance of the Services to RISL and execute all such agreements/documents and file all relevant applications, effect transfers and obtain all permits and approvals that may be necessary in this regard to effectively transfer and conserve the Intellectual Property Rights of RISL. As further clarification, it may be stated that any software, tool, patch or utility developed on bespoke basis for the purposes of execution of this contract; shall be the sole property of RISL including the source code and the accompanying documentation. If RISL desires, Further, Bidder shall be obliged to ensure that all approvals, registrations, licenses, permits and rights which are inter-alia necessary for use of the infrastructure installed by the Bidder, the same shall


of 166

be acquired in the name of RISL, prior to termination of this Contract and which shall be assigned by RISL to the Bidder for the purpose of execution of any of its obligations under the terms of the Bid or this Contract. However, subsequent to the term of this Contract, such approvals etc. shall endure to the exclusive benefit of RISL. Bidder shall ensure that while it uses any software, hardware, processes or material in the course of performing the Services, it does not infringe the Intellectual Property Rights of any person and Bidder shall keep RISL indemnified against all costs, expenses and liabilities howsoever, arising out of any illegal or unauthorized use (piracy) or in connection with any claim or proceedings relating to any breach or violation of any permission/license terms or infringement of any Intellectual Property Rights by the Bidder during the course of performance of the Services.


of 166

7. SPECIAL TERMS AND CONDITIONS OF TENDER & CONTRACT 7.1 Acceptance Criteria The successful bidder shall achieve operational acceptance of the complete CA solution in accordance with the time schedule specified in the implementation schedule, scope of work, technical requirements, design considerations section and any refinements made in the agreed and finalized project plan, or within such extended time to which Bidder has been provided. As soon as the System, or any subsystem, has, in the opinion of Bidder, been delivered, Pre-commissioned, and made ready for commissioning and operational acceptance Testing in accordance with the technical requirements of the RFP as per the agreed and finalized Project plan, selected bidder shall notify RISL in writing. RISL shall, after receipt of Bidder’s notice, either issue an installation certificate, stating that the system, or major component or subsystem (if Acceptance by major component or subsystem) has achieved Installation by the date of Bidder’s notice under or notify Bidder in writing of any defects and/or deficiencies, including, but not limited to, defects or deficiencies in the interoperability or integration of the various components and/or subsystems making up the System. Bidder shall use all reasonable endeavors’ to promptly remedy any defect and/or deficiencies that RISL has notified the Supplier of. Bidder shall then promptly carry out retesting of the system or subsystem and, when in Bidder’s opinion the system or subsystem is ready for commissioning and operational acceptance testing, notify RISL in writing, in accordance with RFP. The procedure shall be repeated, as necessary, until an Installation certificate is issued. The following should be provided as ‘for acceptance’ other than documents specified by RISL or agreed between RISL & bidder:

S. No Solution Component Acceptance Criteria 1. All Hardware & Security Components 1. Installation and commissioning of all the Hardware &

Software Supplied as part of the Project must be clearly documented.

2. Functional Acceptance Criteria – Demonstration of tasks, business processes or functions which RISL has listed out in RFP as Functional & Non Functional requirement and Design Considerations.

3. Submission of Manuals & Architecture Design & Run Book to RISL.

4. Training to RISL Personnel is complete as per the project plan & bidders proposal.

2. CA Certificate Life Cycle Management System

1. Installation and commissioning of all the Hardware & Software Supplied as part of the Project must be clearly documented.


3. Testing must be complete: 4. Summary of test cases and execution results to prove

that the acceptance criteria have been met. 5. Test Plan Document with test execution results. 6. User acceptance testing (UAT) has been

completed and the Senior User/Project Executive has signed off on user acceptance testing.


of 166



3. OCSP Solution 1. Installation and commissioning of all the Hardware & Software Supplied as part of the Project must be clearly documented.







4. Time Stamping 1. Installation and commissioning of all the Hardware & Software Supplied as part of the Project must be clearly documented.







5. eSign Solution 1. Acceptance of SRS by RISL. 2. Installation and commissioning of all the Hardware &

Software Supplied as part of the Project must be clearly documented.


4. Testing must be complete:


of 166

5. Summary of test cases and execution results to prove that the acceptance criteria have been met.

6. Test Plan Document with test execution results. 7. User acceptance testing (UAT) has been




6. Go Live of Complete System 1. Successful completion of Audit by CCA empanelled / deputed Auditor.

2. Integration of CA Lifecycle application along with Time Stamping, OCSP & eSign services.

3. At least 5000 DSC’s should be issued successfully by the installed system.

4. 2 weeks Logs should be stored and handed over to RISL.

5. Minimum 4 weeks of SLA Reports, Helpdesk report & Reports from SOC operations team is submitted to RISL.

6. Backup & Restore Plan and Procedure document should be submitted to RISL & approved by RISL.

7. Business Continuity Plan (BCP) is in place (to be used in situations where the CA system is unavailable at PR site for whatever reason) and accepted by RISL.

7.2 Payment Terms and Schedule 7.2.1 All the payments shall be made by RISL to Bidder except as otherwise provided in the RFP after

deducting all taxes including TDS, as per laid down provisions from time to time. All the payment shall be in Indian Rupees. The detailed payment terms are given below.

7.2.2 RISL will release the payment after receiving the undisputed invoice on completion of the phase / period to the satisfaction of RISL, after deduction of any charges such as penalties as per “Section 10: SERVICE LEVEL AGREEMENT” etc. No advance payments will be made. Further, it may be noted that the mentioned criteria is only for the purpose of effecting agreed price payment. The selected Bidder shall cover the entire scope including deliverables mentioned in the RFP.

7.2.3 Payment schedule – As per Chapter 4 of the RFP. 7.2.4 All payments would be made on actual basis only. 7.2.5 The selected bidder’s request for payment shall be made to the purchaser in writing, accompanied

documents mentioned in point d below, describing, as appropriate, the services performed, and by the required documents submitted pursuant to general conditions of the contract and upon fulfilment of all the obligations stipulated in the Contract.

7.2.6 Documents Required, whichever applicable along with documents for desired deliverables, to be submitted to RISL for Payment (in Triplicate):

a. Module Wise Monthly Team Attendance Reports for the quarter b. Module Wise Monthly Team Review Report for the quarter c. Individual Order Delivery Report and Other related Deliverables for the quarter d. Bills and Invoices for the quarter


of 166

7.2.7 The currency or currencies in which payments shall be made to the selected bidder under this Contract shall be Indian Rupees (INR) only.

7.2.8 All remittance charges will be borne by the selected bidder. 7.2.9 In case of disputed items, the disputed amount shall be withheld and will be paid only after

settlement of the dispute. 7.2.10 Any penalties and/or liquidated damages, as applicable, for delay and non-performance, as

mentioned in this bidding document, will be deducted from the payments for the respective deliverables.

7.2.11 Taxes, as applicable, will be deducted/paid as per the prevalent rules and regulations.

7.3 Service Level Standards/ Requirements/ Agreement SLA shall come into existence after the contract is signed between RISL & successful bidder. Effectiveness of SLA shall begin with contract signing & shall end after the exit management. Quarterly payment is linked to the compliance with the SLA metrics. SLA shall be calculated to arrive at the amount payable to Bidder for each quarter. For purposes of this Service Level Agreement, the definitions and terms as specified in the contract along with the following terms shall have the meanings set forth below: 7.3.1 "Availability" shall mean the time for which the services and facilities offered by Bidder are

available for conducting operations from the solution. 7.3.2 “Downtime” is the time the services and facilities are not available to RISL and excludes the

scheduled outages planned in advance for the solution. 7.3.3 “Incident” refers to any event / abnormalities in the functioning of the solution / Services that

may lead to disruption in normal operations. 7.3.4 “Recovery Time Objective (RTO)” refers to the targeted duration of time and a service level

within which a business process must be restored after a disaster (or disruption) in order to avoid unacceptable consequences associated with a break in business continuity.

7.3.5 “Recovery Point Objective (RPO)” refers to the maximum targeted period in which data might be lost from an IT service due to a major incident.

7.3.6 Severity for Problem / incidents: The severity of a problem request or defects fixes would be based on the business impact of the problem.

7.4 SLAs for the Post-Implementation Phase

7.4.1 Severity Classification

IR Classification

Description Response Time

Resolution Time

Severity 1 Most Critical

Severe problem affecting production, demanding immediate attention. Business risk is high.

10 Minutes. 30 Minutes.

Severity 2 Critical

System degradation that slows down operations. Problem affecting production systems, demanding immediate attention. Customer or IT service has been affected. Business risk is moderate to low. SLA 99.99%

30 Minutes. 1 Hour

Severity 3 Important

Other problems with no business impact. SLA 99.5%. Shall include components from production infrastructure whose have failed however operations is not impacted.

1 hour 4 hours


of 166

Severity 4 Minor

Other problems with no business impact. SLA 98% 4 hour 1 Day

7.4.2 Penalty Calculation Penalty will be calculated on Monthly basis based on following criticality levels:

S. No

Service Level category

Number of Defaults up to or Part thereof

Corresponding Penalty

1. Most Critical 1 1 % of Quarterly payment 2. Critical 1 0.75 % of Quarterly payment 3. Important 2 0.5 % of Quarterly payment 4. Minor 3 0.25 % of Quarterly payment

7.4.3 Services Priorities (RTO & RPO)

Service Area Criteria & Criticality RTO RPO

Directory / Repository

Most Critical (PKI Users need to know about Public Key / DSC of an individual for integrating into various applications)

To be available 24x7x365, RTO would be 10 minutes

No data loss as PR and DR site shall be in sync

CRL Management: Generating Publishing of CRL Availability

Most Critical (Any application may need the latest and updated CRL for verification of certificate status while signing and trusting e- transactions)

To be available 24x7x365, RTO would be 10 minutes

RA Web Servers at PR site and DR site have been put in sync, so RPO has null value

DSC Revocation/ Suspension

Most Critical (As per CPS revocation / suspension request to be processed within 72 hours of receiving the request)

After 48 hours of continuous failure of Raj eSign operations at PR site, it is recommended to start operations from DR site. RTO is < 72 hours.

All servers at PR site and DR site have been put in sync but for any eventuality the latest available backup shall be taken as RPO.

Routine / Scheduled Generation of CRL even if no DSC has been revoked

Most Critical (The Routine / scheduled generation of CRL takes place on a weekly basis and the next scheduled date for updating the CRL is given in the next update information, available in CRL.

RTO has to range from 0 to 7 days, depending upon the next scheduled date for updating the CRL. Operations need to be started from DR site accordingly.


DSC issuance Critical (Depending upon the business compulsions, the issuance of DSCs from DR site shall be decided by RISL Management)

Requirement / Timeframe to be decided by Raj eSign


OCSP Most Critical To be available To be available 24x7x365, RTO would be 10 minutes

All servers at PR site and DR site have been put in sync but


of 166

for any eventuality the latest available backup shall be taken as RPO.

eSign Services Most Critical To be available 24x7x365, RTO would be 10 minutes


Time Stamping Most Critical To be available To be available 24x7x365, RTO would be 10 minutes


7.4.4 Expected SLA for CA Services

Service Area Activity SLA Measurement

SLA failure indicator

IR Classification

Digital Certificate Life Cycle Application Availability

Monitoring, Maintenance and resolution

24x7x365 The uptime is below the threshold of 24x7x365


OCSP shall provide a response in ten seconds (max) under normal operating conditions & shall have performance >300 requests per second.

OCSP Request Handling



Time stamping solution shall be able to create timestamps with RSA 2048 bit (and higher) signatures at a rate of more than 150 per second

Timestamps with RSA 2048 bit



eSign Solution shall have performance >200 requests per second

Signing Requests 24x7x365 The uptime is below the threshold of 24x7x365


Audit Compliance Various audits of Raj eSign conducted by RISL or by RISL appointed third party or by regulator

For each High risk observations in the audit

High risk observation


Audit Compliance Various audits of Raj Non- Non- Severity 2


of 166

eSign conducted by RISL or by RISL appointed third party or by regulator.

compliance to Audit observations

compliance to audit observations.

Critical

Other services not covered above but are part of the RFP

As indicated in RFP. For the Project Period

Non-compliance Severity 2 Critical

Deliverables in the RFP - Deliverables as desired.

Failure to provide the services / part delivery


7.4.5 Expected SLA for eSign Services The purpose of these SLAs is to define the level of service which is expected from the eSign Service Provider to be provided to Application Service Provider (ASP). However, these are subject to change and shall be mutually decided by the respective ASPs and ESPs (RISL) as per ASP need and requirement at the time of signing of Agreement. The solution provider has to comply these SLAs specific to e-Sign Service.

Measurement Definition Target Penalty Availability of ESP applications to facilitate UID authentication and e-Signing

Uptime = { 1 – [(Application Downtime)/ (Total Time)]} Total time shall be measured on 24*7 basis Downtime required for maintenance, new initiatives undertaken by ASP or for performance enhancement measures shall be done after deciding in advance by ASP & ESP Downtime shall be measured from the time the application become unavailable (due to any reasons whatsoever attributable to ESP) for business processing to the end user or ASP to the time it becomes fully available for the above stated business processes

Minimum 99.9% up time measured on a monthly basis

No Penalty

>=99.5% to <99.9% up time measured on a monthly basis

0.5% of monthly payment for respective ASP








of 166

<95.0% up time measured on a monthly basis

4.0% of monthly payment for respective ASP and contract will be reviewed

ESP response time* *Note: The activities not under direct control of ESP will not be considered for SLA calculation. For example, if ASP/ UIDAI response is delayed due to specific reasons, the service provider will not be responsible

The ESP receiving the request from the ASP and sending the request back to ASP. The time taken by the UIDAI will be excluded from this request and the entire operation should ideally take 10 seconds

Minimum 98% of transactions are completed in the designated time

No Penalty

<=98.0% to >95.0% Transactions are completed in the designated time

1.0%of monthly payment for respective ASP

<=95.0%to>90.0% transaction are completed in the designated time


<=90.0% to >85.0% Transactions are completed in the designated time


<85% Transactions are completed in the designated time


Incident Management Incidents logged by ASP should be resolved within a stipulated time The time stipulated for solving the incident would vary depending upon the severity level. The severity level as well as the time required to solve each of it needs to be decided mutually by ASP and ESP. Response time is the time taken by ESP to acknowledge the incident raised by ASP. Ideally for high priority incidents it should be within 30 minutes and between 30-60 minutes for others Resolution time is the time taken by ESP to come up with a solution for the incident raised by ASP.

Minimum 98% of the incidents are handled effectively

No Penalty

<=98.0%to >95.0% incidents are handled effectively


<=95.0%to >90.0% incidents are handled effectively


<=90% incidents are handled effectively



of 166

Change Management for application integration and updating

Any change request (changes in application, integration) should be adhered to as per the agreed timelines. ASP and ESP may discuss the timeline for the implementation, integration testing, and depending on the complexity of change may mutually agree on the timelines

Minimum 99% changes should be implemented as per agreed timelines

No Penalty

<99% changes are implemented as per agreed timelines


DR Drill To be conducted half yearly or yearly. The frequency of DR drills to be performed can be mutually agreed upon by the ASP and ESP. This is being done to make sure ASP has the confidence in the operations of ESP

100% of the time the drill happens as per schedule

No Penalty

Anomaly in the above schedule


Compliance to CCA guidelines

Closing the audit observations identified in the audit of ESP

For major or high non-compliance to CCA Guidelines


7.4.6 SLA for Performance of Hardware & Security Components

No. Measurement Definition Target Penalty 1. ALL Raj eSign

Infrastructure including Servers & related components including Firewall, etc.

Total Time shall be measured on 24*7 basis. Any downtime for maintenance shall be with prior written intimation to RISL.

Minimum 99.99 % up time measured by EMS. Bidder needs to submit weekly availability reports.

1% of Quarterly payment

2. Biometric Access Control

Total Time shall be measured on 24*7 basis. Any downtime for maintenance shall be with prior written intimation to RISL.

Retention of Access Logs for a period of 1 year on system.

0.5 % of Quarterly payment

3. CCTV System Total Time shall be measured on 24*7 basis. Any downtime for maintenance shall be with prior written intimation to RISL.

Retention of Log of Camera for minimum 3 Years (1 year on system)

0.5 % of Quarterly payment


of 166

7.4.7 SLA for Quality of Services No. Measurement Definition Target Penalty Application Maintenance 1. Scheduled

Maintenance Measures timely maintenance of the ICT Infrastructure equipment Bidder shall provide a detailed ICT Infrastructure maintenance plan on the commencement of the project.

100 % of scheduled maintenance should be carried out as per maintenance plan submitted by the SI. Any scheduled maintenance needs to be Planned and intimated at least 2 working days in advance and must be Approved by RISL.

1% of the Quarterly Pay-out for “noncompliance)

Manpower Availability:- 2. Resource

availability for bidder Services

No. of shift days for which resource present at the designated location / Total no. of shift days.

>99% averaged over all resources designated for bidder services and calculated on a quarterly basis.

No Penalty

>=98.5 % to < 99% averaged over all resources designated for bidder services and calculated on a quarterly basis.

2% of the “Component Quarterly Pay-out”

>=97 % to < 98.5% averaged over all resources designated for bidder services and calculated on a quarterly basis.


>=95.5 % to < 97% averaged over all resources designated for bidder services and calculated on a quarterly basis.


< 95.5 % averaged over all resources designated for bidder services and calculated on a quarterly basis.

Event of Default & Escalation to RISL and Bidder’s Management


of 166

Note: Any approved leave by RISL shall not be treated as absence and shall not be used for SLA calculation.

7.4.8 SLA for Support Services No. Measurement Definition Target Penalty 1 Response time “Response Time”, means time

taken (after the request has been logged at the helpdesk and escalated to bidder team) by the respective bidder / RISL staff in responding to the call and updating the status of the call in the Help Desk system. The response time would include: Call diagnosis Categorization into problem request/change requests for defect fixes Assign severity levels to PRs Tentative timelines for further action.

At least 99% of the calls within 30 minutes

No Penalty

>= 97% to < 99% of the calls within 90 minutes

1% of the Component Quarterly Pay-out”

>= 95% to < 97% of the calls within 120minutes

2% of the Component Quarterly Pay-out

>= 90% to < 95% calls Within 180 minutes


<90% calls Within 240 minutes


2 Resolution Time

“Resolution Time”, means time taken by Bidder staff to troubleshoot and fix the problem/defect from the time the call has been escalated to Bidder team till the delivery of the solution to RISL for UAT and subsequently updates the status of the call in the Help Desk system.

Level of Call – Critical At least 99% calls to be resolved within 30 mins

No Penalty

>= 97% to < 99% calls to be resolved within 90 mins

1% of the component Quarterly Pay Out



< 95% calls to be resolved within 180 Mins


Any 3 consecutive months of any of the above default may lead to termination of contract.

Level of Call – High At least 99% calls to be resolved within 90 Mins

No Penalty


of 166


0.50% of the Component Quarterly Pay-out

>= 95% to < 97% calls to be resolved within 180 Mins


< 95% calls to be resolved within 240 Mins



Level of Call–Medium At least 99% calls to be resolved within 180 Mins

No Penalty


0.5% of the “Component Pay-out”


0.75% of the “Component Pay-out”

< 95% calls to be resolved within 1 working days

1% of the “Component Pay-out”


Level of Call–Low At least 99% calls to be resolved within one 240 Mins

No Penalty




of 166

>= 95% to < 97% calls to be resolved within One days


< 95% calls to be resolved within Three days


Any 3 consecutive months of any of the above default will lead to termination of contract.

7.4.9 SLA for End user Helpdesk Services No. Measurement Definition Target Penalty 1 Response time “Response Time”, means time taken

(after the request has been logged at the helpdesk and escalated to bidder team) by the respective bidder / RISL staff in responding to the call and updating the status of the call in the Help Desk system. The response time would include: Call diagnosis Categorization into problem request/change requests for defect fixes Assign severity levels to PRs Tentative timelines for further action.

At least 99% of the calls on receipt of call/ communication

No Penalty


1% of the “Component Quarterly Pay- out”



>= 90% to < 95% calls within 120 minutes


<90% calls within 120 minutes


2 Resolution Time

“Resolution Time”, means time taken by Bidder staff to troubleshoot and fix the problem/defect from the time the call has been escalated to Bidder team till the delivery of the solution to RISL for UAT and subsequently updates the status of the call in the Help Desk system.

At least 99% calls to be resolved on call / communication response

No Penalty





<95% calls to be resolved within 180 mins



of 166

Any 3 consecutive months of any of the above default will lead to Termination of contract.

7.4.10 SLA for EMS, Log and Service Desk Monitoring All events must be monitored and resolved on a 24x7 basis. The EMS system shall cover the following:

1. Virus/Malware outbreak 2. Application/Website uptime and performance monitoring 3. All hardware/Infrastructure uptime and performance monitoring 4. Customer account related incidents 5. Customer inquiries.

Compliance Procedure

No. Measurement Definition Target Penalty 1 Incident Reporting Any failure/incident on any

part of the solution shall be communicated immediately to RISL as an exceptional report giving details of impact, if any. Quarterly measurement.

100% incidents to be reported to RISL within 1 hour with the cause and action for the incident.

No Penalty

Delay beyond an hour 1% of the “Component Quarterly Pay-out” for every hour’s delay on an incremental basis.

100% incident log to be submitted to RISL that comprises exceptional & normal reportable activities by 5th of every Quarter for the previous quarter.

No Penalty

Delay beyond the date of submission

1% of the “Component Quarterly Pay-out” for every hour’s delay on an incremental basis.

2 Change Management

Measurement of quality and timeliness of changes to the solution. Quarterly measurement

100% of changes should follow formal change control procedures. All changes need to be approved by RISL.



of 166

All changes should be implemented on time and as per schedule & without any Disruption to business.


100% incident log to be submitted to RISL that comprises exceptional & normal reportable activities by 5th of every Quarter for the previous quarter.

No Penalty



3 Implementation of Audit Recommendations

Implementation of audit recommendations by RISL or its auditor which have been agreed by Bidder & RISL to be implemented. Half-yearly measurement.

100% on time to be implemented as per timelines agreed upon with RISL or as stipulated by the regulatory framework.


4 Adherence to Backup Policy

Bidder shall adhere to the Backup Policy developed in consultation with RISL. Quarterly measurement.

100% adherence to Backup policy.

1% of the “Quarterly Pay-out” for every non-compliance incident.

5 BCP / DR Drill Bidder shall adhere to the DR Policy developed in consultation with RISL. Quarterly measurement DR Drill Half yearly

100% of the time the drill should happen as per schedule and as per request of RISL.

1% of the “Quarterly Pay-out” for every non-compliance incident


of 166

6 Internal Periodic Audit

Bidder shall adhere to the Periodic Internal audit such as VAPT, developed in consultation with RISL Quarterly measurement.

100% of the time the drill should happen as per schedule and as per request of RISL.

1% of Quarterly payment

7.4.11 SLA for Audit

No. Measurement Definition Target Penalty 1 Internal Audit by

Bidder Bidder shall conduct the periodic Internal audit such as quarterly audit of the solution, quarterly VAPT, in consultation with RISL. Quarterly measurement.

100% of the time the internal audit should happen and report including key observations and remediation steps submitted to RISL within 21 days after the end of quarter.

1% of Quarterly payment.

100% recommendations should be addressed in the following audit cycles.


2 Implementation of Audit recommendations

Implementation of audit recommendations by RISL or its auditor which have been agreed by Bidder & RISL to be implemented. Half-yearly measurement

100% on time to be implemented as per timelines agreed upon with RISL.

1% of the “Quarterly payment” for every non-compliance incident

7.4.12 SLA for other services

No. Measurement Definition Target Penalty 1 Patch

Management Bidder shall conduct fortnightly patch management for all components of the Raj eSign infrastructure.

100% of the time the Patch management should be carried out including reporting to the Raj eSign Team every fortnight.


2 Hardware Replacement

Bidder to replace hardware within 3 working daysof hardware failure.

100% on time to be implemented.

1% of the “Quarterly payment” for every non-compliance incident


of 166

7.4.13 SLA for Raj eSign Infrastructure Help Desk Services S. No

Measurement Definition Measurement Interval

Target Penalty

1. Resolution Time “Resolution Time”, means time taken by Bidder staff to troubleshoot and fix the problem from the time the call has been logged at the Helpdesk till the time the problem has been fixed. The Help Desk will typically receive calls from Raj eSign for IT infrastructure support such as system administration, server not accessible, ad-hoc report generation etc.

Quarterly 100% calls to be responded to within 1 hour

No Penalty

100% calls to be resolved within 2 hours

No Penalty

Unresolved Call 0.5% of the quarterly Operations & Maintenance Cost for every 60 minutes of delay after 2 hours on an incremental basis for every unresolved call.

7.4.14 SLA for End User Help Desk Services

S. No Measurement Definition Measurement Interval

Target Penalty

1. Resolution Time

“Resolution Time”, means time taken by Bidder staff to troubleshoot and fix the problem from the time the call has been logged at the Helpdesk till the time the problem has been fixed. The Help Desk will typically receive calls from end users related to Raj eSign services support such as account creation, deletion, DSC generation, eSign etc.

Quarterly 100% calls to be responded to within 30 minutes

No Penalty

100% calls to be resolved within 1 hour

No Penalty

Unresolved call

0.5% of the quarterly Operations & Maintenance Cost for every 60 minutes of delay after 1 hour on an incremental basis for every unresolved call.


of 166

7.4.15 SLA for Compliance and Reporting Procedures S.No Measurement Definition Measurement

Interval Target Penalty

1. Submission of MIS Reports

Bidder shall submit the MIS reports as defined in Scope of Work

Quarterly All MIS Reports for the previous quarter shall be submitted by 5th of next quarter

No Penalty


0.5% of the quarterly Operations & Maintenance Cost for every day’s delay on incremental basis.

2. Adherence to Security policy

Bidder shall adhere to the Security policy developed in consultation with Raj eSign.

Quarterly 100% Compliance.

No Penalty

Non Compliance. 0.5% of the quarterly Operations & Maintenance Cost for every day’s delay on incremental basis.

3. Scheduled Maintenance

Measures timely maintenance of the ICT Infrastructure equipment installed at the PR site. Bidder shall provide a detailed ICT Infrastructure maintenance plan on the commencement of the project.

Quarterly 100 % of scheduled maintenance should be carried out as per maintenance plan submitted by Bidder. Any scheduled maintenance needs to be planned and intimated to Raj eSign at least 2 working days in advance.

0.1% of the quarterly Operations & Maintenance Cost for every non- compliance


of 166

4. Implementation of Audit Recommendations

Implementation of audit recommendations by RISL or its auditor which have been agreed by bidder to be implemented.

Quarterly 100%ontimeto be implemented as per Timelines agreed upon with bidder.

0.2% of the quarterly Operations & Maintenance Cost for every non Compliance

7.4.16 SLA for Reporting

S.No. Measurement Definition Measurement Interval

Target Penalty

1. Report and Dashboard Report and Dashboard

Periodic reports to be provided to Raj eSign in the prescribed format as required. Periodic reports to be provided to Raj eSign in the prescribed format as required.

Quarterly

Daily Reports: Critical reports should be submitted by 10 AM every day.

Delay in reporting for daily report for more than 2 hours shall incur a penalty of 3% of Operations Cost for the Month per instance.

Daily Reports: Critical reports should be submitted by 10 AM every day.

Delay in reporting by more than 1 day for weekly reports shall incur a penalty of 10% of Operations Cost for the Month.

Monthly Reports: Critical reports should be submitted 5th of each month

Delay in reporting by more than 3 days for monthly reports shall incur a penalty of 10% of Operations Cost for the Month.

Quarterly reports: Continual Improvement Reports : Bidder is expected to improve the operations on an on-going basis. Bidder is expected to provide a quarterly report of the new improvements suggested, action plans, and the status of these

Delay in providing quarterly reports shall lead to 2% of the monthly operation charges.


of 166

improvements to RISL. Improvement areas could include: process changes/ training resulting in efficiency/SLA improvement, new correlation rules to identify threat patterns etc. Quarterly reports need to be provided by the 5th day of each quarter beginning. Daily Report: Provide security dashboard which should give an online view of the all the security devices monitored online and their status.

Delay/inability in providing quarterly reports shall lead to 2% of the monthly operation charges.

Security Dashboard should give the details of Critical/medium events reported by security tools and status on their mitigation.

Delay/inability in providing quarterly reports shall lead to 2% of the monthly operation charges.

Note: Penalty shall be governed by the following conditions:

• The Penalty shall be calculated on a quarterly basis. The Penalty would be calculated on an incremental basis for each component of the entire ICT Infrastructure affected. For example, if the total number of Access Switch affected is 3, the Penalty would be multiplied by 3.

• If the downtime of a particular system affects a secondary system, the bidder has to pay penalty for both.

• The total penalty on the selected bidder shall not be more than 10% of the Project Value.


of 166

ANNEXURE-1: PRE-BID QUERIES FORMAT{to be filled by the bidder} Name of the Company/Firm: Bidding Document Fee Receipt No. ___________ Dated___________ for Rs. _____________/- Name of Person(s) Representing the Company/ Firm:

Name of Person Designation Email-ID(s) Tel. Nos. & Fax Nos.

Company/Firm Contacts:

Contact Person(s) Address for Correspondence

Email-ID(s) Tel. Nos. & Fax Nos.

Query / Clarification Sought:

S.No. RFP Page No.

RFP Rule No.

Rule Details Query/ Suggestion/ Clarification

Note: - Queries must be strictly submitted only in the prescribed format (.XLS/ .XLSX/ .ODF). Queries not submitted in the prescribed format will not be considered/ responded at all by the procuring entity. Also, kindly attach the coloured scanned copy of the receipt towards the submission of the bidding/ tender document fee.


of 166

ANNEXURE-2: BILL OF MATERIALS

SNo Component Primary Site DR Site Core

Zone

Secure

Zone

Web

Zone

Test

Zone

Monitoring

Zone

Core

Zone

Secure

Zone

Web

Zone

Total

Qty.

1. Red Hat Enterprise License

30 30

2. Windows Server (Standard Edition)

25 25

3. Antivirus (Server and Workstation)

100+20 120

4. Backup Software As per CCA Guidelines

5. Enterprise Monitoring Software with Ticketing Tool

200 Ips for Network and Server Monitoring and 20 Technicians for Service Desk

6. CA & eSign Software

Unlimited, perpetual, with 5 years support, upgrade, update

7. Log Collection For 100 Devices

8. Management Software For 200 Devices

9. Patch Management For 120 workstations/servers

10. Database

Microsoft SQL for minimum 32 cores and MySQL for minimum 36 cores

11. HSM 4 2 1 1 1 9

12. Hyper-converged Nodes 8 4 4 6 6 6 3 4 41 13. SSL Server Hardware 1 1 2

14. Backup Server Hardware 1 1 1 1 4 15. Desktops for support team

with Windows 10 and above & MS Office 2016

12 12

16. Laptops for support team with Windows 10 and above & MS Office 2016

3 3

17. Dual Drive Tape Library 1 1 18. Auto Loader 1 1 1 3 19. Tape Media (LTO 6 and

above) 50 50

20. Network Switches 2 2 2 2 1 1 1 11 21. Gateway Switches 2 2 22. InterZone UTM / NGFW 2 2 1 1 1 7 23. Gateway Enterprise

UTM/NGFW/ Firewall 3 3

24. Gateway Router 3 3 25. Server Rack 7 7 26. Cage Area (200 SqFt) 1 1 2 27. Cage Door (Biometric

Enabled) 4 4


of 166

28. Audit As per CCA Guidelines 29. KVM 11 11 30. Monitoring Screen (42") 4 4 31. DC RACK Screen 7 7 32. Jack Panel 7 7 33. Passive & Structured

Cabling As per CCA Guidelines

34. Camera 10 10 35. DVR (capable to store 1

month data) 3 3

36. Crypto USB Token 5000 5000

Hyperconverged Virtual Machine configuration CA SOFTWARE

PS Component VM Config vCpu Mem Disk

1 DB 64 GB, 500 GB, 8 Core 8 64 500

2 OCSP 64 GB, 250 GB, 8 Core 8 64 250

3 TIME 64 GB, 250 GB, 8 Core 8 64 250

4 CA 32 GB, 250 GB, 8 Core 8 32 250

5 Enrolment 32 GB, 200 GB, 8 Core 8 32 200

6 LDAP 32 GB, 500 GB, 4 Core 4 32 500

7 DB 32 GB, 500 GB, 8 Core 8 32 500

8 Application 32 GB, 100 GB, 8 Core 8 32 100 9 Application DB 32 GB, 1.2 TB, 8 Core 8 32 1200

10 Misc Application 32 GB, 100 GB, 8 Core 8 32 100

ESIGN

11 CA Software 64 GB, 250GB, 12 Core 12 64 250

12 eSign Software 64 GB, 250GB, 12 Core 12 64 250

13 CA DB 128 GB, 10 TB, 12 Core 12 128 10000

14 eSign DB 128 GB, 10 TB, 12 Core 12 128 10000

15 CA Offline 8 GB, 250 GB, 4 Core 4 8 250

16 eSign and Aadhar 128 GB, 500 GB, 16 Core 16 128 500

17 LDAP 64 GB, 10 TB, 8 Core 8 64 10000

18 eSign Application 64 GB, 250 GB, 12 Core 12 64 250 19 DB 64 GB, 750 GB, 12 Core 12 64 750

SSL

20 CA Software 8 GB, 250 MB, 4 Core 4 8 250 21 DB 8 GB, 250 MB, 4 Core 4 8 250


of 166

22 Application 8 GB, 250 MB, 4 Core 4 8 250

23 LDAP 8 GB, 250 MB, 4 Core 4 8 250

Key Notes-

All Hardware is to be proposed with 5 year onsite warranty.

All software excluding Open source & Core application’s product are to be quoted with perpetual licenses

ONLY and including 5 year support subscription. For Core applications and open source product vendor has

to quote the same in perpetual nature only.

Above is the minimum mandatory purchase in the area of hardware, software and support infrastructure

however the eventual BOM must comply to CCA Guidelines and eventual solution proposed


of 166

ANNEXURE-3: DIGITAL CERTIFICATE LIFECYCLE MANAGEMENT, ONLINE CERTIFICATE STATUS AND TIME STAMPING AUTHORITY SOLUTIONS The below mentioned section provides the requirement for CA Solution. Bidder shall propose solution which must meet the mandatory requirements. Not meeting the mandatory requirements, shall lead to disqualification of bids 3.1 General Requirements for Digital Certificate Lifecycle Management, Online Certificate Status and

Time Stamping Authority solutions

S.No. General Requirements for Digital Lifecycle Management, Online Certificate Status and Time Stamping Authority Solutions

Compliant Yes / No.

Readily available, Customizable

Remarks / reference to Data Sheet

1.

All services should be commissioned physically at PR and DR site. Services should have the capability to work in virtualized & non virtualized environment on Intel/AMD (32/64 bits).

2. All services should be logically separate in terms of functionality, database, and interface with Hardware Security Module (HSM) etc.

3. The CA should support a DBMS working on Log Shipping / Instant Replication mode.

4.

The proposed solution for all these services should work in fail–over and switch-over modes i.e. primary site and disaster site should be completely in sync for all the components of these services in terms of systems, application, database etc. and hence services should run from DR site in case there is failure at primary and vice versa.

5.

The proposed solution should have inbuilt process for PKI administrators to test the performance, load, efficiency required for capacity planning and should be provisioned for fine tuning at the level of system, application, database etc. Please provide a report / datasheet on performance benchmarks set for the solution.

7. The proposed solution brands Raj eSign name and / or logo on all public web interfaces.

8. The proposed solution should provide a complete architectural /flow/control/including insertion and update in database and step by step view in the form of manual/document for all services starting from enrolment to delivery, installation, configuration and commissioning.

9.

All services of the proposed solution should generate sufficiently detailed logs with time stamp for each and every activity taking place in the system starting from beginning to end. Logs should


of 166

3.2 Technical Specifications for Digital Certificate Lifecycle Management

S.No. RISL’s Requirements Compliant (Yes/No)

Readily available, Customizable, Not available


A.

Registration of Subject and Creation of Secure Device All DSC applicants are required to get registered themselves with the CSP for issuance of Digital Certificate. Also applicants are also required to undergo different modes of user validation or pre-validation: manual validation (individually or in batch), automatic validation (against a data repository).

1.

The proposed solution should provision for enrolling subjects (remote) on-line in accordance with the DSC Form of Raj eSign enabled with digital signing, verification and storing their request details in digital form securely (digital sign and encryption).

2.

The proposed solution should ensure that different DSC applicant/subscribers are not registered with same email-id i.e. email id must be unique to a subscriber and Multiple DSCs containing the same email-id may be issued where it is established that

be tamper proof, encrypted, their integrity be maintained by digital signature, configurable to retain them for sufficient period and exportable to external media.

10.

The solution should have in-built system to monitor these logs through management console by the authorized person. Logs should be exportable to other standard analysis tools.

11.

The proposed solution should have the provision of perpetual License for production, hot standby, stage located at PR site and DR site and offline site at Pune. No fee shall be paid based on per usage of services or per certificate.

12.

The proposed solution should explain effective, simple and quick provision to upgrade to new version of the product that has been tested in pre-production.

13.

The proposed solution should be in conformance with Indian Information Technology Act 2000 & Subsequent amendments and CCA guidelines namely

X.509 Certificate Policy for India PKI and DSC Interoperability guidelines available on

http://cca.gov.in and should have provision to support future enhancement issued from time to time by CCA office.

http://cca.gov.in/


of 166

these multiple DSCs are being issued to a single/same subscriber.

3.

The solution must support notification to end users through e-mail and SMS (registration/generation/acceptance of application rejection/revocation and expiration of X.509 certificates).

4.

The proposed solution should provide API toolkit for customization of registration process. Bidder may also provide a clear process- flow diagram illustrating how certificates are issued and delivered to the end users.

5. The proposed solution should provision UIDAI based authentication verification of the subject.

6.

The proposed solution should support smart Cards or certificate storage tokens from multiple bidders. Please give a list of vendors, whose certificate storage tokens are supported in the proposed solution.

7.

The proposed solution needs to distribute the challenge- phrase / PIN No. / Password for initializing the corresponding DSC applicant through a different channel / mechanism for both Remote and In- person Applicants in order to avoid impersonation. All cryptographic material between the CSP / RA and the end users / subject should be exchanged using https only.

B. Key Generation & Storage for Issuer Keys (CA Keys)

1.

The proposed solution should support generation of private keys of issuers certificates like Self signed, Certifying Authority, Time Stamping, OCSP Responder, SSL issuer, Code Signer etc. on FIPS 140-2 Level 3 / 4 or higher certified HSM. These keys may be kept on the same HSM or different HSM.

2. Key pair generation should be under dual control and should create a verifiable audit trail by the solution and by the HSM.

3. The proposed solution should provide documentation about the strategy for managing the protection of issuer keys as described above.

4.

The proposed solution should support multiple hardware tokens with different Form Factor for private key storage and safe backup with the idea of cloning the private key for recovery in case of disaster (key blob).


of 166

5.

The proposed solution should provide documentation for security policy for issuer key generation, including the number of people required, their deployment, logistics support, number of copies of private keys to be generated, splitting of private key to enable multiple control over signing events, etc.

6. The solution should provide documentation to elaborate the system/process by which it can be ensured that private key of issuer certificate cannot be compromised under any eventuality.

7. The proposed solution should support multiple formats for CA key storage. Provide detailed documentation as to how this has been achieved.

C. Usage of Issuer Keys/HSM Operation

1. Issuers keys, kept in HSM should enforce manual invoking of HSM for certificate issuance.

D. Key Generation & Storage for Clients

1. The proposed solution must support issuance of X.509 certificates on Smart cards, USB tokens, Soft tokens (PKCS#12), mobile devices, such as tablets and mobile phones.

2. The proposed solution must support issuance of X.509 certificates on mobile devices, such as tablets and mobile phones.

3. The proposed solution must have support for on-site key (Subject’s Place)/off-site key generation.

4. The proposed solution must check the issuance of X.509 certificates to registered device and FIPS 140-2 Level Hardware or Software as stated below in the table

S. No. Type of Certificate with Class

Hardware / Software

1. Code Signing FIPS 140-2 Level -2 Hardware

2. Human Subscriber Signature-class- 1

Software(PKCS#12)


of 166

3. Human Subscriber Signature-class- 2, & 3

FIPS 140-2 Level-2 Hardware

4. Human Subscriber Encryption- class-1

Software(PKCS#12)

5. Human Subscriber Encryption- class -2, & 3


6. SSL-Class-2 Software(PKCS#12)

7. SSL-Class-3 FIPS 140-2 Level-2 Hardware

8. Device/System-Class-2

Software(PKCS#12)

9. Device/SystemL-Class-3


10. Document Signer-Class-2

Software(PKCS#12)

11. Document Signer-Class-3


F Key Update & Replacement for issuer Key (Raj eSign)

1.

The proposed solution should have the facility for Invalidating Raj eSign DSC on key compromise and must have a facility to auto- enrolment for existing DSC holder to issue them new DSC with new issuer key/DSC.

G Key Update & Replacement for Clients

1. The proposed solution should have a well-defined facility for transition for a DSC subscriber/holder to new DSC/key in case of key compromise of subscriber/DSC holder with keeping him informed.

H Certificate History for a user


of 166

1.

As signing keys are updated at regular intervals, it will become necessary to verify a signature created with an earlier key pair. Raj eSign should store copies of every certificate issued to users. The proposed solution should provide means to maintain complete key history of the subscriber for a minimum period of seven years as stated in IT Act 2000.

I Pubic Key Certificate Generation

1.

The proposed solution should have the ability to self-sign root certificates, generate a key pair with validity period, CSR generation for CA, Sub-CA, Time Stamping, OCSP responder. The solution must support multiple issuer certificate/CSR generation for self-sign, for CA, Sub-CA, Time Stamping, OSCP responder etc. This module should work only in offline/ standalone system.

2.

The profiles of issuer certificates and end entities certificates must be configurable strictly in accordance with DSC Interoperability guidelines, accessible at http://cca.gov.in/cca/sites/all/DSC_Interoperability_Guidelines_R2 .5.pdf.

3.

The solution must check subject certificate request duly passed, signed and verified by RA and CA and issue the end entity DSC by signing with issuer private keys. This module should configurable to work in online/offline modes. The profile of DSC must be strictly in accordance with certificate profiles given in http://cca.gov.in/cca/sites/all/DSC_Interoperability_Guidelines_R2 .5.pdf

4. The solution must support incorporation of new certificate profiles based on guidelines issued by CCA from time to time.

5.

The solution must support issuance of DSC to end entities with different Certificate policies/issuer Certificates e.g. SSL Certificates, Code Signing Certificates to be issued by different Certificate/Signer.

6. The proposed solution should be flexible enough to support multiple policies, certificates types, intermediate CA and Sub-CAs.

http://cca.gov.in/cca/sites/all/DSC_Interoperability_Guidelines_R2







of 166

7. The proposed solution must support the publishing of DSC after subscriber consent (online/digital signature) to LDAP directory services/repository of CSP.

J. Certificate Revocation, Suspension Expiry and CRL generation

1.

The proposed solution should allow trusted role to initiate suspension/revocation request on the CA system based on telephonic/email intimation received from DSC holder. The period for suspension of certificate must be configurable. The solutions should support the revocation of the suspended certificate.

2.

The proposed solution shall have provision to receive online request for revocation/suspension and subsequently revoke/suspend a DSC with recording the reason of revocation/suspension.

3. The proposed solution should support bulk revocation of DSCs.

4.

The proposed solution should support sending automated E- mails/SMS Alerts to users whose Digital certificate is going to expire within a time frame (say 45 days) which should also be configurable.

5. The proposed solution should have configurable provision for CA administration to highlight the certificates in the repository that are going to expire shortly.

6.

The proposed solution should have the capability to automatically generate a certificate revocation list CRL after a certificate is revoked / suspended and transmission of revocation/suspension notices to users using email/SMS.

7. The proposed solution should support a configurable option for scheduling CRL generation process. A manual option to generate and update CRL should also be available.

8. The proposed solution should have the ability to update CRLs with event recording. Also the solution should have the ability to update the CRLs upon removing the suspension and recording the events appropriately.

9. The proposed solution should have provision of secure archiving CRL for historical checking.


of 166

K.

Distribution (Push), Publication of Certificate & Revocation List (CRL) The DSCs and CRLs need to be distributed among the PKI community of users, CCA office for legal compliance, OCSP responders etc. They generally fetch DSCs and CRLs from directory service of CSP using the most common protocols such as LDAP & HTTP.

1. The CRLs should be retrievable using CRL DP available in DSC i.e. CRL should be automatically be published to CRL DP.

2. The proposed solution should have the capability to distribute/push CRLs (before expiry) to the designated sites/users using HTTP/LDAP/OCSP responders and designated locations.

3. The proposed solution must support Certificates and CRL submission to CCA office as per prescribed format by CCA office on weekly basis.

4.

The proposed solution should have directory support for x. 500 and LDAPv3, wherein Certificates and CRLs are published. The Solution Provider must specify the directory architecture (s) LDAP and mechanisms for publication of certificates.

5. The proposed solution should support queries to LDAP and report generation/screen display for certificates and CRLs with various parameters.

L. BCP/DR Usage Execution

1.

The proposed solution should address the issues with respect to (i) Hardware failure (ii) Network failure (iii) Software error (iv) DB failure etc at PR site by switching operations automatically from DR site for that failed component.

M. Administration/Management Interface CA administration must support procedures for implementing policies, in and out of band authentication schemes, issuing of multiple certificate types, work flows in connection with certificate requests, upload, revocation, suspension, renewal.

1.

The proposed solution should have the facility to permit Administrators to perform secure remote administration of the CA application with only a digital certificate and using a secure channel only but being in the RISL network.

2. The proposed solution should be configurable for single and dual physical control of certificate generation system events.

3.

The proposed solution should have the facility to assign different administrators with different tasks, i.e. different levels of administration. Roles defined in section 5.2.1 of “X.509 certificate policy for Indian


of 166

PKI”, latest version (presently version 1.2) of which is available at CCA website (cca.gov.in) are required to be part of the solution.

4.

The Proposed CA Solution should allow the CA Administrator authorized to install, configure, and maintain the CA, establish and maintain user accounts; configure profiles and audit parameters; and generate component keys.

5. The Proposed CA Solution should allow CA Officer authorized to request or approve certificates or certificate revocations.

6. The Proposed CA Solution should allow Audit Administrator authorized to view and maintain audit logs.

7. The Proposed CA Solution should allow System Administrator authorized to perform system backup and recovery.

8.

The proposed solution should support the insertion of assurance levels (presently four, it should be configurable for future need) as defined in the roles defined in Section 1.2 of “X.509 Certificate Policy for Indian PKI”, latest version (presently version 1.2) of which is available at CCA Website (cca.gov.in). As of now following assurance level/OIDs are required to be made part of certificate issuance process

id-India PKI ::= 2.16.356.100.2 id-cp ::= 2.16.356.100.2 id-class0 ::= 2.16.356.100.0 id-class1 ::= 2.16.356.100.1 id-class2 ::= 2.16.356.100.2 id-class3 ::= 2.16.356.100.3

N. Audit Trail, Logging & Reporting

1.

The proposed solution should have the provision for audit trail and reporting. Describe audit trail and reporting capabilities in the proposed solution with a flow diagram. Mention the standard it conforms to.

2. The proposed solution should support security of audit logs. Describe how the logs are protected from deletion, modification, tampering etc.

3. The audit log of the CA should be digitally signed by the log application/server.


of 166

4.

The proposed solution should have provision for administrative operations reporting in the audit log. Indicate the ability of the solution to generate reports that describes all administrative operations performed.

5. The proposed solution should have provision to export log information (in encrypted flat file) or some standard tool for supervision.

6.

The offered CA solution must provide flexibility to customize the Audit Log with the provision to include / exclude the following (i) Deletion of security sensitive data (ii) Security Profile changes (iii) System crashes/Hardware failures/other anomalies (iv) Decision to bypass encryption/authentication process or procedures (v) attempt to establish a session (vi) attempts to query or change an operating parameter of the application software or the underlined hardware.

7.

Describe the effect of increase in the audit trail details on the system performance. Indicate extra resource requirements (in terms of hardware and software) for maintaining performance levels in the case that comprehensive audit trail needs to be generated.

8. The proposed solution should support for event notification to trusted role for defined triggers. Describe the facilities for notification on user defined triggers and explain the procedure.

9. The proposed solution should provide consolidated Audit Trail for applications and provide the list of all the possible logs.

10. The proposed solution should provide a Forensic Evidence Audit Tracing facility on a per user level and other parameters.

11.

The proposed solution should support report generation (daily, monthly, yearly, date range wise, as on date) like Certificate Expiry report, issued Certificate report, Declined Certificates report, Revocation/suspension report etc.

O. Standards /references The proposed solution should be compliant with the standards mentioned in IT Act 2000 and its accompanying rules, regulations, guidelines and amendments 2008 thereof. The following standards need to be adhered.

Cryptographic Functions

Cryptographic Algorithm


of 166

Public Key Signature Algorithm

RSA-2048-8192 Bits, ECC, NIST P‐256, P‐384, or P‐521

Hashing SHA-256, 512

PKCS#10 Certificate request syntax (CRS)

Public Key Certificate standard

X.509 v3

Certificate revocation list X.509 CRL v2

Certificate Management Protocol

CMP

Certificate Request Message Format

CRMP

Public Key Infrastructure PKlX

Directory publishing LDAPv3 , LDIF

PKCS #1

Password based Encryption

PKCS #5

certificate reply etc. PKCS #7

Private Key Information Syntax

PKCS #8

Selected Attribute types PKCS #9

Communication with external cryptographic modules

PKCS#11

Vault to store private keys and certificates

PKCS#12

Elliptic Curve Cryptography

PKCS#13

Cryptographic Token Information Format Standard

PKCS#15

X520


of 166

Digital Signature Interoperability Guidelines, Controller of Certifying Authorities India, Version: Release 1.1, August 14, 2009.

CCA-PROF,

Security Requirements for Cryptographic Modules, 1994-01

FIPS 140-2

2. List any proprietary protocols or wrappers that are part of the offer discuss the support for each of the standards clearly & precisely. Also describe variances & extensions, if any, from standards.

3. The proposed solution must have the capability to integrate new standards. Describe how new standards are incorporated in to the functionality of the proposed solution.

P. Cryptographic Algorithm Support

1. The software should be configurable to implement the cryptographic algorithms including the length of the key. Submit documentary evidence in support of the above statement.

2.

The proposed solution should have the provision to support higher key lengths as may be available in the future. Indicate the transition path to integrate the use of higher length keys as and when they are available.

3.

The proposed solution should have provision for royalty-free use of the cryptographic algorithms and applications. Indicate whether there are any restrictions on the cryptographic algorithms including patents/IPR in the proposed solution.

4.

The proposed solution should have support for choice/configurable/hardening of algorithms. Indicate how the proposed solution takes care of the integration of the specific crypto algorithms that may come up in future.

5.

The proposed solution should have support at least for the following algorithms

S.No. Cryptographic Functions

Cryptographic Algorithm

1 Signature RSA-2048 to 8192 Bits, ECC NIST P‐256, P‐384, or P‐521

2 Hashing SHA-256


of 166

Mention the support for each of the algorithms clearly & precisely. Any other proprietary algorithms that are part of the offer may please be mentioned.

Q. Interoperability

1. The solution should have the provision for interoperability with the National Root CA, and other CAs licensed by National Root CA as mandated by CCA guidelines from time to time.

2. The proposed solution should be capable of accepting & processing CSR (Certificate Signing Request (PKCS #10)) generated by other CA solutions/tools.

R. Scalability and Performance

1. The proposed solution should be scalable to support the increase in demand for the issuance/generation of certificates. Mention the level of scalability in terms of load handling capacity.

2.

The proposed solution should have modular architecture to support scalability and performance. Please furnish a clear process flow diagram of the PKI architecture showing the various modules and their interconnection and also explain how the solution may be scaled up to enhance the performance with the addition/deletion/ of the modules.

3. Please provide details with a process flow diagram how the system can provide scaled down skeleton services in the event of catastrophe.

4. The proposed solution should have provision to co-locate different modules on same system. Please explain how this can be achieved.

5. The proposed solution should have provision to configure different modules across separate systems.

6. The proposed solution should provide Installation scripts/auto installer.

7. The proposed solution should have the provision for upgrading modules/system. Please discuss the upgradability issues of the proposed solution.

8. The proposed solution should have support for load-balancing for entire system. Please elaborate with a clear process flow diagram.


of 166

9. Please provide the reports of testing carried out at any of the production installations of the proposed solution.

10. Please clarify whether the proposed PKI product has any limitations in terms of the level of Sub-CAs or user capacity per CA/Sub-CA. Maximum limits may please quantified.

S. Security

1.

The proposed solution should have support for secure communication among different components. Please describe how the proposed solution provides secure communication between clients, management agents, certificate authorities and other different components of the system with a schematic diagram.

2.

The proposed PKI solution should allow for network isolation of issuing CA, issuing CA keys and data store while still offering an 'online' service. Please clarify how the proposed solution allows for isolation of Raj eSign, its keys and database with a schematic diagram.

3. What solution is proposed for tamper proof protection of Raj eSign root Keys?

4. Briefly describe how the proposed solution guards against eavesdropping or data captures of CA information during sign on process.

5. Please indicate the mechanisms and provisions for securing the internal database against corruption, tampering and eavesdropping in the proposed solution

6.

Please clarify whether well-defined procedure to test and ensure security and reliability of third party devices that may be used in the proposed solution is followed. Describe the mechanism used by Bidder to ensure security and quality of devices from other bidders.

T. Database/ Internal Storage

1. Please furnish the details about the database integrity checking in the proposed solution

2. The proposed solution should have the ability to re-populate the directory from the database in the eventuality of a directory failure.

U. Certificate Transparency


of 166

1.

The proposed solution should support RFC 6960, 6962 i.e. there has to be provision to publish SSL certificates to publicly auditable LOG servers so that any fake / rogue / wrongly issued / unauthorized / unintended / SSL certificates can quickly and easily be detected.

2.

The proposed solution should have the ability to publish pre- certificate on public log server and receive an SCT (Signed Certificate Time Stamp) as proof. It should then be possible to send the resulting SCTs to end-users in any of three different ways: In a certificate extension (embedded when issuing the real certificate) In a stapled OCSP response extension, and / or, In a TLS extension. In either case, CT enabled browser (client) would process SCT data, i.e. legitimate issuance of certificate can be established by the public or by the domain owner.

3.

The proposed solution should support the submission of pre- certificate to CT Log Server, receiving response SCT from CT Log Server and incorporation of SCT inside the certificate on real issuance, stapling SCT tag in OCSP responses and SCT based TLS extension support.

3.3 Technical Specifications for Online Certificate Status (OCS)

The online service status service is to be provided by deploying “Online Certificate Status Protocol-OCSP” responder; the functional requirements are described below:

S. No.

Technical and Functional Requirements of Online Certificate Status (OCS)

Compliant (Yes / No)


Remarks/reference to Data Sheet

1. The OCS solution should be compliant with RFC 2560, RFC 6960 as well as RFC 5019.

2. The OCSP responder should be able to respond to any number of instances of CAs. Please specify the limit, if any.

3. The status information should be stored in a database.

4. The solution should provide a feature of updating status information in real time.

5. The solution should allow additions of custom extensions.


of 166

6. The requestor shall be able to get OCSP response using

All OSCP enabled Browsers OCSP API/SDK Toolkit by way of integrating

the same in e-Gov online applications A GUI Desktop OCSP client, which can be

downloaded from Raj eSign portal and Any other OCSP client/product like Adobe

Acrobat.

7. The GUI Desktop OSCP client shall work in all major platforms like Windows/Linux/Solaris/MAC etc. on 32/64 bits hardware.

8. OCSP API/SDK Toolkit shall be available in .NET, Java, C, C++ etc. frameworks to integrate e-Gov applications.

9. In order to maintain interoperability for applications developed on various platform, frameworks, languages, it shall also have the provision to provide time stamping services as web services standards for easy integration into the applications.

10. OCSP service should also work with available general OCSP clients /products like PDF etc.

11. The solution should have flexible and configurable audit and transaction logging features.

12. The solution should provide definitive response as good, revoked or unknown for any certificate verification request.

13. The solution should allow on-line renewal of OCSP responder keys and certificates.

14. The solution should be able to provide logs and events to the Log Management solution.

15. Solution should be able to integrate with standard LDAP / Active Directory to enforce user based authentication.

16. The solution should be able to retrieve and cache revocation information based on the configuration as per the requirement of Raj eSign.

17. For each successful request, the OCS solution should be able to sign the response with a pre-acquired / configured signing key.


of 166

18. All configuration changes of the OCS solution should be available for audit by RISL.

19. The deployment of proposed solution should be able to provide strong level of protection for the solution signing key

20. The OCSP responder services should be fully compliant to the requirements given in:

“X.509 Certificate Policy for India PKI”, latest version (presently version 1.2) of which is available at CCA website (cca.gov.in)

Interoperability Guidelines (http://cca.gov.in/cca/index.php?q=dsc_interoperability.html) and,

Online Certificate Status Protocol (OCSP) Service Guidelines for Certifying Authorities (CA) Version 1.4 dated June 2014 issued by CCA.

21. The OCSP should support the GET or the POST method for DSC issued under PKI India Hierarchy.

22. OCSP responses should conform to IETF RFC2560 standard. OCSP responses should either be signed by the CA that issued the Certificates whose revocation status is being checked, or be signed by an OCSP responder who’s Certificate is signed by the CA or its Sub-CA that issued the Certificate whose revocation status is being checked.

23. The OCSP responder should ascertain that certificate whose status being checked, has been issued actually by CSP after processing request through prescribed process/channel. In case, the OCSP responder receives a request for status of a certificate that has not been issued by prescribed process of CSP, the OCSP responder should NOT respond with a "good" status. The OCSP responder should monitor such OCSP requests and generate alarm/record of the requestor information as part of its security response procedures.

24. The OSCP should support Certificate Transparency RFC 6962, i.e. stapling of SCT extension in OCSP responses so that CT enabled browser can check the existence of the certificates in CT Logs to establish the legitimacy of SSL certificates.

25. The OCSP Server should also comply with the CEN Workshop Agreement CWA 14167-1 security requirements. It should also be capable of providing OCSP certificate validation services for multiple Certificate Authorities (CAs) concurrently.

http://cca.gov.in/cca/index.php?q=dsc_interoperability.html)

http://cca.gov.in/cca/index.php?q=dsc_interoperability.html)


of 166

26. The OCSP shall provide a response in ten seconds (maximum) under normal operating conditions. High performance >300 request per second on regular basis.

27. The end to end process should be automated for providing OCSP response to a Relying Party. There should not be any manual intervention unless an error condition arises.

28. The OCSP should accept both signed and unsigned OCSP requests.

29. The OCSP should not use pre-computed or Cached responses for certificate Status.

30. The OCSP Responder should be able to support nonce extension in request and responses.

31. The OSCP Server should include high-performance CRL Monitor and processing services that import and quickly process large CRLs ensuring that the latest revocation information is always available. It should be able to access multiple HTTP/S and LDAP/S CRL locations to maintain high reliability and availability.

32. The OCSP Server should have an option to allow CSP systems to use a Real-Time Publisher Utility to update certificate status information immediately, even if CSP is not due to create CRL for several hours.

33. The OCSP Servers should support high scalability and availability. Multiple servers should work concurrently using standard load- balancing techniques and provisioning to establish a resilient secondary site by way of replicating whole system including database. In case PR is not working OSCP requests should be served from DR and vice versa.

34. The OCSP Server should be deployable in sophisticated ways to maximize performance. Logging level should be controlled and CRLs used in memory to boost performance. Its components like OCSP service, CRL Monitor service and database should be deployable on separate servers.

35. The OCSP Server should provide a detailed historical record of all transactions. It should also have viewing facility for OCSP request & response required for billing and/or troubleshooting and management.

36. The OCSP Server should generate detailed event and transaction logs that can be used to create usage and advanced management reports for identifying high demand users, certificates or IP addresses. These


of 166

reports should be available for a specific date range also.

37. The solution should provide above mentioned reports exportable to PDF and CSV formats so that they can be imported into Adobe® Reader and Microsoft Excel for example. It should also produce graphical service usage reports on a per CA basis for easy presentation in an easily understandable manner such as pie-charts and tables?

38. The OCSP server should have in-built mechanism or separate tool for administrators/testers to test load with a selectable large number of OCSP requests, enabling operations managers to prove how their systems respond to varying load conditions. This tool should also collect OCSP responses, analyze them for time taken to respond, and generate a report of the total time taken and the average time per OCSP request. It should be capable of performing comprehensive checks on OCSP responses as per CSP policy like signature, certId, nonce, thisUpdate, nextUpdate, responder certificate chain validity, extended key usage, responder certificate trust building etc.

39. An OCSP Client tool should be available to test and ensure that OCSP systems are operating effectively as per CSP specifications and validation policies applicable. This tool should facilitate the checking of OSCP request using defined URL or use of AIA extension contained within the certificate(s), sending signed and unsigned OSCP requests, receive and validate OCSP responses from OSCP responder, time out setting, and comprehensive facility to manage OCSP services during installation, operation & maintenance.

40. The OCSP responder certificate and subscriber certificates shall comply with latest version of interoperability Guidelines for Digital Signature Certificates issued under Information Technology Act and any subsequent amendments.

41. The OCSP Responder should have a simple secure web interface and policy-based engine that would enable configurations to be made quickly and easily. The OCSP Responder should provide transaction logging and management reporting that can be reviewed on a per CA basis.


of 166

42. The OCSP Responder should provide secure and detailed OCSP transaction logging in viewable, human readable format, exportable (individual or set) and searchable format to drill down to the details of OCSP requests and responses. E.g. all fields be shown within each and every OCSP request and response.

43. The OCSP responder should provide real-time system alerts via SNMP, email and SMS. These alerts should be configurable for various events that could potentially affect the normal operation of the OCSP Responder such as CRL retrieval problems (e.g. due to network issues or otherwise), CRLs not being issued when scheduled Keys and certificates approaching their expiry date, Database communication problems.

44. The OCSP responder should have the provision to enable logs, secure archival, the archiving of the database records be performed both manually and automatically, signing the archive logs using a separate log signing key, archived logs be re-importable, verifiable and viewable later.

45. The OCSP responder should provide management reporting information such as: How many OCSP service transactions were received within a particular date range, Which relying party OCSP client was making the most OCSP requests within a particular date range, Which target certificate was checked the most by all OCSP clients within a specific data range?, Which of the registered CA certificates were checked the most?, How many “unknown/Bad” or “revoked” responses were returned within a date range?

3.4 Technical Specifications for Time Stamping Authority (TSA)

S.No. Technical and Functional Requirements of Time Stamping Authority (TSA)



Remarks/ reference to Data Sheet

1. The solution should implement time stamping as specified by IETF PKIX Time-Stamp Protocol RFC 3161.

2. The solution should provide a secure, verifiable audit trail of time synchronizations by logging all clock adjustments and signing them inside the HSM.

3. The proposed solution should support tool based and browser based administration console having secure authentication mechanisms for its management.


of 166

4. The solution should support multiple operating system platforms such as Linux, Windows, Solaris etc. and virtual/non virtual environment, no vendor lock-in.

5. The solution should perform highly accurate time stamping for PKI- enabled applications, electronic records etc. Please mention accuracy level.

6. The solution should provide auditable functionalities with time stamps auditable to UTC.

7. The solution should provide protection mechanism in order to safeguard the electronic time stamping process and keys through independently certified, tamper-resistant hardware.

8. The proposed solution should have the ability to operate and administer the solution remotely.

9. The solution should provide a tamper-proof network-attached hardware device which isolates and protects critical time stamping keys from manipulation, providing trusted time stamps for a broad range of security and business applications.

10. All configuration changes to the time stamping authority solution should be able to be audited by RISL.

11. The solution should support scalability and high availability deployment options.

12. The proposed timestamp authority solution deployments shall be able to provide strong level of protection for the solution signing key.

13. Time stamping services shall be deployed strictly in accordance with CCA issued Guidelines “Time Stamping Services Guidelines for Certifying Authorities (CA) Version 1.0 dated October 2012” available on CCA website (http://cca.gov.in).

14. Time stamp token shall include representation (hash) of the datum being time stamped.

15. The proposed solution should provide a time stamp that is bound to the input data by a digital signature as per standards (X.509 V3).

16. The specification of the output of the time stamping solution should be available in documentation form and conform to published standards such that it can be verified by an independent time stamp validation service.


of 166

17. Time stamping solution should also generate a paper certificate in printable format stating fingerprint received, date, time of time stamp and fingerprint of time stamp response.

18. The proposed solution should be configurable to an external source (National Physical laboratory of India) of trusted time. Time included in the time stamp token should be synchronized with standard time source within the accuracy of +/- 1 second. Monitoring of NTP time source to check TSA server time drift and alert the management about the same and if necessary stop time stamping services.

19. Solution should integrate FIPS 140-2 level 3 or higher, CC EAL4+ temper-detecting hardware security module (HSM) for performing - Secure time stamp functions, Clock and audit trails along with LOG Enablement for HSM

20. Each component of the solution should create secure error/success logs with configurable log period/level and in a well-defined syntax.

21. Securely logs all time stamping requests submitted to the system (including error in processing) and the outcome of these requests in secure manner (temper-resistant/proof-digital signing, encryption) with timestamp, auditable required for legislative or regulatory purposes, dispute resolution processes or as an evidences for analyzing security incidence.

22. Solution should provide secure, verifiable audit trails of time synchronization at regular time calibration periods and HSM signed audit trails.

23. All logs shall be exportable to any 3rd party audit log management System in general for review. Secure archival of logs to some external storage/system.

24. Alert messages to the management for any issues relating to the malfunctioning of TSA components including unplugging network etc.

25. Solution should be configurable create time-stamp with RSA 2048- 8192 bits, ECC curve NIST P‐256, P‐384, or P‐521 signature algorithms.

26. Solution should support time-stamp requests containing message imprints of hash algorithms SHA256, SHA 384 and SHA512 etc.

27. The solution should provide and prove minimum RSA 2048 bit 150 Time Stamps Per Second, RSA 4096 bit -100 Time Stamps Per Second. Solution should be


of 166

properly scalable up to millions of timestamps per day.

28. The solution should have the provision to generate account statement of fee charged per token and to control (limit) and evaluate the consumption of time stamping service for each user. Fee per token should be configurable.

29. Time stamping server should be highly effective, scalable, high availability. It should have provision to deploy multiple virtualized/logical TSAs servers with load balancers, clustering modes using multi core CPUs and physical CPUs, different nonce requirements, time accuracies and TSA signing key/Certificate, TSA policies. Two or more servers (cluster modes) with load balancer should work as a single managed system so that if one server fails TSA service is not hampered. Also in case PR is down, Time stamping Service should run from DR and vice versa.

30. Multiple instances at different sites (DR), i.e. the solution should support replica of all the TSA components to DR site using virtualization/SAN Data replication or otherwise.

31. The solution should be easy to integrate with business applications to time stamp digitally signed documents (e.g. PDFs), application code, or other electronic records. The requestor should be able to get its document/request time stamped and validate using:

TSA portal (web based) TSA API/SDK Toolkit by way of integrating

the same in e-Gov online applications A GUI Desktop time stamp client, which can be

downloaded from TSA portal and Any other time stamping client/product

including Adobe Acrobat.

32. The GUI Desktop time stamp client shall work in all major platforms like Windows/Linux/Solaris/MAC etc. on 32/64 bits hardware. It shall also have the provision to sign the document using crypto token/smart cards.

33. TSA API/SDK Toolkit shall be available in .NET, Java, C, C++ etc. frameworks to integrate e-Gov applications.

34. In order to maintain interoperability for applications developed on various platform, frameworks, languages, it shall also have the provision to provide


of 166

time stamping services as web services standards (SOAP, WSDL) for easy integration into the applications.

35. Service shall also work with available general time stamping clients/products like PDF etc.

36. Security operators shall be authenticated using Client SSL Certificates in a client/server mutually authenticated TLS/SSL session using strong algorithms. The clients certificates keys should be maintainable inside the HSM which maintains the temper-evident LOGS and controllable in dual mode.

37. The users are required to enroll to the system with their credentials (Name, email, Mobile No, organization, project details, a user id and password (should be stored in HMAC form) using Raj eSign Time Stamping Request Form.

38. The service shall run over (https) SSL/TLS with proper user authentication and password (HMAC based) without user/Administrator intervention.

39. Provision to restrict the services based on white list of IPs, MACs etc.

40. The retrieval/search /report based on criteria like Nonce (the unique number generated for each time stamp request), user details, date of time stamp request, document hash. Different MIS reports, Analytical Reports, consumption Reports etc.

Notes: * “Proof acceptable to RISL” as mentioned above means bidder shall provide copy of PO / SLA / Signoff by client / Invoice duly accepted or approved by client / copy of invoice from OEM along with other supplementary documents justifying claim of having supplied the services to bidder / email from client “Reasonably Comparable to RISL” and shall subject to verification by RISL. Lack of verification may lead to disqualification of Bidder. Generic proofs like PO for firewalls, IDS etc. which are not relevant to the project shall neither be attached by Bidder nor be accepted by RIS


of 166

ANNEXURE-4: ESIGN TECHNICAL & FUNCTIONAL SPECS The Government has introduced Electronic Signature or Electronic Authentication Technique and Procedure Rules, 2015 in which the technique known as “e-authentication technique using Aadhaar e-KYC services” has been introduced to eliminate stumbling block in the widespread usage of Digital Signature. This service is termed as “eSign Service”. The certificate issued through eSign service will have a limited validity period and is only for one-time signing of requested data, in a single session. eSign service shall be provided strictly in accordance with “eSign API Specifications” and “e-Authentication Guidelines” issued by Controller of Certifying Authorities (CCA) office. These specifications may change from time to time; same can be accessed from http://www.cca.gov.in. The Bidder is required to tune eSign Services accordingly. S. No

RISL’s Requirements Compliant (Yes / No)

Mandatory / Optional

Readily available, Customizable Not available reference to Data Sheet (R/C/N)

Remarks /reference to Data Sheet

A. AUTHENTICATION AND DSC APPLICATION FORM

1. The mode of e-authentication should be biometric in accordance with UIDAI framework/OTP based.

2. AADHAAR e-KYC service should provide digitally signed information that contains name, address, email id, mobile phone number, and photo and response code to applicant.

3. The response code, which is preserved online for six months from the date of its generation and further two years offline by UIDAI, should be recorded on the application form (Form C of Schedule IV) & included in the DSC as well.

4. DSC application form is to be electronically generated after successful authentication of DSC applicant by Aadhaar e-KYC services and same will be archived as per CCA guidelines.

5. The application form should programmatically be filled with the digitally signed information received from by Aadhaar e-KYC services.

http://www.cca.gov.in/


of 166

6. The filled-in application form should be preserved. The following events should be recorded:- Response code (e-KYC) Authentication logs Communication with CAs for

Certificate issuance Activation mechanism for Digital

Signature.

7. The consent of the subscriber for use of Aadhaar information for availing eSign services should be obtained electronically.

8. Subscriber should be given an option to reject the Digital Signature Certificate.

B. SECURITY PROCEDURE FOR KEY-PAIR GENERATION

1. TTP service should facilitate generation of key pairs on their Hardware Security Module. The key pair passes through associated activation mechanism unique to the subscriber.

2. The private key of the subscriber shall be secured by Hardware security module (HSM) in accordance with FIPS 140-2 level 3 recommendations for Cryptographic Modules Validation List.

C. CERTIFICATE ISSUANCE

1. The validity of the certificate shall not be more than 30 minutes for one time use only.

2. On successful key generation, the Certificate Signing Request is sent to CA by the TTP service for issuing the DSC.

3. The DSC is published in the Repository maintained by CA.

4. eSign Solution shall have performance >200 requests per second.

D. EVIDENCE REQUIREMENTS


of 166

1. Record all relevant information concerning the e- authentication of DSC applicant for generation of key pair and subsequent certification functions for a minimum period of 7 years (ref The Information Technology (Certifying Authorities) Rules, 2000, Rule 27), in particular for the purpose of providing evidence for certification purposes. Such electronic record should be preserved accordingly in secure environment.

2. Record all relevant information concerning the e- authentication of subscriber for accessing the key pair for a minimum period of 2 years, in particular for the purpose of providing evidence of Digital signature creation. Such electronic record should be preserved accordingly in secure environment.

E. OTHERS

1. Dashboard with provision for setting the number of eSign to be issued per ASP should be provided.

2. Counter / alert system with configurable levels per ASP for both the ASP and Raj eSign, should be provided for keeping track of eSign.


of 166

ANNEXURE-5: TECHNICAL SPECIFICATIONS FOR HARDWARE SECURITY MODULE (HSM)

S.No. RISL’s Requirements Compliant? (Yes / No)

Remarks /

reference to Data Sheet

1 Should support Windows 2008 or higher, Linux, Solaris, HP UX 11i, VMWARE, AIX 5.3 and the platform quoted by Bidder.

2 Should comply to standards FIPS 140-2 Level 3, CC EAL4+,ROHS, FCC part 15 Class B.

3 Key Exchange Symmetric Algorithm: AES, DES, Triple DES, RC2, RC4, RC5, SEED.

4 Support for Hash Message Digest HMAC, SHA2 (224-512).

5 Support for various cryptographic algorithms: Asymmetric Key RSA (1024-8192 bits), Diffie-Hellman (1024 4096 bits), Elliptic Curve Cryptography – ECC curve NIST P‐256, P‐384, or P‐521, DSA (1024-3072).

6 Random Number Generation –FIPS 140-2 approved DRBG (SP 800-90 CTR mode).

7 Support for PKCS#11, CAPI, OpenSSL, JCE/JCA.

8 Keys are always stored securely in Hardware and never stored in software in any form. Complete hardware based storage of key material for entire Life cycle.

9 If solution cannot backup CA keys using Smart Card/Crypto Token, bidder should provide appropriate mechanism to prepare backup device at PR/DR.

10 Onboard key generation, signing inside the HSM.

11 Provision of delivery of new device on its failure without returning the failed one.

12 Support for multi factor authentication (Remote and Local) with PED support

13

HSM should provide the configurability such that HSM operations can be configured for mandatory manual interventions for all kind of operations & access to HSM. The following functionalities should be provided in HSM operations:

Multiple Operators should be required to perform tasks / operations with traceability for each of the role.

One operator should be able to perform multiple roles and each operation should be traced to operator’s role.

HSM should require manual intervention for performing tasks / operations by inserting CARD / Token / Biometrics

Logs generated by HSM should provide the operators signatures / traces.

14 Support for interface with the CA Applications with log generating feature, Published API for various functionality and integration with applications.

15 Support for minimum 1000 signatures per second for both RSA 2048 bit keys and ECC 256/384/512 bit keys

16 HSM should be scalable to support more signatures per second i.e. usable in cluster mode.


of 166

17

Enhanced Audit Log Facility & Error logs managed by separate audit role. Log entries should originate from HSM, which should include, when, who, what and result of logging. Audit log entries are ensured against any truncation, modification, deletion, addition. Critical events like tamper, decommissioning, zeroization, SO creation audit role creation should be logged automatically and unconditionally. Logs should be sent to the server before rewriting them.

18 Support for Health checkup, Diagnostic commands such as PING, TRACERT & NETSTAT for monitoring Ethernet connections and utilization statistics.

19 HSM should support integrations with interfaces and providers like IAIK , OpenPGP, Openssl, CryptoMathic and with applications like Ascertia ADSS , Nuance ( voice Biometrics ), Totemo Email Gateway

20 HSM should support SIEM integration with applications like Splunk , CyberARK.

21 Device 'hardening' ability to disable functions not required for CA operations.

22

Support for secure transit from one place to another place. Key material should be storable in encrypted files with key split/split forms for backup, cloning and easy transportation to disaster recovery site. Key transportation from one HSM to another HSM (same and different make).

23 24/7/Telephonic/email/onsite support from OEM in India.

24 HSM Appliance shall be network (TCP / IP) based appliance and must work as cluster. The key generation speed of HSM’s should be minimum two (02) key pair per second (RSA 2048 bits).

26 HSM OEM should have 24 x 7 support available directly from personnel from OEM in India (support employees should directly on the Payroll of OEM in India

27 HSM OEM should have Engineering, R&D and Support in INDIA only , HSM OEM should be employing at-least 300 Engineers for R&D and Engineering in India (should have employees on OEM Payroll only)

28 Should have sold 100+ PKI (General Purpose) HSM in Year 2016 and used in major project like Adhaar, UPI etc.

29 Should support complete use of ECC curves for commercial activities like issuance of Digital certificates generated using the same curves to external parties without need of any additional licenses


of 166

ANNEXURE-6: TECHNICAL SPECIFICATIONS FOR CRYPTO USB TOKEN

S. No

RISL’s Requirements



1. Support for 32 and 64 bits machines.

2. Minimum 64Kb secure memory for storing multiple digital signature Certificates.

3. On board Crypto Algorithm for support of RSA up to 2048 bit keys, DES, 3DES and ECC 256, 384, 512 bit keys.

4. Hash Algorithm support for minimum SHA-256

5. Middleware Support for PKCS#11 v2.01, v2.11, X.509 v3 certificate storage.

6. FIPS 140-2 Level 2/3 Security Certification.

7. Common Criteria CC 4/4+ or above for chip.

8. True Random Number Generator (TRNG) as per NIST SP 800 or ANSI X9.31 PRNG.

9. OS should support standard platforms like Java 3.0/Higher or .NET or Sun Solaris.

10. Compliance to PC/SC and USB 2.0 (CCID 1.0 compatible).

11. No method to extract, view and access the private key.

12. Hard tamper-proof body as one unit.

13. USB token attached with a key ring based plastic dog-tag.

14. A unique Serial Number should be pre-printed/engraved on it.

15. Memory data retention should be at least 05 years.

16. All executables related to crypto operation should be on ROM only.

17. Single unit Packaging containing Crypto USB Token, middleware/driver CD and dog-tag should be provided.

18. SDK and API should be made available with User Guide.


of 166

ANNEXURE-7: TECHNICAL SPECIFICATIONS FOR GATEWAY ROUTER Make: ___________________________ Model: __________________________

S. No

RISL’s Requirements

Compliant (Yes/No)


1. Router should be multi core processor, modular architecture and support min performance 1 Gbps and fabric based architecture which will allow high bandwidth modules to module communication without compromising routing performance.

2. Out of band management access via USB /console/Aux port.

3. The Router should have 4 WAN or LAN 10/100/1000 ports. Support 4 SFP-based/ 4 RJ-45-based ports.

4. Router should support Online insertion and removal of modules,

5. Support for External RADIUS/TACACS for console restriction and authentication.

6. IPV4: IP routing Protocols like static, RIP v1 and OSPF, BGP v4, equal cost routing, VRF, MPLS, Layer 2 VPN, Layer 3 VPN, BFD, MPLS, NSF awareness, HSRP/VRRP.

7. IPv6: OSPF v3, and static routes, ipv6 Routing , t IPv6 Multicast, IPv6 QoS, IPv6 VPN over MPLS (6VPE) for IPv6,IPv6 Ready Logo as certified by the IPv6 Forum.

8. Collection of IP traffic information, mechanism for application performance & usage pattern, as well as security. MPLS-Aware NetFlow / jflow / sflow.

9. Support Class-Based Weighted Fair Queuing (CBWFQ) / CBQ, WRED, QoS for Traffic Management inspections, QoS classification with TCP Application traffic.

10. SNMPV1, SNMPv2, and SNMPv3, Layer 2 / Layer 3 traceroute, TFTP, NTP, RMON I and II, CLI Support, Telnet, SSH version 1 & 2, SNMP over IPv6.

11. Should support IPSEC, Network performance monitoring and network performance visibility.

12. Support mechanisms for measuring service-level indicators, including delay, jitter, and availability, mechanism to monitor network performance.

13. Support identification of flows by looking at the Source IP address, Destination IP address, Source port number, Destination port number & support on-board automation for fault detection, troubleshooting, and recovering.


of 166

14. Power requirement 240 VAC, 50 Hz, Operating temperature 0 to 45 degree centigrade, Operating humidity 10% to 85 % (non-condensing).

15. IPv6 ready logo with day one & EAL/NDPP certification.


Page 123 of 166

ANNEXURE-8: TECHNICAL SPECIFICATIONS FOR TOP OF THE RACK (TOR) SWITCH

S.No. RISL’s Requirements Compliant (Yes/No)


1 19" Rack mountable switch with minimum of 48 x10G BaseX ports which 10G LR/SR and 1G BaseT RJ45 , SX/LX from day one . Switch & transceiver should be from same OEM

2 Should have redundant internal power supplies redundant fans.

3 switch should have for minimum 960 GBPS of switching throughput & minimum 650MPPS of forwarding rate.

4 Switch should support of 320gbps of bandwidth (in addition to above asked ports and bandwidth) as and when required for future requirement to provide vPC /Virtual Fabric /Virtual Chassis interconnectivity.

5 Should have IPv4 Static Routes, OSPFv2, BGP and /Sflow/ from day one

6 Should support 802.1d, 802.1s, 802.1w and 802.1ad layer 2 protocol.

7 Switch should have minimum of 2GB of internal DRAM and 2G B flash memory.

8 Switch should have 16MB of packet buffer size for traffic to support huge file transfers.

9 Should have 12000 IPv4 Routes, 148K MAC Address , 4K active VLAN's and 8 hardware queues per port.

10 Should support minimum of 32 no of ports per LAG/etherchannel.

11 Should support switching latency of not more than to 0.5 micro second

12 Should support IEEE 802.1Qaz , IEEE 802.1Qbb, DCB, multi-hop FCOE, pause frames IEEE 802.3x and layer 2 extensions over VXLAN or equivalent protocol.

13 Should support port security, Dynamic ARP Inspection, BPDU and root Guard security features.

14 Should support enterprise class CLI console, telnet, SSH and web management.

15 Should support RADIUS/TACACS, 802.1x SNMP versions 1, 2 and 3 RMON and NTP.

17 Warranty - must be quoted with the three years comprehensive direct from OEM support.


Page 124 of 166

ANNEXURE-9: TECHNICAL SPECIFICATIONS FOR GATEWAY ENTERPRISE UNIFIED THREAT MANAGEMENT (UTM)/NGFW

S.No RISL’s Requirements Compliant (Yes / No)


1. Appliance should be Hardware based, Reliable, purpose-built security appliance with hardened operating system that eliminates the security risks associated with general purpose operating systems.

2. Appliance should be rack mountable. Appliance with Unrestricted users.

3. Should support stateful inspection.

4. Firewall throughput shall be at least 15 Gbps.

5. VPN throughput shall be at least 5 Gbps.

6. IPS throughput should be more than 5 Gbps.

7. Firewall connections supported shall be at least 6 million

8. Connections/sec supported shall be more than 1 lakh.

9. Minimum Anti-malware throughput shall be 3.5 Gbps.

10. Unit should have minimum 8 GB or Higher memory.

11. Unit should have option of at least 6 Core with specialized security processing.

12. Should have upgradeable Firmware.

13. Gateway Antivirus should be able to scan the 50+ Protocols including HTTP, FTP, SMTP, POP3 and IMAP.

14.

Restricts or prioritizes applications or application categories in order to maximize available bandwidth for critical applications while eliminating or reducing undesired application traffic.

15. The appliance should support 802.IQ Trunking and minimum 500 Vlans.

16.

Support for deployment of the appliance in a secure Layer 2 bridging mode, providing rich Layer 2-7 appliance security services for the protected network while remaining "invisible" to devices on each side of it.

17.

Controls applications, or individual application features, which are identified by the DPI engine against a continuously expanding database of over 4,000 application signatures, to increase network security and enhance network productivity.

18. The appliance should support standard routing protocols like RIP, OSPF in addition to static and policy based routing.

19. Appliance should have Out-of-band management port


Page 125 of 166

20. Appliance should Support for RADIUS/TACACS, Active Directory & LDAP for the user authentication protocols in addition to local authentication.

21. Appliance should support Active-Active as well as Active-Passive cluster High Availability deployment.

22.

Identifies common protocols such as HTTP/S, FTP, SMTP, SMBv1/v2 and others, which do not send data in raw TCP, and decodes payloads for malware inspection, even if they do not run on standard well known ports.

23.

Bi-directional raw TCP inspection - scanning raw TCP streams on any port bi- directionally, preventing attacks that try to sneak by outdated security systems that focus on securing a few well-known ports.

24. Scans all inbound, outbound and intra-zone traffic for viruses, Trojans, key loggers & other malware in files of unlimited length and size across all ports and TCP streams.

25. Appliance should support Multiple WAN Link load balancing across multiple WAN interfaces using Round Robin, Spillover or Percentage based methods.

26. Appliance should identify and control applications regardless of port and protocol for at least 500 applications.

27. The system shall support Multiple forms of site-to-site VPN configurations for Route, Policy, Domain etc

28. Appliance should have Integrated IPS Solution

29. Support Behaviour analysis and signature based analysis with online download support of newer signatures for at least 1500

30.

IPS solution should be flexible enough to configure, enable/disable signatures and have different actions for the IPS signature at the appliance policy level and not configured at GLOBAL or interface level

31.

IPS signatures should have configurable actions like terminate a TCP session by issuing TCP Reset packets to each end of the connection, or silently drop traffic in addition to sending an alert and logging the incident

32.

Appliance should have integrated gateway level Anti-Virus Solution. Anti-virus gateway should provide real-time detection of viruses and malicious code at the gateway for SMTP, IMAP/ POP3, HTTP, HTTPS and FTP Internet traffic.

33. Appliance should support flow based AV scanning Technology.


Page 126 of 166

34.

Frequent updates of virus pattern files should be available from the Web and option for scheduling for automatic update thru a secure communication as well as for manual update should be available.

35. Should have facility to block files based on file extensions over HTTP, FTP, SMTP, POP3.

36. Should have reporting facility to generate reports on virus detected over different protocols, top sources for viruses, destination for viruses, top viruses etc.

37. Appliance should have integrated category based URL filtering solution which should be capable of filtering HTTP and HTTPS based URLS

38. Should have configurable parameters to block/allow unrated sites Should have configurable options to allow/deny access to web sites in case if the URL rating service is unavailable

39. Should have options to customize the block message information send to end users Should have facility to configurable policy options to block web sites based on banned words.

40. Should have configurable policy options to block URLs based on web patterns (e.g. Mail.* to block web mail related sites)

41. Should have configurable policy options to define the URLs what needs to be blocked as well as the exempt list

42. Proposed system shall have the ability to detect, log and take action against network traffic based on over 3,000 application signatures

43. The administrator shall be able to define application control list based on selectable application group and/or list and its corresponding actions.

44. The proposed system shall be able to operate on either Transparent (bridge) mode to minimize interruption to existing network infrastructure or NAT/Route mode.

45. The system must be able to support routing protocols including, RIPv1 & v2, OSPF

46. The system shall be able to provide Wan link redundancy

47. Appliance should support Multiple links( more than 2) load sharing / balancing with failover cum redundancy.

48.

Appliance should at least be comprised of following 7 security functionalities 1)Firewall 2)Intrusion Prevention system 3)Antivirus 4) Web Content Filtering 5) Application Control 6) Link Load balancing & Routing


Page 127 of 166

49.

Reporting module should provide web-based traffic analytics and reporting tool that provides real-time and historical insight into the health, performance and security of the network

50.

Should provide visibility into suspicious network activity and employee productivity with comprehensive graphical reports on firewall bandwidth usage statistics, threats, and per user application traffic analysis

51. Should offer customisable reporting.

52. Reports should be scheduled and sent out in various formats to one or more email addresses

53. Administrators should be able to generate reports that fulfill compliance requirements on an ad-hoc and scheduled basis to meet specific regulatory mandates

54. Granular reporting should help administrators to quickly react to incoming threats with new attack intelligence including types of attacks or intrusion attempts and the source address of the attacker

55. Should support IPv4 and IPv6 from day one.


Page 128 of 166

ANNEXURE-10: TECHNICAL SPECIFICATIONS FOR INTERZONE UNIFIED THREAT MANAGEMENT (UTM)/NGFW

S.No. RISL's Requirements Compliance Yes/No


1. The appliance should be Hardware based, Reliable, purpose-built security appliance with hardened operating system that eliminates the security risks associated with general purpose operating systems.

2. Appliance should be rack mountable. UTM Appliance with Unrestricted users.

3. Firewall throughput shall be at least 6 Gbps

4. VPN throughput shall be at least 3 Gbps.

5. IPS throughput should be more than 2 Gbps.

6. Firewall connections supported shall be at least 4 million

7. New connections/sec supported shall be more than 80,000

8. Minimum Anti-malware throughput shall be 1.1 Gbps.

9. The Unit should have minimum 2 GB or Higher memory.

10. Appliance should have 8x 10/100/1000 copper gigabit ports and option of 8 x 1- GbE SFP and 4 x 10-GbE SFP+.

11. Should have upgradeable Firmware.

12. Gateway Antivirus should be able to scan the 50+ Protocols including HTTP, FTP, SMTP, POP3 and IMAP.

13. Restricts or prioritizes applications or application categories in order to maximize available bandwidth for critical applications while eliminating or reducing undesired application traffic.

14. Controls custom applications by creating signatures based on specific parameters or patterns unique to an application in its network communications, in order to gain further control over the network.

15. Appliance should support 802.IQ Trunking and should support minimum 500 Vlans.

16. Support for deployment of the appliance in a secure Layer 2 bridging mode, providing rich Layer 2-7 appliance security services for the protected network while remaining "invisible" to devices on each side of it.

17. Controls applications, or individual application features, which are identified by the DPI engine against a continuously expanding database of over 4,000 application signatures, to increase network security and enhance network productivity.


Page 129 of 166

18. Appliance should at least be comprised of following 7 security functionalities 1)Firewall 2)Intrusion Prevention system 3)Antivirus 4) Web Content Filtering 5) Application Control 6) Link Load balancing & Routing

19. Appliance should support standard routing protocols like RIP, OSPF in addition to static and policy based routing.

20. Appliance should have Out-of-band management port

21. Appliance should Support for RADIUS/TACACS, Active Directory & LDAP for the user authentication protocols in addition to local authentication.

22. Appliance should support Active-Active as well as Active-Passive cluster High Availability deployment.

23. Identifies common protocols such as HTTP/S, FTP, SMTP, SMBv1/v2 and others, which do not send data in raw TCP, and decodes payloads for malware inspection, even if they do not run on standard well known ports.

24. Scans all inbound, outbound and intra-zone traffic for viruses, Trojans, key loggers and other malware in files of unlimited length and size across all ports and TCP streams.

25. Appliance should support Multiple WAN Link load balancing across multiple WAN interfaces using Round Robin, Spillover or Percentage based methods.

26. Appliance should identify and control applications regardless of port and protocol for at least 500 applications.

27. Appliance should support Traffic shaping and prioritization based on applications.

28. The system shall support Multiple forms of site-to-site VPN configurations for Route, Policy, Domain etc

29. Support Behaviors analysis and signature based analysis with online download support of newer signatures for at least 1500

30. The software on the IPS should support online software reconfiguration to ensure that changes made to a IPS configuration take place with immediate effect.

31. IPS solution should be flexible enough to configure, enable/disable signatures and have different actions for the IPS signature at the appliance policy level and not configured at GLOBAL or interface level


Page 130 of 166

32. IPS signatures should have configurable actions like terminate a TCP session by issuing TCP Reset packets to each end of the connection, or silently drop traffic in addition to sending an alert and logging the incident

33. Appliance should have integrated gateway level Anti-Virus Solution. Anti-virus gateway should provide real-time detection of viruses and malicious code at the gateway for SMTP, IMAP/ POP3, HTTP and FTP Internet traffic.

34. Appliance Should support flow based AV scanning Technology.

35. Frequent updates of virus pattern files should be available from the Web and option for scheduling for automatic update thru a secure communication as well as for manual update should be available.

36. Should have facility to block files based on file extensions over HTTP, HTTPS, FTP, SMTP, POP3.

37. Should have reporting facility to generate reports on virus detected over different protocols, top sources for viruses, destination for viruses, top viruses etc.

38. Appliance should have integrated category based URL filtering solution which should be capable of filtering HTTP and HTTPS based URLS.

39. Should have configurable parameters to block/allow unrated sites Should have configurable options to allow/deny access to web sites in case if the URL rating service is unavailable

40. Should have options to customize block message information send to end users Should have facility to configurable policy options to block web sites based on banned words.

41. Should have configurable policy options to block URLs based on web patterns (e.g. Mail.* to block web mail related sites)

42. Should have configurable policy options to define the URLs what needs to be blocked as well as the exempt list

43. The proposed system shall have the ability to detect, log and take action against network traffic based on over 3,000 application signatures

44. The administrator shall be able to define application control list based on selectable application group and/or list and its corresponding actions.

45. The proposed system shall be able to operate on either Transparent (bridge) mode to minimize interruption to existing network infrastructure or NAT/Route mode.


Page 131 of 166

46. The system must be able to support routing protocols including, RIPv1 & v2, OSPF

47. The system shall be able to provide Wan link redundancy

48. Appliance should support Multiple links (more than 2) load sharing / balancing with failover cum redundancy.

49. Reporting module should provide web-based traffic analytics and reporting tool that provides real-time and historical insight into the health, performance and security of the network

50. Should provide visibility into suspicious network activity and employee productivity with comprehensive graphical reports on firewall bandwidth usage statistics, threats, and per user application traffic analysis

51. Should offer customisable reporting

52. Reports should be scheduled and sent out in various formats to one or more email addresses

53. Administrators should be able to generate reports that fulfill compliance requirements on an ad-hoc and scheduled basis to meet specific regulatory mandates

54. Individual user activities should be tracked locally or on remote network sites to provide even greater insight into traffic usage across the entire network and get a closer look at application usage, web sites visited, backup activity, and VPN connections per user

55. Granular reporting should help administrators to quickly react to incoming threats with new attack intelligence including types of attacks or intrusion attempts and the source address of the attacker

56. Should support IPv4 and IPv6 from day one.


of 166

ANNEXURE-11: TECHNICAL SPECIFICATIONS FOR ANTI-VIRUS S.No. RISL’s Requirements Compliant

(Yes / No) Remarks / reference to Data Sheet

1. Single Agent: Should be only single agent that combines all the critical components for total security on the endpoint. (Antivirus, Antimalware, Firewall, etc.)

2. Personal Firewall: Firewall should block unwanted traffic, prevents malware from infecting endpoint systems, and makes them invisible to hackers.

3. Program Control with Program Advisor: Program Control ensures that only legitimate and approved programs are allowed to run on the endpoint. Program Advisor is a real-time Vendor knowledge base of over a million trustworthy applications and suspected malware used to automatically set the Program Control configuration.

4. Heuristic virus scan: Should Scan files and identifies infections based on behavioral characteristic of viruses

5. On-access virus scan: Should Scan files as they are opened, executed, or closed, allowing immediate detection and treatment of viruses

6. Deep scan: Should Scan Runs a detailed scan of every file on selected scan targets

7. Scan target drives: Should specify directories & file types to scan 8. Scan exclusions: Should specify directories and file extensions not to be

scanned

9. Treatment options: Should Enables choice of action agent should take upon detection of virus: Repair, rename, quarantine, delete

10. Intelligent quick scan: Should Check the most common areas of the file system and registry for traces of spyware

11. Full-system scan: Should Scan local file folders & specific file types 12. Deep-inspection scan: Should Scan every byte of data on the computer 13. Scan target drives: Should Specify which directories and file types to scan 14. Scan exclusions: should Specify directories and file extensions not to be

scanned

15. Treatment options: Should Enable choice of action agents should take upon detection of virus: Automatic, notify, or confirm

Browser Security 16. Should Support common browsers 17. Should Provide a dual browser mode / unique browser exploit protection

that segregates corporate data from the Internet

18. Should Allow users the freedom to surf with full protection against malicious software that is automatically downloaded and phishing attempts

19. Should Secure through unique browser virtualization, heuristic anti-phishing and malware site detection

20. Should Support Browser Virtualization 21. Should Support Signature & Heuristic Phishing Protection 22. Should Support Site Status Check 23. Should Support Centralized Browser Security Policy Management


of 166

24. Should Support Centralized Browser Security Event Logging & Reporting Management Platform Support 25. Operating Systems: Should Support Windows/Linux 26. Solution should have single console to Manage desktop AV, Servers , Mail

and Web Gateway software solution

27. Should be a Software Solution Integrated, centrally-managed security framework-for a unified defense

28. Simplifies administration with automated update deployment & license renewal

29. Should have Intelligence with customizable, flexible reports for easy interpretation

30. Expands visibility into individual clients, reducing desk-side visits 31. Assign specific privileges based on predefined administrative roles 32. Allow user-defined customizable administrative roles 33. Supports visibility into clients so central IT can remotely monitor and

manage client security

34. Solution should support Role based administration 35. Should have capability to control the Outbreak scenario such as applying/

removing policy related to outbreak as when required.

36. Should have capability to provide critical alerts during virus outbreak, action taken on infections, suspicious vulnerability detection

37. Should be able to produce the reports on scheduled and one-time basis and shall also be able to automatically deliver reports via email to designated users

38. Reports shall support the following formats: PDF, RTF, ActiveX, Crystal Reports

39. Should have at least following report templates: Virus & Spyware/Grayware Detection Reports Antivirus Client Information Reports Antivirus Product Registration Report (Registration Status) Outdated Antivirus Client Consolidated Report

Client Platform Support 40. Should support Windows 7/8/10 (32 & 64 bit)/Linux/Windows Server

2003 and above

41. The antivirus solution should have enhanced protection from Network virus/Worms, Trojans, Key loggers, Intrusions, Conceivably harmful websites /Phishing sites, Malicious behavior, data loss, web based threats, root kits, mixed threats, real-time compressed executable files, spyware/gray ware etc.

42. Antivirus incremental pattern size should not be more than 5 KB and Sandbox technology should be used for browser exploit prevention to test the behavior of web pages in real time and detect any malicious script or program before the antivirus agent is exposed to threats

43. Should have a provision for setting up a local reputation server so that for verifying reputation of any file, endpoints should not contact Internet always. Client machine, which is acting as an update agent to deliver


of 166

pattern updates to rest of the machines in the LAN, should have the capability to upgrade program and agent software upgrades also without separate web server.

44. Client machine acting as update agent, which is delivering pattern updates to rest of the machines in the LAN, should have the capability to upgrade program upgrades also. No separate web server should be required.

45. Solution should be able to be managed from a central management console Antivirus solutions across operating systems and devices ( PCs, servers, mobile OS etc. )

46. Must be capable of cleaning viruses/malware even without the availability of virus cleanup components. Using a detected file as basis, it should be able to determine if the detected file has a corresponding process/service in memory and a registry entry, and then remove them altogether

47. Simplifies administration with automated update deployment and license renewal Provides single sign-on, eliminating the need to logon to each product Consolidates data for a master view of Central Manager servers throughout the network

48. Web Threat Protection provided should be browser independent meaning if malware tries to connect to any malicious domains/IPs without opening browser, Web Threat module should be able to block that access

49. Should have capability to provide critical alerts during virus outbreak, action taken on infections, suspicious vulnerability detection

50. Host based IDS/IPS should support virtual patching both known and unknown vulnerabilities until the next scheduled maintenance window.

51 Virtual Patching should be achieved by using a high-performance HIPS engine to intelligently examine the content of network traffic entering and leaving hosts.

52 Should provide automatic recommendations against existing vulnerabilities, Dynamically tuning IDS/IPS sensors (Eg. Selecting rules, configuring policies, updating policies, etc...) And provide automatic recommendation of removing assigned policies if vulnerability no longer exists - For Example - If a patch is deployed

53 The solution should have Application Control rules provide increased visibility into, or control over, the applications that are accessing the network. These rules will be used to identify malicious software accessing the network and provide insight into suspicious activities such as allowed protocols over unexpected ports (FTP traffic on a mail server, HTTP traffic on an unexpected server, or SSH traffic over SSL, etc.), which can be an indicator of malware or a compromise.

54 Solution should have Security Profiles allows Firewall rules to be configured for groups of systems, or individual systems. For example, all Windows 2003 servers use the same operating system rules, which are configured in a single Security Profile, which is used by several servers.

55 The solution should protect against Distributed DoS attacks


of 166

ANNEXURE-12: TECHNICAL SPECIFICATIONS FOR LOG MANAGEMENT

S.No. RISL's Requirement Compliance Yes/No

Remarks / reference to Data Sheets

1 Solution shall collect logs and perform analysis from a central point for all hardware, software, devices, applications and databases etc.

2 Should support user customizable event/log filtering analysis, reporting, generating alerts, triggers and long-term storage.

3 Should support minimum 3000 EPS.

4 Should provide the ability to drill down on output data.

5 Should securely make data available for monitoring without granting access to production systems.

6 Solution should be able to provide raw logs as and when required. Extracted logs should be in read-only format.

7 Logs collected from different components should be stored in their original ASCII format like syslog (preferably to a WORM device), even though LOG management system may use native format for query purpose.

8 The product must provide some mechanism that guarantees delivery of events such that no events will get lost if the log management system is unavailable.

9 The logs should be Searchable & the log format must be customizable

10 Any License or application required to run Enterprise level log management and reporting will be in the scope of the bidder.

11 Log Conversion Utilities may be used to convert proprietary format logs into standard formats.

12 Should be configurable to not record unwanted sensitive information such as passwords etc.

13 Monitor the logging status of all log sources to ensure that each source is enabled, configured properly, and functioning as expected.

14 Monitor log rotation and archival processes to ensure logs are archived and cleared correctly.

15 Check for upgrades and patches for logging software; acquire, test, and deploy the updates.

16 Reconfigure logging as needed based on factors such as policy changes, audit findings, technology changes, and new security needs.

17 Setup standard searches as real-time alerts and trigger automatic responses

18 Custom dashboards based on any search

19 Graphs to display log data and metrics to show percentiles, facets, histograms, week-over-week trends, etc.


of 166

20 The Log and report solution must be able to provide near real time log viewer/dash board.

21 Easy switching between logs, graphs, and views.

22 Adaptable interface with multiple views, pages and workspaces

23 Multiple report types: user activity, historical trends etc.

24 Built-in, simple and customized reports.

25 Ability to find similar events based on selected event.

26 Customizable alert on anything that can be extracted from a time series or log parser.

27 Built-in tool to quickly find cause of an issue/alert.

28 The solution shall have readymade templates to generate reports like complete reports or attack reports, bandwidth report, intranet report etc.

29 Should have options to generate reports in different formats like HTML, PDF, XML, MS Word etc.

30 Should support log rotation based on schedule (hourly, daily, weekly) or when log file reaches a certain size.

31 Should support secure log archival and retrieval in readable format for an extended period of time, typically on removable media etc.

32 Should support log compression during log rotation and archival.

33 Should store logs both at system level and infrastructure level until purged so that if either the system or infrastructure fails, the other should still have the log data.

34 The solution must be able to store one year of log data locally on disk.

35 Transmission and storage of log data should be encrypted and follow the basic rules of Confidentiality, Integrity and Authentication.

36 Should be able to retrieve raw logs of a particular device, source IP, destination IP, protocol or time for a particular period.

37 Should allow defining roles based on responsibilities of individuals involved.

38 Users should not have any access to log files unless required.

39 All network communications involving log data are protected appropriately as needed.

40 Should support a Distributed / Multi-tiered/Hierarchical logging system where there would be localized Log collectors in a collect/store/forward mode and eventually forwards logs to a Centralized Log server.

41 Should support Log collection at PR and DR sites while forwarding logs to the Central Log Collector at the PR Site.

42 Centralized Logging should support data retention up to 7 years.


of 166

43 The Centralized log server should be able to support/view/analyze logs to the maximum size supported by the Database.

44 Historical data should be viewable by the same interface by going to a different section on the user interface. There should not be a different tool for viewing and analyzing historical / archived data.

45 Reports, views, analysis, search, etc., all functions of the primary log interface should be available for historical data also.

46 Should be able to support SMS, email and SNMP trap notifications based on user defined alerting events and parameters.

47 Should be able to collect logs from heterogeneous sources like Windows, Unix/Linux, Network Devices, VMWare, Active Directory, Privilege User Monitoring, Firewalls, Applications, etc.

48 Should have reports like Event Trends, Category Trends, Alerting Trends, etc.


of 166

ANNEXURE-13: TECHNICAL SPECIFICATIONS FOR ENTERPRISE MANAGEMENT SYSTEM S. No RISL’s Requirements Compliant


1. Basic Requirements Solution should be inclusive with hardware, OS, patches, etc.

and should have compatibility to RDBMS supplied by bidder. Solution should provide for future scalability of the whole

system without major architectural changes. Should be SNMP compliant, scalable, support distributed

architecture and third party integrations Should provide performance management for multi-vendor

TCP/IP networks.

2. Security Should be able to provide secured windows based

consoles/secured web based consoles for accessibility to EMS.

Should have web browser interface with user name and Password Authentication.

Administrator/ Manager should have privilege to create/modify/delete user.

3. Fault Management Should be able to get fault information in real time and

present the same in alarm window with description, affected component, time stamp etc.

Should be able to get fault information from heterogeneous devices, routers, switches, servers etc.

Event related to servers should go to a common enterprise event console where a set of automated tasks can be defined based on the policy.

Should support advanced filtering to eliminate extraneous data / alarms in Web browser and GUI.

Should be configurable to suppress events for key systems/devices that are down for routine maintenance or planned outage.

Should be able to monitor on user-defined thresholds for warning/ critical states and escalate events to event console of enterprise management system.

Should have self-certification capabilities so that it can easily add support for new traps and automatically generate alarms.

Should provide sufficient reports pertaining to asset and change management, alarms and availability of critical network resources as well as network response times for critical links.

Should integrate network and server performance information and alarms in a single console and provide a


of 166

unified reporting interface for network and system components. The current performance state of the entire network and system infrastructure shall be visible in an integrated console.

Should provide an integrated performance view for all the managed systems and networks along with the various threshold violations alarms in them.

Should be able to auto-calculate resource utilization baselines for the entire managed systems and networks and allow user to set corresponding upper and lower threshold limits.

4. Monitoring Should be able to monitor/manage large heterogeneous

systems environment continuously. Should monitor / manage following (based on Stack):

o Event logs/OS/Memory/Disk(Logical and Physical)/Process/Processor/Paging file/Network interface traffic/cache/Active Directory/LDAP Services

o Virtual and physical memory statistics o Paging and swap statistics o Operating system o IP statistics o ICMP statistics o Network interface traffic o Cache o Active Directory / LDAP Services

Should monitor following with statistics : o Should monitor various operating system

parameters such as processors, memory, files, processes, file systems etc. where applicable using agents on the servers to be monitored.

o Application should be capable of monitoring the availability and performance of the IT infrastructure and services leveraging an agent- based or agentless monitoring approach.

o Memory(Physical and Virtual)/System virtual memory (includes swapping and paging)/Paging and swap/IP/ICMP/CPU Utilization, CPU Load Averages/Disc usage/Number of nodes /Critical sys Log Integration

o Web server statistics/HTTP and HTTPS Services/ICMP Services


of 166

ANNEXURE-14: TECHNICAL SPECIFICATIONS FOR HYPER CONVERGED INFRASTRUCTURE

S.No. RISL’s Requirements Compliant? (Yes / No)


1 The solution shall provide hyper-converged software that allows delivery of enterprise-class storage services using latest x86/x64 server infrastructures without dependence on a separate Storage Area Network & associated components such as SAN Switches & HBAs. It should be capable of supporting multiple hypervisors.

2 The solution should able to support different generation of Intel processors in the same cluster for investment protection over the life of the proposed solution.

3 The nodes should connect over 10G IP connectivity. Minimum 2x10G Ethernet port per node must be proposed. There should be no dependency on any proprietary or specialized interconnects. The OEM should provision compatible TOR switching with redundancy to ensure all nodes connectivity via TOR

4 Appliance must have Redundant Hot Plug High Efficiency Power Supply with N+1configuration.

5 Redundant Hot Plug High Speed Cooling Fans

6 The solution shall provide scale-up (by adding SSD/disks) and scale-out (by adding nodes) architecture with no disruption to the workloads already running on the platform

7 The solution should provide a single unified management console for the management of the entire environment including virtualized environment as well as software defined storage environment, underlying Hardware and associated components

8 The solution should deliver zero data loss in case of disk, host or network failure

9 The solution should support checksum of data to ensure data integrity & to enable automatic detection and resolution of silent disk errors.

10 The solution should support both hybrid and all flash configurations and both should exist in the same cluster

11 The solution should provide enterprise data services such as de-duplication and compression with erasure coding completely in software without dependence on any proprietary hardware. These should be delivered in hybrid and/or all flash appliances and in the same cluster. These functionalities should be part of the proposed solution and licensed.

12 Remote management features, Appliance management software capable of providing role-based security, alerts of critical component failure along with power monitoring. Should also provide for controlling Power, Fan management, Compute node initialization, Resource discovery and inventory management, Resource alerts and monitoring management, Compute node power management and diagnostics for elements including I/O options and compute nodes.


of 166

13 The hyper-converged appliance should support Hypervisor agnostic replication.

14 The solution must support migration of Virtual machines across multiple disaster recovery sites, so that key virtual machines can be recovered in times of disaster. All software licences for enabling the above must be part of overall solution.

15 The Solution should have capability to manage Firmware across entire hardware stack.

16 The hyper-converged appliance should support at least four hypervisor. (Microsoft, Vmware, Open KVM, Xenserver)

17 3 years comprehensive onsite warranty with 6 hours problem resolution.

18 The solution shall provide a purpose-built hypervisor with minimal footprint that installs directly on the bare metal x86 server

19 The solution shall provide a single console for management of the platform to conduct activities such as onboarding/managing hosts, virtual machines, storage and networks

20 The solution shall provide the ability to create new virtual machines from scratch or based on templates (created from fully configured virtual machines)

21 The solution shall provide the ability to rapidly on-board new hosts by automatically deploying reference configurations including networking settings

22 The solution shall intelligently place and balance virtual machines on appropriate available storage tier based on SLA, performance and availability requirements

23 The solution shall provide automated live migrations for initial placement and balancing of available resources with rules to define affinity and/or anti-affinity for workloads (eg. 2 VMs providing availability for each other should always be placed on different hosts)

24 The solution shall provide the ability to hot-add cpu and memory and hot-plug disks and NICs (provided the same is supported by the guest operating system)

25 The solution shall provide the ability to use flash devices on the host as a 'read & write cache' to improve performance for read & write sensitive workloads

26 The solution shall support configurations of 802.1q VLANs which are compatible with standard VLAN implementations from other vendors

27 Single view of all virtual machines, allow Monitoring of system availability and performance and automated notifications with alerts. Monitor and analyze virtual machines, and server utilization and availability with detailed performance graphs.

28 Virtualization management software should have integrated Physical Host and Virtual Machine performance monitoring.


of 166

29 Virtual Machine performance monitoring reports for performance and utilization of Virtual Machines. It shall co-exist and integrate with leading systems management vendors.

30 Virtualization management software should support user role and permission assignment (RBAC)

31 Virtualization management software console shall maintain a record of significant configuration changes and the administrator who initiated them.


of 166

ANNEXURE-15: TECHNICAL SPECIFICATIONS FOR BACKUP SOFTWARE

Sl. No. RISL Technical Specification Compliant (Yes/No)


1 Backup software must be present as Leaders in latest Gartner’s Magic Quadrant Report.

2 Backup software must support GUI with centralized management / Single interface for management of all backup activities.

3 The offered software must support Advanced sharing of different media across the environment (disk, tape and optical)

4 The offered software must support multiple level of backups including full, incremental, differential and synthetic full.

5

The offered software must include following application and database backup with native integration (without third party agents integration)for 64-bit Active Directory, SQL, Exchange, Share-Point, Oracle, MySQL, PostGreSQL etc.

7

The software must be able to perform inline block-level de-duplication of data across different electronic data repository like physical server, Virtual machine from different hypervisors, user machines etc.

8 The software must be able to Compress and Encrypt data at the Client-side and this feature should be available even during de-duplication.

9

The offered software must have more than three Encryption algorithms (like 128 bit AES, 256 BIT AES etc.) and it should not demand for additional license, any such license if needed should be quoted for the total backup capacity license.

10

The offered software must support complete integration of Server Backup, Desktop backup, Laptop Backup, Virtual Machine Backup, Archival and Replication Solution with a Single Console to manage all the solutions

11

The offered software must integrate with different hypervisors to backup different plarforms including RHEV, Vmware, Hyper-v, Oracle Virtual machine, Citrix Xen.

12 Backup solution must support multi tenancy feature for creation of distinct data zones.

13 The offered software must be able to auto discover guest VMs and dynamically configure them for data backup.

14 The software solution must provide full support for Global Filter lists.

15 The offered software solution must support IPV4 and IPV6 addressing system.

16 The offered software solution must have capability to do trend analysis for capacity planning of backup environment.

17 The offered software must be proposed for 5 TB capacity license

18 Five year support with 24x7x365 days must be included with license from OEM


of 166

ANNEXURE-16: TECHNICAL SPECIFICATIONS FOR TAPE LIBRARY S.No. RISL's Requirement Compliant

Yes/No Remarks / reference to Data Sheets

1. Should support Native data capacity of 120TB (uncompressed) expandable to 300TB (2.5:1 compressed).

2. Should be offered with two LTO6 FC tape drives supporting LTFS and AES 256-bit encryption.

3. Should be offered with 24 Cartridge slots.

4. Offered LTO6 drive in the Library shall conform to the Continuous and Data rate matching technique for higher reliability.

5. Offered LTO6 drive should support 160MB/sec in Native mode and 400MB/sec in 2.5:1 Compressed mode.

6. Offered Tape Library should provide 8Gbps native FC connectivity to SAN switches.

7. Offered Tape Library should have at-least two partition support so that drives can be configured in a partition with dedicated slots.

8. Offered Library should be provided with a hardware device like USB key, separate appliance etc. to keep all the encrypted keys in a redundant fashion.

9. Tape Library should provide web based remote management.

10. Tape library should support Barcode reader and mail slot.

11. Tape Library should have GUI Panel

12. Should be rack mountable

13. Should be supplied with redundant power supply


of 166

ANNEXURE-17: TECHNICAL SPECIFICATIONS FOR STAND ALONE EXTERNAL TAPE DRIVE S. No RISL’s Requirements Compliant


1 LTO Ultrium Half-Height Ultrium 15TB Tape Drive

2 LTO tape drive technology capable of storing up to 15TB (compressed 2.5:1) per cartridge

3 Offered LTO7 drive in the Library shall conform to the Continuous and Data rate matching technique for higher reliability.

4 Offered LTO7 drive shall support 300MB/sec in Native mode

5 Support for LTFS and AES 256-bit hardware data encryption easy-to-enable security to protect the most sensitive data and prevent unauthorized access of tape cartridges.

6 Shall be providing with SAS-based LTO Ultrium models with SAS cable which allows direct attach from embedded SAS controller. The HBA/interface/cables/licenses required for Server Connectivity to be supplied along with the Server Type – 2 components in this document.

7 Tape drive should support monitoring and management capabilities

8 Tape drive should support with software which can predict and prevent failures through early warning and shall also suggest the required service action.

9 Offered Software also have the capability to determine when to retire the tape cartridges and what compression ratio is being achieved


of 166

ANNEXURE-18: TECHNICAL SPECIFICATIONS FOR DATABASE – STANDARD EDITION S.No RISL’s Requirements Compliant


1. Must have built-in security means to protect its content (and users) from dangers of unauthorized users

2. Database should support OS clustering to avoid any single point of failure

3. Should support a sufficiently rich data manipulation language to allow data manipulations and information generation

4. Detailed documentation shall be provided for Database Management specific to the project and the applications deployed

5. GUI based tool shall be provided to manage, test and tune the database

6. The database should be provided with features which will allow securing / encrypting the sensitive / classified data

7. The database should provide with features, which will prevent the DB administrator and other users to delete / erase the audit trails

8. The Database should support a minimum of 4 Sockets or 24 Cores

9. Should be certified to work on the virtualization platform quoted by the vendor

10. Licenses as virtual instances should be limited to the number of cores of the VM

11. The system should support Log Shipping for High Availability.

12. The system should support Backup Compression

13. The system should support Database Snapshots

14. The system should support Failover Cluster instances for at least 2 nodes

15. The System should have default integration capabilities with the Central LDAP/Authentication mechanism of the project. The system should allow user authentication only via LDAP/Central Authentication mechanism which allows, groups, policies, users, roles, etc.

16. The system should support Row level security and encryption for backups.

17. The system should support snapshot, merge, transactional among other types of replication.


of 166

ANNEXURE-19: TECHNICAL SPECIFICATIONS FOR DATABASE – ENTERPRISE EDITION S. No RISL’s Requirements Compliant


1. Must have built-in security means to protect its content (and users) from dangers of unauthorized users

2. Database should support OS clustering to avoid any single point of failure

3. Should support a sufficiently rich data manipulation language to allow data manipulations and information generation

4. Detailed documentation shall be provided for Database Management specific to the project and the applications deployed

5. GUI based tool shall be provided to manage, test and tune the database

6. The database should be provided with features which will allow securing / encrypting the sensitive / classified data

7. The database should provide with features, which will prevent the DB administrator and other users to delete / erase the audit trails

8. Should support cores to the operating systems maximum support

9. Should be certified to work on the virtualization platform quoted by the vendor

10. Licenses as virtual instances should be limited to the number of cores of the VM and not the entire Virtual environment hardware stack.

11. The system should support Log Shipping for High Availability.

12. The system should support Backup Compression

13. The system should support Database Snapshots

14. Should support OS maximum of failover cluster instances

15. Should support availability groups with synchronous replicas

16. The system should support Data Compression, Table and index partitioning

17. The System should have default integration capabilities with the Central LDAP/Authentication mechanism of the project. The system should allow user authentication only via LDAP/Central Authentication mechanism which allows, groups, policies, users, roles, etc.

18. The system should support database encryption, row level security and other encryption features

19. Should support peer-to-peer transactional replication with updatable subscription


of 166

ANNEXURE-20: BIDDER’S AUTHORIZATION CERTIFICATE{to be filled by the bidder} To, {Procuring entity}, ______________________________, ______________________________, I/ We {Name/ Designation} hereby declare/ certify that {Name/ Designation} is hereby authorized to sign relevant documents on behalf of the company/ firm in dealing with NIB reference No. ______________________ dated _________. He/ She is also authorized to attend meetings & submit technical & commercial information/ clarifications as may be required by you in the course of processing the Bid. For the purpose of validation, his/ her verified signatures are as under. Thanking you, Name of the Bidder: - Verified Signature: Authorised Signatory: - Seal of the Organization: - Date: Place:


of 166

ANNEXURE-21: SELF-DECLARATION{to be filled by the bidder} To, {Procuring entity}, ______________________________, In response to the NIB Ref. No. _____________________________ dated ___________ for {Project Title}, as an Owner/ Partner/ Director/ Auth. Sign. of ____________________________________, I/ We hereby declare that presently our Company/ firm _________________, at the time of bidding,: -

a) possess the necessary professional, technical, financial and managerial resources and competence required by the Bidding Document issued by the Procuring Entity;

b) have fulfilled my/ our obligation to pay such of the taxes payable to the Union and the State Government or any local authority as specified in the Bidding Document;

c) is having unblemished record and is not declared ineligible for corrupt & fraudulent practices either indefinitely or for a particular period of time by any State/ Central government/ PSU/ UT.

d) does not have any previous transgressions with any entity in India or any other country during the last three years

e) does not have any debarment by any other procuring entity f) isnot insolvent in receivership, bankrupt or being wound up, not have its affairs

administered by a court or a judicial officer, not have its business activities suspended and is not the subject of legal proceedings for any of the foregoing reasons;

g) does not have, and ourdirectors and officers not have been convicted of any criminal offence related to their professional conduct or the making of false statements or misrepresentations as to their qualifications to enter into a procurement contract within a period of three years preceding the commencement of the procurement process, or not have been otherwise disqualified pursuant to debarment proceedings;

h) does not have a conflict of interest as mentioned in the bidding document which materially affects the fair competition.

i) will comply with the code of integrity as specified in the bidding document. If this declaration is found to be incorrect then without prejudice to any other action that may be taken as per the provisions of the applicable Act and Rules thereto prescribed by GoR, my/ our security may be forfeited in full and ourbid, to the extent accepted, may be cancelled. Thanking you, Name of the Bidder: - Authorised Signatory: - Seal of the Organization: - Date: Place:


of 166

ANNEXURE-22: CERTIFICATE OF CONFORMITY/ NO DEVIATION{to be filled by the bidder} To, {Procuring Entity}, ______________________________, CERTIFICATE This is to certify that, the specifications of services and resources which I/ We have mentioned in the Technical bid, and which I/ We shall supply if I/ We am/ are awarded with the work, are in conformity with the minimum specifications of the bidding document and that there are no deviations of any kind from the requirement specifications. Also, I/ we have thoroughly read the bidding document and by signing this certificate, we hereby submit our token of unconditional acceptance to all the terms & conditions of the bidding document without any deviations. I/ We also certify that the price I/ we have quoted is inclusive of all the cost factors involved in the end-to-end implementation and execution of the project, to meet the desired Standards set out in the bidding Document. Thanking you, Name of the Bidder: - Authorised Signatory: - Seal of the Organization: - Date: Place:


of 166

ANNEXURE-23: MANUFACTURER’S AUTHORIZATION FORM (MAF){to be filled by the OEMs} To, {Procuring Entity}, ______________________________, Subject: Issue of the Manufacturer’s Authorisation Form (MAF) Reference: NIB/ RFP Ref. No. _____________________ dated ________ Sir, We {name and address of the OEM} who are established and reputed original equipment manufacturers (OEMs) having factories at {addresses of manufacturing location} do hereby authorize {M/s __________________________} who is our {Distributor/ Channel Partner/ Retailer/ Others <please specify>}to bid, negotiate and conclude the contract with you against the aforementioned reference for the following Hardware/ Software manufactured by us: - {OEM will mention the details of all the proposed product(s) with their make/ model.} We undertake to provide standard OEM support for the offered Hardware/ Software, as mentioned above, for three Years from the date of commissioning of phase wise hardware/software. We hereby confirm that the offered Hardware/ Software is not likely to be declared as End-of-Sale within next twelve months from the date of bid submission. We hereby confirm that the offered Hardware/ Software is not likely to be declared as End-of-Service/ Support within next three years from the date of bid submission.] Yours faithfully, For and on behalf of M/s (Name of the manufacturer) (Authorized Signatory) Name, Designation & Contact No.: Address: ___________________________________ Seal:


of 166

ANNEXURE-24: COMPONENTS OFFERED – BOM

Please fill the following BOM for all the offered components.

S.No. Product Details

(Only one make and model)

Detailed Technical

Specification Reference**

OEM Details

(Name, Address, E-

Mail, Mobile Nos.)

1. {Item No. xx}

2. {Item No. xx}

3. {Item No. xx}

** Please attach technical specifications compliance sheet (on OEM letter head only) and provide

reference number in this column. (deviations, if any, should be appropriately mentioned &

highlighted in the compliance/ deviation column of the respective table as provided above in the

technical specifications)


of 166

ANNEXURE-25: FINANCIAL BID COVER LETTER & FORMAT COVER LETTER {to be submitted by the bidder on his Letter head} To, The Managing Director, RajCOMP Info Services Limited, Yojana Bhawan Campus, Tilak Marg, C-Scheme, Jaipur (Raj.) Reference: NIB No. :___________________________________ Dated:__________ Dear Sir, We, the undersigned bidder, Having read & examined in detail, the Bidding Document, the receipt of which is hereby duly acknowledged, I/ we, the undersigned, offer to work as mentioned in the Scope of the work, specifications, Service Level Standards & in conformity with the said bidding document for the same. I / We undertake that the prices are in conformity with the specifications prescribed. The quote/ price are inclusive of all cost likely to be incurred for executing this work. The prices are inclusive of all type of govt. taxes/duties as mentioned in the financial bid (BoQ). I / We undertake, if our bid is accepted, to deliver the services in accordance with the schedule specified in the schedule of Requirements. I/ We hereby declare that in case the contract is awarded to us, we shall submit the contract performance guarantee as prescribed in the bidding document. I / We agree to abide by this bid for a period of _____ days after the last date fixed for bid submission and it shall remain binding upon us and may be accepted at any time before the expiry of that period. Until a formal contract is prepared and executed, this bid, together with your written acceptance thereof and your notification of award shall constitute a binding Contract between us. I/ We hereby declare that our bid is made in good faith, without collusion or fraud and the information contained in the bid is true and correct to the best of our knowledge and belief. We understand that you are not bound to accept the lowest or any bid you may receive. We agree to all the terms & conditions as mentioned in the bidding document and submit that we have not submitted any deviations in this regard. Date: Authorized Signatory Name: Designation:


of 166

Financial Bid Format {to be submitted by the bidder only in BoQ format (.XLS) available at eProc portal}

S.No. Item No. and

Description

Unit Qty Per Unit Cost (in INR)

(inclusive of all taxes, levies,

and duties applicable

excluding CST, VAT and

Service Tax – as applicable)

CST if applicable

in INR

VAT if applicable

In INR

Service Tax if applicable

In INR

Total Cost (in INR)

inclusive of all taxes

A B C D E F G H I= D X (E+F+G+H)

1. CAPEX Cost for Raj eSign Digital Signature Platform

No. 1

2. OPEX Cost for 5 Years for Raj eSign Digital Signature Platform

No. 1

Total (In Figures) – Rs.

Total In Words

NOTE:

a) Service Tax and RVAT if any will be paid at prevailing rates. b) While tabulating the financial Bids, the element of Rajasthan Value Added Tax (RVAT)

shall be excluded from the rates quoted by the firms of Rajasthan and the element of Central Sales Tax (CST) shall be included in the rates of firms from outside Rajasthan for financial bid evaluation purpose.


of 166

ANNEXURE-26: BANK GUARANTEE FORMAT{to be submitted by the bidder’s bank} BANK GUARANTEE FORMAT – BID SECURITY (To be stamped in accordance with Stamp Act and to be issued by a Nationalised/ Scheduled bank having its branch at Jaipur and payable at par at Jaipur, Rajasthan) To, The Managing Director, RajCOMP Info Services Limited, Yojana Bhawan Campus, Tilak Marg, C-Scheme, Jaipur (Raj.) Sir, 1. In accordance with your Notice Inviting Bid for <please specify the project title> vide NIB

reference no. <please specify> M/s. …………………………….. (Name & full address of the firm) (Hereinafter called the “Bidder”) hereby submits the Bank Guarantee to participate in the said procurement/ bidding process as mentioned in the bidding document. It is a condition in the bidding documents that the Bidder has to deposit Bid Security amounting to <Rs. ______________ (Rupees <in words>)> in respect to the NIB Ref. No. _______________ dated _________ issued by RajCOMP Info Services Limited, , Yojana Bhawan Campus, Tilak Marg, C-Scheme, Jaipur, Rajasthan (hereinafter referred to as “RISL”) by a Bank Guarantee from a Nationalised Bank/ Scheduled Commercial Bank having its branch at Jaipur irrevocable and operative till the bid validity date (i.e. <please specify> days from the date of submission of bid). It may be extended if required in concurrence with the bid validity. And whereas the Bidder desires to furnish a Bank Guarantee for a sum of <Rs. ______________ (Rupees <in words>)> to RISL as earnest money deposit.

2. Now, therefore, we the ……………………………….…… (Bank), a body corporate constituted under the Banking Companies (Acquisition and Transfer of Undertaking) Act. 1969 (delete, if not applicable) and branch Office at…………………... (hereinafter referred to as the Guarantor) do hereby undertake and agree to pay forthwith on demand in writing by RISL of the said guaranteed amount without any demur, reservation or recourse.

3. We, the aforesaid bank, further agree that RISL shall be the sole judge of and as to whether the Bidder has committed any breach or breaches of any of the terms costs, charges and expenses caused to or suffered by or that may be caused to or suffered by RISL on account thereof to the extent of the Earnest Money required to be deposited by the Bidder in respect of the said biddingdocument and the decision of RISL that the Bidder has committed such breach or breaches and as to the amount or amounts of loss, damage, costs, charges and expenses caused to or suffered by or that may be caused to or suffered by RISL shall be final and binding on us.

4. We, the said Bank further agree that the Guarantee herein contained shall remain in full force and effect until it is released by RISL and it is further declared that it shall not be necessary for RISL to proceed against the Bidder before proceeding against the Bank and the Guarantee herein contained shall be invoked against the Bank, notwithstanding any security which RISL may have obtained or shall be obtained from the Bidder at any time when proceedings are


of 166

taken against the Bank for whatever amount that may be outstanding or unrealized under the Guarantee.

5. Any notice by way of demand or otherwise hereunder may be sent by special courier, telex,

fax, registered post or other electronic media to our address, as aforesaid and if sent by post, it shall be deemed to have been given to us after the expiry of 48 hours when the same has been posted.

6. If it is necessary to extend this guarantee on account of any reason whatsoever, we undertake

to extend the period of this guarantee on the request of our constituent under intimation to you.

7. The right of RISL to recover the said amount of <Rs. ______________ (Rupees <in words>)> from

us in manner aforesaid will not be precluded/ affected, even if, disputes have been raised by the said M/s. ……….………………(Bidder) and/ or dispute or disputes are pending before any court, authority, officer, tribunal, arbitrator(s) etc..

8. Notwithstanding anything stated above, our liability under this guarantee shall be restricted

to <Rs. ______________ (Rupees <in words>)> and our guarantee shall remain in force till bid validity period i.e. <please specify> days from the last date of bid submission and unless a demand or claim under the guarantee is made on us in writing within three months after the Bid validity date, all your rights under the guarantee shall be forfeited and we shall be relieved and discharged from all liability thereunder.

9. This guarantee shall be governed by and construed in accordance with the Indian Laws and

we hereby submit to the exclusive jurisdiction of courts of Justice in India for the purpose of any suit or action or other proceedings arising out of this guarantee or the subject matter hereof brought by you may not be enforced in or by such count.

10. We hereby confirm that we have the power/s to issue this Guarantee in your favor under the

Memorandum and Articles of Association/ Constitution of our bank and the undersigned is/are the recipient of authority by express delegation of power/s and has/have full power/s to execute this guarantee under the Power of Attorney issued by the bank in your favour.

Date ………………… (Signature) ………………………………………. Place ………………… (Printed Name) …………………………………. (Designation) …………………………………… (Bank’s common seal) …………………………. In presence of: WTTNESS (with full name, designation, address & official seal, if any) (1) ……………………………………… ……………………………………… (2) ……………………………………… ……………………………………… Bank Details Name & address of Bank : Name of contact person of Bank: Contact telephone number:


of 166

GUIDELINES FOR SUBMISSION OF BANK GUARANTEE The Bank Guarantee shall fulfil the following conditions in the absence of which they cannot be considered valid: - 1. Bank Guarantee shall be executed on non- judicial stamp paper of applicable value purchased

in the name of the bank. 2. Two persons should sign as witnesses mentioning their full name, designation, address and

office seal (if any). 3. The Executor (Bank Authorities) may mention the power of attorney No. and date of

execution in his/ her favour authorizing him/ her to sign the document. The Power of Attorney to be witnessed by two persons mentioning their full name and address.

4. The Bank Guarantee should be executed by a Nationalised Bank/ Scheduled Commercial Bank only.

5. Non – Judicial stamp paper shall be used within 6 months from the date of Purchase of the same. Bank Guarantee executed on the non-judicial stamp paper after 6 (six) months of the purchase of such stamp paper shall be treated as non-valid.

6. The contents of Bank Guarantee shall be strictly as per format prescribed by RISL 7. Each page of Bank Guarantee shall bear signature and seal of the Bank and B.G. number. 8. All corrections, deletions etc. in the Bank Guarantee should be authenticated by signature of

Bank Officials signing the Bank Guarantee. 9. Bank should separately send through registered post/courier a certified copy of Bank

Guarantee, mentioning Bid reference, Bid title and bidder name, directly to the Purchaser at the following address:


of 166

BANK GUARANTEE FORMAT – PERFORMANCE SECURITY (PBG) (To be stamped in accordance with Stamp Act and on a Stamp Paper purchased from Rajasthan State only and to be issued by a Nationalised/ Scheduled bank having its branch at Jaipur and payable at par at Jaipur, Rajasthan) To, The Managing Director, RajCOMP Info Services Limited, Yojana Bhawan Campus, Tilak Marg, C-Scheme, Jaipur (Raj.) 1. In consideration of the RajCOMP Info Services Limited (hereinafter called "RISL") having

agreed to exempt M/s ..........................(hereinafter called "the said Contractor(s)" from the demand, under the terms and conditions of an Work Order No...................................dated .....................made between RISL and .......................(Contractor) for the work ................. of Security Deposit for the due fulfilment by the said Contractor (s) of the terms and conditions contained in the said work order, on production of a Bank Guarantee for Rs...................(Rupees ........................................only), we ...................(indicate the name of the Bank), (hereinafter referred to as "the Bank") at the request of ..................Contractor(s) do hereby undertake to pay to RISL an amount not exceeding Rs...................(Rupees..................................only) on demand.

2. We................. (Indicate the name of Bank), do hereby undertake to pay Rs.................... (Rupees............................only), the amounts due and payable under this guarantee without any demur or delay, merely on a demand from RISL. Any such demand made on the bank by RISL shall be conclusive as regards the amount due and payable by the Bank under this guarantee. The Bank Guarantee shall be completely at the disposal of RISL and We....................... (Indicate the name of Bank), bound ourselves with all directions given by RISL regarding this Bank Guarantee. However, our liability under this guarantee shall be restricted to an amount not exceeding Rs...................... (Rupees....................only).

3. We.......................(indicate the name of Bank), undertake to pay to RISL any money so demanded notwithstanding any dispute or disputes raised by the contractor(s) in any suit or proceeding pending before any Court or Tribunal or Arbitrator etc. relating thereto, our liability under these presents being absolute, unequivocal and unconditional.

4. We.....................(indicate the name of Bank) further agree that the performance guarantee herein contained shall remain in full force and effective up to <DATE> and that it shall continue to be enforceable for above specified period till all the dues of RISL under or by virtue of the said Agreement have been fully paid and its claims satisfied or discharged or till RISL certifies that the terms and conditions of the said Agreement have been fully and properly carried out by the said Contractor(s) and accordingly discharges this guarantee.

5. We ...........................(indicate the name of Bank) further agree with RISL that RISL shall have the fullest liberty without our consent and without affecting in any manner our obligations hereunder to vary any of the terms and conditions of the said work order or to extend time of performance by the said Contractor(s) from time to time or to postpone for any time or from time to time any of the powers exercisable by RISL against the said Contractor(s) and to forbear or enforce any of the terms and conditions relating to the said work order and we shall not be relieved from our liability by reason of any such variation, or extension being granted to the said Contractor(s) or for any forbearance, act or omission on the part of RISL or any indulgence by RISL to the said Contractor(s) or by any such matter or thing whatsoever which would but for this provision, have effect of so relieving us.

6. The liability of............................. (indicate the name of Bank), under this guarantee will not be discharged due to the change in the constitution of the Bank or the contractor(s).


of 166

7. We .............................. (indicate the name of Bank), lastly undertake not to revoke this guarantee except with the previous consent of RISL in writing.

8. This performance Guarantee shall remain valid and in full effect, until it is decided to be discharged by RISL. Notwithstanding anything mentioned above, our liability against this guarantee is restricted to Rs........................... (Rupees..............................only).

9. It shall not be necessary for RISL to proceed against the contractor before proceeding against the Bank and the guarantee herein contained shall be enforceable against the Bank notwithstanding any security which RISL may have obtained or obtain from the contractor.

10. We .............................. (indicate the name of Bank) verify that we have a branch at Jaipur, Rajasthan. We undertake that this Bank Guarantee shall be payable at any of its branch at Jaipur, Rajasthan. If the last day of expiry of Bank Guarantee happens to be a holiday of the Bank, the Bank Guarantee shall expire on the close of the next working day.

11. We hereby confirm that we have the power(s) to issue this guarantee in your favour under the memorandum and articles of Association/constitution of our bank and the undersigned is/are the recipient of authority by express delegation of power(s) and has/have full power(s) to execute this guarantee for the power of attorney issued by the bank.

Dated..........................day of....................For and on behalf of the <Bank> (indicate the Bank)

Signature (Name & Designation) Bank's Seal

The above performance Guarantee is accepted by RISL For and on behalf of RISL

Signature

(Name & Designation)


of 166

ANNEXURE-27: DRAFT AGREEMENT FORMAT{to be mutually signed by selected bidder and procuring entity} This Contract is made and entered into on this ______day of ________, 2017 by and between RajCOMP Info Services Limited, having its head office at Yojana Bhawan Campus, Tilak Marg, C-Scheme, Jaipur-302005, Rajasthan (herein after referred to as Purchaser/ RISL) which term or expression, unless excluded by or repugnant to the subject or context, shall include his successors in office and assignees on ONE PART And M/s__________________, a company registered under _______________ with its registered office at _____________________ (herein after referred as the “Successful Bidder/ Supplier”) which term or expression, unless excluded by or repugnant to the subject or context, shall include his successors in office and assignees on the OTHER PART. Whereas, Purchaser is desirous of appointing an agency for <project title>as per the Scope of Work and Terms and Conditions as set forth in the RFP document dated _________ of <NIB No _________________>. And whereas The supplier represents that it has the necessary experience for carrying out the overall work as referred to herein and has submitted a bid and subsequent clarifications for providing the required services against said NIB and RFP document issued in this regard, in accordance with the terms and conditions set forth herein and any other reasonable requirements of the Purchaser from time to time. And whereas Purchaser has accepted the bid of supplier and has placed the Work Order vide Letter No. __________________dated _______, on which M/s__________ has given their acceptance vide their Letter No._____________ dated ____________. And whereas The supplier has deposited a sum of Rs. ________________/- (Rupees _________________) in the form of __________________ ref no. _________________ dated ______________ of ____________ Bank and valid up to _____________ as security deposit for the due performance of the contract. Now it is hereby agreed to by and between both the parties as under: - 1. The NIB Ref. No. ____________________________ dated ___________ and RFP document dated _________

issued by RISL along with its enclosures/ annexures, wherever applicable, are deemed to be taken as part of this contract and are binding on both the parties executing this contract.

2. In consideration of the payment to be made by RISL to successful bidder at the rates set forth in the work order no. ____________________ dated_________ will duly deliver the services in the manner set forth in the RFP, along with its enclosures/ annexures and Technical Bid along with subsequent clarifications submitted by supplier.

3. RISL do hereby agree that if successful bidder shall duly deliver services in the manner aforesaid observe and keep the said terms and conditions of the RFP and Contract, RISL will pay or cause to be paid to successful bidder, at the time and the manner set forth in the said conditions of the RFP, the amount payable for each and every project milestone & deliverable. The mode of Payment will be as specified in the RFP document.

4. The timelines for the prescribed Scope of Work, requirement of services and deployment of technical resources shall be effected from the date of work order i.e. ____________ and completed by successful bidder within the period as specified in the RFP document.


of 166

5. In case of extension in the delivery of services and completion period with liquidated damages, the recovery shall be made on the basis of following percentages of value of services and products only for which successful bidder has failed to deliver / complete: -

Delay up to one fourth period of the prescribed delivery of services& completion of work.

2.5%

Delay exceeding one fourth but not exceeding half of the prescribed delivery of services & completion of work.

5.0%

Delay exceeding half but not exceeding three fourth of the prescribed delivery of services & completion of work.

7.5%

Delay exceeding three fourth of the prescribed delivery of services & completion of work.

10.0%

Note: v. Fraction of a day in reckoning period of delay in services shall be eliminated if it is less

than half a day. vi. The maximum amount of agreed liquidated damages shall be 10%.

vii. If successful bidder requires an extension of time in completion of contractual delivery on account of occurrence of any hindrances, he shall apply in writing to the authority which had placed the work order, for the same immediately on occurrence of the hindrance but not after the stipulated date of completion of supply.

viii. Delivery period may be extended with or without liquidated damages if the delay in the delivery of services in on account of hindrances beyond the control of supplier.

6. All disputes arising out of this agreement and all questions relating to the interpretation of this agreement shall be decided as per the procedure mentioned in the RFP document.

In witness whereof the parties have caused this contract to be executed by their Authorized Signatories on this _____day of _______________, 2013.

Signed By: Signed By: () Designation:, Company:

Managing Director RajCOMP Info Services Limited

In the presence of:

In the presence of:

() Designation: Company:

() Designation: RajCOMP Info Services Limited

( ) Designation: Company:

() Designation: RajCOMP Info Services Limited


of 166

ANNEXURE-28: FORMAT FOR SUBMISSION OF PROJECT REFERENCES FOR PRE-QUALIFICATION EXPERIENCE

Project Name: Value of Contract/Work Order (In INR):

Country: Location within country:

Project Duration:

Name of Customer: Total No. of staff-months of the assignment:

Contact person with address, phone, fax and e-mail:

Approx. value of the services provided by your company under the contract (in INR):

Start date (month/year): Completion date (month/year): Name of associated Bidders, if any:

Narrative description of Project:

List of Services provided by your firm/company

Please attach a copy of the work order/ completion certificate/ purchase order/ letter from the customer for each project reference


of 166

ANNEXURE-29: MEMORANDUM OF APPEAL UNDER THE RTPP ACT, 2012 Appeal No ………of …………… Before the ………………………… (First/ Second Appellate Authority) 1. Particulars of appellant:

a. Name of the appellant: <please specify> b. Official address, if any: <please specify> c. Residential address: <please specify>

2. Name and address of the respondent(s):

a. <please specify> b. <please specify> c. <please specify>

3. Number and date of the order appealed against and name and designation of the officer/

authority who passed the order (enclose copy), or a statement of a decision, action or omission of the procuring entity in contravention to the provisions of the Act by which the appellant is aggrieved:<please specify>

4. If the Appellant proposes to be represented by a representative, the name and postal address

of the representative:<please specify> 5. Number of affidavits and documents enclosed with the appeal:<please specify>

6. Grounds of appeal (supported by an affidavit):<please specify>

7. Prayer:<please specify> Place ……………………………………. Date …………………………………… Appellant's Signature


of 166

ANNEXURE-30: FORMAT FOR CV General Information Name of the person Proposed Role in the Project Proposed Responsibilities in the Project Academic Qualifications:

Degree Academic institution graduated from Year of graduation Specialization (if any) Key achievements and other relevant

information (if any)

Professional Certifications (if any) Total number of years of experience Number of years with the current company Summary of the Professional / Domain Experience

Past assignment details (For each assignment provide details regarding name of organizations worked for, designation, responsibilities, tenure) Prior Professional Experience covering:

Organizations worked for in the past o Organization name o Duration and dates of entry

and exit o Designation Location(s) o Key responsibilities

Prior project experience Project name Client Key project features in brief Location of the project Designation Role Responsibilities and activities Duration of the project

Please provide only relevant projects.

Proficient in languages (Against each language listed indicate if speak/ read/ write)

RFP for Raj eSign Digital Signature Platform

Documents

Transcript of RFP for Raj eSign Digital Signature Platform