Skip to content
Region
English | Global
Request a demo

See What Is Verified. Keep The Gaps Visible.

Govern patch scope, recorded outcomes and independent review alongside the tools that deploy your updates.

Fictional workspace · actual product recordsDeclared baseline

2 assets · 1 required update

1 verified1 unknown
2 of 3 active inventory assets included
Payroll gatewayIn scopePayroll portalIn scopeOther inventoryOutside this baseline

Baseline coverage and inventory inclusion are different measures.

A successful job is only part of the answer.

Scanner observations, installation reports and verified outcomes answer different questions. In the payroll example, the gateway has a reviewed result while the portal remains unknown. The baseline stops one successful update becoming a whole-inventory claim. Vulnerability findings can provide context; routine updates need neither an invented finding nor a CVE.

  1. Define what must be maintained.

    Maya selects the published payroll policy, two active assets and update NS-2026-09, targeting version 4.2.

    How it works

    Maya selects the published payroll policy, two active assets and update NS-2026-09, targeting version 4.2. The baseline retains the policy version, 14-day observation freshness and a 30-day policy deadline. These are the example’s requirements, not product-wide defaults.

    Maya · GRC lead
  2. Agree the scope before measuring it.

    An independent eligible reviewer publishes the baseline; its creator cannot self-approve.

    How it works

    An independent eligible reviewer publishes the baseline; its creator cannot self-approve. Publication preserves the decision and policy basis. Changed assets or updates require a new baseline, keeping the earlier scope available for review.

    Independent GRC lead or tenant admin
  3. Inspect observations before accepting changes.

    Maya previews JSON observations naming asset, update, source, time, result and report reference.

    How it works

    Maya previews JSON observations naming asset, update, source, time, result and report reference. The capture shows one new observation, no duplicates and one omitted pair. The omitted record stays unchanged: absence means neither a successful update nor disappearance of earlier exposure.

    Maya · Intake reviewer
  4. Give the maintenance work a practical plan.

    Group a compatible update within one environment.

    How it works

    Group a compatible update within one environment. Retain the owner, maintenance window, timezone, test plan, change and rollback references. The payroll package covers the gateway, with an explained ownership override. Moving its maintenance window does not reset the policy deadline.

    Maya · Maintenance coordinator
  5. Record what the deployment team reports.

    The endpoint tool performs installation.

    How it works

    The endpoint tool performs installation. The owner records installed, reboot-pending, failed, rolled-back or unknown execution with job reference and evidence. Maya records the gateway’s installation; it still needs fresh post-execution observations and independent review.

    Assigned implementation owner
  6. Verify the result and follow the remaining gap.

    Alex independently checks the gateway’s fresh observations and evidence.

    How it works

    Alex independently checks the gateway’s fresh observations and evidence. The portal remains unknown. Each asset must satisfy all declared updates to count as verified. New observations can return an earlier decision for review; verification is not a permanent green label.

    Alex · Independent verifier

Inspect The Work Behind The Coverage.

Choose a step to see the real record, the responsible person and the reason for the next action.

1 of 4
You control the pace. Play advances every 12 seconds.

Maya · Intake reviewer

Check the import before accepting its changes.

Maya previews observations from the scanner or patch tool. The preview identifies one new observation and one omitted asset–update pair. She can inspect the proposed change before committing the reviewed import.

Why it matters

A missing row cannot quietly turn an unknown result into a successful update.

One omitted pair remains unchanged; the screenshot shows an import preview.

Product screen
Check the import before accepting its changes.

Fictional workspace · English interface

Read the complete walkthrough
  1. Check the import before accepting its changes.

    Maya · Intake reviewer

    Maya previews observations from the scanner or patch tool. The preview identifies one new observation and one omitted asset–update pair. She can inspect the proposed change before committing the reviewed import.

    A missing row cannot quietly turn an unknown result into a successful update.

    One omitted pair remains unchanged; the screenshot shows an import preview.

    Open full product screen ↗
  2. Make the denominator visible.

    Maya · GRC lead

    The published payroll baseline names two assets and update NS-2026-09. Maya can see its policy reference, freshness requirement and service-level deadline alongside the population being assessed.

    Everyone can tell which assets and updates a coverage statement includes before relying on it.

    Two asset–update pairs; two of three active inventory assets are included.

    Open full product screen ↗
  3. Separate reported installation from verification.

    Maya · Maintenance coordinator

    Maya coordinates the maintenance package and records an installed result with supporting evidence. Alex independently verifies that asset’s outcome. The per-asset view keeps the verified gateway separate from the portal’s unknown result.

    The reviewer can distinguish an owner’s report from independently checked proof.

    PlanGRC records and verifies outcomes. Your deployment tool performs installation.

    Open full product screen ↗
  4. Keep unknown coverage in the conversation.

    Maya · GRC lead

    The coverage view shows one verified pair and one unknown pair. Maya follows up on the missing result with the accountable owner. Reviewed exclusions and deferred exposure have their own categories instead of counting as verified work.

    A useful coverage view shows where to act next and makes the limits of the reported result clear.

    One verified, one unknown. This is declared-baseline coverage, not whole-inventory compliance.

    Open full product screen ↗

Read the result with its denominator.

Coverage counts assets across all their required updates. With one required update, this example’s two assets also represent two asset–update pairs. Inventory inclusion is a separate measure.

Verified
1 asset

The payroll integration gateway has an independently reviewed result.

Unknown
1 asset

The payroll access portal still needs a verified outcome.

Baseline
2 assets · 1 update

The published scope names update NS-2026-09 and target version 4.2.

Inventory included
2 of 3 active assets

The remaining inventory asset is outside this baseline’s assessment.

Fictional payroll baseline: one asset verified, one unknown. Two of three active inventory assets are included.Fictional workspace · English interface

Make the next action clear, even when the answer is incomplete.

Distinct states help the team choose the right follow-up.

Unknown needs investigation.

Missing observations, stale sources and conflicting results need attention. Check the source or obtain fresh proof. Where uncertainty and a deferral coexist, the coverage view keeps uncertainty visible.

Deferred remains exposure.

An approved delay retains its reason, compensating controls and expiry. It does not become verified work or move the original policy deadline.

Exclusion needs its own evidence.

Review non-applicability independently. A superseded update is excluded only when its declared replacement is verified. An entirely excluded asset is not shown as verified.

Constrained systems still need an owner.

No available fix, end of support or supplier-managed maintenance requires an open, owned follow-up issue and a future review date. The constraint itself is not acceptance or remediation.

Your tools deploy. PlanGRC retains the governance record.

PlanGRC coordinates scope, responsibility, evidence and review. It does not scan or install software. Scanner-provider contracts and readiness checks do not establish live integrations. Confirm your tools’ supported intake path before operational use.

Meet the people involved

Questions Worth Asking.

What can we import?

Patch observations use the baseline-specific JSON template and preview. The separate vulnerability workflow supports reviewed CSV finding intake, asset matching and duplicate checks. Finding intake and patch verification are different processes.

What happens when observations change?

Earlier history remains. New observations can invalidate the affected verification or applicability decision and return the work for review. An omitted row stays unchanged; it does not close an outcome.

Does closing a package close everything related to it?

No. Patch closure checks current outcomes and evidence, then follows the shared issue closure review. Linked findings, risks and supplier records retain their own decisions; they are not automatically closed.

What can we take into a review?

Export a dated JSON record containing the baseline, policy basis, source history, evidence references, maintenance context, deadlines and exceptions. It preserves the declared scope; it is not a whole-estate compliance certificate.

Start with one maintenance scope your team can explain.

Bring a policy, asset group and required update. Walk through intake, ownership, verification and remaining gaps in a focused demo.

Request a demo