Learning outcomes
- Identify who can reduce risk, pays control cost, receives benefit, and bears failure.
- Find externalities, hidden action, hidden quality, moral hazard, and unsafe proxy metrics.
- Redesign ownership, budget, defaults, evidence, and feedback around the full lifecycle.
- Test whether the safe action remains the rational and practical action for each role.
Protection need
Choose one persistent security problem: direct-origin bypass, slow patching, shared accounts, overbroad roles, weak recovery, missing logs, unprotected vendor access, or unowned application authorization. State the harm and current technical control.
Security objectives and requirements
Create a party matrix with user, application team, platform team, security, support, finance, vendor, customer, insurer, attacker, and affected third party. For each, record:
- Goal and success measure.
- Authority and information.
- Implementation, operating, delay, and switching cost.
- Benefit from the control.
- Loss from failure.
- Ability to observe quality and report defects.
- Time horizon and exit option.
The control must give an accountable owner enough authority, budget, information, and feedback. The party asked to perform the safe action must have a usable tool and a benefit or requirement stronger than the workaround incentive.
Security invariants and evidence
Use evidence that is hard to game and close to the real outcome. Examples include direct-path denial tests, time from identity removal to last accepted action, percentage of privileged actions using named time-bounded identity, verified restore time, or patch exposure by reachable service.
Pair measures. A faster response target without correctness can create premature closure. A lower alert count can hide disabled detection. A high training completion rate can coexist with an unusable workflow.
Review who creates and verifies each metric. Provide safe reporting so people do not hide incidents to avoid penalty.
Failure cases
- Security defines a control, but application teams pay all integration and on-call cost.
- A vendor receives payment at sale while customers bear long-term patching and breach loss.
- Users must approve frequent prompts so the provider can reduce fraud cost.
- A team is measured on release speed and receives no credit for reducing future incident cost.
- Compliance completion becomes the target and replaces actual control testing.
- An insurer or shared platform absorbs loss and the service increases risky behavior.
Redesign options
Move safe defaults into the platform. Fund migration and operations. Assign one owner for the end-to-end result. Charge or restrict risky exceptions. Make quality visible through independent tests and lifecycle evidence. Align service levels with patch, revocation, recovery, and notification outcomes. Give users a fast approved alternative.
Use escalation and policy when one party can externalize severe harm. Keep exceptions visible, expiring, and owned. Revisit vendor selection and exit when hidden quality cannot be observed or corrected.
Design tradeoffs and residual risk
Strong incentives can cause gaming and silence. Central funding can weaken local ownership. Penalties can discourage early reporting. Evidence collection costs time and can become surveillance. Contracts can shift stated liability without changing technical control.
State which incentives remain outside the organization's control and which risk is accepted as a result.
Pomerium boundary
Pomerium can make a consistent protected route easier than separate VPN, bastion, and application middleware patterns. It does not assign migration budget, origin ownership, application permission work, on-call response, or vendor accountability. Adoption succeeds when those costs and benefits have explicit owners.
Exercise
Analyze one control that teams bypass or delay. Interview the people who implement, operate, use, support, and fund it. Produce the party matrix and identify at least one externality, hidden action, and gameable metric.
Change one default, ownership rule, budget, feedback loop, or exception cost. Measure safe-path adoption, task time, bypass use, reporting, and actual control outcome for a bounded period. Confirm that the change did not only move work to another team.
Evaluation checklist
- Are authority, information, cost, benefit, failure loss, time horizon, and exit mapped for every material party?
- Does the party able to reduce the risk have the authority, budget, and feedback to do so?
- Which cost is exported to users, operators, customers, vendors, or the public?
- Can each metric be gamed, and is it paired with an outcome or negative check?
- Does the redesign make the safe action practical and rational without suppressing reporting or moving hidden work?
Next learning unit
Security Incentives and Externalities
Find when the party able to reduce risk does not receive the benefit or bear the loss, then realign cost, authority, and feedback.
