Build a Security Behavior Learning Program

Operating objective

Define the behavior and harm to reduce. Examples: support verifies recovery through an independent channel, developers remove secrets before commit, administrators use named time-bounded access, users report a suspicious session quickly, and responders revoke identity and application state.

Map each behavior to a role, real task, available tool, trigger, expected time, escalation, and control owner. Do not begin with a generic annual syllabus.

Program design

For each behavior:

1. Explain the threat and required outcome in the role's language.
2. Demonstrate the exact approved tool and workflow.
3. Let the learner practice a normal, error, and pressure case.
4. Give immediate specific feedback.
5. Provide a job aid at the point of work.
6. Ensure managers reward the safe action and allow enough time.
7. Remove system friction and unsafe alternatives found during practice.

Use short reinforcement when the task or threat changes. Provide deeper role training for people who administer identity, policy, support, applications, data, and incidents.

Signals and evidence

Measure task performance and system outcomes:

• Correct and incorrect action under realistic conditions.
• Time to complete, report, contain, revoke, and recover.
• Use of named identities, approved routes, managed tools, and narrow permissions.
• Unsafe exceptions, shared credentials, direct paths, support load, and abandoned work.
• Incident recurrence and control changes after lessons.

For phishing simulations, rate detection difficulty and account for role and exposure. Measure reporting and containment, not only clicks. Protect individual privacy and use aggregate findings to improve the system.

Response and recovery

When learning reveals a failure, decide whether the root cause is missing knowledge, unavailable tool, poor interface, conflicting incentive, unsafe default, excessive workload, inaccessible process, or weak technical control. Assign the correct owner.

Update content after system changes and incidents. Retire obsolete lessons. Give people a non-punitive way to report both suspicious events and unworkable controls. Close the loop by showing what changed.

Design tradeoffs and residual risk

Practice consumes time. Surprise tests can harm trust. Detailed measurement can become surveillance or punishment. Role-specific material takes more work than generic content and is more likely to change behavior.

Learning cannot make a bearer credential phishing resistant, constrain a broad administrator account, or fix a direct origin. Keep technical controls as the primary treatment when they can remove the failure class.

Pomerium boundary

Pomerium can give people one consistent protected route and can provide access evidence for covered requests. The learning program must use the actual identity provider, Pomerium route, application permission, support, emergency, reporting, and containment workflow. Product documentation alone is not role-specific practice.

Exercise

Choose three high-risk roles and one behavior for each. Observe the current task, identify system friction, and record baseline outcome. Build one normal and one pressure exercise in the real training environment.

Run the exercises, classify each error by root cause, and change at least one control or workflow in addition to the lesson. Repeat after a delay. Compare correct action, task time, reporting, support work, and bypass use without ranking individual people publicly.

Evaluation checklist

• Does each learning unit map to a real role, task, tool, threat, and measurable behavior?
• Can learners practice normal, failure, urgent, and reporting cases in a realistic environment?
• Do measures include task success, report and containment time, unsafe workarounds, and control outcomes?
• Does the program fix interface, tool, incentive, workload, and technical causes instead of repeating training?
• Are privacy, accessibility, fairness, trust, and non-punitive reporting protected?