Audited before hosting. Secure after it?

For the audit that clears an application for hosting, the auditor has to be one of the bodies the rules name. GIGW 3.0 requires a security audit and an audit clearance certificate from NIC, STQC, an STQC-empanelled laboratory or a CERT-In-empanelled laboratory before hosting in production, and CERT-In’s 2025 guidelines tell the website’s content owner to ensure the audit is done by a CERT-In-empanelled organisation. Internal audits and testing between audits need not be done by an empanelled firm. SemperWise is not empanelled; we prepare you for the mandatory audit and you appoint the auditor directly.

An independent security audit of the application, usually on a staging environment that mirrors production, before it goes live. The auditor records the hash values and version numbers of the audited build in the certificate, files audit metadata with CERT-In within five days, and the findings are closed and confirmed before the clearance is relied on. The detail is in CERT-In’s Comprehensive Cyber Security Audit Policy Guidelines of July 2025. The certificate covers that build only; the next major change needs a fresh audit.

At least once a year and after every major change, under CERT-In’s 2025 audit guidelines — and CERT-In’s guidelines for government entities add an internal audit at least once every six months. In practice a busy portal changes more often than annually, so the “major change” trigger is the one that matters most. Testing between audits, after each significant release, keeps the formal audit from being the first time a change is examined — see continuous penetration testing.

Not for the purposes of the audit clearance. We are not CERT-In empanelled and not an STQC or NIC lab, so we cannot issue it, and CERT-In’s guidelines forbid empanelled auditors from sub-letting an audit, so we cannot do it under another firm’s name either. What we can do is everything around it: a pre-audit test of the staging build, fixing priorities for your developer, verification that fixes hold before the empanelled auditor retests, testing between audits, and keeping your evidence in order. We say this before any work begins.

Yes, unless a department is an instrumentality the Central Government has notified under section 17(2)(a), and then only for processing in the interests that section lists. Other departments, PSUs and municipal bodies are Data Fiduciaries. Section 7(b) lets the State process personal data for subsidies, benefits, services, certificates and licences without consent, but the duties to keep reasonable security safeguards and to report a breach still apply from about 13 May 2027. See DPDP Act compliance.

The April 2022 CERT-In Directions apply expressly to government organisations: listed incidents — including website defacement, intrusion, data breaches and leaks, and attacks on applications such as e-governance services — must be reported within six hours of noticing them. Departments must also keep logs of their ICT systems for 180 days within India and name a point of contact for CERT-In. Contracts should require vendors to notify the department fast enough for it to meet that six-hour deadline.

At minimum: secure-by-design requirements, static code analysis by the developer, a software bill of materials with each release, a right to audit and incident-reporting terms with a notice period in hours, an audit scope that covers development, UAT and production plus third-party components, follow-up audits inside the original scope, 180-day log retention in India, and a requirement that the named empanelled auditor does the work itself. The section on tender clauses above explains each, with its source in CERT-In’s guidelines.

Often you would not, from the inside — the 2026 campaigns used cloaking so administrators saw a normal page while search engines and visitors saw spam or redirects. Check what search engines have indexed under your domain, look for unfamiliar site-verification entries in your search-console accounts, review the web server’s files and redirect rules rather than the CMS view, and monitor the site from outside. Continuous external discovery of what resolves under your domains catches forgotten microsites before they are used.