Security Policies and Awareness

The Policy Hierarchy

Security policies fail when they're too vague to enforce or too detailed to maintain. The solution is a hierarchy that separates what must be done from how it's done. This hierarchy ensures policies are enforceable, standards are specific, and procedures are actionable.

The three levels

1. Policy — High-level, mandatory outcomes

Policies state what must be achieved, not how. They're approved by leadership, apply organization-wide, and change infrequently:

Policy: Access Control

All users must authenticate with multi-factor authentication before
accessing company systems. Access must be granted on a least-privilege
basis and reviewed quarterly. Unauthorized access attempts must be
logged and investigated.

This policy applies to all employees, contractors, and third parties
who access company information systems.

2. Standard — Specific, mandatory requirements

Standards translate policies into specific, measurable requirements:

Standard: Authentication

- MFA must use at least one of: hardware token, push notification,
  or biometric factor. SMS-based MFA is not acceptable.
- Passwords must be at least 14 characters.
- Sessions must timeout after 12 hours of inactivity.
- Failed login attempts must be locked after 5 failures.

3. Procedure — Step-by-step implementation

Procedures describe how to implement standards in specific systems:

Procedure: Enabling MFA in Okta

1. Log in to the Okta admin console
2. Navigate to Security → Multifactor
3. Enable MFA factors: Okta Verify, WebAuthn, Google Authenticator
4. Set policy: Require MFA for all users
5. Exclude only break-glass accounts (documented in the exception register)

Why the hierarchy matters

Without this hierarchy, organizations create one of two failure modes:

Vague policies that can't be enforced:

Bad: "Access should be secure"
Good: "All users must authenticate with MFA before accessing company systems"

Overly detailed policies that are impossible to maintain:

Bad: "MFA must be configured in Okta by navigating to Security > Multifactor..."
Good: Policy states the outcome; procedure describes the steps

The hierarchy ensures:

• Policies are stable (they don't change when procedures change)
• Standards are specific enough to audit
• Procedures are detailed enough to follow

Writing enforceable policies

An enforceable policy has these characteristics:

1. Clear scope: Who and what does this apply to?
2. Mandatory language: "must" not "should" or "may"
3. Measurable outcomes: Can you verify compliance?
4. Named owner: Who is accountable for this policy?
5. Review date: When will this policy be re-evaluated?
6. Consequences: What happens if the policy is violated?

policy:
  title: Data Classification
  scope: All employees, contractors, and third parties
  statements:
    - All data must be classified as Public, Internal, Confidential, or Restricted
    - Confidential and Restricted data must be encrypted at rest and in transit
    - Restricted data must not be stored on personal devices
  owner: Chief Information Security Officer
  review_date: 2027-01-01
  consequences: Violations may result in disciplinary action up to termination

Policy exceptions

Exceptions are inevitable — a legacy system can't support MFA, a developer needs admin access for a migration. The key is managing exceptions formally:

exception:
  id: EXC-2026-001
  policy: MFA Enforcement
  requester: jane.doe@company.com
  system: Legacy CRM (Salesforce Classic)
  reason: Legacy system does not support MFA
  compensating_controls:
    - System is accessible only from the corporate network
    - Access is restricted to 3 named users
    - All access is logged and reviewed monthly
  approved_by: ciso@company.com
  expiration_date: 2026-12-31
  review_date: 2026-10-01

Every exception must have:

• A documented reason
• Compensating controls that reduce the risk
• An expiration date — exceptions expire, they don't persist forever
• A review date — the exception is re-evaluated periodically
• An approver — someone with authority accepts the residual risk

Security Awareness That Changes Behavior

Most security awareness training is a compliance checkbox — employees click through slides, take a quiz, and forget everything within a week. The completion rate is 100%, but phishing click rates don't improve. The problem isn't the content; it's the approach.

Why traditional training fails

1. It's not relevant: Generic phishing examples don't look like the emails employees actually receive.

2. It's not timely: Annual training doesn't reinforce behavior when it matters — when the employee is actually facing a phishing email.

3. It's not measured: Completion rates don't measure behavior change. An employee can complete training and still click phishing links.

4. It's punitive: Training that shames employees for clicking creates a culture of fear, not security.

The behavior-change model

Effective security awareness follows a simple model:

Knowledge → Motivation → Practice → Feedback → Habit

• Knowledge: Employees know what threats look like
• Motivation: Employees understand why it matters to them
• Practice: Employees practice identifying threats in realistic scenarios
• Feedback: Employees receive immediate feedback on their decisions
• Habit: Employees automatically apply what they've learned

Phishing simulations that work

Phishing simulations are the most effective tool for measuring and improving security awareness — but only when done correctly:

Do:

• Use realistic templates that mimic current threats (not obvious fakes)
• Send simulations at random times, not on a predictable schedule
• Provide immediate, constructive feedback when someone clicks
• Track click rates over time to measure improvement
• Celebrate improvement, not just failures

Don't:

• Shame or punish employees who click
• Use simulations as a trap or gotcha
• Send simulations during high-stress periods (incident response, audits)
• Stop simulating — threats evolve, training must too

# Phishing simulation metrics
def calculate_click_rate(simulations_sent, clicks):
    return (clicks / simulations_sent) * 100

def track_improvement(monthly_rates):
    # Target: click rate below 5%
    for month, rate in monthly_rates.items():
        status = "PASS" if rate < 5 else "NEEDS_IMPROVEMENT"
        print(f"{month}: {rate:.1f}% — {status}")

# Example: tracking improvement over time
monthly_rates = {
    "2026-01": 18.2,
    "2026-02": 15.7,
    "2026-03": 12.1,
    "2026-04": 9.8,
    "2026-05": 7.3,
    "2026-06": 5.1
}
track_improvement(monthly_rates)

Measuring what matters

The goal is not 100% completion — it's reduced click rates and increased reporting rates:

The most important metric is report rate — employees who report suspicious emails are your last line of defense. A high report rate means employees are engaged and vigilant.

Building a security culture

Training alone doesn't build a security culture. Culture comes from:

• Leadership modeling: Executives follow the same security practices they ask of employees
• Positive reinforcement: Recognize and reward good security behavior, not just punish bad behavior
• Relevant examples: Use real incidents (anonymized) to show how threats actually manifest
• Continuous reinforcement: Short, frequent touchpoints (weekly tips, monthly simulations) beat annual marathons
• Psychological safety: Employees should feel safe reporting mistakes without fear of punishment

Bad culture: "You clicked a phish — you're required to re-take training"
Good culture: "You reported a phish — thank you. Here's what to look for next time."

The goal is to make security everyone's responsibility, not just the security team's problem.