Background
The Cyber Security Directions, first notified on April 28, 2022 (Directions), have been in force since July 27, 2022.1 Based on industry feedback, CERT-IN had extended the deadline for enforcement on Micro, Small & Medium enterprises (MSMEs) and of parts of Direction 5 till September 25, 2022.2 This deadline has now expired; the Directions now apply across the board in full.
On September 25th, NASSCOM and the Data Security Council of India (DSCI) made a representation to CERT-IN outlining persisting concerns with the Directions being faced by the industry. The aim was to highlight practical challenges that had been realised since July 27th, which would likely have an amplified impact on MSMEs. We summarise the representation below.
General comments across the Directions
We underlined the fact that the Directions were the only legally binding instrument for industry to determine compliance and make investment decisions with certainty. However, the Frequently Answered Questions (FAQs) published in May 2022 contained several material changes to the Directions.3 Given that the FAQs are not recognised by the law or the CERT-IN as a document that can be legally recognised as a basis for compliance, industry risks non-compliance even if it adheres to the FAQs.
Moreover, even if the industry decides to rely on the FAQs, the global clients of the industry placed in a situation where they would be forced to question the industry as to the legal position of the FAQ and doubt the reliability of compliance status. This has created challenges for any due diligence, compliance audit, or risk assessment process, and created scope for undue frictions to arise in commercial relationships. We recommended, therefore, that CERT-IN may release updated Directions incorporating the FAQs as well as any additional guidance it may have provided to the industry via other channels.
We also noted the need to generally clarify how the Directions were to be read with the rest of the IT Act, in two ways: (1) that the CERT-IN Rules continue to apply to the operation of these Directions (2) that the Directions’ jurisdictional scope should be read in accordance with section 75 of the IT Act. This requires a connection to be established to systems in India. We submitted that, to reflect this section, it should be clarified that the Directions do not apply to offshore entities that do not serve Indian customers or do not have operations or systems in India.
Specific comments on each of the Directions
On Direction 1, we submitted that it should be clarified that organisations can sync their systems with third-party NTP servers that are traceable to UTC, since the NIC and NPL NTP servers also sync to this time. We submitted that there is a need for clarity on how this Direction applies to air-gapped or isolated systems, specifically, that it is sufficient that they are synchronised at regular intervals.
On Direction 2, we submitted that (1) the Directions should clearly state that the 6-hour reporting timeline only applies to the material categories of incidents stated in Question 30 of the FAQs (2) the Directions should clarify that organisations can adopt a “reasonable security” approach to defining how to comply with this Direction given their sectoral and organisational contexts – particularly in terms of defining their own policies on how to assessing individual incidents and defining how they “notice” incidents.
On Direction 3, we submitted that there are apprehensions that the Points of Contact will be held personally liable for potential infringements of the Directions. The requirement for a POC originates from the CERT-IN Rules, which was silent on this matter. However, the IT Act does suggest that penalties are to be applied to entities, not individuals, for infringements of any Directions issued by CERT-IN. To afford industry certainty, we submitted that the role of POC should be clarified. We also requested that it be clarified that (1) POCs can be foreign nationals, so that appointments are based not on location, but on information security capabilities (2) the contact details notified for POCs can be group email IDs, so that multiple people can use the ID and respond to CERT-In in a timely manner.
On Direction 4, we submitted that the clarity afforded by the FAQs – that only logs relevant to information security and for critical applications – should be reflected in the text of the Directions. We also submitted that it be clarified that organisations can adopt a “reasonable security” approach to defining how to comply with this Direction given their sectoral and organisational contexts – particularly in terms of defining their own policies on how to minimise the retention of personal data in such logs, or how to ensure alignment with existing models in the industry, such as the shared responsibility model in cloud computing. Further, the clarity from the FAQs, that logs can be stored outside India as long as CERT-IN’s lawful requests can be met when required, should also be reflected in the text of the Directions.
On Direction 5, we submitted that, because there are several sources of uncertainty arising from the text of Direction 5, it is not possible to estimate the quantum of resources and developmental time needed to actually meet this requirement. The sources of uncertainty include:
- The requirement to “validate” subscriber details. This can be interpreted in several different ways, and for which there is no standard market solution. Further, companies are private actors and lack, and should not have, the legal authority to guarantee to others the authenticity of proof supplied by customers, such as government identification numbers. Finally, covered entities already collect customer details authenticated under sectoral frameworks. For example, as part of existing onboarding processes, covered entities collect customers’ contact, payment instrument details, and, for business customers, GST numbers, as well. These are already subject to their own know-your-customer processes. It is unclear how these can be ‘verified’ any further and, in a connected larger point, what the gap with the existing processes followed in industry actually is that this Direction seeks to fill. Building unnecessary verification processes disrupts customers’ journeys, which impacts the doing of business in India. We recommended this requirement be dropped.
- The intended period of collection frequency and retention. The text of Direction 5 can also be interpreted as requiring customer information to be kept in a continually updated state for 5 years. However, based on prior discussions with CERT-IN, we understood that it is likely that the intent is actually that covered entities perform a one-time capture of customer information during the initial onboarding process and that data of initially captured customer data is to be kept for 5 years. This latter interpretation should be reflected in the text of the Directions, as it would clarify that covered entities do not have to keep data up to date, which would be beyond their control. Further, the inter-relationship with Direction 4 can also be clarified. So, for example, the IPs allotted to customers at the time of assignment would be stored for 5 years, while logs of IPs being dynamically allotted would, if relevant from a security or critical application standpoint, only must be stored for 180 days (under Direction 4).
- The concept of “enterprise/corporate VPNs” from the FAQs. Direction 5 applies to providers of virtual private networks. In Question 34 of the FAQs, it is clarified that this does not include “enterprise/corporate VPNs”. However, the FAQs do not provide an explanation of this concept. From prior discussions with CERT-IN, we learnt that this concept refers to end-user entities using VPNs internally, whether by using their own solution or as customers of providers of VPNs. Such end-user organisations would not have to comply with Direction 5. This clarity should be provided in the Directions.
For more information, kindly write to varun@nasscom.in ; apurva@nasscom.in (at NASSCOM) or atul.kumar@dsci.in (at DSCI).
