Inside AccuKnox’s CERT-In Readiness Journey

What is CERT-In Guidelines?

On 10 June 2026, CERT-In, India’s national cybersecurity incident response agency published a new set of guidelines aimed squarely at OEMs and technology providers: the companies whose software, cloud services, APIs and managed platforms sit underneath everyone else’s business. The definition of “OEM” in the guideline is deliberately broad. It doesn’t just mean hardware manufacturers. It means software vendors, cloud service providers, managed service providers and digital platform operators.

For a SaaS security company, a moment like this cuts two ways. On one hand, this is exactly the kind of regulatory shift we build products to help other companies navigate. On the other, it meant turning that same lens inward and asking an uncomfortable question: if a regulator audited AccuKnox tomorrow against this guideline, would we hold up?

“If a regulator audited us tomorrow against this guideline, would we hold up?” That question forms the foundation of our compliance framework.

So we moved past the broad requirements, converted the guidelines into a detailed checklist, and began collecting system logs and documentation to verify our posture.

What CERT-In Actually Asks For

Strip away the legal language and the guideline boils down to something fairly intuitive: know what you’ve deployed, test it continuously, respond fast when something serious turns up, build software securely from the start, protect the credentials that guard everything else, and keep evidence that proves all of the above actually happened, not just that a policy exists somewhere.

A SaaS product makes that harder than it sounds. It isn’t one file you can scan and sign off on. It’s APIs, container images, cloud infrastructure, third-party libraries, authentication services and a web of operational integrations and a vulnerability in any single layer can ripple out to every customer downstream. Detection by itself was never going to be enough. What the guideline really demands is a closed loop: find the issue, understand its blast radius, fix it, prove the fix worked, tell the people who need to know, and keep the receipts.

The loop, in practice

We already had a mental model for this loop, even before CERT-In formalized one. It looks like this:

The AccuKnox security response lifecycle — evidence is captured at every stage, not just at the end.

Walk through a realistic scenario and the loop makes sense fast. A Critical vulnerability drops in a widely-used open-source component. A prepared provider should be able to answer, within hours: do we use this component, where, in which services and versions, what’s our exposure, can we throttle the risk while a permanent fix is built, and once it’s deployed, can we prove to ourselves and to a regulator that it’s actually closed. That is the standard CERT-In is pushing the entire industry toward.

Where We Started From: Auditing Our Own House

Before we could talk about readiness, we needed an honest inventory of what already existed. We pulled together every category of evidence that speaks to the security lifecycle, not because any single artifact proves compliance, but because together they show whether a control is real or just written down somewhere: assessment and penetration-testing outputs, component and image analysis, deployment-version records, runtime monitoring, patch management, incident-response planning, secure-development practices, and access-control documentation.

Each category tells a different part of the story. A scan tells you a weakness exists. An inventory tells you where. A patch record tells you how it was fixed. A retest tells you whether the fix actually worked. An incident record tells you whether the team made good decisions under pressure. You need all of them, in sequence, to demonstrate a real lifecycle rather than a pile of disconnected artifacts.

What came back from that inventory was, honestly, encouraging. AccuKnox had a real technical and operational security foundation, this isn’t a company starting from zero. The harder question wasn’t whether the controls existed. It was whether we could prove it, consistently, in a form a regulator could actually verify.

Six Pillars We Mapped the Guideline Against

We organized the guideline into six practical pillars and, for each one, asked the same question: what does CERT-In actually expect here, and how does our existing practice already serve that outcome?

1. Continuous Assessment and Runtime Protection

Where it comes from: Section 2 and Section 2.1(a), pages 2–3

CERT-In wants comprehensive, continuous vulnerability assessment, source-code analysis, software-composition analysis, dependency analysis, threat modelling, penetration testing, behavioural anomaly detection and continuous monitoring, working together rather than as one-off exercises.

How this shows up in our practice: Layered security assessment and runtime monitoring already run as ongoing operational activities, not point-in-time exercises. Findings get validated, prioritized and tracked through remediation as part of the normal workflow.

2. AI Risk, Guardrails and Software Inventories

Where it comes from: Section 2, pages 3–4

For AI-enabled services, CERT-In wants a four-factor risk assessment on every one, sensitivity of accessible data, autonomous actions the system can take, systems it can connect to, and blast radius if it’s misused, plus human oversight, logging and dependency review.

How this shows up in our practice: AI-related risk is addressed through security assessment, prompt and input inspection, policy-based controls and human oversight for sensitive actions — protecting against prompt injection, unauthorized access and data leakage. Component and deployment-version visibility already exists at the SBOM and image-analysis level.

3. Vulnerability Disclosure, Patching and Temporary Protection

Where it comes from: Sections 2.1(b)–(d) and Section 3, pages 4–6

Immediate communication of confirmed Critical and High vulnerabilities. Immediate notification of zero-days or active exploitation, with mitigation guidance and indicators of compromise.

How this shows up in our practice: Patch-management and incident-response practices already support technical validation, severity assessment, affected-version analysis and controlled deployment. Where an immediate patch isn’t practical, compensating controls reduce exposure while a permanent fix is prepared.

4. Secure Development and Release Validation

Where it comes from: Section 4, pages 6–7

An industry-standard Secure Development Lifecycle: architecture review, secure coding, threat modelling, code and dependency analysis, dynamic and penetration testing, supply-chain risk and secrets management, all validated before release.

How this shows up in our practice: Secure-development and testing practices already run across the product lifecycle. Security assessments, dependency and image analysis, SBOM records and release controls help catch insecure configurations and vulnerable components before deployment.

5. Identity, Credentials and Privileged Access

Where it comes from: Section 5, page 7

Strong authentication, role-based access control, privileged-access management, credential rotation, time-bound administration and continuous authentication monitoring.

How this shows up in our practice: Access-control practice already reflects least-privilege design, centrally managed authentication and accountable administrative activity, with temporary elevation used only where operationally required.

6. Incident Response, Reporting and Assurance

Where it comes from: Sections 6–8, pages 8–11

Formal incident-response processes covering detection, containment, evidence preservation, recovery and customer coordination — plus a hard requirement, carried over from CERT-In’s 2022 directions, to report specified cyber incidents within six hours of noticing them.

How this shows up in our practice: Formal incident-response policy and planning material already cover classification, escalation, investigation, containment, recovery and post-incident review, with monitoring and logging supporting investigation throughout.

How We Closed the Loop: From Working Controls to Documented Evidence

Once we lined our own operating history up against the guideline, the honest picture wasn’t a list of missing controls. It was something narrower, and common across the industry: strong security work was already running quietly in the background. What it needed was proper documentation, turning controls that already worked into evidence a regulator or a customer could actually verify.

1. From continuous monitoring to continuous documentation

Our security work already ran continuously. We built out the dated records to prove it — investigation timestamps, closure evidence and coverage tracking across the full environment — so continuous monitoring now produces a continuous, auditable trail.

2. From scattered evidence to one consolidated package

Assessment findings, patch records and release checks already existed, each in the system that produced them. We consolidated them into a single, release-level package tying scope, test results, approvals and verification together end to end.

3. From a documented plan to a rehearsed drill

The six-hour CERT-In reporting requirement was already covered on paper in our incident-response plan. We ran it as a full, timed drill, start to finish, so the process is proven in practice — not just written down.

None of this required new controls. It required documenting what was already working, consistently and in a form that holds up under review — which is exactly the outcome CERT-In is asking every technology provider to demonstrate.

Why This Matters Beyond the Checkbox

It would be easy to treat this as a compliance exercise that only matters to auditors. It doesn’t stay contained to that. When assessment, patching, access control and incident response operate as one connected, well-documented lifecycle, customers feel it directly:

• Faster identification of which services and software versions are actually affected when something goes wrong
• Risk-based remediation, backed by temporary safeguards instead of “wait for the full fix”
• Stronger validation before and after every security-relevant change
• Clearer, faster communication during material vulnerabilities or incidents
• Real visibility into the software components and dependencies underneath the product
• Evidence that holds up under a customer’s own security or compliance review, not just ours

Check Your Own CERT-In Readiness

Building this internal review meant creating a working checklist to score ourselves against, pillar by pillar. We’re sharing it below so any SaaS or technology provider can run the same exercise before a regulator or a customer’s security team asks first.

1. Continuous Assessment & Runtime Protection

☐  Dated penetration-test, SCA and SAST reports covering the full in-scope environment
☐  Runtime monitoring and alerting logs with investigation and closure timestamps
☐  A documented process for tracking findings from detection through to closure

2. AI Risk & Software Inventories

☐  A four-factor AI risk assessment (data sensitivity, autonomy, connectivity, blast radius) for every AI-enabled service
☐  A consolidated SBOM covering products, APIs and third-party dependencies
☐  An inventory of exposed services, endpoints and cryptography in use

3. Vulnerability Disclosure & Patching

☐  A formal external vulnerability-disclosure procedure
☐  A zero-day / active-exploitation response playbook
☐  Patch timelines mapped explicitly to CERT-In’s indicative windows
☐  An evidence chain linking each material finding to mitigation, patch and verification

4. Secure Development & Release Validation

☐  A documented Secure Development Lifecycle (architecture review, secure coding, threat modelling)
☐  Release-level evidence: scope, test results, approvals, exceptions, deployment record
☐  A periodically signed SDL evidence package

5. Identity, Credentials & Privileged Access

☐  Documented access-control policy (least privilege, role-based access)
☐  Credential rotation and privileged-session records
☐  Scheduled access reviews and credential-hygiene checks

6. Incident Response, Reporting & Assurance

☐  A formal incident-response plan covering detection through post-incident review
☐  A tested, timed six-hour reporting workflow
☐  The five Section 7 deliverables: security-posture assessment, remediation action plan, management commitment, continuous assurance report, SDL compliance evidence

If most boxes across a pillar are checked, that pillar is likely in good shape technically — the remaining work is usually consolidation, not new controls. If a pillar has several unchecked boxes, that’s where to start.

This Isn’t a Report You File Once

The honest ending to this story is that there isn’t one. Products change, dependencies get added and dropped, deployments shift, and threats evolve, which means a CERT-In readiness assessment from June 2026 is stale by definition the moment something material changes. We maintain a detailed, requirement-by-requirement internal assessment separately from this public account, mapping every guideline obligation to its source, its evidence, its current readiness position and its next action. That internal record is what gets refreshed continuously; this article is the plain-language summary of where that record stands today.

Key Takeaway

CERT-In’s 2026 guidance sets a clear bar: know your environment, test it continuously, respond fast, build securely, protect access, and keep evidence that proves it. For AccuKnox, meeting that bar isn’t about bolting on new tools, it’s about connecting security assessment, software-component visibility, runtime protection, patching, secure development, access control and incident response into one measurable, auditable lifecycle.

The foundation was already there when the guideline landed. The work since has been about proving it consistently, on paper, in a form a regulator or a customer can actually verify. Because we invested in getting that documentation right, we can now point to exactly where each pillar stands, evidence in hand, rather than taking it on faith.

The result isn’t a binder of policies. It’s a repeatable process for finding risk, shrinking it, proving the fix, and keeping the evidence to show for it.

Official References

1. CERT-In, Guidelines regarding AI-Accelerated Vulnerability Protection and Response Requirements for OEMs and Technology Providers, Version 1.0, 10 June 2026: cert-in.org.in

2. CERT-In, Directions relating to information security practices, procedure, prevention, response and reporting of cyber incidents, 28 April 2022: cert-in.org.in

This document records evidence readiness and does not constitute CERT-In certification or legal advice.