When You Need a CERT-In Empanelled Security Audit

A department is ready to launch a new citizen portal, but the hosting team will not make it live without a security audit certificate. A broker's compliance officer is told that the annual cyber audit must be done by an approved firm. A software vendor bidding for a state tender finds "safe to host certificate" in the eligibility list. In each case the requirement is the same: a CERT-In empanelled security audit.

Many organisations treat this as a last minute formality and book an auditor a week before the deadline. That usually leads to a long list of findings, rushed fixes and delayed launches. This guide explains what empanelment means, when the audit is typically required, what it covers and how to prepare so the process runs on time.

What CERT-In Empanelment Means

CERT-In (the Indian Computer Emergency Response Team) is the national agency for cyber security incident response under the Ministry of Electronics and Information Technology. It evaluates information security auditing organisations and publishes a list of empanelled auditors on its website.

Empanelment tells a buyer or regulator that the auditing firm has passed CERT-In's technical evaluation. It does not certify your application or network. Your system is judged by the audit report and the closure of the findings in it. Always check that the auditor's name appears on the current list published by CERT-In before you sign an engagement.

When You Need a CERT-In Empanelled Security Audit

Government websites and applications

Government departments, municipal bodies and PSUs are generally expected to get their websites, portals and mobile apps audited by a CERT-In empanelled auditor before hosting, and again after major changes. Data centres that host government applications often ask for this report, sometimes called a safe to host certificate, before they allow the application to go live. The Guidelines for Indian Government Websites and Apps (GIGW) also set out security expectations for such sites.

Regulated financial entities

Financial regulators ask many regulated entities to use CERT-In empanelled auditors. For example, SEBI's Cybersecurity and Cyber Resilience Framework, issued in August 2024, requires its regulated entities to conduct cyber audits through CERT-In empanelled auditors. If you are a stock broker, depository participant or similar entity, check the exact audit scope and timelines in the circular that applies to your category.

Tenders and enterprise contracts

Many government tenders and large enterprise buyers ask vendors to submit a security audit report from a CERT-In empanelled firm for the software being supplied. Read the bid document carefully. Some ask for an audit of the specific application, others for the vendor's own infrastructure.

As good practice

Even where it is not mandatory, an independent audit before a major launch is sensible for any business handling customer data, payments or health records.

What the Audit Usually Covers

Scope depends on what you ask for, so define it clearly. Common audit types include:

• Web application security testing: checks for issues such as injection flaws, broken authentication, insecure access controls and misconfiguration, often mapped to the OWASP Top 10.
• Mobile application testing: Android and iOS apps, including local data storage and API calls.
• API testing: authentication, authorisation and input handling on backend APIs.
• Network and infrastructure VAPT: vulnerability assessment and penetration testing of servers, firewalls and network devices.
• Configuration review: hardening of operating systems, databases and cloud settings.
• Process and policy review: for compliance audits, a review of policies, access management, logging and incident response.

The auditor usually issues a first report with findings rated by severity. After you fix them, a retest follows and a final report or certificate is issued once critical and high findings are closed.

How to Prepare: A Practical Checklist

1. Freeze the scope. List URLs, apps, APIs, IP ranges and user roles to be tested. Changes midway reset the clock.
2. Provide a stable staging environment that mirrors production, with test accounts for every role.
3. Run your own scan first. Fix obvious issues such as outdated libraries, missing security headers, default passwords and open admin panels before the auditor sees them.
4. Check logging. The CERT-In Directions of April 2022 require organisations to maintain logs of their ICT systems for 180 days and to report certain cyber incidents to CERT-In within six hours of noticing them. Make sure logs are enabled and retained.
5. Review access control. Confirm that one user cannot view another user's data by changing an ID in the URL. This is one of the most common findings in government portals.
6. Keep developers available. Findings get closed faster when the people who wrote the code are on hand during the audit and retest window.
7. Plan time for at least one retest. Budget calendar time for fixing and retesting, not only for the first round.

Common findings to fix before the audit starts

Across portals and business applications, the same issues appear again and again. Fixing them in advance shortens the audit cycle:

• Outdated JavaScript libraries, frameworks and server software with known vulnerabilities
• Missing security headers and cookies without the Secure and HttpOnly flags
• Weak password rules, no account lockout and no CAPTCHA on login or OTP pages
• File upload fields that accept any file type
• Detailed error messages that reveal database or server information
• Admin pages reachable from the public internet
• Sensitive data such as Aadhaar or mobile numbers shown in full where masking would do

Choosing an Auditor and Managing Findings

When selecting an empanelled auditor, look beyond price. Ask about experience with your type of system, the tools and manual testing methods they use, report format, retest policy and turnaround time. Confirm who will actually perform the testing.

Once the report arrives, treat findings as engineering work, not paperwork:

• Fix the root cause, not only the tested page. If one form was vulnerable to injection, check every form.
• Record each fix with evidence for the retest.
• Where a finding cannot be fixed immediately, document the risk, the compensating control and the target date.
• Feed lessons into your development process so the next release starts cleaner.

Security audits work best as part of an ongoing programme. Our cybersecurity services page outlines how regular VAPT, secure coding reviews and monitoring fit together.

Frequently Asked Questions

Who needs a CERT-In empanelled security audit?

Typically government websites and apps before hosting, entities whose regulator requires it such as those covered by SEBI's cyber framework, and vendors whose tender or contract asks for it.

How often should the audit be done?

Before launch, after major changes, and at the frequency your regulator, hosting provider or contract specifies. Many organisations audit at least once a year.

How long does an audit take?

It depends on the size of the application or network and the number of findings. Allow time for the first test, fixes and at least one retest.

Is empanelment the same as certification of my system?

No. Empanelment applies to the auditing firm. Your system is assessed through the audit report and the closure of its findings.

How Affix Center Can Help

We help organisations get ready for a CERT-In empanelled security audit by reviewing applications and infrastructure, fixing common vulnerabilities, setting up logging and supporting developers through the retest cycle. For public sector teams, we also support secure development of e-governance platforms from the design stage.

If you have an audit or hosting deadline coming up, contact our team to plan your preparation.