From policy requirements to the right technical controls
The problem it solves
A policy says what must be true. An engineer needs to know which setting to check, on which systems, and how. Today, policies are translated clause by clause, and the reasoning rarely outlives the spreadsheet. When the policy changes, nobody can easily tell which controls it affects.
Guardian Nexus maps each requirement to existing catalogue controls, and generates a new technical control specification where none fits. Every control it proposes links back to its source clause and carries a review state.
What goes in
- Policies, regulations and baselines, with version and source.
- A control catalogue to reuse.
- Context about the systems in scope.
What Nexus does
-
Parse the policy
Split the source into clauses, keeping identifiers, hierarchy and original wording.
-
Resolve entities
Tag each phrase as an identity, resource, action, mechanism or risk, and resolve aliases to one registry.
-
Interpret the requirement
Identify the obligation, who it applies to, its conditions and its exceptions.
-
Reuse or generate
Map to catalogue controls; where coverage is missing or partial, specify a new control.
-
Reconcile
Merge both routes, remove overlap, flag conflicts and gaps, and label each control by origin.
-
Review and approve
People approve, amend or reject each mapping and specification before Nexus versions it.
We agree per engagement which steps are automated and how much of each route a demonstration covers.
Two ways to resolve a requirement
| Reuse an existing control | Generate a new specification | |
|---|---|---|
| When | A catalogue control covers the requirement | No catalogue control fits, or only partly |
| What Nexus does | Maps the requirement to a versioned catalogue entry | Writes a reviewable technical control specification |
| What you see | Catalogue control ID, requirement link, rationale and coverage | Specification ID, requirement link, intended check, parameters and assumptions |
| Origin label | catalogue |
generated |
A requirement can use either route or both. One requirement can map to several controls, and one control can satisfy several requirements.
A generated specification is not an executed check. It describes what to check. Checking real systems is Guardian Angel’s job, and Angel is in development.
What Nexus produces
Nexus tags each clause by the elements a control must address. Here, an IM8 least-privilege clause is tagged by identity, resource, action, mechanism and risk.
Each output control records its origin (catalogue or generated), the catalogue ID or specification, the source clause and version, and its review status. It does not claim any machine has been assessed.
The IM8 policy-to-control explorer
Zennite’s IM8 Policy-to-Control Explorer applies Nexus to the Singapore Government’s harmonised IM8 control catalogue.
For each clause, the explorer shows:
- Control lineage: obligation, policy, controls, implementations and evidence, with counts of risks, deviation hooks, conflicts and crosswalks.
- Tagged source text: the catalogue’s own wording, with every element highlighted.
- Policy controls: strength, control type, evaluation mode (automated,
semi-automated or manual) and a formal condition, for example
forall input in application.inputs: input.validated_against_schema == true. - Evidence contracts: what each control needs observed, where it comes from, and whether missing evidence means unknown or violation.
- Control implementations: how the catalogue says to realise each control.
- Deviation hooks and conflicts: where the text allows exceptions, and how precedence rules resolve cross-clause conflicts.
- Applicability and crosswalk: the level each clause carries in each system security plan profile, and references to IM8, NIST SP 800-53, MVSP and SLSA.
Nexus marks every policy control in the explorer as inferred: derived from the source text and awaiting human review. The explorer shows Nexus output, not Nexus internals.
Modules
Nexus has six modules. Parsing, which produces the output above, and catalogue mapping and generation are available to demonstrate; the other four are in development.
Policy ingestion and parsing
Extracts clauses and their elements with LLM assistance, traceable to the source text.
Available to demonstrate
Control knowledge graph
Links policy intent, risk and asset-specific controls in one graph. The explorer’s entity registry is its first layer.
In development
Catalogue mapping and generation
Reuses the right catalogue controls and specifies new ones where the catalogue falls short.
Available to demonstrate
Control compiler and adapters
Compiles approved controls into checks, scripts and Group Policy, Ansible, Intune or API artefacts.
In development
Deterministic validators
Reads actual state, compares it with expected state and reports confidence in each result.
In development
Evidence vault and workflow
Manages approvals, exceptions, rollback, audit trails, evidence packs and the deviation lifecycle.
In development
Where Nexus meets Angel
Nexus will hand approved, versioned control definitions to Guardian Angel and link Angel’s findings back to the source clause. Today’s demonstration does not include this exchange.
What you can see today
A scoped demonstration on a policy or control family you choose: the clause catalogue, entity resolution and control mapping, with each output’s origin and review state. Bring your own requirements or use a public framework such as IM8.