Configuration Verification and Audit (process ST 3.5)

Verification and auditing is responsible for ensuring that information in Configuration Management is accurate and that all Configuration Items (CIs) are identified and recorded in Configuration Management. The process can be conducted manually, or by using automated inventory and discovery tools.

Verification includes routine checks that are part of other processes (for example, verifying the serial number of a desktop PC when a user logs an incident). Audit is a periodic, formal check. You should verify and audit your configurations regularly to ensure proper functioning of the entire Configuration Management process, and for related IT service management processes.

The objective of verification and auditing for Configuration Management is to detect and manage all exceptions to configuration policies, processes, and procedures, including security and license use rights. The verification process ensures that configuration records are accurate and complete, and that any recorded changes are approved. Configuration audits help to maintain the integrity of the Configuration Management System (CMS).

Also included in the configuration and audit process is the periodic review of installed software against the policy for software usage to identify personal or unlicensed software or any software instances in excess of current license agreements.

Configuration Verification and Audit activities include:

• Make sure that baselines and standards match the actual components in the IT environment
• Verify that services and products are built and documented, according to documented requirements, standards, or contractual agreements
• Verify that the correct and authorized versions of any CI exists and is correctly identified and described
• Verify the physical existence of CIs (for example, in the organization, in the Definitive Media Library, or in stock)
• Check that release documentation and configuration administration are present before making a release
• Confirm that the current environment is as expected and documented in the CMS, and that any Change requests are resolved
• Check that configuration modifications are implemented through authorized changes
• Validate the existence of a SLA against each CI
• Verify that CI specifications are compliant with defined configuration policies and baselines
• Validate that all required documentation for each CI is available (for example, maintenance contracts, license records, or warranties)
• Check data quality for accuracy and completeness
• Initiate an incident for discovered unauthorized changes

The following are examples of discrepancies:

• Unauthorized software installed
• Unauthorized access to resources and services (for example, access rights not reflected in subscriptions)
• Discrepancy of status or configuration details, as registered in the CMS, compared with the actual status.

Configuration Verification and Audit processes, both physical and functional, should be scheduled and a check performed to ensure that adequate processes and resources are in place. Benefits of this process include:

• Protection of the physical configurations and the intellectual capital of the organization
• Verification that the service provider is in control of its configurations, master copies, and licenses
• Confidence that configuration information is accurate, controlled, and visible
• Conformance of changes, releases, systems, and IT environments to contracted or specified requirements.
• Accuracy and completeness of configuration records

Configuration audits should be carried out regularly, before and after a major change (or release), after a disaster, and at random intervals. Deficiencies and nonconformities should be recorded, assessed and corrective action initiated, acted on, and reported back to the relevant parties and plan for improving the service. Unauthorized and unregistered items that are discovered during the audit should be investigated and corrective action taken to address possible issues with procedures and the behavior of personnel. All exceptions are logged and reported as incidents. Details for this process can be seen in the following figure and table.