Read from one shared model
Reporting reads the single finding model the whole platform shares, alongside assets, projects, and SLA timers, so there are no competing scanner exports to reconcile.
PMAP capability
Reporting and Risk Analytics
Report from one finding model, not five scanner exports. PMAP gives you SLA and remediation tracking, program-level risk analytics and a tamper-evident audit trail, so the numbers you present hold up.
One source of truth for the numbers
When each scanner produces its own report, leadership sees several different pictures and none of them reconcile. Audit prep turns into a manual reconciliation exercise.
PMAP reports from the single finding model the whole platform shares, so SLA status, remediation progress and risk all come from the same data, and the audit trail backs every figure.
From clashing exports to one set of numbers
The same program, counted four different ways by four exports, resolves to one read-only intelligence layer where every KPI reconciles to the same scoped source.
Disconnected exports
- Scanner A Open: 1,204 CSV export
- Scanner B Open: 980 PDF report
- Spreadsheet Open: 1,310 manual roll-up
- Console Open: 1,150 live view
One intelligence layer
One scoped program dashboard
- 1,204 open
- scope-enforced
- read-only
Every KPI, trend, and risk score reads from the same scoped source, so the board slide and the console never disagree.
What reporting covers
One finding model, one set of numbers
Because scanning, triage and remediation share one data model, every report reconciles to the same source instead of competing scanner exports.
- Single source of truth
- Reports reconcile by design
- No manual export stitching
SLA and remediation tracking
Track SLA status and remediation progress across the program, so you can show what is on time, what is at risk and what is overdue.
- On-time, at-risk and overdue views
- Progress across teams and projects
- Deadline-driven reporting
Tamper-evident audit trail
Deadline-driven remediation is backed by a tamper-evident audit trail, so every status change and closure is evidenced for auditors.
- Evidence for every change
- Audit-ready by default
- Defensible closure records
Risk analytics across the program
Program-level analytics turn the finding model into trends and priorities, so risk decisions rest on data rather than a single scanner view.
- Trends across the program
- Prioritization by real risk
- Multi-tenant aware analytics
How reporting and analytics work end to end
One read-only intelligence layer turns findings, assets, and SLA timers into KPIs, trends, and risk rankings, scoped on every aggregate and writing nothing back.
Scope every aggregate
Every query attaches the tenant scope from the auth context, so a company only ever sees its own numbers and a platform-wide roll-up still cannot leak across tenants.
Score risk, not just severity
Each asset risk score combines severity weights with the asset criticality factor, and rises when the asset is SLA-breached or externally exposed, so the top-20 shortlist points at real exposure.
Measure SLA against your thresholds
Breach rate and average days to close are measured against the deadlines you set per severity at project, company, or global scope, with the project override outranking the company default.
Trend and compare
Daily created, closed, and open series run over a window of up to 365 days, and any two companies or projects compare on one shape with a computed delta.
Report without mutating the source
The analytics layer persists nothing, so generating a KPI, trend, or risk ranking can never change the records it summarizes, and the audit trail backs every figure.
What your team gets
Numbers leadership can trust
The board slide and the console read from the same scoped source, so posture figures reconcile by design instead of being argued over in the meeting.
Risk ranked by real exposure
Asset, company, and project risk scores weigh severity against criticality and exposure, so the team works the issues that carry the most risk first rather than the loudest scanner.
SLA you can prove
Breach rate, days to close, and a tamper-evident audit trail make compliance defensible, and thresholds you set per severity recalculate every open deadline the moment policy changes.
Frequently asked questions
Can a report change the data it summarizes?
No. The analytics layer is purely downstream and writes nothing. It reads from findings, assets, projects, companies, and a materialized summary view, then returns read-only shapes, so generating a KPI, trend, or risk ranking can never mutate the source records.
How is one tenant kept from seeing another tenant numbers?
Every query attaches the scope from the auth context, so cross-tenant data never leaks, even on platform-wide aggregates. Company and project filters are additive on top, meaning they narrow what scope already allows and cannot widen it.
How is a finding SLA deadline decided?
A waterfall resolves the hour limit per severity: project config first, then company config, then global defaults, then hardcoded values, with a final fallback. The first non-zero value wins, so a project override outranks the company default.
What happens when an admin changes the SLA policy?
Saving a config recalculates the deadline for every open finding in scope inline, and the affected count is returned. When a new deadline lands in the future, the notification state resets so escalation re-fires as it approaches.
See the reporting layer
Walk through SLA, remediation and risk analytics built from one finding model, live.