Technical postures
A technical posture measures a fleet of assets against a technical baseline — a CIS Benchmark, a hardening guide, any check-shaped framework — and keeps measuring. Where an audit is a point-in-time evaluation signed by a person, a technical posture is a living scoreboard: scripts, scanners and operators keep pushing results, and the platform shows the latest state of every check on every asset.
Where to find it
Section titled “Where to find it”Compliance → Technical postures in the sidebar.
Creating one
Section titled “Creating one”A technical posture takes a Name, a Domain, an optional Perimeter, and the Framework whose assessable requirements become the check list. Two settings shape the measurement:
- Selected implementation groups — narrows the check list when the benchmark tags its recommendations, for example the Automated versus Manual split in a CIS Benchmark.
- History depth — how many results are kept per check per asset, ten by default. Older results are pruned as new ones arrive.
Leave Create a related findings assessment ticked and a findings binder is created alongside, ready for the failures you act on.
The measurement cube
Section titled “The measurement cube”Think of the posture as a three-dimensional grid: checks from the framework, assets under measurement, and history per cell. The grid is deliberately sparse — a cell only exists once something has measured it. Assets can be enrolled explicitly or appear automatically the first time results arrive for them.
Each result carries one of five values — Pass, Fail, Not applicable, Error or Not checked — alongside the observed and expected values and a message when the source provides them. The current posture is the latest result in each cell, and everything on the page is computed from it.
Three read-outs sit at the top: Pass rate, computed over Pass and Fail only so errors and unmeasured cells cannot dilute it; Measured checks, how much of the grid is filled; and Assets covered.
The tabs
Section titled “The tabs”| Tab | What it holds |
|---|---|
| Overview | Pass rate, the run trend chart, the current posture breakdown, and a per-asset filter |
| Assets | Per-asset roll-ups, with CSV and XLSX export and the ability to add or purge an asset column |
| Runs | The ingestion log — every run with its tool, check counts and pass/fail split |
| Action plan | Every check whose current result is not Pass, failures first |
| API | A ready-to-copy example for pushing results from a scanner |
Tree view shows the framework hierarchy with the results underneath, and is where a human edits check results per asset.
Getting results in
Section titled “Getting results in”Every route produces a run, and runs are what make drift visible — the Overview trend chart plots the pass rate across them.
- New manual run on the Runs tab, for checks a person performs.
- Import results accepts CSV, XLSX and OCSF Compliance Finding JSON. A mapping dialog binds scanner columns and result values, decides how colliding rows aggregate, and targets one or more scoped assets.
- The API — a scanner posts JSON to the assessment’s upload endpoint. Re-using the returned run identifier patches the same run.
Failures and remediation
Section titled “Failures and remediation”The Action plan tab lists everything not currently passing — failures, then errors, then unchecked and not-applicable cells. Each line can be turned into a finding in one click.
Findings deliberately do not live on the posture itself. They are created in the linked findings binder, because a measurement is ephemeral — overwritten by the next run, eventually pruned by the history depth — while remediation needs a stable life of its own with a status, an owner, an ETA and linked applied controls. The link stays visible in both directions, and a fix is verified by the next run turning the check green, not by anyone declaring it done.
Posture or audit?
Section titled “Posture or audit?”Use an audit when a human has to weigh evidence and sign off. Use a technical posture when a tool can answer the question and you want it answered often. The two share the same framework catalog, so a benchmark imported once can back both.
Related
Section titled “Related”- Audits — the point-in-time counterpart.
- Assets — the fleet under measurement.
- Frameworks — where the check list comes from.
- Feature flags — enabling the module.