Design a phishing campaign you could defend to HR

applied · 80 min · Objective 5.6

Task

Design a phishing simulation programme end to end: the pretexts, the control group, the metrics, the no-blame communication and the follow-up. This lesson has no short lab because the real exercise needs colleagues who consented to be measured, and a campaign run against yourself proves nothing about behaviour. Designing it is the part a candidate is actually asked to get right.

Steps

  1. Write /tmp/campaign.md starting with the objective, stated as a behaviour rather than a score: what you want people to DO differently in six months.
  2. Define the metrics and put report rate first: report rate, time to first report, click rate, credential submission rate. Say which one you would take to the board and why it is not the click rate.
  3. Design three pretexts of increasing difficulty, and write the ones you are RULING OUT with the reason — fake bonuses, fake redundancies, fake disciplinary notices. Cruel pretexts produce distress, lasting mistrust of the security team, and an HR problem.
  4. Design the control group: who does not receive the simulation, so you can tell whether a change in behaviour came from your programme or from something else.
  5. Write the no-blame communication: what is said before the programme starts, what happens when somebody clicks, and what explicitly does NOT happen. Then write the escalation path for somebody who clicks repeatedly, which is a support conversation rather than a punishment.
  6. Design the reporting mechanism and the response to a report, including what a reporter is told afterwards.
  7. Finally, write the consent and communication position you would take to HR and to the works council or staff representatives, and what data you would and would not retain about individuals.

Verify

python3 - <<'PY'
import re
t=open('/tmp/campaign.md').read().lower()
need={'report rate first':'report rate',
      'time to report':'time to (first )?report',
      'control group':'control group',
      'ruled-out pretexts':'rul(e|ing) out|would not use|excluded pretext',
      'no-blame':'no.blame|not be punished|no punishment',
      'repeat clicker path':'repeat|again|support conversation',
      'consent/hr':'consent|hr|works council|staff rep',
      'data retention':'retain|retention|individual data'}
missing=[k for k,p in need.items() if not re.search(p,t)]
print('elements present:',len(need)-len(missing),'of',len(need))
assert not missing, 'missing: '+', '.join(missing)
i_rep=t.find('report rate'); i_click=t.find('click rate')
assert i_rep>=0 and (i_click<0 or i_rep<i_click), \
    'click rate is presented before report rate - the programme is optimising the wrong number'
print('report rate leads the metrics')
PY
grep -ciE "six months|behaviour|do differently" /tmp/campaign.md

The ordering assertion is deliberate and is the lab's central claim: report rate must appear before click rate in your own document. A programme that leads with click rate optimises for people not clicking, which is achieved by sending easier simulations; a programme that leads with report rate builds a detection capability out of the workforce.

Notes

The ruled-out pretexts and the HR position are what make this defensible. Every organisation that has run a fake-bonus simulation has learned the same lesson publicly, and the damage is not to the campaign — it is to the security team's standing, which is the thing the whole programme depends on.

This is an independent study companion for CompTIA Security+ SY0-701 and is not produced by or endorsed by CompTIA.