Justina Dong · AI Governance · Control register
My working attempt at governing my own lab of 37 AI agents: 21 controls, mapped to ISO/IEC 42001, NIST AI RMF and four other frameworks, with the gaps left in.
Nobody has settled how to implement or test AI governance yet, me included. This is one attempt. AI drafted the controls, mapped them to the frameworks and ran the tests. I directed it, decided what risk to accept, and I own the result. Nobody else has reviewed it. It shows how I designed the controls, not that anything is compliant.
What they're for: Governance02 · Risk register
I run this as a one-person lab. Most of what I build can only break things for me, so I take on a lot of risk on purpose. The line sits where harm could reach someone else, or can't be undone.
Where I drew the line
Anything whose worst realistic outcome is rework, noise, or a degraded page that someone notices within a week.
Anything that can fail while still reporting healthy. A detective control has to catch it, because silence, not failure, is what this system can't tolerate.
Where the risks sit
1 more is withheld from this version, because describing it would disclose what it protects. It is outside tolerance.
Likelihood and impact are each my own 1 to 5 rating, on scales I defined, and the score is the two multiplied. The scales are ordinal, so a 10 isn't twice a 5, and where a risk sits tells you more than its number. Before means without the current controls; after means with them. I first scored these on August 7, 2026 and re-scored them on September 29, 2026. Nobody else has checked them yet. The next review is due December 29, 2026.
The risks
Tap a risk for its scores, how I'm treating it, and the controls that cover it.
Where agents touch my real data
What an agent can do in each place, and what stops a mistake there.
03 · The controls
Tap a control to see the risk, the control, and the gaps.
How far each control is proven
I work the grade out mechanically from each control's own "how it runs" and "tested" lines, so anyone can check my working. It's one way to grade a control, not a standard. Tested means a test ran when the code changed; nothing is re-tested on a schedule yet (known gap 02).
Risks get noticed only after they happen. The system gets good at closing incidents and never states which risks it has decided to accept.
Each quarter, and whenever a risk realizes or a new autonomous surface is added, the builder re-scores every risk in the register: likelihood and impact before and after its current control, and whether what is left sits inside the written tolerance. Each risk outside tolerance gets a named treatment, tracked as a work item until it closes. The review is recorded in the register as a dated line that sets the next due date.
Written by the builder it governs. The scores are ordinal judgment anchors, not measured rates, and the register says so.
suite coverage, surveyed 2026-09-29Testing: Operated once; the published copy is tested →
Negative residual risks (defined as the sum of all unmitigated risks) to both downstream acquirers of AI systems and end users are documented.Residual scores are ordinal judgments, not a sum of unmitigated risk.
Processes, procedures, and practices are in place to determine the needed level of risk management activities based on the organization’s risk tolerance.
Organizational risk tolerances are determined and documented.
The gates exist only as code. Nobody can say how a change is supposed to go, how to undo one, or how to retire an agent or a job without breaking whatever depended on it.
Plain-language procedures cover how a change is proposed, reviewed, built, verified, and recorded; how each class of change is rolled back; which actions can't be rolled back at all (sends, publishes, deletions of cloud pointers); and how an agent or scheduled job is retired. They're reviewed whenever the watched-path table changes.
This documents the gates; it doesn't add any. The procedure says so itself: where it and a hook disagree, the hook is right and the document is stale.
suite coverage, surveyed 2026-09-29Testing: Read through, no record kept →
Post-deployment AI system monitoring plans are implemented, including mechanisms for capturing and evaluating input from users and other relevant AI actors, appeal and override, decommissioning, incident response, recovery, and change management.Covers change, recovery and retirement; no monitoring plan or user input.
Processes and procedures are in place for decommissioning and phasing out AI systems safely and in a manner that does not increase risks or decrease the organization’s trustworthiness.
Personal data spreads to places no one mapped, because the system grew faster than anyone's picture of where the data sits and where it flows.
A privacy impact assessment inventories categories of personal data (never the data itself), maps the surfaces data flows to and from, and grades perimeter, minimisation, and flow awareness separately.
Done once and not yet repeated. An assessment that isn't re-run describes the system as it was.
suite coverage, surveyed 2026-09-29Testing: Read through, no record kept →
Privacy risk of the AI system – as identified in the MAP function – is examined and documented.
The system grows toward whatever is interesting that week. With no written purpose or targets, nobody can say whether a control serves anything, or what a risk would cost if it happened.
The owner writes the mission and a short list of objectives, each with a measure and a status taken from data. They're published on the governance page and reviewed at each quarterly register re-score. An objective whose status the data can't support is marked unmeasured or unmet.
Written by the person it governs. Three of the four objectives have no measurement yet, and the register's risks were scored before the objectives existed.
suite coverage, surveyed 2026-09-29Testing: Not operated yet; the published copy is tested →
The organization’s mission and relevant goals for AI technology are understood and documented.
An agent changes load-bearing configuration, an automation, or a public page without a written spec and without a second look. Or the builder decides for itself that the change is too small to need either.
Pre-execution hooks intercept file writes and edits, plus shell commands that write through redirects or in-place edits, whenever the target is on a shared table of watched paths. The action is blocked unless a spec file lists the path, or a separate reviewer agent recorded a clean audit within the last two hours. A narrow size exemption covers trivial edits, and the builder can't waive the gate for anything more.
The reviewer is a second agent, not a second person, so the segregation of duties is agent from agent. Some native system calls that rewrite scheduled jobs aren't matched, and sessions on another model provider fire none of these hooks.
suite coverage, surveyed 2026-09-29Testing: Shell path tested; the file-edit path isn't →
The risk management process and its outcomes are established through transparent policies, procedures, and other controls based on organizational risk priorities.
Post-deployment AI system monitoring plans are implemented, including mechanisms for capturing and evaluating input from users and other relevant AI actors, appeal and override, decommissioning, incident response, recovery, and change management.Change management only.
A nightly job pushes a change to the system's own governing rules before anyone awake has seen it.
When the reconciliation job changes a foundational rule, it commits the change with a hold tag. The nightly commit-and-push job looks for any held commit less than 48 hours old and skips the push until that commit ages out.
The change takes effect locally the moment it's written. The hold only delays the offsite copy, and it requires no sign-off: if nobody looks within 48 hours, the push goes through.
suite coverage, surveyed 2026-09-29Testing: Tested, but never shown it can fail →
Post-deployment AI system monitoring plans are implemented, including mechanisms for capturing and evaluating input from users and other relevant AI actors, appeal and override, decommissioning, incident response, recovery, and change management.A review window over rule changes, with no sign-off.
Nobody can reconstruct what the system's rules were on a given date, or when they changed.
Every night a scheduled job commits the working system (standing rules, procedures, registers, build scripts) and pushes it to a private remote. The same job commits the agent-control layer (agent specs, hooks, settings) to its own repository, locally.
The agent-control repository has no offsite remote, and most scheduled-job definitions aren't under version control. Granularity is one day, and the recorded author is the job, not whoever made the change.
suite coverage, surveyed 2026-09-29Testing: Automated test that can fail →
Post-deployment AI system monitoring plans are implemented, including mechanisms for capturing and evaluating input from users and other relevant AI actors, appeal and override, decommissioning, incident response, recovery, and change management.Keeps the change record; it doesn't manage change.
A change ships because it ran once, and nothing shows that the check it adds would ever say no.
New skills and commands default to test-first, with a companion test suite, and a hook nudges any new one written without it. The standing method for proving a check can fail is to copy the code to a sandbox, break it on purpose, confirm the test goes red, and restore the original byte for byte.
Nothing re-runs the suites on a schedule. A suite shows green on the day someone runs it, and that's all it shows.
suite coverage, surveyed 2026-09-29Testing: Tested, but never shown it can fail →
AI system performance or assurance criteria are measured qualitatively or quantitatively and demonstrated for conditions similar to deployment setting(s). Measures are documented.Shows a check works and can fail; no performance criteria are set.
An agent runs a recursive delete, or deletes cloud-document pointers from the synced drive, and the loss spreads to the cloud copy.
Pre-execution hooks inspect every shell command, and block recursive force-deletes and deletion of cloud-document placeholder files.
The hooks match patterns. A deletion done another way, through a script or a different tool, isn't caught.
suite coverage, surveyed 2026-09-29Testing: Automated test that can fail →
Mechanisms are in place and applied, and responsibilities are assigned and understood, to supersede, disengage, or deactivate AI systems that demonstrate performance or outcomes inconsistent with intended use.Blocks specific destructive actions; it can't disengage an agent.
The agent acts on a whole class of items at once, or sends, publishes, or spends, on its own reading of an instruction.
A hook blocks a shell command that looks like it will change many files at once until a manifest exists listing each file with its own reason. Sends, publishes, deploys, and anything involving money need the owner's explicit approval, and one approval covers one action.
The send-and-spend half is a rule the model applies, and no hook checks it. By this system's own standard, that half is a policy, not a control.
suite coverage, surveyed 2026-09-29Testing: Bulk part tested; sends and spend aren't →
Policies and procedures are in place to define and differentiate roles and responsibilities for human-AI configurations and oversight of AI systems.
Processes for human oversight are defined, assessed, and documented in accordance with organizational policies from the GOVERN function.Defined and documented; nothing assesses the send-and-spend half.
Anyone who can message the remote channel can steer the agents or trigger production jobs.
The remote messaging listener acts only on messages from an allowlisted sender ID. A remote job trigger resolves to a fixed list of scheduled jobs that must also be loaded, and it maps to a fixed argument list, never a command string taken from the input.
It controls who can send instructions. It doesn't stop instructions hidden in content the agents read, such as web pages, email, and documents. That exposure is handled by AC-02's approval rules and is a scored risk in GV-01.
suite coverage, surveyed 2026-09-29Testing: Read through, no record kept →
A scheduled job stops running, or runs and fails, and nobody notices for days.
Every hour a watchdog reads the fleet's health table. For any job that has gone silent or stale it tries a restart, then reports the problem, the action taken, and what it means. A status dashboard regenerates every 15 minutes.
It sees whether a job ran and reported in. A job that exits cleanly after doing nothing looks healthy here; OP-02 covers that case.
suite coverage, surveyed 2026-09-29Testing: Alerts tested; the restart isn't checked →
The functionality and behavior of the AI system and its components – as identified in the MAP function – are monitored when in production.Watches that jobs ran, not what they produced.
Post-deployment AI system monitoring plans are implemented, including mechanisms for capturing and evaluating input from users and other relevant AI actors, appeal and override, decommissioning, incident response, recovery, and change management.Monitoring and recovery for scheduled jobs only.
The status field reports success for runs that produced nothing.
Model-executed scheduled automations were reporting success even when the model died before doing any work. A detector now classifies each run by its output rather than its status: output that's too small, or that contains an API error at any length, marks the run hollow.
It only detects. Whether to retry is deliberately left as a separate decision.
suite coverage, surveyed 2026-09-29Testing: Automated test that can fail →
The functionality and behavior of the AI system and its components – as identified in the MAP function – are monitored when in production.Scheduled model runs only.
A control is counted as operating when it can't fire at all.
A shared wiring check lets a hook's test suite assert that the hook is registered, under a matcher that fires for today's tool name, and invoke it through the exact command the configuration specifies. It was built after an enforcement gate sat unwired for about six weeks because a tool it watched had been renamed. The suites for the destructive-command blocks (AC-01) and the bulk-change gate (AC-02) use it; most hook suites don't yet.
Coverage is partial: most hook suites, including the one behind OI-01, don't yet assert their own wiring. And suites run only when something changes (CM-04), so a rename between runs goes unnoticed until the next one.
suite coverage, surveyed 2026-09-29Testing: No test of its own →
Appropriateness of AI metrics and effectiveness of existing controls are regularly assessed and updated, including reports of errors and potential impacts on affected communities.Runs on change, and most hook suites don't use it yet.
The same failure recurs because the fix addressed the symptom.
Significant failures get a structured root cause: criteria, condition, cause, consequence, corrective action. The corrective action becomes a tracked item, and incidents are written up as blameless postmortems.
A tracked item shows the fix was written down, not that it shipped. Some corrective actions produce a guard that isn't wired in.
suite coverage, surveyed 2026-09-29Testing: Only the alert version is tested →
Incidents and errors are communicated to relevant AI actors, including affected communities. Processes for tracking, responding to, and recovering from incidents and errors are followed and documented.
Organizational practices are in place to enable AI testing, identification of incidents, and information sharing.Incident identification and sharing; testing is CM-04's.
A bad write corrupts a register that several sessions share, and no earlier copy exists.
Before a file-edit tool call, a hook snapshots the shared registers that agents read and write. The nightly commit puts the vault offsite (CM-03).
Snapshots sit in temporary storage and don't survive a restart. They fire on the file-edit tools only, so a register rewritten from the shell relies on the nightly copy.
suite coverage, surveyed 2026-09-29Testing: Read through, no record kept →
Post-deployment AI system monitoring plans are implemented, including mechanisms for capturing and evaluating input from users and other relevant AI actors, appeal and override, decommissioning, incident response, recovery, and change management.Recovery only.
The agent reports work as done when it isn't, and a success log line stands in for the artifact.
At the end of every agent turn, a hook checks three things: whether the agent changed something, whether it then claimed success, and whether anything in that turn verified the claim. If there's a change and a claim with no verification, it blocks the turn and sends the agent back to check.
It recognizes claims by their wording. The same false claim, phrased in words the hook doesn't know, gets through.
suite coverage, surveyed 2026-09-29Testing: Automated test that can fail →
The functionality and behavior of the AI system and its components – as identified in the MAP function – are monitored when in production.Checks completion claims by their wording.
Personal data reaches a public page through a copied artifact or a delegated task.
The rule is that public artifacts are built from curated or fabricated material, never by stripping the private system in place. The public learnings reader, which is generated from private notes, runs a scrub gate. This page's build runs a leak test that fails on real names, local file paths, or account identifiers.
Coverage is per surface, not universal: several hand-written public pages have no automated leak test. And a test only knows the identifiers it was given.
suite coverage, surveyed 2026-09-29Testing: Automated test that can fail →
Privacy risk of the AI system – as identified in the MAP function – is examined and documented.Tested per public surface, not everywhere.
Delegation turns into abdication. The owner can no longer tell what she asked for from what the system decided on its own.
The rule is that every surfaced item carries an origin label: requested by the owner, raised by an agent, fixed by self-healing, produced by a hook or a scheduled job, or origin unknown.
Nothing mechanical checks the labels. By this system's own rule, something the model consults and nothing enforces is a policy, not a control. It's listed so the gap stays visible.
suite coverage, surveyed 2026-09-29Testing: Not tested →
Policies and procedures are in place to define and differentiate roles and responsibilities for human-AI configurations and oversight of AI systems.Labels who started what; nothing enforces them.
An unattended loop runs up metered API spend.
Workflows billed per API call have to state an estimated cost per unit and get a yes before they run. A spend audit runs on demand. The daily scheduled run of the same audit checks for exposed API keys, not for spend.
The estimate is the model's own arithmetic, applied as policy.
suite coverage, surveyed 2026-09-29Testing: Only the new spend flag is tested →
Resources required to manage AI risks are taken into account – along with viable non-AI alternative systems, approaches, or methods – to reduce the magnitude or likelihood of potential impacts.Weighs cost per run; non-AI alternatives aren't considered.
A vendor changes a model, tool, or interface underneath the system, and the controls that depended on it stop working without a sound.
Every morning a scheduled job diffs the agent host's tool interface and flags tools that were renamed, added, or removed. The system is designed so models and tools can be swapped out, with its state kept in plain files rather than a vendor's memory. A written procedure covers model deprecation.
The diff watches one vendor's tool interface. Other connectors are covered by the portability design, not by monitoring.
suite coverage, surveyed 2026-09-29Testing: Automated test that can fail →
Contingency processes are in place to handle failures or incidents in third-party data or AI systems deemed to be high-risk.
AI risks and benefits from third-party resources are regularly monitored, and risk controls are applied and documented.Monitors one vendor's tool interface.
04 · Testing
AI ran every test here, on controls AI also built, at my direction. So none of it is independent yet. Tap a control for what I did, what it found, and one way it could be tested.
One way to test a control
I borrowed the two tests financial auditors use. Whether they fit AI systems well is part of what I'm trying out.
Walk one real instance from start to finish, and confirm the control as built deals with the risk.
Show it worked across a period. For a manual control, inspect a sample sized by how often it runs. For an automated one, test each case once, try to make it fail, and rely on change control to show the logic didn't change.
In an audit, the person testing is not the person who runs the control. Here, for now, it is.
From KPMG, Sarbanes-Oxley Section 404: Management's Assessment Process (2005), p. 10. The guide calls these examples and says each company should size its samples on its own facts.
How far my testing goes
The grade in chapter 03 says how a control runs. This says how hard it has been tested.
register, pre-binder: Operated once: re-scored on 2026-09-29 by the builder, not independently. One residual score rose and three fell. Next due 2026-12-29.
binder conclusion, 2026-10-01: Effective with exception(s) · how →
Walk through one quarterly re-score. To test that it operates, inspect two quarterly reviews and re-score a few risks yourself. Ideally the person checking isn't the person who scored.
register, pre-binder: Design walkthrough only
Checked 2026-09-29: none of the four documents has a dated review line yet, and one line in the back-out procedure still describes the snapshot step as it used to be.
binder conclusion, 2026-10-01: Effective with exception(s) · how →
Inspect the procedures for a dated review. Then pick changes made to the gates during the period and check that each one followed the written change and back-out steps.
register, pre-binder: Design walkthrough only
binder conclusion, 2026-10-01: Not operated in period · how →
Inspect the assessment against the data the system actually holds, and check it was redone after any new data source was added.
register, pre-binder: Not yet operated; written 2026-09-29.
binder conclusion, 2026-10-01: Not operated in period · how →
Inspect that each objective has a measure, then inspect two quarterly reviews that compare each measure with its target.
register, pre-binder: Test suites, run on change: the shell-redirect path, and scope parity across the three gate entry points
All green in the full run on 2026-09-13.
Not covered: the file-edit entry point has no suite of its own, and the gate keeps no decision log, so that piece of evidence doesn't exist yet.
binder conclusion, 2026-10-01: Effective with exception(s) · how →
Automated, so test one of each case: a write to a watched path with no approved spec should be blocked, and one with approval should go through. Then rely on change control over the gate itself to show the logic did not change during the period.
register, pre-binder: Test suite for the commit job, run on change
28 of 28 passed on 2026-09-14.
Not covered: nothing tests that a hold ends after 48 hours. The hold has never fired for real, so there are no held commits to inspect.
binder conclusion, 2026-10-01: Not operated in period · how →
Force the condition once: commit a rule change inside the hold window and confirm the push is held. Then read the job log for the period and confirm no held commit was pushed early.
register, pre-binder: Test suite for the commit job, run on change
28 of 28 passed on 2026-09-14. The 2026-09-29 nightly run committed both repositories.
binder conclusion, 2026-10-01: Effective with exception(s) · how →
Pick files that changed on the live system and trace each one to a commit. Then check whether anyone reviews the record, since a detective control usually needs a reviewer.
register, pre-binder: The nudge hook has its own test suite
Green on 2026-09-13.
Not covered: the nudge watches new commands but not new skills, and its suite never breaks the nudge to prove it can fail.
binder conclusion, 2026-10-01: Effective with exception(s) · how →
Sample changes from the period, about 25 for a control that runs on every change, and inspect each for a passing suite and a mutation run that failed as it should, before promotion.
register, pre-binder: Test suites, run on change
All green on 2026-09-13.
binder conclusion, 2026-10-01: Effective with exception(s) · how →
In a sandbox, try each class of blocked command and confirm the block. Compare the block list with the destructive commands the system can actually run, and rely on change control for the rest of the period.
register, pre-binder: Test suite for the bulk-change gate, run on change
Green on 2026-09-13.
Not covered: the gate counts the manifest's lines but doesn't check that each file has its own reason, and the approval rule for sends and spend has no test.
binder conclusion, 2026-10-01: Effective with exception(s) / Not testable (policy only) · how →
Automated part: try a bulk change with no manifest (blocked) and with one (allowed). Policy part: sample about 25 sends and paid runs from the logs and inspect each for an approval recorded before the action.
register, pre-binder: Design walkthrough only (read in code 2026-09-29)
binder conclusion, 2026-10-01: Design only (no TOE possible) · how →
Send a message from an unlisted sender and from a listed one, and confirm only the listed one triggers anything. Inspect the allowlist and who can change it.
register, pre-binder: Test suite for the watchdog, run on change
67 of 67 and 17 of 17 passed on 2026-09-29.
Not covered: the suite records the restart attempt but never checks that it happened.
binder conclusion, 2026-10-01: Effective with exception(s) · how →
Break one job on purpose and confirm the alert fires and the fix runs. Then take the alert history for the period and trace each alert to its resolution.
register, pre-binder: Test suite, run on change
Green on 2026-09-13.
binder conclusion, 2026-10-01: Effective · how →
Feed in a run that finishes with empty output and confirm it is flagged. Then sample the detector log and trace each flag to its follow-up.
register, pre-binder: This control is itself a test
Not covered: the check has no test of its own, so nothing shows it would catch a hook that isn't wired.
binder conclusion, 2026-10-01: Effective with exception(s) · how →
List which controls have a wiring check and which do not. Break one wire and confirm its check fails.
register, pre-binder: Design walkthrough only
binder conclusion, 2026-10-01: Effective with exception(s) · how →
Take every incident in the period, or a sample of about 25 if there are more, and inspect each for a root-cause record and a corrective item that was closed and checked.
register, pre-binder: Design walkthrough only
Checked 2026-09-29: 55 snapshots were taken between 2026-09-28 and 2026-09-29.
binder conclusion, 2026-10-01: Effective with exception(s) · how →
Restore a register file from the snapshot and from the offsite copy, and compare both with the original.
register, pre-binder: Test suite, run on change
Green on 2026-09-13, and run again on 2026-09-17 after the last change.
binder conclusion, 2026-10-01: Effective with exception(s) · how →
Send a turn that claims the work is done with no proof and confirm it is blocked; send one with proof and confirm it passes. Rely on change control for the rest of the period.
register, pre-binder: This page: leak test with a planted negative control
71 of 71 passed on 2026-09-29.
Not covered: the leak check runs when someone runs the test, not on every build or push, and it looks for internal names and paths, not a list of real people.
binder conclusion, 2026-10-01: Effective with exception(s) · how →
List every public surface and whether it has a leak test. Where one exists, plant a known private string and confirm the build fails. Where none exists, inspect the surface by hand.
register, pre-binder: Not tested
binder conclusion, 2026-10-01: Not testable (policy only) · how →
Sample about 25 surfaced items from session output and check that each carries an origin label and that the label is right.
register, pre-binder: Design walkthrough only
The line above is out of date: a suite now exists for the flag, though not for the approval rule.
binder conclusion, 2026-10-01: Not testable (policy only) · how →
Sample paid runs from the cost log and inspect each for a cost estimate and an approval recorded before the run. Reconcile the cost log to the provider's bill.
register, pre-binder: Design walkthrough only
The line above is out of date: this suite has been green since 2026-09-13.
The 2026-09-29 daily run failed to save its snapshot.
binder conclusion, 2026-10-01: Effective with exception(s) · how →
Compare the watch list with the vendors actually in use. Confirm the diff report ran every day of the period and that each flagged change was looked at.
05 · Known gaps
The gaps I know about, measured against the same frameworks. There are probably others I haven't found.
One person owns, builds, operates, reviews, and approves. There's no provisioning or access review, because there's only one user. Agent-from-agent review (CM-01) narrows this gap but doesn't close it.
NIST GOVERN 2.1 · NIST MEASURE 1.3 · SOX: segregation of duties · COSO 10
The test suites and wiring checks run when something changes, never on a timer. No control is re-performed on a sample over time, so every 'tested' line on this page means tested the last time someone ran it.
NIST MEASURE 1.2 · COSO 16
A few detectors have measured thresholds (OP-02). There's no set of risk metrics with tolerances tracked over time; the risk register scores on ordinal judgment.
NIST MEASURE 1.1 · COSO 16
Native calls that edit or unload scheduled jobs aren't matched by the change gate, and sessions on another model provider fire none of the hooks. Both appear in the change procedure itself.
NIST GOVERN 1.4 · SOX ITGC: program change
The person who built the system mapped it. Nobody who knows these frameworks independently has reviewed it yet, so it shows control design, not assurance.
NIST MEASURE 1.3
Appendix · Frameworks
Pick a framework to see which of its items I think a control covers, and how well. Every fit here is my own judgment, open to challenge.
I left out an overall letter grade. Many items in these frameworks assume an organization with staff, leadership and affected communities, so I think a letter would grade the scope more than the work.
19 of 72 subcategories have a control · 20 of 21 controls map here. 9 of the 19 have a full fit.
Partly met. GV-01 fits it fully, but GV-01 is only partly proven.
Met. CM-01 fits it fully and is enforced and tested.
Partly met. GV-02 fits it fully, but GV-02 is only partly proven.
Partly met. AC-02 fits it fully, but AC-02 is only partly proven.
Partly met. OP-04 covers part of it. No control fits it fully.
Partly met. OI-05 fits it fully, but OI-05 is only partly proven.
Partly met. GV-04 fits it fully, but GV-04 is rule only.
Partly met. GV-01 fits it fully, but GV-01 is only partly proven.
Partly met. AC-02 covers part of it. No control fits it fully.
Partly met. OP-03 covers part of it. No control fits it fully.
Partly met. CM-04 covers part of it. No control fits it fully.
Partly met. OP-01, OP-02 and OI-01 cover part of it. No control fits it fully.
Partly met. GV-03 fits it fully, but GV-03 is only partly proven.
Partly met. GV-01 covers part of it. No control fits it fully.
Partly met. OI-04 covers part of it. No control fits it fully.
Partly met. AC-01 covers part of it. No control fits it fully.
Partly met. OI-05 covers part of it. No control fits it fully.
Partly met. GV-02, CM-01, CM-02, CM-03, OP-01 and OP-05 cover part of it. No control fits it fully.
Partly met. OP-04 fits it fully, but OP-04 is only partly proven.
5 of 12 risks have a control · 8 of 21 controls map here. 0 of the 5 have a full fit.
Partly met. OI-01 covers part of it. No control fits it fully.
Partly met. GV-03 and OI-02 cover part of it. No control fits it fully.
Partly met. CM-01, AC-02 and OI-03 cover part of it. No control fits it fully.
Partly met. AC-03 covers part of it. No control fits it fully.
Partly met. OI-05 covers part of it. No control fits it fully.
11 of 16 clauses and objectives have a control · 17 of 21 controls map here. 4 of the 11 have a full fit.
Partly met. GV-01 and GV-04 cover part of it. No control fits it fully.
Met. CM-03 fits it fully and is enforced and tested.
Met. CM-01 fits it fully and is enforced and tested.
Partly met. OP-03 covers part of it. No control fits it fully.
Partly met. OP-04 fits it fully, but OP-04 is only partly proven.
Partly met. OI-03 covers part of it. No control fits it fully.
Partly met. GV-03 covers part of it. No control fits it fully.
Met. CM-01 fits it fully and is enforced and tested.
Partly met. GV-03 covers part of it. No control fits it fully.
Partly met. AC-01 and AC-02 cover part of it. No control fits it fully.
Partly met. OI-05 covers part of it. No control fits it fully.
10 of 17 principles have a control · 21 of 21 controls map here. 5 of the 10 have a full fit.
Partly met. GV-04 covers part of it. No control fits it fully.
Partly met. GV-01 fits it fully, but GV-01 is only partly proven.
Partly met. OI-05 covers part of it. No control fits it fully.
Partly met. AC-02 fits it fully, but AC-02 is only partly proven.
Met. CM-01, CM-03, AC-01, OP-01 and OP-02 fit it fully and are enforced and tested.
Partly met. GV-02 fits it fully, but GV-02 is only partly proven.
Partly met. OI-01 covers part of it. No control fits it fully.
Partly met. OI-03 covers part of it. No control fits it fully.
Partly met. CM-04 and OP-03 cover part of it. No control fits it fully.
Partly met. OP-04 fits it fully, but OP-04 is only partly proven.
4 of 4 domains have a control · 10 of 21 controls map here. 2 of the 4 have a full fit.
Partly met. GV-02, CM-01 and CM-03 cover part of it. No control fits it fully.
Partly met. CM-04 covers part of it. No control fits it fully.
Partly met. AC-03 fits it fully, but AC-03 is only partly proven.
Met. OP-01 and OP-02 fit it fully and are enforced and tested.
6 of 10 risks have a control · 8 of 21 controls map here. 0 of the 6 have a full fit.
Partly met. AC-02 and AC-03 cover part of it. No control fits it fully.
Partly met. OI-02 covers part of it. No control fits it fully.
Partly met. OI-05 covers part of it. No control fits it fully.
Partly met. CM-01, AC-01, AC-02 and AC-03 cover part of it. No control fits it fully.
Partly met. OI-01 covers part of it. No control fits it fully.
Partly met. OI-04 covers part of it. No control fits it fully.