成熟度階梯給的是狀態判讀與下一步的方向，狀態要移動，動作得排進固定的日程。本章處理排程這一側：多久做一次、每個動作由誰承接、拿什麼判斷能力有沒有前進。階段名沿用階梯那一章、本章不另立一套（理由見必連章節的第一條）。

本章的角色分工假設參與者在組織內部且可以被指派。權力或證據受眾在外部時（甲方核准、監理機關、外部稽核），外部方設定的是節奏的下限與證據的保留期，而本地能指派的是「誰負責去要那個決定」；參與者少到角色無法分立時，阻力要換成機制而不是人（見下方角色段）。到期日集合為空的小團隊要注意這只消掉本章算式那一條上限，不消掉外部強制週期與變化速率那幾類驅動源。

回顧節奏的下限由已經存在的到期日決定

治理節奏的起點是系統裡已經存在的到期日，不是月曆。定期回顧是這些到期日的最後一道攔截，所以間隔有一個算得出來的上限：

回顧間隔 ≤ （集合裡最早的真正截止日 − 現在）÷ n

三個輸入各有它的判定，而三者都答完才有一個門檻可以驗收。

集合是帶到期日的治理物件：風險例外的期限、憑證的有效期、回顧產出的改進項目的完成時限。

集合可以扣掉自帶 tripwire 的項目，而扣除要同時滿足兩個條件：

  1. 觸發訊號涵蓋這個項目的到期日（「到期前 N 天觸發」）。tripwire 的典型形態是條件驅動——驗證失敗率超標、特權操作異常增長——而條件驅動的觸發器不會因為某張憑證快到期而響；用它扣掉一個到期日，等於把時間驅動的攔截換成一個不看時間的訊號。
  2. 通過存活性檢查：問的是最近一次觸發或心跳的時間。訊號源停止供資料、門檻設在永遠不會被跨過的位置、升級路徑指向已經離職的人——這幾種情況下 tripwire 跟過期一樣不發出訊號，而「沒有觸發」與「沒有事情發生」在儀表板上無法區分（清單不窮盡，共同特徵是失效本身不產生訊號）。

兩個條件任一不成立時，該項目留在集合裡。另外自動續期不算 tripwire：它消掉到期日而不產生訊號，覆蓋範圍外的那幾張憑證因此既沒有觸發器也不在任何人的視野裡。

集合怎麼列舉決定這個門檻涵蓋誰，而它跟下方指標段是同一個分母問題：到期日從某張登記表數出來時，沒登記的項目不在集合裡。憑證這一側由簽發端或掃描端獨立列舉，做法與 7.3 的資產與憑證分母的來源對帳 同一條。例外這一側的獨立來源是變更紀錄（掃描對它無效，例外不是一個可探測的物件）：把放行紀錄裡帶範圍限制的那些（gate decision 寫下的「允許在某條件下上線」）與例外登記表對照，差集就是當時做了決定而沒有登記的例外。第二個來源是補償控制的設定——為某個例外開的臨時規則、放寬的限額、額外的告警——它們留在系統裡而例外可能已經從表上消失。

真正截止日是到期日減掉該項目的前置期。前置期來自組織外部的要求：合約規定變更要提前十四天書面申請、甲方核准要排隊、供應商的維護窗口每月只開一次。一張二十天後到期的憑證在十四天前置期下的真正截止日是第六天，而不是第二十天——用到期日直接算，第一次回顧會落在申請截止日之後。

n 是截止日之前要落幾次回顧——n 等於二的意思是「第一次提出、第二次是最後機會」。算式讓第 n 次剛好落在截止日當天，所以那一次沒有驗收緩衝、實際可用的補救循環是 n−1 次；要保留兩次完整的提出加驗收循環，n 是三。需要跨團隊協調或外部核准的項目取更大的 n。

有兩個重算時點。一是集合新增成員時：每一筆帶範圍限制的放行都新增一筆例外，最早截止日可能因此提前。二是算出的間隔短於團隊可行的最小會議頻率時；這時的處置是把那個項目改成事件驅動（掛一條到期前觸發的提醒，並依存活性要求驗證它會響），不是把間隔調回可行值。

集合可能是空的，而這是一個有意義的答案：所有帶到期日的物件都被自動續期消掉、或都有帶存活性檢查的 tripwire 時，由到期日推導出的那個間隔上限不存在。小團隊常落在這一格，判定它的方式是把集合列出來而不是省略這一步：空集合與「還沒列」在會議紀錄上長得一樣。

空集合消掉的只是這一條上限，不是時間驅動的回顧本身。另外三類驅動源與到期日無關：外部強制週期（稽核要求每季一次時，集合為空不構成豁免）、下一節的變化速率、以及沒有到期日卻需要定期複核的對象（人員的權限、下一節提到的熟練度衰退）。集合為空而這三類也都不適用時，才是「不需要時間驅動的回顧」。

兩條收斂路徑，差別是誰配合誰。一條是照上面的算式壓縮回顧間隔；另一條是把到期日對齊既有的回顧節奏（例外期限一律訂成回顧週期的整數倍，讓到期日永遠落在會議之前）。第二條的維護成本低，代價是例外期限失去彈性——而在受外部稽核的環境裡代價會反轉：把三十天的例外拉長到九十天以配合季度會議，等於為了行政節奏延長風險窗口，而這個決定的理由要寫得出來。

另一類節奏由變化速率決定

另一類節奏由依賴對象的變化速率決定，跟到期日無關。

偵測規則的誤報率隨部署頻率漂移——部署越頻繁，規則越快跟不上系統的實際形狀——所以規則檢視的節奏綁部署節奏而不綁月曆，生命週期見 7.B5 Detection Engineering Lifecycle。

演練有三個各自獨立的驅動因子，混在一起會導出錯誤的行動。要揭露 runbook 缺陷這個產出由 runbook 的變更與人員流動驅動，兩者都沒有變動的期間，重跑同一個演練在這一項上的邊際資訊接近零。另兩個產出不受此限：人員的熟練度隨時間衰退，不需要任何變動就會衰退；環境漂移是 runbook 沒改而它依賴的系統改了，這一項與偵測規則同源、綁變化速率。所以「這段期間沒有變動」只能推出「不必為了查 runbook 而重跑」，推不出停辦演練。演練本身的設計見 7.19 資安演練。

每個節奏動作要有能執行的人與能否決的人

節奏存在而動作沒有承接者時，會議照開、產出照列，而同一個項目在每一輪被重新討論。Ownership 的最小要求是每個改進項目掛一個具名的人，不是掛一個團隊。

角色的分法要能回答一個具體問題：例外關不掉的時候，誰有權延期、誰有權要求關閉。7.17 的例外協議 要求業務 owner 與技術 owner 兩個角色，理由在這一題上顯現——兩個角色由同一個人擔任時，延期沒有阻力，而延期是治理物件的預設漂移方向（延期的成本在未來、關閉的成本在當下）。

兩個角色不一定都在組織內部，也不一定都存在。權力在甲方或監理機關那一側時，本地能掛的是「誰負責去要那個決定」而不是決定本身，而節奏要為那段往返留出時間——節奏算式裡的前置期就是它的量化形式。團隊小到兩個角色只能由同一人擔任時，替代的阻力要換成機制而不是人：把例外設成到期自動失效（過期即回退到未放行狀態），讓延期需要一個動作、而不是讓關閉需要一個動作。

角色名稱因組織而異，要對位的是「這件事在誰的目標裡」。節奏動作落在沒有人的目標裡時，它的優先序低於有目標的工作，而會議紀錄上看不出這件事——紀錄上它有一個負責人。

指標要能回答能力有沒有前進，而每個指標要標分母

指標分兩類，混用會讓儀表板長期健康而能力不動。活動指標數的是做了多少（這一輪處理了幾件、開了幾次會），能力指標數的是同類問題的復發間隔與處置成本（同一類事件第二次出現隔了多久、MTTR 的趨勢、改進項目的關閉率）。成熟度提升要看的是後者。

每個指標要標分母的來源，而分母的來源決定它承載什麼。例外關閉率的分母是登記過的例外，它衡量的是登記過的那批有沒有關——沒登記的例外不在分母裡，所以這個數字可以長期接近滿分而與治理品質無關。這與 7.5 憑證輪替完成率 的形態相同，機制見 覆蓋率與完成率。判讀的問法是「這個數字是從哪裡數出來的」，答案是某個工具或某張登記表時，要另外找一份獨立來源估分母。

誤報率（一段時間內判定為非事件的告警數除以告警總數）有另一種失真：它可以靠關掉噪音大的規則來改善，而被關掉的規則涵蓋的攻擊路徑不會出現在任何指標上。所以這一項要跟偵測覆蓋率一起讀，覆蓋率的定義見 7.13 偵測覆蓋率與訊號治理；誤報累積到讓值班者停止相信告警的那個失敗模式另有專卡（alert fatigue），它處理的是後果而不是這裡的指標定義。

回顧要產出能被下一輪驗收的項目

回顧的產出是改進項目，而每個項目要有完成時限，且時限要落在下一輪回顧之前——時限晚於下一輪時，驗收沒有發生的位置，項目會以「進行中」的狀態跨越任意多輪。改進項目本來就在節奏算式的那個集合裡，所以這條要求跟間隔的算法是同一條：回顧是它們到期前的最後一道攔截。

觀察面沿用 7.20 的四個評估維度（流程穩定性、證據品質、回寫節奏、自動化覆蓋），每輪對其中一個維度做判讀而不是全部——四個維度同時推進時，每個都拿到不足以改變狀態的投入。哪個維度優先由當前階段決定，路線圖在 7.20。證據品質那一維的主要產出是放行證據，判準見 7.22 資安風險如何進入 Release Gate——階梯走到可稽核閉環時，這一維的驗收就落在那道關卡上。

事故後的回顧另有一套流程與產出（post-incident review），它是事件驅動的，與本章的時間驅動回顧並存：前者處理單一事件的責任鏈與改進項，後者處理跨事件的能力趨勢。兩者的改進項目進同一份清單，否則會出現兩份互不知道的待辦。

判讀訊號與下一步

判讀訊號代表的缺口下一步
風險判讀依賴少數人的經驗，沒有固定的承接流程階段判讀本身還沒做，節奏無從掛先用 7.20 的成熟度階梯 判出當前階段與最有回報的提升項，triage 流程見 7.B6
指標每輪都在收，而同類問題的復發間隔沒有變長收的是活動指標，能力指標缺席依本章的指標段換成復發間隔、MTTR 與改進項目關閉率，並為每個指標標分母來源
例外的數量長期累積，關閉的那幾筆多半是到期後補登記回顧間隔長於例外期限，到期在兩次回顧之間發生依本章的節奏段重算間隔，或把例外期限對齊回顧週期；短窗口的高風險例外單獨掛 tripwire，協議見 7.17
回顧產出的改進項目跨越多輪仍是進行中完成時限晚於下一輪回顧，驗收沒有發生的位置把時限壓進下一輪之前，並確認每個項目掛的是具名的人而不是團隊，ownership 的最小要求
事故復盤的改進項與定期回顧的改進項各自有一份清單兩條回顧路徑的產出沒有合流，兩邊都以為對方在追併成同一份清單，事故側的流程與產出見 7.24 資安事故如何回寫產品與架構

驗收條件

節奏失效時流程不會停下來：會議照開、指標照收、項目照列，而能力有沒有前進沒有人判斷得出來。要讓這個狀態可被發現，驗收沿依賴序往下走。

最上游是集合列得出來——列不出來時後面每一項都沒有輸入，而空集合本身是合格的答案。集合成立之後間隔才算得出來，指得出它是由哪一個項目的真正截止日與哪一個 n 決定的（「習慣上每季一次」不是答案），而扣除掉的 tripwire 項目要指得出它的存活性檢查在哪。間隔成立之後改進項目才有意義：每一項掛得到具名的人、時限落在下一輪之前。指標那一層獨立於前三項，驗收是每個指標指得出分母從哪裡數出來。

這個順序有操作意義——從中間開始補的團隊會先訂會議頻率，再回頭發現集合裡有項目趕不上那個頻率，而那時頻率已經寫進行事曆。

必連章節