Security policies and user awareness

Northfield Community Centre runs on a small staff and a large group of volunteers. When Brightline took over its IT in the summer of 2026, Keisha found a shared front-desk password written on a card taped under the keyboard, volunteers using their personal email to send registration forms, and no written rules about anything. Nobody was careless on purpose. They had simply never been told what was expected. In November the centre's director, Grace Okonjo, asked Brightline to help write a short set of security policies and train the staff and volunteers on them. Keisha brought Jordan to the planning meeting and gave him a job: listen for what people actually do, because a policy that ignores how people work will be ignored in return.

This lesson explains how security policies are organized, which policies small organizations need most, how to write rules people will follow, and how awareness training builds the habits that technical controls cannot. The exam groups these topics with risk management, because policies are how an organization turns its risk decisions into everyday behaviour.

Policies, standards, procedures and guidelines

Security documents form a hierarchy, and the exam expects you to know what belongs at each level.

• A policy states what the organization requires and why, in broad terms, and is approved by leadership. Example: all accounts that access personal information must use multi-factor authentication.
• A standard sets specific, mandatory requirements that support a policy. Example: passwords must be at least 15 characters, and the approved MFA methods are an authenticator app or a security key.
• A procedure gives step-by-step instructions for doing a task in a way that meets the standard. Example: how a technician enrols a new volunteer in MFA.
• A guideline offers recommended practice that is not mandatory. Example: tips for creating a memorable passphrase.

Keeping the levels separate makes documents easier to maintain. Policies change rarely and need leadership approval. Standards change as technology changes. Procedures change whenever a tool or screen changes, and the technicians who use them can update them. If every rule is written into the policy itself, a small change to a login screen means sending the whole policy back to the board.

The policies a small organization needs

Large organizations have dozens of security policies. A community centre needs a handful, each short enough to read in a few minutes. Keisha's starting set for Northfield had seven.

• Acceptable use policy: what staff and volunteers may and may not do with the organization's devices, accounts, network and data. Everyone signs it.
• Account and password policy: unique accounts for every person, no shared passwords, MFA where available, and how passwords are stored and reset.
• Data classification and handling policy: which information is public, internal or confidential, and how each kind may be stored, shared and disposed of.
• Personal device policy: whether personal phones and laptops may access work data, and the conditions, such as the application management approach from Lesson 1.
• Remote access and public Wi-Fi policy: how to connect safely from home or on the road.
• Incident reporting policy: what to report, how, and the promise that reporting honestly will not be punished.
• Onboarding and offboarding procedure: how accounts and access are granted when someone starts and removed the day they leave.

Other common policies include a clean desk policy, which requires sensitive papers and unlocked screens not to be left unattended; a data retention policy, which says how long records are kept and how they are destroyed; a change management policy, introduced in Lesson 2; and a vendor or third-party security policy for suppliers who reach the organization's systems.

Writing rules people will follow

Jordan's notes from the planning meeting showed why the old habits existed. The front desk had one PC and up to six volunteers on a busy day, so a shared password was the only way they knew to let everyone use it. Volunteers used personal email because they had no work accounts. Telling them to stop without giving them another way would only drive the behaviour underground.

Keisha's approach had four principles. First, make the secure way the easy way: Brightline gave each volunteer a simple account with a short sign-in using a security key kept on a lanyard at the desk, and set the front-desk PC to switch users quickly. Second, explain the reason for each rule in one sentence, because people follow rules they understand. Third, keep documents short and in plain language. Fourth, assign an owner and a review date to every policy, so it does not go stale.

Policies also need enforcement and exceptions. Technical controls can enforce many rules automatically: MFA cannot be skipped if the system requires it. For rules that cannot be enforced technically, the policy says what happens when they are broken, from a reminder to removal of access. Exceptions follow the same pattern as baseline exceptions in Lesson 1: documented, approved by an owner and reviewed.

Data classification

Classification tells people how carefully to treat information. A simple scheme with three or four levels works best for small organizations.

Classification connects directly to privacy law. Personal information such as the registration forms is protected under federal and provincial privacy laws, and a breach involving it may have to be reported to the Office of the Privacy Commissioner of Canada or a provincial commissioner. Knowing where such data lives, and keeping it out of personal email, makes both protection and incident response far easier.

Joiners, movers and leavers

Many breaches involve accounts that should not have existed: a former employee's account still active, a volunteer from three years ago who can still read shared folders, a contractor who kept a password. The joiners, movers and leavers process prevents this. Joiners get exactly the access their role needs. Movers have old access removed when they change roles, not just new access added. Leavers have their accounts disabled on their last day, their devices collected and any shared passwords they knew changed. Northfield's new procedure gave the director a one-page checklist for each case and a monthly report from Brightline listing every active account for her to review.

Security awareness training

Technical controls stop many attacks, but people still decide whether to click, whether to share a password on the phone and whether to report something odd. Security awareness training builds those habits. Effective programs share a few features.

• Short and frequent beats long and annual. A few minutes each month keeps topics fresh.
• Relevant examples work best. Volunteers learned to spot fake registration emails and phone calls pretending to be the city's recreation office, not generic examples from banks they did not use.
• Clear actions: every session ends with what to do, such as using the report button in email or calling Brightline.
• A positive reporting culture: people who report mistakes quickly are thanked, because early reports limit damage.
• Measurement: track completion, reporting rates and, where used, simulated phishing results, and use them to improve the training rather than to shame people.

Simulated phishing campaigns send realistic but harmless test emails to staff to measure how many click and how many report. Used well, they show where training is needed. Used badly, they create resentment. Brightline's rules were that the organization's leadership must approve each campaign, tests must never imitate sensitive situations such as pay cuts or health emergencies, results are shared as group trends, and anyone who clicks gets a short, friendly lesson rather than a reprimand.

Social engineering defences

Social engineering is manipulating people into giving away information or access. CSCO-121 described the main types. The policy side of defence is about verification: never act on an unexpected request for money, passwords or data without confirming it through a separate, known channel. A volunteer who gets a call from someone claiming to be Brightline and asking for the front-desk security key should hang up and call Brightline's published number. A bookkeeper who receives an email from a supplier announcing new bank details should phone the supplier using the number on file, not the one in the email. Writing these rules into policy gives staff permission to slow down and say no, even to someone who sounds important.

Rolling out and reviewing the policies

A policy that sits in a folder protects nobody. Northfield's rollout had three parts. Each staff member and volunteer received a one-page summary of the rules that applied to them, written as plain actions: use your own account, keep registration forms in the work drive, report anything odd to Brightline. Everyone signed the acceptable use policy at a short session where they could ask questions. And the full documents were stored in one shared location with a version number and date, so that nobody worked from an old copy.

Policies also age. New tools arrive, laws change, and incidents reveal gaps. Keisha set a review date twelve months out for each document and added three triggers for an early review: a security incident, a significant change in the organization's systems, or a change in a law that applies to it. Each review is recorded, even when nothing changes, because the record shows auditors, insurers and the board that the policies are living documents rather than paperwork written once and forgotten. When Northfield's insurer next asks whether it has written security policies reviewed within the past year, Grace will be able to answer yes and attach the list.