What an awareness evidence repository actually contains

The Reserve Bank's 2026 Directions for NBFCs carry a sentence most awareness programmes cannot answer on demand. Section C.12, Training, ¶36, p. 19: the NBFC shall maintain an "up-to-date repository of the training and awareness status of all users".

Read as a specification, that describes a thing rather than an activity. A repository has a population, a set of fields, a currency date and a retention rule. It exists before it is asked for.

Where the requirement comes from

¶35 and ¶36 sit together in Section C.12 of the RBI (NBFCs — Cybersecurity, Technology: Risk, Resilience and Assurance Framework) Directions, 2026, issued 31 July 2026 and in force on issuance.

"The NBFC shall deploy a formal mechanism to measure and track the effectiveness of such training through periodic assessments or testing. The NBFC shall also maintain an up-to-date repository of the training and awareness status of all users."

RBI (NBFCs) Directions, 2026, ¶36, p. 19. ¶35, immediately before it, requires an "ongoing information security training and awareness program for all users".

¶35 is the programme. ¶36 is two duties on top of it: a formal mechanism measuring whether the training worked, and a record of where every user stands. It names the acceptable methods — "periodic assessments or testing" — and attaches the words up-to-date to the record.

Those words separate a repository from a report. A quarterly pack is current on the day it is tabled and ages from there. Commercial banks carry a duty of that shape at ¶202, to "evaluate the awareness level of employees periodically". NBFC ¶36 adds custody on top: something has to exist, cover everyone, and be current when the question arrives.

What it has to contain

A population, and the rule that defines it

¶36 says "all users". That is a denominator, and a denominator is a decision somebody writes down: which categories count as a user of the information systems — permanent and fixed-term staff, contractors on the network, outsourced desks, privileged administrators, third-party personnel with access.

The definition sits beside the list, because a coverage figure means nothing without the population it was computed over, and so does the date that population was last reconciled against the record of joiners and leavers. Hiring moves the denominator on its own.

Coverage per cohort, against the cadence that cohort's clause sets

Cadence differs between regulators, and between cohorts inside one Direction. The cohort is the unit the repository counts in.

Cohort	Clause	Cadence	What the record shows
All users of an NBFC	RBI (NBFCs) ¶35–36	Ongoing, effectiveness measured through periodic assessments or testing	Status per user, and the test behind it
New recruits, commercial bank	RBI (CB) ¶203	Mandatory	Completion dated against the joining date
Lower and middle management, commercial bank	RBI (CB) ¶203	Annual	Share of the cohort trained in the last twelve months
Board and Senior Management, commercial bank	RBI (CB) ¶204	Annual	Dated attendance at a named session
Lower, middle and upper management, urban co-operative bank	RBI (UCB) ¶156, Section H — Chapter V, Level III and Level IV	Web-based quiz and training every year	Quiz completion per user, with the UCB's level
Employees of a SEBI regulated entity	CSCRF v1.0, §3.2 PR.AT, p. 63, Standard PR.AT.S1	Standard says "periodic"; periodic-compliance table row 9 says "Annually"	Dated delivery, against the one being reported to

A flat list of employees cannot answer that table: cadence, and so whether a user is inside coverage today, belongs to the cohort rather than to the person.

Dates

Four: the training event, the user's completion of it, the evaluation that followed, and the date the record was last updated. The fourth is what establishes up-to-date.

The method, and the level the result may claim

¶36 permits "periodic assessments or testing", and the two produce results of different kinds, so the record says which was used. A completion quiz gives a score attributable to the person who sat it. A campaign against general staff gives a rate over a population.

SEBI names the second as an example. CSCRF v1.0, GV.RM Guidelines item 1(e), p. 87, standards column GV.RM.S3, applicable to "All REs except small-size, self-certification REs (Mandatory)": REs "shall periodically assess level of employee cybersecurity awareness, for e.g., through phishing test success rate, etc." The obligation is the assessment; the phishing test is the illustration offered.

Results are then stored at the level the method permits: a score for a quiz; for a campaign, population figures carrying the cohort they cover and the difficulty of the pretext behind them, without which two quarters look comparable and are not.

The link back to the training round

¶36 measures the effectiveness "of such training", and effectiveness is a relation between two events. Each evaluation therefore carries the training round it follows, the interval, and the overlap between the trained and evaluated populations. Without it the repository holds two unrelated series.

Two records, not one

The specification above contains a structural problem. Training status is held per user. Evaluation results from a simulation are held at population level. Two records, two identity rules, two clocks.

Per user, because ¶36 asks for the status of all users, and a status not attributable to a named person is not that. The record carries identity by construction.

At population level, because of how the evaluation is conducted. CERT-In's Comprehensive Cyber Security Audit Policy Guidelines, CISG-2025-02, Version 1.0, 25 July 2025, govern social engineering and process testing by empanelled auditing organisations, at §15.2.2(iii), pp. 55–56:

"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."

A result returned under that rule has no user column. The same clause fixes who may be tested: such testing "must only target group of employees explicitly included within the agreed audit scope", excluding customers, business partners, vendors and other third parties unless specific written consent is obtained from the target organisation. Trained and tested populations can therefore differ, and the repository shows both.

The design failure is the merge. Writing a campaign outcome back onto a user row turns a population statistic into a per-user record of who failed a test — a different artefact from the one §15.2.2(iii) contemplates, and from the training status ¶36 asks for. Two records, joined on cohort and date, never on user identity.

How long each record lives

The Digital Personal Data Protection Act, 2023 — Act 22 of 2023 — reaches both records, separately. The ground on which an employer processes this data at all is s.7(i), the legitimate use "for the purposes of employment or those related to safeguarding the employer from loss or liability".

s.8(5) requires reasonable security safeguards, and the evaluation side is where they lapse: the raw campaign log behind a population rate is personal data about employees, held so that the rate can be computed from it.

s.8(7)(a) sets the erasure test: erasure "as soon as it is reasonable to assume that the specified purpose is no longer being served". Applied to each record separately, it gives two answers.

• Training status, per user. The purpose is evidencing that a named user's obligation was met, across the periods an auditor can ask about. It closes on a date the organisation can state.
• Evaluation results, per population. The statistical result has to survive, because the series is what shows effectiveness over time. The raw campaign data beneath it has served its purpose once the result is computed and checked: the shortest clock in the repository.

Which is one more field: the purpose each record is kept for, and the date it closes.

What an auditor's afternoon looks like

The test is not whether the repository exists, but what can be produced from it without notice. From one built to the specification above:

1. Coverage per cohort as at today, with the population definition and the last reconciliation date beside it.
2. The cadence each cohort is held to, and the clause that sets it.
3. Every evaluation in the period, with its date, its method, and the authorisation that preceded it. CISG-2025-02 §13.2.7(ii), p. 50: "Specific written permissions must be obtained from the auditee organization before conducting tests that involve ... process testing, or social engineering."
4. The training round each evaluation followed, and the retention decision on each record.

Reconstructed, and visibly so: attendance exported from three systems and de-duplicated by hand; a denominator recomputed from an HR extract of uncertain date; a click rate set beside last year's as though the campaigns were comparable; an authorisation that survives as an email thread. All of it can be assembled, given a week. None of it is a repository, and the reconstruction is itself the finding.

The expectation reaches SEBI-regulated entities in another form. Annexure-K, p. 166, Measure 3, "Security Training Measure [PR.AT.S1]", asks for "Details of the training/awareness sessions scheduled within the past 1 year", at a target of 100% and a weighting of 5%, for MIIs and Qualified REs, scoped to information system security personnel.

Most columns fill from systems the organisation already runs: the HR record, the training record, the access list. The one it cannot fill from the inside is the evaluation result. Where that testing is commissioned from a CERT-In empanelled auditing organisation, CISG-2025-02 sets the written permission that precedes it and the form the result takes coming back. Build the record so it can hold that result: cohort-tagged, dated, method beside it, no user column to fill.