Security Training

For a long time, security money went to equipment and tooling first. Buy a firewall, add a system that logs access, enforce strong password rules. But look at the paths actual incidents took and they were mostly outside that equipment.

The common shape runs like this. An email arrives in the founder's name with an urgent request. Someone opens the attachment, or clicks the link and enters their username and password. The firewall sees a normal login, because the username and password are correct. The system wasn't breached; a door was opened from the inside, by someone with a legitimate key.

For a while this was handled as individual carelessness. After an incident the person gets a word and one company-wide notice goes out. People are careful for about two months and then return to normal. A notice works only in the moment it's read, and people who join afterward never see it at all — so the organization's average level of care drifts downward with every hire.

Security training moves that from a one-off warning into a recurring procedure. It takes as given that people are the weak link and changes the approach to tightening that link on a schedule.

It cycles on an annual basis, in five steps.

1. Decide what to teach, taking it from the security policy, the document that states the rules. Teach something the policy doesn't contain and there's no basis for enforcing it afterward; leave something in the policy untaught and it becomes a rule that exists only on paper.
2. Split by audience — what everyone needs versus what specific roles need. The everyone portion is recognizing phishing, password management, and how far customer data can be downloaded. The engineering portion adds not putting access keys in code and the rules for querying a production database directly.
3. Build it as short sessions, repeated. Two hours once a year sticks only during the session. Twenty minutes once a quarter lasts far longer on the same total time, and it also fits into a week without anyone having to reschedule around it.
4. Use real examples. A generic list of practices doesn't get read. Showing an actual phishing email your company received and finding what's wrong with it together is what sticks — one character off in the sender address, sentences engineered to create urgency, an approval request that doesn't match how approvals usually arrive.
5. Confirm and record. Log who completed it when, and check comprehension with a few short questions. The record is what lets you chase the people who skipped it, and what serves as evidence in an external audit.

Training alone tells you nothing about its effect. So a phishing drill, sending fake phishing mail to see how people respond, gets attached afterward. Setting the click rate before training next to the rate after shows whether the activity changed anything. When it didn't, what needs work is usually the format rather than the content — the same material delivered at a different length, or at a different moment, often moves the number when rewriting it doesn't.

Everyone. That it isn't only for engineers or the security owner is the defining feature of the activity. If anything it matters more for sales and customer success, who handle customer data daily. Sending a list file to a personal account, or exposing another customer's information during a screen share, happens at those desks, and neither action looks like a security event while it's happening.

The timing splits four ways.

1. At joining, in the first week. That's when accounts and permissions arrive, so it's exactly when the rules are needed. Miss this slot and the person works without any standard until the next quarterly session.
2. On a schedule, commonly quarterly, keyed to dates rather than to people. Run it only after incidents and the careful period ends after about two months.
3. When something changes — a new tool, an amended policy, or an actual incident. Training after an incident is the training people hear best, so that moment doesn't get skipped.
4. When a role changes. Someone who just received production database access learns the rules attached to that access then.

Manager participation matters too. When a team lead treats the session as a formality, that team's completion rate falls first, which is why many companies pull completion by team.

It often starts from an external requirement. Certifications like SOC 2, which verifies a service organization's security controls, include annual training and its records as line items. Security questionnaires from customers carry the same question, which means the records get read by someone outside the company sooner or later.

"Let's put this in the first-week onboarding. Rules should arrive the same day permissions do."

Aligning the timing with when access is granted.

"Do we still have last year's training records? The customer questionnaire asks whether we run it annually."

Records serving an external requirement.

"Drill click rate is identical before and after training. The content has to change."

Checking the effect numerically and reworking the format.

At Pagedeck, Grace runs a twenty-minute session once a quarter. The material isn't rebuilt each time — it uses two or three phishing emails the company actually received that quarter. An approval request sent in the founder's name was last quarter's example.

The activity caught something once. Two weeks after a session, an email of the same shape arrived, and the recipient asked Grace instead of clicking. They recognized the one-character difference in the sender domain exactly as they'd seen it in training. Since then the material includes the cases that got stopped, not only the rules. Training with a save in it is heard differently from training with only instructions.

A common belief is that security training is a formal annual event. It's done for certifications and customer requirements, so filling the line item looks like the job. But satisfying a requirement and reducing incidents are different pieces of work. Play a two-hour video and log completions and the line item is satisfied while the click rate is unchanged. What's left is grounds for saying training happened, and those grounds don't stop anything.

The other belief is that teaching people eliminates incidents. The cause is people, so fixing people should fix it. But however well someone is taught, an urgent email on a busy day gets clicked by anyone. Training lowers the probability; the remaining probability gets covered by other things. Add a second authentication factor, grant minimum permissions, and run access review, the periodic check of who can reach what, alongside it. In an organization with training and nothing else, one person clicking opens everything, and the training records are what you'll be reading afterward.