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 8 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.

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",
  "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}
  ]
}

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.

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.

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

Five compliance tools are available via the MCP endpoint:

• 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

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.