Skip to main content

What an auditor asks to see from an awareness programme

The eight questions an auditor puts to a security awareness programme, the RBI, SEBI, CERT-In and DPDP clause behind each of them, and the answers that fail.

By Yash Kadakia
August 31, 20267 min read

An internal auditor, a regulator's inspection team and a CERT-In empanelled auditor arrive with different mandates and substantially the same question set. None asks whether the training was good. They ask which clause binds this entity, who was covered against the cadence it sets, how awareness was evaluated as distinct from how it was delivered, and what happens to the data underneath.

The answers that fail are rarely dishonest. They are the artefacts a training programme naturally produces, offered against clauses asking for something else. Here are the eight questions, the clause behind each, and the answer that does not survive it.

The obligation, the cohorts and the cadence

Show me the awareness obligation that applies to this entity

The RBI Directions, 2026, issued 31 July 2026, place the awareness obligation at a different paragraph in each of six entity-specific instruments. "The bank shall evaluate the awareness level of employees periodically" is ¶202 for commercial banks, ¶201 for payments banks and small finance banks, ¶197 for credit information companies. NBFCs are constructed differently, at Section C.12 Training, ¶35–36; urban co-operative banks carry ¶156, Section H.

A good answer gives the Direction by entity type, the paragraph and the date; for a UCB, the level first, since Section H sits in Chapter V, which the applicability table at ¶4 binds to Level III and Level IV UCBs.

The answer that fails is one paragraph number carried across a group. A holding company citing ¶202 for both its bank and its NBFC arm has it wrong for one of them. The looser version records it as "the RBI cyber security framework", with no paragraph at all: an obligation stated at that resolution cannot be tested.

Show me coverage for each cohort the clause names, against the cadence it sets

The clauses name cohorts, not a workforce. "Cybersecurity awareness programmes shall be mandatory for all new recruits, and annual training shall be conducted for lower and middle management" (¶203), with "annual training to all Board members and Senior Management" drawn separately at ¶204. UCB ¶156 reaches upper management, and prescribes a web-based quiz every year.

A good answer is coverage per cohort, each with its own denominator and dates: joiners in the period for new recruits, the management population for the annual cycle, the Board and Senior Management on their own line.

The answer that fails is one aggregate figure for all employees. A high workforce completion percentage is consistent with the Board at zero, and ¶204 is the paragraph asking about the Board. The second is a rolling twelve-month number against an annual obligation: with no anniversary date, nobody can say whether a given Board member was trained in the period.

Evaluation, not delivery

Show me how you evaluated awareness, not how you delivered training

¶202 is a separate paragraph from ¶203: the duty to evaluate is drawn apart from the duty to train. NBFC ¶36 requires "a formal mechanism to measure and track the effectiveness of such training through periodic assessments or testing". For SEBI regulated entities, GV.RM Guidelines item 1(e), p. 87 (GV.RM.S3), applicable to "All REs except small-size, self-certification REs (Mandatory)", says REs "shall periodically assess level of employee cybersecurity awareness, for e.g., through phishing test success rate, etc." The periodic assessment is the obligation; the phishing test is the regulator's example.

A good answer is a result with a population, a method and a date, produced separately from the delivery record.

The answer that fails is the attendance register: a completion export evidences that a session occurred, which was the previous question. The subtler failure is the end-of-module quiz, taken immediately after the content with the answers on the preceding slide. It measures retention of a module, in the module.

Show me the repository

NBFC ¶36 closes with a second requirement: "an up-to-date repository of the training and awareness status of all users".

A good answer is a single record, current as at the day it is produced, resolving any user the auditor names to a status and its date.

The answer that fails is the quarterly deck, a report as at a date that ages from there: between quarters, the status of everyone who joined, changed role or left goes unrecorded. The second is the vendor portal, whose population is bounded by whatever the enrolment feed put into it, while all users is the standard the paragraph sets.

The SEBI evidence fields

Show me the CCI evidence for Measure 3, and the cadence you run to

The Cyber Capability Index scores awareness at CSCRF Annexure-K, p. 166, Measure 3, "Security Training Measure [PR.AT.S1]", which applies to MIIs and Qualified REs, per GV.OV Guidelines item 1, p. 85. The measure is "Percentage (%) of information system security personnel that have received security training within the past one year", target 100%, weighting 5%. Its evidence fields are "Details of the training/awareness sessions scheduled within the past 1 year" and the cyber audit observation against Standard 1 under the Protect: Awareness and Training header.

A good answer reports the measure as its formula defines it, supplies both evidence fields, and takes the cadence from both places it is written: the PR.AT Standard at §3.2, p. 63, says such programmes "shall be conducted on a periodic basis", and the periodic-compliance table fixes the interval at row 9 — PR.AT.S1, all REs, annually.

The answer that fails is a workforce-wide completion percentage. The measure is scoped to information system security personnel; a workforce denominator produces a different figure, and at a 100% target carrying 5% of the index the substitution moves the score. The second is a definition of that population assembled at reporting time and different from last year's, making the year-on-year movement an artefact of the denominator.

Authorisation, report, retention

Show me the authorisation for the testing

Where the testing was performed by a CERT-In empanelled auditing organisation, its conduct is governed by CISG-2025-02, Version 1.0, 25 July 2025, whose §4 names such organisations among its audiences. §13.2.7(ii), p. 50:

"Specific written permissions must be obtained from the auditee organization before conducting tests that involve survivability failures, denial-of-service (DoS), process testing, or social engineering."

A good answer is a document specific to social engineering, signed on the auditee side, dated before the campaign window opened, and naming the population in scope. §15.2.2(iii) makes that population part of the authorisation: such tests "must only target group of employees explicitly included within the agreed audit scope".

The answer that fails is the master services agreement. A general permission to test is a permission to test; the paragraph asks for specific written permission for this class of test. The second is a rules-of-engagement document dated after the first send: "before" is in the clause, and the timestamps are in the mail logs.

Show me the report, and confirm no individual is identified in it

§15.2.2(iii), pp. 55–56, fixes the form the result takes. Testing that targets general staff "must utilize anonymized or statistical techniques—ensuring no individual is personally identified or penalized. The purpose is to evaluate overall awareness and the effectiveness of security processes, not to single out individuals."

A good answer is a report at population and cohort level — rates by department, role band, campaign and over time — answering the awareness question without naming anyone.

The answer that fails is the appendix of clickers. It sits against a clause requiring anonymized or statistical techniques. The second is a cohort cut fine enough to identify: a two-person team's click rate is a name written as a percentage. The third is any trace that the list was circulated to line managers.

Show me your retention position over the underlying dataset

A report can be anonymised while the dataset behind it is not: a simulation produces a target list, timestamps and an outcome per recipient, keyed to identified individuals. The Digital Personal Data Protection Act, 2023 (Act 22 of 2023) grounds an employer's processing at s.7(i), the legitimate use "for the purposes of employment or those related to safeguarding the employer from loss or liability". s.8 runs against the data regardless: s.8(5) reasonable security safeguards, s.8(7)(a) erasure "as soon as it is reasonable to assume that the specified purpose is no longer being served".

A good answer names where the identified dataset sits and who holds it, the purpose it is retained for, when that purpose is served, and what follows. What the programme keeps is the aggregate, which does not need the names.

The answer that fails is "the testing firm has it", with no purpose, no period and no erasure trigger, when s.8(7)(a) is drawn against the specified purpose rather than the location of the file. The second is indefinite retention of named click data described as necessary for trend analysis. The third is an anonymised report over a platform record still keyed to employee IDs.

What to hold before you are asked

Six artefacts answer all eight questions, each assembled before an audit is scheduled rather than during it.

  1. The paragraph, by entity type and date — with the level, for a UCB.
  2. Coverage per named cohort, each with its denominator and its dates.
  3. An evaluation result that is not the delivery record.
  4. The repository, current as at today.
  5. The written authorisation, dated before the campaign, naming the population.
  6. The report at population level, and a retention position over the dataset beneath it.

None of this makes a programme more effective. It makes an effective programme provable, a different property, and the only one an audit can see.

About the author

Yash Kadakia, CERT-In Empanelment Since 2008

Founder & Chief Technology Officer

Founded Security Brigade in 2006 with the thesis that security assessment quality should be structural, not dependent on individual testers. 16+ years building platforms, teams, and methodologies that make enterprise security consistent.