2.7 Post-Installation Validation Checklist
The checklist below converts “the install finished” into “the install works”. Work through it in order, and sign off each group before moving to the next.
2.7.1 Service Validation
All services report running and healthy.
The version endpoint responds on the API base path.
The interactive API reference loads.
-
The seeding step completed: default policies, widgets and dashboard templates are present.
Sensor schemas are registered.
Logs from every service are visible in the log dashboard, confirming the observability pipeline end to end.
2.7.2 Portal Access and Dashboard Validation
The portal loads at the external FQDN over HTTPS with no certificate warning.
Login succeeds with the seeded administrator account, and that password has been changed.
The default dashboard renders with its widgets present.
A widget can be added, the layout saved, and the saved layout survives a reload.
A second account with a non-administrative role sees the reduced navigation appropriate to that role.
2.7.3 Discovery Execution Validation
Validate at least one execution model, and ideally each model the deployment will actually use.
-
Agentless: create a template with a TLS endpoint sensor, create a task against a known HTTPS endpoint, execute it, and confirm the certificate appears in the inventory with correct source properties.
-
Remote-executed: register a host, deploy to it, run the task, and confirm results arrive with that host recorded as the deployment location.
-
API-triggered: authenticate, create and execute a task through the API, and poll status to completion.
-
Off-grid: generate a bundle, run it on an isolated host, import the result, and confirm the material appears and is scored identically to a network-delivered result.
In every case confirm the ingestion accounting — requested, inserted, updated and skipped counts — matches expectation. A large skipped count on a first scan indicates a schema or configuration problem, not a quiet success.
2.7.4 Analysis and Policy Validation
A discovered material has a criticality level assigned.
A discovered material shows pass or fail against the default policy set.
A deliberately weak test material (for example an undersized RSA key) is flagged as failing.
The summary report generates and exports.
A CycloneDX export produces a valid document.
The history timeline shows a created entry for a newly discovered material, and an updated entry after a second scan that changes its footprint.
2.7.5 Integration Validation
Each configured integration authenticates successfully.
Credentials are masked when the integration is read back.
If EDR host synchronisation is configured, hosts appear in the inventory.
If ticketing or notification integration is configured, a test notification reaches its destination and creates the expected record.
2.7.6 Sign-Off
Close the checklist with a sign-off block recording the installer name, date, platform version, deployment topology, external FQDN, execution models validated, and any item deliberately skipped with a reason. An item skipped with a stated reason is a decision; an item skipped silently is a defect waiting to be found in production.