CMDash Help: Glossary

This glossary defines key terms used throughout the CMDash platform. Terms are organized alphabetically. Many have specialized meanings within CMDash that differ subtly from general industry usage — those nuances are noted where relevant.

Which number is which

CMDash shows several numbers that sound alike and measure completely different things. None of them feeds into any of the others, and none of them is a restatement of another. This is the one place they are reconciled; each row links to its full entry below.

Two rules of thumb. A Level is an ordinal on somebody's published ladder, so it is only comparable within that model; a Score is a 0–100 number CMDash computes. And the Posture Score is not a compliance measurement: a workspace can hold an A while a framework sits at 40% implemented, because the two read different data.

A

ALE (Annualized Loss Expectancy)

A FAIR-based financial risk metric that represents the expected monetary loss from a given risk scenario over a one-year period. In CMDash, ALE is calculated by multiplying Annualized Loss Event Frequency (ALEF) by the Loss Magnitude (LM) for each risk scenario. ALE is displayed on the Risk Register's FAIR Quantification panel and in board-level financial risk reports.

Alert Rule

A user-defined condition that triggers a notification when a specified threshold is crossed or a specific event occurs. Alert Rules in CMDash can be configured to watch for events such as a Posture Score dropping below a defined threshold, an integration going unhealthy, or a compliance control regressing from "Met" to "Not Met." Alert Rules are configured under Settings → Alert Rules and route notifications to configured Notification Channels.

Anomaly Detection

An automated CMDash capability that identifies unusual patterns in your security signals relative to your organization's historical baseline. Examples include a sudden spike in failed authentication attempts, a rapid increase in open vulnerabilities, or an unusual drop in endpoint coverage. Anomaly Detection findings appear as Insight Cards on the dashboard and may also generate Alert Rule notifications if configured.

Attestation

A formal, dated declaration — made by a named individual within your organization — confirming that a control or policy has been reviewed, implemented, or remains in effect. In CMDash, attestations are used as a form of manual evidence for compliance controls that cannot be automatically evaluated through integrations (e.g., physical access controls, contractual terms, personnel training). Attestations are timestamped, logged in the Audit Log, and can have configurable expiry periods.

Audit Evidence Package

A compiled, downloadable archive containing all evidence associated with a specific compliance framework assessment — including integration-sourced evidence, manually uploaded documents, attestations, and control status history. Audit Evidence Packages are generated under Reports → Evidence Package and are designed for delivery to external auditors, C3PAOs, or assessors. Unlike a live CMDash report link, an Audit Evidence Package is a static snapshot that does not require the recipient to have a CMDash account.

Audit Log

An immutable, time-stamped record of all actions taken within a CMDash tenant — including user logins, configuration changes, integration additions and removals, role changes, risk edits, and evidence uploads. The Audit Log is accessible to Owners and Admins under Settings → Audit Log and can be exported to CSV or forwarded to a SIEM. Audit Log entries cannot be edited or deleted by any user, including Owners.

B

Benchmarking

A feature that compares your organization's Posture Score, control coverage, and risk metrics against anonymized aggregate data from CMDash customers in the same industry vertical and approximate size range. Benchmarking data is displayed as percentile bands on the dashboard (e.g., "Your score is in the 68th percentile for mid-market financial services") and is updated monthly. Benchmarking data is aggregate and anonymized — individual customer data is never exposed.

BIA (Business Impact Analysis)

The exercise, on the Continuity & recovery section's BIA page, that identifies your organization's critical business processes, each process's Maximum Tolerable Period of Disruption (MTPD), and its upstream and downstream dependencies (systems, vendors, personnel, facilities). The BIA is the input every other continuity artifact is built from: a process's recovery priority in the Business Continuity Plan, and a system's recovery tier — and therefore its RTO/RPO commitment — in the Disaster Recovery Plan, both trace back to the BIA rather than being set independently. Refresh it at least annually and whenever a critical process changes materially.

BIMI (Brand Indicator for Message Identification)

A DNS TXT record that publishes a link to your organization's logo, which some mailbox providers display next to authenticated mail once DMARC enforcement is in place. In CMDash's Domain Posture module, the mail.bimi check reports a BIMI record's presence as informational only — it is optional and does not affect a domain's DNS Posture grade.

Business Unit (BU)

A sub-organizational unit within a CMDash tenant used to segment posture data, risks, and compliance tracking for different divisions, subsidiaries, geographic regions, or product lines. Business Units allow large organizations to view security posture at a corporate level (aggregated across all BUs) or drill into individual BU performance. BU hierarchy, user scoping, and risk tagging are available on Command and Enterprise plans.

C

C3PAO (Certified Third-Party Assessment Organization)

An organization accredited by the Cyber AB (CMMC Accreditation Body) to conduct formal CMMC Level 2 and Level 3 assessments for defense contractors. If your organization requires a CMMC assessment (rather than a self-assessment), you must engage a C3PAO to evaluate your compliance posture. CMDash supports C3PAO assessments by generating structured evidence packages, POA&M reports, and audit-ready control documentation that can be provided directly to your C3PAO assessor.

CAA (Certification Authority Authorization)

A DNS record that restricts which certificate authorities are allowed to issue TLS certificates for a domain, so a careless or compromised third-party CA cannot mint a valid certificate for it. In CMDash's Domain Posture module, the zone.caa check reports whether a CAA record is present, and — once certificate-transparency monitoring is available — whether it names the issuers actually seen for the domain.

CCM (Cloud Configuration Management)

The continuous monitoring and enforcement of secure configurations across cloud infrastructure (AWS, Azure, GCP) and SaaS applications. Within CMDash, CCM signals are sourced from connected cloud security posture management (CSPM) tools and used to evaluate compliance controls related to cloud hardening, encryption, and access configuration. CCM findings appear on the dashboard and in compliance frameworks such as NIST CSF and CIS Controls.

Client Comparison (Compare tab)

The Compare tab on the vCISO dashboard (/vciso): one framework's control status counts for every client workspace side by side, a drill to a single control across all clients, and each client's overdue remediation tasks. A client that has scoped the framework out shows Out of scope, and one whose figures could not be read shows Unavailable, never zeros. See vCISO — Multi-Client Dashboard.

CMMC (Cybersecurity Maturity Model Certification)

A U.S. Department of Defense framework mandating specific cybersecurity practices for defense contractors and subcontractors that handle Controlled Unclassified Information (CUI). CMMC has three levels: Level 1 (foundational, self-assessed annually), Level 2 (advanced, 110 practices from NIST SP 800-171; some contracts require C3PAO assessment), and Level 3 (expert, adds 24 practices from NIST SP 800-172; DCSA-assessed). CMDash supports Level 2 and Level 3 tracking with automatic control mapping, POA&M export, and C3PAO-ready evidence packages. CMMC tracking is available on every plan.

Collector Attestation

A signature made by a collector running inside your own network, over a measurement it took (for example how many hosts run an endpoint-detection agent). A receipt built from that measurement names the collector's key, and the signature travels beside the receipt as a companion document, so a relying party can check that the number was measured inside the supplier's boundary and not only signed by the platform. It does not prove the supplier's own system reported the truth to its collector. See Collector-attested receipts.

Compliance Calendar

A CMDash feature that displays upcoming compliance deadlines, evidence expiry dates, framework assessment due dates, and scheduled audit events in a calendar format. The Compliance Calendar helps security teams plan remediation and evidence renewal activities proactively. It is accessible under Compliance → Calendar and can be filtered by framework, control owner, or Business Unit.

Compliance Framework

A structured set of cybersecurity controls, requirements, and practices defined by a standards body, regulatory authority, or industry group that organizations adopt to demonstrate a minimum level of security maturity. Examples include CMMC, SOC 2, NIST CSF, PCI DSS, ISO 27001, and HIPAA. In CMDash, enabling a Compliance Framework begins tracking your compliance posture against it, and applies whatever evidence-mapping rules ship for that framework to your connected integration data. How many rules ship varies by framework, and for several frameworks it is none — the per-framework table in Compliance Mapping and Content says exactly which, and is generated from the shipped rules rather than maintained by hand.

Compliance Score

One of two different numbers, depending on which page you are looking at — they share a name and nothing else. On Alert Rules, "Compliance Score" is the share of your control assessments, across every framework you have scoped, whose status is Implemented: implemented ÷ total, rounded to a whole percentage, and 0 when you have no assessments at all. Evidence that has gone stale under an evidence-freshness SLA stops counting as Implemented, so this number can fall without anyone changing a status. On STIGs, each DISA benchmark has its own severity-weighted compliance score: CAT I rules weigh 10, CAT II 4 and CAT III 1, only Not a Finding counts as compliant (Open and Not Reviewed both count against you), rules marked Not Applicable are excluded, and a benchmark with no applicable rules scores 100. Neither number is the Posture Score, and neither is a maturity measurement — see Which number is which.

Control

A specific security requirement within a Compliance Framework — the individual unit of compliance assessment. For example, CMMC Practice AC.1.001 ("Limit information system access to authorized users") is a control. See Framework Line, below, for the record this is in CMDash's UI, and Tenant Control for the separate, related concept of what your organization actually built to satisfy it. A framework line's status is Not Started, In Progress, Implemented, Not Applicable, At Risk, or Failing (the last two are written only by Continuous Control Monitoring), driven by the evidence and controls linked to it.

Control Mapping

The process of associating a specific control from a Compliance Framework with the integration data and signals that can serve as evidence for that control. CMDash maintains a continuously updated control mapping library that defines which integration signals satisfy which controls across all supported frameworks. Control mappings are also the basis of Framework Crosswalk — if a control is satisfied in one framework, CMDash can automatically mark the equivalent control in a related framework.

CUI (Controlled Unclassified Information)

Information the U.S. federal government creates or possesses that requires safeguarding or dissemination controls pursuant to applicable laws, regulations, and policies (32 CFR Part 2002). CUI is a key concept in CMMC compliance — if your organization handles, processes, or stores CUI on behalf of DoD, you are subject to CMMC requirements. In CMDash, you can tag Business Units or integrations as "CUI environment" to scope CMMC compliance tracking specifically to the systems that handle CUI.

Custom Role

A user access role with a tailored set of permissions — created by an Owner on Enterprise plan accounts — that provides more granular access control than the built-in Owner, Admin, and Viewer roles. Custom Roles can be scoped to specific features (e.g., read-only access to Compliance but no access to Risk Register), specific Business Units, or specific frameworks. Custom Roles are managed under Settings → Roles.

D

Data Export

A user-initiated bulk export of CMDash data in a machine-readable format (CSV, JSON, or XLSX depending on the data type). Data Exports are available for the Risk Register, Audit Log, Compliance control lists, Integration sync logs, and POA&M. Data Exports do not contain integration credentials or personally identifiable information beyond user names and email addresses. Exports are available to Admins and Owners.

Dead Letter Queue

An internal system mechanism used by CMDash's integration pipeline to capture and retain data payloads that failed to process during a sync — for example, due to a temporary parsing error or data transformation issue. Dead Letter Queue items are automatically retried on the next sync cycle. This term appears in internal documentation and support escalations; end users do not interact with the Dead Letter Queue directly.

Dry-Run (Jira push)

The workspace setting that makes Send to Jira preview an issue without creating it. It is on by default. An owner or admin turns it off from the Send to Jira dialog after a confirmation, the change is written to the Audit Log, and every real push after that still waits for a confirmation. See Remediations.

DKIM (DomainKeys Identified Mail)

An e-mail authentication method that signs outbound mail with a private key, letting the receiving server verify the signature against a public key published at a DNS selector (for example google._domainkey.<domain>). In CMDash's Domain Posture module, the mail.dkim-probe check looks for a published selector across a list of common provider names plus any you supply, and reports the key's type and length. No selector list can be exhaustive, so a domain that publishes DKIM under an unlisted selector reads as UNKNOWN rather than FAIL — see Domain Posture.

DMARC (Domain-based Message Authentication, Reporting and Conformance)

An e-mail authentication policy, published as a DNS TXT record, that tells receiving mail servers what to do with mail that fails SPF and DKIM alignment (quarantine, reject, or take no action) and where to send aggregate reports about it. CMDash's Domain Posture module runs five DMARC checks — record presence, policy strength, aggregate-report configuration, subdomain policy, and alignment mode — and DMARC is the control (CIS Controls 9.5) a Domain Posture scan attaches machine evidence to, in place of a self-attested checkbox.

DNSSEC (Domain Name System Security Extensions)

A set of DNS extensions that lets a resolver cryptographically verify that a DNS answer came from the zone's real authoritative servers and was not forged in transit. In CMDash's Domain Posture module, the zone.dnssec check looks for a DS record at the parent zone and the AD (Authenticated Data) bit on answers; a DS record that fails validation scores worse than no DNSSEC at all, since it signals a broken deployment rather than an absent one.

Domain (within a framework)

A grouping of related controls within a Compliance Framework, used to organize the framework's requirements into thematic categories. For example, in CMMC, domains include Access Control (AC), Incident Response (IR), and System and Communications Protection (SC). In NIST CSF 2.0, the equivalent groupings are called Functions. In CMDash, the Compliance view organizes controls by domain, and domain-level completion percentages are displayed to help identify which areas have the most gaps.

E

External ID (AWS)

A value CMDash issues for each AWS connection and always sends when it assumes your IAM role. Your role's trust policy must require it (an sts:ExternalId condition), which stops another CMDash customer from pointing CMDash at your role. CMDash refuses to connect a role whose trust policy does not require it. See the AWS setup guide.

EPSS (Exploit Prediction Scoring System)

FIRST.org's daily-updated score (0–1) estimating the probability that a given CVE will be exploited in the wild in the next 30 days. In CMDash, EPSS scores appear alongside the CISA KEV catalog under Vendors → [vendor] → Exploit Intelligence, so a vulnerability's real-world exploitation risk — not just its raw CVSS severity — can drive what gets fixed first.

Evidence

Any data, document, or artifact that demonstrates a control is implemented and operating effectively. In CMDash, evidence can be:

• Automated evidence: Data pulled from a connected integration (e.g., MFA enrollment records from Okta, vulnerability scan results from Tenable) that CMDash maps to specific controls automatically.
• Manual evidence: Documents, screenshots, or records uploaded by a user (e.g., a signed security policy, a training completion certificate, an audit report).
• Attestation: A formal declaration by a named individual confirming a control is in place.

Evidence is displayed on the framework line it covers as an "N evidence" chip under Compliance → [Framework], and every piece of evidence has its own full record — opened from that chip, from the Evidence Vault, or from any control it is linked to. See Evidence Link.

Evidence Link

The connection between one piece of Evidence and one Framework Line or Tenant Control. The same evidence artifact can hold several Evidence Links at once — a single access-review screenshot might cover three framework lines and a control across two frameworks — so it is counted and can be opened from every place it applies, rather than existing as a separate copy under each one. A Quick Note creates its evidence and its first Evidence Link in one step. Crosswalk propagation (see Framework Crosswalk) also works by adding an Evidence Link, not by duplicating the underlying artifact.

Evidence Package

A compiled archive of evidence — including automated integration data snapshots, manually uploaded documents, and attestations — associated with a specific compliance assessment period. Evidence Packages are generated under Reports → Evidence Package and are intended for delivery to auditors, assessors, or regulators. Evidence Packages can be generated as a downloadable ZIP archive or as a structured PDF. See also: Audit Evidence Package.

F

FAIR (Factor Analysis of Information Risk)

An international standard quantitative risk analysis methodology (ANSI/IEC 27005) that models risk in financial terms by analyzing the frequency and magnitude of potential loss events. CMDash's FAIR Quantification feature allows you to model risks in your Risk Register using FAIR's Loss Event Frequency (LEF) and Loss Magnitude (LM) inputs to produce Annualized Loss Expectancy (ALE) figures. FAIR quantification enables risk-based conversations with boards and executives in business language (dollars at risk) rather than technical severity scores.

Feature Flag

An internal mechanism that allows CMDash to enable or disable specific features for individual tenants or user segments — typically used during gradual feature rollouts, beta programs, or when a feature has been provisioned for a specific plan tier. If you believe a feature should be available on your plan but it is not visible, it may be behind a feature flag that has not yet been enabled for your tenant. Contact support to inquire about availability.

Framework Crosswalk

The mapping of controls across multiple Compliance Frameworks that share overlapping or equivalent requirements. For example, CMMC IA.3.083 (multi-factor authentication) overlaps with NIST 800-171 3.5.3 and SOC 2 CC6.1. A crosswalk chip on a framework line names the mapped line and, for a partial or weak match, says so; clicking it opens that line's own record. From an evidence record, Propagate offers to add an Evidence Link to every crosswalked line above your workspace's confidence threshold — one artifact, several links, not a duplicate per framework. Framework Crosswalk mappings are managed by CMDash and updated as frameworks are revised.

Framework Line

One requirement from a Compliance Framework's catalogue (e.g., CMMC AC.L2-3.1.5), shown as a row under Compliance → [Framework] → [Domain]. A framework line carries its own status, and opens as a full record — its requirement text, every linked Evidence item and Tenant Control, its Quick Notes, and its activity history — either as a dialog over the framework page or at its own page address (/compliance/[framework]/[code]) for sharing. "Control" (above) is the general compliance-industry term for the same requirement; CMDash calls the record a framework line to keep it distinct from a Tenant Control, which is a different thing that happens to share the word "control."

H

How to Fix

The block on a control's record that explains an At risk or Failing line: the signal the monitoring rule read, hand-written steps a person follows in your own tools, and the open remediation task with its Send to Jira button. CMDash does not make the change for you. A monitoring rule your workspace wrote has no written fix. See Compliance Frameworks.

I

Incident Frequency

In the context of FAIR risk quantification, Incident Frequency refers to the number of times a threat event results in an actual loss — measured per year. Within CMDash's FAIR module, you input Threat Event Frequency (how often a threat actor attempts an action) and Vulnerability (the probability the attempt succeeds) to derive Incident Frequency, which is one of the two primary inputs to ALE alongside Loss Magnitude.

Insight Card

A prioritized, actionable recommendation displayed on the CMDash dashboard that explains a specific finding, its impact on your Posture Score or compliance posture, and the recommended remediation action. Insight Cards are generated by CMDash's analytics engine and AI systems based on your current integration data, compliance gaps, and risk register. Examples include: "Connect your Azure AD integration to improve MFA coverage accuracy" or "7 critical CVEs from last week's Tenable scan are not yet assigned in the Risk Register." Dismissing an Insight Card removes it until the underlying condition changes.

Integration

A connector between CMDash and an external security or IT tool that enables CMDash to pull data (read-only) from that tool via API. Integrations are the primary data source for automated posture scoring and compliance control evidence. CMDash supports integrations with endpoint security tools (CrowdStrike, SentinelOne, Carbon Black, Microsoft Defender), identity providers (Okta, Azure AD / Entra, Duo), vulnerability management (Tenable), email security (Proofpoint), network security (Cisco Umbrella), cyber insurance (Coalition), and 13+ additional platforms. Integrations are configured under the Integrations section of the navigation.

IP (Internet Protocol address)

The numeric network address of a host on the internet, in IPv4 (for example 198.51.100.7) or IPv6 form. In CMDash's IP reputation module (Security → Exposure → IP reputation), your organization's public addresses come from two places: addresses derived from the DNS records of your verified domains (their A/AAAA records, your own mail servers, and the ip4/ip6 entries of your own SPF record), and addresses you declare yourself, which are labelled "declared, unverified" and count toward your plan's cap. Private, reserved and other non-public addresses are refused. Each address is checked daily against reputation sources such as blocklists, and a source that could not be asked is shown as Unknown, never as clean.

ISPM (Information Security Program Management)

The governance layer above any single framework — charter, objectives, committees, management reviews, and security-awareness training for the security program as a whole (ISO 27001 clauses 4–9, NIST PM family). In CMDash, the ISPM hub lives at Program in the navigation and is ungated, unlike the per-framework Compliance pages it sits alongside.

J

JIT Provisioning (Just-in-Time Provisioning)

An authentication method available starting on Starter plans (the same tier as SAML SSO itself) that automatically creates a CMDash user account the first time a user successfully authenticates via SSO/SAML, without requiring the Owner to pre-create the account or send an invitation. JIT Provisioning is useful for organizations with large user populations using SSO, as it eliminates the manual invitation step while still respecting role assignments configured in the IdP. JIT Provisioning is enabled under Settings → Security → SSO Configuration.

Journey

An ordered sequence of pages you move through to accomplish one goal — getting a workspace set up, running the compliance loop, or preparing a CMMC submission — drawn as numbered steps rather than a strip of statuses, because a journey has no status of its own; it is you moving from page to page. See Typical workflows for the full set.

K

KEV (Known Exploited Vulnerabilities)

CISA's catalog of vulnerabilities confirmed to be actively exploited in the wild, published at cisa.gov/known-exploited-vulnerabilities-catalog. In CMDash, uploading a vendor's SBOM cross-references its components against the KEV catalog under Vendors → [vendor] → Exploit Intelligence; a component's absence from the results means nothing in the catalog names that product, not that it is safe.

L

LEF (Loss Event Frequency)

A FAIR metric representing how often a loss event (a threat action that results in actual damage) is expected to occur per year. LEF is derived from Threat Event Frequency (TEF) and Vulnerability (the probability a threat event results in a loss). In CMDash's FAIR Quantification module, LEF is calculated from the inputs you provide and displayed alongside LM and ALE on each risk's FAIR panel.

Lifecycle

The sequence of statuses a record such as an Exception, a Policy, or a POA&M item moves through from open to closed, drawn as a diagram in the workflow guides: an arrow along the row is a step forward, and an arc drawn above the row is a step backward. See Typical workflows for the full set of lifecycle diagrams.

LM (Loss Magnitude)

A FAIR metric representing the expected financial impact of a single loss event — combining primary losses (direct costs such as incident response, data recovery, regulatory fines) and secondary losses (indirect costs such as reputational damage, customer churn, litigation). In CMDash's FAIR Quantification module, you input LM as a range (minimum, most likely, maximum) and the system uses Monte Carlo simulation to produce a probability-weighted expected loss value.

M

Maturity Level

Where one dimension of one maturity model currently sits on that model's own ordinal ladder — Tier 1 to 4 for NIST CSF tiers, IG1 to IG3 for CIS Implementation Groups, and so on. Every maturity model in CMDash ships its own ladder, so a level is only meaningful inside its model: "Level 2" in one model is unrelated to "Level 2" in another, and to a CMMC level. Each dimension carries a current level and, where you have set a target profile, a target level; the difference between them is the gap the Maturity pages plan against. A dimension you have never assessed is unknown, not level zero, and is excluded from the Maturity Rollup rather than counted as a failure. Levels recorded from a seeded pack or an attestation are capped one rung below the model's top level for rollup purposes — you cannot claim the highest level on your own say-so alone. See Which number is which.

Maturity Rollup

The single number for a whole maturity model, shown on Maturity → [model] as the tile labelled "Rollup": a weight-normalized mean of the effective levels of every dimension you have assessed, expressed 0–100. Dimensions you have not assessed are excluded from the denominator, so a rollup is always read alongside its coverage figure — below a coverage floor the tile shows "—" instead of a number rather than implying a programme-wide result from two assessed dimensions. Where exceptions suppress a dimension, the count of suppressed dimensions is shown next to the label and the unsuppressed figure is one click away. A crown-jewel-weighted rollup is shown beside it, never in its place. This is the closest thing CMDash has to an overall maturity number; it is not called a "maturity score" anywhere in the product. See Which number is which.

Maturity Score

Not a CMDash term. Industry writing uses "maturity score" loosely for either a per-dimension Maturity Level or a model-wide Maturity Rollup, which are different numbers on different scales — CMDash names both and computes no third metric by this name. If a document, a proposal, or an assessor asks for "your maturity score", establish which of the two they mean before answering. See Which number is which.

MFA Coverage

A Posture Score signal that measures the percentage of user accounts in your environment that have multi-factor authentication enabled and enrolled, as reported by your connected identity providers. MFA Coverage is one of the highest-weighted signals in the CMDash Posture Score due to the significant impact MFA has on credential-based attack prevention. MFA Coverage is calculated by aggregating enrolled accounts across all connected identity providers (Okta, Azure AD, Duo, etc.) and dividing by the total active account count.

MTA-STS (Mail Transfer Agent Strict Transport Security)

A mechanism, published as both a DNS TXT record and a policy file at https://mta-sts.<domain>/.well-known/mta-sts.txt, that tells sending mail servers to require a valid, encrypted TLS connection before delivering mail to a domain — closing the downgrade attack plain SMTP otherwise allows. CMDash's Domain Posture module runs two checks, mail.mta-sts-txt and mail.mta-sts-policy, verifying the record and fetching the policy file itself.

MTPD (Maximum Tolerable Period of Disruption)

The longest a business process can be disrupted before the impact to the organization becomes unacceptable — the number the Business Impact Analysis (BIA) exists to establish, process by process. A process's MTPD sets the ceiling for its recovery priority in the Business Continuity Plan and, by extension, the recovery tier (and RTO) assigned to the systems that process depends on. A shorter MTPD does not automatically mean more budget gets spent recovering it — it means the organization has less time to decide that before the impact is already unacceptable.

MTTR (Mean Time to Remediate)

A metric that measures the average number of days between when a vulnerability, finding, or risk is identified and when it is marked as resolved or remediated. In CMDash, MTTR is calculated separately for each severity level (Critical, High, Medium, Low) and for each integration source. MTTR is displayed on the Risk Register analytics view and in board reports. A decreasing MTTR trend over time demonstrates an improving security operations capability.

Multi-BU Hierarchy

The organizational structure in CMDash that allows a single tenant to contain multiple Business Units (BUs) arranged in a parent-child hierarchy. For example, a corporate parent can contain subsidiary BUs for each regional division. Multi-BU Hierarchy enables roll-up reporting (aggregated posture at the corporate level) and drill-down analysis (individual BU posture). User access can be scoped to specific BUs using Custom Roles on Enterprise plan.

N

Narrative (AI Narrative)

An automatically generated, human-readable summary of your organization's current security posture, key findings, and recommended priorities — produced by CMDash's AI engine. The Narrative is designed to be included in board reports and executive briefings without requiring manual writing. It is generated fresh each time from your current integration data and is written in non-technical language appropriate for a board audience. The Narrative does not use your data to train AI models and is generated using zero-data-retention API agreements with AI providers.

Notification Channel

A configured destination for CMDash alerts and automated reports. Notification Channels define how and where CMDash sends notifications — supported channel types include email, Slack, Microsoft Teams, and webhook. Channels are configured under Settings → Notification Channels and are referenced by Alert Rules and Scheduled Reports. An organization can configure multiple channels of the same type (e.g., one Slack channel for the security team and a separate one for executive escalations).

O

OSCAL (Open Security Controls Assessment Language)

A NIST-published set of standardized, machine-readable formats (XML/JSON/YAML) for expressing system security plans, component definitions, assessment plans, and assessment results (pages.nist.gov/OSCAL). In CMDash, the OSCAL module generates SSPs and assessment-results documents from your framework assessments, validates uploaded OSCAL documents against the real NIST OSCAL v1.2.3 JSON Schema, and can diff two documents of the same kind to show what changed between assessment cycles.

Owner (role)

The highest-privilege role in CMDash. Owners have full access to all features, including billing management, plan changes, tenant deletion, and user management. An Owner can change any other user's role, including promoting a user to Owner. Every CMDash tenant must have at least one Owner. Owners receive all system-level notifications (integration failures, critical alerts) regardless of their Notification Channel configuration. Unlike Admin, the Owner role cannot be customized or restricted.

P

POA&M (Plan of Action and Milestones)

A structured document — required for CMMC and FedRAMP compliance — that identifies security weaknesses or deficiencies, the planned actions to address each one, the responsible parties, and the target completion milestones. In CMDash, the POA&M export is generated from your control assessments — every control that is not Implemented or Not Applicable, including any whose evidence has gone stale — and the standalone POA&M register at Security → POA&M tracks items raised any other way. Export it from Compliance → [framework] as XLSX (columns in the FedRAMP POA&M Template's order; columns CMDash does not model are left blank, and import into CSAM/Xacta/eMASS has not been verified against a specific release) or CSV (CMDash's own columns).

Partner API Key

An API key minted by a vCISO or MSP practice that reads the client workspaces the practice owns through the read-only /v2/partner/* API. It reaches the client list, posture, control statuses, open remediation tasks and proof receipt metadata, and nothing else; a tenant API key and a partner key do not work on each other's routes. See the Partner API reference.

Policy

A documented organizational rule or standard that defines required security behavior, configuration requirements, or procedural expectations. In CMDash, Policies can be uploaded as documents (PDF, DOCX) and linked to Compliance Controls as evidence. Policies can also be configured for Policy Attestation workflows, where employees are required to formally confirm they have read and understood the policy.

Policy Attestation

A workflow in which one or more users are required to formally attest that they have read, understood, and agreed to comply with a specific Policy. In CMDash, Policy Attestation workflows can be created under Compliance → Policies → [policy] → Create Attestation Workflow. The system tracks who has attested, when, and can send reminders to users who have not completed their attestation. Attestation completion rates and timestamps are available as evidence for related compliance controls.

Posture Score

CMDash's primary metric for representing overall security health — expressed as a letter grade from A (excellent) to F (critical risk). The Posture Score is calculated in real-time from a weighted aggregate of exactly seven security signals:

• Mean Time to Patch
• MFA Coverage
• Open Critical Vulns
• Incident Frequency (30d)
• Policy Compliance
• SaaS Sprawl
• DLP Violations (30d)

The score is designed to be immediately interpretable by both technical teams and executive stakeholders. Score history, signal breakdowns, and industry benchmarks are available on the dashboard. The underlying number runs 0–100 (one decimal); the grade bands are A at 90 and above, B at 80, C at 70, D at 60, F below that. It measures operational security signals, not compliance progress and not maturity — see Which number is which for how it differs from the Compliance Score and the maturity numbers.

Proof Receipt

A small, signed statement about one measured or self-attested claim: the numerator, the denominator and what was left unknown, with its basis (Measured, Self-assessed or Self-attested) and a freshness window. Anyone can check one offline with the public verifier, without asking CMDash. See Proof receipts.

Provenance

Where a piece of evidence or a policy version came from: machine collected, human attested, AI drafted or unknown. Only machine-collected and human-attested content may back a claim that a control is covered; AI-drafted and unknown content is refused. See Content provenance.

Q

Quick Note

A short note typed directly under a Framework Line on Compliance → [Framework] that becomes a dated, attributed Evidence item (kind Text) linked to that line — not a shared notes field the next person overwrites. On a line that is still Not Started, a checkbox next to the box optionally sets it to In Progress in the same step; the checkbox's default is a per-workspace setting under Settings → Compliance, and a Quick Note never changes status on its own unless it is ticked.

R

Record Panel

The one component CMDash uses to show a Framework Line, a Tenant Control, or an Evidence item — same layout, a header naming which of the three it is, its status, its links to the other two record types, and an activity feed with a comment thread. It opens as a dialog over the page you were on (its address lives in the URL as ?open=<kind>:<id>, so it survives a reload and can be shared) or as its own page for a deep link, a search result, or a notification.

Relying Party

An organization that relies on another organization's security claims, for example a prime contractor or an insurer, and asks that organization (the supplier) for proof through the Relying-Party Desk. It reads only the signed receipts the supplier granted, and only while the grant is active. See Relying-Party Desk.

Remediation

The process of addressing and resolving a specific vulnerability, risk, or compliance gap. In CMDash, Remediation refers to the workflow of assigning a risk to an owner, setting a due date, tracking progress through statuses (Open → In Remediation → Resolved/Closed), and verifying that the fix has been reflected in subsequent integration syncs. MTTR is the primary metric for evaluating remediation performance.

Risk

An identified potential event or condition that could negatively affect the organization's security posture, operations, or compliance status. In CMDash, a Risk is a record in the Risk Register that includes a description, severity rating, likelihood, potential financial impact (FAIR-quantified or qualitative), status, assigned owner, due date, and linked compliance controls. Risks can be imported automatically from integration findings or created manually by users.

Risk Register

The centralized repository of all identified risks within a CMDash tenant. The Risk Register provides a unified view of open, in-remediation, accepted, and closed risks across all sources (integration-sourced vulnerabilities, manual entries, TPRM findings). The Risk Register supports sorting, filtering, Saved Views, bulk assignment, CSV export, and POA&M generation. It is the operational hub for day-to-day risk management within CMDash.

Risk Score

A numerical or categorical rating assigned to each risk in the Risk Register that represents the combined assessment of its likelihood and potential impact. CMDash supports both qualitative risk scoring (Critical / High / Medium / Low, derived from likelihood × impact matrices) and quantitative scoring (FAIR-based ALE in dollar terms). Risk scores are used to prioritize remediation efforts and to filter and sort the Risk Register.

RPO (Recovery Point Objective)

The maximum acceptable data loss for a system, measured as the age of the last recoverable data at the moment a disruption occurs. Shown on the Continuity & recovery section's Recovery objectives page alongside each system's committed RTO and its actually-tested result. RPO is a backup-frequency question, not a recovery-speed question — it is what the Backup Policy's 3-2-1 rule and restore-testing requirements exist to make achievable in practice, not just on paper.

RTO (Recovery Time Objective)

The target elapsed time between a disruption's onset and a service's restoration. Shown on the Continuity & recovery section's Recovery objectives page next to each system's RPO, tracked against the recovery register and recovery-test history so a committed target and an actually-tested result sit next to each other. RTO is set per system tier in the Disaster Recovery Plan, driven by the tier that system's business process was assigned in the Business Impact Analysis (BIA).

S

SAML / SSO (Security Assertion Markup Language / Single Sign-On)

A standard protocol for federated authentication that allows users to log in to CMDash using their organization's existing identity provider (e.g., Okta, Azure AD, Ping Identity) without maintaining a separate CMDash password. SAML SSO is configured under Settings → Security → SSO Configuration and is available starting on the Starter plan (SCIM and LDAP directory sync remain Enterprise-only). SSO eliminates the need for users to remember separate credentials and enables centralized access control through the IdP.

Saved View

A named, persistent filter configuration applied to a list view in CMDash (such as the Risk Register, Compliance control list, or Integration list) that allows users to quickly switch between predefined subsets of data. For example, a CISO might create a Saved View called "Critical Open Risks — Q3" that filters the Risk Register to show only Critical-severity risks in Open or In-Remediation status with a due date in Q3. Saved Views are per-user by default but can be shared with the team.

SBOM (Software Bill of Materials)

A formal, machine-readable inventory of the components (libraries, packages, and their versions) that make up a piece of software, per the NTIA's minimum elements for an SBOM (ntia.gov). In CMDash, you upload a vendor's CycloneDX JSON SBOM under Vendors → [vendor] to cross-reference its components against the CISA KEV catalog and to check for component concentration risk across your vendor portfolio.

SCIM (System for Cross-domain Identity Management)

An open standard protocol (RFC 7644) that enables automated user provisioning and deprovisioning between an identity provider (Okta, Azure AD, etc.) and CMDash. When SCIM is configured, adding a user to the CMDash application group in your IdP automatically creates their CMDash account; deactivating their IdP account automatically revokes their CMDash access. SCIM eliminates the need for manual invitation management at scale. SCIM is available on Enterprise plan and is configured under Settings → Security → SCIM.

Send to Jira

The button that turns a remediation task into a Jira issue, on Remediations and in a control's How to Fix block. Available to owners and admins on plans that include ticket push (Essentials and above). It previews the exact issue first; see Dry-Run. Pushing the same task twice returns the same issue. See Remediations.

Signal

One of the seven measurements that make up the Posture Score, each sourced from a connected integration (Policy Compliance instead comes from your own control assessments): Mean Time to Patch, MFA Coverage, Open Critical Vulns, Incident Frequency (30d), Policy Compliance, SaaS Sprawl, and DLP Violations (30d) — see Posture Score for the full list. Each signal is weighted in the Posture Score calculation — weight customization is available on Command and Enterprise plans.

SPF (Sender Policy Framework)

A DNS TXT record that lists which mail servers are authorized to send mail on a domain's behalf, so a receiving server can reject mail claiming to be from that domain sent anywhere else. CMDash's Domain Posture module runs seven SPF checks — the single-record rule, whether the record parses, the RFC 7208 10-DNS-lookup budget, the terminal qualifier (-all/~all/+all/?all), the deprecated ptr mechanism, the 2-void-lookup budget, and whether any mechanism authorizes an implausibly large address range — because a permissive or malformed SPF record is one of the most common ways a domain leaves itself open to spoofing.

SPRS (Supplier Performance Risk System)

The DoD system a contractor's NIST SP 800-171 Rev 2 self-assessment score is submitted into, per DFARS 252.204-7020 — a summary-level score from 110 (fully implemented) down to as low as -203, computed by starting at 110 and subtracting each unimplemented control's assigned point value (1, 3, or 5, weighted by the control's security impact). In CMDash, SPRS (Compliance → SPRS Basic Assessment) computes this score from your existing CMMC Level 2 / NIST SP 800-171 control assessments, tracks which enclave(s) it covers, and exports the CSV or PDF artifact filed with PIEE (Procurement Integrated Enterprise Environment) — CMMC's Basic Assessment tier posts this same self-generated score.

Stack Preset

An optional choice in the onboarding wizard's first step ("What do you run?") that pairs a described tool stack with the frameworks and connectors that usually go with it. It pre-ticks the frameworks, still capped to what your plan allows, and puts the connectors first. Nothing is locked in. See the Quick Start Guide.

SSP (System Security Plan)

The core artifact of a NIST SP 800-171 / CMMC Level 2 assessment: a document describing a system's boundary, the security requirements that apply to it, and how each one is implemented. In CMDash, the SSP is generated under OSCAL → Export from the approved system boundary (Program → System Boundary) plus your control implementation statements, and without one the assessment cannot be scored.

Sync

The process by which CMDash retrieves the latest data from a connected integration via API. Syncs occur automatically on a scheduled basis (typically every 15 minutes) and can be manually triggered at any time from the Integrations page. The most recent sync timestamp ("Last Synced") and any sync errors are displayed on each integration's detail page. The Posture Score and compliance control statuses update automatically following each successful sync.

T

Tag

A user-defined label applied to Risks, Integrations, Evidence, or Business Units to enable custom categorization, filtering, and reporting. Tags are free-form text and can represent concepts such as system names, regulatory applicability, remediation owners, or project codes. Tagged items can be filtered using Saved Views and included or excluded from specific report scopes.

Tenant

A logically isolated instance of CMDash belonging to a single customer organization (or client, in the case of a vCISO managing multiple clients). Each tenant has its own data, users, integrations, posture history, compliance frameworks, and billing account. Data from one tenant is never accessible to users of another tenant. In a vCISO multi-client deployment, each client has their own tenant and the vCISO practitioner uses the vCISO console to switch between them.

Tenant Control

Your organization's own implemented safeguard, tracked under Controls in the sidebar — distinct from a Framework Line, which is the catalogue requirement it satisfies. A Tenant Control has a key (e.g. CTL-042), a title, description, owner, implementation type (Preventive, Detective, Corrective, Administrative), and its own status; one control commonly covers several framework lines across several frameworks at once. Both POA&M exports name the Tenant Controls linked to each open requirement.

The Skeptic

The display name of CMDash's AI add-on (formerly "AI Assistant"). Only the display name changed. It is separate from the Skeptic page (/skeptic), which lists where your own records contradict each other and is included on every tier. See Skeptic.

Tier

The subscription plan level that determines the features, user seat limit, and support level available to a CMDash tenant. CMDash offers four tiers: Starter ($149/mo, up to 5 user seats), Essentials ($499/mo, up to 25 user seats), Command ($1,499/mo, unlimited user seats), and Enterprise (custom pricing, unlimited user seats with custom SLAs, dedicated CSM, and all advanced features). See the pricing and entitlement matrix — generated from tier-map.ts, the file the API enforces — for the canonical, up-to-date figures. Tier can be viewed and changed under Settings → Billing.

TLS-RPT (SMTP TLS Reporting)

A DNS TXT record that tells other mail servers where to send daily reports about TLS connection failures when delivering mail to a domain, giving the domain owner visibility into delivery problems — including attempted downgrade attacks — that would otherwise be invisible. CMDash's Domain Posture module's mail.tls-rpt check reports whether the record is present.

TPRM (Third-Party Risk Management)

The practice of identifying, assessing, and managing cybersecurity risks introduced by vendors, suppliers, contractors, and other third parties that have access to your systems, data, or operations. In CMDash, TPRM is supported through the Risk Register (where third-party risks can be tracked alongside internal risks), the Coalition cyber insurance integration (which provides vendor risk scoring), and evidence collection workflows for vendor security questionnaires and certifications.

Transparency Log

An append-only Merkle-tree log of the proof receipts a deployment issues. It proves a receipt was published and where it sits in the order of publication; consistency proofs between signed checkpoints show that nothing the log signed earlier was changed or removed. It does not reveal what a receipt says. See Transparency log.

V

vCISO (Virtual CISO)

A fractional or outsourced Chief Information Security Officer who provides CISO-level security leadership and program management to organizations on a part-time or contract basis, typically serving multiple client organizations simultaneously. CMDash supports vCISO practitioners through the vCISO Console — available on Command and Enterprise plans — which provides a single login with a client-switcher, a consolidated multi-client posture overview, and the ability to generate white-labeled board reports for each individual client. Each client maintains their own separate CMDash tenant; the vCISO console aggregates across them.

Viewer (role)

The read-only role in CMDash. Viewers can view the dashboard, Posture Score, Compliance framework status and Risk Register entries, and download reports and exports that an Owner or Admin has already generated. They cannot make changes: they cannot edit risks, manage integrations, invite users, upload evidence, add comments or notes, generate a new export or report, use the AI assistant (Ask, AI explanations, AI summaries), or access Settings. A Viewer can still do things that concern only themselves, such as attesting to a policy, completing their own training, or signing off on an exercise they took part in. The Viewer role suits board members, executives and other stakeholders who need visibility into security posture. For an external auditor, use an Assessor Grant instead (Settings → Security & Access → External Assessors).

White-Label

A capability available on the Command and Enterprise plans that allows vCISO practitioners and managed security service providers to present CMDash-generated reports and dashboards under their own brand identity — replacing CMDash's name and logo with the practitioner's or client's branding. White-label configuration is done under Settings → Branding and applies to board report PDFs, PowerPoint exports, scheduled report emails, and (optionally) the application URL if a custom domain is configured.

Y

Your Control

The relationship diagrams' label for what the rest of this glossary calls a Tenant Control — your organization's own implemented safeguard, as distinct from a Framework Line, the catalogue requirement it satisfies. See Tenant Control, above, for the full definition.

For terms not defined here, consult the CMDash documentation portal or contact support@cmdash.com.