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.
Editorial analysis by NHI Mgmt Group, based on content published by AccuKnox: “CERT-In Compliance for Cloud Apps: India Guide 2026”.
By the numbers:
- CERT-In compliance requires security logs to be retained for at least 180 days.
Key questions
Q: What breaks when cloud teams have no six-hour CERT-In reporting runbook?
A: The incident response process becomes the control failure.
Q: Why do cloud incidents become harder to report under CERT-In in shared responsibility models?
A: Because the evidence is split across provider logs, customer identities, applications, Kubernetes, and runtime telemetry.
Q: What are the signs that CERT-In logging controls are failing in cloud environments?
A: Common signs include missing identity logs, inconsistent timestamps, slow evidence assembly, and reliance on manual screenshots or ticket trails.
Practitioner guidance
- Build a six-hour reporting runbook Define who detects, who validates, who approves, and who submits a CERT-In report before an incident occurs.
- Retain cloud logs for 180 days Enforce searchable 180-day retention across cloud control plane, identity, Kubernetes, application, and runtime logs with synchronized system time.
- Centralize identity and workload telemetry Correlate IAM activity, Kubernetes audit logs, container runtime events, and API logs so incident reconstruction can connect access to impact.
Bottom line: CERT-In cloud compliance fails when organisations treat reporting as a documentation task rather than a timed operational process.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
21/08/2026 5:15 pm
Six-hour reporting readiness is the real compliance control: CERT-In turns incident response into a measurable operational capability, not a policy exercise. The determining factor is whether telemetry, ownership, and escalation already exist when the incident begins. Practitioners should judge compliance by response readiness, not by the existence of a document.
A few things that frame the scale:
- Red Hat’s Kubernetes Security Report found that nearly 9 in 10 organizations had at least 1 container or Kubernetes security incident in the last 12 months.
A question worth separating out:
Q: How should security teams prepare for CERT-In audits and incident reporting at the same time?
A: They should align audit evidence collection with incident response evidence collection so the same telemetry supports both. That means defined log sources, tested retention, assigned escalation owners, and a submission workflow that can run before forensic analysis is complete.
👉 Read our full editorial: CERT-In cloud compliance hinges on six-hour reporting readiness