That does not make the preparation work optional. It changes the timeline. Security teams have roughly eight months to turn vague assurances about “logging,” “monitoring,” and “incident response” into tested processes that can reconstruct an intrusion and support a regulatory notification. For organisations covered by India’s existing CERT-In directions, parts of that evidence discipline are already mandatory.
CyberPeace’s central argument—that governance, risk, and compliance work must produce usable forensic evidence—is sound. The important correction is that DPDP’s one-year log-retention and 72-hour Data Protection Board reporting requirements are a coming obligation, not one that began with the Rules’ notification in November 2025.
The DPDP Rules set a delayed but concrete deadline
The Ministry of Electronics and Information Technology’s Gazette notification splits the DPDP Rules’ commencement into phases. Rules 1, 2, and 17 through 21 began immediately on November 13, 2025. Rule 4 was scheduled for one year later. Rules 3, 5 through 16, and 22 and 23—including the security-safeguard requirements in Rule 6 and personal-data-breach notifications in Rule 7—were deferred for 18 months.
That staging matters for any company building a compliance calendar. Treating the 2025 publication date as an enforcement date could produce an inaccurate board report, while treating the delayed date as a reason to wait until 2027 would create a different failure: a rushed programme with no evidence that its controls actually work.
Rule 6 is more demanding than a policy requirement. It says a Data Fiduciary must implement reasonable security safeguards that include security measures such as encryption, obfuscation, masking, or virtual tokens; controls over access to relevant computer resources; logs, monitoring, and reviews sufficient to detect and investigate unauthorised access; continuity measures such as backups; processor contract terms; and technical and organisational measures supporting the safeguards.
The rule also requires retention of relevant logs and personal data for one year where needed for detection, investigation, remediation, recurrence prevention, and continued processing. That is a compliance requirement with a direct engineering consequence: an organisation cannot credibly promise one-year forensic visibility if its Windows event logs, cloud audit records, endpoint telemetry, and identity-provider data expire after 30 or 90 days.
CERT-In already creates the shorter incident clock
The DPDP timetable should not obscure obligations already active under CERT-In’s April 2022 directions. Service providers, intermediaries, data centres, body corporates, and government organisations must report specified cyber incidents to CERT-In within six hours of noticing them or being informed of them. The covered incidents include data breaches and leaks, ransomware, unauthorised access, and other incidents listed in the directions’ annexure.
CERT-In’s directions also require covered organisations to enable logs for ICT systems and retain them securely for a rolling 180 days within Indian jurisdiction. They require synchronisation of ICT system clocks with the National Informatics Centre, National Physical Laboratory, or time servers traceable to those sources.
The CyberPeace article is therefore right to describe overlapping operational demands, but the sequence is critical. A serious incident today can already put an organisation on a six-hour CERT-In reporting clock. From May 13, 2027, a personal-data breach can also trigger the DPDP Rule 7 process: notification to affected individuals without delay, an initial notification to the Data Protection Board without delay, and detailed information for the Board within 72 hours unless the Board allows more time.
Those clocks are not interchangeable. CERT-In reporting concerns the specific incidents and entities described in its directions. DPDP Rule 7 concerns a personal data breach involving a Data Fiduciary. A ransomware incident may satisfy both regimes, but the recipients, time limits, information required, and internal owners will differ.
A practical incident plan should therefore identify, in advance, who is authorised to decide that an incident is reportable; who contacts CERT-In; who assesses whether personal data is involved; who communicates with affected individuals; and who can preserve technical evidence without contaminating it.
GRC must specify the evidence, not only the control
GRC programmes often describe a control at the wrong level of detail. “MFA is enabled,” “privileged access is reviewed,” and “security logging is monitored” are statements about intended posture. They do not answer the questions an investigator, regulator, customer, or insurer will ask after an incident.
Forensic readiness means pairing every important control with the records needed to test whether it was operating at the relevant time. A privileged-access review should lead to review records, approval trails, group-membership changes, and account-removal evidence. An MFA requirement should be supported by identity-provider sign-in records, policy configuration history, exception approvals, and logs showing whether the attacker authenticated through a bypassed or unenrolled pathway.
For Windows-heavy environments, the evidence inventory normally has to extend beyond a central SIEM’s headline alerts. Domain controllers, Entra ID or other identity systems, VPNs, EDR platforms, mail systems, file servers, firewall appliances, cloud control planes, and backup platforms all tell different parts of an intrusion story.
Windows administrators should be especially careful about the gaps between endpoint and identity telemetry. A ransomware investigation may require proof of when an account first authenticated, when it received elevated privileges, which hosts it reached, whether PowerShell was used, when security tooling was altered, and whether backup repositories were accessed. If those sources have different timestamps, inconsistent retention periods, or no central collection, the incident timeline becomes guesswork.
The relevant question is not whether a system produces logs by default. It is whether those logs are complete enough, retained long enough, protected from alteration, and accessible quickly enough to support six-hour and 72-hour reporting decisions.
The one-year rule exposes retention design problems
Rule 6’s one-year retention requirement deserves more attention than it usually receives in privacy compliance discussions. It is not simply a storage-budget issue. Retention changes the architecture of logging, the cost of collecting high-volume telemetry, the access controls around sensitive records, and the preservation process used once an incident occurs.
Security teams should not solve that problem by retaining everything indefinitely. Broad collection without data classification can create privacy, cost, and searchability problems of its own. The defensible approach is to define the evidence needed for specific scenarios: account takeover, ransomware deployment, unauthorised database extraction, insider misuse, mailbox compromise, and cloud administrative abuse.
For each scenario, document the systems of record, event types, normal retention period, archive location, access owner, encryption status, and the process for placing information on preservation hold. The distinction between routine retention and legal or investigative preservation is important. A one-year rolling retention setting does little good if an archive job can overwrite the very period an investigation still needs.
CERT-In’s 180-day requirement is also not a substitute for DPDP’s future one-year requirement. The two periods serve different legal mandates and may apply differently depending on the entity and incident. Companies subject to both should design for the longer relevant period while confirming where the data is stored and which records are accessible to responders.
A ransomware response will test the paper programme
Consider the familiar sequence: an attacker compromises a user account, moves through the network using valid credentials, changes a privileged group membership, disables or evades endpoint protections, accesses file servers, and deploys ransomware. By the time users see encrypted files, the initial access may be days or weeks old.
An organisation that has only an incident-response policy will struggle to establish the facts. It will need reliable evidence from authentication services, administrator activity, endpoint detection tools, server logs, email systems, network controls, backup systems, and cloud administration records. It will need timestamps that line up. It will need copies protected from the attacker and from accidental alteration by responders.
This is where GRC earns its place. Governance assigns owners for logging, preservation, reporting, and customer communications. Risk management identifies the systems and data categories where a failure would be material. Compliance maps each requirement to a control and its evidence. Forensics turns those records into a timeline that can survive scrutiny.
NIST’s Cybersecurity Framework 2.0 and its 2025 revision of SP 800-61 both reinforce that approach. Incident response is not a document activated after an alert; it is an outcome supported by continuing governance, asset knowledge, protective controls, detection capability, recovery planning, and improvement after failures.
What organisations should complete before May 2027
The most useful preparation is not a new policy binder. It is a short, tested evidence plan attached to the controls already in place.
- Identify every system that processes personal data and every system that can materially affect its confidentiality, integrity, or availability.
- Define which identity, endpoint, network, application, database, backup, and cloud records are needed to investigate a breach involving those systems.
- Reconcile retention periods with the coming DPDP one-year requirement, existing CERT-In obligations, contractual commitments, and any sector-specific rules.
- Centralise time synchronisation and regularly test for timestamp drift across Windows servers, security appliances, cloud services, and logging platforms.
- Restrict access to collected security records, record administrative changes to logging systems, and preserve copies in storage resistant to routine modification or attacker tampering.
- Run tabletop exercises that begin with incomplete facts and require the team to decide whether CERT-In reporting, DPDP notification, customer communication, or all three are required.
The deadline is now visible: May 13, 2027. Organisations that use the remaining time to prove that their controls generate intact, retrievable evidence will be in a far stronger position than those that discover their logging gaps during the first reportable breach.