Product
Defend every decision.
The product turns a governed, reusable control library into an assessment of one described solution. It derives the baseline from the original applicability relationships, keeps each decision dimension separate, and holds the rationale next to the conclusion.
- Scope you can explain, control by control.
- Decisions that cannot silently inherit one another.
How it works
The workflow
Four steps, in a fixed order, from solution facts to a defensible conclusion. Each one produces a record the next step depends on, which is what makes the result explainable afterwards.
- 01
Describe the solution
The assessment boundary is a recorded set of facts about one solution, not a questionnaire preference.
Selection follows the original taxonomy in a fixed order. You choose the asset group, then the subgroup, then a risk tier only where the governed glossary makes tiering applicable to that subgroup. A required solution profile follows, and it stays attached to the assessment as the explanation for everything derived from it.
The solution profile records
- Deployment model, service model, provider and the exact services in use
- Regions, data classification and residency
- Regulated use, electronic-record expectations and external exposure
- Architecture patterns, criticality, recovery objectives and integrations
- Privileged paths, administrative tenants, exit planning and deletion expectations
Rule Asset groups cover Org and Data, Applications, Infrastructure, Devices, Digital and Other Asset. Cloud is one context the profile can describe, never the boundary of the product.
- 02
Derive the governed baseline
The baseline comes from the original applicability relationships, so every control in scope can be explained by the link that put it there.
The matrix link recorded against the selected subgroup is the authoritative initial scope. Risk tier is a second, dependent dimension that applies only to the tier-classified application subgroups: tier-unrestricted controls remain, matching-tier controls remain, and controls restricted to another tier are excluded. Cloud, provider, data-classification and regulated-use answers are later overlays on top of that scope.
Derived signals behave as review prompts
- Provider, multi-cloud, cloud-native, API and architecture signals
- Privacy, residency, regulated-use and electronic-record signals
- External exposure, resilience and AI signals
Rule A derived signal never marks a control implemented, never removes a control the matrix link placed in scope, and never creates an approved framework crosswalk. It raises a question for a person to answer.
- 03
Record evidence-led decisions
Each control carries its own decisions, its own rationale and its own evidence references.
Applicability, implementation, design and operating effectiveness, and maturity are recorded separately against every control in scope. Exclusions require a rationale rather than a silent removal. Assessor notes and evidence references sit with the decision they support, so a reviewer reads the conclusion and the reason for it in the same place.
Recorded per control
- Applicability: in scope, out of scope, or not applicable with rationale
- Implementation: implemented, partial, not implemented, or not assessed
- Design effectiveness and operating effectiveness as distinct judgements
- Maturity on the governed scale from 0 Absent to 5 Optimizing
- Evidence references, exclusion rationale and assessor notes
Rule For an AI-enabled solution, the AI security checklist and the EU AI Act obligation register are two separate records with independent status, evidence and review.
- 04
Review and act
Unresolved work stays visible instead of being averaged away.
Dashboards for controls in place, gaps, maturity, domain coverage and action priority are driven by the same filters as the checklist, so the counts on a summary reconcile with the list behind them. Priority is produced by transparent rules over recorded facts. Named views make a recurring analysis scope repeatable across assessments.
Review surfaces
- Open gaps, exclusions and controls awaiting a decision
- Maturity distribution rather than a single headline figure
- Domain coverage and action priority across the filtered set
- Persistent named views for recurring qualification scenarios
Rule Approval authority is separate from authorship. Where independence is required, the person who recorded a decision cannot be the person who approves it.
Separated decisions
Six separate dimensions
Collapsing these into a single status field is the fastest way to produce an assessment nobody can defend. They are stored separately, reviewed separately, and reported separately.
- Applicability
- Whether a control is in scope, out of scope, or not applicable, with the rationale for the answer.
What this dimension never does
Out of scope is never inferred from a profile answer. It is a recorded decision with a reason.
- Implementation
- Whether the control is implemented, partial, not implemented, or not yet assessed.
What this dimension never does
An implemented state is never produced by a derived signal, an overlay, or a framework mapping.
- Maturity
- A level from 0 Absent to 5 Optimizing for how the control is operated, held apart from whether it exists at all.
What this dimension never does
A maturity average never stands in for implementation, and never conceals an unimplemented key control.
- Evidence
- The references, notes and activity trail that support the conclusion recorded against the control.
What this dimension never does
Missing evidence is never treated as satisfied. It stays open and countable.
- Source assurance
- Which source and version a control or mapping came from, and the review state of that mapping.
What this dimension never does
An imported legacy reference is never reported as approved current coverage.
- Legal review
- Legal applicability, compliance state and approval for obligations that require a qualified reviewer.
What this dimension never does
A security control decision never marks a legal obligation compliant or approved.
Worked example
A control record in depth
One control from an assessment, with the reason it is in scope, the dimensions recorded against it, the evidence behind them, and the next action it is waiting on.
01 Control record and reason
Included by Applications › Business Applications at risk tier RT-2. The recorded data classification and regulated use added review context; no overlay removed the control.
Decision dimensions, kept separate
Legal review is recorded on its own obligation checklist. Nothing on this record changes it.
02 Evidence and activity
Approved data classification record, linked verified
Handling procedure sign-off, not yet attached open
Baseline derived from the governed control library 12 Jan
Reason for inclusion recorded by the assessor 18 Jan
Source review verified against baseline rev 4 22 Jan
Evidence request open with the data owner 29 Jan
03 Reviewer and next action
Open work is ordered by stated rules. No recommendation is generated without an explanation.
Export
Exports and their limits
A filtered library scope or an assessment result exports as CSV, so the set you reviewed is the set that leaves the workspace.
The relational library is the system of record. A spreadsheet is treated as a controlled exchange format and a portable view of an assessment; it is deliberately not where applicability or version logic lives. Wider governed import, export and reporting is defined work rather than a current capability, and this page does not present it as one.
An export carries its context
- The filter that produced the set
- The source and version behind each control
- Decision states, rationale and evidence references
- The review state of each mapping, kept distinct from coverage
Reassessment
Reassessment and baseline change
Solutions change, and so do baselines. Neither changes an assessment quietly.
-
A newer baseline never migrates an assessment on its own
When a newer internal baseline takes effect, an active assessment affected by it receives an accountable owner, a due date and a recorded decision with rationale. Escalation is derived from the due date and the decision state rather than set by hand.
-
Immaterial change touches unchanged populations only
Where the delta does not change the control population, an independently authorized migration updates only the unchanged set and records population-hash evidence of exactly what moved.
-
Material change requires a reviewed plan
Where the change is material, every control is dispositioned as retain, add or retire in an immutable plan bound to exact versions and hashes. The plan requires independent review, preserves retired decisions and their evidence, and is applied as one atomic operation.
-
History is append-only
Approvals and assessment changes are written as append-only records, and an assessment can be fixed as an immutable, hash-bound snapshot of what was concluded at a point in time.
Where a control record still needs editorial review, or a mapping has not been approved, the assessment says so. Unresolved work is a visible state, not a rounding error.
How the control sources are governedNext step
Bring your own scope
See the workflow against your own solution scope. Access begins with a guided review of that scope and your assurance requirements.