This post explains how to design logging and reporting practices that are "evidence-friendly" — meaning logs are captured, preserved, and presented in a way that directly supports FAR 52.204-21 and CMMC 2.0 Level 1 evidence requirements (Control SI.L1-B.1.XII) for small contractors handling covered information.
Understanding the requirement and its intent
At Level 1, CMMC and FAR basic safeguarding expect you to be able to show that you capture relevant activity and can present that activity as evidence of controls working — for example, authentication events, access to covered information, and configuration changes. The practical goal is reproducibility: an auditor should be able to re-run a query or examine an artifact and see the same raw data that supports your conclusions.
What makes a log "evidence-friendly"?
Evidence-friendly logs are consistent (structured fields), time-synchronized (UTC timestamps), protected (write-restricted and hashed or versioned), and accompanied by reproducible queries and a manifest that binds the exported artifacts to your system state (e.g., configuration screenshots, SIEM search strings, and export hashes). For small businesses this means turning ad-hoc log files into a repeatable, auditable package.
Practical implementation steps for a Compliance Framework
Step 1 — Inventory and source selection: list all sources that touch covered data: endpoints (Windows Event Log), servers, firewalls, VPNs, cloud services (Azure AD, Office 365, AWS CloudTrail), and application logs. For each source note the owner, what events are required (logon/logoff, privilege use, file access), where logs are stored, and who can access them.
Step 2 — Standardize logging and timestamps
Configure logs to emit structured events (JSON where possible) and use ISO 8601 timestamps in UTC. On Windows enable relevant audit policies (examples: Logon events 4624/4625, Account Management 4720/4726, Process Creation 4688 if available). On Linux use auditd rules for critical file reads/writes (example rule:
-w /opt/cui -p rwxa -k cui-watchStep 3 — Centralize, protect, and retain
Forward logs to a central collection point (SIEM or secure log server). On small budgets this can be a hosted SIEM or a secured VM with syslog-ng + elastic stack. Protect logs by: restricting write/delete permissions to a small admin role, enabling object immutability (AWS S3 ObjectLock or Azure Blob immutable storage) where possible, and applying cryptographic hashes on exported bundles (SHA-256). Recommended retention: keep raw logs for at least 90 days locally and aggregated/archived copies for 1 year when feasible — document your retention policy in your Compliance Framework policies.
Step 4 — Make reports reproducible and auditable
Create templated report packages for common audit requests: raw log export (prefer compressed text/JSON), parsed CSV summary, the exact SIEM query or grep/awk command used to generate summaries, a configuration snapshot (screenshots or export of logging configuration), and a manifest that lists files + SHA-256 hashes. Example Splunk search you can save and export:
index=security (EventCode=4624 OR EventCode=4625) | stats count by AccountName, EventCode, hosttar czf evidence-2026-03-27.tgz raw-logs/ summary.csv config-screenshots/; sha256sum evidence-2026-03-27.tgz > evidence-2026-03-27.tgz.sha256Real-world small business scenarios
Scenario A — 20-person subcontractor using Microsoft 365: Enable Unified Audit Logging in Microsoft 365, configure Azure AD sign-in logs to stream to a secure Log Analytics workspace, and schedule a weekly export that includes the Azure AD diagnostic settings JSON, a CSV of sign-in failures, and a screenshot of the Azure AD diagnostic settings page. Package with a manifest and hash before submission.
Scenario B — Small MSP with on-prem VMware and perimeter firewall: Forward ESXi host logs and vCenter events to a central syslog server; configure your firewall to push to the same collector (use TLS syslog if supported). When an auditor asks for evidence of access to a server, provide the raw syslog entries, a parsed table showing timestamps, source IPs, usernames, the saved syslog query used, and the hash-signed package.
Compliance tips, best practices, and the risk of not implementing
Tips: automate evidence collection (scheduled exports + hashing), document your retention and hashing procedures in the Compliance Framework policy, use least privilege on log access, and snapshot configurations after changes. Best practices include always keeping raw logs (not only summaries), storing a copy of exported evidence off-site, and using immutable storage for archived logs. The risk of failing to implement: inability to prove control operation, failed contract audits, potential loss of contracts, undetected breaches, and longer incident investigation times due to missing or inconsistent records.
In summary, building evidence-friendly logs and reports is about repeatability, protection, and documentation: standardize your event sources and timestamps, centralize and protect raw logs, create reproducible queries and manifest-signed export packages, and document the whole process in your Compliance Framework. For small businesses this is achievable with careful configuration, templated reporting, and a small set of automated exports and hashes that demonstrably tie your evidence to the live environment.
