Security Policies & Procedures

When the Uber breach of 2022 was investigated, one detail stood out: the attacker got in by posing as an IT support person and convincing an employee to hand over their credentials via WhatsApp. No zero-day. No advanced malware. Just a gap between what the security policy said and what employees actually did when pressure was applied. The policy existed. The enforcement didn't. That gap is what this lesson is about.

Policy, procedure, standard, guideline — four different things

These four terms get used interchangeably in most organisations. They shouldn't. Each operates at a different level and serves a different purpose, and conflating them produces documents that are simultaneously too vague to follow and too rigid to be practical.

A policy is a high-level statement of intent. It says what must happen, not how. "All user accounts must be protected by multi-factor authentication." That's a policy. It sets the requirement. It doesn't specify which MFA solution to use.

A standard translates a policy into specific, measurable requirements. "MFA must use TOTP-based authenticator apps or hardware keys. SMS-based MFA is not permitted for privileged accounts." That's a standard. It gives the policy teeth.

A procedure is the step-by-step operational instruction. "To enrol in MFA: open the authenticator app, tap Add Account, scan the QR code displayed in the admin portal, enter the six-digit code to verify." That's a procedure. It tells people exactly what to do.

A guideline is a recommendation — not mandatory, but advised. "It is recommended that employees use a dedicated authenticator app rather than adding accounts to a personal password manager." Guidelines acknowledge that not every situation fits a rigid rule.

The core policies every programme needs

Organisations of any meaningful size need a base set of security policies. These aren't optional paperwork — they're the documented agreements between the organisation and its people about what's acceptable, what's required, and what happens when things go wrong.

Acceptable Use Policy (AUP) defines what employees can and cannot do with company systems, devices, and networks. Can they use company laptops for personal use? Can they access personal email from a work machine? Can they install software without IT approval? Without an AUP, every one of those questions is answered differently by every employee — and the organisation has no recourse when something goes wrong.

Password Policy sets the rules for credential creation and management. Minimum length, complexity requirements, rotation schedules, prohibition on reuse, requirements for MFA. A password policy that requires 8-character passwords with one uppercase letter and one number is not a security control — it's theatre. Modern guidance from NIST recommends length over complexity and drops forced rotation unless compromise is suspected.

Incident Response Policy establishes what counts as a security incident, who gets notified, and what the response process looks like. Without one, an organisation that discovers a breach spends the first critical hours arguing about who's responsible, who should be told, and whether to call the vendor or legal first. That argument costs time that could be spent containing damage.

Data Classification Policy defines categories of data and the handling requirements for each. Public, internal, confidential, restricted — or whatever labels the organisation uses. It answers the question every employee unconsciously asks when handling data: does this need to be encrypted? Who can I share it with? Can I store it on my personal device?

Access Control Policy governs how access to systems and data is granted, reviewed, and revoked. It's the policy layer above the technical controls. It should specify that access follows least privilege, that it's reviewed periodically, and that it's revoked immediately when an employee leaves. Most organisations do the first two inconsistently and forget the third entirely.

Policy without enforcement is decoration

A policy document sitting in a shared drive that nobody reads is not a security control. It's liability coverage — evidence that the organisation knew what should be done and chose not to enforce it. The gap between policy and practice is one of the most consistent findings in security audits, and it's almost always the result of one of three failures.

Policy isn't communicated. Employees never read the acceptable use policy they signed during onboarding. Training happens once at hire and never again. When a security incident occurs, investigation reveals that the relevant policy existed — employees just didn't know it, or had forgotten it three years later.

Policy isn't technically enforced. The password policy says passwords must be at least 14 characters, but the system accepts 6. The acceptable use policy prohibits personal USB drives, but no endpoint control blocks them. Written rules without technical controls are social contracts — and social contracts break under pressure.

Policy isn't practical. If following the policy makes it significantly harder to do the job, people find workarounds. A password policy that requires a new complex password every 30 days produces passwords written on sticky notes. A policy that blocks all external file sharing produces a shadow IT ecosystem of personal Dropbox accounts. Unusable security gets bypassed. The bypass is always worse than a better-designed policy.

A password policy — compliant vs effective

Password policies are the easiest place to see the difference between a policy written to pass an audit and one written to actually work. Here's what that contrast looks like in a real configuration file:

# /etc/security/pwquality.conf

# ── OUTDATED APPROACH ── looks compliant, produces weak passwords
# minlen = 8
# dcredit = -1      # at least 1 digit
# ucredit = -1      # at least 1 uppercase
# lcredit = -1      # at least 1 lowercase
# ocredit = -1      # at least 1 special character
# maxrepeat = 3
# Result: users write "Password1!" on a Post-it note and rotate it
# to "Password2!" next month. Technically compliant. Practically useless.


# ── NIST SP 800-63B ALIGNED APPROACH ── length beats complexity
minlen = 16           # Minimum 16 characters
maxrepeat = 3         # No more than 3 consecutive identical chars
gecoscheck = 1        # Reject passwords containing the username
dictcheck = 1         # Reject passwords found in common word lists
# No forced rotation — rotate only on confirmed or suspected compromise
# Pair with: haveibeenpwned API check at password set time

Policy review — keeping documents alive

A policy written in 2019 and never reviewed is almost certainly wrong in some way by now. Threat landscapes shift, technology changes, regulations evolve, and the organisation itself grows in ways that the original authors didn't anticipate. Policies need an owner, a review cycle, and a version history.

Annual review is the standard minimum for most policies. After a significant incident, review immediately — the incident almost certainly revealed a gap that the policy needs to address. After a major regulatory change (new data protection law, new compliance requirement), review any policy that touches the affected area.

Version control for policy documents is not bureaucracy — it's essential. When an auditor asks whether a policy was in place at the time of an incident, you need to be able to prove what version existed and who approved it. A shared document with tracked changes and approval signatures does this. A Word file emailed around and saved in three different versions on two different drives does not.

Practice Questions

Quiz