India Cybersecurity

India Cybersecurity, CERT-In, Scams and Cyber Law: A Practical Safety Guide

A source-grounded guide to India cybersecurity, CERT-In recommendations, scam and phishing risks, cyber law considerations, and ransomware-ready recovery steps.

Text-free editorial illustration of a secure Indian digital network with a shield, connected devices, and a recovery pathway

India cybersecurity, CERT-In, scams and cyber law** are easiest to understand as one connected safety problem: people and organizations need to prevent deceptive access, preserve evidence when something goes wrong, respond in a disciplined way, and recover without making the incident worse. The supplied 2026 evidence does not provide a national count of scams or ransomware victims, so this guide avoids unsupported totals and focuses on documented recommendations and observed investigation findings. The immediate lesson is practical. Phishing and exploitation of unpatched software are described as common access methods in the revised FBI/CISA/HHS advisory on Medusa ransomware. CERT-In’s CIAD-2026-0020 advisory recommends offline backups aligned with the 3-2-1 rule, restoration tests, incident-response contacts, log preservation, tested continuity procedures, and cyber drills. Those controls help an individual, an Indian MSME, or a larger organization create a safer path from suspicion to recovery. This is an evidence-led explainer, not a substitute for legal advice or an incident responder. The provided research file does not set out a statute-by-statute account of Indian cyber law, specific reporting deadlines, penalties, or a measured India scam trend. Where the evidence is limited, the article says so plainly. > **Key Takeaways > - India cybersecurity is strongest when scam awareness, access protection, evidence preservation, reporting, and recovery are planned together. > - CERT-In’s cited 2026 advisory recommends secure offline backups, 3-2-1 backup design, restoration testing, incident-response contacts, log preservation, business-continuity testing, and regular drills. > - Phishing and unpatched software are documented entry routes in the Medusa advisory; treat unexpected requests and exposed systems as operational security risks. > - Cyber law considerations begin with disciplined records and careful coordination. Do not assume that a backup, payment, or informal message alone completes a legal or reporting obligation. > - The research supports resilience guidance, not claims about a national 2026 attack count, scam volume, victim list, or search demand.

What India cybersecurity means for everyday risk

India cybersecurity is not only a technology purchase. It is the set of decisions that keeps identities, devices, applications, backups, records, and business services from being misused or made unavailable. For a small organization, that may mean controlling administrator access, updating exposed software, teaching staff how to question unexpected messages, and knowing which systems must be restored first. For an individual, it can mean slowing down before opening a link, sharing a code, or approving an unfamiliar request.

The ransomware evidence shows why this broader view matters. Google Cloud/Mandiant’s M-Trends 2026 summary says that, in more than 500,000 hours of global investigations conducted in 2025, operators targeted backup infrastructure, identity services, and virtualization management planes. The summary also describes deletion of cloud backup objects and attacks on hypervisor storage. These findings come from a vendor investigation sample, not a census of every incident, but they show why “we have a backup” is not the same as “we can recover.”

Security also has a time dimension. The same M-Trends summary reports that the median hand-off from initial access to a secondary cybercrime group fell from more than eight hours in 2022 to 22 seconds in 2025, within its investigation sample. That observation supports a simple operating rule: suspicious activity should be escalated quickly, before an attacker can move from an account or endpoint into identities, backups, or shared infrastructure.

For a practical companion on preparation and recovery, see [ransomware attacks and recovery in 2026](https://cyberoinfo.com/cybersecurity/ransomware-attacks-and-recovery-2026). The goal is not to create fear. It is to make the next safe action obvious when a message, login, device, or service does not look right.

How CERT-In guidance supports India cybersecurity

CERT-In is most useful in this evidence set as a practical coordination and resilience reference. The cited CERT-In Advisory CIAD-2026-0020 addresses frontier-AI-driven cyber risks rather than presenting a ransomware incident series or a measured India trend. Its recommendations are still relevant to preparation: maintain secure offline backups aligned with the 3-2-1 rule, test restoration, preserve logs, keep incident-response contacts including CERT-In, contain suspicious activity, test business-continuity and disaster-recovery procedures, and conduct regular cyber drills.

The 3-2-1 idea is operational rather than decorative. It asks an organization to design several copies of important data across different media or locations, with an offline or otherwise protected copy that an intruder cannot casually alter along with production systems. The exact implementation depends on the organization, but the core test is simple: can the team restore a clean, usable copy after an account, cloud object, server, or virtualization layer is compromised?

Testing matters because a backup that has never been restored is an assumption. A useful exercise records who can authorize restoration, which systems are business-critical, how clean media is validated, where recovery credentials are kept, and how staff communicate while normal systems are unavailable. CERT-In’s cited advisory also points MSMEs toward structured response plans and restoration testing, which makes the guidance applicable even when a dedicated security team is not available.

The CERT-In recommendation to preserve logs and maintain response contacts connects technical work to accountability. It helps a team reconstruct what happened, brief responders, support appropriate reporting, and avoid guessing. For more small-business context, see [cybersecurity for Indian MSMEs](https://cyberoinfo.com/cybersecurity/cybersecurity-for-msmes-in-india).

How scams and phishing become an entry point

Scams often succeed by creating pressure: an unexpected request appears urgent, familiar, authoritative, or financially consequential. The supplied evidence does not quantify online scams in India, but the revised FBI/CISA/HHS Medusa advisory identifies phishing as a common method used by the described ransomware actors. That makes scam resistance part of ransomware prevention, not a separate awareness topic.

A safer response to an unexpected message is to pause and verify through a known channel. Do not use the phone number, reply address, QR code, or link supplied by the suspicious message as the only verification route. Check the request with the person or team through a previously trusted contact method, and report the message through the organization’s established process. For high-risk accounts, reduce unnecessary privileges so that one deceptive interaction cannot grant broad access.

The advisory also describes exploitation of unpatched software as a common route and notes opportunistic targeting of unpatched systems. That is why awareness training cannot replace technical maintenance. Inventory internet-facing services, apply updates through a controlled process, remove unnecessary exposure, and monitor important accounts and systems. If a message leads to a new login, tool, or download, treat the resulting activity as a possible security event rather than assuming the user made an innocent mistake.

The response should be supportive. People are more likely to report quickly when the process is clear and non-punitive. A short internal instruction such as “stop, disconnect only as directed, preserve the message, and contact the response lead” can be more useful than a long policy that nobody remembers. For a focused reader guide, see [phishing and online scams](https://cyberoinfo.com/cybersecurity/phishing-and-online-scams).

Cyber law: what evidence and response discipline can support

Cyber law is not a single technical control. In an incident, it sits alongside evidence handling, reporting, contracts, privacy decisions, communications, and coordination with authorized responders. The supplied research file does not provide a complete analysis of Indian statutes, legal deadlines, penalties, or jurisdiction-specific duties. Accordingly, this section does not invent a legal rule; it explains the records and decision discipline that can help an organization obtain qualified advice and respond responsibly.

Start by preserving what may explain the event. Keep relevant logs, alert details, suspicious messages, affected account information, system images or memory where feasible, and a time-ordered incident record. CISA’s #StopRansomware Guide recommends isolating impacted systems, preserving images, memory, and logs where possible, triaging critical systems for restoration, hunting for persistence and exfiltration, and checking for available decryptors with law enforcement or responders. These are response practices, not a statement that every organization has identical legal duties.

Avoid casual deletion, speculation, or public accusations. Record who observed what, when a decision was made, what was isolated, which evidence was preserved, and which qualified internal or external adviser was consulted. Keep copies of communications and document whether data exfiltration was suspected, because the distinction between encryption and threatened publication is operationally important. The Medusa advisory describes double extortion as encryption combined with threatened publication of exfiltrated data; it does not establish that every incident has the same facts.

A written incident record also supports better coordination with CERT-In, law enforcement, insurers, customers, vendors, and legal counsel when those parties are relevant. Before an incident, an organization should identify the appropriate contacts and approval path rather than improvising under pressure. For a plain-language companion, see [cyber law and digital safety](https://cyberoinfo.com/cybersecurity/cyber-law-and-digital-safety). This article should not be read as legal advice or as a substitute for advice on a specific incident.

What to do during a suspected ransomware incident in India

The first priority is containment without destroying evidence. Follow the organization’s response plan, isolate affected systems as directed, and escalate immediately. Do not reconnect a suspected device simply to see whether it works, and do not begin broad cleanup before a responder has considered evidence preservation. CISA’s response checklist places isolation, preservation of images, memory and logs, critical-system triage, threat hunting, and clean-network restoration in the response sequence.

Next, determine the scope carefully. Identify affected users, endpoints, servers, cloud services, identity systems, backup systems, and virtualization management. Look for persistence and possible data exfiltration, not only encrypted filenames. The M-Trends 2026 summary specifically describes attackers targeting backup infrastructure, identity services, and virtualization management planes, so a recovery plan should not trust every administrative account or backup control simply because it appears available.

Then validate the recovery path. Select clean backups or golden images, confirm that restoration media is not silently altered, and restore critical services in a prioritized order. CISA recommends offline, encrypted backups, regular integrity and restoration tests, golden images, and an exercised incident-response and communications plan. CERT-In’s cited advisory similarly emphasizes offline backups, restoration testing, response contacts, continuity procedures, and drills.

Finally, coordinate reporting and communications through the designated incident lead, qualified counsel, and appropriate authorities or responders. Avoid promising that payment guarantees recovery; the supplied evidence does not support that claim. Capture lessons learned, rotate exposed credentials, harden access, and test the revised plan. A calm, documented sequence is safer than a rushed attempt to make systems look normal.

How Indian MSMEs can build a practical recovery plan

An MSME does not need a large security department to begin. Write down the few services that keep the organization operating, the people who can authorize recovery, the accounts that can change backups or identity settings, and the trusted contacts for technical, legal, insurance, and reporting support. CERT-In’s CIAD-2026-0020 explicitly gives MSMEs practical advice to test backup restoration and maintain a structured response plan.

Protect recovery from the same failure as production. Maintain offline or otherwise strongly separated copies, limit administrative permissions, use distinct recovery credentials, and test whether a compromised administrator account can alter or delete backups. The 3-2-1 alignment recommended in the CERT-In advisory is a design starting point, not a guarantee; the organization still needs to test integrity, restoration speed, dependencies, and staff readiness.

Use a short exercise to expose gaps. Simulate a phishing-led account compromise, an unavailable file server, or a suspected data-exfiltration event. Ask who receives the first report, who can isolate systems, how staff continue work, where logs are collected, what gets restored first, and how customers or partners are briefed. Document answers and revise the plan rather than treating the exercise as a one-time compliance ritual.

The broader recovery framework is consistent across the supplied sources. NIST’s final IR 8374 Rev. 1, published in June 2026, maps ransomware risk management to CSF 2.0 outcomes: govern, identify, protect, detect, respond, and recover. That sequence gives an MSME a useful way to organize incremental work without claiming that every business faces the same threat profile.

FAQ: India cybersecurity, CERT-In, scams and cyber law

### Does the research prove that ransomware or scams increased across India in 2026?

No. The research file explicitly says that no measured India ransomware trend, national incident count, scam volume, victim list, search volume, or trend score was supplied. It supports an evidence-led resilience article, not a numeric claim about India-wide growth.

### What does the cited CERT-In advisory recommend?

CERT-In Advisory CIAD-2026-0020 recommends secure offline backups aligned with the 3-2-1 rule, regular restoration testing, maintained incident-response contacts including CERT-In, log preservation, containment and reporting when suspicious activity is found, tested business-continuity and disaster-recovery procedures, and regular cyber drills. The advisory is about frontier-AI-driven cyber risks; it is not presented as a ransomware incident count.

### Is phishing a scam issue or a ransomware issue?

It can be both. The revised FBI/CISA/HHS Medusa advisory identifies phishing as a common access method, while scam awareness focuses on deceptive requests and social pressure. A suspicious message should be handled as a possible security event until it is verified, with fast reporting and preservation of the message and related records.

### What should an organization preserve after a suspected attack?

Preserve relevant logs, alert details, suspicious messages, affected account information, and system images or memory where feasible. Record a time-ordered account of observations and decisions. CISA’s guide emphasizes preservation and careful triage; qualified responders and legal advisers can determine what additional records are appropriate for the incident.

### Does this article explain every cyber-law obligation in India?

No. The supplied source context does not contain a complete statute-by-statute legal analysis, specific deadlines, or penalties. The article therefore focuses on evidence preservation, response discipline, coordination, and qualified advice rather than presenting an unsupported legal checklist.

Limitations

  • Evidence and guidance can change; verify current advisories and organisational applicability before acting.

Evidence sources

  1. enisa.europa.eu — ENISA Threat Landscape — 2026 key highlights and reporting period
  2. cisa.gov — FBI/CISA/HHS #StopRansomware: Medusa Ransomware — revised August 18, 2026
  3. cloud.google.com — Google Cloud/Mandiant M-Trends 2026 — ransomware recovery denial and investigation findings
  4. cisa.gov — CISA #StopRansomware Guide — prevention and response checklist
  5. csrc.nist.gov — NIST IR 8374 Rev. 1 — Ransomware Risk Management: CSF 2.0 Community Profile
  6. cert-in.org.in — CERT-In Advisory CIAD-2026-0020 — defending against frontier AI-driven cyber risks