Security Awareness in Daily Work

Why IT workers need it most

Security awareness is knowing which everyday situations carry a security risk and having the habits to handle them safely: pausing at an odd request, checking before acting, protecting credentials and reporting what looks wrong. It is not the same as security knowledge. You can understand encryption perfectly and still read out a password to a convincing caller.

Attackers go for people because it works. The Verizon Data Breach Investigations Report (DBIR) of 2026 found a human element in 62% of the breaches it analyzed, up slightly from 60% the year before. Pretexting, an invented story to get information or action, accounted for 6% of breaches and is increasingly used as the first step toward ransomware or extortion, often by phone. In the phishing simulations the report looked at, attacks by voice and text message had median click rates 40% higher than email.

People in IT are at the sharp end of this. A service desk employee can reset a password or register a new MFA device. A system administrator can create accounts, change firewall rules and read mailboxes. A developer has access to source code and deployment pipelines. For an attacker, one IT account is worth more than a hundred ordinary ones, and an IT worker who "just helps quickly" is the shortest route in. The attack techniques themselves are described in Social Engineering and Phishing; this page is about the habits that defend against them during a normal working day.

Verify unusual requests

Most successful scams ask you to do something slightly outside the normal process, and give a reason why the normal process cannot be followed this time. That combination is the signal. Treat a request as unusual when it involves:

• Money: a payment, a changed bank account number, gift cards.
• Access: a password reset, a new MFA device, extra rights, an account for someone you have not met, a firewall rule "just for today".
• Data: an export of customer records, a list of accounts, a copy of a mailbox.
• Skipping the process: "don't log a ticket", "keep this between us", "no time for the change board", "I'll explain later".
• Pressure: a deadline in minutes, an angry senior manager, a reason why the person cannot be reached in the normal way.

CEO fraud

CEO fraud is a scam in which the attacker poses as a senior executive, such as the chief executive officer (CEO) or chief financial officer (CFO), and orders an employee to make an urgent, confidential payment or to hand over data. It is a form of business email compromise (see Business Email Compromise). The Dutch Fraudehelpdesk describes the classic version: an email from "the boss" asks someone in finance to transfer a large amount abroad, sometimes with a fake law firm in the story. The red flags it lists are worth remembering because they also fit attacks on IT:

• the request is phrased as an order, leaning on authority;
• you are told not to discuss it with colleagues;
• flattery ("you are the only one I can trust with this");
• personal pressure and a tight deadline;
• a sender domain that looks right but is not, for example a lower case l replaced by a capital I.

In IT the "payment" is often access. The version a service desk meets looks like this message, which arrived at Kestrel Energy's service desk on a Friday evening:

From: Sanne de Vries (External)                     21:47
Hi Amara, I'm abroad and my phone was stolen. Please remove MFA
from my account and send a temporary password to this chat. I'm
presenting to the board in 20 minutes and can't get in. No ticket
please, I'll sort it out with Mei on Monday. Thanks!!

Every lever is there: a real manager's name, urgency, a reason why the normal channel (her phone) does not work, a request to remove a control, and a request to skip the ticket. The "External" label means the account sending the message is not a Kestrel account at all. Amara does not have to decide whether it is fake. She only has to follow the procedure:

Hi, I'd like to help, and for MFA changes I have to follow the
verification procedure. I'll call Sanne now on the number in the
company directory. If that doesn't work, her manager can confirm
through the service desk line and we'll take it from there.

Then she calls the number in the directory, reaches the real Sanne at home, who knows nothing about it, and reports the message (see reporting below). If the request had been genuine, the cost would have been a few minutes. Your manager should always back you when you follow the procedure; if they do not, that is a problem to raise, not a reason to skip it.

Callback verification

Callback verification means confirming a request by contacting the requester yourself, through a phone number or channel you already had — from the company directory, the contract or the customer record — rather than replying to the message or calling the number it contains. The Dutch National Cyber Security Centre (NCSC) gives the same advice: when in doubt, contact the sender through the channels known to you to confirm the request is genuine.

The point is that the attacker controls everything in the request: the sender name, the phone number in the signature, the caller ID on your screen and even, with voice cloning, the voice on the line. They do not control the company directory. A callback breaks the chain because it starts from information you trust.

Credentials and secrets

In IT you handle far more credentials than most colleagues: your own account, an administrator account, service accounts, API keys, device passwords, recovery codes. A few rules cover nearly every situation:

• You never need a user's password. Not to fix their mailbox, not to test their login, not to "check something". Use a remote session they approve, your own admin tools, or a reset. Saying this out loud ("I will never ask for your password") also teaches users how to recognize the fake IT caller who does.
• Secrets live in the password manager or vault, not in tickets, chat, email, wiki pages, spreadsheets or screenshots. Those places are searchable, copied into backups and readable by far more people than you think. See password managers, and what never belongs in Git for code.
• Use your admin account only for admin work. Read email and browse with your normal account; sign in with the separate administrator account for the task, then sign out. Why this matters is explained in Privileged Access Management.
• Never share an account, even with a colleague covering your shift. Shared logins make it impossible to tell who did what, which hurts you as much as the organization when something goes wrong.
• If a secret leaks, treat it as compromised. Deleting the chat message does not undo it. Rotate (replace) the secret, then report it.

Tickets deserve special attention because they are written in a hurry and kept for years. Compare these two notes on the same ticket:

INC-48213  Reset pw for j.bakker, new pw Welkom2026! given by
phone. Backup job on batch-01 stuck, restarted it with svc-backup
(pw is in the team chat). Works now.

INC-48213  Identity confirmed by callback to the number in the
directory. Sent self-service reset link to his registered device;
he set a new password himself at 10:31. Backup job on batch-01
stuck: restarted it with my admin account (adm-aokafor) following
KB-0419. Job finished 10:42. No credentials recorded here.

The second note is also simply a better ticket note: it says how identity was checked, which account did what, and which procedure was followed. More on writing notes like this in Writing Tickets and Technical Documentation.

MFA prompts, screens and sessions

Small physical habits stop a surprising number of incidents.

• Never approve an MFA prompt you did not start. An unexpected prompt means someone else has the password. Deny it, change the password and report it. Attackers sometimes send prompt after prompt, or call pretending to be IT and ask you to approve one (MFA fatigue).
• Lock your screen every time you stand up (Windows + L on Windows, Control + Command + Q on a Mac). An unlocked admin console in an open office is an open door. Many teams have a friendly rule for colleagues who forget; it works better than a lecture.
• Mind what is on your screen during screen sharing, in video calls and on trains: open tickets with customer data, a password manager left open, a terminal with a token in it. The clean desk and clear screen rules are in Physical Security.
• Close remote sessions properly. When you support someone remotely, ask permission, tell them when you take control and when you are done, and end the session from your side. See Remote Access.
• Do not plug in what you did not bring. A USB stick found in the car park or "left by a supplier" goes to the security team, not into a laptop to see whose it is.

Outside tools and copied data

A quieter risk is data leaving the organization through useful tools: pasting a log file into an online formatter, uploading a configuration to a public "diff checker", sharing a screenshot of an error with customer names in a public forum, or putting text into an AI tool the company has not approved. None of these feels like a security incident, but each one copies internal data to a service nobody has checked.

Before you paste, ask: would I be allowed to email this to a stranger? If not, remove hostnames, IP addresses, user names, customer data and secrets first, or use an approved tool. What not to paste into AI tools, and why company-approved accounts matter, is covered in Using AI at Work.

Reporting quickly

Security incident reporting is telling the security team or service desk, through the agreed channel and as soon as possible, about anything that might be a security incident: a suspicious message or call, a lost device, a password typed into the wrong page, data sent to the wrong person. You report possibilities, not certainties. Deciding whether it is an incident is the security team's job; making sure they hear about it is everyone's.

Speed matters for three reasons:

• The same attack is aimed at your colleagues. One early report lets the security team remove a phishing email from every mailbox and block the sender before anyone else clicks.
• Damage grows with time. A stolen password used within the hour can be reset within the hour.
• Legal clocks may be running. When personal data may be involved, the GDPR (in Dutch: AVG) generally requires the organization to notify the supervisory authority, in the Netherlands the Autoriteit Persoonsgegevens, within 72 hours of becoming aware of a breach, unless the breach is unlikely to create a risk for the people concerned. Those 72 hours start when the organization knows, so do not investigate on your own first: escalate, and let the people responsible assess it. See data breaches and Ethics, Privacy and Professional Conduct.

The report button

A phishing report button is a button in the email program that sends a suspicious message to the security team for analysis, usually removing it from your inbox at the same time. It is the fastest and safest way to report phishing: the team receives the full original message with its technical headers, which a forwarded copy or a screenshot loses. Use it instead of forwarding the email to colleagues to ask what they think, which only spreads it.

For anything that is not an email, such as a phone call, a chat message, a lost laptop or a mistake you made, use the channel your organization has set up: a security incident form, a phone number, or a ticket in a specific category. Find out where it is in your first week, before you need it.

What a useful report contains

A report does not need to be polished. It needs facts, including the uncomfortable ones. Joost Bakker, a billing engineer, opened an attachment before he noticed the sender's domain:

What:     Email "Updated bank details - invoice 2026-0915" from
          finance@kestreI.example.com (capital I, not l; ours is
          kestrel.example.com). Reported with the button.
When:     Received 09:12, I opened it 09:14.
What I did: opened the PDF (yes), clicked the link in it (yes),
          entered my password (no), approved an MFA prompt (no).
Others:   Sent to the whole billing team, 8 people.
Now:      Laptop on and connected, nothing else touched.
          I'm at my desk, ext. 4417.

Compare that with "got a weird mail, deleted it". The useful report tells the security team exactly what to check, who else to warn and how to reach him. It also admits the click. Reports like this only happen in teams where people are thanked for reporting, not blamed for clicking. If you clicked, say so straight away; what to do next is listed under if you clicked, and how the security team handles it in Incident Response.

When users report to you

In a service desk or IT support role you are often the person others report to. How you react decides whether they report next time.

• Thank them, every time, including for false alarms. A user who reports ten harmless emails and one real one has done exactly the right thing.
• Ask facts without judgment: what did you click, what did you type, when? "Why did you open that?" teaches people to hide the next one.
• Log it and pass it on through the security process, even when it looks harmless. You may be seeing one piece of a larger campaign.
• Tell them what happens next: whether to change a password, keep the laptop on, or simply carry on.

How to talk to users who are worried or embarrassed is covered in Communicating with Users and Customers.