From once-authored policy to durable response: how the rule engine triages every finding at ingest and runbooks turn platform events into governed, auditable action.
Every vulnerability program eventually hits the same wall: the volume of findings grows faster than the analysts who triage them. Manual triage of every scanner import, every notification, and every ticket does not scale, and the toil it creates is where consistency quietly erodes. This ebook is about the two engines PMAP uses to remove that toil without removing the governance. The rule engine encodes the triage decision once, as policy, and applies it to every finding at the moment it arrives. The runbook engine listens to the platform event bus and turns each significant moment into an ordered, auditable sequence of actions. Together they let a small team operate a large program, because the work that used to live in people’s heads now lives in the platform, applied consistently and reversible by design.
What you will learn
- Why automation in vulnerability management is a governance problem before it is a throughput problem.
- How the rule engine matches findings with an AND/OR criteria tree of 25+ fields and 16 operators, then applies one of 8 action types.
- How dry-run preview, a four-eyes approval gate, and safe or force revoke keep automated mutation safe to trust.
- How runbooks subscribe to 16 trigger events and execute a catalog of 22 action types in order.
- How the durable workflow engine makes sleep and await-signal survive worker restarts for multi-day gates.
- How the circuit breaker, throttle, concurrency gate, and execution history keep automation healthy and observable at scale.
Inside this ebook
- Chapter 1. Automation as a Governance Problem. It is easy to automate badly. The hard part is automating in a way an auditor can reconstruct and an operator can reverse. PMAP treats that as the whole point, not an afterthought.
- Chapter 2. The Rule Engine: Policy at Ingest. A rule encodes a triage decision once and applies it to every finding that matches, the moment that finding arrives. This is how a program triages a six-figure backlog without touching most of it by hand.
- Chapter 3. Governing Automated Mutation. A rule that silently rewrites findings is a risk, not a feature. PMAP wraps the rule engine in four controls that make automated mutation something a program can defend: preview, approval, audit, and revoke.
- Chapter 4. The Runbook Engine: Events Into Action. Where rules govern the shape of a finding, runbooks govern what happens next. A runbook listens to the platform event bus and turns each significant moment into an ordered, auditable sequence of actions.
- Chapter 5. Durable, Resilient, Observable. An automation engine has to survive the real world: long waits, transient failures, runaway loops, and the need to prove afterward exactly what happened. PMAP builds for all four.
- Chapter 6. Designing an Automation Program. Two engines do not make a program. Composing them with intent, and operating them with discipline, is what turns automation from a collection of rules into a system your team can rely on.
Automation that you cannot explain to an auditor or undo after a mistake is not a time saver. It is a liability that happens to be fast.
PMAP design principle
At a glance
- Series: PMAP Ebook
- Discipline: VM Automation
- Audience: Security engineer, SOC lead, platform admin
- Reading time: About 45 minutes
- Platform: PMAP by Privia Security
- Applies to: PMAP v2026.06
