This document is not an API Standard; its under consideration within an AP! technical committee but has not received all approvals required to become an API Standard. It shall not be reproduced or circulated or quoted, in whole or in part, outside of API committee activites except with the approval of the Chairman of the committee having jurisdiction ‘and staff of the API Standards Dept. Copyright API, All rights reserved. Guidance to API Specification Q2 API TECHNICAL REPORT 18TR2 FIRST EDITION, XXXXXX 201XThis document is not an API Standard; itis under consideration within an API technical committee but has not received all approvals required to become an API Standard. It shall not be reproduced or circulated or quoted, in whole or in part, outside of API committee activites except with the approval of the Chairman of the committee having jurisdiction ‘and staff of the API Standards Dept. Copyright API, All rights reserved. Special Notes ‘API publications necessarily address problems of a general nature. With respect to particular circumstances, local, state, and federal laws and regulations should be reviewed. Neither API nor any of API's employees, subcontractors, consultants, committees, or other assignees make any warranty or representation, either express or implied, with respect to the accuracy, completeness, or usefulness of the information contained hereinvor assume any liability or responsibility for any use, or the results of such use, of any information or process disclosed in this publication. Neither API nor any of API's employees, subcontractors, consultants, or other assignees, represent that use of this publication would not infringe upon privately owned rights. Classified areas may vary depending on the location, conditions, equipment, and substances involved in any given situation. Users of this specification should consult with the appropriate authorities having jurisdiction API publications may be used by anyone desiring to do so. Every effort has been made by the Institute to assure the accuracy and reliability of the data contained in them; however, the Institute makes no representation, warranty, or guarantee in connection with this publication and hereby expressly disclaims any liability or responsibility for loss or damage resulting from its use oF for the violation of any authorities having jurisdiction with which this publication may conflict. ‘API publications are published to facilitate the broad availability of proven, sound engineering and operating practices. These publications are not intended to obviate the need for applying sound engineering judgment regarding when and where these publications should be utilized. ‘The formulation and publication of API publications is not intended in any way to inhibit anyone from using any other practices. All nights reserved. No pat ofthis work may be reproduced, translated, stored in 2 reieval system, or ransmitad by any means ‘ectroni, mechanical, shotooopying, recording, or otherwise, without prior writen permission from the publisher. Contact the Publisher, AP! Puolshing Senvces, 1220 L Street, NW, Washington, DC 20005, Ccopyrig © 2016.2mercan Perotewn DsThis document is not an API Standard; itis under consideration within an API technical committee but has not received all approvals required to become an API Standard. It shall not be reproduced or circulated or quoted, in whole or in part, outside of API committee activites except with the approval of the Chairman of the committee having jurisdiction ‘and staff of the API Standards Dept. Copyright API. All rights reserved. Table of Contents to be created prior to publication.This document is not an API Standard; ft under consideration within an AP! technical committee but has nat received all approvals required to become an API Standard. soll not be reproduced or circulated or quoted, in whole or in part, outside of AP committee activities except with the approval ofthe Chairman of the committee having jurisdiction and staff ofthe API Stondards Dept. Copyright APL All vights reserved. 1 Scope This document provides guidance on the intent and use of API Specification Q2 (API Q2). This document is not intended to provide training on the development and implementation of a quality management system. This document will not provide guidance to each section of the API Q2. 2 Terms, Definition, Acronyms and Abbreviations 2.1 Terms and Definitions For the purposes of this document, the terms and definitions given in API Q2 apply. 2.2 Acronyms and Abbreviations moc management of change PMITP preventive maintenance, inspection and test program ams quality management system sap service quality plan SRP service relate product TMMDE testing, measuring, monitoring, and detection equipment NOTE Paragraph numbering aligns with the sections of API Q2. 5.3 Risk Assessment and Management Risk assessments create an awareness of situations, processes, environments, etc. that may cause or contribute to disruptions, incidents, problems, failures, delays, or loss. The primary goal of risk mitigation is to lower the risk exposure to within acceptable threshold limits. Risk mitigation consists of identifying and implementing actions designed to decrease the probability and/or consequence of an incident irrespective of the actual occurrence of risk. Mitigating actions are expected for risks that exceed the risk threshold. Risk assessments are conducted by a competent individual or team with @ good working knowledge of the methodology, operational and environmental conditions, and the intended servieg and service-related product. (See Section 4.3.2.2) Risk assessments may be incorporated into other management system processes, procedures, documents and records.This document is not an API Standard; its under consideration within an AP! technical committee but has not received all approvals required to become an API Standard. It shall not be reproduced or circulated or quoted, in whole or in part, outside of API committee activites except with the approval of the Chairman of the committee having jurisdiction ‘and staff of the API Standards Dept. Copyright API, All rights reserved. There are numerous industry tools and standards that can provide guidance for risk assessments. The organization must identify the methodology they plan to use and have a documented procedure for conducting the risk assessment ISO 31010 provides examples of various techniques for risk management. 5.5 Contingency Planning Contingency plans are not emergency response plans. Contingency planning is the process by which the organization identifies backup plans in the event that the risk materializes. Contingency planning does not change the probability of the event, but can change its impact. Developing a contingency plan involves making decisions in advance about the management of services and SRP, coordination and communication procedures, and being aware of a range of technical and logistical responses. Risk mitigation and contingency planning are two strategies that are used in the management of risk. Both are closely related to one another as they, are sequential, complementary steps used in the risk assessment process. Every contingency plan requires a risk a8sessment (See Section 5.5.2); however, not every assessed risk requires a contingency plan. 5.6.1 Purchasing Control Requirements established in section 5.6.1 (2-e) are applicable to purchasing control of critical and non-critical services and service related products (SRP). The difference between the requirements for critical and non-critical is that the organization must perform an on-site assessment of the critical service or service related product supplier prior to use. The purpose of the assessment is to verify the supplier's ability to meet the specified scope of work and that the supplier’s quality management system meets the requirements specified by the purchasing organization. For nomertical service or service related product suppliers, the organization has the option ofperforming one or more of methods identified in Section 6.6.1 (ii. {tis the organization's responsibility to determine and define what is critical and non-critical as it relates to service related products or services and the evaluation process Is defined in Section 56, The organization is responsible for identifying the quality management system (QMS) requirements (e.g, ISO 9001, API Q1, API Q2, organization specific, etc.) for their subcontractors. The QMS requirements should be based on the product or service being supplied and the associated risk.This document is not an API Standard; its under consideration within an AP! technical committee but has not received all approvals required to become an API Standard. It shall not be reproduced or circulated or quoted, in whole or in part, outside of API committee activites except with the approval of the Chairman of the committee having jurisdiction ‘and staff of the API Standards Dept. Copyright API, All rights reserved. NOTE: See further clarifications in Section 1 Scope and Application. 5.6.2 Purchasing Information Requirements established in Section 5.6.2 (a-e) are applicable to purchasing information for critical and non-critical services and service related products. Each requirement is applied “where appropriate" for the type of service to be performed andior service related product to be provided. Examples of where this information could be captured or referenced include, but are not limited to: purchase order, master service agreement (MSA), master purchasing agreement (MPA), contracts, addendums, statement of requirement (SOR), etc. 5.6.3 Verification of Purchased Services and Service-related Product ‘The requirements in this section are applicable, not only to services or service related product purchased outside the organization but inside the organization as well. The organization determines and documents how the verification of purchased services or service related products are performed for both intemal and external suppliers 5.7.2 Service Quality Plan Service Quality Plans (SQP) are a requirement for all services. The organization is responsible for determining how to build a SQP that will be effective, usable and compliant to all requirements listed in 5.7.2. The SQP is not intended to be a bridging document between multiple management systems. It is possible to employ one document or a combination of documents to achieve this. The requirement is not intended to mean there is a “standard” service quality plan in place. SQPs should be job specific, service specific, customer specific — as long as it meets the specific requirements of API Q2. “External parties’ is a general term that can describe customers, regulators, suppliers, contractors, subcontractors and other parties external to the organization that impact the delivery of the service. In other parts of API Q2 where the standard mentions subcontractors and or suppliers, thet are specific requirements that are applied to those external parties. The SQP requires'identification of the responsibilities of suppliers, subcontractors and other external parties. This includes the identification of the subcontractor and the description of the controls over the subcontractor. Examples of various templates for quality plans can be found in ISO 10005. If you use one of these templates, all of the requirements of API Q2 must be included.This document is not an API Standard; its under consideration within an AP! technical committee but has not received all approvals required to become an API Standard. It shall not be reproduced or circulated or quoted, in whole or in part, outside of API committee activites except with the approval of the Chairman of the committee having jurisdiction ‘and staff of the API Standards Dept. Copyright API, All rights reserved. 5.7.3 Identification and Traceability API Q2 specifies the minimum set of requirements for traceability for critical service related product which includes rental tools designated as critical. Specific material traceability and records requirements will depend on the product and the requirements defined by the organization and the customer. Critical service related product including legacy tools that do not meet the traceability requirements of API Q2 would be identified as nonconforming product and handled in accordance with Section 5.10. The identification of the criticality of SRP (including components) is based on risk assessment and performed during the design of the service. Identification of an assembly as critical does not by default make all the components in the assembly critical. Itis the responsibility of the organization to communicate the criticality of SRP to applicable personne! throughout the Service Realization Process. 5.7.5 Customer Property Intellectual property could include, but are not limited to, well data, lab results, specifications, proprietary products, logging data, reservoir data, etc. 5.7.7 Validation of Service-related Product The intent of validation of SRP is to ensure SRP functionality through inspection and/or testing prior to service execution. Some SRP (e.g. cement, perforating assemblies, ete.) may not be able to undergo a validation prior to service execution. Other SRP that can be validated may require a facility and special testing equipment that is not available while the SRP is deployed, Certain classes of SRPs are deployed and utilized for multiple customers and in multiple wells prior to being returned to a facility where the SRP is inspected, tested, repaired and maintained, (2. a driling tring that is deployed to dri three land wells for two different customers prior to being retumed fo the repair and maintenance facility where the tool wil be inspected, tested, repalred, maintained and validated prior to its next deployment). The SP should be used to specify the controls needed for validation of service-related product in the shop andior the field 5.7.8 Preventive, Maintenance, Inspection, and Test Program The requirement for PMITP applies to service related products that are used throughout the execution of the service. Critical spare parts for service related product are determined based on the type of Service, location, risk levels established by the service provider and customer, input from the original equipment manufacturer, and the application of the service related product. Critical spare parts may be located at the service provider's facility and/or at the well site. Process related equipment is addressed under Section 4.3.3. Usage history can include a variety of factors related to the cumulative time SRP is used, the environments and conditions the SRP is exposed to, the related environmental impacts on the SRP, the type of SRP, the application of the SRP, etc.This document is not an API Standard; its under consideration within an AP! technical committee but has not received all approvals required to become an API Standard. It shall not be reproduced or circulated or quoted, in whole or in part, outside of API committee activites except with the approval of the Chairman of the committee having jurisdiction ‘and staff of the API Standards Dept. Copyright API, All rights reserved. The requirement for acceptance criteria applies to processes, tests and inspections (see 5.7.1.2). Components of the SRP subjected to planned inspection and testing are required to have documented acceptance criteria 5.8 Control of Testing, Measuring, Monitoring and Detection Equipment Not all testing, measuring, monitoring, and detection equipment (TMMDE) may be part of the calibration program. It is the responsibility of the organization to determine which TMMDE is used for verification and validation of service and service-related product. The organization has the responsibilty to verify that TMMDE supplied by extemal sources for its use is calibrated and/or verified prior to its use. This may include verification of the calibration of the TMMDE through calibration status indicators, confirmation with the owner of the TMMDE, and review of records. Organizational procedures should describe the process for determining evidence of conformity 5.10.2 Nonconforming Service Execution and Service-related Product Where software is used in the execution of a service (\¢., service-related product), Ronconformities should be handled as defined in the documented procedure for addressing nonconforming service-related product. 5.11.2 MOC Implementation A management of change (MOC) is not needed for routine personnel changes (e.g., crew or shift changes) ifthe change is not going to impact the execution of service 5.11.3 MOC Evaluation, Notification and Controls The specification requires notification of relevant personnel, including the customer, of the change and the isk assessment results. The source or initiation of the change does not affect the requirement that the MOC process must be employed. It is outside the scope of the specification to require a response or acknowledgement from the customer. 6.2.2 Internal Audit Outsourced activities that are part of the organization's processes are included in the internal audit plan. As an example a calibration contractor that visit's the organization's site annually to calibrate equipment would not be part of the intemal audit plan. A NDE company that conducts inspection of service-related product as part of the routine inspection process would be included in the intemal audit plan.This document is not an API Standard; its under consideration within an AP! technical committee but has not received all approvals required to become an API Standard. It shall not be reproduced or circulated or quoted, in whole or in part, outside of API committee activites except with the approval of the Chairman of the committee having jurisdiction ‘and staff of the API Standards Dept. Copyright API, All rights reserved. The internal audit requirements of 6.2.2.1 and the on-site assessment (see 5.6.1) requirements for critical suppliers are separate requirements, with different scopes that require separate activities to be performed. 6.3 Analysis of Data The organization must define the frequency of data analysis. 6.4.3 Preventive Action During the process of performing Risk Analysis and Management (Section 6.3) for a service Telated product or process you may identify a potential scenario that may result in a nonconformance and therefore take preventive action. Preventative Action is used before an event occurs whereas a Corrective Action is used after an event occurs. 6.5.1 Management Review, General Expectation is that the service provider performs a management review at least every 12- months. 6.5.2 Management Review Input Requirements Only the results of internal audits (as opposed to other types of audits) are specifically required by API Q2, However, the results of other types of audits, while not required, may be included in management review if deemed appropriate by the service organization.This document is not an API Standard; itis under consideration within an API technical committee but has not received all approvals required to become an API Standard. It shall not be reproduced or circulated or quoted, in whole or in part, outside of API committee activites except with the approval of the Chairman of the committee having jurisdiction ‘and staff of the API Standards Dept. Copyright API, All rights reserved. Bibliography 1. API Specification Q1, Specification for Quality Management System Requirements for ‘Manufacturing Organizations for the Petroleum and Natural Gas Industry 2. API Specification Q2, Specification for Quality Management System Requirements for Service Supply Organizations for the Petroleum and Natural Gas Industries 1S0 9001, Quality management systems — Requirements 1SO 10005, Quality management systems — Guidelines for quality plans 5. ISO 31010, Risk management — Risk assessment techniques RO