> 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/documentation/documentation-pt-br/proteja-e-governe/overview/compliance-and-audit-readiness.md).
# Primeiros passos
Prontidão automatizada para auditoria com o Dispel para controles NERC CIP, NIST 800-53 e NIS2.
## Primeiros passos
Produzir um pacote de Conformidade do Dispel é um fluxo de trabalho de quatro etapas:
1. [**Selecione**](#step-1-select-a-framework) os frameworks com os quais sua organização reporta conformidade.
2. [**Avaliar**](#step-2-assess-dispels-coverage) a cobertura do Dispel em relação à configuração atual do seu tenant.
3. [**Revisar**](#step-3-review-coverage-and-close-gaps) quais controles o Dispel cobre, identificar quaisquer lacunas de cobertura e usar o simulador para planejar mudanças de configuração que as fechem.
4. [**Exportar**](#step-4-export-the-inheritance-package) a Definição de Componente OSCAL e o relatório em PDF e entregá-los à sua equipe de GRC ou ao auditor.
***
#### Etapa 1: Selecione um framework
Selecionar um framework informa ao Dispel qual vocabulário de controles usar para expressar sua cobertura. A maioria das organizações seleciona o framework de onde o auditor ou a autoridade competente trabalha. Você pode ter vários frameworks ativos ao mesmo tempo — útil quando a mesma implantação do Dispel é auditada em relação a mais de um regime regulatório.
1. Na barra lateral esquerda, navegue até a aba **Configurações**.
2. Abra a **Conformidade** .
3. Clique em **Adicionar Framework**.
4. Selecione um **catálogo** (por exemplo, *NIST SP 800-53 Rev 5*).
5. Selecione um **perfil** ou **linha de base** (por exemplo, *Moderado*). Os perfis restringem um catálogo ao subconjunto de controles exigidos em um determinado nível de impacto.
6. Clique em **Adicionar**.
O framework aparece imediatamente na sua lista de frameworks ativos. O Dispel começa a avaliar sua cobertura em segundo plano e o painel é preenchido à medida que os avaliadores são concluídos.
{% hint style="info" %}
Adicionar vários frameworks não **duplica** o trabalho. O Dispel produz um único conjunto de evidências sobre sua própria implementação e o reexpressa por meio de cada framework ativo. Adicionar o NIST CSF junto ao NIST 800-53 reutiliza a mesma evidência subjacente.
{% endhint %}
**Remover um framework**
Para remover um framework ativo, clique no ícone de lixeira ao lado dele na lista de frameworks ativos. Remover um framework apaga seu scorecard, mas não afeta nenhum outro framework ativo nem o registro de evidências subjacente. **Você pode readicionar facilmente frameworks removidos sem perder nenhum do seu histórico.**
***
#### Etapa 2: Avalie a cobertura do Dispel
**Avaliação automatizada**
O Dispel vem com uma biblioteca de **avaliadores de controles** que verificam se o Dispel — dada a configuração atual do seu tenant — implementa cada controle no escopo. Por exemplo: `a MFA está imposta neste tenant`, `a gravação de sessão está habilitada`, `a política de senha atende ao limite do framework`, e `as atestações de fornecedores estão arquivadas`. Cada avaliador mapeia para um ou mais controles em cada framework ativo.
Para executar uma avaliação:
1. Navegue até **Configurações** > **Conformidade**.
2. Abra o framework que você deseja avaliar.
3. Clique em **Executar avaliação**.
Os resultados da avaliação são armazenados com um carimbo de data e hora. Cada controle recebe um dos seguintes status, que descrevem a implementação do Dispel desse controle no seu tenant:
| Status | Significado |
| ----------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Implementado** | O Dispel implementa totalmente este controle no seu tenant. Você pode herdá-lo. |
| **Falhou** | O Dispel **duplica** não implementa atualmente este controle no seu tenant — normalmente porque uma configuração do Dispel precisa ser alterada. Você não pode herdá-lo como está configurado. |
| **Não avaliado** | Nenhum avaliador automatizado é executado para este controle, ou os avaliadores ainda não foram concluídos. |
| **Não aplicável** | O controle está fora do escopo do Dispel (por exemplo, segurança física na sua instalação) e a herança do Dispel não se aplica. |
{% hint style="info" %}
As avaliações são não destrutivas e somente leitura. Elas observam a configuração do Dispel; nunca modificam seu tenant.
{% endhint %}
***
#### Etapa 3: Revise a cobertura e feche as lacunas
O painel de Conformidade é seu espaço de trabalho do dia a dia para entender o que o Dispel cobre no seu tenant e onde a cobertura pode ser melhorada.
**Scorecard**
Cada framework ativo tem um scorecard mostrando a porcentagem dos controles no escopo que o Dispel implementa atualmente no seu tenant. Crédito parcial é dado quando apenas alguns subcontroles ou aprimoramentos são implementados. Passe o mouse sobre qualquer número para ver a distribuição subjacente.
**Gráfico sunburst**
A visualização hierárquica em sunburst mostra a cobertura do Dispel de relance: framework → família de controles → controle individual. Controles implementados (que podem ser herdados) aparecem em verde; falhados (não herdáveis no momento), em vermelho; não avaliados, em cinza. Clique em qualquer segmento para acessar a página de detalhes do controle.
**Página de detalhes do controle**
Selecionar um controle exibe:
* **Status** — a implementação atual e histórica do controle pelo Dispel neste tenant
* **Evidências** — os avaliadores específicos que contribuíram para o status, com carimbos de data e hora e os valores subjacentes que observaram
* **Narrativa** — a declaração de implementação do Dispel para o controle
* **Linhagem** — todos os outros frameworks cujos controles se mapeiam para esta mesma evidência (assim, uma única reivindicação de herança pode ser expressa em várias linguagens de framework)
* **Orientação de remediação** — para controles com falha, uma descrição da configuração do Dispel ou da mudança de configuração que restauraria a herança
**Simulação de impacto da configuração**
Antes de alterar uma configuração do Dispel no seu tenant, use o simulador para prever como a cobertura muda:
1. No painel, visualize **Impacto estimado** em **Recomendações**.
2. Localize uma ou mais configurações do Dispel no painel sobreposto (por exemplo, *Habilitar MFA para todos os usuários*).
3. Compare o scorecard projetado com o seu scorecard atual.
O simulador não modifica nenhuma configuração real. Ele é puramente uma ferramenta de planejamento para sequenciar mudanças que fortalecem a herança do Dispel.
{% hint style="info" %}
Use o simulador para sequenciar mudanças de configuração na ordem que restaura primeiro os controles mais herdáveis.
{% endhint %}
***
#### Etapa 4: Exporte o pacote de herança
**Definição de Componente OSCAL**
A Definição de Componente OSCAL é o artefato padronizado para documentar a contribuição de um único componente para o Plano de Segurança do Sistema de um cliente. Para o Dispel, esse componente é sua implantação do Dispel, e a Definição de Componente é o registro oficial do que o auditor pode creditar a você por herdar.
1. Abra a página de detalhes do framework.
2. Clique em **Exportar** > **Definição de Componente OSCAL**.
3. Um arquivo JSON é baixado em conformidade com o OSCAL 1.1.2.
A exportação inclui:
* O catálogo e o perfil em que a reivindicação de herança é expressa
* O status de implementação de cada controle no escopo, do lado do Dispel (`implementado`, `parcial`, `não implementado`, `não aplicável`)
* A narrativa de implementação do Dispel para cada controle
* Links para os registros de evidências subjacentes
Este arquivo pode ser importado para envios ao eMASS, Xacta, RegScale, FedRAMP e GovRAMP, ou qualquer ferramenta que aceite OSCAL — onde ele fica ao lado das Definições de Componente de seus outros fornecedores e do conteúdo interno do seu SSP.
**Relatório executivo em PDF**
Para partes interessadas internas e cartas de apresentação de auditoria:
1. Abra a página de detalhes do framework.
2. Clique em **Exportar** > **Relatório em PDF**.
O relatório contém:
* Um resumo executivo indicando qual porcentagem dos controles no escopo você pode herdar do Dispel hoje
* Um scorecard do framework
* Cada controle que o Dispel não implementa atualmente no seu tenant, com a mudança de configuração que restauraria a herança
* A lista de fontes de evidência que contribuem para a avaliação
* Carimbo de data e hora da geração e a identidade do avaliador
***
### Evidência contínua e trilha de auditoria
Cada execução de avaliador produz um **instantâneo de evidências** que é armazenado com um carimbo de data e hora. O instantâneo registra o que o Dispel observou sobre sua própria cobertura naquele momento.
Auditores que precisam verificar um momento específico no tempo podem:
1. Localizar o registro de avaliação da data em questão.
2. Acessar o instantâneo de evidências de qualquer controle individual.
3. Ver os valores exatos que o avaliador observou e o carimbo de data e hora da observação.
***
### O que o Dispel cobre (e o que não cobre)
O Dispel cobre os controles de segurança implementados dentro da própria plataforma Dispel — principalmente as camadas de acesso remoto, identidade, monitoramento de sessão, segmentação de rede e conectividade OT. Controles que dependem da própria postura corporativa do Dispel (gestão de fornecedores, cadeia de suprimentos, SDLC, triagem de pessoal) também são cobertos por meio das narrativas de implementação publicadas pelo Dispel.
O Dispel **duplica** cobrir controles fora de sua área de atuação: segurança física nas suas instalações, fortalecimento de endpoints em equipamentos que o Dispel não gerencia, desenvolvimento de aplicativos dentro dos seus sistemas de negócios, práticas de RH na sua organização e assim por diante. Esses controles continuam totalmente sob sua ferramenta corporativa de GRC.
A tabela a seguir resume as categorias de evidência que o Dispel produz e as famílias de controles de framework que elas normalmente suportam. Isso é apenas ilustrativo; o mapeamento oficial para o seu framework ativo é mostrado na página de detalhes de cada controle.
| Categoria de evidência | Famílias representativas do NIST 800-53 | Requisitos representativos do NERC CIP | Medidas representativas do NIS2 (Regulamento de Implementação 2024/2690) |
| ----------------------------------------------------- | --------------------------------------- | -------------------------------------- | ------------------------------------------------------------------------ |
| Identidade, MFA, ciclo de vida da sessão | AC, IA | CIP-004, CIP-005, CIP-007 | Identidade e controle de acesso; autenticação |
| Acesso remoto e segmentação | AC, SC | CIP-005, CIP-007 | Segurança de rede; políticas de controle de acesso |
| Gravação de sessão e análise forense | AU | CIP-007, CIP-008 | Tratamento de incidentes; registro e monitoramento |
| Registros de configuração e alterações | CM | CIP-010 | Gerenciamento de ativos; gerenciamento de mudanças |
| Atestações de fornecedores e da cadeia de suprimentos | SR, PS | CIP-013 | Segurança da cadeia de suprimentos |
| Atestação e integridade da plataforma | SI, SC | CIP-007, CIP-010 | Tratamento e divulgação de vulnerabilidades; criptografia |
***
### Perguntas frequentes
Executar uma avaliação muda algo no meu tenant?
Não. As avaliações são somente leitura. Elas observam o estado atual da sua configuração do Dispel e produzem instantâneos de evidências sobre a cobertura do Dispel. Elas nunca modificam configurações, usuários, dispositivos ou políticas.
Com que frequência devo executar uma avaliação?
Para a maioria das organizações, executar uma avaliação após qualquer mudança significativa de configuração é suficiente. Alguns auditores exigem evidências de avaliação periódica (por exemplo, mensal ou trimestral) — agende as avaliações para corresponder à cadência exigida pelo seu programa de auditoria. A exportação OSCAL e o relatório em PDF registram o carimbo de data e hora da avaliação.
Posso usar o Dispel como meu sistema completo de GRC?
Não. O Dispel é o sistema de registro apenas para os controles que o próprio Dispel implementa — a camada de herança abaixo da sua auditoria. Para controles fora da área de atuação do Dispel (segurança física, processos de RH, práticas de desenvolvimento de software, endpoints que o Dispel não gerencia etc.), a evidência fica na sua plataforma corporativa de GRC. A Definição de Componente OSCAL do Dispel foi projetada para ser ingerida nessa plataforma como um componente entre muitos.
O que "Não avaliado" significa em um controle?
Um controle mostra *Não avaliado* quando nenhum avaliador automatizado foi executado contra ele ainda, ou quando os avaliadores ainda não foram concluídos. Isso é diferente de *Não aplicável*, o que significa que o controle está fora do escopo do Dispel e não faz parte do que você pode herdar do Dispel.
Posso demonstrar conformidade com o NIS2 com o Dispel?
Para a parte do NIS2 que o Dispel cobre, acreditamos que sim. Selecione **NIS2** como um framework ativo e o Dispel produzirá uma Definição de Componente expressa em relação às medidas do Regulamento de Implementação do NIS2 da UE (2024/2690), mapeadas para o NIST 800-53 conforme a Orientação Técnica de Implementação da ENISA. Entregue-a à sua autoridade competente junto com o restante da documentação do NIS2 como a camada de herança para seus controles de acesso remoto, identidade, monitoramento de sessão e conectividade OT.
A ENISA não publicou um catálogo OSCAL oficial para NIS2. O catálogo do Dispel é criado diretamente a partir do texto legal do Regulamento de Implementação. Se a ENISA publicar um catálogo oficial no futuro, o Dispel o adotará.
Por que alguns controles mostram "Não aplicável"?
Um controle é marcado *Não aplicável* quando está fora da área de atuação do Dispel e, portanto, não é algo que você possa herdar do Dispel — por exemplo, controles que governam o acesso físico à sua instalação, práticas de contratação na sua organização ou desenvolvimento de software em seus aplicativos internos. A determinação N/A é registrada na exportação OSCAL para que seu auditor possa ver exatamente quais controles foram excluídos da reivindicação de herança do Dispel e verificá-los por outros canais.
O que acontece com meus dados se eu remover um framework?
Nada, é totalmente seguro. Remover um framework apaga seu scorecard e o remove do painel. Os instantâneos de evidências subjacentes e as narrativas de controle são preservados e ficam disponíveis novamente se você readicionar o framework. Nenhum histórico de avaliação é destruído.
A exportação OSCAL inclui configuração sensível do tenant?
Não. A Definição de Componente contém o status de implementação do Dispel, narrativas e ponteiros para evidências — não valores brutos de configuração, credenciais, endereços IP ou dados de usuários do seu tenant. É seguro compartilhá-la com auditores e carregá-la em plataformas de GRC compatíveis com OSCAL.
A mesma evidência do Dispel pode dar suporte a mais de um framework?
Sim. Esse é o principal benefício da arquitetura baseada em OSCAL. Uma única evidência do Dispel (por exemplo, “A MFA está imposta neste tenant”) contribui simultaneamente para o NIST 800-53 IA-2(1), NIST CSF PR.AA-03, NERC CIP-005-7 R2 e qualquer outro controle que se mapeie para o mesmo avaliador. A mesma reivindicação de herança pode ser expressa na linguagem de framework que cada uma das suas auditorias exigir.
Como posso provar a cobertura contínua do Dispel durante uma janela de auditoria?
Execute uma avaliação no início do seu período de auditoria e outra no final, e confie nos instantâneos de evidências subjacentes entre as duas. Cada instantâneo tem carimbo de data e hora, então você pode mostrar que sua reivindicação de herança do Dispel foi válida em todos os dias do período de auditoria — não apenas no dia em que a avaliação foi gerada.
Posso adicionar meu próprio framework de controle interno?
A ingestão de catálogo personalizado está no roadmap. Hoje, frameworks internos normalmente são representados selecionando-se a linha de base publicada mais próxima (por exemplo, NIST 800-53 Moderate) — o Dispel produzirá sua evidência de herança nesse vocabulário, que sua equipe de GRC poderá então remapear para o framework interno dentro da sua plataforma corporativa de GRC.
---
# 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/documentation/documentation-pt-br/proteja-e-governe/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.