> 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/compliance-and-audit-readiness.md).
# Getting Started
Automated audit readiness with Dispel for NERC CIP, NIST 800-53, and NIS2 controls.
## Getting started
Producing a Dispel Compliance package is a four-stage workflow:
1. [**Select**](#step-1-select-a-framework) the framework(s) your organization reports against.
2. [**Assess**](#step-2-assess-dispels-coverage) Dispel’s coverage against your tenant’s current configuration.
3. [**Review**](#step-3-review-coverage-and-close-gaps) which controls Dispel covers, identify any gaps in coverage, and use the simulator to plan configuration changes that close them.
4. [**Export**](#step-4-export-the-inheritance-package) the OSCAL Component Definition and PDF report and hand them to your GRC team or auditor.
***
#### Step 1: Select a framework
Selecting a framework tells Dispel which control vocabulary to express its coverage in. Most organizations select the framework their auditor or competent authority works from. You can have multiple frameworks active at once — useful when the same Dispel deployment is audited against more than one regulatory regime.
1. In the left sidebar, navigate to **Settings**.
2. Open the **Compliance** tab.
3. Click **Add Framework**.
4. Select a **catalog** (e.g., *NIST SP 800-53 Rev 5*).
5. Select a **profile** or **baseline** (e.g., *Moderate*). Profiles narrow a catalog down to the subset of controls required at a given impact level.
6. Click **Add**.
The framework appears in your active frameworks list immediately. Dispel begins evaluating its coverage in the background and the dashboard populates as evaluators complete.
{% hint style="info" %}
Adding multiple frameworks does **not** duplicate work. Dispel produces a single set of evidence about its own implementation and re-expresses it through each active framework. Adding NIST CSF on top of NIST 800-53 reuses the same underlying evidence.
{% endhint %}
**Removing a framework**
To remove an active framework, click the trash icon next to it in the active frameworks list. Removing a framework deletes its scorecard but does not affect any other active framework or the underlying evidence record. **You can easily re-add removed frameworks without losing any of your history.**
***
#### Step 2: Assess Dispel’s coverage
**Automated assessment**
Dispel ships with a library of **control evaluators** that check whether Dispel — given your tenant’s current configuration — implements each in-scope control. For example: `is MFA enforced on this tenant`, `is session recording enabled`, `does the password policy meet the framework threshold`, and `are vendor attestations on file`. Each evaluator maps to one or more controls in each active framework.
To run an assessment:
1. Navigate to **Settings** > **Compliance**.
2. Open the framework you want to assess.
3. Click **Run Assessment**.
Assessment results are stored with a timestamp. Each control receives one of the following statuses, which describes Dispel’s implementation of that control on your tenant:
| Status | Meaning |
| ------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Implemented** | Dispel fully implements this control on your tenant. You may inherit it. |
| **Failed** | Dispel does **not** currently implement this control on your tenant — typically because a Dispel setting needs to change. You cannot inherit it as configured. |
| **Not Assessed** | No automated evaluator runs for this control, or evaluators have not yet completed. |
| **Not Applicable** | The control falls outside Dispel’s scope (e.g., physical security at your facility) and inheritance from Dispel does not apply. |
{% hint style="info" %}
Assessments are non-destructive and read-only. They observe Dispel’s configuration; they never modify your tenant.
{% endhint %}
***
#### Step 3: Review coverage and close gaps
The Compliance dashboard is your day-to-day workspace for understanding what Dispel covers on your tenant and where coverage can be improved.
**Scorecard**
Each active framework has a scorecard showing the percentage of in-scope controls Dispel currently implements on your tenant. Partial credit is given when only some sub-controls or enhancements are implemented. Hover any number for the underlying breakdown.
**Sunburst chart**
The hierarchical sunburst visualization shows Dispel’s coverage at a glance: framework → control family → individual control. Implemented (inheritable) controls render in green; failed (not currently inheritable) in red; unassessed in grey. Click any segment to drill into the control detail page.
**Control detail page**
Selecting a control surfaces:
* **Status** — Dispel’s current and historical implementation of the control on this tenant
* **Evidence** — the specific evaluators that contributed to the status, with timestamps and the underlying values they observed
* **Narrative** — Dispel’s implementation statement for the control
* **Lineage** — every other framework whose controls map to this same evidence (so a single inheritance claim can be expressed in multiple framework languages)
* **Remediation guidance** — for failed controls, a description of the Dispel setting or configuration change that would restore inheritance
**Configuration impact simulation**
Before changing a Dispel setting on your tenant, use the simulator to predict how coverage shifts:
1. From the dashboard, view **Est. Impact** under **Recommendations**.
2. Locate one or more Dispel settings in the overlay panel (e.g., *Enable MFA for all users*).
3. Compare the projected scorecard to your current scorecard.
The simulator does not modify any real settings. It is purely a planning tool for sequencing changes that strengthen Dispel inheritance.
{% hint style="info" %}
Use the simulator to sequence configuration changes in the order that restores the most inheritable controls first.
{% endhint %}
***
#### Step 4: Export the inheritance package
**OSCAL Component Definition**
The OSCAL Component Definition is the standardized artifact for documenting a single component’s contribution to a customer’s System Security Plan. For Dispel, that component is your Dispel deployment, and the Component Definition is the authoritative record of what your auditor can credit you for inheriting.
1. Open the framework’s detail page.
2. Click **Export** > **OSCAL Component Definition**.
3. A JSON file is downloaded conforming to OSCAL 1.1.2.
The export includes:
* The catalog and profile the inheritance claim is expressed in
* Each in-scope control’s implementation status from Dispel’s side (`implemented`, `partial`, `not-implemented`, `not-applicable`)
* Dispel’s implementation narrative for each control
* Links to the underlying evidence records
This file can be imported into eMASS, Xacta, RegScale, FedRAMP and GovRAMP submissions, or any tool that accepts OSCAL — where it sits alongside Component Definitions from your other vendors and your internal SSP content.
**Executive PDF report**
For internal stakeholders and audit cover letters:
1. Open the framework’s detail page.
2. Click **Export** > **PDF Report**.
The report contains:
* An executive summary stating what percentage of in-scope controls you can inherit from Dispel today
* A framework scorecard
* Every control Dispel does not currently implement on your tenant, with the configuration change that would restore inheritance
* The list of evidence sources contributing to the assessment
* Generation timestamp and the assessor identity
***
### Continuous evidence and audit trail
Each evaluator run produces an **evidence snapshot** that is stored with a timestamp. The snapshot records what Dispel observed about its own coverage at that moment.
Auditors who need to verify a specific moment in time can:
1. Locate the assessment record for the date in question.
2. Drill into the evidence snapshot for any individual control.
3. See the exact values the evaluator observed and the timestamp of observation.
***
### What Dispel covers (and what it does not)
Dispel covers the security controls that are implemented inside the Dispel platform itself — primarily the remote access, identity, session monitoring, network segmentation, and OT connectivity layers. Controls that depend on Dispel’s own corporate posture (vendor management, supply chain, SDLC, personnel screening) are also covered through Dispel’s published implementation narratives.
Dispel does **not** cover controls outside its footprint: physical security at your facilities, endpoint hardening on equipment Dispel does not manage, application development inside your business systems, HR practices at your organization, and so on. Those controls remain entirely with your enterprise GRC tooling.
The following table summarizes the categories of evidence Dispel produces and the framework control families they typically support. This is illustrative; the authoritative mapping for your active framework is shown on each control’s detail page.
| Evidence category | Representative NIST 800-53 families | Representative NERC CIP requirements | Representative NIS2 measures (Implementing Regulation 2024/2690) |
| ------------------------------------ | ----------------------------------- | ------------------------------------ | ---------------------------------------------------------------- |
| Identity, MFA, session lifecycle | AC, IA | CIP-004, CIP-005, CIP-007 | Identity & access control; authentication |
| Remote access and segmentation | AC, SC | CIP-005, CIP-007 | Network security; access control policies |
| Session recording and forensics | AU | CIP-007, CIP-008 | Incident handling; logging & monitoring |
| Configuration and change records | CM | CIP-010 | Asset management; change management |
| Vendor and supply-chain attestations | SR, PS | CIP-013 | Supply-chain security |
| Platform attestation and integrity | SI, SC | CIP-007, CIP-010 | Vulnerability handling & disclosure; cryptography |
***
### Frequently asked questions
Does running an assessment change anything on my tenant?
No. Assessments are read-only. They observe the current state of your Dispel configuration and produce evidence snapshots about Dispel’s coverage. They never modify settings, users, devices, or policies.
How often should I run an assessment?
For most organizations, running an assessment after any significant configuration change is sufficient. Some auditors require evidence of periodic assessment (e.g., monthly or quarterly) — schedule assessments to match the cadence your audit program requires. The OSCAL export and PDF report capture the assessment timestamp.
Can I use Dispel as my full GRC system?
No. Dispel is the system of record only for the controls Dispel itself implements — the inheritance layer beneath your audit. For controls outside Dispel’s footprint (physical security, HR processes, software development practices, endpoints Dispel does not manage, etc.), the evidence lives in your enterprise GRC platform. The Dispel OSCAL Component Definition is designed to be ingested into that platform as one component among many.
What does "Not Assessed" mean on a control?
A control shows *Not Assessed* when no automated evaluator runs against it yet, or when evaluators have not yet completed. This is distinct from *Not Applicable*, which means the control falls outside Dispel’s scope and is not part of what you can inherit from Dispel.
Can I demonstrate NIS2 compliance with Dispel?
For the portion of NIS2 that Dispel covers, we believe yes. Select **NIS2** as an active framework and Dispel produces a Component Definition expressed against the measures in the EU NIS2 Implementing Regulation (2024/2690), cross-walked to NIST 800-53 per ENISA’s Technical Implementation Guidance. Hand it to your competent authority alongside the rest of your NIS2 documentation as the inheritance layer for your remote access, identity, session monitoring, and OT connectivity controls.
ENISA has not published an official NIS2 OSCAL catalog. The Dispel catalog is authored directly from the legal text of the Implementing Regulation. If ENISA publishes an official catalog in the future, Dispel will adopt it.
Why do some controls show "Not Applicable"?
A control is marked *Not Applicable* when it falls outside Dispel’s footprint and is therefore not something you can inherit from Dispel — for example, controls governing physical access to your facility, hiring practices at your organization, or software development on your internal applications. The N/A determination is recorded in the OSCAL export so your auditor can see exactly which controls were excluded from the Dispel inheritance claim and verify them through other channels.
What happens to my data if I remove a framework?
Nothing, it is entirely safe. Removing a framework deletes its scorecard and removes it from the dashboard. Underlying evidence snapshots and control narratives are preserved and become available again if you re-add the framework. No assessment history is destroyed.
Does the OSCAL export include sensitive tenant configuration?
No. The Component Definition contains Dispel’s implementation status, narratives, and pointers to evidence — not raw configuration values, credentials, IP addresses, or user data from your tenant. It is safe to share with auditors and to upload to OSCAL-aware GRC platforms.
Can the same Dispel evidence support more than one framework?
Yes. This is the core benefit of the OSCAL-based architecture. A single piece of Dispel evidence (e.g., “MFA is enforced on this tenant”) contributes simultaneously to NIST 800-53 IA-2(1), NIST CSF PR.AA-03, NERC CIP-005-7 R2, and any other control that maps to the same evaluator. The same inheritance claim can be expressed in whichever framework language each of your audits requires.
How do I prove continuous Dispel coverage during an audit window?
Run an assessment at the start of your audit period and one at the end, and rely on the underlying evidence snapshots between the two. Each snapshot is timestamped, so you can show that your inheritance claim from Dispel was valid for every day of the audit period — not just the day the assessment was generated.
Can I add my own internal control framework?
Custom catalog ingestion is on the roadmap. Today, internal frameworks are typically represented by selecting the closest published baseline (e.g., NIST 800-53 Moderate) — Dispel will produce its inheritance evidence in that vocabulary, which your GRC team can then re-map onto the internal framework inside your enterprise GRC platform.
---
# 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/compliance-and-audit-readiness.md?ask=&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.