Compliance · Control mapping
WorkflowCross-industryMapping policy obligations to controls with one reviewed workflow
Every policy change raises the same question: which controls does this touch, and which obligations have no control at all? One workflow can do the first pass and hand a person a short list to confirm.
Valnora & Elric team5 min read
- WorkflowsThe visual builder: blocks, models and integrations wired into agent logic.
- Knowledge BasePolicies and procedures agents search before they answer.
- TablesA database, built in, for cases, queues and decisions.
- FilesOne store for documents your team and agents share.
- LogsEvery run traced block by block.
- DashboardsCharts, tables and KPI tiles over governed metrics.
A control library and a policy set describe the same organisation in two languages. Policies say what must be true. Controls say what someone actually does, how often and with what evidence. Keeping the two in step is a quiet, permanent job, and it gets harder with every policy refresh, new framework or audit finding.
The work has a shape that suits an agent: read a long document, break it into parts, search a library for each part and explain each match. It also has a part that does not: deciding that a control really covers an obligation. This post walks through one workflow, component by component, that does the first and leaves the second to the control owner.
The trigger: a new policy version
The workflow starts when a policy changes. If your document system can call a webhook on publication, use a Webhook trigger. If not, the policy team runs the workflow by hand and attaches the file. A File block reads the document, and AWS Textract or Reducto can extract the text when the policy only exists as a scanned PDF.
Running on each version, rather than on a calendar, matters for the record. Every mapping row carries the policy version it was made against, so an auditor can see which version of the access policy a control was mapped to and when.
Extracting obligations
The first Agent block turns a policy into a list of obligations. Each obligation is one testable statement, quoted from the source with its section number. “Access is reviewed quarterly and revoked within one day of leaving” becomes two obligations, because they would be met by two different controls.
The instructions are strict about three things:
- Quote, do not paraphrase. The reviewer must see the policy’s own words.
- One requirement per line. Compound sentences are split.
- Skip the non-obligations. Purpose statements, definitions and history sections are left out, and the output lists what was skipped so nothing disappears silently.
Searching the control library
Your control descriptions live in a Knowledge Base. A Loop block runs one Knowledge search per obligation and returns the closest controls by meaning, not by keyword. That is the useful part: a policy that says “leavers” still finds a control titled “Joiner, mover, leaver process”.
The search only shortlists. It returns a handful of candidate controls with their descriptions, and nothing is decided yet. Keep the library current, because a stale description produces confident links to controls that no longer work the way they read.
Proposing links and reasons
The second Agent block reads each obligation with its shortlist and proposes one of three outcomes: a full match, a partial match or no match. Every proposal carries a one-line reason that names what the control covers and, for partial matches, what it leaves out.
Partial matches are where the value sits. A control that approves privileged access but says nothing about recording sessions is the kind of gap that survives years of audits because the titles look right. Writing the reason out forces the gap into view.
An Evaluator block then checks the batch for basic quality: every obligation has an outcome, every match has a reason and every quoted clause appears in the source. If the check fails, the batch is flagged rather than sent on.
The reviewer step
A Human block pauses the workflow and sends the proposals to the control owner for that area. The owner accepts, changes or rejects each one, and can add a note. The workflow waits for as long as the review takes.
This is not a formality. The model is proposing; the owner is attesting. Your organisation will rely on the mapping when it answers auditors and regulators, so the person whose name goes next to a link should be the person who runs the control.
What the solution produces
Proposed mappings for review (illustrative)
Record- Obligation 7
- “Access to production systems is reviewed at least quarterly by the system owner.” Source: Access policy v4, section 3.
- Proposed control
- AC-04 Quarterly user access review · full match
- Reason
- Control describes a quarterly owner-led review of production access.
- Obligation 8
- “Privileged sessions are recorded and retained.” Source: Access policy v4, section 4.
- Proposed control
- AC-09 Privileged access management · partial match
- Reason
- Control covers approval of privileged access but says nothing about session recording.
- Obligation 11
- “Shared accounts are prohibited.” Source: Access policy v4, section 6.
- Proposed control
- No match found · flagged as a gap
The mapping table and what it feeds
Confirmed results are written by a Table block to a mapping table: obligation, source clause, control ID, match type, reviewer, timestamp and policy version. Gaps get their own status, so they can be assigned and tracked rather than buried in a spreadsheet tab.
From there the table feeds other work:
- A coverage view. A dashboard on the table shows obligations by policy, the share fully covered and the open gaps by owner.
- Framework mapping. The same pattern maps your controls to an external framework, such as the outcomes in the NIST Cybersecurity Framework 2.0, by swapping the policy for the framework text.
- Evidence collection. Once you know which controls an obligation depends on, gathering audit evidence for it becomes a lookup. The audit evidence collection playbook picks up from here.
Records and controls around the workflow
Every run is traced in Logs, block by block, with inputs and outputs, so you can show which policy text produced which proposal. The workflow runs from a deployed version, so a change to the extraction instructions is reviewed before it touches production mappings. Roles limit who can edit the workflow, and permission groups limit which models it may call.
Controls and governance
Run logs
Every workflow run records each block’s inputs, outputs and errors, so a reviewer can trace how a result was reached.
Deployed versions
Workflows run from a deployed version, so a change is reviewed before it reaches production runs.
Audit trail
Proposals, approvals, declines and executed actions are written to the workspace audit log, which admins can export.
Roles and permission groups
Admin, write and read roles per workspace, plus permission groups that limit which models, blocks and integrations a team can use.
SSO and SCIM
Sign in through your identity provider with SAML 2.0 or OIDC, and provision people with SCIM.
Self-hosting
Run Agent Serve in your own cloud or data centre, next to the systems it reads.
SOC 2 ready
The controls SOC 2 looks for are in place. Agent Serve does not claim a SOC 2 report or certification.
More on how Agent Serve handles access, data and audit on the security page.
Where to start
Pick one policy that changes often and has a well-described control set, such as access management. Run the workflow on the current version, have the owner review every proposal, and record how many they changed. A first run might, for example, find a handful of partial matches the team already suspected and one or two nobody had noticed. Add the next policy once owners trust the proposals enough to review them quickly.
One workflow from policy document to confirmed mapping
Workflow · Policy to control mapping
- 01New policy versionA webhook from your document system, or a manual run with the file attached.
- 02Extract obligationsAn Agent block splits the text into single obligations, each quoting its source clause.
- 03Search control libraryA Loop runs a Knowledge search per obligation against your control descriptions.
- 04Propose linksAn Agent block proposes full, partial or no match for each obligation, with a one-line reason.
- 05Reviewer confirmsA Human block pauses until a control owner accepts, changes or rejects each proposal.
- 06Mapping tableConfirmed links, gaps and reviewer names are written to a table with the policy version.
What you need
- Your policies as documents with stable section numbers
- A control library with an ID, a plain description and an owner for each control
- A Knowledge Base holding the control descriptions, kept in step with the library
- Named control owners to review proposals for their area
- A mapping table design: obligation, source clause, control ID, match type, reviewer, policy version
- A rule for what counts as a partial match, written down before the first run