Log retention and privacy incident evidence in India
A practical checklist for aligning privacy incident evidence, DPDP breach readiness and CERT-In log retention duties in India.
Data>Nuance
Logs are the witnesses that remember what everyone else swears was obvious.
For Indian product, security and privacy teams, log retention is no longer only a security engineering preference. It is the evidence layer behind DPDP breach assessment, processor oversight, CERT-In reporting and board-level incident governance. A privacy incident review can fail even where the team acted quickly if the organisation cannot prove what data was accessed, when access began, which systems were affected, whether a processor was involved and what remedial steps followed.
The operating question is not simply how long to store logs. It is which logs are needed to reconstruct a personal data event without retaining more personal data than the business can justify.
What to review
Start with a log map tied to personal data processing. Include identity and access logs, application audit trails, database access records, API gateway events, cloud control-plane logs, data export events, privileged admin activity, security tooling alerts, ticketing records and processor notifications. Mark which systems hold personal data, which only hold metadata, and which can reveal sensitive behaviour when combined.
Then map each source to the legal reason for retention. CERT-In directions require covered entities to enable ICT system logs, retain them securely for a rolling 180-day period within Indian jurisdiction and provide them with incident reporting or when directed. The DPDP Rules, 2025 also point privacy teams towards visibility through logs, monitoring and review for detecting unauthorised access, investigation and remediation, with retention of relevant logs and personal data for one year unless another law requires otherwise.
That creates a practical baseline: do not delete incident-critical logs at thirty or ninety days merely because storage is expensive, and do not keep raw personal data forever because nobody owns the deletion decision.
Implementation steps
Create an evidence matrix with four columns: system, personal data relevance, retention rule and owner. Security can own ingestion and integrity, but privacy should own the personal data rationale and legal hold triggers. Procurement should add processor commitments for log availability, breach cooperation, secure retention and export formats.
Set a normal retention tier and an incident hold tier. The normal tier should preserve enough detail for breach triage, access review and CERT-In support. The incident hold tier should freeze relevant records once a suspected breach is detected, including logs held by cloud, SaaS, analytics, customer support and managed security providers.
Make timestamps investigation-ready. CERT-In directions require clock synchronisation with NIC or NPL-linked time sources, or a standard source that does not deviate from them for entities with global infrastructure. In practice, mismatched time zones and unsynchronised SaaS exports can add days to breach scoping.
Minimise where possible. Hash or tokenise identifiers in analytics logs where full values are not needed. Restrict log search privileges. Separate production support access from bulk export rights. Record who accessed incident evidence during review, because the investigation file can itself contain personal data.
Run one tabletop test each quarter. Pick a realistic event such as an exposed storage bucket, compromised admin account or unauthorised database query. Ask whether the team can answer: what happened, when it started, whose data may be involved, which processors touched the records, what was contained and what notices may be required.
Common mistakes
- Keeping infrastructure logs but missing application-level events that show which personal data fields were viewed, exported or changed.
- Treating processor logs as optional evidence, then discovering during an incident that the SaaS provider only offers short retention or slow manual exports.
- Retaining full identifiers in every log stream without masking, access controls or deletion rules after the legal purpose expires.
How DataNuance can help
DataNuance helps Indian organisations turn privacy incident readiness into evidence records that security, legal and leadership teams can actually use. We can review log-retention policies, processor clauses, breach playbooks, evidence matrices and tabletop outputs, then align them with DPDP and CERT-In expectations without over-collecting personal data. For a focused review of your current evidence posture, speak to DataNuance.
FAQs
Does every business in India need 180 days of logs?
CERT-In directions apply to broad categories including service providers, intermediaries, data centres, body corporates and government organisations. Many companies should treat 180 days as the security incident baseline, then layer DPDP-specific retention and minimisation decisions on top.
Can privacy teams rely only on SIEM logs?
No. SIEM coverage is useful, but privacy incident evidence often needs application audit logs, database records, data export history, customer support access, consent records, vendor notices and deletion records. The evidence set should follow the personal data flow, not only the network perimeter.
How should processor logs be handled?
Processor contracts should require timely breach cooperation, log preservation, export support, security controls and deletion after the agreed retention period. The Data Fiduciary remains responsible for processing undertaken on its behalf, so processor evidence cannot be an afterthought.
What should be preserved when a breach is suspected?
Preserve relevant access logs, system events, alerts, tickets, administrator actions, processor communications, affected data inventories, containment decisions and notification analysis. Keep the scope tight, document the reason for the hold and review deletion once the incident file is closed.
Sources
This publication is general information and is not legal advice for a specific organisation or matter.