Phishing Simulation Services in India: Process, Metrics and Cost

The average click rate for untrained employees sits at roughly 33 percent. After a year of regular simulation and training, organisations typically get that under 5 percent. Those two numbers are why phishing simulation exists as a service category.

They are also why most programmes stall. A team runs a campaign, sees a click rate fall, declares progress and stops. Click rate is the easiest metric to move and the weakest predictor of whether your organisation would survive a real campaign. This post covers how phishing simulation services actually work, which metrics matter, and what determines the cost of running one properly.

What a phishing simulation programme involves

A simulation is not a single email blast. A programme has four moving parts that run continuously rather than once.

Baseline campaign. An initial simulation sent without warning, to establish where you actually are. Announcing it in advance produces a flattering number and no useful data.

Scenario design. Templates built to match plausible threats against your organisation rather than generic bait. For an Indian finance team that might be a vendor payment change request. For an engineering team, a fake single sign on prompt. Realism is what makes the exercise diagnostic.

Delivery and measurement. Campaigns sent in waves across departments, with tracking on delivery, opens, clicks, credential submission and reports.

Training response. Targeted training triggered by behaviour, delivered close to the moment of the click, when it is most likely to land.

The programme then repeats at a cadence, usually monthly or quarterly, with scenario difficulty increasing as performance improves.

The metrics that actually matter

Four numbers tell you the truth. Most reports show only the first.

Click rate

The percentage of recipients who clicked the link. Useful as a baseline and easy to move, which is exactly why it should never be reported alone. A falling click rate can mean genuine improvement, or it can mean your scenarios got easier.

Report rate

The percentage who proactively reported the email to your security team. Report rates across industries typically range from 9 to 29 percent. This is the metric that reflects active defence rather than passive avoidance. An employee who deletes a phishing email protects themselves. An employee who reports it protects everybody.

Resilience ratio

Report rate divided by click rate. A ratio above 3:1 indicates a genuinely strong security culture. This single figure resists the gaming that click rate invites, because you cannot improve it by making scenarios trivially easy: easy scenarios lower clicks and lower reports together.

If you report one number to your board, report this one.

Credential submission rate

The percentage who not only clicked but entered credentials on the landing page. This is the number closest to real loss. A high click rate with near zero submission is a different risk profile from a moderate click rate with frequent submission, and the two need different training responses.

These are global figures. Treat them as directional for an Indian organisation rather than as a target your board should hold you to, because sector, language mix and email culture all shift the baseline.

Designing scenarios that teach rather than trick

There is a line between a simulation that builds capability and one that damages trust. Programmes cross it when they use bait that is cruel rather than realistic: fake bonus announcements, fabricated layoff notices, false news about a colleague.

Those campaigns produce high click rates and an angry workforce, and the second effect outlasts the first. Employees who feel tricked stop reporting, which destroys the metric that actually matters.

Good scenarios mirror what attackers genuinely send to organisations like yours. Mapping them to MITRE ATT&CK initial access techniques keeps the programme anchored to real adversary behaviour rather than to whatever gets the highest click rate. Realistic and difficult is the goal. Humiliating is not.

The India specific dimension

Three things shape phishing programmes for Indian organisations in ways global templates miss.

Language and register. Multilingual workforces and the specific register of Indian corporate email mean templates written for a US office read as obviously foreign. Local phrasing raises realism, which is the point.

Vendor payment fraud. Business email compromise targeting vendor payment changes is a persistent pattern against Indian finance teams. Any programme covering an organisation with a payables function should include this scenario, because it is where the largest single losses occur.

Reporting obligations. Where a phishing incident results in an actual compromise, the CERT-In six hour reporting clock applies. A simulation programme is a reasonable place to rehearse that path, and continuous monitoring is what makes meeting it realistic, since the report to your security team is the first step in the same chain that ends in a regulatory notification.

For NCR organisations specifically, the concentration of IT services and BPO operations means large distributed workforces where email is the primary interface with clients. Scale makes both the exposure and the training logistics harder.

What drives the cost

Public pricing for phishing simulation in India is thin, and any firm quoting a rate before understanding your scope is guessing. Rather than a number that would not survive contact with your environment, here is what actually moves the price.

Employee count and campaign frequency. Most commercial models price per user per year, with frequency as a multiplier. A quarterly programme costs materially less than a monthly one.

Scenario customisation. Off the shelf template libraries are cheap. Custom scenarios built around your vendors, your systems and your internal language cost more and produce better data.

Training depth. Automated micro training triggered on click is the low cost option. Facilitated sessions for high risk groups such as finance and executive assistants cost more and are usually worth it for those groups specifically.

Reporting and integration. Board level reporting, integration with your ticketing system, and a real report button in your mail client add setup effort.

Whether it is bundled. Phishing simulation as part of a broader offensive security programme usually costs less per exercise than buying it standalone, because scenario design shares research with the red team work.

Ask any provider for pricing broken into setup, per user licensing and services, so you can see what you are actually buying.

How to tell a good programme from a box tick

Questions worth asking a provider:

• Do you report resilience ratio, or only click rate?
• Who writes the scenarios, and will they be customised to our organisation?
• What happens after somebody clicks, and how quickly?
• How do you handle repeat clickers without creating a punishment culture?
• Can you demonstrate the programme feeding into our incident response process rather than sitting beside it?

A provider who cannot answer the first question is selling a mailing tool.

Where SecureRoot fits

SecureRoot runs phishing simulation as part of our offensive security practice, which means scenario design draws on the same research as our red team engagements. Templates reflect techniques we see used against Indian organisations rather than a generic library, and the results feed your incident response process rather than a standalone dashboard.

We also report resilience ratio by default, because click rate on its own tells your board a story that may not be true. See the full range on our services page.

Frequently asked questions

How often should we run phishing simulations?

Monthly or quarterly, and the cadence should come from exposure rather than from a calendar habit. Below quarterly there is not enough repetition for behaviour to change: the gap between campaigns runs longer than the window in which the last lesson is still live, so every wave reads like a fresh baseline. Above monthly, fatigue sets in and people start treating every unusual message as a test, which trains suspicion of the medium rather than judgement about the signal. Split it by role. Finance, payables and executive assistants handle the external mail that vendor payment fraud arrives on, so a monthly rhythm for those groups and quarterly for everybody else is usually the right shape. Raise scenario difficulty as performance improves. Holding difficulty flat while reporting a falling click rate produces a number your board will believe and an attacker will not have to work around.

Should we tell employees the programme is running?

Tell them the programme exists; never announce an individual campaign. Those are two different disclosures, and conflating them is where most programmes lose either trust or diagnostic value. Announcing the programme sets the frame: this is a measurement exercise the organisation runs on itself, results are not disciplinary, and reporting is the behaviour being asked for. That frame is what lifts report rate, and report rate is the half of the resilience ratio you cannot manufacture by making scenarios easier. Announcing a specific campaign destroys the measurement instead. You get a flattering click rate, no read at all on credential submission, and a baseline the next quarter cannot be compared against. Put the programme in your acceptable use or awareness policy, say it at induction, and name the security contact people should forward suspicious mail to. Then send the campaigns unannounced, and report what they found.

What should we do about repeat clickers?

Treat it as a training and role risk question, never a disciplinary one. Punitive responses suppress reporting, and reporting is worth more to you than the clicks cost. Start by separating signal from exposure. Somebody in accounts payable who handles hundreds of external mails a week and clicks a well built vendor payment change request is telling you something about scenario quality and about process design. Somebody in a low exposure role clicking generic bait is telling you about judgement. The first calls for a control change: out of band verification on bank detail changes, dual approval on payee edits. The second calls for training delivered close to the click. Track credential submission separately, because a repeat clicker who never submits has a different profile from one who does. Where submission repeats across waves, move that group to a facilitated session rather than escalating the individual.

Is phishing simulation the same as a red team engagement?

No. Simulation measures workforce behaviour at scale across many recipients, while a red team engagement uses social engineering as one route toward a specific objective, testing detection and response rather than aggregate awareness. The outputs differ accordingly. A simulation gives you rates: click, report, resilience ratio and credential submission, sliced by department and tracked across waves. A red team gives you a narrative of how far an operator got, what your defenders saw along the way, and a proof of concept for each finding. Organisations commonly run both, and the data flows one way usefully: simulation results tell you which pretext and which department a red team should start from, since there is little value in testing detection along a route nobody would take. At SecureRoot both sit inside the same offensive security practice, so scenario design draws on the same adversary research.

Does phishing simulation help with our ISO 27001 or SOC 2 position?

Yes. Both expect security awareness activity, and a documented programme with measured outcomes is stronger evidence than an annual slide deck with an attendance list. ISO/IEC 27001:2022 treats awareness as part of the management system rather than a single tick box, so an auditor looks for a defined cadence, evidence that it ran, and evidence that the results changed something. A campaign log carrying click rate, report rate and resilience ratio by quarter answers all three in one artefact. For SOC 2 the same reporting maps to the control activity and monitoring criteria, and the board pack you already produce usually serves as audit evidence unchanged. Two practical points. Keep the raw campaign exports, not only the summary, because auditors sample. And record what you did after each wave, the training triggered and the process changed, since evidence of response is what separates a programme from a mailing exercise.

Next step

If you are running simulations already and only seeing click rate, or have not started and want a baseline, we can scope a programme around your headcount and risk profile.

Book a 30 minute scoping call, or call +91 73071 48874.