Control status by framework

Overview

Govern → Compliance program → Framework controls shows, for the current environment, the status of each control in four frameworks. Every status is backed by evidence Shield360 already observes: the AI inventory, the enforcement policy, what the guards stopped, the audit log, alert rules, evaluations and coding-agent sessions.

Caution

This is evidence scaffolding for auditors, not a legal determination. A status says what Shield360 observed in this environment for the period. It does not certify compliance with any framework.

The per-trace governance report maps one trace’s findings to controls. This page answers the question across the whole environment for a period: is each control backed by evidence, and where are the gaps?

Frameworks

Framework	Controls	Source
EU AI Act	33	Every Article of Regulation (EU) 2024/1689 that places an obligation on a provider, deployer, importer, distributor or general-purpose AI model provider, from AI literacy (Art. 4) to the right to explanation (Art. 86). Each has a Statement of Applicability entry, and which Articles apply is derived from your roles and systems. See EU AI Act.
NIST AI RMF	72	Every subcategory of the AI RMF 1.0 Core (NIST AI 100-1, January 2023): 19 categories under GOVERN, MAP, MEASURE and MANAGE. Each has a Statement of Applicability entry. See NIST AI RMF coverage.
OWASP Agentic (ASI)	10	The OWASP Top 10 for Agentic Applications, ASI01 to ASI10.
ISO/IEC 42001	38	All Annex A controls, from the AI policy to customer relationships. Each has a Statement of Applicability entry.

The ISO/IEC 42001 titles are short paraphrases of the Annex A control titles. Check them against your copy of the standard before you quote them. The NIST AI RMF subcategories carry NIST’s own wording from Tables 1–4 of NIST AI 100-1, shown when you expand one, with a short title for lists.

Statuses

Each control is backed by one or more checks. Each check reports one of these statuses:

Status	Meaning
Met	The evidence shows the control in place for the period.
Gap	The evidence shows something missing or something that got through. The reason says what.
No evidence	There is nothing to judge, such as no coding-agent sessions in the period. It also means a source could not be read. The reason then says Unavailable.
Not applicable	The check cannot be judged across an environment. It is left out of the control’s status.

On ISO/IEC 42001, the NIST AI RMF and the EU AI Act, a control recorded as not applicable in the Statement of Applicability is Not applicable as a whole, whatever its checks found. On the EU AI Act, an Article nobody has decided on is also Not applicable when your recorded roles and AI systems rule it out; the attestation check gives the reason. See which Articles apply.

A control that is a gap or has no evidence, but has at least one check that is met, is also marked Partly met, so you can tell a control with some evidence from one with none. The export carries it as partial (JSON) and partly_met (CSV).

A control takes the worst status of its applicable checks: gap, then no evidence, then met. A source that fails to read never fails the page. Its checks say no evidence, and a note names the source.

Statement of Applicability

ISO/IEC 42001 asks for a Statement of Applicability (SoA): for every Annex A control, whether it applies to you, why not when it does not, and how it is met. Shield360 keeps one per environment, so you can hand an auditor all 38 controls in one export. The EU AI Act has one too, with an entry for each of its 33 Articles.

The NIST AI RMF uses the same mechanism for its 72 subcategories. The AI RMF does not ask for an SoA by name, but recording each subcategory’s applicability, owner, evidence and review is how a current profile is documented, and it is what lets every subcategory have a status.

Caution

The Statement of Applicability records what your team decided and attested. Shield360 does not check that the evidence you point to is adequate, and a complete SoA is not an ISO/IEC 42001 certification. The NIST AI RMF is voluntary and has no certification; a status on every subcategory says that each was assessed and recorded, not that NIST or anyone else has endorsed it.

Applicability

Each control has one of three values:

Applicability	Meaning
Undecided	Nobody has recorded whether the control applies. Every control starts here.
Applicable	The control applies. It needs an owner, an evidence reference and a review within its cadence.
Not applicable	The control does not apply. A justification is required, and auditors read it.

Shield360 never records a control as not applicable for you, even when it observed nothing for it. On the EU AI Act, an undecided Article shows as not applicable when your recorded roles and systems rule it out, with the reason; that is shown, not recorded, and any decision you record wins.

For each control you can record:

• Owner: the person or team accountable for it.
• Evidence reference: a link (https://…) or a short note on where the evidence is kept. Files are not uploaded.
• Review every (days): how often the control is reviewed. The default is 365 days.
• Last reviewed and Reviewed by: when the last review took place and who carried it out. Reviewed today fills in today’s date.

Attested controls

Every ISO/IEC 42001 control and every NIST AI RMF subcategory has an Attested in the Statement of Applicability check, built from its entry:

Entry	Check status
Undecided	No evidence
Applicable, with an owner, an evidence reference and a review within its cadence	Met
Applicable, with no owner, no evidence reference or no review	Gap. The reason names what is missing.
Applicable, with the last review older than its cadence	Gap. The reason says the review is overdue and since when.
Not applicable	Not applicable. The control leaves the status and shows its justification.

The attestation joins the control’s observed checks under the same rule: the control takes the worst status. An applicable control with a met attestation but an observed gap is still a gap.

Some controls have observed checks as well as the attestation. The others are attested only: what your team records is their only evidence. For the NIST AI RMF, 44 subcategories are observed and attested and 28 are attested only; the list is on NIST AI RMF coverage.

Above the controls, a coverage line for these frameworks reads, for example, “72 of 72 subcategories have a status: 44 backed by observed evidence and an attestation, 28 by an attestation only”, followed by how many have their applicability recorded.

Control	Evidence
A.2.2 AI policy	Observed and attested
A.2.3 Alignment of the AI policy with other policies	Attested only
A.2.4 Periodic review of the AI policy	Attested only
A.3.2 AI roles and responsibilities	Observed and attested
A.3.3 Reporting of concerns	Observed and attested
A.4.2 Resource documentation	Observed and attested
A.4.3 Data resources documented	Observed and attested
A.4.4 Tooling resources	Observed and attested
A.4.5 System and computing resources documented	Observed and attested
A.4.6 People and competencies documented	Attested only
A.5.2 AI system impact assessment process	Observed and attested
A.5.3 Impact assessments recorded	Observed and attested
A.5.4 Assessing AI system impact on individuals or groups	Observed and attested
A.5.5 Societal impact assessment	Observed and attested
A.6.1.2 Objectives for responsible AI development	Attested only
A.6.1.3 Responsible design and development processes	Attested only
A.6.2.2 AI system requirements	Attested only
A.6.2.3 Design and development records	Attested only
A.6.2.4 AI system verification and validation	Observed and attested
A.6.2.5 Deployment planning	Observed and attested
A.6.2.6 AI system operation and monitoring	Observed and attested
A.6.2.7 Technical documentation	Observed and attested
A.6.2.8 AI system recording of event logs	Observed and attested
A.7.2 Data for development and enhancement of AI systems	Observed and attested
A.7.3 Acquiring data	Observed and attested
A.7.4 Data quality	Observed and attested
A.7.5 Data provenance	Observed and attested
A.7.6 Preparing data	Observed and attested
A.8.2 System documentation and information for users	Observed and attested
A.8.3 Reporting by external parties	Attested only
A.8.4 Communication of incidents	Observed and attested
A.8.5 Information for interested parties	Attested only
A.9.2 Processes for responsible use of AI systems	Observed and attested
A.9.3 Objectives for responsible use	Attested only
A.9.4 Intended use of the AI system	Observed and attested
A.10.2 Allocating responsibilities	Observed and attested
A.10.3 Suppliers	Observed and attested
A.10.4 Customer relationships	Attested only

Record applicability

1. Open Govern → Compliance program → Framework controls and choose ISO/IEC 42001 or NIST AI RMF.
2. Select Applicability. The table lists every control with its applicability, owner, last review, evidence and status. NIST AI RMF subcategories are grouped under their category.
3. Select Edit on a control. The dialog shows a one-line hint on the evidence that usually satisfies it and, for the NIST AI RMF, the subcategory’s wording.
4. Choose the applicability, fill in the owner, evidence reference and review, and select Save.

Checks

Check	Met when	Evidence
AI inventory exists	At least one AI asset is registered	AI inventory
AI assets have an owner	At least 90% of active, non-retired assets have an owner	AI inventory
AI assets are reviewed and decisions are current	At least 80% of active, non-retired assets were reviewed in the last 365 days, and no recorded decision has lapsed	AI inventory
AI assets have a risk rating	Every current asset has a risk rating	AI inventory
Rejected AI is not in use	No rejected asset was seen in use	AI inventory
AI requests are decided by a reviewer	No AI request has waited for a reviewer for more than 14 days. Not applicable while the environment has no requests. On ISO/IEC 42001 it backs A.6.2.5, A.9.2, A.9.4 and A.10.3.	AI requests, AI inventory
Approved model list is set and enforced	The list is on and the AI proxy warns or blocks outside it	Enforcement policy
Use outside the approved list is stopped	No use outside the list in the period went ahead after a warning or escaped enforcement	Violations
Sensitive-data protection is on in every channel	Every channel in use in the period (browser extension, AI proxy, coding agents) acts on at least one kind of sensitive data	Enforcement policy
Sensitive data is stopped before it reaches a model	No sensitive-data event in the period was sent anyway or escaped enforcement	Data protection
Prompt-injection detection is on	Detection is on for coding agents and the MCP gateway	Prompt injection
Prompt-injection detections are handled	No detection in the period went ahead after a warning or escaped enforcement	Prompt injection
Audit log is recording	The organisation’s audit log has records in the period	Audit log
Retention is configured	Every data source has a retention period; also counts active legal holds	Compliance overview, legal holds
Governance alerts reach a person	An enabled rule sends at least one governance alert kind to an enabled channel	Alerts
Evaluations are running	Hallucination, bias, toxicity or other evaluations ran in the period	Evaluations
AI output is evaluated for bias	A bias evaluation ran in the period. A gap when evaluations are not configured; no evidence when they are but no bias evaluation ran. It shows bias is measured, not that the output is fair. Backs NIST AI RMF MEASURE-2.11.	Evaluations
AI risks are owned, reviewed on time and treated	The risk register has risks, and every live (open or treating) risk has an owner and is not past its review date, every live high or critical risk has a treatment chosen, and no acceptance has lapsed. No evidence while the register is empty. Backs NIST AI RMF GOVERN-1.4, 1.5, 4.2, MAP-5.1, MEASURE-3.1 and MANAGE-1.2, 1.3, 1.4 and 2.3.	Risk register
Sequence policies are on	At least one sequence policy is on in warn or block mode	Sequence policies
Coding agents ask before acting	No coding-agent session in the period bypassed permission prompts	Coding agents
AI vendors have an owner and a decision	Every vendor has an owner and an approval decision	AI inventory
AI provider keys are clean	No key has key-hygiene findings	Costs → API keys
AI vendors have current due diligence	Every vendor the vendor procurement standard covers (recorded, or seen in AI traffic with nothing recorded) has the due diligence the standard requires, none of it expired; judged against a default baseline while no standard is approved. Not applicable with no vendor in scope. Backs ISO/IEC 42001 A.10.3, NIST AI RMF GOVERN-6.1 and MANAGE-3.1, and SOC 2 CC9.2.	Vendors
Vendor contracts contain audit and cooperation terms	Every vendor in scope has a contract recorded to give audit rights and a duty to cooperate with regulatory inquiries. Not applicable with no vendor in scope. Backs ISO/IEC 42001 A.10.3, NIST AI RMF GOVERN-6.1 and SOC 2 CC9.2.	Vendors
AI agents under test are red-teamed and no critical attack gets through	Every agent test target had a red-team run with results in the last 30 days, and the latest red-team run of each of its suites fails no critical-severity test; not applicable when the environment has no target. Backs ISO/IEC 42001 A.6.2.4, EU AI Act Art. 15, NIST AI RMF GOVERN-4.3, MEASURE-2.1 and MEASURE-2.7, and OWASP ASI01.	Agent tests → Red team
Data flows to AI are traced, and every sensitive classification seen has an owner	Every classification more sensitive than internal that was seen in the period’s data lineage (data gateway, MCP gateway, guards) has an owner in the classification catalog; not applicable when no flow was recorded. Backs ISO/IEC 42001 A.7.2 and A.7.5, EU AI Act Art. 10 and NIST AI RMF MEASURE-2.10. Lineage covers only the paths Shield360 observes.	Data lineage
Datasets feeding AI systems are owned, sourced, licensed, classified, examined for quality and bias, and approved	Every registered dataset that is not retired and feeds an in-scope AI system (an application or agent in use, a tool rated high risk, or a system classified high-risk under the EU AI Act) has an active owner, provenance, a license, a legal basis, data classes, an Art. 10 quality and bias examination and a second person’s approval; the gap names each dataset and what it lacks; not applicable when no registered dataset feeds an in-scope system. Backs EU AI Act Art. 10, ISO/IEC 42001 A.7.2–A.7.6 and NIST AI RMF MAP-2.3, MAP-4.1, MAP-4.2 and MEASURE-2.1. Covers the datasets people registered.	Datasets
Logs are kept at least six months	The traces table keeps rows for at least 183 days, read from its own TTL; met when it keeps them indefinitely. Backs EU AI Act Art. 16, 19 and 26.	Data retention
Members have current AI literacy records	At least 90% of the organisation’s members have a literacy record completed in the last year or not yet expired. Backs EU AI Act Art. 4.	EU AI Act → AI literacy
AI uses are screened against prohibited practices	No system classified as prohibited is in use, no AI request the Art. 5 screening flagged was approved, and every request in the period was screened. Backs EU AI Act Art. 5.	AI requests, EU AI Act → AI systems
AI systems are classified under the EU AI Act	Every AI system in scope has a class. Backs EU AI Act Art. 6.	EU AI Act → AI systems
High-risk systems have their Annex IV documentation	Every high-risk system you provide has each Annex IV item observed or referenced; not applicable without one. Backs EU AI Act Art. 11 and 16.	EU AI Act → AI systems
Fundamental rights impact assessments are complete	Every system that needs one has a current approved impact assessment with every Art. 27 element and the authority notification; not applicable when none needs one.	Impact assessments
Systems are registered in the EU database	Every system Art. 49 applies to has its EU database id recorded; not applicable when none.	EU AI Act → AI systems
Art. 50 transparency measures are in place	Every transparency trigger set on a system has its measure ticked; not applicable when no reviewed system has one.	EU AI Act → AI systems
Serious incidents are reported in time	No serious incident is open past its Art. 73 deadline, and none in the period was reported late; not applicable while none is recorded. Backs EU AI Act Art. 26, 72 and 73.	EU AI Act → Serious incidents
AI systems have a current approved impact assessment	Every application and agent in use, and every tool rated high risk, has an approved assessment not past its review date; not applicable when none is in scope	Impact assessments
Runtime findings in the period	No finding in the control’s categories went ahead after a warning or escaped enforcement	Violations, prompt injection, coding agents, agent access, evaluations

Targets

Some checks measure a share against a target. Each check’s reason shows the actual value and the target, for example “84% owned, target 90%”. A share is rounded down, so a value just below a target never shows as reaching it.

Target	Default	Gap when
Assets with an owner	90% of active, non-retired assets	Below 90%
Assets reviewed	80% of active, non-retired assets, reviewed within the last 365 days	Below 80%
Rejected AI in use	0	Any rejected asset is in use
Lapsed decisions	0	Any recorded decision has passed its expiry
Events that went through	0	Any event was sent anyway after a warning, or a block could not be enforced
Red-team recency	A red-team run within the last 30 days, for every agent test target	Any target without one

“Active” means the asset was seen in the inventory’s 90-day lookback. Rejected AI in use and lapsed decisions are explicit policy breaches, so any count above zero is a gap. The targets are the same for every organisation for now.

Warnings and blocks

A blocked or masked event is evidence that the control works. A warning that your policy chose is not a gap by itself. An event that went ahead after a warning (“sent anyway”), or a block a channel could not enforce, is a gap.

Channels in use

Sensitive-data protection is judged per channel. A channel counts as in use when one of these was seen in the period:

• Browser extension: an enrolled extension checked in.
• AI proxy: an enrolled proxy checked in.
• Coding agents: a computer with the collector checked in, or coding-agent sessions were recorded.

A channel with protection off is a gap only when it is in use. When it is not in use, the reason says it is not applicable. If the device list cannot be read, a channel with protection off counts as a gap, and the reason says why.

Rolled-up findings

The last check rolls up the per-trace finding categories that are recorded across the environment. These are policy violations, prompt injection, tool misuse, coding-agent risks, agent harness signals and evaluation flags. Span errors, generation health and agent loops can be seen only in a single trace’s report, so they are not applicable here.

The period applies to everything except the inventory checks. Those use the inventory’s own 90-day lookback. Every check shows the period it covers.

Choose a framework and period

1. Open Govern → Compliance program → Framework controls.
2. Pick a framework from the tabs. Each tab shows how many of its controls have a gap.
3. Choose Last 7 days, Last 30 days or Last 90 days.
4. Expand a control to see its checks, each check’s reason, and links to the pages that show the evidence.
5. Narrow the list with the search box, Function (NIST AI RMF), Evidence (observed and attested, or attested only) and the status filter. The filters apply to the applicability table too.

Under each control’s title, a strip shows its daily status over the period you chose. See Daily history.

Daily history

An audit covers a period, not a moment. ISO/IEC 42001 and SOC 2 auditors want to see that a control held throughout the audit period. Raw telemetry ages out under your retention settings, so Shield360 keeps a small daily record of each control’s status instead.

What you see

The Daily history panel and the strip under each control cover the period you chose: the last 7, 30 or 90 full UTC days, ending yesterday. Each cell is one day:

Cell	Meaning
Green	Met that day.
Red	A gap that day.
Amber	No evidence that day.
Grey	Not applicable that day.
Hollow	Not recorded. No snapshot exists for that day.

Below the strip, a summary reads, for example, “Met 86% of days, gaps on 4 days · first gap 3 Sept 2026, last gap 19 Sept 2026”. The percentage is of every day in the period, recorded or not, rounded down. A day that was not recorded never counts as met.

History starts on the day this feature was turned on for your Shield360. Days before that, and any day the job did not run, show as not recorded. The panel says when recording started for the current environment.

How a day is recorded

Shortly after midnight UTC (00:35 by default), a scheduled job evaluates every environment for the UTC day that just ended:

• Presence checks ask whether something is on, running or happening. They are measured over the 7 days ending with the snapshot day. A quiet weekend with no audit records or evaluation runs does not read as a gap. A whole silent week still does.
• Breach checks count what went through or should not have happened. They are measured over the snapshot day alone, so an incident shows on the day it happened and not for the week after.
• Checks that read configuration (whether a policy, approved model list or alert rule is on) read it as it is when the job runs.
• Inventory checks use the inventory’s own 90-day lookback, as on the page.
• The Statement of Applicability is applied as it stood when the job ran.

Window	Checks
Presence (7 days)	audit.active, evaluations.running, alerting.configured, retention.configured, models.approved_list, data_protection.enabled, injection.detection, oversight.sequence_policies, inventory.registered, inventory.ownership, inventory.risk_rated, third_party.vendors, third_party.key_hygiene, third_party.due_diligence and third_party.contract_terms (read from the vendor records as they are when the job runs), impact.assessed, intake.decisions (read from the requests waiting when the job runs), risks.managed (read from the register as it is when the job runs), evaluations.bias, agent_tests.red_teamed (read over the 30 days before the snapshot day ends), and the repo.* checks
Breach (the day)	models.unapproved_use, data_protection.violations, injection.detections, inventory.rejected_in_use, inventory.review (lapsed decisions), oversight.coding_agents (permissions bypassed), provenance.recorded (unattributed actions, broken integrity), and findings.rollup

Because breach checks look at one day, a day with no coding-agent sessions or agent actions reads as no evidence for oversight.coding_agents and provenance.recorded, not as a gap.

Each record stores both window lengths with it.

Running a day again replaces that day’s record. It never adds a second copy. If one environment cannot be read, the job logs it and carries on with the others. That environment’s day is then not recorded.

The job is registered at startup with the other scheduled jobs, so no extra deployment step is needed. Set CONTROL_HISTORY_SCHEDULE (a cron expression, evaluated in UTC) to change when it runs.

What is stored, and what is not

For each environment, framework control and UTC day, Shield360 stores:

• the control’s status (met, gap, no_evidence or not_applicable);
• how many of its checks had each status;
• the presence and breach window lengths it was measured over;
• short reason codes: the ids of the checks behind a gap or missing evidence (for example audit.active), or soa.not_applicable when the Statement of Applicability excludes the control.

It does not store raw events, prompts or responses, user or person identifiers, or check reason text. It also leaves out Statement of Applicability free text: justification, owner, evidence reference and reviewer.

Retention

Daily records are kept for three years (1,096 days), long enough for an audit period and the surveillance audits that follow it. The daily job deletes older records. Deleting an environment deletes its history. An organisation export includes the history as control_status_history.

Caution

The history shows what Shield360 recorded each day. It is evidence for your auditor, not a certification, and it does not show that a control operated on a day that was not recorded.

Export

Export (JSON) downloads the selected framework with every control, check, reason, count, period and evidence link. It also records when the export was generated. On ISO/IEC 42001 and the NIST AI RMF, each control also carries its Statement of Applicability entry under soa, and the framework carries coverage (how many controls have a status, are observed or attested only, have their applicability recorded, are not applicable or partly met). The NIST AI RMF also carries source (NIST AI 100-1, version 1.0, January 2023, with its DOI link), groups (the four functions and 19 categories with their statements), and on each subcategory group and text (NIST’s wording).

Export (CSV) downloads one row per control: its status, applicability, justification, owner, evidence reference, review cadence, last review, reviewer, next review due, whether it is attested only, each check’s status, its group (the NIST AI RMF category) and partly_met. Columns from the Statement of Applicability are empty for frameworks without one.

Both exports carry the daily history for the period’s days, ending yesterday, or for from and to when you give them. The JSON has a history object with the range, the day recording started, and each control’s summary and recorded days. The CSV adds the range, days recorded and not recorded, days met, gap, no evidence and not applicable, the met percentage, the first and last gap, and history_daily: every day of the range as 2026-10-01=met; 2026-10-02=not_recorded; ….

The API exports every framework when no framework is given:

curl -H "Cookie: <session>" \
  "https://<your-shield360>/api/governance/controls/export?format=csv&framework=iso_42001&period=30d"

Control ids (eu-ai-act/Art.12) and check ids (audit.active, soa.attestation) are stable between releases.

Evidence package

Evidence package on the same page downloads one ZIP for an auditor: the Statement of Applicability (with the framework’s source and coverage for the NIST AI RMF and ISO/IEC 42001), control status and daily history, the risk register, an AI inventory summary, audit-log counts and the policy settings for one framework and period, with a manifest of SHA-256 hashes signed with Ed25519. External auditors can be given read-only access to one environment until a date you choose. See Evidence package and auditor access.

Impact assessments

ISO/IEC 42001 A.5.2, A.5.3, A.5.4 and A.5.5 are also backed by the check AI systems have a current approved impact assessment: every application and agent in use, and every tool rated high risk, needs an approved impact assessment whose next review date has not passed. With no system in scope the check does not apply.

Findings

The Findings panel on the same page shows how many findings are open and overdue in this environment. To people who may raise findings, it suggests controls whose latest day in the history is a gap, or whose attested review is overdue, each with Raise finding to open the form already filled in. Nothing is raised until a person does it, and a control a finding already covers is not suggested. Each finding is then contained, its root cause recorded, corrected and reviewed for effectiveness against this history. See Findings and corrective actions.

Internal audits and management reviews

Govern → Compliance program → Internal audits keeps the audit programme: audits of a framework’s controls, their lead auditor’s independence, a conclusion on each control, and when each control was last audited. Govern → Compliance program → Management review keeps management reviews at planned intervals, with an input pack generated from this history and the rest of the platform’s records. See Internal audit and Management review.

Access

The page and its API need the View the compliance overview permission (compliance.read). The Compliance officer, Analyst and Viewer roles have it, as well as owners and administrators. Every read is scoped to your current environment. The environment comes from your session, never from the request. Each export is written to the audit log as data access.

Scripts can call the status, export and history routes with a project API key. The routes check compliance.read for the person who created the key. The environment is the one the key is bound to, whatever the request names:

curl -H "Authorization: Bearer <api-key>" \
  "https://<your-shield360>/api/governance/controls/export?format=json&framework=iso_42001"

Changing the Statement of Applicability needs the Maintain the Statement of Applicability permission (compliance.soa.manage). Owners, administrators and the Compliance officer role have it. Other roles see the applicability table with Edit turned off. Changes need a signed-in person; an API key cannot make them. Each change is written to the audit log with the fields that changed, the applicability and the review dates. The owner, justification, evidence reference and reviewer are free text that may name a person or carry a link, so they are left out of the audit record.

API

Method	Path	Parameters
GET	/api/governance/controls	framework (eu_ai_act, nist_ai_rmf, owasp_asi, iso_42001), period (7d, 30d, 90d; default 30d)
GET	/api/governance/controls/export	format (json or csv; default json), and optionally framework, period, and from and to for the history (both or neither)
GET	/api/governance/controls/history	framework, from and to (UTC days, yyyy-mm-dd, both included). Each control’s recorded days and its summary for the range.
GET	/api/governance/controls/soa	framework (iso_42001 or nist_ai_rmf; default iso_42001). Every control with its entry; undecided where nothing is recorded.
PATCH	/api/governance/controls/soa	JSON body: framework, controlId, and any of applicability, justification, owner, evidenceRef, reviewCadenceDays, lastReviewedAt (a date, or null), markReviewed (true records today), reviewedBy

An unknown framework, period or format returns 400. So does a history range that is not two real days, starts after it ends, ends today or later, is longer than 366 days, or starts before the history kept. A PATCH with malformed JSON, a control id the framework does not have, a value of the wrong kind, an evidence link that is not http or https, a review date in the future, or Not applicable without a justification also returns 400.

curl -X PATCH -H "Cookie: <session>" -H "Content-Type: application/json" \
  -d '{"framework":"iso_42001","controlId":"A.5.5","applicability":"not_applicable","justification":"No AI system affects the public."}' \
  "https://<your-shield360>/api/governance/controls/soa"

curl -H "Authorization: Bearer <api-key>" \
  "https://<your-shield360>/api/governance/controls/history?framework=iso_42001&from=2026-07-01&to=2026-09-30"

Evidence package

A signed ZIP of this evidence for an auditor, and read-only auditor access.

Findings

Nonconformities and their corrective actions, suggested from control gaps.

Internal audit

The audit programme and each audit’s conclusions on the controls.

Management review

Reviews at planned intervals, with an input pack built from these records.

AI inventory

The register behind the inventory, ownership and vendor checks.

Enforcement policy

Sensitive data, approved models and prompt-injection settings.

Violations

Every enforcement outcome the checks count.