Social Engineering & Phishing Simulation

Every technical control you own can be intact while someone types their credentials into a page we built that morning.

We run controlled phishing campaigns against your own people, using pretexts built from what is genuinely discoverable about your organisation. The point is not to catch anyone out. It is to find out which pretexts work, which teams are exposed, and whether anybody reports it — because reporting rate matters more than click rate.

Hands using a phone in low light
The message that works looks exactly like the ones that are real
Who this is for

Four reasons this gets commissioned

Someone already fell for one

A real attempt landed and you need to know how wide the exposure is rather than treating it as one person’s mistake.

Training happens but nothing is measured

Staff complete an annual module and everyone assumes it worked. Nobody has tested whether it changed behaviour.

A framework or insurer requires it

Simulated phishing is an expected control, and you need it run properly and evidenced.

You want to test the reporting path

Not whether people click, but whether the ones who notice know how to raise it and what happens when they do.

What we run

Campaigns built for your organisation, not a template library

Open-source reconnaissance

What an attacker can learn about your people and structure from public sources. This alone is frequently the most uncomfortable part of the report.

Credential harvesting

Messages leading to a controlled page that records the attempt. Submitted credentials are never stored in usable form.

Pretext and lure design

Scenarios drawn from your actual context — the systems you use, the language you use internally, the time of year.

Targeted campaigns

Higher-effort pretexts aimed at the smaller group whose access would matter most, run separately from the broad campaign.

Attachment and action lures

Testing whether people will open, enable or approve something, which is often the step that matters more than the click.

Detection and response testing

Whether your own controls flagged the campaign, and what your team did with it if they did.

How we work

Agreed in advance, run quietly, debriefed openly

01

Rules of engagement

Who is in scope, who is excluded, what pretexts are off limits, and who inside your organisation knows it is happening.

02

Reconnaissance and build

We gather what is publicly available and construct pretexts from it, then agree them with you before anything is sent.

03

Run

Campaigns are delivered and monitored. Anyone who submits credentials sees a short explanation immediately rather than being left wondering.

04

Report and debrief

Results by group and pretext, what your controls caught, and a session with staff that treats the exercise as instruction rather than an accusation.

Deliverables

What you receive

  • Results by campaign and group — click, submission and reporting rates, with reporting treated as the headline measure
  • The reconnaissance picture showing what an attacker can assemble about your organisation without touching it
  • An assessment of which pretexts worked and why, which is the part that informs training
  • What your technical controls caught, and what passed through them unremarked
  • A staff debrief delivered without naming individuals, and recommendations for the awareness programme
Scoping

Timing and cost

Cost depends on how many people are in scope, how many campaigns you want, and how much effort goes into targeted pretexts as against a broad send. Whether this runs once or on a recurring basis also changes the shape of it.

We do not publish packages or rates. Every engagement begins with a short call, followed by a written scope and a fixed price for that scope before any work starts.

What we need to scope it

Roughly how many staff, whether you have run simulations before, whether you want targeted campaigns as well as broad ones, and who internally would be told.

FAQ

Common questions

Will you name the people who clicked?
Not unless you ask us to, and we would push back if you did. Results are reported by group. Naming individuals reliably produces one outcome: people stop reporting incidents because they are afraid of being on the list, which leaves you materially worse off than before the exercise.
What happens to credentials people submit?
They are never stored in usable form. We record that a submission occurred, not what was typed. That is agreed in writing before anything is sent.
Is this legal, and do we need consent?
It is lawful when the organisation authorises testing of its own systems and staff, which is why rules of engagement are signed before we start. Employment and privacy considerations vary by province and by what your contracts and policies already say — worth a word with HR, and we will flag anything that looks like it needs it.
Do you do phone or physical social engineering?
Our simulation work is message-based. Voice pretexting and physical access attempts are a different discipline and we would rather point you to someone who specialises in them than stretch a claim.
Should we tell staff beforehand?
Telling everyone the week before measures nothing. Announcing that simulations will happen at some point during the year, without saying when, keeps the exercise honest and tends to sit better with staff and with works councils. We will discuss which fits your culture.
How often should this run?
Once tells you where you stand. Repeating it is what shows whether anything changed, and the second round is usually more informative than the first. Frequency is set with you rather than sold as a fixed cadence.

Tell us what prompted this

A real incident, a framework requirement, or simply not knowing how your people would respond. Thirty minutes and we will tell you what a useful campaign would look like.

Start with a scoping call