A vulnerability management platform produces an enormous amount of data. Open finding counts, severity distributions, SLA status, risk rankings, trend lines, taxonomy breakdowns, and team throughput all live inside the same system. The hard part is not generating these numbers. The hard part is deciding which numbers each person sees first when they log in.
That decision is exactly where most analytics screens fail. A single fixed page tries to serve an analyst, a manager, and an executive at the same time, and it serves none of them well. The analyst scrolls past portfolio risk summaries to find open-finding counts. The executive scrolls past per-asset detail to find a clean KPI row. Everyone adapts to the screen instead of the screen adapting to them.
PMAP takes the opposite position. Its dashboard layer is a security dashboard builder in the literal sense. Every authenticated user composes their own named, persisted widget canvas from a fixed library of widget types, sets one as the default landing view, and rearranges it whenever their focus changes. No shared template gets edited. No other user is affected. This article explains how that canvas is built, what each widget shows, how layout and scope persist, and why per-user isolation is a structural property rather than a setting you have to remember to turn on.
For the program-level picture of how analytics and reporting fit a vulnerability management practice, this piece sits under the pillar on vulnerability risk analytics and reporting. Here the focus is narrower and more mechanical. We are looking at the canvas itself.
Why One Fixed Analytics Page Satisfies Nobody
Roles do not consume vulnerability data the same way, and pretending they do creates friction at every login.
A security analyst opening the platform in the morning wants a fast operational read. Current open findings, how many are urgent or critical, where SLA status stands today, and a short trend that tells them whether the backlog is growing or shrinking. They do not need a portfolio-wide company risk ranking to start their day.
A manager or team lead has a different question. They track posture across a portfolio. They want a dashboard scoped to a single company or project, with company-risk and SLA widgets relevant to the engagements they own. The analyst’s open-finding tile matters less than the comparative shape of risk across the work they are accountable for.
An executive wants the least detail and the most signal. A minimal KPI card row that answers “are we on track” in one glance, with the ability to switch to a risk-ranking view only when a specific question comes up. Forcing an executive through an operational console is how dashboards lose their most important audience.
A platform administrator or power user sits across all of these. They maintain several thematic dashboards, perhaps a weekly review canvas and a vendor posture canvas, and switch between them depending on the meeting they are in.
One fixed page cannot be all of these at once. Whatever default the product team picks is wrong for three of the four personas. PMAP resolves this by making the canvas personal. The metrics are shared and authoritative. The arrangement of those metrics belongs to the individual.
A Dashboard Is a Named, Persisted Widget Grid
The core abstraction is simple and worth stating precisely. In PMAP a dashboard is a named, ordered grid of widgets. Each widget maps to exactly one analytics data type and carries its own configuration. That configuration includes its grid position, its chart type where applicable, its date range, its result limit, and an optional company or project scope override.
The dashboard record itself is small. It holds an identity, the owning user, a name, a default flag, the layout array, and an optional saved filter object. Everything visual is reconstructed from that layout array on load. When a user opens the platform, their default dashboard is fetched, the layout array is read, and each widget fires its own analytics query in parallel. A widget query runs only when that widget type is present in the active layout. Nothing fetches data the canvas is not going to display.
This separation is deliberate. The dashboard domain owns layout records and nothing else. It does not compute a single metric. All metric computation is delegated to the analytics domain. The dashboard layer is a composition and configuration layer that decides what to show and where, then asks analytics to produce the numbers. That boundary keeps the two concerns clean. The canvas can change freely without touching aggregation logic, and aggregation logic can improve without disturbing anyone’s saved layout.
The practical consequence is that a dashboard in PMAP is cheap to create, cheap to change, and entirely yours. It is a saved view definition, not a copy of data.
The Eight Widget Types and What Each Shows
The widget library is a fixed set of eight types. Each one answers a specific question and pulls from a specific analytics source. Knowing what each shows is the fastest way to compose a canvas that earns its place on your screen.
KPI cards give the single-glance headline row. This is the widget executives pin first. It surfaces the high-level counts that answer whether the program is on track without any drill-down required.
Severity distribution breaks findings down by severity. It tells you the shape of risk in the current scope, so you can see at a glance whether your open work is concentrated in critical and high or spread across lower severities.
Status distribution breaks findings down by workflow status. Where severity answers “how bad,” status answers “where in the lifecycle.” It shows how much work is open, in progress, or resolved across the current scope.
Findings trend plots findings over a lookback window. This is the widget that answers the question every backlog owner cares about, namely whether the trend is going the right way. By default it looks back over a 30-day window, and that window is configurable per widget.
Top risk assets ranks the assets carrying the most risk. It points attention at the specific machines or services that deserve remediation effort first, rather than treating the estate as undifferentiated. The number of rows it returns is configurable.
Company risk distribution is the portfolio view. For managers and administrators who oversee multiple companies, it shows how risk is spread across them, which is exactly the comparative read a single fixed analyst page never delivers well.
SLA overview surfaces SLA status as a first-class widget. It is the operational pulse that tells a team whether commitments are being met across the current scope, and it belongs on nearly every operational canvas.
Project risk summary rolls risk up by project. For engagement-oriented teams, especially consultancies running multiple assessments, it frames risk in the unit of work the team actually plans around.
Each of these eight types routes to a defined analytics call on the server. KPI cards, severity distribution, and status distribution all draw from the same dashboard aggregation. Findings trend draws from the trends aggregation. Top risk assets, company risk distribution, SLA overview, and project risk summary each map to their own dedicated analytics method. The routing is enforced on the server, and the eight-type set is validated in two places. The storage layer recognises only these eight widget-type constants, and the data-fetch layer rejects any unknown type outright. Ask for a widget type that is not in the catalog and the request is refused rather than silently producing nothing.
The eight types are not a coincidental list. They map to the questions the four personas actually ask. The mechanics here cover how those numbers are displayed. For how the underlying metrics are defined and read, including SLA breach rate and how an asset risk score is built, see the companion piece on the KPIs and SLA dashboards executives actually read.
Multi-Dashboard Workspaces and the Default View
A single canvas is rarely enough. The same person wears different hats in a week, and PMAP supports that directly. Each user can hold an unlimited number of named dashboards. A weekly review canvas, a vendor posture canvas, a deep operations canvas, and a stripped-down executive view can all coexist under one account.
Switching between them happens from a selector in the header. The selector lists every dashboard the user owns, with the default surfaced first and the rest ordered by recency, so the most relevant views are always at the top. From the same control a user creates, renames, or deletes a dashboard. Creating a new one opens an inline modal that asks for a name. Everything else can be configured afterward.
One dashboard per user is flagged as the default. This is the view that loads automatically on login, the one a user reaches without a single click. Promoting a dashboard to default is a one-click action, available only when the active dashboard is not already the default, which keeps the control from being redundant.
The benefit of this model is that nobody has to compromise. The executive’s default can be a clean KPI row while the analyst’s default is a dense operational grid, and both live in the same platform without conflict. The default is a personal choice, not a product decision imposed on everyone.
Why Only One Dashboard Can Be Default
The default flag carries an invariant. At most one dashboard per user may be marked as the default at any moment. This is not a soft convention. It is enforced transactionally across every path that can set a default.
There are three such paths. Creating a dashboard with the default flag set, updating an existing dashboard to become the default, and the explicit set-default action all clear any existing defaults before they apply the new one. Because the clear and the set happen inside the same transaction, there is no window in which a user has two defaults or zero defaults. The system either has exactly one default for that user or it is mid-transaction and about to.
This matters more than it first appears. The default dashboard determines what every login shows. If two dashboards could both claim default, the landing view would be ambiguous and the experience would feel unpredictable. The transactional invariant guarantees a single, deterministic answer to “what loads when I sign in.” It is a small rule with an outsized effect on perceived reliability.
Layout Persistence That Survives Sessions
A dashboard you have to rebuild every morning is not a dashboard. PMAP persists the full layout server-side, so the canvas you arranged is the canvas you return to, on any device.
What gets saved is comprehensive. Every widget’s grid position is stored as four values, its column and row coordinates plus its width and height. Alongside position, each widget persists its chart type, its date range, its result limit, and any per-widget scope override. The dashboard’s saved filter defaults are persisted in the same save operation. Pressing the save action writes the current arrangement as a layout array, and that array is what gets read back on the next load.
Because persistence is server-side rather than browser-side, the layout follows the user rather than the machine. Sign in from a laptop, arrange a canvas, sign in later from a different browser, and the same grid appears. There is no local cache to clear, no per-device drift, and no surprise when you switch hardware.
The width values are bounded to a small grid, which keeps layouts coherent and predictable across screen sizes rather than allowing widgets to sprawl into unreadable arrangements. The chart type field accepts the standard set of bar, line, pie, and table, so a widget that supports multiple representations remembers the one you chose. Nielsen Norman Group’s dashboard design research makes the case that consistent, glanceable arrangement is what lets a dashboard be read at a glance rather than studied, and persistence is what makes that consistency last beyond a single session.
Global Filters vs Per-Widget Scope Overrides
Scope is where a configurable canvas earns its flexibility. PMAP gives you two levels of control, and they compose in a sensible way.
At the canvas level there is a global filter bar. It carries date-from and date-to pickers, a company picker, a project picker that narrows to the selected company, severity pills, a clear-all action, and a refresh. Set a company and a date range once on this bar and the filter state propagates to every widget query on the canvas. For a manager building a portfolio view, this is the fast path. One filter, applied everywhere, no per-widget fiddling.
At the widget level there is an override. Any individual widget can carry its own company or project scope. When a widget declares its own scope, it uses that. When a widget does not declare a scope, it falls back to the dashboard-level filter defaults. The rule is a clean fallback. A per-widget scope wins where it is set, and the global filter fills in everywhere it is not.
This composition lets a single canvas mix scopes intentionally. You can build a dashboard where most widgets reflect a company-wide date range while one specific widget is pinned to a single high-stakes project. The global bar handles the common case and the per-widget override handles the exception, without forcing you to choose one model for the whole canvas.
The saved filter defaults are stored alongside the layout, so the scope you set is remembered the same way the arrangement is. A canvas scoped to a particular company opens scoped to that company next time, with no re-entry.
A Sensible Default Layout for New Dashboards
A blank canvas is intimidating, and an empty dashboard is useless until it is configured. PMAP avoids both by seeding new dashboards with a working layout.
When a dashboard is created without an explicit layout, the service injects a default set of six widgets. That seed is fixed and deliberate. It places KPI cards across the top as the headline row, a severity distribution and a status distribution side by side beneath it, a findings trend over a 30-day window, a top risk assets widget, and an SLA overview. The grid positions are predetermined so the result is a coherent, readable canvas the moment it is created.
The intent is immediate productivity. A user who creates a new dashboard is looking at meaningful vulnerability data before they have customised anything. They can keep the seed as-is, add widgets from the library, remove what they do not need, or rearrange the grid. The default is a starting point, not a constraint. It exists so that the first experience of a new dashboard is a useful view rather than an empty grid asking to be assembled.
This seed also reinforces the persona model. The six widgets it ships with cover the operational read an analyst needs on day one. Other roles trim or expand from there, but nobody starts from nothing.
Where the Numbers Come From
It is worth being precise about a boundary that shapes the whole feature. The dashboard layer does not compute metrics. It owns layout. Every number a widget displays is produced by the analytics domain.
When a widget loads, it calls the analytics service through the appropriate method for its type. KPI cards, severity distribution, and status distribution share one aggregation call. Findings trend, top risk assets, company risk distribution, SLA overview, and project risk summary each have their own. The dashboard layer’s job is to know which call belongs to which widget type and to forward the relevant scope and parameters. The actual aggregation SQL, the risk scoring, and the trend math all live in analytics.
This separation has a direct performance benefit. The analytics layer is backed by materialized views that the server refreshes on a fixed cycle. Every five minutes a background process refreshes the wave-visibility materialized views, so widget reads draw from pre-aggregated data rather than recomputing heavy aggregations on every page load. The practical effect is that widget data is at most around five minutes stale, and the cost of that freshness is paid once in the background instead of on every render. A dashboard with eight widgets does not trigger eight expensive aggregate scans on load. It reads from views that are already warm.
That trade is appropriate for a management dashboard. The numbers do not need to be accurate to the second to be useful for triage, planning, and reporting, and the refresh cycle keeps them current enough while keeping the canvas fast. The defensibility of those numbers as program measurement aligns with the measurement guidance in NIST SP 800-55 and ISO/IEC 27004, both of which frame security metrics as something to be defined, computed consistently, and reviewed rather than improvised per request.
Per-User Isolation by Design
The most important security property of the dashboard feature is also its simplest to describe. Dashboards are private to the user who owns them, and that privacy is structural rather than configured.
Every repository query in the dashboard layer filters by the owning user. Fetching a dashboard by its identity requires both the dashboard identity and the user identity to match. Deleting a dashboard requires the same pairing. There is no code path that returns a dashboard to anyone other than its owner. If one user requests another user’s dashboard by its identity, the response is a not-found, because from the requesting user’s perspective that record does not exist.
This is a stronger guarantee than a permission check that could be misconfigured. Cross-user access is not blocked by a rule you have to set correctly. It is impossible by construction, because the queries themselves never reach across the user boundary. A dashboard is not a shared resource with access controls layered on top. It is a user-scoped record that other users have no mechanism to see.
The consequence is reassuring for both the individual and the administrator. A user can build experimental dashboards, name them whatever they like, and arrange them however they want, with full confidence that nobody else is looking at their canvas and nobody else’s actions will reshape it. There is no shared dashboard to break, no global default to fight over, and no risk that one person’s layout choices leak into another’s view. Note that this user-scoping is distinct from the tenant scoping applied to the data itself. The analytics layer attaches the caller’s tenant scope to every aggregate query, so even though a user controls their own canvas freely, the findings and assets that fill it are always confined to what that user is entitled to see.
How PMAP Composes a Canvas Without Shared State
Step back and the design reads as a single coherent idea. PMAP composes dashboards out of independent, user-owned pieces, and it never asks those pieces to share mutable state.
A dashboard is a layout record. A widget is an entry in that record pointing at one analytics data type. The numbers come from analytics, refreshed on a fixed cycle. Scope flows from a global filter with per-widget overrides on top. The default flag is held to exactly one per user by transaction. And the whole structure is filtered by user identity at the data layer, so no two users ever touch the same canvas.
There is no central template that an edit could break for everyone. There is no shared default that one person could change for the team. There is no widget that fetches data the canvas will not show. Each of these is a deliberate absence, and together they produce a feature that is flexible for the individual and safe for the platform. A power user can maintain a dozen thematic dashboards and an executive can keep exactly one, and neither configuration costs the other anything.
That is what a configurable security dashboard should be. Not a single screen everyone tolerates, but a personal canvas everyone actually uses. For teams that want to compare entities side by side rather than monitor a single scope, the comparison analytics workspace extends this same data into benchmarking views, and saved views carry the same persistence philosophy into other parts of the platform. To build your first canvas end to end, follow the practitioner guide on building a configurable dashboard with widgets.
Explore the configurable dashboards datasheet and give every role its own landing view.
Frequently Asked Questions
How many widget types can I add to a PMAP dashboard?
PMAP ships eight widget types. They are KPI cards, severity distribution, status distribution, findings trend, top risk assets, company risk distribution, SLA overview, and project risk summary. Each maps to one analytics data source, and the eight-type set is validated on the server, so a request for any type outside the catalog is rejected rather than rendering an empty widget.
Are dashboards shared across my team or private to each user?
They are private to each user. Every dashboard query filters by the owning user, and fetching or deleting a dashboard requires both the dashboard identity and the user identity to match. Cross-user access is structurally impossible, so one user requesting another user’s dashboard receives a not-found response. No administrator-managed shared dashboard exists, and no one else can see or change your canvas.
Does my dashboard layout persist between sessions and devices?
Yes. The full layout is stored server-side, including each widget’s grid position, chart type, date range, result limit, and any per-widget scope override, plus the dashboard’s saved filter defaults. Because persistence is server-side rather than browser-based, the same canvas appears when you sign in from a different browser or device, with no local cache to clear.
What happens when I create a new dashboard without configuring it?
It is seeded with a default six-widget layout so you are productive immediately. The seed places KPI cards, a severity distribution, a status distribution, a findings trend over a 30-day window, top risk assets, and an SLA overview in a predetermined arrangement. You can keep the seed, add widgets from the library, remove ones you do not need, or rearrange the grid from there.
Can different widgets on one dashboard use different scopes?
Yes. The canvas has a global filter bar for company, project, and date range that applies to every widget by default. Any individual widget can also carry its own company or project scope override. When a widget declares its own scope it uses that, and when it does not it falls back to the global filter. This lets a single dashboard mix a portfolio-wide view with one widget pinned to a specific project.
Why can only one dashboard be set as the default?
The default flag is held to a strict invariant of at most one default per user, enforced transactionally. Whenever a dashboard is created as default, updated to default, or promoted to default, any existing default is cleared in the same transaction before the new one is set. This guarantees a single, deterministic landing view on login, with no ambiguous state where two dashboards or none claim the default.
How current is the data shown in dashboard widgets?
Widget data is at most around five minutes stale. The analytics layer is backed by materialized views that a background process refreshes every five minutes, so widgets read from pre-aggregated data instead of recomputing heavy aggregations on each load. This keeps a multi-widget canvas fast while keeping the numbers current enough for triage, planning, and reporting.
