Apply for AI Grants India

Audit logs for compliance are structured, tamper-evident records of activity across applications, infrastructure, identities, data stores, and administrative processes. They help an organisation prove that controls operate as intended, investigate incidents, identify unauthorised access, and respond to auditors or regulators with reliable evidence.

For Indian businesses, the need is increasingly practical rather than theoretical. The Digital Personal Data Protection Act, 2023 (DPDP Act), sectoral requirements, contractual security clauses, CERT-In directions, and frameworks such as ISO 27001 and SOC 2 can all make logging, monitoring, retention, and incident response important parts of a compliance programme. The exact obligations depend on your sector, data, role, and applicable notifications, so legal and compliance teams should validate the final policy.

What Are Audit Logs for Compliance?

An audit log is a chronological record of an event that can affect the confidentiality, integrity, availability, or governance of a system or data. A compliance-grade log should answer five questions:

• Who performed the action?
• What action occurred?
• When did it occur, using a trusted time source?
• Where did it originate, such as an IP address, device, workload, or region?
• Why or under what context did it occur, such as a ticket, approval, workflow, or service identity?

Typical events include successful and failed logins, privilege changes, creation or deletion of accounts, access to sensitive records, exports, configuration changes, API calls, security-policy changes, key-management events, database queries, file access, and administrative actions.

Application logs and audit logs are related but not identical. Application logs may describe errors or business events, while audit logs focus on accountability and traceability. A mature compliance programme usually correlates both with identity, endpoint, network, and cloud-provider records.

Why Audit Logs Matter in an Audit or Investigation

Audit logs provide evidence for several control objectives:

1. Accountability: They link actions to named users, approved service accounts, or workload identities.
2. Access governance: They show whether privileged or sensitive-data access was authorised and appropriate.
3. Change management: They connect production changes to approved requests, reviewers, and deployment pipelines.
4. Incident response: They establish timelines, affected systems, indicators of compromise, and containment scope.
5. Fraud detection: They reveal unusual exports, repeated failed access, segregation-of-duties conflicts, or after-hours activity.
6. Control testing: They provide samples proving that monitoring, approvals, reviews, and retention controls are operating.

Logs do not automatically prove that a control is effective. A system might record an event but fail to alert on it, retain it for too short a period, allow administrators to alter it, or collect incomplete identity data. Auditors therefore evaluate the entire process: event generation, collection, protection, analysis, review, escalation, and disposal.

Which Events Should You Log?

A risk-based logging inventory is better than collecting everything without a purpose. Classify systems by business criticality and data sensitivity, then define mandatory events for each tier.

Identity and access events

Capture authentication successes and failures, multi-factor authentication outcomes, password and recovery changes, session creation, account lockouts, role assignments, privilege elevation, API-token creation, and service-account use. Include the identity provider, authentication method, source address, device or workload, and result.

Privileged activity

Record commands or administrative actions where technically and legally appropriate, changes to security controls, access to production systems, break-glass use, and changes to logging itself. Privileged activity deserves stronger controls because an administrator may otherwise be able to erase evidence.

Data access and movement

For sensitive personal, financial, health, confidential, or regulated data, log reads, writes, updates, deletions, bulk queries, exports, downloads, sharing, and changes to retention status. Avoid recording raw personal data or secrets in the log payload; use identifiers, hashes, classifications, or references instead.

Configuration and software changes

Log infrastructure changes, firewall rules, cloud policies, database permissions, deployment events, code releases, schema changes, feature flags, encryption settings, and backup configuration. Correlate these events with change-management records and commit or pipeline IDs.

Security and operational events

Include malware detections, endpoint-policy changes, vulnerability exceptions, network denies, certificate changes, key rotation, backup failures, data-loss-prevention alerts, and service interruptions. These records often support both security operations and business continuity evidence.

Minimum Fields in a Compliance-Ready Log

A useful event schema should be consistent across systems. At minimum, consider including:

• Event ID and event type
• UTC timestamp, plus source timestamp where useful
• Actor identity, identity type, and authentication context
• Target resource, record, tenant, or account
• Action and outcome
• Source IP, device ID, workload ID, or geographic metadata where justified
• Request, session, transaction, ticket, or correlation ID
• Application, host, cloud account, region, and environment
• Data classification or sensitivity label
• Reason code or approval reference for high-risk activity
• Ingestion timestamp and parser or schema version

Use synchronised clocks through an approved time service. Inaccurate timestamps can make a timeline unreliable, especially when events cross cloud regions, SaaS platforms, and on-premises systems. Store logs in a structured format such as JSON where possible, but preserve vendor-native evidence when it may be needed for forensic validation.

Protecting Audit Logs from Tampering

The value of an audit log depends on its integrity. Apply defence-in-depth controls:

• Send logs to a separate central platform rather than retaining them only on the source system.
• Restrict deletion and modification permissions using least privilege and separation of duties.
• Use write-once, read-many or immutable storage for high-value records.
• Apply cryptographic integrity controls, such as hashes, signed batches, or provider-supported immutability.
• Encrypt logs in transit and at rest, with controlled key access.
• Monitor attempts to disable logging, alter retention, change time settings, or access the log platform.
• Maintain redundant storage across suitable availability zones or locations.
• Record administrative access to the logging platform itself.
• Test restoration and evidence export periodically.

A common failure is giving the same administrator control over the production system, log collector, and retention policy. This creates a single point of compromise. Separate roles for system administration, security monitoring, and evidence governance wherever feasible.

Retention: How Long Should You Keep Logs?

There is no universal retention period for every log. Set retention using a documented matrix that considers:

• Applicable law, regulatory directions, and sector rules
• Contractual and customer requirements
• The organisation’s incident-detection and investigation window
• The limitation period or litigation risk for relevant disputes
• Storage cost and operational value
• Data-minimisation and privacy principles
• The sensitivity of the log itself

For Indian organisations, check current CERT-In directions and applicable sector-specific rules before finalising a policy. Certain directions may prescribe cyber-incident reporting or log-related obligations for specific entities or circumstances. Do not assume that a generic “90-day retention” setting satisfies every requirement.

Use tiered retention when appropriate. Keep searchable, high-performance data for active detection; move older records to low-cost immutable archive storage; and securely delete them when the approved period expires. Document legal holds so relevant evidence is not deleted during an investigation or dispute.

Audit Log Reviews and Monitoring Procedures

Collecting logs without review is not an effective compliance control. Define who reviews which events, how often, and what happens when a threshold is exceeded.

A practical review model can include:

• Real-time alerts for impossible travel, privilege escalation, logging disablement, mass export, and suspicious authentication.
• Daily review of high-severity alerts and privileged activity.
• Weekly or monthly sampling of sensitive-data access and administrative changes.
• Quarterly access-review evidence for privileged roles, service accounts, and exceptions.
• Formal incident escalation with ticket numbers, owners, decisions, and closure evidence.

Tune detections to reduce false positives, but do not suppress events merely because they are inconvenient. Record the rule version, analyst, review date, outcome, and supporting evidence. These review records demonstrate that monitoring is not just configured but actually performed.

Audit Logs and Indian Compliance Context

India’s compliance landscape is distributed across general data protection, cybersecurity, sectoral regulation, and customer contracts. Organisations should map logging controls to their actual obligations rather than treating one certification as a complete answer.

Relevant considerations may include:

• DPDP Act: Governance of personal data, security safeguards, breach response, and accountability may require evidence that access and security controls are operating. Avoid placing unnecessary personal data in logs.
• CERT-In directions: Eligible entities should assess current requirements concerning incident reporting, time synchronisation, and maintenance or provision of specified information.
• RBI and financial-sector expectations: Regulated entities may face detailed requirements for cyber resilience, access management, monitoring, outsourcing, and audit trails.
• SEBI, IRDAI, UIDAI, healthcare, and other sector rules: Sector-specific entities should review applicable circulars, standards, and supervisory expectations.
• ISO 27001 and SOC 2: These frameworks commonly require evidence for logging, monitoring, access control, change management, incident management, and retention, but certification does not replace legal analysis.

For a multinational or cloud-native company, also consider GDPR, contractual customer controls, regional transfer requirements, and the location of log storage. Work with counsel to establish whether logs contain personal data and what rights, access controls, and cross-border safeguards apply.

Common Audit-Log Failures

Avoid these recurring mistakes:

• Logging only successful logins while ignoring failed attempts and privilege changes.
• Using shared administrator accounts with no individual accountability.
• Recording passwords, access tokens, full payment data, or unnecessary personal information.
• Retaining logs but allowing source administrators to delete them.
• Failing to synchronise clocks across systems.
• Relying on a SIEM dashboard without preserving underlying evidence.
• Having no documented review frequency or escalation owner.
• Keeping incompatible vendor formats that cannot be correlated.
• Setting retention based only on storage cost.
• Treating an audit-log policy as complete without testing it through an incident exercise.

How to Implement Audit Logs for Compliance

Follow a repeatable implementation plan:

1. Define scope: Inventory applications, cloud services, databases, endpoints, identities, and third parties.
2. Classify risks: Identify sensitive data, critical processes, privileged paths, and high-impact changes.
3. Create an event catalogue: Specify required events, fields, severity, owner, and retention.
4. Standardise time and identity: Use trusted time synchronisation and central identity wherever possible.
5. Centralise collection: Forward records to a controlled log-management or SIEM platform.
6. Protect evidence: Apply encryption, immutability, access separation, backups, and monitoring of logging controls.
7. Build detections: Prioritise high-risk scenarios and connect alerts to response workflows.
8. Document reviews: Capture reviewers, samples, findings, tickets, and corrective actions.
9. Test regularly: Conduct access reviews, restore tests, tabletop exercises, and control assessments.
10. Improve continuously: Update the catalogue after incidents, architecture changes, new regulations, and audit findings.

Measure the programme with indicators such as logging coverage for critical assets, ingestion failures, time-to-detect, time-to-investigate, alert quality, privileged-activity review completion, and evidence-restoration success.

FAQ: Audit Logs for Compliance

Are audit logs legally required for every business?

Not always in the same form. Requirements depend on the organisation’s sector, data, systems, contracts, and applicable Indian and international rules. Even where no specific log format is mandated, logs may be essential to demonstrate reasonable security and investigate incidents.

Should audit logs contain personal data?

Only when necessary for accountability and investigation. Minimise data, mask sensitive values, restrict access, define retention, and document the purpose. Never place passwords, private keys, or bearer tokens in logs.

Is a SIEM required for compliance?

A SIEM is not universally required. Compliance focuses on appropriate evidence and effective controls. A smaller organisation may use a managed logging service if it can collect relevant events, protect them, review alerts, retain records, and produce reliable evidence.

What is the difference between logs and audit trails?

Logs are records generated by systems. An audit trail is the broader, connected evidence showing activity, identity, approvals, changes, reviews, and outcomes over time. A strong audit trail may combine logs with tickets, access approvals, deployment records, and investigation notes.

Apply for AI Grants India

Building an AI product with strong security, governance, and compliance foundations? Apply through AI Grants India to explore support and opportunities for Indian AI founders.