Security Protocol

What a security protocol is

A security protocol is the document that sets out the rules and procedures everyone in an organisation follows to keep people, information, and premises safe. It is the human-facing companion to the technical controls: where an engineer hardens a server, the protocol tells a receptionist how to handle a stranger at the door, tells a new hire how to choose a password, and tells a finance clerk what to do when a suspicious invoice arrives.

A protocol is operational, not theoretical. It describes behaviour — what people must do, what they must never do, and who to call when something looks wrong. A good one is short enough that people actually read it, specific enough that a new starter knows exactly how to act, and written in plain language rather than the dense wording of a formal standard.

Keep in mind the difference between three documents that are easy to confuse. A security policy is the high-level statement of intent ("we protect customer data"). A technical security plan shows how one system is engineered to deliver on that intent — the encryption settings, the access model, the monitoring. A security protocol, the subject of this guide, is the set of everyday procedures the whole workforce follows. The three reinforce each other; this document focuses on the people and procedures layer.

Scope: physical, information, and personnel security

A complete protocol covers three overlapping domains, and the most damaging gaps usually sit where they meet.

• Physical security — control of the building and its contents: who may enter, how visitors are signed in and escorted, how doors and server rooms are locked, where badges and keys live, and what a clean-desk and clear-screen rule looks like in practice. A leaked password matters less if anyone can walk in and read a screen.
• Information security — how data and systems are protected through behaviour rather than configuration: acceptable use of company devices, email and phishing awareness, safe handling of files, and the rules for storing, sharing, and disposing of sensitive information.
• Personnel security — the human lifecycle: vetting appropriate to the role, a security briefing on day one, defined responsibilities while employed, and — most often neglected — a reliable off-boarding step that revokes every access the moment someone leaves.

Access and authentication rules

Most real incidents come down to who could get in and how easily. State the rules plainly so there is no room for interpretation.

• Identity and accounts — every person gets their own named account; shared logins are banned because they destroy accountability. Service or system accounts are owned by a named person.
• Authentication — set a clear standard: a passphrase rather than a short password, multi-factor authentication (MFA) on anything that matters, and a password manager instead of sticky notes or reused passwords.
• Least privilege — people get only the access their role needs and nothing more. Elevated or administrator access is the exception, granted deliberately and reviewed regularly.
• Physical access — badges, keys, and door codes are issued to individuals, logged, and recovered when no longer needed. Tailgating — letting someone follow you through a secure door — is treated as a real risk, not a courtesy.
• Joiners and leavers — access is provisioned to a defined baseline on day one and fully revoked on the last day. A leaver who still has a working login is one of the most common and avoidable exposures.

Acceptable use and data handling

This section is what most employees will actually consult, so make it concrete.

• Acceptable use — what company devices, accounts, and networks may and may not be used for; whether personal use is permitted; and the line that turns ordinary use into a breach (installing unvetted software, disabling security tools, connecting unknown USB devices).
• Data classification — give people a small, memorable set of labels (for example Public, Internal, Confidential, Restricted) and one rule for each: who may see it, how it may be shared, and how it must be stored.
• Sharing and transfer — how confidential information may leave the organisation: approved tools only, encryption where required, and a check on the recipient before anything sensitive is sent.
• Retention and disposal — how long records are kept and how they are destroyed: shredding paper, wiping devices before reuse, and emptying shared drives of files that are no longer needed.

Incident reporting

The single most useful thing a protocol does is make reporting easy and blame-free, because the faster a problem surfaces the smaller it stays.

• What counts as an incident — a lost laptop or phone, a clicked phishing link, a misdirected email containing personal data, an unfamiliar person inside a secure area, a suspected malware infection, or simply something that feels wrong.
• How to report — one obvious channel that works at any hour (a phone number, an address, or a chat channel), with a named role behind it. If reporting is hard, people will hide mistakes.
• No-blame principle — reporting promptly is rewarded, not punished. The person who reports their own phishing click within minutes has done exactly the right thing.
• What happens next — who triages the report, how the person is kept informed, and the basic shape of the response: contain the problem, assess the impact, fix the cause, and record what was learned.

Training, enforcement, and review

A protocol that nobody is taught and nobody enforces is decoration.

• Training — every new starter is briefed during onboarding and signs to confirm they have read the protocol; everyone refreshes it at a set interval, with short, practical reminders (a simulated phishing email beats an hour-long slideshow).
• Enforcement — make clear that the rules apply to everyone, including leadership, and what happens when they are ignored. Pair consequences with a supportive culture, so honest mistakes are reported rather than buried.
• Ownership and review — name a single owner responsible for keeping the protocol current, and set a review date (commonly every six to twelve months, and after any significant incident or change to how the organisation works).

Common mistakes to avoid

• Writing it for auditors, not staff. A protocol crammed with formal standard wording is one nobody reads. Write for the receptionist and the new hire, in plain language.
• No off-boarding step. Granting access carefully but never revoking it leaves a trail of live logins for former staff. Make the leaver checklist as firm as the joiner one.
• Shared accounts and passwords. They feel convenient and they destroy accountability — when something goes wrong nobody can tell who did it.
• A reporting channel nobody can find. If staff do not know exactly who to tell at 9pm on a Friday, incidents go unreported until they are expensive.
• Punishing honest reports. Blaming the person who reports a mistake guarantees the next mistake stays hidden. Reward speed and honesty.
• Treating it as write-once. An out-of-date protocol that still names a person who left two years ago signals that none of it is taken seriously. Assign an owner and a review date.