7.2.2.C2 合同評審
組織必須建立和保持以合同評審過程，并應該包括：
a) 產品接受準則和準則評審過程，
b) 處理在產品接受后發現的問題方法，包括顧客抱怨，
c) 在適用的保質期后或在產品合同約定的維護期內, 不合格的移去和/或糾正計劃，
d) 可能不可預計費用和風險識別，
e) 針對產權信息足夠的防護，
f) 組織與外包工作有關的職責定義，
g) 由顧客執行的活動，包括顧客在要求,規范和接受中的作用；
h) 由顧客提供的裝置，工具和軟件項目，和
i) 所有參考的標準和程序。
7.2.2.C 2注：適當時，產品接受準則應該包括：
a）文件化測試程序，
b）測試用例，
c）測試數據，
d）測試職責，
f）包含的資源，
g）規定的接受測試報告。
7.2.3.C.1 問題的嚴重度分類
除了嚴重程度水平報告特別除外的那些產品, 組織必須根據本手冊中的術語定義中對關鍵，嚴重和輕微問題報告定義對客戶的影響來確定客戶報告問題的嚴重度，必須根據這嚴重程度來確定組織作出反必須的及時程度。
7.2.3.C.1 - 注1 ：客戶與組織應該共同決定解決客戶報告問題的優先次序。
7.2.3.C.1-注 2: 在報告NPR4的產品類型單獨注冊的組織不需要通知豁免此要求。
7.2.3.C.2 問題的提升
組織必須建立一文件化提升程序以解決客戶報告問題。
7.2.3.C.3 問題報告反饋
組織必須及時和系統地向客戶對其問題報告提供反饋。
7.2.3.HS.1 產品追回
組織必須建立并保持文件化程序以識別和追回不適合繼續服務的產品。
7.2.3.HS.2 設計開發過程質量測量數據報告
按顧客要求，溝通必須包括共同認可的設計開發過程測量的報告和評價。
7.2.3 HS.3 關鍵問題報告的通知
組織必須建立一文件化程序，通知可能由關鍵問題報告影響到的所有顧客。
7.2.3.V.1 關鍵服務中斷通知
組織必須針對影響到的顧客建立和保持一方法，獲取關于目前中斷的實時信息。
7.2.3.V.1-注 1: 此要求僅適用于提供服務給最終客戶的組織。
7.3.1.C.1 項目計劃
組織的序幕策劃活動必須根據已規定的產品生命周期模式建立并保持項目計劃（見7.1.C.1）。計劃應該包括：
a) 項目組織結構;
b) 項目團隊的作用，職責和義務;
c) 相關團隊或個人在組織內外部的作用，職責和義務，在他們和項目團隊之間的接口，
d) 時間計劃，跟蹤，問題解決和報告的方法;
e) 項目因素估算;
f) 準備使用的方法，標準，文件化程序和工具的標識(假如此項目是被清晰的定義作為產品生命周期模式的部分，參考生命周期模式是可以的)，
g) 與其它相關計劃的連接(例如：風險管理，開發，測試，配置管理和質量)，
h) 項目特定開發或服務交付環境和物質資源的考慮(例如：去描述開發,用戶文件， 檢測, 操作,規定的開發工具,安全計算環境,試驗空間,工位等的資源)，
I) 針對X(DFx)設計計劃適合于產品的生命周期;
j) 項目質量的管理，包括合適的質量測量，
k) “X”計劃設計適合產品生命周期(計劃例子包括,但不限于:可加工性,可靠性,法規性,適用性,
安全性,耐久性,和可試驗性)
l) 來自先前項目一流分析的課程，
m) 風險管理和應急計劃 (例如，工作風險, 現場低可靠性, 缺陷, 資源和時間計劃)，
n) 項目特定的培訓要求，
o) 規定的認證，(例:產品認證或員工的技術認證)
p) 專利權，使用權，所有權，保證期和許可證權限，和
q) 項目完成后的分析和改進活動，包括學習的項目課程根本原因分析，和在將項目中排除重復發生而采取的糾正措施。
7.3.1.C.1- 注 1: 項目計劃和任何其它相關計劃都可以是一個獨立的文件或是另外一份文件的一部分或是幾份文件的組合.
7.3.1.C.1 – 注 2: 對所有開發項目都通用的，規定任務和職責的通用作業指導書不需要重復作為項目計劃的一部分。
7.3.1.C.1-注 3:項目因素的估計應該包括產品的規模,復雜性,要求變更,工作量,雇工,計劃,成本,質量,可靠性,和產率.來自估算過程的數據應該和比較先前估算到實際進行分析.
7.3.1.C.1-注 4: DFx 例子包括可加工性，可靠性，法規，可維修性和可試驗性。參見DFx 在TL9000.org 針對例子和其他信息的指南文件。
7.3.1.C.2 要求的可追溯性
組織必須建立并保持一方法以追溯每一個設計和檢測過程中文件化的要求。
7.3.1.C.2 - 注 ：
組織應該建立溝通方法以傳達產品要求和要求的更改，給項目計劃中識別的所有受影
響相關方。
7.3.1.C.3 測試策劃
測試計劃必須文件化，并應該包括:
a) 測試范圍 (例如, 單元, 特征, 集成, 系統, 驗收,電場,轉移和回歸);
b) 需要進行的測試種類 (例如, 功能, 極限, 使用性, 性能, 回歸, 相互操作性,超載);
c) 對要求的可追溯性;
d) 測試環境 (例如, 有關客戶環境, 操作使用);
e) 測試覆蓋范圍; ( 驗證產品功能程度的測試，有時用功能測試百分比來表示)，
f) 期望結果;
g) 數據的定義和數據庫的要求;
h) 測試裝置, 測試實例 (輸入, 輸出, 測試準則) 和文件化測試程序;
i) 外部測試的使用，和
j) 報告和解決缺陷的方法。
k) 顧客測試要求
l) 預定義的退出準則.
測試結果和其后的采取的措施必須被記錄(參見4.2.4).
7.3.1.C 4 風險管理策劃
組織必須開發和文件化一個針對會影響成本, 進度, 產品質量或產品業績方面的項目識別, 分析和風險控制的計劃。
7.3.1.C.4 注：
風險管理應該在所有的產品開發階段被執行，可以包括：
a) 確定風險資源,分類和優先順序;
b) 關鍵和致命特性和失效模型,包括顧客的期望，
c) 被用于界定風險優選和任何計分的原理的風險參數定義(例如:發生的可能性,影響的程度)被應用(例如:FEMA, Failure Mode Effect Analysis)，
d) 風險如何被管理(例如:使用的工具,降低風險的措施,遷移決策,監視和報告的要求)，
e) 來之合適的功能性學科的輸入，
f) 針對獲取和應用學習課程的機制。
7.3.1.C.5 集成策劃
組織必須開發并文件化一計劃去集成硬件，軟件和/或服務部分進入到產品中，以確保達到設計要求。計劃必須包括：
a) 方法和文件化程序，
b) 職責，
c) 集成的時間計劃， 和
d) 測試要求。
7.3.1.HS.1 遷移策劃
當一個系統，硬件或軟件產品將要從一個舊環境遷移到一個新操作環境，組織必須開發和文件化遷移計劃，假如老的環境不再被支持，用戶必須給出轉移計劃和活動，包括新環境獲得日期的通知，以及其他支持選擇的獲得描述，包括一旦老環境支持被移去。這個計劃也應該包括：
a) 要求分析和遷移的定義，
b) 遷移工具的開發，
c) 產品和數據的轉換，
d) 遷移的執行，
e) 遷移的驗證，和
f) 今后對舊環境的支持。