Set severity-based deadlines, layer scope overrides, route a three-level escalation chain, and recalculate the whole finding population in sync.
This guide shows you how to define remediation SLAs in PMAP as a clean hours-per-severity mapping across urgent, critical, high, medium, and low. You will layer company and project overrides on top of global admin defaults using the strict four-level resolution waterfall, and use nullable partial overrides so only the severities that differ from policy are set while the rest cascade. The effective policy stays predictable at every scope.
It is written for SLA and remediation owners who manage deadlines across multiple companies and projects. By the end you will be able to configure a three-level escalation chain of contact and days-after-breach pairs, save a config that triggers automatic deadline recalculation across every open finding in scope, and confirm the recalculated count.
Inside this guide
- Read the four-level waterfall and the current effective policy.
- Set or confirm the global default thresholds and the company-level severity thresholds.
- Use nullable partial overrides to inherit selectively across severities.
- Set project-level thresholds that win over company-level values.
- Configure the three-level escalation chain of contacts and days-after-breach.
- Save and confirm automatic deadline recalculation, then run on-demand bulk recalculation.
- Revert an override to the inherited level and verify breach routing, pause accounting, and audit.
Before you start
- A PMAP account whose RBAC scope covers the company or project whose SLA policy you intend to edit.
- Platform administrator access to the Admin System tab if you also need to set or read the global default ladder.
- Your organization’s contractual or internal SLA policy expressed as hours per severity, so the numbers you enter are deliberate.
- The user IDs of the people who should receive escalations, since each escalation contact is referenced by user ID.
- An understanding that recalculation runs synchronously, so a large tenant save may take longer than a small one.
