How to prepare for a compliance audit using your Windows event logs
When an audit is on the calendar, someone has to show that your systems are logging the right events and keeping those logs. Cloud GRC platforms such as Vanta and Drata are built mainly for SaaS companies working toward SOC 2, and they generally don’t collect Windows event logs. Enterprise SIEMs collect logs but usually don’t map them to compliance frameworks. For a hospital, a county sheriff’s office, a school district or a defense subcontractor, much of the audit-logging record sits in Windows event logs, and it helps to have a tool that lines those logs up against the requirements your auditor will ask about.
The options
GRC Platforms
- SOC 2 focused
- SaaS/cloud integrations
- Policy document management
- Don't collect Windows logs
- Don't monitor your servers
Enterprise SIEMs
- Collect and index logs
- Detection rules (if tuned)
- No compliance mapping
- No framework reports
- You build reports and mappings yourself
Arden Comply
- Audit-log coverage for 7 frameworks
- 133 requirements, 56 event categories
- Flags audit-policy logging gaps
- PDF, CSV and JSON export
- Runs on your network
Arden Comply fills the space between the two. It reads your Windows event logs and, for each of 133 requirements across seven frameworks, shows which Windows event categories the requirement depends on and whether those events were observed in the collected logs. It also points out logging gaps in your audit policy and exports reports by framework and requirement as PDF, CSV or JSON.
133 requirements across seven frameworks
Each requirement maps to specific Windows event categories. There are 56 in total, covering logon activity, account lifecycle, privilege use, group membership changes, scheduled tasks and policy modifications. When Arden finds a logging gap, for example an audit policy that isn’t recording privilege use events, it suggests the audit policy setting to turn on. Once those events start arriving, the coverage dashboard reflects them.
PDF audit-log coverage reports
Sample HIPAA audit-log coverage report from Arden Comply. For each requirement it shows how many baseline and enriched event categories were observed.
The report lists audit-log coverage for each requirement, which hosts contributed data, and which audit policy changes would close the logging gaps. Instead of telling your auditor that you believe the right things are being logged, you can show what was actually observed, organized by requirement. Whether your organization is compliant is still decided by your auditor or assessor.
Start with your servers
You don’t need agents on every workstation to get started. The events that many audit-logging requirements depend on, such as authentication, account management, privilege use and policy changes, are concentrated on domain controllers, file servers and the systems that handle regulated data. Putting agents on two or three of those servers gives you ongoing audit-log coverage data for many requirements across all seven frameworks, along with a list of where the logging gaps are. That is a manageable starting point even for a one-person IT department at a rural clinic.
Compliance reporting and threat detection work from the same data. The logon events that HIPAA §164.312(b) audit controls rely on are the same events used to detect brute-force attempts. Arden Complete includes both products, so one set of logs feeds the detection alerts and the coverage reports. The SIEM pricing comparison has a fuller cost breakdown.
See your audit-log coverage in Arden Comply
Arden is in invite-only beta. Request an invite to try Arden Comply on your own network.
Request a Beta Invite