Skip to main content
CMDashCybersecurity Maturity Dashboard
DocsUser guideTypical workflows

Typical workflows

The previous page showed how CMDash's record types relate. This one follows those relationships through a day's work — getting a workspace started, running the compliance loop, and the path each of exceptions, risks, policies, vendors, audits, CMMC/SPRS and incidents take from open to closed.

Getting started

Diagram: getting started
Diagram: getting started
What moves it forwardWhoWhere in the app
Choose your roleThe person setting up the workspaceThe onboarding wizard
Select your frameworksSame person, pre-filled from the roleThe onboarding wizard
Complete the readiness checkSame personThe onboarding wizard
Invite your team (skippable)Owner or AdminThe onboarding wizard, or Members later
Get your data inSame personThe onboarding wizard, or Connections later

The wizard runs once, after sign-up; every step but the role question can be revisited later from its own place in the sidebar. Landing on the dashboard starts a Getting Started checklist of six first milestones (a control assessment, an integration, a published policy, a teammate, a report, a piece of evidence), which disappears once every one is checked off.

The compliance loop

Diagram: the compliance loop
Diagram: the compliance loop
What moves it forwardWhoWhere in the app
Enable a frameworkOwner or AdminFrameworks
Assess a lineWhoever owns that controlFrameworks
Quick note or attach evidenceSame personFrameworks, or Evidence
Set its statusSame personFrameworks
Check audit readinessGRC leadAudit Readiness
Export the resultGRC lead, or whoever presents itExports

This is the loop a GRC lead runs most days. A quick note typed on a line becomes evidence the moment you press Add note — there is no separate "evidence" step — and one piece of evidence can attach to more than one line or control. Audit Readiness is a periodic check across everything you've enabled, not a step in every line's own path.

Evidence lifecycle

Diagram: evidence lifecycle
Diagram: evidence lifecycle
What moves it forwardWhoWhere in the app
Pending → CollectedWhoever attaches the artifactEvidence
Collected → ReviewedA reviewerEvidence
Reviewed → Approved / RejectedA reviewerEvidence
Rejected → CollectedWhoever re-attaches itEvidence

Fresh or stale is not one of these statuses — it is worked out on every read, from the collection date and a validity window, so it can never be wrong just because a scheduled check didn't run. When a slot goes stale, CMDash opens a renewal task for its owner automatically, and that task closes itself the moment new evidence lands.

Risk lifecycle

Diagram: risk lifecycle
Diagram: risk lifecycle
What moves it forwardWhoWhere in the app
Open → In progressThe risk ownerRisk Register
In progress → MitigatedThe risk ownerRisk Register
In progress → AcceptedAn approved exceptionRisk Register, via Exceptions
Mitigated / Accepted → ClosedThe risk ownerRisk Register

A risk can also open itself: a dropping vendor monitoring score, a rejected questionnaire, an overdue known-exploited-vulnerability match, or a missed POA&M milestone can each raise one automatically. Whichever way it opened, it's worked the same way from there.

Exception lifecycle

Diagram: exception lifecycle
Diagram: exception lifecycle
What moves it forwardWhoWhere in the app
Draft → Pending approvalThe requesterExceptions
Pending approval → ActiveAn approver (never the requester)Exceptions
Active → ExpiredAutomatic, on the expiry dateExceptions
Active / Pending / Draft → RevokedOwner or AdminExceptions
Expired → ActiveWhoever renews itExceptions
Active / Expired / Revoked → ClosedOwner or AdminExceptions

An exception formally accepts a risk instead of remediating it, so the approver identity check matters: whoever signs off can never be the same person who asked. Renewing an expired exception is only allowed while its compensating control still has current evidence — an exception cannot quietly outlive the safeguard it depends on.

Policy lifecycle

Diagram: policy lifecycle
Diagram: policy lifecycle
What moves it forwardWhoWhere in the app
Draft → In review, or straight to ActiveThe author, via PublishPolicies
In review → ActiveReviewer quorum, via ApproveApprovals
In review → DraftA single RejectApprovals
Active → RetiredOwner or AdminPolicies

Whether publishing goes straight to Active or stops at In review depends on a workspace setting — approval is opt-in, not a permanent step for everyone. A single rejection is a full stop: the policy returns to Draft at once, even if other reviewers haven't decided. While a policy is Active, a separate attestation campaign can ask named people to confirm they've read it, without changing the policy's own status.

Vendor review

Diagram: vendor questionnaire lifecycle
Diagram: vendor questionnaire lifecycle
Diagram: vendor status
Diagram: vendor status
What moves it forwardWhoWhere in the app
Draft → In progressThe vendor's respondentVendors (TPRM)
In progress → SubmittedThe respondentVendors (TPRM)
Submitted → Accepted / RejectedYour reviewerVendors (TPRM)
Rejected → In progress / DraftThe respondentVendors (TPRM)

A questionnaire is one of two machines running for a vendor: the relationship itself moves separately, from Onboarding through Active, Under review and Offboarding to Retired. Accepted is final for a questionnaire — a re-assessment is a fresh one, never a re-opened one, the way an auditor expects a signed attestation to stay put. Independently of any questionnaire's outcome, a dropping monitoring score or an overdue known-exploited-vulnerability match can raise a risk on its own.

Audit engagement

Diagram: audit engagement lifecycle
Diagram: audit engagement lifecycle
Diagram: PBC request lifecycle
Diagram: PBC request lifecycle
What moves it forwardWhoWhere in the app
Planned → FieldworkThe assessorSettings → Assessors
Fieldwork → ReportingThe assessorSettings → Assessors
Reporting → FieldworkThe assessor, on a new findingSettings → Assessors
Reporting → CompleteThe assessorSettings → Assessors
Planned / Fieldwork / Reporting → CancelledOwner or AdminSettings → Assessors

Alongside the engagement, a provided-by-client (PBC) request loop runs during fieldwork: the assessor asks for something specific, you submit evidence, and the assessor accepts it, sends it back, or waives it if it's no longer needed. A firm returning for a second year gets a new engagement under the same standing grant, not a reopened one.

CMMC and SPRS

Diagram: CMMC and SPRS
Diagram: CMMC and SPRS
Diagram: POA&M item lifecycle
Diagram: POA&M item lifecycle
What moves it forwardWhoWhere in the app
Set your CMMC levelOwner or AdminSecurity Program → CMMC Level
Assess your practicesThe practice ownersFrameworks
Track gaps on the POA&MThe item ownersPOA&M
Score and submit to SPRSOwner or AdminSPRS
Sign the annual affirmationThe Affirming OfficialSecurity Program → CMMC Affirmations

Every open practice becomes its own POA&M item, and closing one requires real closure evidence — self-reporting "done" moves an item to Pending verification, not to Completed, since an assessor treats the two differently. A SPRS submission attempt is recorded as Prepared, then Submitted or Failed, and CMDash flags any historical score computed under an earlier weight table so it can be recomputed.

Incident response

Diagram: incident response
Diagram: incident response
What moves it forwardWhoWhere in the app
Open → ContainedThe responderIncidents
Contained → MonitoringThe responderIncidents
Monitoring → ContainedAutomatic, if it recursIncidents
Monitoring / Contained → ClosedThe responderIncidents

Action items — ordinary remediation tasks pointed at the incident — open as findings surface, and are tracked the way any other remediation task is, with the same due dates and the same one list of what's overdue. A postmortem documenting the timeline and root cause is written once the incident is closed, and stands as an evidence artifact in its own right.

Who does what

CISOGRC leadMSP / vCISODefense contractorAssessor
Getting startedSets it upSets it upSets it up per clientSets it up—
The compliance loopReviews the scoreRuns it dailyRuns it per clientRuns itReads it
Evidence lifecycle—Reviews itReviews it per clientReviews itSamples it
Risk lifecycleOwns the registerWorks individual risksWorks it per clientWorks it—
Exception lifecycleApprovesRequestsRequests or approvesRequestsReads it
Policy lifecycleApprovesAuthorsAuthors per clientAuthorsReads it
Vendor reviewReviews rollupsRuns questionnairesRuns it per clientRuns it—
Audit engagementSponsors itCoordinates itCoordinates per clientCoordinates itRuns it
CMMC and SPRS—Assesses practicesCoordinates per clientOwns it end to endAssesses against it
Incident responseOwns the responseSupports itOwns it per clientOwns it—

This page is the product manual, published from the repository at docs/user/guide/workflows.md. Customers read the same text inside CMDash under Help. Last updated September 14, 2026.

Typical workflows — CMDash Docs