#FactCheck -Viral Post Falsely Attributes Communal NEET Remark to Kangana Ranaut; Fact Check Debunks Claim

Executive Summary

‍
A collage made by combining two images is going viral on social media. It is being shared as being related to the recent devastating floods in Nepal. One image in the collage shows a beautiful town before the floods, while the other depicts the destruction caused by the flooding. A research done by the Research Wing of the CyberPeace found the viral claim to be false. The research revealed that the viral image collage circulating on social media is AI-generated and is being falsely shared as visuals of the recent floods in Nepal.

‍

Claim:

‍

A user on social media platform Facebook shared the viral collage with the caption: “Nepal in the morning, Nepal in the evening. The tragedy has shaken all of humanity. The flood originating from China-occupied Tibet devastated Nepal in an instant.”

The link to the post, its archived version, and a screenshot are provided below.

https://www.facebook.com/photo/?fbid=1630488505774559&set=a.467756888714399

https://archive.ph/cGVjB 

‍

‍

Fact Check

‍

To verify the authenticity of the viral images, the desk first conducted a reverse image search. However, the search did not lead us to any credible media reports or original sources featuring these images. We then closely examined the images. The analysis revealed several anomalies in the structure of the buildings, the vehicles visible on the road, and other elements in the images, further strengthening the suspicion that they were AI-generated. We then scanned the viral image using the AI detection tool Hive Moderation. The tool’s analysis indicated a 99 percent likelihood that the image was AI-generated.

‍

‍

We then scanned the viral image using the AI detection tool Sightengine as well. The tool’s analysis indicated a 99 percent likelihood that the image was AI-generated.

‍

‍

Conclusion

‍

Our research found that the viral collage of images being shared on social media is AI-generated and is being falsely linked to the recent floods in Nepal.

‍

Introduction

For years, Indian companies could get away with vague privacy promises. That window closed on 13 November 2025, when the government notified the Digital Personal Data Protection Rules, giving teeth to the broad principles Parliament had passed back in 2023 under the DPDP Act. The Rules turned soft commitments into specific, auditable duties, and a lot of organisations are only now realising how much that actually changes.

Start with Section 8(4). It requires every Data Fiduciary to put "appropriate technical and organisational measures" in place. Most readers skim past "organisational" and focus on the technical half, but that's a mistake, because the word is doing real work. It's asking for defined roles, written policies, staff training, and someone actually watching whether any of it holds up over time, not just firewalls and encryption keys. Section 8(5) goes further, demanding reasonable security safeguards against breaches, and Rule 6 spells out exactly what that phrase means in practice: encrypt data at rest and in transit, restrict access on a need to know basis, require multi factor authentication, log and monitor activity, run regular vulnerability checks, bind your data processors contractually to the same standard, and keep relevant logs for at least a year.

Then there's Rule 7, and this is where the clock starts running. Once a Data Fiduciary becomes aware of a breach, the Data Protection Board must be told without delay, and a full report has to follow within 72 hours covering what happened, when, why, what's being done about it, and confirmation that affected individuals were notified. Unlike GDPR, there's no minimum severity threshold here. A breach affecting ten people triggers the same obligation as one affecting ten million. And CERT-In's existing six hour reporting window under its 2022 Directions still applies separately, which means a serious incident can trigger two overlapping regulatory clocks running side by side.

Put all of this together and a pattern emerges. The law assumes an organisation already knows what it's protecting, has actually protected it, kept usable records the whole way through, and can explain clearly what happened the moment something breaks. That coordination job belongs to Governance, Risk and Compliance, or GRC for short. GRC decides who's accountable, which risks actually matter, which controls address them, and how anyone checks whether compliance is real rather than assumed. Skip that structure and security work tends to splinter into a pile of disconnected tasks nobody truly owns.

GRC gives a legal duty somewhere to live. Forensic readiness is what lets an organisation prove, months or years later, that the duty was actually being met.

The Role of Governance, Risk and Compliance

On paper, most cybersecurity programmes look fine. There's an incident response plan somewhere, access control rules exist, logging is "in place," and someone has a title that says they're responsible for security. None of that gets tested until something actually breaks. A phishing compromise, a ransomware infection, a leaked database, a hijacked admin account, whatever the trigger, the questions that follow are always the same, and they're not comfortable ones. What happened, exactly, and when did it start? Which systems, which data, were actually touched? Were the controls the organisation claims to run genuinely functioning at that moment, or just described in a slide deck somewhere? And can anyone produce records solid enough to answer those questions with confidence rather than a shrug?

This is the exact seam where GRC and digital forensics meet. GRC lays out what's expected, who's responsible, and what evidence a control should be generating in the background. Digital forensics is the craft of taking whatever technical traces actually exist and turning them into an account of events that will hold up to scrutiny. Passing an audit was never really the point. Being able to stand in front of a regulator, mid incident, and show that the processes described on paper were real, active, and generating trustworthy evidence, that's the actual bar.

Why Compliance Alone Falls Short

Compliance, in the narrow sense, just means meeting whatever legal, contractual, or internal requirement applies. But a policy sitting in a document repository proves nothing about what actually happens on a Tuesday afternoon when someone requests admin access. A written incident response plan says nothing about whether the team can actually execute it under real pressure, at 2am, with a ransomware note on every screen. A logging policy is close to worthless if the logs it promises were switched off somewhere along the way, or overwritten, or scattered across systems that were never synchronised to the same clock.

NIST's Cybersecurity Framework 2.0 essentially built this concern into its core structure, placing "Govern" alongside Identify, Protect, Detect, Respond, and Recover as one of five equal functions rather than background paperwork sitting off to the side. India's own regulatory posture pushes in the same direction. CERT-In's 2022 Directions require certain incidents to be reported within six hours of discovery, and its guidance for government entities leans heavily on documented incident handling and disciplined evidence practices. The underlying message from both is identical: figure out, before anything goes wrong, whether the evidence you'll eventually need is actually going to exist when someone asks for it.

Where GRC and Forensics Actually Connect

A good GRC programme spells out what's supposed to happen. Forensic readiness is what lets you later prove what actually did.

Access control is a useful example here. On the GRC side, an organisation might require least privilege access, multi factor authentication, periodic reviews of who holds privileged accounts, and prompt removal of access once someone leaves or changes roles. On the forensic side, none of that means anything without the underlying records that let investigators actually test it, authentication logs, MFA usage history, privilege change records, and account activity trails. The table below lines up a few common GRC controls against the specific evidence needed to show they were genuinely operating.

‍

A Practical Scenario: After a Ransomware Incident

Picture a mid-sized company waking up to find half its file servers encrypted. There's an incident response plan somewhere in the shared drive, technically, but nobody's actually run through it in over a year. The security team isolates the obviously compromised endpoint and starts escalating. Now the forensic side of the house has to reconstruct what happened, working backward through endpoint telemetry, authentication logs, firewall events, email traffic, and file activity, hunting for the original point of entry, how the attacker escalated privileges, how they moved sideways through the network, what data they actually touched, and finally how the ransomware got deployed.

This is where the quality of everything collected beforehand suddenly matters a great deal. If server clocks were never properly synchronised, the timeline investigators build might not line up cleanly enough to trust. If logs only ever lived locally on individual machines rather than being pulled centrally, some of them are probably gone by now. If nobody ever bothered logging administrator actions, there are going to be real, unexplained gaps in the story. And if whatever evidence does exist wasn't collected the right way, its integrity can be challenged later, sometimes fatally, in a legal or regulatory proceeding. CERT-In actually ran a programme on exactly this in July 2026, "Inside the Breach," covering system artefacts, investigative technique, and chain of custody requirements, precisely because this is where real investigations tend to succeed or quietly fall apart.

Building a Forensic Ready GRC Programme

For an organisation starting more or less from scratch, forensic readiness doesn't need to be bolted on as some separate initiative. It can be built straight into the GRC programme that already exists. Start by identifying the systems, applications, cloud services, and privileged accounts that actually matter. Map the real risks and regulatory requirements onto the controls meant to address them. Then get specific about what evidence each control should be generating, and how that evidence gets protected and kept over time. Time synchronisation, centralised logging, tightly controlled access to security records, and clear ownership of preservation, escalation, and investigation all need to exist well before an incident, not be improvised during one. And none of it means much until it's actually been tested, through tabletop exercises and simulated incidents rather than assumed to work because it's written down somewhere. NIST SP 800-61 Revision 3 frames incident response as one continuous loop of preparation, detection, response, recovery, and improvement, rather than a series of separate boxes to check.

There's one question worth asking of every important control an organisation runs: could you actually prove this was working at the moment an incident happened? If the honest answer is no, what you have is a compliance process on paper, and a forensic readiness gap sitting quietly underneath it.

Conclusion

Cyber readiness was never really about how many policies sit in a binder or how many boxes get ticked in an audit. It shows up, or doesn't, in the hours right after something breaks, when an organisation has to move fast, preserve evidence that can actually stand up to scrutiny, explain clearly what happened, and prove that governance and technical controls were genuinely working together rather than just coexisting on paper. GRC sets the direction, the accountability, the risk priorities, and the compliance expectations. Digital forensics does the work of preserving and interpreting the technical evidence once something actually happens. Forensic readiness sits in between the two, making sure they're actually talking to each other long before an incident forces the conversation. The practical task for most organisations comes down to something simple to say, if not always simple to build: design controls that hold up under real incident response, not just an auditor's checklist. The strongest compliance posture was never the one with the thickest binder. It's the one that can back every document up with evidence, on the day it actually matters.

References

1. Digital Personal Data Protection Act, 2023, Sections 8(4), 8(5), 8(6). https://www.meity.gov.in/writereaddata/files/Digital%20Personal%20Data%20Protection%20Act%202023.pdf
2. Digital Personal Data Protection Rules, 2025, Rules 6 and 7, notified 13 November 2025. https://www.meity.gov.in
3. National Institute of Standards and Technology, The NIST Cybersecurity Framework (CSF) 2.0, CSWP 29, 2024. https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final
4. Indian Computer Emergency Response Team (CERT-In), Directions under Section 70B of the Information Technology Act, 2000, dated 28 April 2022. https://www.cert-in.org.in/Directions70B.jsp
5. Indian Computer Emergency Response Team (CERT-In), Guidelines on Information Security Practices for Government Entities. https://www.cert-in.org.in/Downloader?fileName=CIPS-2026-0014.pdf&pageid=5&type=2
6. National Institute of Standards and Technology, SP 800-86: Guide to Integrating Forensic Techniques into Incident Response, 2006. https://csrc.nist.gov/pubs/sp/800/86/final
7. International Organization for Standardization, ISO/IEC 27037:2012, Guidelines for identification, collection, acquisition and preservation of digital evidence. CERT-In, "Inside the Breach: Advanced Cyber Forensics & Incident Investigation," 31 July 2026. https://www.cert-in.org.in/s2cMainServlet?pageid=PRSTNVIEW03&reCode=CIWS-2026-3569
8. National Institute of Standards and Technology, SP 800-61 Rev. 3: Incident Response Recommendations and Considerations for Cybersecurity Risk Management, 2025. https://csrc.nist.gov/pubs/sp/800/61/r3/final
9. Matters.ai, "DPDP Breach Notification: 72-Hour Rule & ₹200 Cr Penalty." https://www.matters.ai/article/dpdp-breach-notification MediaNama, "Data Breach Reporting Timeline of DPDP Rules 2025 Explained." https://www.medianama.com/2025/11/223-data-breach-reporting-timeline-of-dpdp-rules-2025-explained/

‍

Introduction

With the increasing reliance on digital technologies in the banking industry, cyber threats have become a significant concern. Cyberlaw plays a crucial role in safeguarding the banking sector from cybercrimes and ensuring the security and integrity of financial systems.

The banking industry has witnessed a rapid digital transformation, enabling convenient services and greater access to financial resources. However, this digitalisation also exposes the industry to cyber threats, necessitating the formulation and implementation of effective cyber law frameworks.

Recent Trends in the Banking Industry

Digital Transformation: The banking industry has embraced digital technologies, such as mobile banking, internet banking, and financial apps, to enhance customer experience and operational efficiency.

Open Banking: The concept of open banking has gained prominence, enabling data sharing between banks and third-party service providers, which introduces new cyber risks.

How Cyber Law Helps the Banking Sector

The banking sector and cyber crime share an unspoken synergy due to the mass digitisation of banking services. Thanks to QR codes, UPI and online banking payments, India is now home to 40% of global online banking transactions. Some critical aspects of the cyber law and banking sector are as follows:

Data Protection: Cyberlaw mandates banks to implement robust data protection measures, including encryption, access controls, and regular security audits, to safeguard customer data.

Incident Response and Reporting: Cyberlaw requires banks to establish incident response plans, promptly report cyber incidents to regulatory authorities, and cooperate in investigations.

Customer Protection: Cyberlaw enforces regulations related to online banking fraud, identity theft, and unauthorised transactions, ensuring that customers are protected from cybercrimes.

Legal Framework: Cyberlaw provides a legal foundation for digitalisation in the banking sector, assuring customers that regulations protect their digital transactions and data.

Cybersecurity Training and Awareness: Cyberlaw encourages banks to conduct regular training programs and create awareness among employees and customers about cyber threats, safe digital practices, and reporting procedures.

RBI Guidelines

The RBI, as India’s central banking institution, has issued comprehensive guidelines to enhance cyber resilience in the banking industry. These guidelines address various aspects, including:

Technology Risk Management

Cyber Security Framework

IT Governance

Cyber Crisis Management Plan

Incident Reporting and Response

Recent Trends in Banking Sector Frauds and the Role of Cyber Law

Phishing Attacks: Cyberlaw helps banks combat phishing attacks by imposing penalties on perpetrators and mandating preventive measures like two-factor authentication.

Insider Threats: Cyberlaw regulations emphasise the need for stringent access controls, employee background checks, and legal consequences for insiders involved in fraudulent activities.

Ransomware Attacks: Cyberlaw frameworks assist banks in dealing with ransomware attacks by enabling legal actions against hackers and promoting preventive measures, such as regular software updates and data backups.

Master Directions on Cyber Resilience and Digital Payment Security Controls for Payment System Operators (PSOs)

Draft of Master Directions on Cyber Resilience and Digital Payment Security Controls for Payment System Operators (PSOs) issued by the Reserve Bank of India (RBI). The directions provide guidelines and requirements for PSOs to improve the safety and security of their payment systems, with a focus on cyber resilience. These guidelines for PSOs include mobile payment service providers like Paytm or digital wallet payment platforms.

Here are the highlights-

The Directions aim to improve the safety and security of payment systems operated by PSOs by providing a framework for overall information security preparedness, with an emphasis on cyber resilience.

The Directions apply to all authorised non-bank PSOs.

PSOs must ensure adherence to these Directions by unregulated entities in their digital payments ecosystem, such as payment gateways, third-party service providers, vendors, and merchants.

The PSO’s Board of Directors is responsible for ensuring adequate oversight over information security risks, including cyber risk and cyber resilience. A sub-committee of the Board may be delegated with primary oversight responsibilities.

PSOs must formulate a Board-approved Information Security (IS) policy that covers roles and responsibilities, measures to identify and manage cyber security risks, training and awareness programs, and more.

PSOs should have a distinct Board-approved Cyber Crisis Management Plan (CCMP) to detect, contain, respond, and recover from cyber threats and attacks.

A senior-level executive, such as a Chief Information Security Officer (CISO), should be responsible for implementing the IS policy and the cyber resilience framework and assessing the overall information security posture of the PSO.

PSOs need to define Key Risk Indicators (KRIs) and Key Performance Indicators (KPIs) to identify potential risk events and assess the effectiveness of security controls. The sub-committee of the Board is responsible for monitoring these indicators.

PSOs should conduct a cyber risk assessment when launching new products, services, technologies, or significant changes to existing infrastructure or processes.

PSOs, including inventory management, identity and access management, network security, application security life cycle, security testing, vendor risk management, data security, patch and change management life cycle, incident response, business continuity planning, API security, employee awareness and training, and other security measures should implement various baseline information security measures and controls.

PSOs should ensure that payment transactions involving debit to accounts conducted electronically are permitted only through multi-factor authentication, except where explicitly permitted/relaxed.

Conclusion

The relationship between cyber law and the banking industry is crucial in ensuring a secure and trusted digital environment. Recent trends indicate that cyber threats are evolving and becoming more sophisticated. Compliance with cyber law provisions and adherence to guidelines such as those provided by the RBI is essential for banks to protect themselves and their customers from cybercrimes. By embracing robust cyber law frameworks, the banking industry can foster a resilient ecosystem that enables innovation while safeguarding the interests of all stakeholders or users.