>>>> For example, in all our audits for other standards, no “audit >>>> period” is clearly documented in the report; time since previous >>>> audit is always implied. >>> >>> Again, I don't believe that it is reasonable to assume that >>> auditing/sampling has been done over the full year. >>> >> >> [NS]: No assumptions are made. This is common practice and common >> understanding. > > >Sigh. If it were so well understood then I would think CAs and auditors >would be providing better answers regarding whether their audits are >point-in-time or full audits, and what the audit period start and end dates >are.
In the ETSI audits I've been participating (and also in nearly all other audits, be it ISO 27001 or ISO 9001) the auditor was differentiating between a Test of Design (ToD) and Test of Effectiveness (ToE) for every control. For the ToD the auditor looks at the very moment of the audit into the processes or technical methods that are in place to fulfill the requirements of the specific control. He assesses if those methods or processes seem to be sound and reasonable by his professional experience or other standards. For the ToE the auditor takes evidence from the audit period in the past to check, first, if the auditee always followed the methods or processes checked in the ToD and, second, if the methods and processes really worked to fulfill the goal of the control. Failures in the tests are documented in the audit report. The certificate is only issued if there were no significant deviations found. My question to the WebTrust community would be, if the WebTrust auditors work significantly different? And if yes, what are the differences? >Sorry if I'm being slow here, but how do we get the ETSI audits and audit >statements fixed ASAP? Microsoft has published a form (http://aka.ms/rootcertapply) that needs to be filled in after every audit by the auditor with all additional information required by Microsoft beyond the normal audit certificate. This form is collected by Microsoft from the Root CAs and by the Root CA from their Issuing CAs. Maybe introducing such a form for Mozilla as well could be a low hanging fruit to increase audit documentation quality. Further more you could publish the names of the auditors or the auditing companies that fail to comply with your requirements. If there is a cluster of auditors / companies that often fail to comply those would practically be disqualified for further audits since nobody with a straight mind would hire such an auditor / audit company again. With best regards, Rufus Buschart Siemens AG Information Technology Human Resources PKI / Trustcenter GS IT HR 7 4 Hugo-Junkers-Str. 9 90411 Nuernberg, Germany Tel.: +49 1522 2894134 mailto:rufus.busch...@siemens.com www.siemens.com/ingenuityforlife _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
