Encode one triage decision as a governed, fail-closed, fully reversible policy with nested criteria, a dry-run preview, four-eye approval, an audit log, and a safe revoke path.
This guide teaches you to build a single finding rule end to end in PMAP, from a nested AND/OR criteria tree to one committed, audit-logged action. You will compose conditions across more than 25 matchable fields using the 16-operator library, choose an action type, and set its place in priority-ordered evaluation. The result is a policy the engine applies consistently instead of a decision you repeat by hand.
It is written for triage leads and security engineers who already make a recurring decision manually and want it governed. By the end you will be able to quantify blast radius with a dry-run preview and a live affected-findings scan, route a high-impact rule through four-eye approval, read its audit log after it fires, and reverse it with a safe or force revoke.
Inside this guide
- Understand how the engine evaluates a rule in priority order before you author one.
- Set the rule basics: name, scope, priority, and expiry.
- Build a nested AND/OR criteria tree and pick the right field and operator for each condition.
- Choose an action type and its parameters from the available set.
- Quantify impact with a dry-run preview, an in-context test, and a live affected-findings scan.
- Submit a high-impact rule for four-eye approval and read its audit log after activation.
- Revoke a rule in safe or force mode and watch its metrics.
Before you start
- A PMAP account with rule create and update permissions in your company scope, plus rule approve permission if you will sign off on gated rules.
- A populated Findings queue from at least one scan import, so preview and the affected-findings view have real data to match against.
- A clear, written triage decision you already make by hand, so the rule encodes one policy rather than guesswork.
- Familiarity with your severity policy, SLA thresholds, and which automated changes your governance model considers sensitive enough to gate.
- For a four-eye rule, a second reviewer with rule approve permission who did not author the rule, because self-approval is blocked server-side.
