> For the complete documentation index, see [llms.txt](https://docs.dispel.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.dispel.com/secure-and-govern/overview.md).

# Compliance

Automated audit readiness with Dispel for NERC CIP, NIST 800-53, and NIS2 controls.

## Compliance & Audit Readiness Overview

The Compliance module turns Dispel into a continuous, evidence-backed control assessment of how Dispel implements security controls on your behalf. Instead of preparing for an audit by collecting screenshots and spreadsheets in the weeks beforehand, your GRC team can pull a current, timestamped view of where your organization stands against the frameworks that matter — at any time, in formats your auditors already accept.

Compliance is built on the [Open Security Controls Assessment Language (OSCAL)](https://pages.nist.gov/OSCAL/) specification published by NIST. Every catalog, profile, control implementation statement, and assessment record produced by Dispel is structured according to OSCAL 1.1.2 — so the artifacts you export are machine-readable, framework-neutral, and portable into whatever GRC platform your organization uses to assemble its full System Security Plan (SSP).

#### **Key benefits**

* **Inherited controls, proven continuously** — Dispel evaluates its own implementation of each in-scope control against your tenant’s live configuration, so the evidence supporting your inheritance claim is always current and timestamped.
* **One vocabulary per audit** — Choose the framework your organization reports against and Dispel re-expresses its coverage in that framework’s terms. The same underlying evidence supports NIST 800-53, NERC CIP, NIS2, and NIST CSF simultaneously.
* **Auditor-ready Component Definition** — Export an OSCAL Component Definition: the standard artifact for documenting a single component’s contribution to a customer’s SSP. Auditors and GRC platforms accept it as the authoritative inheritance package for Dispel.
* **Executive PDF report** — A concise narrative summary showing which controls you can claim from Dispel today, which are partial, and what configuration changes would close the remaining gaps in Dispel coverage.
* **Configuration impact simulation** — Before changing a Dispel setting, see exactly which inherited controls would move from partial to fully implemented (or the reverse). Use this to prioritize internal configuration changes that strengthen your inheritance posture.
* **Permanent evidence trail** — Every assessment captures a timestamped snapshot. During an audit window you can demonstrate that Dispel’s coverage was in place continuously, not just on the day of the audit.

#### **Who Compliance is for**

The Compliance module is designed for the people inside your organization who answer the question *“what does Dispel cover for us?”* during your own audits:

* **GRC analysts** assembling SSPs and audit responses for NERC CIP, NIST 800-53, NIST CSF, NIS2, SANS, or internal control frameworks, who need to know what they can inherit from Dispel.
* **CISOs and security directors** reporting compliance posture to executive leadership, boards, and regulators, and accounting for vendor inheritance in that posture.
* **Internal auditors** verifying that the controls your organization claims to inherit from Dispel are actually implemented in your Dispel tenant.
* **Operations leadership** at organizations subject to multiple, overlapping regulatory regimes who want a single source of truth for the Dispel portion of every audit.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.dispel.com/secure-and-govern/overview.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.