ThreatLocker Allowlisting

Run the ThreatLocker default-deny runbook. A blocked application is the product working; the
risk is approving too fast. Approvals and policy changes are console actions: you triage,
recommend a scoped decision, record it, never self-approve.

1. Identify what was blocked: application or file, hash, publisher and certificate, the path
   it ran from, the parent process, the user, the endpoint.

2. Weigh legitimacy before approving: publisher or certificate valid and expected; path
   normal (Program Files) rather than user-writable (temp, AppData); a legitimate parent
   process rather than Office or a browser spawning an unknown binary; an expected update of
   allowed software rather than something new. Correlate with a change the user made and
   prior tickets for the same app.

3. Approve at the narrowest scope: verified publisher or certificate over hash, hash over
   full path, full path over folder or wildcard. Scope to the client or policy group that
   needs it, not globally unless it is fleet-wide trusted. A path or folder allow in a
   user-writable location is a hole. When legitimacy cannot be established — unsigned, odd
   origin, unknown-reputation binary launched by a document or script — do NOT approve to
   clear the ticket. Investigate (edr-detection-runbook, or phishing-triage
   if a document or link is upstream) and leave it denied.

4. Learning versus Secured mode. Learning builds the baseline by observing what runs and is
   NOT protecting; Secured enforces default-deny. Onboarding runs Learning first, then Secured
   after review. A client "protected by ThreatLocker" but left in Learning is not
   enforcing — flag it. A spike of requests right after go-live is expected;
   never "fix" it by loosening broadly.

5. Elevation Control (admin rights for one app, not the user) takes the same
   legitimacy bar plus a privilege lens: scope elevation to the specific application, prefer
   time-limited or one-time, and never grant standing elevation for convenience. Elevating
   an unknown binary is a red flag. Storage Control (USB, removable media, network shares)
   follows the client's removable-media policy per usb-removable-media-policy: scope to the
   specific device or share and user, time-box temporary access, and route policy-loosening
   to the client's authorized approver, never the requester.

6. Note the decision: what was blocked, the legitimacy evidence, the rule scope chosen and
   why, and the approver where a policy was loosened. Plain text, no markdown or emojis
   (apply the PSA Note Discipline base skill). Recurring legitimate blocks get a scoped
   baseline policy, not repeated one-off approvals; client-facing wording follows
   defensive-writing-standard.

Without documentation the client's software baseline is unknown — lean to
investigate-don't-approve and say so. When in doubt, leave it denied and escalate.