Published 09 June 2026 · Updated 08 October 2026
Why the empanelment matters
The Indian Computer Emergency Response Team (CERT-In) maintains a list of organisations empanelled to carry out information security audits. Government departments, public sector bodies and many regulated entities ask for audits by an empanelled organisation, and some hosting environments will not accept a report from anyone else.
Empanelment is reviewed periodically, so check the current list on the CERT-In website before you engage an auditor. CERT-In also publishes guidelines for auditee organisations, and reading them early will save time later.
An empanelled auditor must also be independent of the systems it audits. If the same firm built or operates the application, ask a different empanelled organisation to carry out the audit.
Define the scope in writing
Most delays in security audits trace back to a vague scope. Agree in writing exactly what will be tested, from which locations, and what is out of bounds. The scope drives the effort, the schedule and what the final report can truthfully say.
Count carefully. A web application with an administrative portal and a public portal is often two applications for effort purposes, and an API used by a mobile app needs testing in its own right because attackers can call it directly.
- Web applications by URL, with the modules and user roles to be covered.
- APIs by base URL, with documentation or a collection file.
- Mobile applications by platform and build version.
- Network devices, servers and cloud accounts by IP range or identifier.
- The testing approach, such as black box, grey box or configuration review.
- Any systems or techniques that are explicitly excluded, such as denial of service.
- Third-party services and integrations, noting which are tested and which are only reviewed.
Prepare an asset list and owners
Give the auditor a current list of the assets in scope, with an owner for each who can answer questions and approve fixes. Include versions of operating systems, frameworks and major components where you have them. A good asset list also helps your own team, because findings can be routed to the right person on the day they are raised.
Include the third-party components and services the application depends on, such as payment gateways, identity providers, content delivery networks and analytics scripts. They may be outside the scope of testing, but the auditor needs to know they exist to judge how data flows and where trust boundaries lie.
Choose test and production environments deliberately
Application testing is usually done on a staging or test environment that mirrors production. It should run the same code, configuration and security controls, with test data rather than live personal data. If staging differs from production in ways that affect security, tell the auditor so the report can reflect it.
Some checks, such as external network exposure, TLS configuration and hosting controls, are only meaningful against production. Agree testing windows, rate limits and an emergency contact for these, and let your hosting provider know in advance.
Back up staging before testing begins. Testing involves submitting unexpected input and may create, change or delete records, and it is easier to restore a clean copy than to tidy up by hand.
Arrange access before the start date
Testers lose days waiting for credentials or firewall changes. Set up access before the engagement starts and confirm it works.
Test the accounts yourself the day before. Expired passwords, missing roles and multi-factor prompts tied to one person's phone are common reasons for a lost first morning.
- Test accounts for each user role in scope, including administrative roles where agreed.
- IP allow-listing or VPN access for the audit team.
- A signed authorisation letter and non-disclosure agreement.
- A named technical contact and a named business contact for the duration.
- Read-only access to configurations if a configuration review is in scope.
Evidence and how it is handled
Auditors record evidence for every finding: requests and responses, screenshots and configuration extracts. Ask how this evidence will be stored, who can see it and when it will be destroyed after the engagement.
Keep your own record of what was tested and when. CERT-In also issues directions on incident reporting and log retention, so make sure the logs generated during testing are kept as your policy requires and that your monitoring team knows which activity is authorised.
If testing will touch personal data in production, agree in advance how that data will be minimised in screenshots and reports. Redaction is better done at capture time than afterwards.
Remediation and re-test
The first report lists findings with a severity, evidence and a recommendation. Fix them in order of risk, record what you changed and tell the auditor when each fix is ready for verification.
The re-test confirms whether each finding is closed. A finding is closed when the vulnerability no longer exists, not when a compensating note has been added. If you accept a residual risk, record who accepted it and why, because the final report will show it as open.
Agree a remediation window at the outset. Long gaps between the first report and the re-test tend to coincide with new releases, which can introduce new issues and widen the re-test.
The final report
The final report should identify the auditing organisation and its empanelment, the audit team, the scope, the dates, the methods used and every finding with its status after re-test. Check the scope section carefully; a report is only useful for the systems and versions it names.
Keep the report with your risk records and plan the next audit. Regulators and hosting providers typically expect audits to be repeated at intervals and after significant changes.
Ask for the report in the form your stakeholder expects, whether that is a ministry, a regulator or a hosting provider. Some ask for a summary certificate or compliance letter alongside the detailed technical report.
