With the DPDP Rules now in effect, every organisation that processes personal data of Indian citizens carries active compliance obligations right now. Also, the penalty for failing to implement reasonable security safeguards – the category that directly covers logging – is up to ₹250 crore per violation.
Under DPDP, it is a legal obligation with a defined scope, a minimum retention floor and an audit evidence trail the Data Protection Board of India (DPB) can demand at any time.
This blog breaks down exactly what DPDP mandates for a logging solution, which log types you must capture, how to resolve the Act’s built-in retention paradox and what the DPB will check when it reviews your setup.
What DPDP Act says about logging
The logging mandate sits across two critical provisions of the DPDP Rules, 2025 — Rule 6 and Rule 8. They together define what you must capture, how long you must keep it and under what conditions it must be stored.
Rule 6 and the security safeguard mandate
Rule 6 defines the “reasonable security safeguards” every Data Fiduciary must implement. Logging is explicitly listed as one of these safeguards alongside encryption, access controls and continuity measures. The rule requires continuous monitoring, review and maintenance of access logs to detect and investigate unauthorised access. Crucially, this obligation extends to all stages of data processing, not just critical IT systems.
Rule 8(3) and the one-year retention floor
Rule 8(3) sets the retention baseline. Every Data Fiduciary must retain personal data, associated traffic data and other logs of processing for a minimum of one year from the date of processing. This obligation survives consent withdrawal, account deletion and purpose fulfilment. If any other applicable law such as SEBI’s Cybersecurity and Cyber Resilience Framework (CSCRF) or the IT Act, 2000 requires a longer period, the longer period governs.
The eight types of logs your DPDP stack should capture
Rule 6(1)(c) requires Data Fiduciaries to maintain “appropriate logs, monitoring and review” for detecting and investigating unauthorised access. The Rule does not enumerate specific log types. However, it sets the objective. In practice, satisfying that standard means your stack should capture these eight categories:
- Access logs: who accessed what personal data, when and from which system
- Authentication logs: login events, multi-factor authentication outcomes, session initiations and failures
- Modification logs: changes to personal data records, processing parameters or data classifications
- Processor activity logs: every action performed by Data Processors acting on your behalf
- Consent update logs: grant, revision and withdrawal events for each Data Principal with timestamps
- Breach detection logs: alerts, anomaly triggers and detection events from monitoring infrastructure
- Deletion event logs: records of data erasure, including timestamp, scope and confirmation
- System anomaly logs: unusual patterns in access volume, authentication attempts or data movement
Together, these categories give you visibility across the full data access and processing lifecycle the standard Rule 6(1)(c) is designed to achieve. Each category also serves a second purpose: providing the evidence trail needed to file a defensible breach report to the DPB.
Logging for the 72-hour breach notification window
Rule 7 has two separate notification obligations. On becoming aware of a breach, the Data Fiduciary must immediately notify the DPB “without delay” with an initial description of the nature, extent, timing and likely impact of the breach.
In addition, a detailed report covering root cause, affected data, remediation steps and findings, then follows within 72 hours.
This two-tier structure makes your logging stack the critical dependency. The initial “without delay” notification requires immediate breach detection. The 72-hour detailed report requires your SIEM to have assembled the full evidence picture well before the deadline, affected data categories, access path, breach timeline and measures taken.
Three things make this achievable.
- First, detection rules tuned to breach indicators: bulk data access, privilege escalation and anomalous export patterns.
- Second, automated log correlation that surfaces the breach timeline without manual forensics.
- Third, a pre-built evidence template that maps log data to the DPB’s required report structure on demand.
Organisations that treat SIEM as a passive log archive will not meet either window. Your logging solution must function as an active detection and evidence engine from the moment a breach is suspected.
What the Data Protection Board will check in your logs
The DPB holds audit and investigation powers under the DPDP Rules. When it reviews your logging setup, it will verify the following:
- Confirmation that all eight log categories are captured and centralised
- One-year retention with tamper-evident, write-protected storage
- Evidence that logs survive data erasure events and deletion logs confirming erasure occurred and when it happened
- Consent trails showing grant, modification and withdrawal with exact timestamps
- Breach detection logs with a traceable detection-to-initial-notification timeline (“without delay”) and a detailed report timeline within 72 hours
- Processor activity logs confirming your Data Processors maintain the same logging standard as your own systems
A missing log category is not a minor gap. Under DPDP, it is direct evidence that reasonable security safeguards were not implemented – placing you squarely in the ₹250 crore penalty bracket.
Conclusion
DPDP’s logging obligations are specific, enforceable and active today. Rule 6 defines what you must capture. Rule 8(3) defines how long you must keep it. Rule 7’s two-tier breach window defines how fast your stack must convert logs into evidence, immediately for the initial notification, within 72 hours for the detailed report. And the erasure-retention tension defines an architectural challenge that policy alone cannot solve.
The compliance window closes on May 13, 2027. Building the right logging foundation now protects your organisation from penalties, supports breach investigations and demonstrates accountability to the DPB when it comes looking for evidence.
At CyberNX, we help Data Fiduciaries design and deploy DPDP-compliant logging solutions, from log architecture and SIEM implementation to DPB evidence readiness and breach playbook engineering. Connect with our DPDP consulting team to build a logging stack that satisfies Rule 6 and Rule 8 before enforcement begins.
Logging solution as per DPDP Act 2023 FAQs
What is the minimum log retention period under DPDP?
Rule 8(3) of the DPDP Rules 2025 sets the floor at one year from the date of processing. This covers personal data, associated traffic data and processing logs. If a sectoral law such as SEBI CSCRF or the IT Act, 2000 requires a longer period, the longer period takes precedence.
Do logs that contain personal data need to be erased under DPDP?
Not within the one-year window. Rule 8(3) explicitly requires retention of logs, including personal data within them, for a minimum of one year. The recommended practice is to pseudonymise personally identifiable fields at the point of log ingestion, satisfying the erasure obligation for raw personal data while keeping the forensic integrity of the log intact.
Is a SIEM mandatory to comply with DPDP logging requirements?
Not by name, but effectively yes. Rule 7’s two-tier breach notification – initial intimation to the DPB “without delay” followed by a detailed report within 72 hours – combined with Rule 6’s continuous monitoring mandate, requires real-time detection, centralised log correlation and audit-ready evidence generation. These capabilities are only consistently achievable through a SIEM at scale.
