Most AD CS compliance work happens once a year: an auditor asks for evidence, someone scrambles to pull screenshots and configuration exports, and the result gets filed until next year’s request. That approach treats compliance as a point-in-time deliverable instead of what it actually should be, an ongoing, evidenced state. This is a reference for mapping specific AD CS technical controls to the specific evidence that proves they’re actually operating, plus the baseline, exception, SLA, and reporting discipline that turns that mapping into a continuous practice.
This builds directly on ADCS Audit Logging Deep Dive and Continuous ADCS Risk Assessment vs One-Time Audits, both of which describe the technical foundation this governance layer depends on.
TL;DR: Key Takeaways
- Every control needs a specific, named evidence artifact, not a general assertion that “we follow best practice,” a control without evidence isn’t auditable, it’s a claim.
- A documented configuration baseline is what makes drift detectable at all, without one, a changed permission or a re-enabled policy flag has nothing to be compared against.
- Specific AD CS events double as compliance evidence, not just security telemetry, the same event IDs covered throughout our series prove that issuance, change, and audit-integrity controls are actually functioning.
- Every open gap needs either a remediation deadline or a formal exception, an unaddressed finding with no plan and no documented risk acceptance is itself a compliance failure.
- Remediation SLAs should scale with severity, not be uniform, and reporting should be built differently for technical teams, leadership, and external auditors, one format rarely serves all three well.
Controls Mapped to Evidence
| Control Domain | Control | Evidence Artifact |
|---|---|---|
| Access Control | Tier 0 administrative separation, least-privilege CA/template permissions | Permission review reports, PAW usage logs, JIT elevation records, ESC1-ESC16 scan results |
| Key Management | HSM-backed keys, ceremony discipline for generation and renewal | Ceremony logs, witness sign-offs, key custody documentation |
| Audit Logging | AuditFilter fully enabled, events reaching centralized storage | AuditFilter configuration export, SIEM ingestion confirmation, Event ID 4885 monitoring history |
| Issuance Controls | Template permissions, manager approval where required, EKU restrictions | Template configuration snapshots, correlated 4886-4889 event history, denial rate reports |
| Revocation and Publication | CRL/OCSP/AIA availability and currency | Publication success logs, synthetic retrieval test results, OCSP signing certificate status |
| Change Management | CA and template configuration changes reviewed and authorized | Change tickets correlated with 4890-4898 events, CAPolicy.inf version history |
| Disaster Recovery | Backup completion and tested restore capability | Backup completion logs, documented DR test results and dates |
| Vulnerability Management | Patch currency against known AD CS CVEs | Patch level confirmation, re-scan results after remediation |
Configuration Baselines
- Document a versioned snapshot of every CA’s templates, registry settings, policy flags, and permissions at a known-good point in time, this is what future comparisons measure against, without it, drift has nothing to be flagged relative to.
- Update the baseline deliberately after every reviewed, authorized change, not automatically after every change, an unreviewed change updating the baseline defeats the purpose of having one.
- Store baseline history, not just the current state, being able to show what changed, when, and why is itself a compliance artifact, particularly useful when an auditor asks how a specific setting evolved over time.
Events as Evidence
- Certificate request lifecycle events (4886, 4887, 4888, 4889) prove issuance controls are functioning, correlated by Request ID, covered in full in our event ID reference, this history demonstrates templates are being enforced and approvals are genuinely happening, not just configured to happen.
- Event 4885 proves audit control integrity specifically, a clean history of no unexpected AuditFilter changes is itself evidence that your logging control hasn’t been quietly weakened.
- The 4890-4898 configuration change range provides your change management evidence, correlated against actual change tickets, a configuration change with no corresponding authorized ticket is a control failure worth flagging on its own.
Exceptions
- Formalize the exception process before you need it, a legacy template that can’t be immediately remediated, an HSM migration that’s mid-flight, a compensating control standing in for a delayed fix, all of these are legitimate situations that need a documented path, not an unaddressed gap.
- Require every exception to include a compensating control, an owner, and an expiration date, an exception with no review date tends to become permanent by default, which defeats its purpose entirely.
- Re-review every open exception on a recurring schedule, treating an exception as a standing decision that gets revisited, not a one-time approval that’s forgotten once granted.
Remediation SLAs
- Scale remediation timelines to severity, using the same prioritization logic from our ESC detection playbook: CA-wide exposures like a dangerous policy flag warrant remediation in days, template-level findings in weeks, and low-severity operational gaps can reasonably wait for a scheduled maintenance window.
- Make every SLA explicit and tracked, not implied, a finding with an informal “we’ll get to it” carries no accountability, an SLA with a tracked due date does.
- Escalate SLA breaches distinctly from new findings, a finding that’s overdue against its own remediation deadline is a different, arguably more urgent signal than a fresh finding still within its window.
Reporting
- Build a granular, technical report for your PKI and security teams, covering specific findings, evidence artifacts, and remediation status in enough detail to actually act on.
- Build a trend-level summary for leadership, covering overall posture direction, open exception counts, and SLA compliance rate, detail leadership needs to make resourcing and risk decisions, not the granular findings themselves.
- Build a formal evidence package for external auditors, mapped explicitly to the specific control requirements they’re assessing against, using the control-to-evidence structure from this guide as your starting template.
- Recognize these are three different documents serving three different purposes, one report attempting to serve all three audiences typically serves none of them well.
How Encryption Consulting Can Help
Turning AD CS technical controls into a genuine, continuous compliance practice, with real evidence, tracked exceptions, and enforced SLAs, is governance work layered on top of the technical monitoring most organizations have already started building.
Encryption Consulting’s PKI Services team supports this directly:
- Control-to-evidence mapping: building this framework specific to your actual compliance obligations and existing telemetry.
- Baseline establishment and drift management: documenting your current known-good configuration and building the recurring comparison process that keeps it meaningful.
- Exception and SLA program design: building the formal process and tracking discipline that turns open findings into managed, accountable work rather than an ignored backlog.
- Audit-ready reporting, building the technical, leadership, and formal evidence packages this guide describes, tailored to your actual compliance framework.
- Ongoing compliance program management, integrated with the continuous risk assessment and threat hunting practices covered throughout our broader AD CS series.
If your AD CS compliance today is an annual scramble rather than a continuous, evidenced state, our PKI Services team can help you build the program that changes that.
Conclusion
AD CS compliance stops being an annual scramble once every control has a named piece of evidence behind it, every configuration has a documented baseline to drift against, every gap has either a remediation deadline or a formal exception, and reporting is built for the audience actually reading it. The technical telemetry covered throughout our broader series is what makes this possible, this guide is the governance structure that turns that telemetry into an actual, continuous compliance practice rather than a pile of logs nobody’s mapped to anything.
Related reading: ADCS Audit Logging Deep Dive · Continuous ADCS Risk Assessment vs One-Time Audits · ADCS ESC1-ESC16 Detection Playbook · ADCS Telemetry Guide: Events, Metrics, Logs, and Alerts · Tier 0 Microsoft ADCS Architecture and Hardening · ADCS Disaster Recovery Backup: What Must Be Included
Is your AD CS compliance an annual scramble instead of a continuous state? Talk to our PKI Services team about building a real compliance monitoring program. Encryption Consulting is ISO/IEC 27001:2022 and SOC 2 certified.
FAQ
What counts as audit evidence for an AD CS access control? Documented CA and template permission reviews, Privileged Access Workstation usage logs, just-in-time elevation records, and the results of a recurring ESC1-ESC16 detection scan. Together these demonstrate the control isn’t just configured correctly today but is actively maintained and verified on a recurring basis.
What is a configuration baseline in the context of AD CS compliance? A documented, versioned snapshot of your CA’s templates, registry settings, policy flags, and permissions at a known-good point in time. Every future configuration review compares against this baseline, so drift shows up as a specific, flagged difference rather than being invisible until someone happens to notice.
Should every AD CS compliance gap be remediated immediately? No, but every gap needs either remediation on a defined timeline or a formal, documented exception. A gap that’s simply left open with no plan and no accepted-risk documentation is a compliance failure in itself, independent of the underlying technical issue.
How should remediation SLAs be set for AD CS findings? Based on severity, not a flat timeline for everything. CA-wide exposures like a dangerous policy flag warrant remediation in days, template-level findings in weeks, and low-severity operational gaps can reasonably wait for a scheduled maintenance window, provided the timeline is explicit and tracked.
Why does compliance reporting need different formats for different audiences? Because a technical team needs granular findings to act on, leadership needs a trend-level summary to make resourcing decisions, and an external auditor needs a formal evidence package mapped to specific control requirements. One report trying to serve all three audiences usually serves none of them well.