CERT-In Directives Compliance for Indian SaaS in 2026: 6 Hour Reporting and 180 Day Logging

Why CERT-In Compliance Is Now a Procurement Gate in India

The Indian Computer Emergency Response Team (CERT-In) issued landmark directions in April 2022 under Section 70B(6) of the Information Technology Act 2000. These directions reset the operating expectations for cybersecurity reporting and logging in India and have been operational since June 2022. By 2026 the directions are deeply embedded in BFSI procurement, public sector tenders, large enterprise vendor onboarding, and the parallel Digital Personal Data Protection Act compliance program. The text and FAQ are published at cert-in.org.in and the parent ministry context is at meity.gov.in.

Indian SaaS founders often discover the CERT-In obligations during the worst possible moment, after an incident or during a hostile audit. By then the missing 180 day logs and the late incident report have already created exposure. The good news is that the directions are operationally clear, and a 30 day implementation sprint moves a SaaS to a defensible posture and unblocks BFSI and government adjacent procurement.

Who Is in Scope Under the CERT-In Directions

The directions apply to a broad set of entities operating in India:

• Service providers (SaaS, PaaS, IaaS) serving Indian users
• Intermediaries as defined under the IT Act
• Data centers and managed service providers
• Body corporates handling personal or sensitive personal data
• Government organizations and PSUs
• Virtual Private Server (VPS) providers
• Cloud service providers
• Virtual Private Network (VPN) providers
• Cryptocurrency exchanges and virtual digital asset service providers

Practical SaaS rule for 2026: assume you are in scope. The carve outs are narrow and the exposure on the wrong side is high.

The 6 Hour Incident Reporting Window

The directions require that specified cyber incidents be reported to CERT-In within 6 hours of noticing or being brought to notice. This is one of the tightest reporting windows in any major jurisdiction in 2026. The categories of incidents that must be reported are listed in Annexure I of the directions and include:

• Targeted scanning, probing, and reconnaissance of critical networks
• Compromise of critical systems and information
• Unauthorized access to ICT systems and data
• Defacement of websites and intrusions
• Malicious code attacks (including ransomware)
• Attacks on servers (DNS, mail, application)
• Identity theft and phishing
• Denial of service and distributed denial of service
• Attacks on critical infrastructure, IoT systems, and SCADA
• Data breaches and data leaks
• Attacks or incidents involving cryptographic systems
• Fake mobile apps

The 6 hour clock starts at the point of noticing. The word noticing is significant. CERT-In does not require a confirmed root cause analysis to start the clock. A reasonable belief that a reportable category applies is enough.

What the Report Must Contain

The submission template (also in the directions) covers:

• Time of incident and time of detection
• Affected systems, networks, and applications
• Description of the symptoms and the apparent cause
• Estimated impact
• Actions taken to contain and respond
• Contact details of the reporting person and organization

Submissions are made via email, fax, or the CERT-In portal. The email submission path remains the most common in 2026. Build the submission template into your incident response runbook so that 5 of the 6 hours are not spent drafting from scratch. See our companion guide to incident response readiness for startups for the runbook framing.

The 180 Day In Country Log Retention

All ICT system logs must be enabled and securely maintained for a rolling 180 days. Logs must be retained within the Indian jurisdiction. CERT-In may require the logs at any time during incident investigation or supervisory activity.

What Logs Must Be Retained

The CERT-In FAQ enumerates the expected categories. For a typical SaaS deployment the practical scope covers:

• Authentication and access logs (success and failure)
• Privilege use and administrative actions
• System and OS logs
• Application access logs
• Database access logs (especially privileged queries)
• Network flow logs (firewall, load balancer, VPC flow)
• DNS query logs
• Endpoint detection and response logs
• Security tooling alerts and outcomes
• Email server logs
• Cloud control plane logs (CloudTrail, Audit Logs)

The In Country Storage Requirement

The retention must be in Indian jurisdiction. SaaS founders running in AWS Mumbai, GCP Mumbai, or Azure India regions are aligned. Founders running primarily in Singapore, US, or EU regions must replicate or back up logs to an Indian region. Build the logging architecture so the in country store is the system of record. Pair with our secure logging and telemetry architecture deep dive.

KYC and Customer Information for VPN, VPS, Cloud, and Crypto

Specified categories of providers carry an additional obligation to maintain customer information for at least 5 years even after the customer has left the service. Affected categories include VPN providers, VPS providers, cloud service providers, and virtual digital asset service providers. The information set is broad: validated names, contact details, ownership patterns, IP allocations, and purpose of usage. SaaS founders running adjacent services should verify whether they fall in this expanded category.

How CERT-In Stacks With DPDP, RBI, SEBI, and IRDAI Frameworks

CERT-In is the cross sector cybersecurity reporting and logging baseline. It runs in parallel with sector specific cybersecurity rules.

• DPDP Act: personal data breach notification to the Data Protection Board and to affected Data Principals. Plan both DPDP and CERT-In notification flows in a single runbook. See our DPDP Act compliance for Indian SaaS startups guide.
• RBI cybersecurity guidelines: additional reporting and recovery time objective expectations for banks, payment system operators, and NBFCs. SaaS vendors selling to Indian BFSI inherit RBI flow downs.
• SEBI cyber resilience framework: reporting and audit cadence for stock exchanges, depositories, listed entities, and intermediaries.
• IRDAI Information and Cyber Security Guidelines: applicable to insurers and SaaS vendors serving them.

The takeaway for SaaS founders: build one incident response runbook with sector specific notification branches. Test it in a tabletop exercise. Indian BFSI buyers ask for evidence of the most recent test during procurement and renewal.

The 30 Day CERT-In Readiness Sprint for SaaS

Days 1 to 5: Inventory and Gap Assessment

Inventory the ICT systems, the data flows, and the existing log sources. Map each to the CERT-In log categories. Identify which categories are missing or insufficiently retained. Identify the regional location of each log store. Document the result as a gap register.

Days 6 to 12: Logging Architecture Uplift

Stand up a centralized logging stack in an Indian region. Common patterns include AWS CloudWatch with cross account aggregation in Mumbai, GCP Cloud Logging with Cloud Storage retention in Mumbai, or self managed Loki, OpenSearch, or Elastic in Indian region VMs. Configure 180 day retention. Encrypt at rest. Restrict access. Pair with the patterns in cloud IAM hardening.

Days 13 to 20: Application and Database Log Coverage

Add the application access logs, the privileged database query logs, and the cloud control plane logs that are commonly missing. Many SaaS deployments capture network flow but forget application authentication events.

Days 21 to 25: Incident Response Runbook Update

Bake the CERT-In submission template into the runbook. Add the 6 hour clock to the incident command checklist. Pre approve a notification email template. Add the DPDP notification path in parallel. Identify the named submitters and an escalation list.

Days 26 to 30: Tabletop Exercise and Evidence Pack

Run a 90 minute tabletop. Validate that the runbook, the logs, and the submitter rotation work end to end. Capture screenshots, after action notes, and the timeline. This artifact goes into the trust pack for BFSI and public sector buyers.

The CERT-In Submission Template (Pre Drafted)

A pre drafted submission shaves hours off the 6 hour clock. Maintain a template covering:

1. Organization name, address, point of contact
2. Date and time of incident in IST
3. Date and time of noticing
4. Affected systems, networks, applications
5. Symptoms observed
6. Apparent or suspected cause
7. Estimated extent of compromise
8. Actions taken to contain and respond
9. Forensic preservation steps in progress
10. Anticipated next steps and follow up window

The template is a starting point. The actual submission must reflect the incident specifics. Update before send.

Common 2026 Pitfalls We See in Indian SaaS

• Logs in Singapore or US only. The in country requirement is strict. Mirror to Indian region.
• Application authentication logs never captured. SaaS often logs only network flow. Add app level auth events.
• No named submitter for CERT-In. The 6 hour window cannot survive a search for the right person at midnight.
• Treating CERT-In and DPDP as separate runbooks. One incident triggers both. Unified runbook saves time.
• Missing tabletop exercise evidence. BFSI procurement asks. Run one quarterly and capture screenshots.
• Ignoring the KYC obligations for adjacent services. If your SaaS runs a VPN, VPS, or crypto adjacent feature, the 5 year customer information retention applies.

The Buyer Trust Pack for Indian BFSI and Public Sector

Indian BFSI procurement teams now expect a 1 page CERT-In compliance summary covering:

• Acknowledgement of CERT-In April 2022 directions
• 180 day log retention architecture summary with India region location
• Categories of logs maintained
• Incident response runbook overview with 6 hour submission template
• Named CERT-In submitter and escalation list
• Tabletop exercise cadence with most recent date
• Cross map to RBI, SEBI, or IRDAI sector specific obligations as applicable
• Coordination with DPDP Act notification path

Pair this with the broader vendor security questionnaire response playbook to close BFSI deals 3x faster.

Frequently Asked Questions

Are foreign SaaS vendors subject to CERT-In directions?

If the SaaS provides services in India or to Indian customers, CERT-In takes the position that the directions apply. Most foreign SaaS selling into India operate as in scope by default.

Can the 6 hour clock start at root cause confirmation?

No. The clock starts at noticing. CERT-In has been clear that confirmation of root cause is not required to begin the report.

Does CERT-In require physical Indian servers?

The directions require logs to be maintained within Indian jurisdiction. Cloud regions located in India satisfy this. SaaS founders should verify the physical region of each log store.

What are the penalties for not complying with CERT-In directions?

Non compliance can attract penalties under Section 70B(7) of the IT Act 2000, which includes imprisonment up to one year and fines, plus contractual fallout from BFSI and government customers.

How does CERT-In coordinate with DPDP breach notifications?

The two regimes operate in parallel. A single incident may require both a CERT-In submission within 6 hours and a DPDP notification to the Board and affected Data Principals. Build the unified runbook so neither gets missed.

Conclusion: Operational Discipline as Indian Sales Wedge

CERT-In compliance in 2026 is not a paperwork exercise. It is operational discipline that converts directly into Indian enterprise revenue. BFSI buyers, public sector tenders, and large Indian enterprises filter SaaS vendors by their CERT-In posture before shortlisting. The 30 day readiness sprint pays back in faster deals, smoother audits, and a defensible story when the inevitable incident happens.