Compliance Frameworks

The frameworks page shows what your governance record is worth against a compliance framework, one control at a time. Every state is computed from the data MITRITY actually holds — the audit trail and its signed checkpoints, holds and approvals, the agent registry and its reviews, the lifecycle gate, DLP and injection enforcement, execution coverage, the risk register, assessments, policy statements and policy versions, roles and retention, red-team runs, the model inventory and compliance reports — and every figure comes with a sentence that says how it was counted. Where the evidence comes from lists each source and what full evidence takes.

Two rules hold everywhere on this surface:

• A control MITRITY cannot evidence is reported as not assessed. It stays in the denominator and is never counted as covered. The reason it cannot be evidenced is written beside it.
• No bare percentages. Wherever a coverage figure appears — the frameworks page, a control table, a report — the sentence beside it says how many applicable controls that is, how many MITRITY assessed, how many it did not, and how many are out of scope and why.

The libraries and how they are licensed

The framework libraries ship inside MITRITY and are versioned with it. Each library states the framework's own control identifiers as published. The description of what each provision requires is always MITRITY's own summary, written to a short ceiling and never a reproduction of the source text, and the titles are MITRITY's own short labels unless the library's attribution line says they are the source's official titles, as the EU AI Act and GDPR article titles and the OWASP and MITRE ATLAS names are. Every library declares an attribution line and a link to the authentic source, and every page that renders a control renders that attribution with it. The summaries describe what a provision requires; they do not say how to satisfy it, and they are not legal advice.

Which capability evidences which control is MITRITY's own assessment. It is not a certification, an audit opinion or a statement endorsed by a framework's authors: it shows what your governance record evidences for each control, and where the evidence has to come from elsewhere.

The GDPR, SOC 2 and ISO/IEC 27001 apply to everything an organization does — every system, supplier and process — and MITRITY evidences the part its governed AI agents perform. Every mapping in those three libraries is supporting evidence, so their controls show at most partial coverage: MITRITY's evidence is a real part of the answer, and the rest comes from your wider program.

The GDPR library carries the articles an AI agent program is assessed against, and the MITRE ATLAS library every tactic and the techniques that play out where agents act; every other library is complete against its source. Further libraries follow the same rules as they are released. The list your account carries, with each library's edition, is what GET /compliance/frameworks returns.

How a control state is computed

Each control is mapped, in the library, to one or more MITRITY capabilities. Behind every capability is a named evidence probe that runs against your data and reports what it found: no evidence, partial evidence or full evidence, a count, and a one-sentence summary made only of counts.

Opening a control shows each mapping with what its probe found and a link to the page where the evidence lives, so a reviewer can follow the claim to the records behind it.

Where the evidence comes from

Each capability below reads one part of your data. Full evidence takes everything in the second column; anything less is partial, and a capability that finds nothing is no evidence. Activity is counted over the last 30 days. A control's drawer names the capabilities behind it, what each one found, and a link to where the records live.

Applicability

Only the EU AI Act library ties its controls to a risk tier; in every other library each control applies until you record it as not applicable. Before coverage is counted, each EU AI Act control is tested against the highest risk tier declared across your agents (minimal, limited, high or unacceptable, set on the agent or by an approved assessment). A control that applies only to high-risk systems does not count against an account whose highest declared tier is limited; it is listed as out of scope with the reason, never as a pass. An account with no classified agent is told that the higher-tier obligations were not assessed because no agent carries a declared risk tier yet.

Obligations that fall on providers of general-purpose AI models are never derived from a deployer's risk tier. If that is you, declare the control in scope with an override.

Overrides and owners

A manager or owner can override a computed state — including declaring a control not applicable, which removes it from the denominator. Every override needs a reason of at least ten characters, because a percentage that moved because someone declared a control out of scope must carry the reason with it. The computed state stays visible beside the decision, and a recompute never touches an override.

A control can be given an owner — the person responsible for getting it to covered. The owner is free text, so someone can be named before they have a login.

Overrides and owner changes are written to the audit trail as compliance.control.overridden and compliance.control.owner_set, with the acting user.

When posture is recomputed

• On demand — the Recompute button, or POST /compliance/frameworks/recompute (member and above).
• Before every report — the states a report cites are computed from the data as it stands when the report is generated.
• Daily — an account's stored posture is refreshed when it is more than a day old or was computed against an older library edition.

Every stored state records the library edition it was computed against, and a page never shows a state from an edition older than the one your account carries.

From the API

List the frameworks with coverage:

curl https://api.mitrity.com/api/v1/compliance/frameworks \
  -H "Authorization: Bearer mk_your-api-key"

{
  "content_version": 10,
  "computed_at": "2026-09-22T06:00:00Z",
  "frameworks": [
    {
      "slug": "eu_ai_act",
      "short_title": "EU AI Act",
      "version_label": "Regulation (EU) 2024/1689, OJ text of 12 July 2024",
      "attribution": "…",
      "source_url": "https://eur-lex.europa.eu/eli/reg/2024/1689/oj",
      "control_count": 23,
      "coverage": {
        "applicable": 9,
        "covered": 3,
        "partial": 4,
        "not_covered": 1,
        "assessed": 8,
        "not_assessed": 1,
        "out_of_scope": 14,
        "not_applicable": 0,
        "coverage_percent": 33,
        "statement": "3 of 9 applicable controls covered (33%); 8 assessed by MITRITY, 1 not assessed; 14 out of scope for the limited tier.",
        "highest_risk_tier": "limited"
      }
    }
  ]
}

content_version is the edition of the framework libraries the figures were computed against. It goes up with every change to a library or to the capability and risk catalogues they share, so the number your account returns may differ from the one shown here.

The control table for one framework, with each control's state, applicability, owner and mappings:

curl https://api.mitrity.com/api/v1/compliance/frameworks/eu_ai_act/controls \
  -H "Authorization: Bearer mk_your-api-key"

One control evaluated live, with what each probe found:

curl https://api.mitrity.com/api/v1/compliance/frameworks/eu_ai_act/controls/EUAIA-12 \
  -H "Authorization: Bearer mk_your-api-key"

Override a control (manager or owner; override_state is covered, partial, not_covered or not_applicable, or null to clear):

curl -X PUT https://api.mitrity.com/api/v1/compliance/frameworks/eu_ai_act/controls/EUAIA-12/override \
  -H "Authorization: Bearer mk_your-api-key" \
  -H "Content-Type: application/json" \
  -d '{"override_state": "not_applicable", "note": "Record-keeping for this system is met by the platform SIEM."}'

Set an owner:

curl -X PUT https://api.mitrity.com/api/v1/compliance/frameworks/eu_ai_act/controls/EUAIA-12/owner \
  -H "Authorization: Bearer mk_your-api-key" \
  -H "Content-Type: application/json" \
  -d '{"owner_name": "Ana Platform", "owner_email": "ana@example.com"}'

Recompute (member and above):

curl -X POST https://api.mitrity.com/api/v1/compliance/frameworks/recompute \
  -H "Authorization: Bearer mk_your-api-key"

Reading the page well

• Read the sentence, not the ring. Two accounts can show the same percentage with very different denominators; the sentence says which controls were counted.
• Classify your agents first. Until an agent carries a declared risk tier, the tier-specific controls are out of scope and the page says so. An approved assessment sets the tier; so does editing the agent.
• Not assessed is not a failure. It marks the limit of what MITRITY can see, so you know which controls need evidence from elsewhere.