What CERT-In Actually Requires
CERT-In's April 2022 cybersecurity directions apply to all entities in India's IT ecosystem, including data centres, cloud service providers, VPN service providers, and any organisation classified as critical information infrastructure. The core log retention requirement is 180 days, covering system logs, network device logs, firewall and intrusion detection logs, application access logs, authentication and authorisation events, API gateway logs, and database access logs. The 180-day clock runs from the time the event is recorded, not from the time a potential incident is detected.
Separately, reportable cybersecurity incidents must be reported to CERT-In within 6 hours of detection. This is the requirement that most compliance teams underestimate until they are actually facing an incident. Meeting the 6-hour reporting window requires that the relevant logs be accessible quickly enough to support a coherent incident report within the timeframe. Logs must be indexable or at minimum easily searchable, not just archived in cold storage.
For practical compliance, the architecture must collect all required log categories, retain them for at minimum 180 days in India-resident storage, prevent modification or deletion, and support retrieval within the timeframe required for incident reporting.
CERT-In and DPDP Act impose different but complementary obligations.
Why Object Storage for Compliance Logs
Log data has characteristics that make object storage the correct long-term home for compliance archival.
Logs are written continuously in high volume but read only during incident investigations, audits, or regulatory requests, which is a fraction of the time they exist. Object storage's pricing model, which charges per GB stored and per request, is ideal for write-heavy, read-rare workloads. You pay very little while the logs sit untouched, and a reasonable retrieval cost when you actually need them.
Log records should not be modified after they are written. Object storage's default behaviour, where object keys are immutable once written, aligns with this requirement. Object lock adds a compliance-grade guarantee on top: objects cannot be deleted or overwritten by any user, including account administrators, within the lock period.
Retaining 180 days of logs for a medium-size platform generates significant data volumes. At Rs.1.50/GB-month ($0.016/GB-month) on IBEE, the cost per GB across a 180-day retention period is Rs.9 ($0.096). All USD equivalents in this article use a conversion rate of Rs.94.91 per dollar as of May 2026. The cost of a CERT-In non-compliance finding is categorically higher.
IBEE is an Indian company operating Indian infrastructure under Indian law, with no US CLOUD Act exposure. Logs stored on IBEE satisfy the India-resident storage requirement directly.
Log Collection Pipeline
Logs from multiple sources, including application servers, databases, network devices, and authentication services, must be centralised before they can be archived to object storage. The diagram below shows the full pipeline from log source to compliant IBEE storage.
Server agents stream logs to a central aggregator, which compresses and archives them to IBEE continuously.
Tamper-Evident Storage With Object Lock
Object lock in COMPLIANCE mode prevents deletion or overwrite by any user, including account administrators, for the lock duration. This is the technical control that satisfies the tamper-evidence requirement for compliance log archival. It is also the piece we see most often missing when a compliance team first reviews their log archival setup.
Configure the compliance log bucket with a default object lock retention of 180 days in COMPLIANCE mode. With this configuration, every log file written to the bucket is automatically locked for 180 days from the time of creation. The log pipeline writes files in the normal way with no special handling required. The bucket configuration ensures the lock is applied to every object on creation. Full bucket configuration details are at ibee.ai/docs.
A CERT-In auditor requesting evidence of log retention controls can be shown the bucket object lock configuration, a sample of locked objects with their retention expiry dates, and the log pipeline configuration showing that all required log categories are being shipped to this bucket.
Lifecycle Policy for Post-Retention Expiry
Object lock prevents deletion during the lock period. After the lock expires at 180 days for CERT-In, a lifecycle policy should delete the objects, otherwise the archive grows indefinitely and accumulates cost for logs that are no longer required.
Set the lifecycle expiry at 185 days, five days after the object lock expires, to ensure the lock has fully expired before the lifecycle rule attempts deletion. If the two overlap, the lifecycle rule will not be able to delete the still-locked object and the expiry will fail silently. Lifecycle configuration examples for this pattern are at ibee.ai/docs.
Incident Response: Accessing Archived Logs
When an incident is detected and a CERT-In report must be filed within 6 hours, the log retrieval process must be fast enough to support the investigation. For incidents where the time range is known, the AWS CLI pointed at IBEE's S3-compatible endpoint can retrieve all relevant logs for a specific prefix and date range in a single command. For incidents where the time range is unknown, log search tools that can query IBEE-hosted logs without downloading the full archive, such as OpenSearch with S3 snapshot integration or DuckDB with S3 access for SQL queries against compressed log files, enable fast investigation directly against the archive. CLI retrieval examples and search tool configuration are at ibee.ai/docs.
DPDP Act Data Processing Records
India's Digital Personal Data Protection Act 2023 requires data fiduciaries to maintain records of data processing activities involving personal data. These records are distinct from operational logs but require similar retention and India-sovereign storage. They document what personal data was processed, when, by which system, and for what purpose, and they are the technical evidence of lawful processing if a data principal exercises their rights under the Act or if a regulatory authority investigates.
Store DPDP processing records as structured JSON objects in a dedicated IBEE bucket, with object lock applied at an appropriate retention period, at minimum the duration of the data processing relationship plus a defined post-processing window. Each record should include the data principal's identifier in pseudonymised form, the category of personal data processed, the processing purpose, the system or service that processed it, and the timestamp.
Separating DPDP processing records from operational compliance logs into their own bucket keeps the two categories distinct for audit purposes and allows different retention periods to be applied independently. Both buckets remain on India-sovereign IBEE infrastructure under the same compliance posture.
