Evidence Collection & Audit Packages

Evidence Collection: Command and above | Audit Evidence Packages: Enterprise

What is Automated Evidence Collection?

Audit preparation is traditionally one of the most labor-intensive parts of a compliance program. Security teams spend weeks pulling screenshots, exporting logs, gathering policy documents, and mapping them to control requirements — often under time pressure with an auditor waiting.

CMDash eliminates most of that work. When you connect your security and IT integrations, CMDash continuously syncs data from those tools and automatically maps it to the relevant compliance control requirements across your active frameworks. Your evidence library is maintained in real time, so when audit season arrives, the bulk of the evidence is already collected, timestamped, and organized.

How Automated Evidence Collection Works

The Collection Pipeline

1. Connect integrations: Link your tools — CrowdStrike, Tenable, Okta, Microsoft 365, AWS Security Hub, and others — in Settings → Integrations
2. CMDash syncs: Each integration is polled every 15 minutes. Data points are ingested: endpoint coverage percentages, vulnerability counts, MFA adoption rates, patch compliance status, user access reviews, and more
3. Automatic mapping: For each data point, CMDash maps it to the relevant controls across your active frameworks. A single data point often maps to multiple controls across multiple frameworks. For example, "MFA enabled for 247 of 251 users in Okta" maps to CMMC IA.L2-3.5.3, SOC 2 CC6.1, NIST CSF PR.AC-7, and ISO 27001 A.9.4.2
4. Evidence appears on the line: any framework line's "N evidence" chip counts it, and opening the chip or the line's own record shows the linked evidence, the source integration, the specific data point, and the timestamp of the most recent sync

What Counts as Evidence

CMDash collects several types of evidence from integrations:

• Configuration state: MFA enabled, SSO enforced, encryption at rest active
• Coverage metrics: percentage of endpoints with EDR agent, percentage of users with access review completed
• Scan results: vulnerability counts by severity, last scan date, unpatched critical findings
• Policy enforcement: password policy settings, session timeout configurations, privileged access controls
• Audit logs: connection to your SIEM or logging platform confirming log retention meets control requirements

Viewing Evidence on a Control

1. Go to Compliance
2. Select a framework (e.g., CMMC, SOC 2, NIST CSF)
3. Select a domain to expand it
4. On the line you want, click the "N evidence" chip to open a popover of what's linked, or click the line's code to open its full record

Either way you land on the evidence item's own record, which shows:

• Source: which integration provided the data (e.g., Okta, CrowdStrike), when the evidence is integration-sourced
• Kind and status: Text, Document, Recording, Link, or an automated kind; Pending, Collected, Reviewed, Approved or Rejected
• Timestamp: when this data was last synced (Collected) and, once reviewed, when
• Sync status: Current (synced within the last 6 hours) or Stale (last sync was more than 6 hours ago)

Stale evidence is flagged in red. If you see stale evidence, go to Settings → Integrations, find the affected integration, and check its Last Synced timestamp and error state. Resolve the connection issue before generating an audit package.

Manual Evidence

Available on: Command and above

Not every control can be satisfied by integration data alone. Process controls, policy approvals, training completion records, vendor assessments, and penetration test reports require manual evidence upload.

Adding Manual Evidence

1. Open Add evidence from a framework line's "N evidence" chip (+ Add, which also links the new item to that line automatically), from the Evidence Vault's Add evidence button, or from an evidence request
2. Choose how it arrives:
   • Upload a file: PDF, image, document or log file, up to 25MB
   • Paste text: written description of how the control is met — for a process rather than a document, and the same kind a quick note on a line creates
   • Link to it: an external document, policy portal, or tool that should stay where it lives
3. Add a title and, for a file or link, a description explaining what it demonstrates
4. Click Add evidence

A quick note on a framework line is the fastest version of this for a fact you can just state — see Adding a Quick Note in the Compliance Frameworks guide.

Versioning

All manual evidence is versioned. When you upload a new version of a file, the previous version is retained and accessible. This is important for auditors who need to verify controls were met during a specific period — they can see the policy document that was in force at the time of the audit, not just the current version.

Evidence Review Workflow

Reviewed evidence carries more weight in audit packages because it confirms a qualified person has verified the evidence — not just that it was uploaded or automatically collected.

To review an evidence item:

1. Open its record — from a line's evidence chip, the Evidence Vault, or a search result
2. In the sidebar, change Status to Reviewed (or Approved / Rejected, once a decision is made)
3. Optionally add Reviewer notes in the sidebar and click Save notes (e.g., "Confirmed with IT team that exception for service account is documented and approved") — this is one shared field, not a per-reviewer history, but it only changes on an explicit save, never silently while someone is typing
4. The status change is recorded with your name and timestamp in the record's activity history

Reviewed status is visible in audit packages and in the evidence manifest.

Audit Evidence Package

Available on: Command

An Audit Evidence Package is a ZIP archive containing all control evidence for a selected framework, packaged for auditor handoff. Instead of emailing files back and forth or granting auditors temporary system access, you generate a single structured package that contains everything they need.

What's in the Package

• JSON manifest: lists every control in the framework, the evidence mapped to it, the source (integration or manual), the timestamp, and the review status. The manifest follows a standard schema that auditors can import into their own GRC tools
• Attached files: all manually uploaded files (PDFs, reports, policy documents, screenshots)
• Integration data snapshots: point-in-time exports of the integration data that satisfies each control

Generating an Audit Package

1. Go to Evidence → Packages → Create Package
2. Select the framework (CMMC, SOC 2 Type II, NIST CSF, ISO 27001, etc.)
3. Set the date range (the period your audit covers)
4. Click Generate
5. Download the ZIP when ready (generation takes 1–3 minutes for large frameworks)

Typical Use Cases

Evidence Freshness and Staleness

Evidence quality depends on how current it is. CMDash uses a 6-hour threshold:

• Current: integration synced within the last 6 hours — evidence is treated as live
• Stale: last sync was more than 6 hours ago — evidence is flagged in red

Before generating an audit package, verify that all integrations are healthy:

1. Go to Settings → Integrations
2. Check the Last Synced column for each integration
3. Resolve any integrations showing errors or stale sync times
4. Wait for a successful sync cycle before generating the package

Stale evidence included in an audit package will be noted in the manifest — auditors will see it and may ask questions. Always generate packages from a healthy, fully synced baseline.

The Evidence Freshness page

The 6-hour integration-sync check above is one input; the Evidence Freshness page is the broader, per-artifact view — every evidence artifact's own validity window (a screenshot and an annually-reviewed policy don't age the same way), computed live from the artifact's age rather than a stored flag, with a daily sweep that opens a renewal task and notifies the control owner once evidence crosses its window. It is a tab on Evidence, not its own sidebar row: Compliance → Evidence → Freshness.

Evidence Propagation (Crosswalk)

Available on: Command and above

Most organizations run multiple compliance frameworks simultaneously — CMMC and NIST CSF, or SOC 2 and ISO 27001. Many controls overlap across frameworks. CMDash's crosswalk engine detects these overlaps and can propagate one piece of evidence to every crosswalked line it also satisfies.

How it works:

On an evidence record with crosswalked lines available, click Propagate. A preview lists the crosswalked lines above your workspace's confidence threshold (80% by default) with each one's confidence score; confirm to link the SAME evidence artifact to each of them — propagation adds a link, it does not create a copy. The artifact you started from still shows one record, with its "N evidence" chip on every crosswalked line now counting it and its own record's Links field showing every line and control it reaches.

Manual evidence always takes precedence. If a target line already has evidence you uploaded or wrote a note for, propagating another artifact onto it adds a second link rather than replacing what's there — nothing is silently overwritten.

A note on confidence scores: a high-confidence propagation (90%+) means the controls are essentially identical in requirement. A lower-confidence propagation (60–80%) means the controls are related but not identical — review these manually to confirm the evidence actually satisfies the target control's specific language before including in an audit package. Anything below your configured threshold does not appear in the preview at all.

Best Practices

Connect integrations at least 30 days before your audit. Evidence timestamps matter. Auditors performing a Type II audit (which covers a period of time, not just a point in time) need to see evidence that spans the audit period. Integrations connected the week before the audit will have insufficient historical data.

Review evidence completeness weekly. Go to Compliance → [Framework] → Completion % per domain to see which control domains have gaps. Address coverage gaps in advance, not during audit prep.

Write narrative text for process controls. For controls that describe a process rather than a technical configuration (e.g., "Security awareness training is conducted annually"), integration data rarely suffices. Write a clear narrative: what the process is, who owns it, when it runs, and where the records are kept. Auditors want to understand your program, not just see a data point.

For CMMC: use the POA&M export alongside evidence. Open findings belong in a Plan of Action & Milestones, not hidden: the POA&M register is on every plan, and its export is [Starter+]. Export the POA&M alongside your evidence package to show auditors that open items are tracked, assigned, and on a defined remediation timeline. This demonstrates a mature program even where controls are not yet fully met.

Name manual evidence files clearly. Use a consistent naming convention that includes what the document proves and when it was current. For example: MFA-Policy-Enforced-2026-Q2.pdf, Vulnerability-Scan-Tenable-2026-05-31.pdf, Security-Awareness-Training-Completion-2026-Annual.xlsx. Clear names reduce auditor confusion and back-and-forth.

Verify propagated evidence before including in packages. Review each propagated link — especially the lower-confidence ones the preview showed — before generating an audit package. Confirm the source line's evidence actually satisfies the target line's specific requirement.

Related Features

• Integration setup guides — 44 per-vendor guides under docs/
• Compliance Frameworks
• Risk Register
• Board & Executive Reporting