Security awareness that changes behaviour rather than completion rates

Objective 5.6 in this course covers security awareness — CompTIA's scope note for it implements phishing training, anomalous behaviour recognition, user guidance, reporting, and monitoring. It is the last lesson of the course, and the applied lab for 5.6 designs the campaign rather than running one, for the reason set out below.

Why this matters

Domain 2 established that most intrusions begin with a person being persuaded to do something. This objective is the control for that, and it is the one most often implemented as a compliance exercise — an annual module, a completion percentage, and no measurable change in behaviour.

The exam reflects the better version. It asks about recognition and reporting rather than about training delivery, and the reporting half is the part that actually produces detections.

The lesson

Phishing campaigns, recognising a phishing attempt, and responding to one

A phishing simulation sends realistic but harmless phishing to your own staff and measures what happens. Done well it is the most useful measurement in the whole awareness programme; done badly it is resented and teaches nothing.

What to measure, in order of value:

1. Report rate — the proportion who reported it. This is the number that matters, and it is the one most programmes do not track. A reported phish is a detection: it tells the security team an attack is in progress, often within minutes, and lets them pull the message from every other mailbox.
2. Time to first report — how quickly. Minutes is a functioning early warning system; hours is not.
3. Click rate — the proportion who clicked. Useful as a trend, and the number organisations fixate on.
4. Credential submission rate — the proportion who went on to enter credentials. Materially worse than a click and worth separating.

What makes a programme work rather than breed resentment:

• No punishment for clicking. Punitive programmes suppress reporting, and reporting is the thing with operational value. An organisation where people hide mistakes is worse off than one where they raise them immediately.
• Immediate, brief teaching at the moment of the click, which is when the lesson lands.
• Realistic difficulty, varied over time. A simulation everyone spots measures nothing.
• Avoid cruel pretexts — fake bonuses, fake redundancies. They produce genuine distress, lasting mistrust of the security team, and in some places an HR problem.

Recognising an attempt: urgency, an unexpected request, a sender mismatch between display name and address, a link whose target differs from its text, a request to bypass a normal process, and any payment or credential request. Spelling errors are a weak signal and a poor thing to train on.

Responding to one is the part to teach explicitly, because the default instinct is wrong. The guidance is: do not click, do not reply, do not delete — report it, and leave it in place so the security team can examine it and find who else received it. If someone has already clicked or entered credentials: report immediately, change the password, and expect to be believed rather than blamed.

Anomalous behaviour recognition: risky, unexpected and unintentional

CompTIA splits the behaviours people should recognise — in themselves and in colleagues — into three.

• Risky behaviour — knowingly doing something insecure because it is convenient: sharing credentials, disabling a control, using an unapproved cloud service, emailing work to a personal account, plugging in an unknown device. The shadow IT motivation from Domain 2 applies: it usually signals that the sanctioned path is too slow or does not exist, so the response is to fix the path as well as to address the behaviour.
• Unexpected behaviour — activity that does not fit the person or the role: a colleague accessing systems unrelated to their job, working hours that do not match their pattern, downloading unusual volumes of data. This is the human-observable counterpart of the UEBA signals from Domain 4, and colleagues often notice first.
• Unintentional behaviour — honest mistakes: the email to the wrong recipient, the attachment that should not have been attached, the document shared with the wrong permissions, the screen left unlocked. Most data incidents are this category rather than malice.

The reason this is in the awareness objective rather than the monitoring one: technical controls detect what they were configured to detect, and people notice things no rule was written for. A workforce that knows what "off" looks like and has a frictionless way to say so is a sensor network, and it covers the gaps between the tools.

User guidance and training: policy, situational awareness, insider threat, password management

The topics CompTIA names, each with what it is actually for:

• Policy and handbooks — what the rules are, where to find them, and the acknowledgement that establishes people knew. The Domain 5.1 documents made usable.
• Situational awareness — recognising that the current situation is unusual: an unfamiliar person in a secure area, a request that does not follow the normal process, a call that creates urgency. This is what defeats vishing and business email compromise, which technical controls largely cannot see.
• Insider threat — what it looks like and how to raise a concern about a colleague, which needs a confidential route and an explicit assurance that good-faith reports are protected. Without that, people say nothing.
• Password management — the current guidance from Domain 4: long passphrases, no reuse, a password manager, MFA everywhere, and never sharing a credential. Teaching the password manager properly is worth more than repeating complexity rules.
• Removable media and cables — why a found USB is a threat, and that a device can present itself as a keyboard.
• Social engineering — the Domain 2 techniques, taught as scenarios rather than definitions.
• Operational security — what not to disclose publicly: system details in job adverts and conference talks, internal screenshots, out-of-office replies naming the deputy and their contact details.
• Hybrid and remote work — home network hygiene, shoulder surfing in public, device security outside the office, and the split-tunnelling reality that the device is often outside your inspection.

The guidance that makes any of it stick: role-specific, short, frequent, and about what to do rather than what not to do. Finance staff need payment verification procedures; developers need secure coding and secrets handling; executives need whaling awareness and travel security. One annual module for everyone is the format that produces completion rates and nothing else.

Reporting and monitoring, development, execution, and the metric worth reading

CompTIA names the programme lifecycle — development, execution, reporting and monitoring — and it mirrors the baseline cycle from Domain 4: define it, run it, measure it, and revise it on what you measure.

Reporting here means the user reporting channel, and it is the highest-value component of the whole objective. What makes it work:

• One obvious mechanism, ideally a button in the mail client, because "forward it to security@" adds friction and produces fewer reports.
• A response, so people know the report went somewhere. A brief acknowledgement and an occasional "you were right, we pulled it from 40 mailboxes" does more for the report rate than any training module.
• No blame, including for reports that turn out to be nothing. The cost of a false report is a minute of triage; the cost of a suppressed real one is an incident.

Monitoring the programme means tracking whether behaviour is changing: report rate and time-to-report trending up, click and credential-submission rates trending down, repeat-clicker numbers falling, and — the measure that connects to everything else — real phishing being reported by users before the gateway or the SOC found it.

The metric worth reading is the report rate, not the completion rate. Completion measures attendance. Click rate measures one failure mode and can be gamed by sending easy simulations. Report rate measures whether you have built a detection capability out of your workforce, which is the only outcome of an awareness programme that shows up in an incident.

A note on this lesson's lab

This is the one lesson in the course with no short hands-on lab, and the reason is worth stating plainly rather than hiding in a plan file: the real exercise is a phishing simulation against colleagues who have consented to be measured, and a campaign you run against yourself proves nothing about behaviour. The applied lab therefore has you design the campaign — the pretext, the control group, the metrics, the no-blame communication and the follow-up — which is the part a candidate is actually asked to get right, and the part that most programmes get wrong.

What to take into the exam

• Report rate is the metric that matters; completion rate measures attendance.
• Do not punish clicking — punishment suppresses reporting, and reporting is the part with operational value.
• Teach the response explicitly: do not click, do not reply, do not delete — report and leave it in place.
• Risky is knowing, unexpected is out of pattern, unintentional is a mistake — and most data incidents are the third.
• Training should be role-specific, short and frequent; one annual module for everyone produces completion and nothing else.
• Insider threat reporting needs a confidential route and protection for good-faith reports, or nobody uses it.