We can distinguish two types of auditing in product development projects. Process auditing looks into the project to find evidence that the (agreed) processes have been followed. Data auditing looks into the project and product data to find evidence that the data is correct. In which category falls configuration auditing?
The configuration management activities follow a process. Compliance to the agreed CM processes can be audited. According to CMMI, the process quality assurance is a PPQA responsibility.
Configuration management controls configurations, which involves aspects like storage, distribution and retrieval, status and promotions, traceability of changes, visibility of dependencies, etcetera. Compliance to the agreed CM definitions (storage locations, distribution databases, data reference links and other metadata) can also be audited by CM. But if non-compliances are the result of process deviations, it may be more effective to audit the process (by PPQA).
And finally, the correct content of configurations must be assured. This can be audited, which is usually called a baseline audit. According to the NASA, a “baseline audit verifies that a configuration item, or a collection of configuration items that make up a baseline, conforms to the documentation that describes it” and should be done by CM. However it is part of product quality assurance and therefore the auditing should be the responsibility of PPQA.
How much does that leave for CM audit? Not much!
Therefore, there is no good reason to consider auditing a primary element of CM. Of course, CM people may and often will assist PPQA people with executing the audits, in particular to find evidence (e.g. configuration records and configuration items). In this respect I agree with Anne Mette Hass in her book Configuration Management Principles and Practices that auditing is not part of CM.