TL;DR: India’s new CERT-In OEM guidelines show that readiness is less about adding controls than proving that assessment, patching, access control, and incident response already work as one auditable lifecycle, according to AccuKnox. The practical shift is from policy statements to time-stamped evidence, because regulatory scrutiny now tests whether controls can be demonstrated, not merely described.
NHIMG editorial — based on content published by AccuKnox: Inside AccuKnox’s CERT-In Readiness Journey
By the numbers:
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
- Only 5.7% of organisations have full visibility into their service accounts.
Questions worth separating out
Q: What breaks when security controls cannot be evidenced during an audit?
A: When controls cannot be evidenced, the organisation loses the ability to prove continuity, ownership, and closure.
Q: Why do credential, access, and incident records matter so much in regulated environments?
A: They show whether access was appropriate, whether secrets were rotated, and whether the team responded in a repeatable way.
Q: What do teams get wrong about proving security readiness?
A: Teams often assume that having tools, policies, or scan results is enough.
Practitioner guidance
- Create a release-level evidence pack Link every release to assessment results, remediation actions, approval records, and post-fix validation so the control history is auditable without reconstruction.
- Time-box privileged access and capture session proof Require privileged sessions, administrative elevations, and credential rotations to produce records that can be reviewed against policy and retention requirements.
- Map each CERT-In obligation to a named evidence owner Assign ownership for vulnerability handling, secure development, incident reporting, and access governance so every requirement has a person, a source of truth, and a review cadence.
What's in the full article
AccuKnox's full article covers the operational detail this post intentionally leaves for the source:
- The six pillar-by-pillar checklist used to map CERT-In guidance against existing controls
- Evidence categories for proving assessment, remediation, release validation, and incident response
- The internal drill structure used to test six-hour reporting and assurance workflows
- The practical wording of the self-audit questions that turn policy into verifiable control evidence
👉 Read AccuKnox’s CERT-In readiness analysis and internal compliance checklist →
CERT-In readiness: what security teams must prove under audit?
Explore further
Evidence readiness is now a governance control, not an audit afterthought. The article shows that mature security work can still fail scrutiny if it cannot be proven coherently. That is the real shift in regulatory posture: control design is no longer enough, because auditors and customers now expect a lifecycle record that links assessment, remediation, validation, and accountability. Practitioners should treat evidence continuity as part of security architecture.
A question worth separating out:
Q: How should security teams prepare for a regulator or customer assurance review?
A: They should prepare a traceable evidence model before the review happens. That means naming the control owner, the log source, the review cadence, and the closure criteria for each requirement. The goal is to answer specific questions quickly, using records that show how the control behaved over time.
👉 Read our full editorial: CERT-In readiness shows compliance now depends on evidence