Security awareness
The core programme for all staff: phishing, social engineering, credentials, data handling and — most importantly — how to report something without being blamed for it.
Training & Awareness
Training people remember on a bad day.
Annual click-through training changes nothing and everybody involved knows it. What changes behaviour is a session built around your systems, your data and the things your staff are actually asked to do.
RoleBased curriculum
LivePhishing simulation
Hands-onDeveloper labs
On-siteor remote
Why most security training fails
The standard programme is a generic video, an annual deadline and a completion percentage reported to an auditor. It satisfies a control. It does not change what anybody does, because it was not designed to — it was designed to be evidenced.
Training works when it is specific. A finance team learns far more from a walkthrough of a real invoice-redirection attempt against a company like theirs than from a module about "social engineering". Developers learn more from finding an authorisation flaw in code that looks like their own codebase than from a slide listing the OWASP Top 10. Executives engage with a briefing about what happened to a peer organisation and what the board was asked in the aftermath.
We build sessions from real material: findings from assessments we have run, attacks we have seen against organisations in your sector, and the systems your people actually use. It takes more preparation than playing a video, and it is the only version that produces a measurable change in how people behave when something looks wrong.
Coverage
Programmes we run
Delivered on-site across Tamil Nadu and remotely across India. Sessions are sized to the audience, from a one-hour board briefing to a two-day developer workshop.
Phishing simulation
Realistic campaigns run against agreed populations, reported in aggregate with a follow-up session. Measured on reporting rate, not just click rate, because reporting is the behaviour that actually helps.
Secure coding for developers
Hands-on labs in your languages: authorisation, injection, cryptography, secrets and dependency risk, using vulnerable code that resembles your own.
Cloud security fundamentals
For engineering and platform teams: identity, permission design, secrets, logging and the configuration mistakes that cause most cloud incidents.
Incident response drills
Tabletop exercises for the people who would actually be in the room, run against a scenario relevant to your business, with the decision points made explicit.
Compliance and privacy awareness
ISO 27001, DPDP Act and GDPR obligations translated into what each role must do differently, which is the only version anybody retains.
Executive and board briefings
Ninety minutes on the threat landscape for your sector, your current position and the questions a director should be asking.
Role-based modules
Targeted sessions for finance, HR, support and administrators — the roles that are attacked specifically because of what they can access.
Approach
How a programme runs
Most clients start with a baseline simulation and an all-staff session, then add role-based modules over the following quarter.
-
01 · Baseline
A phishing simulation before any training, to establish where you actually are. The result is reported as a number, never as a list of names.
-
02 · Design
Curriculum built from your systems, your sector’s real incidents and findings from your own assessments where you are happy for them to be used.
-
03 · Deliver
Live sessions, on-site or remote, with real material and time for the questions people only ask once they trust the room.
-
04 · Practise
Developer labs, tabletop drills and follow-up simulations, because a single session is an event rather than a programme.
-
05 · Measure
Reporting rate, time to report, repeat susceptibility and lab completion — measures that indicate behaviour rather than attendance.
-
06 · Sustain
Short quarterly refreshers and onboarding material for new starters, so the position does not decay back to where it started.
Run against recognised standards
- ISO 27001 A.6.3Awareness, education and training
- DPDP Act & GDPRPrivacy obligations by role
- OWASPSecure coding curriculum
- NIST CSFAwareness and training outcomes
Deliverables
What you actually receive.
The report is the product. If it cannot be acted on by a developer and understood by a director, we have not finished.
Live sessions
Delivered by practitioners who do the testing, not by trainers reading a deck.
Simulation results
Aggregate reporting with trend over time, and never a list of individuals to be disciplined.
Training evidence pack
Attendance, content and outcomes documented in the form an ISO 27001 auditor expects.
Reusable lab material
Vulnerable code and exercises your team keeps, for onboarding new developers.
Quarterly refreshers
Short sessions that hold the baseline rather than letting it decay.
Is this for you?
Talk to us if any of these are true.
If none of them are, say so on the call and we will tell you honestly whether this is the right piece of work — or point you at the one that is.
Book a scoping call- You are certified and need training evidence that is more than a completion report.
- Someone in finance nearly paid a fraudulent invoice.
- Your developers are shipping fast and have never had security training in their own stack.
- You have an incident response plan nobody has ever rehearsed.
- Your board has started asking questions and does not have the context to interpret the answers.
How we work
Six steps, and no surprises.
The same engagement model applies to every piece of work we take on, so you always know what happens next.
01
Scope
A 30-minute call, then a written scope: what is in, what is out, what we need from you and what it costs. Nothing starts before you sign it.
02
Authorise
Rules of engagement, testing windows, escalation contacts and a signed authorisation. Out-of-hours windows where production cannot take the load.
03
Test
Automated coverage first, then manual testing where judgement is required. Critical findings are reported the day we confirm them, not at the end.
04
Report
One report a developer can act on and an executive can read, with evidence, reproduction steps, business impact and a fix for every finding.
05
Remediate
A walkthrough call with your engineers. We answer questions on the fix, not just the finding.
06
Retest
A free retest cycle to confirm the fixes hold, and a clean summary you can hand to a customer, auditor or board.
Questions
Security Training — answered.
The questions clients actually ask during scoping. If yours is not here, ask it directly.
Do you run training on-site?
Yes. We deliver on-site across Coimbatore, Chennai and Tamil Nadu, and travel elsewhere in India for larger programmes. Remote delivery works well for awareness and executive sessions; developer labs and incident response drills are noticeably better in a room together, so we recommend on-site for those where it is practical.
How do you run phishing simulations without damaging trust?
Two rules, and we do not bend them. Results are reported in aggregate, never as a list of individuals — the moment people believe a simulation is a trap that gets them into trouble, they stop reporting real incidents, which is precisely the behaviour you need. And every simulation is followed by a session explaining what the campaign was, what the signals were and what to do next time. The measure that matters is how many people reported it, not how many clicked.
Is the developer training language-specific?
Yes, and it needs to be. Labs are built in the languages and frameworks your team actually uses, with vulnerable code that resembles your own patterns. Generic secure-coding training in a language nobody on the team writes is close to worthless. We cover the major stacks in common use — Java, .NET, JavaScript and TypeScript, Python, PHP, Go and mobile platforms.
Will this satisfy our ISO 27001 auditor?
Yes. We provide the evidence pack auditors ask for under Annex A control 6.3 — content, attendance, dates and outcome measures. Auditors have become noticeably more interested in whether training is effective rather than whether it happened, so the simulation trend data is often the more useful half of the pack.
How large can a session be?
Awareness sessions work well up to about eighty people; beyond that we run multiple sittings, because a session nobody asks questions in is a video with extra steps. Developer labs are capped at twenty so everyone gets hands-on time. Executive briefings are typically six to fifteen people.
Next step
Get a written scope and a fixed price.
A 30-minute call, then a scope document with what is in, what is out and what it costs. No obligation, and no charge for the conversation.