C. Audits
INTRODUCTION TO AUDITS
T he ASQ Audit Division (Russell 2013) defines an audit as “a systematic, independent and documented process for obtaining audit evidence and evaluating it objectively to determine the extent to which the audit criteria are fulfilled” IEEE (2008) includes a similar definition of an audit as “an independent examination of a software product, software process, or set of software processes performed by a third party to assess compliance with specifications, standards, contractual agreements, or other criteria.” According to ISO (2015), internal audits are a required part of a quality management system. The Capability Maturity Model Integration (CMMI) for Development includes formal audits as one of the ways to perform objective evaluations in the process and product assurance process area and in the objectively evaluate adherence generic practice. The CMMI for Development also includes the performance of configuration audits as a specific practice in the Configuration Management process area (SEI 2010). The IEEE Standard for Software Reviews and Audits (IEEE 2008) includes the process required for the execution of audits.
Software audits are planned activities—there are no surprise software audits. Software audits are not trying to “catch” anyone at their worst. The people involved in a software audit should be aware of the audit’s scope, objectives, and schedule, as well as their roles and responsibilities during the audit. Audits are conducted by individuals who are independent of the area being audited. This independence helps make sure that an objective evaluation is conducted. Software audits have documented plans and reports. In addition, corrective action plans are documented, as required, for any nonconformances discovered during the audit. Software audits evaluate some aspect of a software system, process, project, product, or supplier and provide management with information from which fact-based decisions can be made. Software audits use a set of agreed-to criteria as the requirements to conduct these evaluations.
Audit Objectives
Software audits should be value-added activities conducted to provide information to management, based on an evaluation of whether the:
Software audits also help identify areas needing improvement and identify best practices within the organization that should be propagated to other areas. In fact, identifying/ propagating best practices is one of the primary objectives of audits in more mature organizations where few or no nonconformances exist.
Audit Program
An overarching internal audit program should be planned as part of an organization’s quality management system to make certain that required audits are performed regularly, and audits of critical functions are performed frequently. The audit program also makes certain that only trained, qualified, and independent auditors perform audits, and that audit processes are standardized and continually improved. Audits within the audit program should be scheduled so that they closely align with the organization’s strategies, stakeholders’ requirements, senior management’s concerns, and organizational risks. Within the audit program schedule, individual audits should be scheduled to minimize the inconvenience for the auditee. For example, an internal audit of a project should not be scheduled to coincide with a major release when everyone on the project is scrambling to take care of the final details. A better time to schedule such an audit might be while that release is in development or after the major release push is over.
Audit Considerations
Audit findings must be based on facts. However, since humans are identifying and interpreting those “facts,” the audit staff must be as independent as possible in order to enhance objectivity. Objectivity is the absence of any bias that will influence the results of the audit. While total independence on the part of an internal auditor is impossible (at some level of the organization everyone reports to the same management), the goal is still to maintain enough independence so that the auditor can objectively evaluate and analyze the evidence, and produce unbiased audit results.
Conducting an audit consumes resources, including money and time. Auditors typically need to be able to spend time with, and talk to, software managers and individual contributors in order to perform an effective audit. This can take time away from the business of developing and maintaining software, which is the primary mission of a software organization. Care should be taken to confirm that the value of the information received from the audit is worth more than the expected cost of the audit. In other words, audits should be value-added activities. This means that the audit information must have a client (customer), someone who is going to use the information to make decisions, even if that decision is “everything is great—no action is necessary.”
An audit may result in one or more findings. This means that more resources will be needed to perform root cause analysis of any identified nonconformance and take corrective action, or to plan and implement improvement actions or the propagation of best practices. Things will improve, but in the meantime more resources will be consumed.
The mere act of conducting an audit establishes expectations in the participants’ minds that management is going to act on the information and make things better. If the findings of the audit are not adequately followed up on, the entire audit process may be perceived as a waste of time and energy. Unless everything is perfect, value-added audits should result in actions and follow-through.
Based on past experience with pure conformance-type audits, people may perceive audits in a negative light as “policing actions.” This may lead to reluctance to cooperate with the audit or suspicions that the audit results will be used against the audit participants. Care should be taken by both the auditors and both the auditor’s and auditee’s management to focus the audits on process and product improvement or systematic issues, and not on individuals.
1. AUDIT TYPES
Define and distinguish between various audit types, including process, compliance, supplier, system. (Understand)
BODY OF KNOWLEDGE II.C.1
Audits are typed either by who conducts the audit (internal versus external audits or first-, second-, and third-party audits) or by what is being audited (systems audits, process audits, product audits, project audits, or supplier audits). There are also specialpurpose audits including follow-up audits and desk audits.
Internal First-Party Audits
An internal audit, also known as a first-party audit, is an audit that an organization performs on itself. As illustrated in Figure 8.1 , in a first-party audit the people conducting the audit (auditors), the people being audited (auditees), and the client (the person or organization that requested the audit) are all members of the same organization. The audit criteria for an internal audit can come from inside the organization (for example, the organization’s quality management system, individual processes, or plans). The audit criteria can also come from outside the organization. For example, the standards or requirements of the organization’s customers, or external industry standards can be used as audit criteria.
For organizations and teams using agile methods, internal audits may continue to be used based on the risk-levels, requirements imposed by industry standards (like ISO 9001, or its industry specific counterparts like NQA-1, AS 9100 and so on), regulatory requirements, or contractual obligations. “Agile or not, a team ultimately has to meet legal and essential organizational needs, and audits help to ensure this” (Ambler 2012). However, in lower-risk industries with less rigorous requirements, agile teams may substitute self-monitoring through review, retrospectives, and/or reflections to fulfill the software quality assurance objectives of some, or many, of their internal audits.
In some cases, an organization can hire or outsource their internal audits to an external firm or team of consultants. This is still considered an internal, first-party audit because the hired auditors are simply temporary employees of the organization.
Figure 8.1 Internal first-party audit.
Figure 8.2 External second-party audit.
External Second-Party Audits (Supplier Audits)
A second-party audit, also known as a supplier audit, is an external audit where a customer, or an organization contracted by a customer, performs an audit on its supplier. As illustrated in Figure 8.2 , in a second-party audit the auditor and clients are in the customer’s organization and the auditee is in the supplier’s organization. The audit criteria for an external second-party audit can come from inside the supplier’s organization. For example, the supplier’s systems, processes, or plans can be used as audit criteria. The audit criteria can also come from the customer’s organization, including the customer’s standards and requirements. In a second-party audit, the supplier can also be audited to external standards if the contract/agreement with the supplier requires adherence to those standards.
An example of a second-party audit would be a supplier qualification audit, where a customer audits a potential supplier prior to awarding a contract to verify that the supplier has the capability and capacity necessary to produce products of the required quality level. Another example would be a supplier surveillance audit where a customer performs audits of its suppliers as part of ongoing supplier monitoring activities during the execution of a contract/agreement. Of course, the requirements for these audits should be documented in the contracts or other agreements with the supplier.
Figure 8.3 External third-party audit.
External Third-Party Audits
A third-party audit is an audit performed on an auditee by an external auditor other than their customer. In a third-party audit, the client may be the organization being audited or it may be a third-party organization. As illustrated in Figure 8.3 , the audit criteria for a third-party audit may be the audited organization’s own internal systems, processes, or plans, or external standards may be used as the audit criteria.
An example of a third-party audit would be government regulators auditing an organization to verify that all required external regulations (standards) are being met. Another example would be a registrar conducting an audit prior to granting certification to ISO 9001. Even though the registrar’s fees are paid by the organization being audited, they are considered an independent third party because they report to an accreditation board.
System Audits
System audits are audits conducted on management systems that evaluate all of the policies, processes, and work instructions, supporting plans and activities, training, and other components of those systems. A system audit can be thought of as a mega-process audit because it looks at all of the processes in the system. For example, a quality management system audit evaluates an organization’s existing quality management system’s adequacy, conformance, and effectiveness. Other systems that might be audited include an organization’s environmental system or safety system.
Process Audits
A process audit evaluates a single process (or small set of processes) to determine if the process is defined, deployed, and adequate to meet the required quality objectives. A process audit also evaluates whether the process is being implemented correctly with due diligence, and to determine if the process really works. A process audit covers only a specific portion of an entire system. An example of a process audit would be an organization auditing its requirements specification inspection process to evaluate conformance to its documented peer review process, and the effectiveness of that process. Another example might be auditing the software configuration management process, or just one of its sub-processes, such as the configuration identification process.
Product Audits
A product audit looks at a product and evaluates conformance to the product specifications, performance requirements, and workmanship standards, and/or the stakeholders’ requirements. A product audit may look at the results of software peer review, testing, or other verification and validation (V&V) activities, review V&V or other product quality records, or it may include a sampling of repeated V&V activities (re-peer review or retest). An example of a product audit would be an organization auditing a sampling of source code modules to determine the level of conformance to internal coding standards. Another example would be to audit a finished subsystem to evaluate its compliance to its allocated functional requirements.
Project Audits
A project audit looks at the processes and activities used to initiate, plan, execute, track, control, and close a project. It evaluates the project’s conformance to documented instructions or standards. A project audit also looks at the effectiveness of the project management process in meeting the intended goals and objectives of the project, and the adequacy and effectiveness of the project’s controls.
Follow-Up Audits
Any audit may produce nonconformances/noncompliances that require corrective action. When those corrective actions are completed at some future date, a follow-up audit is one of the mechanisms that can be used to verify the completeness and effectiveness of the implementation of those corrective actions. A follow-up audit can be combined with the next scheduled audit of the area in order to minimize time and expense.
Desk Audits
A desk audit, also called a document audit, is limited to the evaluation of the organization’s documentation, including quality records. These audits can be conducted at the auditor’s desk since no on-site visit is required, where people are interviewed and activities are observed. A desk audit might also be conducted by mail, where questionnaires are sent to the auditee and the auditee provides required objective evidence for the auditor to review without the need for an on-site visit.
2. AUDIT ROLES AND RESPONSIBILITIES
Identify roles and responsibilities for audit participants including client, lead auditor, audit team members and auditee. (Understand)
BODY OF KNOWLEDGE II.C.2
Client
The client, also called the initiator or customer of the audit, is the person or organization requesting the audit. The client determines the need for the audit and provides the authority to initiate the audit. The client:
The client is the main customer of the audit report and determines its distribution. The client also acts as the final arbitrator for any audit-related issues that can not be handled at a lower level.
Auditor Management
The auditor management is the management of the auditing organization. The auditor management is responsible for assigning a lead auditor to each audit and working with that lead auditor to select any additional members for the audit team. The auditor management makes sure that the selected lead auditor and other auditors have appropriate training, knowledge, skill level, and independence. The auditor management provides the funding and other resources required to plan, prepare for, execute, report, follow up on, and manage the audit.
In the case of internal audits, the auditor management may also be responsible for establishing an effective audit program, including supporting procedures, processes, and tools, and for evaluating the performance of that audit program and of the individual auditors. The auditor management may also plan the audit program itself, which includes setting priorities for audits and defining the organization’s audit program schedule. An organization may have a full-time team of internal auditors or a group of part-time, trained auditors who perform audits as just one of their work activities. Either way, while performing their auditing duties the internal auditors should be responsible to a manager within the organization with enough authority to:
Lead Auditor
The lead auditor, also called the audit team lead, is designated to manage the individual audit and its audit team, and is responsible for the overall conduct and success of that audit. In addition to fulfilling the responsibilities of an auditor, the lead auditor:
Auditors
The auditors are the individuals conducting the audit. For larger audits there may be an audit team made up of a group of auditors. For small audits, the lead auditor may be the only auditor. The auditors are responsible for:
Auditee Management
The auditee management is the manager of the organization being audited, who has been assigned to coordinate with the lead auditor on matters related to the audit. The auditee management is responsible for:
Auditee
The auditees are the individuals being interviewed and/or observed during the execution of the audit. The auditees are responsible for providing appropriate and accurate answers to the auditors’ questions and for providing all appropriate information requested by the auditors.
Escort
For external audits, for any type of audit where the auditors are unfamiliar with the auditees’ organization or physical location, or for any type of audit in areas with special safety or security concerns, escorts from the auditee organization may be assigned to each auditor or group of auditors. The escort accompanies the auditor during data gathering and serves as liaison between the audit team, the auditees and the auditee management. The escort is responsible for:
3. AUDIT PROCESS
Define and describe the steps in conducting an audit, developing and delivering an audit report, and determining appropriate follow-up activities. (Apply)
BODY OF KNOWLEDGE II.C.3
The basics steps in the audit process are illustrated in Figure 8.4 and include:
Figure 8.4 Audit process.
Audit Initiation
The frequency of audits varies based on an organization’s goals, objectives, risks, and contractual requirements. Audits may be initiated when:
During the initiation steps, the client selects the auditing organization, defines the purpose, scope, and objectives of the audit, and designates the audit criteria. This includes defining why the audit is being conducted and what organizations, processes, projects or products will be audited. All of the required inputs to the audit must also be available before the audit can start.
The audit purpose statement acts as a mission statement for the audit. It should define the purpose (reason) and major objectives for the audit. Examples of audit purpose statements include:
The audit scope defines the boundaries of the audit by identifying the exact items, groups, locations, and/or activities to be examined. While the client of the audit is responsible for defining the purpose and scope of the audit, for internal audits it many times falls to the lead auditor to formally document the purpose and scope statement as part of the audit plan. The scope of the audit is also used to focus the auditors’ attention on what they are supposed to be evaluating. Auditors should not actively seek to identify problems outside the scope of the audit. However, if problems outside the scope are identified, they should be reported to the auditee management. If they are serious or systemic problems that could have major impact on the quality of the software products or services, or that could have legal ramifications if not corrected, they should also be reported to the client as a negative observation in the audit report.
The documents that will be evaluated during the audit preparation should be made available at this time, as input to the audit. This allows the auditors to perform a documentation review prior to the execution of the audit. For example, if an internal audit is being conducted for a project using the organization’s software configuration management (SCM) process as the audit criteria, audit-related input documents might include the project’s SCM plans and project-specific/tailored SCM processes or work instructions. Note that the level of these input documents depends on the scope of the audit. For example, while the project-level audit in the example above looked at project-level documentation as inputs, for a system-level audit the input documents would include system-level documentation (project-level documentation might be sampled during the audit execution but would not be requested as input documentation). Quality records are typically not considered inputs into the audit process. However, they are sampled, as appropriate, as objective evidence during audit execution.
Other inputs to the audit may include background information about the auditee’s organization and information from prior audits. Background information can help the auditor understand the context in which the audit is taking place. This can include information about the business strategies and objectives, product information, domain information, and information about the industry (for example, competitive factors, regulatory environment). If prior audits have been conducted for the organization, the system, or processes being audited, then the audit reports, corrective action plans, and follow-up information from those audits are also inputs to the current audit.
Audit criteria provide the objective requirements against which conformance and compliance are evaluated. Examples of audit criteria include:
Audit Planning
During the planning step the lead auditor selects the appropriate strategy for the audit. Audit strategies include:
Based on the strategy selected, the lead auditor estimates effort and staffing needs for the audit. The lead auditor negotiates with the auditor management, who provide funding, resources, and staffing for the audit. The lead auditor then coordinates with the auditee management to establish the detailed audit schedule, makes arrangements to obtain audit-related input documents and information about the auditee organization, and coordinates the audit logistics.
The lead auditor documents the audit plan to formally communicate the details of the audit to auditor and auditee management, and to the audit team. The audit plan is the primary communication vehicle to inform audit stakeholders of the impending audit. According to IEEE (2008), the audit plan describes the:
The audit plan is a living document and should be updated and/or progressively elaborated as information is gathered during the audit. According to IEEE (2008), the audit plans, and changes to those plans, should be reviewed and approved by the client.
Audit Preparation
Auditors prepare for the audit by studying the input documentation prior to audit execution. The purpose of this document review is to evaluate the audit input documents against the audit criteria in order to assess them for compliance, completeness, consistency, and effectiveness. The subsequent execution step will then determine if the system, processes, and/or plans defined in those documents have been implemented as documented and are functioning effectively and efficiently. During the preparation step, the auditors use information from the input documents and audit criteria to prepare checklists, objective evidence gathering plans, interview questions, and other tools for use during the audit. Standardized checklists, interview questions, or other tools may be used but should be tailored to the needs of each specific audit.
“An audit checklist is the primary tool for bringing order to an audit” (Russell 2013). Checklists are lists of yes or no questions that correspond to the audit criteria. Each audit criterion (requirement) can be translated into one or more checklist items. Checklists are used to bring structure to the audit and to confirm complete coverage within the audit scope. Each item in the checklist should be precise, measurable (it must be possible to gather objective evidence to determine if that item is being met), and factual. The purpose of a checklist is to guide the gathering of information during the execution step of the audit. Checklists help the auditor remember what to look for and observe in a particular area. The information recorded on the checklists can then be analyzed and used to substantiate audit findings and conclusions. Checklists are simply tools, however, and should not be used to limit or restrict the execution of the audit. Checklists can be modified or even abandoned during the audit execution as appropriate.
For many types of audits, standardized checklists can be created (for example, see the standardized checklists for functional and physical configuration audits in Chapter 27 of this book). Advantages of using standardized checklists include:
Prior to each audit, these standardized checklists should be reviewed and updated, as necessary, to make sure that they reflect any changes made in the standards, policies, processes, or plans since the last audit was conducted. These generic checklists should also be supplemented and tailored to the exact circumstances of each individual audit. For example, if the corrective actions against prior audit findings are being verified with the current audit, specific checklist items for those actions may be added to the checklist. Another example might be the auditing of small projects, where certain optional processes or process steps do not apply and were tailored out. Only processes required for that specific project should be included in its audit checklist for that project. “Optional” or “not applicable” processes should either be identified as such, or removed from the checklist.
For each checklist item, the auditors should prepare a plan for objective evidence gathering. This plan will be used during the audit execution to gather evidence to determine whether the checklist item has been met. If the auditors decide to use interviewing as the objective evidence-gathering mechanism for one or more checklist items, interview questions should also be prepared in advance. Interview questions should be open-ended to prompt the auditee to do most of the talking during the interview, and context-free to not limit the scope of the discussion or to signal the expected answer through the wording of the question.
In addition to preparing for the audit as an auditor, the lead auditor also prepares the audit team by making certain that all of the auditors have received orientation and any necessary training required by the audit. The lead auditor continues to work with the auditee management to keep communication lines open, answer questions, and handle ongoing logistical issues.
Audit Execution
The audit execution step is the actual on-site fieldwork of the audit. The audit execution is the data- and information-gathering (objective evidence-gathering) portion of the audit. As illustrated in Figure 8.5 , the execution step of the audit starts with an opening meeting between the audit team and the auditee organization. The lead auditor conducts this meeting, and at least one member of the auditee management should attend the opening meeting. However, additional members of the auditee management and other auditees and interested parties may attend at the discretion of the auditee management. The objectives of the opening meeting include:
Figure 8.5 Audit execution process.
Any known issues, problems, or adjustments that need to be made to the audit schedule or logistics should be handled at this meeting through consensus between the auditee management and the audit team. For example, if interviewees are not available at the scheduled time, the audit schedule can be adjusted. If there are any disagreements, required clarifications, or questions from the auditees, these should also be addressed at this time.
Most of the time and effort of the audit execution step is spent gathering objective evidence. “The job of the auditors is to collect factual information, analyze and evaluate it in terms of the specified requirements, draw conclusions from this comparison, and report results to management” (Arter 1994). Objective evidence is information which can be proven true, based on facts obtained through observation, document review, measurement, test, or other means. One of the reasons that the independence of the auditor is so important to the audit is that it helps make sure that the observed or documented evidence is uninfluenced by prejudice, emotion, or bias. Techniques for gathering objective evidence include:
When auditing an organization or team that uses agile methods, there may not be as many quality records or documents available as when auditing traditional software development methods. Therefore, the auditors may have to depend more heavily on the other objective evidence-gathering techniques.
There is never enough time to look at all possible objective evidence during an audit. For example, there may be hundreds of source code modules or thousands of sets of meeting minutes (from peer reviews, status meetings, change control board meetings, and so on) or other quality records. Audits are always based on sampling from all of the possible objective evidence that is available. Whenever possible, random samples should be taken so that results can be generalized to the entire population.
Tracing is an example of one approach for gathering objective evidence. Tracing follows the chronological progress of an item as it is being processed. Tracing can begin at the beginning, middle, or end of the process. Then an action is chosen, and work products are sampled from that action. For example, the auditor could start in the middle of the software development process and select the action of coding a module. The auditor could then randomly sample specific source code modules from the list of modules that have been coded. The auditor gathers information about the sampled items in five areas:
The auditor can then trace the sampled modules forward into integration test, system test, and release, looking at items such as the integration methods, change control, and problem reports against the modules. The auditor can also choose to trace the modules backward and ask to see the associated detailed design for each module or the higherlevel design that specified each module, or examine the tracing of each module back to its associated requirements. The benefit of tracing is that if a random sampling of items can be traced forward or backward through the process, there is a high confidence level that all of the items can be traced.
Each day of the audit, the audit team should get together in a daily audit team meeting to share gathered objective evidence, tentative conclusions, and problems. Based on the progress that has been made during audit execution, these meetings may also be used to re-plan the audit activities. For example, the team may decide that additional data needs to be gathered to clarify incomplete or contradictory results, or delays in one area of the audit can result in the shifting of assigned activities between auditors. Even if there is only a single auditor performing the audit, that auditor should take time each day to consolidate information and plan further activities as appropriate. During the last day of the audit, the daily team meeting is used to create the draft audit report that will be presented during the closing meeting. Utilizing the objective evidence obtained during the execution phase allows audit conclusions and results to be fact-based.
After the audit team meeting each day, a daily feedback meeting (also called a daily briefing) is held to update the auditee management on the information that has been collected so far, and on any potential nonconformances, problems, or areas of concern. The goal here is “no surprises.” These meetings also give the auditee management an opportunity to provide additional objective evidence to clarify misconceptions, and prevent incorrect information from being included in the audit report.
Holding a closing meeting completes the audit execution step. The auditee management should attend this meeting along with members of the audit team and other interested stakeholders, including auditees. The lead auditor conducts the closing meeting by starting with a summary of the audit and then presenting the audit results in detail. This presentation is followed by an open discussion about the results. The lead auditor or a member of the audit team responds to any questions and clarifies information as necessary. This discussion also gives the auditee management a final opportunity to “point out any mistakes with respect to the facts that have been collected” (Juran 1999). During the closing meeting, the lead auditor also explains the requirements for the corrective action response to any nonconformances/noncompliances identified, and the associated follow-up activities. The objective of the closing meeting is to confirm that the auditee management clearly understands the results of the audit so they can start working on corrective actions.
Audit Reporting
During the reporting step, the results of the audit are formally documented in the audit report. The audit report contains (based on Russell 2013):
Audit Corrective Action and Verification Follow-Up
For each nonconformance/noncompliance in the audit report, the auditee management needs to make sure that corrective actions are planned and implemented. The auditee management may also decide that corrective actions need to be planned and implemented for negative observations and process improvement opportunities. The auditee management may either do this planning and implementation themselves or delegate those activities to others. The corrective action plan should include specific actions with schedules and responsibility assignments for each action. If actions have already been taken to correct the nonconformance/noncompliance, or observation, these should also be documented in the corrective action plans. If the auditee management determines that corrective action is not appropriate after additional review of the audit findings, they should document the reasons why no action is necessary in their response to the lead auditor.
Upon receipt of the auditee management’s corrective action response, the lead auditor coordinates the review of the corrective action plans. This may be accomplished by the lead auditor reviewing the corrective action plans, by the audit team reviewing those plans, or, if necessary, by using a technical expert to review those plans. This review can help prevent the auditee’s organization from wasting time and resources implementing corrective actions that will not eliminate the nonconformance/noncompliance or solve the problem.
If the corrective action plans, or justifications for why no corrective actions were needed, are acceptable, the lead auditor informs the auditee. If one or more of the proposed corrective actions or justifications are not acceptable, the lead auditor contacts the auditee management and resolves the issue. If the issues can not be resolved between the lead auditor and auditee management, they can be escalated to the client.
As the auditees complete the implementation of each corrective action, they inform the lead auditor. The lead auditor then coordinates the verification of each implemented corrective action:
If the corrective action is completed before the end of the audit, the follow-up on that corrective action’s implementation may be completed as part of that same audit, and the audit report can include both the reporting of the nonconformance/noncompliance and the fact that a corrective action was implemented and verified.
The lead auditor confirms that the actions that were taken to verify the corrective action are documented. This documentation becomes part of the quality records for the audit.
Each corrective action is closed as its successful implementation is verified. Each nonconformance/ noncompliance is closed when all of its associated corrective actions are verified and closed. The audit is closed when all nonconformances/noncompliances for that audit are closed.
Audits, like any other process, should be auditable. This means that quality records related to the audit must be collected and retained. Based on the needs of the auditing organization, the required quality records for an audit should be included in the audit process definition. Examples of quality records maintained for an audit might include: