Audit Methodology & Planning
This is the process you actually follow, start to finish, on every audit — regardless of whether the systems underneath are IT, OT, or both. Parts 4 and 5 tell you what to test; this module tells you how the engagement itself runs.
Types of Cybersecurity Audits
Not every cybersecurity audit asks the same question. Before you plan anything, know which of these you're actually doing — it changes everything downstream: scope, tools, timeline, and who you need to talk to.
Compliance Audit
"Does the entity follow the rules it's supposed to?" Tests against cyber-safety law/official incident-response service/data protection requirements, internal policy, or a named standard (ISO 27001). Mostly document and configuration review.
Performance / Value-for-Money Audit
"Is the entity's cybersecurity spending and effort producing results?" Looks at whether security investments (tools, staff, training) are actually reducing risk, not just being purchased.
Information Systems (IS) Audit
"Do the IT general controls and application controls work as intended?" The broadest category — covers access control, change management, operations, and the technical domains in Part 4.
Technical / VAPT-Based Audit
"Can these specific systems actually be broken into?" Hands-on testing — scanning, exploitation attempts within agreed rules — the deepest but narrowest and most resource-intensive type.
Forensic Audit
"What exactly happened during a specific incident, and who is responsible?" Triggered after a breach or suspected fraud; evidence-handling rigour is paramount (see Part 9.4).
Follow-Up Audit
"Did the entity actually fix what we found last time?" Revisits prior findings to verify remediation — often skipped, always valuable (Part 8.4).
Most real institutional cybersecurity audits are a blend — primarily a compliance/IS audit with a technical VAPT component for high-risk systems. State the blend explicitly in your audit memo so the auditee and your supervisor share the same expectation.
Risk-Based Audit Planning & Scoping
You cannot audit everything, everywhere, with equal depth — no audit team has that much time. Scoping means deliberately deciding what you will and won't look at, based on where the real risk is, so your limited time goes where it matters most.
1. Understand the entity's mission & systems landscape
Read the entity's annual report, prior audit reports, and any IT/OT systems inventory. Identify which systems handle money, personal data, or physical/safety-critical operations — these are your highest-risk candidates by default.
2. Build a risk-ranked system inventory
List every major system (e.g. "e-Hospital application," "SCADA for water treatment plant," "payroll ERP") and rank each by a rough combination of (a) sensitivity of data/operations, (b) internet exposure, (c) prior incident history, (d) age/technical debt.
3. Set audit objectives
Write 2–4 specific objectives, e.g. "Assess whether access controls over the treasury payment system prevent unauthorised fund transfers" — not "review cybersecurity," which is too vague to plan against.
4. Define scope boundaries explicitly
State which systems, locations, and time periods are in scope — and just as importantly, what is explicitly out of scope. Get this written into the audit memo before fieldwork starts.
5. Estimate resourcing & timeline
Match team skills to scope — an OT-heavy scope needs someone who has done Part 5, not just Part 4. Build in time for report drafting and management response, not just fieldwork.
Entry Conference & Document Request
The entry conference is your first formal meeting with the entity — where you explain what you're doing and why, and they tell you how their systems actually work (which is often different from how the org chart suggests). Walking in with a document request list in hand saves weeks of back-and-forth later.
Standard pre-audit document request checklist
| Document | Why you need it |
|---|---|
| Network & system architecture diagrams | Establishes scope and segmentation claims to verify later |
| IT/cybersecurity policy documents | Defines the "criteria" you'll audit against (Part 8.1) |
| Asset inventory (hardware, software, OT devices) | Can't test what you don't know exists — also tests whether the inventory itself is accurate |
| List of internet-facing systems / public IP ranges | Defines your external attack-surface testing scope |
| Last VAPT / IS audit report & management response | Tells you what's already known and whether it was fixed |
| User access list for privileged/admin accounts | Starting point for IAM audit (Part 4.3) |
| Incident log for the audit period | Cross-check against official incident-response service reporting obligations (Part 2) |
| Backup & DR policy and last test report | Starting point for Part 4.9 |
| Organisation chart for IT/security function | Reveals whether security has organisational authority or is buried under IT operations |
Risk Assessment Methodology
A risk assessment is just a structured way of answering "how worried should we be about this?" — using a consistent scale so that a "High" risk in the network audit means the same thing as a "High" risk in the OT audit.
This manual uses a simple 5×5 likelihood/impact matrix throughout — the same one referenced by the risk badges (Critical High Medium Low) you've already seen.
| Impact ↓ / Likelihood → | Rare | Unlikely | Possible | Likely | Almost Certain |
|---|---|---|---|---|---|
| Severe (e.g. mass data breach, safety incident) | Medium | High | High | Critical | Critical |
| Major (e.g. service outage >1 day) | Low | Medium | High | High | Critical |
| Moderate (e.g. limited data exposure) | Low | Low | Medium | High | High |
| Minor (e.g. brief, contained disruption) | Low | Low | Low | Medium | Medium |
Use this same matrix when you rate findings in Part 8.2 — consistency across the report is what makes prioritisation credible to the auditee and to your reviewing officer.
Sampling & Materiality
You usually can't check every single user account, every server, or every transaction — sampling means checking a representative subset and drawing a conclusion about the whole. Materiality means deciding how big a problem has to be before it's worth mentioning in your report.
Sampling approach
For control testing (e.g. "are terminated employees' accounts disabled promptly?"), pick a sample of recent leavers — typically 25–40 for a medium-sized entity — across different departments and time periods, not just the most recent month.
Materiality threshold
Set this with your team lead before fieldwork: e.g. "any single finding affecting a system handling >₹1 crore in annual transactions, or any finding involving citizen PII, is automatically material regardless of how isolated it looks."
Treating a single sampled exception as a one-off and dropping it. If you find one terminated employee's account still active, that is evidence the process may be broken — widen your sample before concluding it's isolated.
Evidence & Working Papers
A working paper is your documented proof of what you actually did and saw — not your memory of it. If your finding is ever challenged (by the auditee, in a tribunal, or years later by someone reviewing the file), the working paper is what you stand on.
Every test you run in Parts 4–6 should produce a working paper with these elements:
WP Ref: NET-04
Objective: Confirm internet-facing assets are limited to those approved and documented
Criteria: Entity's Network Security Policy v2.1, s.4.2; official incident-response service Directions 2022
Procedure: Ran Nmap scan against the entity's declared public IP range 203.0.113.0/24
on 14-Feb-2026, 10:15–11:40 IST, from auditor workstation AUD-LP-07.
Evidence: Screenshot of scan command + full output saved as NET-04-Ex1.png;
raw .nmap/.xml output saved as NET-04-scan.xml
Observation: 3 hosts responded that were not on the entity's declared asset list
(203.0.113.45, .61, .88) — see NET-04-Ex2 for side-by-side comparison
Conclusion: Exception noted — asset inventory is incomplete; raised as Finding NET-F03
Prepared by: [Officer name] Reviewed by: [Reviewing officer] Date: [date]
Screenshot or export raw tool output the moment you generate it, with the exact command and timestamp visible. Six weeks later when you're drafting the report, you will not remember the exact flags you used — and "I'm sure I ran a scan" is not evidence.
Audit Programme Design
An audit programme is your detailed to-do list — every individual test you plan to run, in order, with who does it and what "done" looks like. Parts 4, 5, and 6 of this manual are written so you can lift sections almost directly into your programme.
A good audit programme line includes: objective, procedure (specific enough that a colleague could execute it without asking you questions), expected evidence, and assigned owner. Build yours by walking through Part 4 (or 5, for OT) section by section and pulling out every numbered "Audit test" callout into a programme line.
Interactive Audit Programme Builder
Select your entity type, audit type, available days, team size, and the domains you'll cover — the builder calculates a prioritised domain allocation and a day-by-day schedule you can print and take into the field.
The Audit Programme Builder is also accessible from the Reference section of the sidebar — open it there during a live engagement so you're not navigating away from your place in the manual.