# Change Management Policy and Procedures ## Description Policy and procedures for controlling production change through GRCITSM Change Requests: the significant-change taxonomy and evaluation at raise, the six-stage workflow with Change Request Approvers CAB approval, the Security Impact Analysis verified at approval, SCN transmission and dual-format artifacts served through the Trust Center, emergency changes, and the KSI validation evidence the workflow generates. Client-agnostic template covering CMMC L2, FedRAMP Rev5, and FedRAMP 20x. ## Resolution # Change Management Policy and Procedures ## Purpose This document establishes the organization's policy for tracking, reviewing, approving, implementing, and validating changes to the system, and the procedures by which GRCITSM executes that policy. It covers the Change Request record and its structured field set, the FedRAMP significant-change taxonomy and the evaluation that assigns it, the six-stage change workflow and the Change Request Approvers CAB approval at its second stage, the Security Impact Analysis, Significant Change Notification transmission and artifacts, remediation traceability into vulnerability Issues, emergency changes, unauthorized changes and drift, and the machine validation evidence the workflow generates. It implements the FedRAMP Significant Change Notification (SCN) rule family from the FedRAMP Consolidated Rules for 2026 and the Change Management Key Security Indicators (KSI-CMT), with CMMC Level 2 and NIST 800-53 configuration change control lineage. ## Framework applicability | Framework | What this document satisfies | |---|---| | FedRAMP 20x (all classes) | SCN provider rules (SCN-CSO, SCN-RTR, SCN-ADP, SCN-TRF); KSI-CMT-LMC, KSI-CMT-RMV, KSI-CMT-RVP, KSI-CMT-VTD | | FedRAMP Rev5 | The same SCN provider rules; underlying NIST CM-2, CM-3, CM-4, CM-5, CM-6, CM-8, CM-9, SA-10, with CA-7 touchpoints. At Low, CM-3 is not in the baseline and the Change Request workflow applies as good practice | | CMMC Level 2 | CM.L2-3.4.3 (track, review, approve or disapprove, log changes), CM.L2-3.4.4 (security impact analysis), CM.L2-3.4.5 (access restrictions for change) | FedRAMP 20x classes differ in validation depth, not in the procedure itself: Class B should evidence each KSI with at least one automated method, Class C must use at least two, and Class D at least four. Class A follows its alternative-framework path and minimally carries KSI-CMT-LMC. The SCN provider rules apply to Classes B, C, and D. ## Policy - **P-1. Every change is a Change Request.** No change reaches production outside a Change Request ticket in GRCITSM. The ticket is the system of record: change type, justification, impact, risk, plans, approvals, and timestamps live on it, and its audit trail is the change log (KSI-CMT-LMC). - **P-2. Every potential significant change is evaluated and classified when it is raised.** The evaluation determines the significant-change type and the SCN rules that follow from it (SCN-CSO-EVA, MUST). The evaluation is recorded on the Change Request as Change Type, Change Type Explanation, and Justification, and those records are auditable and available to FedRAMP on request (SCN-CSO-MAR, MUST). - **P-3. A Security Impact Analysis is mandatory where FedRAMP requires one, and the CAB verifies it.** SCN-triggering changes carry a Security Impact Analysis on the Change Request, because a copy of the business or security impact analysis is required information in every Significant Change Notification (SCN-CSO-INF, MUST), with Rev5 CM-4 and CM.L2-3.4.4 lineage on that track. The Change Request Approvers CAB verifies that the Security Impact Analysis and the test plan are present and adequate as part of approving the change. Verification is a human act at approval; no automated control blocks the workflow. - **P-4. No change is implemented without recorded approval.** Approval runs as the native approval process at stage 2 of the workflow, decided by the Change Request Approvers CAB. Rejection returns the Change Request to Draft with the reason recorded. Approval is event-driven per change so notification clocks and change windows are met, and does not wait for a scheduled meeting. - **P-5. Notification is on the clock and reaches all necessary parties.** Adaptive changes are notified within 10 business days after finishing (SCN-ADP-NTF, MUST). Transformative changes are notified on the 30 / 10 / 5 / 5 business-day ladder (SCN-TRF-NIP, SCN-TRF-NFP, SCN-TRF-NAF, SCN-TRF-NAV, each MUST), with service documentation updated within 30 business days after finishing (SCN-TRF-UPD, MUST). Routine recurring changes are exempt and no formal notification is sent for them (SCN-RTR-NNR, SHOULD NOT). All necessary parties always includes FedRAMP and every agency customer using the offering. - **P-6. A certification class change cannot proceed under the SCN rules.** A change likely to change the FedRAMP Certification class of the offering requires a new assessment and is out of scope for significant-change handling (SCN-CSO-EVA, MUST). Such changes are raised so the evaluation is on record, and are not implemented under this procedure. - **P-7. Every notification and audit record exists in both human-readable and JSON form.** All Significant Change Notifications and their related audit records are available in human-readable and JSON formats (SCN-CSO-HRM, MUST). The organization generates and keeps both formats for **every** Change Request, not only for SCN-triggering ones, so the machine-readable trail is complete rather than selective. That breadth is an internal commitment beyond the rule. - **P-8. Change history stays available.** Twelve months of historical Significant Change Notifications remain available with the organization's FedRAMP Certification Data (SCN-CSO-HIS, MUST). All Change Request tickets are retained indefinitely, which satisfies that availability requirement by a wide margin. - **P-9. Emergencies may move first, and the paperwork follows.** During an emergency or incident, a change including a transformative one may execute without following the SCN rules in advance; the organization then follows all relevant procedures, notifies all necessary parties, retroactively provides all SCN materials, and completes an appropriate assessment after the incident (SCN-CSO-EMG). Emergency handling is documented policy and procedure, not automation. - **P-10. Changes land as redeploys, not edits.** Changes to machine-based information resources are executed by redeploying version-controlled resources rather than by direct modification wherever reasonable (KSI-CMT-RMV): infrastructure as code, pipelines with enforced review, and immutable redeploys. - **P-11. Testing and validation run throughout deployment and are automated.** Every change carries a test plan and a backout plan, and validation runs through deployment rather than only at its end (KSI-CMT-VTD). - **P-12. The procedure reviews itself persistently.** The effectiveness of these documented change management procedures is reviewed persistently on the cadence in the ODV table, together with the change metrics (KSI-CMT-RVP). ## Organization-defined values | Value | Setting | Default | Force | |---|---|---|---| | Change Request Approvers CAB membership | [CAB membership] | Members hold the `Approver - Change Requests` role | N/A | | Security and privacy representative on the change control body | [Name or role] | ISSO (required at Rev5 Moderate, CM-3(4)) | N/A | | Approval model and CAB oversight cadence | [event-driven approval plus oversight meeting frequency] | Event-driven approval per Change Request; CAB meets monthly for oversight | N/A | | Change record retention | [period] | Indefinite (GRCITSM default) | N/A | | Historical Significant Change Notification availability | 12 months with the FedRAMP Certification Data | 12 months (SCN-CSO-HIS) | MUST | | Notification mechanism | [mechanism] | Trust Center serving surfaces, documented in the FedRAMP Certification Package (SCN-CSO-NOM) | MAY | | Adaptive change notification | Within 10 business days after finishing | 10 business days (SCN-ADP-NTF) | MUST | | Transformative change, initial plans | At least 30 business days before starting | 30 business days (SCN-TRF-NIP) | MUST | | Transformative change, final plans | At least 10 business days before starting | 10 business days (SCN-TRF-NFP) | MUST | | Transformative change, after finishing | Within 5 business days after finishing | 5 business days (SCN-TRF-NAF) | MUST | | Transformative change, after verification | Within 5 business days after completing verification, assessment, or validation | 5 business days (SCN-TRF-NAV) | MUST | | Transformative change, service documentation update | Within 30 business days after finishing | 30 business days (SCN-TRF-UPD) | MUST | | Third-party assessor review before transformative changes | [when human validation of scope and impact is necessary] | Engage an assessor where human validation is necessary, limited to security decisions requiring it (SCN-TRF-TPR) | SHOULD | | Routine recurring change notification | None | Exempt from notification (SCN-RTR-NNR) | SHOULD NOT | | Emergency change approver | [ISSO or System Owner] | ISSO or System Owner | N/A | | Retroactive Change Request after an emergency change | [1 business day] | 1 business day (internal commitment; the rules set no numeric clock) | N/A | | Post-incident review after an emergency change | [48 hours] | 48 hours (internal commitment; the rules set no numeric clock) | N/A | | Change windows | [approved windows] | Defined per system | N/A | | Configuration settings source | [DoD STIGs, CIS Level 2, or documented custom baseline] | STIGs, else CIS Level 2, else custom (CM-6) | N/A | | Change procedure effectiveness review | [cadence] | Persistently, reviewed at least quarterly with the change metrics (KSI-CMT-RVP) | N/A | | CMMC change management values | [per contract] | Per contract (CM.L2-3.4.3, CM.L2-3.4.4, CM.L2-3.4.5) | N/A | ## Roles and responsibilities - **Anyone** may raise a Change Request. - **Assigned agent (Change Requests).** Each Change Request is assigned a tracking owner automatically via the `Agent Assignment - Change Requests` role. Assignment confers tracking ownership, not approval authority. - **Change Request Approvers CAB.** The `Approver - Change Requests` role grants membership to the Change Request Approvers CAB, who approve Change Requests. Approval is always by the CAB, never by the assigned agent. The CAB verifies the Security Impact Analysis and the test plan as part of approving the change, and records its decision and rationale on the Change Request. - **Implementers (system administrators, engineers).** Raise Change Requests, implement approved changes inside approved windows, execute test and backout plans, record results, and update affected documentation. - **ISSO and System Owner.** Accountability and escalation. Either may give expedited approval for an emergency change. The ISSO oversees the significance evaluation and reviews this document on the cadence in the ODV table; the System Owner gives final approval and authorizes exceptions. ## The Change Request record Every Change Request carries the following structured fields, which together supply the Significant Change Notification required-information set (SCN-CSO-INF): | Field group | Fields | |---|---| | Classification | Change Type, Change Type Explanation, Justification | | Assessment | Impact, Customer Impact, Risk, Security Impact Analysis | | Plans | Change Plan, Test Plan, Implementation Plan, Backout Plan, Communication Plan | | Scheduling | Downtime Required, Downtime Duration, change window | | Scope | Affected assets, and the vulnerability Issues the change remediates | The record also carries its approval decision and approver identity, the implementation and validation results, before and after states, and the full workflow timeline. ## Change classification Every Change Request carries a Change Type aligned to the FedRAMP significant-change taxonomy. Legacy Standard, Normal, and Emergency classifications map as shown. | Change Type (CR field) | Definition | Legacy mapping | SCN obligation | |---|---|---|---| | Routine Recurring | Regularly and routinely recurs as part of ongoing operations, vulnerability mitigation, or vulnerability remediation: routine patching, signature updates, capacity scaling, firewall rule updates, like-for-like remediation | Standard | None. No formal Significant Change Notification is sent (SCN-RTR-NNR, SHOULD NOT) | | Adaptive | Does not routinely recur and does not introduce substantive potential security risks needing in-depth assessment: OS or container upgrades with breaking changes, like-for-like component or crypto module swaps, multi-week feature deployments | Normal | Notify all necessary parties within 10 business days after finishing, including a summary of any new risks or vulnerabilities resulting from the change (SCN-ADP-NTF, MUST) | | Transformative | Introduces substantive potential security risks likely to affect existing risk determinations, which must be assessed in depth: IaaS or critical third-party swap, management-plane paradigm shift, cross-boundary data migration, new AI capability touching federal data differently | Normal (major) | Notify initial plans at least 30 business days before starting, final plans at least 10 business days before starting, within 5 business days after finishing, and within 5 business days after completing verification (SCN-TRF-NIP, NFP, NAF, NAV, each MUST); update service documentation within 30 business days after finishing (SCN-TRF-UPD, MUST); engage a third-party assessor before starting where human validation is necessary (SCN-TRF-TPR, SHOULD) | | Certification Class Change | Likely to change the FedRAMP Certification class of the entire offering, for example Class B to Class C | n/a | Cannot proceed under the SCN rules; requires a new assessment (SCN-CSO-EVA, MUST) | | Impact Categorization | **Legacy.** Retained so historical Change Requests keep their original classification. Not used for new changes; classify a class change as Certification Class Change | n/a | Not used for new changes: cannot proceed under the SCN rules (SCN-CSO-EVA, MUST) | | Interim Requirement | Executed to adopt a FedRAMP interim requirement on its adoption timeline | n/a | Per the interim requirement's own terms | | Emergency | Immediate action for an active incident, outage, or exploited vulnerability | Emergency | May proceed without following the SCN rules in advance; retroactive SCN materials and post-incident assessment are required (SCN-CSO-EMG) | Advance FedRAMP approval is not the default for any change type. It applies only where FedRAMP has imposed it as a condition of a formal Corrective Action Plan or other agreement (SCN-FRP-CAP, MAY). ## Change Request workflow The workflow has six stages. Ticket status derives from the stage, so the chevron a reader sees on the ticket is the stage the change is in. | Stage | Ticket status | Actions available | |---|---|---| | 1. Start - Change Initiated | Draft | Request Approval; Cancel Change (closes the Change Request) | | 2. Change Approval | Approval | Approval Process Approved (advances to Awaiting Implementation); Approval Process Rejected (returns to Draft) | | 3. Awaiting Implementation | Scheduling | Initiate Change; Reschedule Change; Cancel Change | | 4. Change Review | Implementation | Complete Change | | 5. Review | Review | Complete Change; Close Child Tickets | | 6. Closed | Complete | Terminal | The procedure runs across those stages as follows. 1. **Raise (stage 1).** The requester opens a Change Request with the field set above, classifies the change per the taxonomy, records the Change Type Explanation and Justification as the significance evaluation (SCN-CSO-EVA, SCN-CSO-MAR), and attaches the Security Impact Analysis where the change is SCN-triggering. Patch-window Change Requests parent the vulnerability Issues they remediate. 2. **Approve (stage 2).** Request Approval routes the change to the Change Request Approvers CAB. The CAB reviews the classification, the Security Impact Analysis, and the test plan, and approves or rejects. Rejection returns the Change Request to Draft with the reason recorded, and the change does not proceed. Transformative changes are the ones most likely to need a third-party assessor review of scope and impact before starting (SCN-TRF-TPR). 3. **Schedule (stage 3).** Approved changes wait in Scheduling until their window. Initiate Change starts implementation; Reschedule Change moves the window; Cancel Change stops the change with the record intact. 4. **Implement (stage 4).** Implementation runs inside the approved window, as a redeploy of version-controlled resources wherever reasonable (KSI-CMT-RMV). Before and after states are captured on the Change Request. A failed change executes its backout plan. 5. **Review (stage 5).** Test and validation results are recorded against the test plan (KSI-CMT-VTD): pipeline gates, post-deploy checks, and re-scan or targeted verification that the change met its objective and that security controls still operate as intended. Close Child Tickets may close the Change Request's children alongside it. 6. **Close (stage 6).** The Change Request reaches Complete. For SCN-triggering changes, the notification clocks that run after finishing and after verification are tracked from here. ## Significant Change Notification When a change is Adaptive or Transformative, the organization notifies all necessary parties, which always includes FedRAMP and every agency customer using the offering, on the clocks in the classification table. Each notification includes at minimum (SCN-CSO-INF): the FedRAMP ID of the service offering, the assessor name if applicable, the related vulnerability if applicable, the significant-change type with an explanation of the categorization, a short description of the change, the reason for the change, a summary of customer impact including changes to services and customer configuration responsibilities, the plan and timeline for the change including verification, assessment, or validation of impacted KSIs or Rev5 controls, a copy of the business or security impact analysis, and the name and title of the approver. Adaptive notifications additionally include a summary of any new risks or vulnerabilities resulting from the change where applicable (SCN-ADP-NTF). Transformative notifications carry embedded content requirements at every step: initial plans include a summary of any likely security impacts or changes in risk (SCN-TRF-NIP); final plans and after-finishing notifications include updates to all previously sent information (SCN-TRF-NFP, SCN-TRF-NAF); and notifications after verification additionally include updates to all previously sent information, that same new-risk summary, and a copy of the security assessment report where applicable (SCN-TRF-NAV). Additional relevant information may be included at the organization's discretion (SCN-CSO-ARI, MAY). **Transmission is a human act.** A person transmits each Significant Change Notification based on the details recorded on the Change Request, working to the SCN clocks. The Change Request is the record and the content source; no transmission automation is claimed. **Artifacts.** Human-readable and machine-readable (JSON) artifacts are generated and kept for every Change Request, not only for SCN-triggering ones (SCN-CSO-HRM, exceeded by internal commitment). They are served through the Trust Center on two surfaces: - the **Significant Changes (Agency)** report, one row per notifiable Change Request in the SCN-CSO-INF shape, in the agency report catalog; and - the **Certification Documents** section, which serves the FedRAMP-schema JSON artifacts. The Security Decision Record, Certification Overview, and Vulnerability Detail JSONs are published there today, and the Significant Change JSON is planned to be published alongside them. The notification mechanism is documented in the FedRAMP Certification Package as part of adopting this policy, and is easily accessible (SCN-CSO-NOM). After a significant change completes, the SSP (Rev5) or the Security Decision Record (20x) is regenerated so published certification data reflects the implemented state. ## Remediation traceability Patch-window Change Requests parent the vulnerability Issues they remediate, so the remediation trail runs from finding to change without a manual join. Stage 5's Close Child Tickets action can close those children alongside the Change Request. A Change Request may close without remediating everything it was raised to address. Unremediated child Issues stay open on their own lifecycle and close on scan evidence that the finding is gone, not on change completion. Vulnerability handling itself follows the Vulnerability Detection, Evaluation, and Response Policy and Procedures. ## Emergency changes Emergency changes, including transformative ones, may execute ahead of a window and without advance notification during an active incident, outage, or exploited vulnerability (SCN-CSO-EMG). This is a documented procedure carried out by people, not an automated path. 1. The implementer obtains expedited approval from the **ISSO or the System Owner**. 2. The implementer files a retroactive Change Request within [1 business day] carrying the full field set, including the Security Impact Analysis performed as rapidly as the incident allowed. 3. The organization provides all retroactive Significant Change Notification materials to all necessary parties and completes an appropriate assessment of the change. 4. A post-incident review completes within [48 hours], recording lessons learned and any permanent-fix plan on the Change Request. The 1-business-day and 48-hour values are organization-defined internal commitments. The SCN rules set no numeric clock for either. ## Unauthorized changes and drift The approved infrastructure-as-code baseline is the reference state. Drift from it is treated as an unauthorized change: detected by automated configuration evaluation, investigated, and either reverted or regularized through a retroactive Change Request. Logical access to make production changes is restricted and enforced with automated audit records; physical access restrictions are inherited from the infrastructure provider (CM-5, CM.L2-3.4.5). ## Documentation and certification data changes Documentation (policies, procedures, plans, diagrams, this article) is version controlled with review and approval before merge, and the change history is the audit trail. Documentation changes that affect the FedRAMP Certification Package or SSP content run through the same significance evaluation as technical changes. After transformative changes, service documentation such as user guides and marketplace listing information is updated within 30 business days after finishing (SCN-TRF-UPD). Technical Change Requests identify the documentation they affect, and the documentation change references the Change Request. ## Recurring reviews | Review | Cadence | Source | |---|---|---| | Privileges to change production | At least quarterly | CM-5(5) | | Component inventory | At least monthly, and on change | CM-8 | | Baseline configuration | At least annually and on significant change | CM-2 | | Configuration compliance scans | At least monthly | CA-7 / CM-6 | | Effectiveness of these change procedures | Persistently, reviewed at least quarterly with the change metrics | KSI-CMT-RVP | | Change management audit (sampled Change Requests, Security Impact Analysis completion, decision records, implementation-matches-approval) | Annually | CM-3; CA-7 | ## Automated validation evidence Operating this process produces machine validation evidence automatically. A deployed event runbook fires when a Change Request is logged and on every subsequent ticket update. For each Change Management KSI carried on the Change Request it ensures a per-KSI Validation record exists under that KSI's validation parent, writes one dated validation run, and sets the record's status to Satisfied or Not Satisfied. Each validation run records the validation method as Automated, the validation identifier `CR-WORKFLOW`, the evidence type as an audit record, the timestamp, and a note naming the source Change Request number, its category, its current status, and whether the Security Impact Analysis and Test Plan fields carry content. The pass and fail conditions as deployed: | KSI | Fails when | Notes | |---|---|---| | KSI-CMT-LMC (Logging Changes) | Never | The Change Request record is itself the log, so any Change Request satisfies it | | KSI-CMT-VTD (Validating Throughout Deployment) | The Change Request has reached an implemented-terminal status and either the Test Plan or the Security Impact Analysis field is blank | | | KSI-CMT-RVP (Reviewing Change Procedures) | The Change Request has reached an implemented-terminal status and the Security Impact Analysis field is blank | | | KSI-SVC-EIS, KSI-SVC-ACM, KSI-CNA-DFP | Same condition as KSI-CMT-RVP | Written only when the Change Request carries these KSIs | Every other state passes, including rejection: a rejected Change Request evidences that the review procedure worked. **This runbook generates evidence. It does not enforce anything.** No automated control blocks approval, implementation, or closure of a Change Request whose Security Impact Analysis or test plan is missing. Enforcement is human: the Change Request Approvers CAB verifies both as a condition of approval (P-3). A missing artifact therefore surfaces as failed validation evidence after the fact, not as a blocked workflow. KSI-CMT-RMV is evidenced separately, by the pipeline and drift-detection records showing changes landing as version-controlled redeploys. Validation results accumulate as append-only pass and fail history and roll up to the KSI reporting used for continuous monitoring and certification data sharing. ## Records, retention, and metrics The Change Request audit trail retains, per change: identifier, requester and timestamps, description and justification, change type and significance evaluation, affected assets, Security Impact Analysis, approval decision and rationale, implementation and validation results, before and after states, and any backout. **All Change Request tickets are retained indefinitely.** Significant Change Notification records additionally follow the 12-month availability rule alongside the FedRAMP Certification Data (SCN-CSO-HIS). Monthly metrics: changes by type, success rate versus backouts, approval latency, emergency-change count and justification, Significant Change Notifications sent by type with clock adherence, validation pass rate, and unauthorized-change (drift) findings. ## Authority, review, and revision Issued under the authority of the System Owner and binding on all personnel with access to the system. Exceptions require written System Owner approval and are documented. The ISSO reviews this document for effectiveness persistently on the cadence in the ODV table, and when frameworks, the system, or lessons learned warrant; the System Owner gives final approval. This review, together with the change metrics, evidences persistent review of documented change management procedure effectiveness (KSI-CMT-RVP). ## FedRAMP coverage SCN provider rules: Evaluate Changes (MUST), Maintain Audit Records (MUST), Required Information (MUST), Historical Notifications (MUST), Human and Machine-Readable Notifications (MUST), Notification Mechanisms (MAY), Additional Relevant Information (MAY), Emergency Changes (MAY, with embedded MUSTs) (SCN-CSO); No Notification Requirements for routine recurring changes (SCN-RTR-NNR, SHOULD NOT); Notification Requirements for adaptive changes (SCN-ADP-NTF, MUST); Notification of Initial Plans, Notification of Final Plans, Notification After Finishing, Notification After Verification, Update Documentation (each MUST) and Third-Party Review (SHOULD) for transformative changes (SCN-TRF). The FedRAMP-side rule that can impose advance approval is SCN-FRP-CAP (MAY). KSI-CMT: Logging Changes, Redeploying vs Modifying, Reviewing Change Procedures, Validating Throughout Deployment. Adjacent KSIs the Change Request workflow also evidences when carried on the record: KSI-SVC-EIS, KSI-SVC-ACM, KSI-CNA-DFP. Underlying NIST: CM-2, CM-3, CM-4, CM-5, CM-6, CM-8, CM-9, SA-10, CA-7. CMMC: CM.L2-3.4.3, CM.L2-3.4.4, CM.L2-3.4.5. ## Internal Memo Source: change-management-policy-and-procedures.md in the GRCITSM knowledge-base library (species: platform-procedure; editor_type 1 = markdown). Downloaded from the public GRC-ITSM documentation site; body carried verbatim from the library source. Paste the Resolution section as the article body (description_markdown) in your GRCITSM instance and apply the Tags list. ## Tags - GRCITSM Procedure - Change Management - FedRAMP Rev5 Class C - FedRAMP 20x Class C - KSI-CMT-LMC - KSI-CMT-RMV - KSI-CMT-RVP - KSI-CMT-VTD - SCN-CSO-ARI - SCN-CSO-EMG - SCN-CSO-EVA - SCN-CSO-HIS - SCN-CSO-HRM - SCN-CSO-INF - SCN-CSO-MAR - SCN-CSO-NOM - SCN-RTR-NNR - SCN-TRF-NAF - SCN-TRF-NAV - SCN-TRF-NFP - SCN-TRF-NIP - SCN-TRF-TPR - SCN-TRF-UPD - CM-02 - CM-03 - CM-04 - CM-05 - CM-06 - CM-08 - CM-09 - SA-10 - CA-07