CA/DCRs
Detailed Controls Reports (DCR) Guidance
Introduction
Detailed Controls Reports (DCRs) supplement, but do not replace, the annual audit reports required by the Mozilla Root Store Policy (MRSP).
Traditional WebTrust and ETSI audit reports provide valuable assurance that applicable audit criteria have been satisfied. However, they generally provide only limited visibility into the specific controls, testing procedures, system boundaries, and operational practices that support those conclusions.
The purpose of a DCR is to provide additional transparency regarding the design, implementation, testing, and operating effectiveness of controls that support compliance with the CA/Browser Forum's TLS Baseline Requirements and the Network and Certificate System Security Requirements.
Mozilla expects that DCRs will:
- Improve transparency into CA operations.
- Strengthen governance and accountability within CA organizations.
- Assist CA management in understanding critical compliance controls.
- Provide auditors with a structured way to communicate how compliance was evaluated.
- Provide Mozilla with greater visibility into the operation of important security and compliance controls.
Nothing on this page modifies the Mozilla Root Store Policy. This page provides guidance intended to help CA operators and auditors prepare DCRs that satisfy the policy requirements.
Applicability
Detailed Controls Reports are required only for CA operators that have one or more root certificates included in Mozilla's Root Store with the Websites trust bit enabled.
Beginning with audit periods that start on or after July 1, 2027, each applicable CA operator MUST obtain one DCR for each annual audit period.
The DCR requirement is in addition to existing audit reports required by the Mozilla Root Store Policy.
Purpose
The purpose of the DCR is to provide readers with a better understanding of how compliance is achieved in practice.
Rather than simply stating that controls exist, the DCR should explain:
- what systems perform important functions;
- what controls have been implemented;
- how those controls operate;
- how the auditor tested those controls;
- what evidence was examined; and
- whether any control deficiencies or exceptions were identified.
The DCR is intended to improve understanding of the CA's operational control environment rather than create another compliance checklist.
Intended Audience
A DCR may be useful to a variety of audiences, including:
- Executive management, including officers and directors
- Compliance officers
- Security management
- Operational management
- Internal auditors
- External auditors
- Mozilla and other root store operators (when provided by the CA)
Different readers will have different objectives, but all should be able to understand how important compliance controls function throughout the certificate lifecycle.
Recommended Organization
Mozilla does not prescribe a specific report format.
However, a DCR will generally be easier to understand if it contains sections similar to the following:
- Executive Summary
- Scope
- CA System Description
- Applicable Criteria / Requirements
- Control Descriptions
- Auditor Testing Procedures
- Testing Results
- Exceptions and Deficiencies
- Auditor Opinion
- Appendices
Equivalent structures are acceptable.
Executive Summary
An Executive Summary should briefly describe:
- the audit period;
- the CA systems covered;
- the applicable audit criteria;
- the overall conclusion reached by the auditor; and
- any significant observations.
This section should allow executive management to understand the overall results without reading the entire report.
Scope
The report should clearly describe what was included within the scope of the auditor engagement.
Examples include:
- CA systems
- Certificate lifecycle activities
- Shared infrastructure
- Outsourced services
- Trusted roles
- Physical facilities (where relevant)
The report should also describe significant exclusions, if any.
CA System Description
The DCR should provide a high-level description of the systems involved in certificate lifecycle operations.
Readers should be able to understand:
- the major systems;
- the purpose of each system;
- how systems interact; and
- where important controls operate.
Examples of certificate lifecycle activities include:
Certificate Request
- Submission of requests
- CSR processing
- ACME interfaces
- APIs
Validation
- Domain validation
- Organization validation
- CAA checking
- Multi-Perspective Issuance Corroboration (MPIC)
Issuance
- Approval workflows
- Certificate generation
- Signing systems
- Certificate Transparency submission
Delivery
- Certificate publication
- Subscriber notification
- Logging
Revocation
- Certificate Problem Report handling
- Reason Code Selection and Revocation
- CRL generation
- OCSP response provisioning
This section does not need to disclose sensitive infrastructure details such as IP addresses, firewall rules, VLANs, router configurations, switch topology, individual server names, or similar implementation details.
Applicable Audit Criteria
The DCR should identify the criteria used during the engagement.
This will typically include:
- CA/Browser Forum TLS Baseline Requirements
- Network and Certificate System Security Requirements
- Relevant WebTrust or ETSI criteria
- Internal policies and CP/CPS Documentation where appropriate
Many organizations may find it useful to map individual requirements to specific controls.
Control Descriptions
Each significant control should be described sufficiently for readers to understand:
- the control objective;
- the associated risk;
- how the control operates;
- whether it is preventive or detective;
- whether it is automated or manual;
- how frequently it operates;
- who performs or owns the control; and
- what evidence the control produces.
Control descriptions should focus on how compliance is achieved rather than reproducing policy language.
Auditor Testing Procedures
The DCR should describe how controls were evaluated.
Examples include:
- inspection;
- observation;
- inquiry;
- reperformance;
- sampling;
- automated testing;
- examination of system evidence.
The report should describe the nature of testing performed without prescribing any particular audit methodology.
Mozilla does not require auditors to use specific testing techniques.
Testing Results
Testing results should summarize:
- controls tested;
- testing performed;
- results obtained;
- whether controls operated effectively;
- identified deficiencies; and
- any compensating controls considered by the auditor.
Where exceptions exist, sufficient information should be provided for readers to understand their significance.
Exceptions and Deficiencies
The report should describe significant control deficiencies identified during the engagement.
Where appropriate, the report may also describe:
- management responses;
- remediation plans;
- corrective actions;
- compensating controls; or
- subsequent improvements.
Minor observations that do not affect the auditor's conclusion may also be included where helpful.
Auditor Opinion
The report should conclude with the auditor's opinion or conclusion, consistent with the reporting framework used.
Mozilla does not prescribe a particular reporting standard or opinion format.
Control Matrix Guidance
Many organizations may find it useful to maintain a control matrix that maps applicable requirements to implemented controls.
Some columns that might appear in a control matrix are:
- Requirement
- Risk
- Control Identifier
- Control Description
- Control Owner
- Frequency
- Evidence Produced
- Auditor Testing
- Test Results
Mozilla expects to publish examples of controls separately.
Level of Detail
The DCR should provide sufficient information for knowledgeable readers to understand how controls operate without unnecessarily disclosing sensitive security information.
For example, readers should understand:
- what systems perform important functions;
- where controls operate;
- how those controls are tested; and
- what evidence supports the auditor's conclusions.
The report ordinarily should not disclose information such as:
- passwords;
- cryptographic key material;
- firewall configurations;
- IP addressing;
- switch configurations;
- penetration test reports;
- source code; or
- other information that would materially increase operational security risk.
Auditor Judgment
Mozilla recognizes that auditors exercise professional judgment when planning and performing engagements.
Accordingly, Mozilla does not prescribe:
- audit methodology;
- sampling methods;
- testing procedures;
- report formatting;
- report length; or
- terminology.
Equivalent approaches are acceptable provided the report satisfies the requirements of MRSP section 3.1.5.
Sensitive Information
Mozilla recognizes that DCRs may contain sensitive operational or security information.
Limited redactions may be appropriate where disclosure would materially increase risk to CA systems.
Any redactions should be narrowly tailored and should not prevent readers from understanding how important controls operate or how the auditor reached the reported conclusions.
Frequently Asked Questions
Additional implementation guidance is available in a Frequently Asked Questions document.
Future topics to be addressed in the FAQ include:
- Existing Detailed Controls Reports
- Report Frameworks
- Redactions
- Intended Users
- Auditor Responsibilities
- Combining Reports
- Shared Infrastructure
- Mozilla Review Process
Examples and Templates
Mozilla expects to publish additional implementation resources, including:
- DCR White Paper
- Frequently Asked Questions
- Example Controls
Conclusion
In conclusion, these resources only illustrate some acceptable approaches and should not be interpreted as mandatory report formats.