How Do the Two Frameworks' Thresholds Differ?

The gap between CERT-In and NIS2 reporting thresholds creates a practical challenge. CERT-In casts a wide net, capturing incidents that NIS2 would consider too minor to report. Conversely, NIS2's "significant incident" definition includes cross-border impact assessment, a dimension CERT-In doesn't address.

CERT-In: Low Threshold, Broad Scope

CERT-In reportable incidents include targeted scanning, probing attempts, and any unauthorised access. A port scan against your network from an unknown source technically requires reporting. The rationale is early detection at a national level, giving CERT-In visibility into emerging threat patterns.

NIS2: Higher Threshold, Deeper Analysis

NIS2 focuses on incidents with material impact. A contained phishing attempt that doesn't compromise systems likely wouldn't meet the "significant" threshold. But an incident causing service degradation to your EU client's operations would.

The Overlap Problem

Here's where it gets complex for Indian IT vendors. Consider a ransomware attack on systems hosting EU client data:

• CERT-In: Report within 6 hours. Covers the malicious code attack category.
• NIS2: Report within 24 hours (early warning). The incident likely qualifies as "significant."
• DPDPA: If personal data is involved, additional notification to India's Data Protection Board.

Now consider a targeted scanning attempt against your perimeter:

• CERT-In: Report within 6 hours. Scanning is explicitly listed.
• NIS2: Likely no reporting required. Scanning alone rarely meets the "significant" threshold.

[UNIQUE INSIGHT] This asymmetry actually works in Indian companies' favour. Meeting CERT-In's stricter timeline for a broader set of incidents means you'll always detect NIS2-reportable events within the 24-hour window. The challenge isn't timing. It's maintaining two separate classification and notification systems.

How Should Indian Companies Structure Dual Reporting?

Only 34% of Indian IT firms serving EU clients have established dual reporting processes (DSCI, 2025). The remaining 66% either report to CERT-In only or handle NIS2 obligations on an ad-hoc basis. A structured approach eliminates gaps and reduces response time.

Build a Unified Incident Classification Matrix

Create a single matrix that classifies incidents against both frameworks simultaneously. For each incident type, map:

• Whether it triggers CERT-In reporting (yes/no)
• Whether it meets NIS2's "significant" threshold (yes/no/assess)
• Whether personal data is involved (triggering DPDPA)
• The applicable timelines for each triggered obligation

Implement Parallel Notification Tracks

Your incident response playbook should branch at the notification step. Once an incident is classified:

1. Minute 0-60: Contain, assess severity, classify against the dual matrix
2. Hour 1-6: Prepare and submit CERT-In report (covers all qualifying incidents)
3. Hour 1-24: Prepare and submit NIS2 early warning to the relevant EU CSIRT (for significant incidents only)
4. Hour 24-72: Prepare detailed NIS2 incident notification
5. Within one month: Submit NIS2 final report with root cause analysis

Designate Dual Reporting Officers

Assign clear responsibility. Your CERT-In reporting contact and your NIS2 liaison may be different individuals, especially if your EU client has a designated CSIRT relationship. Both must be trained on their respective frameworks and empowered to submit reports without waiting for management approval.

[PERSONAL EXPERIENCE] In practice, we've found that Indian IT companies with 24/7 SOC operations adapt to dual reporting more quickly. The SOC team already monitors for incidents continuously. Adding a classification layer and branching notification process typically takes 4-6 weeks of process development and tabletop exercises.

What Happens When Your EU Client Reports Before You Do?

This scenario is more common than most Indian vendors expect. According to ENISA (2024), NIS2 entities are responsible for their own incident reporting regardless of whether the incident originated at a supplier. If your EU client detects an issue in your systems before you do, they'll report it, and you'll face difficult questions.

The Trust Problem

When a client reports an incident originating in your environment before you've notified them, it signals monitoring gaps. The client will question whether you have adequate detection capabilities, a direct NIS2 Article 21 requirement for supply chain security.

Prevention Strategies

• Share threat intelligence proactively. Provide regular security status updates to EU clients.
• Establish joint escalation procedures. Define shared severity classifications and communication channels.
• Implement real-time monitoring dashboards. Give clients visibility into the security posture of shared systems.
• Conduct joint tabletop exercises. Simulate incidents to test dual reporting processes before a real event occurs.

According to Gartner (2025), organisations that conduct joint incident response exercises with key suppliers reduce mean time to detection by 40% compared to those that don't.

Citation capsule: Organisations conducting joint incident response exercises with suppliers reduce mean time to detection by 40% (Gartner, 2025), making collaborative preparedness essential for Indian vendors supporting NIS2-regulated EU clients.

What Are Common Mistakes Indian Companies Make?

Several patterns emerge repeatedly. Understanding them helps you avoid the same pitfalls that have tripped up early adopters.

Mistake 1: Treating CERT-In Compliance as Sufficient

Meeting CERT-In requirements doesn't satisfy NIS2. The formats differ, the authorities differ, and NIS2's three-phase structure demands ongoing engagement after the initial report. A CERT-In submission is a one-time notification. NIS2 expects updates and a comprehensive final report.

Mistake 2: Applying NIS2 Thresholds to CERT-In

Some companies overfit. They assess every incident against NIS2's "significant" threshold and only report those to CERT-In. This creates gaps because CERT-In's scope is broader. Scanning attempts, minor access events, and IoT attacks all require CERT-In notification regardless of NIS2 applicability.

Mistake 3: Unclear Ownership

When both Indian and EU reporting obligations exist, companies sometimes assume the EU client handles NIS2 reporting entirely. The client may handle CSIRT notification, but they'll expect detailed incident data from you within tight timescales. If you haven't prepared that data, you'll miss their deadlines.

Mistake 4: Inadequate Log Retention

CERT-In requires 180 days of log retention within India. NIS2 doesn't specify a retention period, but EU authorities conducting post-incident audits expect comprehensive logs. Many Indian companies retain logs for 90 days, satisfying neither requirement fully.

Based on incident response engagements across Indian IT service companies, the most common failure point is the 72-hour NIS2 notification. Companies meet the 24-hour early warning but struggle to compile the detailed impact assessment NIS2 demands within 72 hours, particularly when cross-border impact must be evaluated.

Frequently Asked Questions

Does meeting CERT-In's 6-hour deadline automatically satisfy NIS2?

No. While CERT-In's tighter timeline means you'll detect incidents early enough for NIS2, the two systems require separate reports to different authorities in different formats. CERT-In reports go to India's CERT-In team. NIS2 reports go to EU national CSIRTs. You must submit both independently.

Who is responsible for NIS2 reporting, the Indian vendor or the EU client?

The EU client bears primary NIS2 reporting responsibility. However, they depend on you for incident data, timelines, and impact assessments. Contractual agreements typically require the Indian vendor to provide all necessary information within hours. Failure to do so damages the relationship and may breach your contract.

What if an incident affects both Indian and EU systems simultaneously?

Report to CERT-In within 6 hours covering the Indian systems. Simultaneously support your EU client's NIS2 reporting by providing impact data for EU-facing systems. If personal data is involved, DPDPA obligations add a third track. A unified incident response playbook with parallel paths is essential.

How should Indian companies prepare for NIS2 incident reporting audits?

EU authorities may audit your client's incident response capability, which includes your contribution. Maintain detailed records of all incident classifications, notification timelines, response actions, and follow-up reports. Conduct annual tabletop exercises simulating dual-reporting scenarios and document the results.

Are there tools that support dual CERT-In and NIS2 reporting?

SIEM platforms like Splunk, Microsoft Sentinel, and IBM QRadar can be configured with dual classification rules and automated notification workflows. The key is configuring incident severity mapping against both frameworks' thresholds and automating the initial report generation for each authority.

Key Takeaways on CERT-In vs NIS2 Incident Reporting

Dual incident reporting under CERT-In and NIS2 is a practical reality for Indian IT companies serving EU clients. The frameworks differ in timelines, thresholds, formats, and authorities, but they share a common goal: faster detection and response.

Build a unified incident classification matrix. Implement parallel notification tracks. Train your SOC team on both frameworks. Conduct joint exercises with EU clients.

The 6-hour CERT-In window is your binding constraint. Meet it consistently, and you'll always have time for NIS2's 24-hour early warning. The real challenge is the 72-hour detailed notification and one-month final report, which demand thorough documentation and root cause analysis capabilities.

Start by mapping your current incident types against both frameworks' reporting thresholds. That single exercise reveals exactly where your gaps are.