Compliance

Pro Plan — This feature requires a Pro subscription. Start a 30-day free trial →

Mipiti's bottom-up threat modeling (feature → assets → attackers → control objectives → controls) ensures security coverage. But compliance frameworks like OWASP ASVS, NIST 800-53, or PCI DSS mandate controls that may go beyond what risk analysis alone produces. The Compliance module bridges this gap with top-down compliance catalogs.

How it works

1. Select a framework for your threat model (e.g. OWASP ASVS 5.0)
2. Generate controls — the LLM sees framework requirements and maps controls to them automatically
3. Run gap analysis — a deterministic report shows which framework requirements are covered, partially covered, uncovered, or unmapped

No LLM is involved in the gap analysis itself — it is a pure cross-reference of your controls against the framework's requirement list.

Built-in frameworks

Mipiti ships with 11 built-in compliance frameworks, automatically seeded on startup:

Frameworks with levels support cumulative filtering: L2 includes all L1 requirements, and L3 includes all L2 requirements. You can filter the compliance report by level.

Target levels

Most level-aware frameworks let you pin a model to a specific tier so control generation, gap analysis, and reports scope to that tier instead of the framework's full breadth. Where the target level lives depends on the framework:

These axes are orthogonal: the same Component can simultaneously target SL 3 (under 62443), EAL 4 (under Common Criteria), and FIPS Level 2 (for its cryptographic module) without conflict.

Where to set each target

How these targets affect generation and reports

• Control generation prompt: per-component grades and org-level targets are injected into the LLM control-generation prompt as a dedicated section. The LLM sees "Component CMP1 targets SL 3" and "IEC 62443-4-1 target ML 3" and scopes control rigour accordingly.
• Auditor report (HTML/PDF): organization-level grades render as a "Compliance Posture Targets" block near the top of the report. Per-Component grades appear as columns in the new Appendix B.1 (Components). Per-CO CAL appears as an extra column in Appendix B (Control Objectives) when at least one CO has it set.
• Compliance descriptions in the report: continue to render via the universal level callout (description on top, framework-defined values for each level immediately below).

Cross-references inside requirement descriptions (e.g. an AC control referencing [AU-2a] in FedRAMP) are now rendered as proper inline links — clicking them scrolls to and briefly highlights the referenced requirement on the same compliance page.

Importing custom frameworks

If your organization follows a framework that is not built-in, you can import it as CSV or JSON.

CSV format

Minimum columns: id and description. Optional columns: chapter_id, chapter_name, section_id, section_name, title, level.

id,description,level
REQ-1,"All user input must be validated",1
REQ-2,"Sensitive data must be encrypted at rest",1
REQ-3,"HSM required for key management",2

JSON format

{
  "name": "My Framework",
  "version": "1.0",
  "level_definitions": {
    "1": {"name": "Baseline", "description": "Minimum controls every system implements.", "source": "authoritative"},
    "2": {"name": "Hardened", "description": "Adds controls for sensitive data systems.", "source": "authoritative"}
  },
  "requirements": [
    {"id": "REQ-1", "description": "All user input must be validated", "level": 1},
    {"id": "REQ-2", "description": "Sensitive data must be encrypted at rest", "level": 1},
    {
      "id": "REQ-3",
      "description": "Passwords meet length / complexity requirements",
      "level": 1,
      "level_specific_text": {
        "1": "Minimum 8 characters.",
        "2": "Minimum 14 characters; multi-factor required."
      }
    }
  ]
}

level_definitions (top-level, optional) — per-level semantic legend. Keys MUST be stringified integer levels ("1", "2", …) and the import endpoint rejects non-integer keys with HTTP 400. The reason: levels are an ordinal that drives the cumulative filter (level <= target_level) and the level: int field on every requirement — the key IS the ordinal. Display naming is decoupled: the human label ("Baseline", "Hardened", "SL3", "CAL Critical") lives in the name field, not in the key. Each entry takes name, description, and source: "authoritative" (paraphrased from the published standard) or source: "mipiti_convention" (you defined the tiers). Surfaced in the LLM prompt when this framework is selected, so reasoning about levels stays grounded in your definitions instead of training-data recall.

level_specific_text (per requirement, optional) — when a requirement has parameters or rigour that vary by level, encode them here. Same stringified-integer-key rule and same 400-on-malformed-key behavior. The LLM prompt and the framework-detail UI render these inline.

Requirements are displayed in the order they appear in the file — place chapters and sections in the order you want them shown. Import via the Import Framework button on the Compliance page. Custom frameworks can be deleted; built-in frameworks cannot.

After import, target levels work identically to built-ins: pin a model to a tier when selecting the framework, and control generation and gap analysis scope to level <= target automatically. (CSV import does not currently carry level_definitions or level_specific_text — use JSON when your framework is level-aware.)

Framework-aware control generation

When you select frameworks for a model before generating controls, the control generation prompt includes the framework's requirements. The LLM:

• Maps generated controls to relevant framework requirements (shown as FrameworkRefs on each control)
• May generate additional compliance-only controls that satisfy framework requirements but were not derived from the control objective matrix

These LLM-generated mappings have a confidence level of llm. You can manually add, remove, or verify mappings in the compliance report.

Auto-mapping existing controls

If you select a framework after controls already exist, click the Auto-Map Controls button in the compliance report. This sends your existing controls and the framework's requirements to the LLM in a single call, which identifies which controls satisfy which requirements and creates mappings automatically. No controls are regenerated — only mappings are created.

Gap analysis

The compliance report evaluates every framework requirement against your controls:

Each requirement is assessed on two independent dimensions:

Mapping status (do the right controls exist?):

Implementation status (are mapped controls done?):

The report shows a coverage progress bar, a breakdown by mapping status, and an implementation summary. Click any requirement to see its mapped controls and add new mappings.

Orphaned controls do not contribute to coverage. A control whose every mapped control objective was tombstoned (because its (asset, attacker) pair was removed in a later version) addresses no live threat on the current version. Letting it claim coverage credit would lie to the auditor — the implementation exists, but it defends a pair that's no longer part of the model. If you see a requirement drop from covered to unmapped after soft-deleting an asset, that's why: the control that satisfied it is now orphaned. Either remap it to a live CO or mark the requirement not-applicable with a rationale — the coverage number stays honest either way.

Mapping confidence

Each control-to-requirement mapping has a confidence level:

• llm — automatically generated during control generation
• manual — added by a user
• verified — reviewed and confirmed by a user

Gap remediation

When the compliance report shows unmapped, uncovered, or partial requirements, the Remediate Gaps button uses the LLM to propose fixes. The remediation pipeline:

1. Analyzes gaps — identifies requirements without adequate control coverage
2. Proposes entities — for each gap, the LLM suggests one of four actions:
   • Add asset + attacker — the most common case; both a new asset and a new threat actor are needed
   • Add asset only — existing attackers already cover the threat, but a new asset is needed
   • Add attacker only — existing assets cover the data/system, but a new attacker capability is needed
   • Not applicable — the requirement does not apply to this system (creates an exclusion)
3. Review — a modal shows all suggestions with proposed entity details and rationale. You can approve or reject each suggestion individually
4. Apply — approved suggestions are applied in a single version bump. The system adds the new entities, carries forward existing controls, generates new controls, and auto-maps them to the framework

The LLM deduplicates against existing entities — it will not propose an asset or attacker that already exists in your model.

Requirement exclusions

Requirements marked as "not applicable" are excluded from the gap analysis. They appear with a blue excluded badge in the report. You can restore an excluded requirement by expanding its row and clicking Restore.

Exclusions can also be created directly from the compliance report without running the full remediation pipeline.

Multiple rounds

After applying remediation, some requirements may still be unmapped if the new controls were not mapped to them. You can re-run gap remediation or use Auto-Map to create additional mappings.

MCP integration

Compliance-related tools available via the MCP endpoint:

Framework selection & reporting:

• list_compliance_frameworks — list available frameworks
• select_compliance_frameworks — select frameworks for a model
• get_compliance_report — run gap analysis
• map_control_to_requirement — create a control-to-requirement mapping
• remediate_compliance_gaps — analyze gaps, propose entities, and apply in one step

Target-level configuration (see Target levels for the full grade-encoding model):

• set_co_cal — set the ISO/SAE 21434 Cybersecurity Assurance Level (CAL 1–4) on a Control Objective
• update_organization — set or clear org-level posture targets (target_ml for IEC 62443-4-1, csf_tier for NIST CSF 2.0); org-admin gated
• edit_component — sets per-Component compliance grades alongside the existing identity fields (target_sl for IEC 62443 SL 1–4, eal for Common Criteria 1–7, fips_level for FIPS 140-3 1–4); orthogonal — the same Component can carry all three

Pinning a model to a per-framework target level (e.g. ASVS L1/L2/L3, FedRAMP Low/Mod/High, IEC 62443 SL 1–4) is currently a UI-only or HTTP-API operation: PATCH /api/models/{model_id}/compliance/frameworks/{framework_id} with {"target_level": int | null}. An MCP tool for this surface is not yet exposed.

Per-entity factor re-baselining:

• reevaluate_threat_model_factors — bulk re-run the LLM factor judgment on every live asset and attacker in a threat model. Records one revision per re-rated entity on the audit side-table; does NOT bump the model version, does NOT touch controls / assertions / components. Per-entity soft-fail: an LLM failure on one entity is recorded in failed_entities and the rest of the call continues. The change_reason parameter distinguishes this platform-driven recalibration from the deployment-specific factor overrides agents perform via edit_asset / edit_attacker.

System-level compliance

When multiple threat models are grouped in a system container, you can run compliance analysis across all member models from the system's Compliance tab.

How it works

1. Select a framework on the system — the selection automatically propagates to all member models
2. View the aggregated report — coverage is computed across all models with scope-aware logic
3. Exclude requirements at the system level ("not applicable to this product") — separate from model-level exclusions ("not applicable to this feature")

Requirement scope

Each framework requirement is classified as one of two scopes:

Scope is determined by an LLM analysis when a framework is first selected on a system. It is an inherent property of the requirement, not the system.

Relevance matrix

For component-scope requirements, not every model may be relevant. For example, a password-length requirement is irrelevant to a file storage model. The system computes a relevance matrix using an LLM that analyzes each model's assets against each requirement. Only relevant models must provide coverage for a component-scope requirement to be considered "covered".

The relevance matrix refreshes automatically when models change (entity additions, removals, or edits), and is also checked for freshness at report time.

Per-model coverage and actions

After running the aggregated report, a Per-Model Coverage section shows each model's individual coverage percentage with a progress bar and status breakdown. Models are sorted lowest-coverage-first so you can see where to focus.

Each model card has a Manage link that deep-links to the model's full compliance page (/compliance?model=X&framework=Y), where you can auto-map controls, remediate gaps, and manage individual mappings.

Model badges in the requirements table are also clickable — click any model pill to jump directly to that model's compliance page.

Framework propagation

• Selecting a framework on a system auto-selects it on all member models
• Adding a new model to the system propagates existing system framework selections
• Removing a framework from the system removes only propagated selections — direct model-level selections are preserved
• Per-model compliance still works independently

MCP integration

Two system compliance tools are available via the MCP endpoint:

• select_system_compliance_frameworks — select frameworks for a system (propagates to models)
• get_system_compliance_report — aggregated gap analysis across all system models

Relationship to Assurance

Compliance and Assurance are complementary:

• Assurance answers: "Are my risk-derived control objectives mitigated?"
• Compliance answers: "Does my model satisfy an external framework's requirements?"

A model can be fully mitigated (all COs addressed) but not fully compliant (missing framework-mandated controls that risk analysis did not produce). The compliance module closes this gap.