Who may be in the target population of a phishing simulation

A phishing simulation needs a list of mailboxes before it needs anything else, and in an Indian organisation of any size that list is not the payroll. The service desk is outsourced. Collections runs through a BPO. Two engineering squads are contractors. All of them hold an address on the company's mail domain, all of them sit inside the same threat model, and none is an employee.

Two instruments speak to that population and they point in different directions, because they govern different activities. CERT-In's audit policy guidelines bound who an empanelled auditing organisation may target in a test. SEBI's CSCRF directs regulated entities to extend awareness training to those same outsourced staff. Both hold. Getting the population right means reading each instrument for the activity it governs.

The scope rule: what CISG-2025-02 says about who may be targeted

CERT-In's Comprehensive Cyber Security Audit Policy Guidelines, CISG-2025-02, Version 1.0, 25 July 2025, applies at §4 to CERT-In empanelled auditing organisations. §15.2.2(iii), pp. 55–56, sets the population rule in two sentences:

"Social engineering and process testing must only target group of employees explicitly included within the agreed audit scope. These tests must not involve external entities such as customers, business partners, vendors, or other third parties, unless specific written consent is obtained from the target organization."

Four phrases carry the rule.

• "group of employees" — the unit is a cohort, consistent with the same clause's requirement that testing "must utilize anonymized or statistical techniques—ensuring no individual is personally identified or penalized".
• "explicitly included" — inclusion is positive and written. A cohort is in the population because a document names it.
• "within the agreed audit scope" — that document is the scope, so the population is settled at scoping and not at campaign build.
• "unless specific written consent is obtained from the target organization" — there is a route for external entities. It is specific, it is written, and it comes from the target organisation.

That route is the one most often misread. The consent §15.2.2(iii) describes is organisational: the auditee authorises the inclusion. A separate authorisation at §13.2.7(ii), p. 50, requires that "Specific written permissions must be obtained" from the auditee organisation before tests involving "process testing, or social engineering". Two documents, both from the client, both before execution.

What the sector instruments ask of the same people

SEBI's Cybersecurity and Cyber Resilience Framework (SEBI/HO/ITD-1/ITD_CSC_EXT/P/CIR/2024/113, 20 August 2024, Version 1.0) opens PR.AT at p. 63 on an objective that reaches past the payroll: personnel and partners "are provided cybersecurity awareness education, and are trained to perform their cybersecurity related duties". Its standard items carry it to privileged users, third parties, senior executives and the Board. The PR.AT Guidelines, pp. 103–104, item 4, are more direct:

"REs shall conduct periodic training programs ... Wherever possible, this shall be extended to outsourced staff, third-party service providers, etc."

The RBI Directions, 2026 — six entity-specific Directions, all issued 31 July 2026 — draw the population differently by entity. Commercial Banks, ¶202, pp. 47–48: "The bank shall evaluate the awareness level of employees periodically." NBFCs use a wider term: at ¶35, p. 19, the programme is established "for all users", and ¶36 requires "an up-to-date repository of the training and awareness status of all users". Urban Co-operative Banks name management bands — ¶156, p. 39, requires "mandatory cybersecurity awareness programs for new recruits and web-based quiz and training for lower, middle, and upper management every year" — and ¶156 sits in Section H of Chapter V, which the applicability table at ¶4 binds to Level III and Level IV UCBs.

So the awareness population is drawn by role and by system access as often as by employment. An NBFC's repository is a repository of users; SEBI's training reaches outsourced staff wherever possible. The test population under CISG-2025-02 is drawn by employment and by the scope document. Across an outsourced estate those lines do not coincide.

Which instrument governs which activity

Read down the middle column and the split resolves. One row governs a test conducted by an auditor; the rest govern a programme the regulated entity runs itself. An organisation can be under a standing instruction to extend training to its outsourced staff and, in the same quarter, unable to put those staff into an auditor's test population until it has specific written consent for them.

Contractors, BPO staff and the outsourced service desk

The difficult population is not the customer or the business partner; the clause names those. It is the population that behaves like staff and is contracted like a vendor: the BPO agent on collections, the managed service desk, the contractor squad on the client's laptops. They read the client's mail on the client's domain, and an attacker phishing it reaches them regardless.

§15.2.2(iii) turns on the employment relationship and on the scope document, so the first artefact a programme produces is not a mailbox export. It is a cohort map: every population intended for the test, with the entity that employs it recorded against it. A mailbox on the client's domain establishes routing, not employment.

Where a cohort is employed by another entity, it enters the population by the route the clause provides — specific written consent obtained from the target organisation — and three conditions have to hold.

1. The target organisation has the standing to give it. The consent named in the clause is the auditee's. Whether the auditee can authorise testing against another entity's staff turns on the contract between them — the auditee's to establish and evidence, not something a testing firm may infer from the mail domain.
2. The consent is specific. A master services agreement permitting "security testing" in general terms is a different instrument from a document naming this cohort, this activity and this campaign window.
3. It is in place before execution, and it is retained. It belongs in the same file as the §13.2.7(ii) written permission; both are audit artefacts and both will be asked for.

The outsourced desk has a second consequence. Exclusion lists and escalation contacts must reach the third party's own incident channel as well as the client's, or the first suspicious-mail report lands with a duty manager who has been told nothing and a live simulation escalates as a real incident — a scoping failure that distorts the report-rate series for that cycle.

Testing an outsourced desk is a different test again. A vishing call to a desk that resets a credential on the strength of a story examines a procedure; CISG-2025-02 §6, pp. 14–17, scopes that work under item (x), Process Security Testing. The agent on the call is the instrument, not the subject: "The purpose is to evaluate overall awareness and the effectiveness of security processes, not to single out individuals."

The data-protection ground splits the same way. The Digital Personal Data Protection Act, 2023 (Act 22 of 2023) provides at s.7(i) a legitimate use "for the purposes of employment or those related to safeguarding the employer from loss or liability", closing on "a Data Principal who is an employee". Where a cohort sits outside that relationship, the ground for processing has to be established by the organisation commissioning the programme, and it is a separate question from the organisational consent §15.2.2(iii) describes. s.8(5) safeguards and s.8(7)(a) erasure apply to the click dataset either way.

What to settle before the campaign is designed

A programme, unlike a single campaign, answers this every cycle. A BPO floor turns over. A contractor engagement ends. A managed desk changes supplier. A population that drifts quietly between quarters produces a trend line measuring the roster rather than the organisation, and the consent behind a third-party cohort has a term of its own.

1. A cohort map of the intended population, with the employing entity recorded against each cohort.
2. An agreed audit scope naming the employee groups explicitly, at group level.
3. For every cohort outside those groups, the specific written consent from the target organisation, held before execution.
4. The §13.2.7(ii) written permission for the social engineering and process testing itself.
5. Exclusions and escalation contacts, extended to each third party's own desk.
6. The reporting form, agreed up front: population and cohort statistics, no individual identified or penalised.
7. A review point each cycle at which the cohort map and every consent are re-confirmed.

The population question is answered on paper before a campaign answers it, and the paper comes to two documents: the agreed audit scope naming the employee groups, and, for anyone outside them, the specific written consent from the target organisation. An organisation holding both for the current cycle can answer the auditor's version of the same question.