An ISO 27001 internal audit is a self-run, evidence-based check of your Information Security Management System (ISMS) against the ISO/IEC 27001:2022 requirements and its 93 Annex A controls, performed before a certification or surveillance audit. For Indian SaaS and IT SMBs, it means: scope the audit, sample evidence across the four Annex A themes (organizational, people, physical, technological), log every nonconformity, fix root causes, and feed results into management review. Skipping this step is the single most common reason certification audits fail on the first attempt.
Most Indian teams treat the internal audit as a formality — a checkbox exercise the week before the external auditor arrives. That approach gets flagged. Certification bodies expect a genuine, planned, documented internal audit programme under Clause 9.2 of ISO/IEC 27001:2022, not a retroactive paperwork exercise. This checklist walks through the full cycle the way an experienced lead auditor would run it.
Why the internal audit matters more than teams think
ISO/IEC 27001:2022, Clause 9.2, requires organizations to "conduct internal audits at planned intervals" to determine whether the ISMS conforms to the organization's own requirements and to the standard, and whether it is effectively implemented and maintained. External certification auditors will ask for internal audit records — audit plan, findings, corrective actions, and management review minutes — as the first evidence pack. A thin or missing internal audit trail is a near-automatic major nonconformity.
For Indian SMBs racing toward certification to unlock enterprise or government contracts, the internal audit is also the cheapest place to catch gaps. Fixing a missing access-review log or an unencrypted backup internally costs a config change. The same gap found by an external auditor costs a stage-2 audit delay, and possibly a re-audit fee. Teams that also handle personal data as defined under the Digital Personal Data Protection Act, 2023 should align internal audit evidence with those obligations too, since the control overlap is significant.
The ISO 27001 internal audit cycle
Run the internal audit as a repeatable cycle, not a one-off event. The diagram below shows the flow this checklist follows.
Step 1: Plan the audit scope
Before touching a single control, define and document:
- Scope — which business units, systems, locations, and third parties fall inside the ISMS boundary (your Statement of Applicability should already list this).
- Audit criteria — ISO/IEC 27001:2022 clauses 4–10, plus applicable Annex A controls from your Statement of Applicability (SoA), plus internal policies.
- Audit programme — frequency (most Indian SMBs run internal audits twice a year ahead of an annual surveillance cycle), auditor assignments, and a schedule that gives auditees at least two weeks' notice.
- Auditor independence — Clause 9.2 requires auditors who did not do the work being audited. A three-person engineering team auditing its own IAM controls is a common finding gap — bring in a peer team lead, a compliance consultant, or rotate auditors across departments.
Step 2: Conduct the audit against the 93 Annex A controls
Walk each of the four themes systematically. Don't audit alphabetically by control number — group by theme so the same evidence source (e.g., HR records, the asset register, the DC provider's SOC 2 report) gets pulled once.
Organizational controls (37 controls, A.5.1–A.5.37) — policies, roles and responsibilities, supplier relationships, incident management, business continuity, legal and contractual requirements, threat intelligence. Sample evidence: information security policy sign-off, supplier security assessments, incident log with response times, records of legal/regulatory register review (relevant for Indian teams tracking DPDP Act obligations).
People controls (8 controls, A.6.1–A.6.8) — screening, terms of employment, security awareness training, disciplinary process, remote working, and confidentiality agreements. Sample evidence: signed NDAs, background-verification records, training completion logs, offboarding checklists confirming access revocation within a defined SLA.
Physical controls (14 controls, A.7.1–A.7.14) — physical security perimeters, entry controls, protection against environmental threats, equipment maintenance, secure disposal. For Indian teams on shared coworking or cloud-only infrastructure, this maps largely to data-center provider attestations (AWS/Azure/GCP compliance reports) plus office access logs and clean-desk checks.
Technological controls (34 controls, A.8.1–A.8.34) — access control, cryptography, vulnerability management, logging and monitoring, secure development, network security, malware protection, and backup. This is the theme where automated evidence collection pays off fastest — vulnerability scan reports, patch cadence records, MFA enforcement logs, and configuration baselines.
For each control, the auditor should record: is it implemented, is it operating effectively (not just "on paper"), and is there objective evidence (a log, a screenshot, a signed document, a ticket) to prove it. "The team says they do this" is not evidence.
Common Annex A theme checklist
| Theme | # Controls | Typical evidence auditors ask for | Common Indian-SMB gap |
|---|---|---|---|
| Organizational | 37 | Policy register, supplier contracts, incident log, legal register | No documented supplier risk assessment for outsourced dev/QA teams |
| People | 8 | Background checks, training logs, offboarding checklist | Offboarding not tied to an HR trigger — access revoked days late |
| Physical | 14 | Access logs, DC provider attestations, asset disposal records | No formal clean-desk or clear-screen policy evidence |
| Technological | 34 | Vulnerability scan reports, MFA logs, backup test records, patch logs | Backups exist but restore has never been tested |
Step 3: Document nonconformities properly
Every gap found during the audit gets logged as a nonconformity (NC) with:
- Clause/control reference — which requirement was not met.
- Objective evidence — what was observed (a missing log, an expired certificate, an untested backup).
- Classification — major (systemic, or a complete absence of a required control) vs. minor (an isolated lapse in an otherwise working control).
- Root cause — not just the symptom. "MFA was disabled on one admin account" is a symptom; "no periodic access review process exists" is the root cause.
Step 4: Corrective action
For every nonconformity, Clause 10.1 requires a corrective action that addresses the root cause, not just the immediate symptom, plus a review to confirm the action worked. Track:
- Action owner and target date.
- Root-cause fix (e.g., implement a quarterly access review job) — not just a one-time patch (e.g., manually disabling one stale account).
- Verification evidence that the fix was effective, collected at a later date — not closed same-day on a promise.
Step 5: Management review
Clause 9.3 requires top management to formally review the ISMS — internal audit results, corrective action status, risk assessment changes, nonconformity trends, and resource needs — at planned intervals (typically annually, aligned with your certification cycle). Minute this meeting. Auditors will ask for management review minutes as standard evidence, and a missing or perfunctory review is a recurring finding in Indian SMB first-time certifications.
Feed management review outputs back into the next audit plan — new risks, new suppliers, or new regulatory obligations (like updated MeitY guidance or sector-specific RBI/SEBI cybersecurity frameworks for regulated entities) should reshape next cycle's scope. That's the continual improvement loop the standard requires.
Know your vulnerabilities before attackers do
Run a free VAPT scan — takes 5 minutes, no signup required.
Book Your Free ScanWhere automation helps — and where it doesn't
Evidence collection for the technological theme (vulnerability scans, patch status, exposed services, misconfigurations) is where continuous automated scanning saves the most audit-prep time versus manual screenshotting once a year. Bachao.AI runs continuous VAPT scans that generate the kind of dated, timestamped evidence auditors want for A.8 controls — vulnerability management, logging, and network security — without a scramble the week before the audit. Automation cannot replace the organizational and people-theme evidence (contracts, training records, management sign-off), which still needs a human audit trail. Dhisattva AI Pvt Ltd built this platform specifically to close that automation gap for Indian SMB security teams stretched thin on headcount.
If your team hasn't run a security assessment recently, a free VAPT scan is a fast way to surface technological-theme gaps before your internal audit date, and for teams also tracking data protection obligations alongside ISO 27001, see the DPDP compliance guide for how the two overlap on data handling controls.
Building your internal audit checklist
A practical starting checklist for Indian SMB teams:
- Confirm Statement of Applicability is current and every exclusion is justified.
- Assign independent auditors per department — no one audits their own work.
- Pull evidence by theme, not by control number, to reduce duplicate evidence requests.
- Classify every gap as major/minor with a documented root cause.
- Set corrective action deadlines and re-verify before closing.
- Hold and minute the management review before the certification/surveillance date.
- Update the risk register and next audit scope based on management review outputs.