Cyber security awareness: what a programme can and cannot change

Someone has to commission it, budget it and evidence it. So the useful question is not what cyber security awareness means. It is what a programme actually changes inside an organisation, what it leaves untouched, and what an auditor will accept as proof.

The short answer is that an awareness programme changes organisational behaviour. It changes whether a suspicious message gets reported and how quickly, whether a process holds when someone is under pressure to skip it, and whether the organisation can produce a year of coverage on demand. It does not reliably change what any particular person knows, and it is not judged on that.

Training and measurement are two obligations, and the instruments keep them apart

Read the Indian instruments in order and the same split appears in each: an obligation to train, and a separate obligation to find out whether the training worked.

The RBI Cybersecurity, Technology: Risk, Resilience and Assurance Framework Directions, 2026, all issued 31 July 2026, draw it in adjacent paragraphs. For commercial banks, Section BB ¶203 makes awareness programmes "mandatory for all new recruits", with annual training for lower and middle management, and ¶204 extends annual training to all Board members and Senior Management. ¶202 stands on its own: "The bank shall evaluate the awareness level of employees periodically."

For NBFCs the same split runs across Section C.12. ¶35 requires the ongoing information security training and awareness programme. ¶36 requires "a formal mechanism to measure and track the effectiveness of such training through periodic assessments or testing", together with an "up-to-date repository of the training and awareness status of all users".

SEBI's Cybersecurity and Cyber Resilience Framework does it across two parts of one circular. PR.AT establishes mandatory awareness programmes on a periodic basis. GV.RM Guidelines item 1(e) requires regulated entities to "periodically assess level of employee cybersecurity awareness, for e.g., through phishing test success rate".

The consequence for anyone commissioning is direct. A simulation is not a training programme, and neither substitutes for the other. A year of courseware with no measurement answers one paragraph and leaves the adjacent one open. A quarterly phishing test with nothing behind it produces a number and leaves the workforce with nothing to have learnt.

Instrument and provision	Obligation	What it requires
RBI 2026 — Commercial Banks, ¶203 and ¶204, pp. 47–48	Train	Awareness programmes mandatory for all new recruits; annual training for lower and middle management; annual training for all Board members and Senior Management
RBI 2026 — Commercial Banks ¶202, Payments Banks ¶201, Small Finance Banks ¶201, Credit Information Companies ¶197	Measure	Evaluate the awareness level of employees periodically
RBI 2026 — NBFCs, ¶35, p. 19	Train	An ongoing information security training and awareness programme for all users
RBI 2026 — NBFCs, ¶36, p. 19	Measure	A formal mechanism to measure training effectiveness through periodic assessments or testing, and an up-to-date repository of the training and awareness status of all users
RBI 2026 — Urban Co-operative Banks, ¶156, Section H, p. 39 (Chapter V, binding Level III and Level IV UCBs)	Train	Mandatory awareness programmes for new recruits, and web-based quiz and training for lower, middle and upper management every year
SEBI CSCRF v1.0, 20 August 2024, §3.2 PR.AT, p. 63, guidelines pp. 103–104; cadence at periodic-compliance table row 9	Train	Mandatory awareness programmes on a periodic basis; the compliance table states the cadence as Annually for all REs
SEBI CSCRF v1.0, GV.RM Guidelines item 1(e), p. 87, standards column GV.RM.S3	Measure	Periodically assess the level of employee cybersecurity awareness, "for e.g., through phishing test success rate". Applies to all REs except small-size, self-certification REs
CERT-In CISG-2025-02, §13.2.7(ii), p. 50	Conduct	Specific written permissions from the auditee organisation before process testing or social engineering
CERT-In CISG-2025-02, §15.2.2(iii), pp. 55–56	Conduct	Testing of general staff uses anonymised or statistical techniques, with no individual personally identified or penalised

The rule that decides what a programme measures

How the measurement is carried out is not left to taste. CERT-In's Comprehensive Cyber Security Audit Policy Guidelines, CISG-2025-02, Version 1.0, 25 July 2025, apply at §4 to CERT-In empanelled auditing organisations. §13.2.7(ii), p. 50, requires specific written permission before process testing or social engineering. §15.2.2(iii), pp. 55–56, then governs the test itself.

"Social engineering and process testing should be conducted in a controlled and ethical manner. When targeting general staff (e.g., untrained or non-security personnel), such testing 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."

Read as a design brief rather than as a restriction, the shape of the whole programme follows from that sentence. The unit of analysis is the population. The output is a distribution, not a list. And the finding worth having is a process that did not hold, rather than an employee who did not.

There is a second reason it holds, independent of the clause. A programme that penalises the people it measures degrades its own measurement. The behaviour it most wants is someone raising a hand about a message they are unsure of, and that is exactly what the prospect of appearing on a list a manager reads suppresses.

What a programme can change

Four things move, and all four are organisational rather than individual.

Whether anything gets reported, and how quickly. This is the most responsive number in the set, and it depends less on the workforce than on the route. A monitored mailbox or a report button, a named owner for what arrives, and an acknowledgement back to the person who sent it. A report rate has nowhere to go without one. Building that route is internal work, and it is usually the single change that moves a programme most.

Whether a process holds under pressure. A service desk that resets credentials without verifying identity, or a finance team that changes payee bank details on an emailed instruction, are procedural failures that a simulation surfaces as a measurement. CISG-2025-02 lists Process Security Testing among its engagement types at §6, pp. 14–17, and §15.2.2(iii) names "social engineering and process testing" together. The result is a statement about a procedure, and a procedure can be rewritten.

Coverage. Who has been through the programme, when, and which cohorts were treated separately. The instruments are specific about cohorts: new recruits and lower and middle management at ¶203, Board and Senior Management at ¶204, upper management for the UCBs that carry ¶156. Coverage is the part of a programme most often assumed and least often evidenced.

The evidence itself. NBFC ¶36 asks for a repository, not a report. A programme that produces a quarterly deck and no retained artefact has satisfied a meeting rather than a clause.

What it cannot change

A well-built pretext aimed at a real business process will be acted on by some part of any workforce. Programmes that set out to reach zero end up measuring the difficulty of their own pretexts rather than the awareness of their population. The design question is what happens in the minutes after someone clicks, not how to prevent every click.

It cannot produce a defensible ranking of individuals. Where general staff are tested, §15.2.2(iii) requires anonymised or statistical techniques. Beyond the rule, a click is one event, under one pretext, on one day, in one inbox. It is a data point inside a population measure. It is not a performance record.

It cannot stand in for a technical control. A pretext that reached an inbox is also a result about the gateway, and treating the human response as the only remediable finding wastes half the exercise.

And it cannot make two periods comparable on its own. Pretext difficulty, population composition and timing all move between campaigns. A rate that fell may be evidence of learning or evidence of an easier pretext, and only a series designed for comparison will tell you which.

What the programme is judged on

On organisational behaviour over time, and on the record of it. The commercial bank Direction names "extent of user awareness training" among the cybersecurity metrics a bank develops, at ¶194. NBFC ¶36 asks for the repository. SEBI states the requirement as periodic in the PR.AT Standard at p. 63 and fixes the cadence in the periodic-compliance table, row 9: "Cybersecurity training program (PR.AT.S1) — All REs — Annually". Both sit in the same circular, and a programme calendar should cite the table.

Two records come out of a programme, and they follow different rules. Training status is held per user, because ¶36 asks for the status of all users. Test results are held at population level, because §15.2.2(iii) requires that. Where the working data behind a test identifies people, the Digital Personal Data Protection Act, 2023 supplies both the ground and the limit: s.7(i) covers processing for the purposes of employment and for safeguarding the employer from loss or liability, and s.8(7)(a) requires erasure "as soon as it is reasonable to assume that the specified purpose is no longer being served".

If you are commissioning a programme, hold four things. A written authorisation naming the population, the channels and the window, per §13.2.7(ii). A cadence you can meet, cited to the instrument that sets it. A report route with an owner, built before the first campaign rather than after it. And a repository that shows coverage across the cohorts the clauses name. Asked at an audit what the programme changed, the answer you want to be able to give is a population trend and a set of processes that behave differently. Not a list of names.