An information security audit checks whether an organisation protects the confidentiality, integrity and availability of its information, and whether it can prove it. It starts with a clear scope, drawn from an up-to-date asset list. It ends with a report that names findings, owners and fix dates. The quality of the audit depends mostly on the scope and the evidence, not on the tools.
Last reviewed: 17 October 2026. Facts checked. We read the full text of CERT-In's Comprehensive Cyber Security Audit Policy Guidelines, Version 1.0, dated 25 July 2025, including the sections on defining audit scope, planning the audit and report handling. We did not open ISO/IEC 27001 or NIST CSF 2.0 text for this post. The checklist items beyond CERT-In's scope list are our working suggestions, not a regulatory list.
What it covers
CERT-In's guidelines say the auditee should define a complete scope. They list the areas the scope should include:
- Systems and applications, both web and mobile
- Software and network infrastructure
- Operational technology and industrial control systems, where they exist
- Cloud architecture and APIs
- Databases and hosting infrastructure
- Code review and application security
- Data security
- A test of incident response capability
They add that testing, development and production environments should all be in scope, and that third-party and supply chain risk assessment should be part of it.
How to set the scope
CERT-In's guidelines give a clear route:
- Start from the asset inventory. The scope must come from a consolidated and updated asset inventory, which the IT team reviews periodically.
- Write down the inventory date. The audit reports should state the date up to which the inventory was updated.
- Get internal review. The scope should be vetted by the internal audit team with the chief information security officer.
- Agree it with the auditor. The auditee defines scope in consultation with the auditing organisation.
- Name versions. Web and mobile application versions should be stated in the scope and the report.
- Plan follow-up. The scope of work should say that follow-up audits are part of the job.
If you skip step one, the audit covers the systems you remember, not the systems you have.
What evidence to collect
Evidence turns a claim into a finding. Ask for it before fieldwork.
| Area | Evidence |
|---|---|
| Governance | Security policy, approval date, owner, board or management review |
| Assets | Inventory with owners and criticality |
| Access | User lists, joiner and leaver records, privileged account list, review sign-offs |
| Network | Firewall rules, network diagrams, configuration exports |
| Applications | Test reports, change records, version list |
| Data | Classification scheme, encryption settings, backup and restore records |
| Incidents | Incident log, response plan, last test |
| Vendors | Vendor list, security review, contract clauses |
CERT-In's guidelines also say the auditing organisation must communicate before work starts the type of audit, the report format, the standards used, the assets in scope, how auditee data is handled and kept, and the timeline. Ask for this in writing.
A short checklist
Use this before the auditor arrives.
- Asset inventory updated, with a date
- Scope written, vetted by internal audit and the security head
- Policies approved and reviewed in the last year
- User access reviewed, leavers removed
- Privileged accounts listed and monitored
- Software patched, or exceptions recorded
- Backups taken and restore tested
- Incident response plan tested
- Vendor access and security checked
- Last audit findings closed or tracked with dates
Our cybersecurity audit checklist goes deeper by control family, and our IT audit checklist sets out the order of work for a financial-statement audit.
Report and follow-up
The audit does not end with the report. CERT-In's guidelines say an audit should not be done just for compliance but to secure the cyber infrastructure. They also call for clear communication on exemptions and limitations, so the auditee does not assume more was covered than was.
For your own management, track each finding with:
- An owner
- A target date
- A status
- Proof of closure
- A retest where the finding was serious
Common gaps
- Scope taken from an old list
- No cloud accounts or shadow IT in scope
- Vendors left out
- Findings closed on paper, not retested
- Evidence gathered after the auditor asked, not before
Frequently Asked Questions
What is the difference between an information security audit and a cyber security audit?
Both look at security controls. "Information security" is the wider term and covers paper and people. "Cyber security" focuses on systems and networks. In practice the words overlap. See our article on how a cyber security audit differs from VAPT and an ISO 27001 audit.
Who should be involved from the company?
IT, the security head, internal audit and the owners of key systems. CERT-In's guidelines expect internal audit to vet the scope.
How often should it be done?
CERT-In's 2025 guidelines say a cyber security audit should be conducted at least once a year, and that sector regulators may require more.
What evidence is weakest?
Verbal assurance and screenshots with no date. Ask for system-generated records.
Do we need an external auditor?
Depends on your regulator, contracts and size. We did not verify a general rule, so check the requirement that applies to you.
Related Articles
Statutory facts on this page are checked against their sources, and the page says where it relied on secondary reporting. How we verify · Report an error