Notifications
Clear all
Topic starter
21/08/2026 4:59 pm
TL;DR: CERT-In compliance for cloud-hosted applications depends on operational readiness, not policy statements: incidents must be reported within six hours, logs retained for 180 days, and cloud, identity, Kubernetes, and runtime evidence preserved across shared-responsibility environments, according to AccuKnox. The real risk is not missing a checklist item but discovering, too late, that detection, ownership, and evidence collection were never wired into the response path.
NHIMG editorial — based on content published by AccuKnox: CERT-In Compliance for Cloud Apps: India Guide 2026
By the numbers:
- 180 days with synchronized system time., with synchronized system time.
Questions worth separating out
Q: What breaks when cloud compliance is treated as a storage problem?
A: Teams usually keep logs but fail to preserve them in a way that supports investigation, correlation, and reporting.
Q: Why do shared responsibility models create compliance risk in cloud environments?
A: Shared responsibility splits control across the provider and the customer, which can leave gaps in application security, identity governance, and incident reporting.
Q: How do you know if incident logging is actually ready for regulatory reporting?
A: You know it is ready when a team can reconstruct an event from control plane, identity, application, and runtime logs without manual hunting.
Practitioner guidance
- Pre-build the six-hour reporting runbook Define the escalation chain, SPOC, evidence owner, and regulator submission template before an incident occurs.
- Centralise cloud, identity, and runtime logs Collect control plane, IAM, Kubernetes, application, and runtime telemetry into a searchable store with 180-day retention and synchronized timestamps.
- Assign evidence ownership across shared responsibility boundaries Document which team owns each log source, which service model it belongs to, and how evidence is preserved in AWS, Azure, and GCP.
What's in the full article
AccuKnox's full guide covers the operational detail this post intentionally leaves for the source:
- A cloud compliance mapping table that ties CERT-In obligations to specific cloud-native controls and evidence sources.
- A six-hour incident reporting workflow showing how detection, evidence capture, and regulator submission fit together.
- A checklist for AWS, Azure, and GCP logging, retention, and escalation coverage across hybrid environments.
- Practical examples of runtime telemetry and Kubernetes logging that support forensic reconstruction.
👉 Read AccuKnox's guide to CERT-In compliance for cloud-hosted applications →
CERT-In cloud compliance: are your six-hour controls actually ready?
Explore further
21/08/2026 5:15 pm
Six-hour reporting turns evidence governance into a security control. CERT-In compliance is less about paperwork than about whether the organisation can preserve a usable incident trail on demand. In cloud environments, that trail spans identities, runtime, application telemetry, and control plane events. The practitioner conclusion is simple: if evidence is not continuously retained and correlated, it is not available when the clock starts.
A question worth separating out:
Q: Who is accountable when cloud monitoring gaps delay breach reporting?
A: Accountability usually sits with the teams that own logging, incident response, and regulatory reporting, but the root issue is often shared control failure across security, cloud, and compliance functions. Where personal data or regulated systems are involved, GDPR Article 32 and similar regimes make demonstrable control evidence a governance requirement.
👉 Read our full editorial: CERT-In cloud compliance hinges on six-hour reporting readiness
