# Continuous Monitoring and Reporting Policy and Procedures ## Description Policy and procedures for monitoring the system persistently between assessments through GRCITSM: the KSI validation tree with runs-only evidence at the check ticket and automatic rollup, the two automated evidence paths (in-boundary Powerpipe checks retrieved through a cross-account role, and the eight event-driven validation generators), the three cadence parents carrying recurring compliance tasks with per-child attribution, the weekly statistics tables and administrator trend views behind metrics over time, and the Ongoing Certification Report and Quarterly Review procedures. Client-agnostic template covering CMMC L2, FedRAMP Rev5, and FedRAMP 20x. ## Resolution # Continuous Monitoring and Reporting Policy and Procedures ## Purpose This document establishes the organization's policy for monitoring the security posture of the system persistently between assessments, and the procedures by which GRCITSM executes that policy. It covers the Key Security Indicator (KSI) validation tree and its run-level evidence, the two automated evidence paths that feed it, the recurring compliance tasks that carry non-machine validation, the statistics tables and dashboards that hold metrics over time, the Ongoing Certification Report and the Quarterly Review, and the security improvement program. It implements the FedRAMP Collaborative Continuous Monitoring (CCM) rule family from the FedRAMP Consolidated Rules for 2026, the FedRAMP Certification verification and validation rules (FRC-CSX), the machine and non-machine verification cadences (VDR-TFR), and the Monitoring, Logging, and Auditing Key Security Indicators (KSI-MLA), with CMMC Level 2 and NIST 800-53 continuous monitoring lineage. ## Framework applicability | Framework | What this document satisfies | |---|---| | FedRAMP 20x (Class C, primary) | CCM provider rules (CCM-OCR, CCM-QTR); FRC-CSX-VVK, FRC-CSX-MOT, FRC-CSX-VVR; VDR-TFR-MVX, VDR-TFR-NMV; SDR-CSX-KMT; KSI-MLA-ALA, KSI-MLA-EVC, KSI-MLA-LET, KSI-MLA-OSM, KSI-MLA-RVL; KSI-SVC-EIS | | FedRAMP Rev5 (Class C) | The same CCM provider rules; VDR-TFR-MVF in place of VDR-TFR-MVX; underlying NIST CA-2, CA-5, CA-7, AU-6, CM-8, and the recurring reviews in the task table below | | CMMC Level 2 | CA.L2-3.12.1 (periodically assess control effectiveness), CA.L2-3.12.3 (monitor controls on an ongoing basis) | FedRAMP 20x classes differ in validation depth, metric history, and machine cadence, 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 (FRC-CSX-VVK). Metric history runs at least 6 months at Class C and at least 18 months at Class D (FRC-CSX-MOT). Machine verification runs at least every 3 days at Class C and at least every 7 days at Class B on the 20x track (VDR-TFR-MVX), and at least monthly on Rev5 (VDR-TFR-MVF). The Quarterly Review is a MUST at Class C and Class D, a SHOULD at Class B, and a MAY at Class A (CCM-QTR-MTG). The Organization-Defined Values table carries the Class C values. --- ## Policy - **P-1. Every applicable KSI is a record.** Each system carries one KSI container and one Validation ticket per applicable KSI, scoped to the system's Certification Class. The tree is stood up by the `Create KSI Validation Tickets` runbook, so no KSI depends on a person remembering to create it. - **P-2. Every check is its own record, and every run is dated evidence.** Each concrete check is a child Validation ticket carrying the check definition. The Validations table at that check ticket holds validation **runs only**: method (Automated or Manual), pass and fail counts, status, note, and reference. Runs are written idempotently, so a re-run updates its own row rather than duplicating it, and per-check history is never merged into a rollup. - **P-3. Status rolls up, it is not asserted.** KSI status derives from its child checks automatically, by an on-child-update runbook and a scheduled sweep. Rollup states are Satisfied, Partially Satisfied, and Not Satisfied. A partially evidenced KSI reads as Partially Satisfied rather than being rounded in the organization's favor. - **P-4. Machine-based information resources are verified and validated persistently.** Automated checks run at least every 3 days on the 20x track at Class C (VDR-TFR-MVX, MUST) and at least monthly on Rev5 (VDR-TFR-MVF, MUST). The evidence pipeline runs on a schedule that meets those requirements, typically daily. - **P-5. Non-machine-based information resources are verified and validated at least every 3 months** (VDR-TFR-NMV, MUST). The recurring compliance tasks and manual attestations carry this validation. - **P-6. Every KSI carries at least two automated validation methods** (FRC-CSX-VVK, MUST at Class C): the scheduled machine checks and the event-driven validation generators. Manual attestation supplements them; it does not substitute for them. - **P-7. Evidence collection never reaches into the boundary from outside it.** The check container runs in-boundary and writes its results to storage that the authorized HaloGRC environment reads through a cross-account role. No boundary credentials are stored in HaloGRC, and nothing pushes from the boundary outward to a monitoring service. - **P-8. Pass and fail criteria are version controlled.** The check definitions live in a version-controlled Powerpipe mod. A change to what a check asserts is a reviewed code change with history, not an untracked edit to a dashboard. - **P-9. Failures of monitoring are vulnerabilities.** A failed check, a broken ingestion, or a stalled evidence pull is treated as a vulnerability and enters the vulnerability pipeline as an Issue on that pipeline's SLAs and deviation rules (VDR-CSO-FAV). Handling follows the Vulnerability Detection, Evaluation, and Response Policy and Procedures. - **P-10. Recurring compliance obligations are tracked as tickets with deadlines.** Each system carries three cadence parents (Annual, Quarterly, Monthly) with a system-generated child task ticket per obligation. Deadlines are SLA-tracked and notifications can be configured for overdue and breached tickets. Acting on a breach is a human responsibility; no automated escalation logic is claimed. - **P-11. Evidence is attributed where it lands.** Each child task carries whatever category fits the work, and the category drives the automatic attribution of controls, requirements, KSIs, FedRAMP rules, and CMMC practices to that ticket, scoped to the system's authorized baselines. Attribution is therefore per child, not inherited wholesale from the cadence parent. - **P-12. Metrics accumulate over time.** Scheduled statistics tables snapshot validation status and ticket activity weekly, and the dashboards graph that history. The organization supplies historical metrics including status from persistent validation over at least the past 6 months for all KSIs (FRC-CSX-MOT, MUST at Class C). - **P-13. The organization reports to all necessary parties every 3 months.** An Ongoing Certification Report covering the entire period since the previous summary is supplied every 3 months in a consistent, human-readable format (CCM-OCR-AVL, MUST), with the target date for the next report published alongside the other public FedRAMP Certification Data (CCM-OCR-NRD, MUST), an asynchronous feedback mechanism for each report (CCM-OCR-FBM, MUST), and an anonymized, desensitized summary of that feedback (CCM-OCR-AFS, MUST). All necessary parties always includes FedRAMP and every agency customer using the offering. - **P-14. Reporting and review disclose enough to decide, and no more.** The organization does not irresponsibly disclose sensitive information in an Ongoing Certification Report (CCM-OCR-LSI, MUST NOT) or in a Quarterly Review (CCM-QTR-NID, MUST NOT) that would likely have an adverse effect on the offering. - **P-15. A synchronous Quarterly Review is hosted every 3 months** at Class C, open to all necessary parties, covering the aspects of the most recent Ongoing Certification Reports the organization determines are of most relevance to agencies (CCM-QTR-MTG, MUST at Class C). Registration or calendar information is supplied to all necessary parties (CCM-QTR-REG, MUST), and the target date for the next review is published with the other public FedRAMP Certification Data (CCM-QTR-NRD, MUST). - **P-16. Security improvements are made persistently and evidenced.** Information resources are persistently evaluated for opportunities to improve security and those improvements are persistently made (KSI-SVC-EIS). A quarter with no improvement activity is recorded as an explicit validation failure, not as an absence of data. - **P-17. The procedure reviews itself persistently.** The ISSO reviews these procedures for effectiveness on the cadence in the ODV table, together with the monitoring metrics. --- ## Organization-defined values | Value | Setting | Default (Class C) | Force | |---|---|---|---| | Automated methods per KSI | At least 2 | 2 at Class C; 1 at Class B; 4 at Class D (FRC-CSX-VVK) | MUST | | Machine-based resource verification and validation | [cadence] | Every 3 days on 20x (VDR-TFR-MVX); every month on Rev5 (VDR-TFR-MVF) | MUST | | Evidence retrieval schedule | [schedule] | Typically daily, which meets the 3-day 20x Class C cadence | N/A | | Non-machine resource verification and validation | [cadence] | Every 3 months (VDR-TFR-NMV) | MUST | | Manual check cadence | [cadence] | At least quarterly, matching VDR-TFR-NMV | MUST | | KSI metric history supplied | [period] | At least the past 6 months at Class C; at least 18 months at Class D (FRC-CSX-MOT) | MUST | | Statistics table snapshot cadence | [cadence] | Weekly (internal setting; the rules set no snapshot cadence) | N/A | | Automated verification and validation of the Security Decision Record for FedRAMP rules | [scope] | Implemented where it fits the implementation (FRC-CSX-VVR) | SHOULD | | KSI metrics in the Security Decision Record | 30-day summaries, up-to-one-year summaries, and daily metric data where available | Per SDR-CSX-KMT at Class C | MUST | | Ongoing Certification Report cycle | Every 3 months, covering the entire period since the previous summary | Every 3 months (CCM-OCR-AVL) | MUST | | Ongoing Certification Report ordinal recurrence | [beginning, middle, or end of quarter] | A regular 3-month cycle spread out from the beginning, middle, or end of each quarter (CCM-OCR-SOR) | SHOULD | | Next Ongoing Certification Report target date | Published with the other public FedRAMP Certification Data | Published (CCM-OCR-NRD) | MUST | | Ongoing Certification Report feedback mechanism | [mechanism] | An asynchronous mechanism for all necessary parties, email by default (CCM-OCR-FBM) | MUST | | Anonymized feedback summary delivery | [addendum to the report, or the next report] | Addendum, kept current through the quarter (CCM-OCR-AFS) | MUST | | Public sharing of Ongoing Certification Report content | [scope, if any] | Shared only where the organization determines no likely adverse effect (CCM-OCR-RPS) | MAY | | Quarterly Review cadence | Every 3 months, open to all necessary parties | Every 3 months (CCM-QTR-MTG) | MUST at Class C | | Quarterly Review registration information | [registration link or calendar file] | Registration link or downloadable calendar file (CCM-QTR-REG) | MUST | | Next Quarterly Review target date | Published with the other public FedRAMP Certification Data | Published (CCM-QTR-NRD) | MUST | | Quarterly Review scheduling relative to the report | [business days after release] | At least 3 and within 10 business days after releasing the Ongoing Certification Report (CCM-QTR-SAR) | SHOULD | | Security improvement cadence sweep | [cadence] | Quarterly; an empty quarter is an explicit validation failure (internal setting supporting KSI-SVC-EIS) | N/A | | Monitoring procedure effectiveness review | [cadence] | Persistently, reviewed at least quarterly with the monitoring metrics | N/A | | CMMC continuous monitoring values | [per contract] | Per contract (CA.L2-3.12.1, CA.L2-3.12.3) | N/A | --- ## Roles and responsibilities - **Continuous Monitoring team.** Owns the recurring compliance tasks. Each child task ticket is assigned a tracking owner automatically via the `Agent Assignment - Data Requests` role, and the instruction for the task lives in the ticket body. - **Validation owners.** Each Validation ticket is assigned a tracking owner automatically via the `Agent Assignment - Validations` role. Assignment confers tracking ownership of the check and its runs. - **Implementers (system administrators, engineers).** Perform the tasks, record results on the ticket, maintain the Powerpipe mod and the evidence pipeline, and raise Issues when a check or an ingestion fails. - **ISSO and System Owner.** Accountability and escalation. The ISSO owns the recurring reviews, signs the Ongoing Certification Report before delivery, and reviews this document on the cadence in the ODV table; the System Owner gives final approval and authorizes exceptions. --- ## The KSI validation tree The tree has three record levels, and the level a record sits at determines what it holds. ```mermaid flowchart TD A["KSI container
one per system"] --> B["Validation ticket
one per applicable KSI
status rolls up"] B --> C["Validation ticket
one per concrete check
check definition on the ticket"] C --> D["Validations table
runs only: dated, method,
pass and fail counts, status, note, reference"] ``` | Level | Record | What it carries | |---|---|---| | System | KSI container | One container per system, holding that system's KSI set | | KSI | Validation ticket, one per applicable KSI | The KSI identifier and name verbatim, the owner, and the rolled-up status. Class-aware: the applicable set follows the system's Certification Class | | Check | Validation ticket, one per concrete check | The check definition, as columns on the ticket itself | | Run | Row in the Validations table at the check ticket | Date, method (Automated or Manual), pass and fail counts, status, note, and reference | Three properties of this shape matter for evidence integrity. 1. **The Validations table lives at the check ticket, and it holds runs only.** What a check asserts is on the ticket; the table is the run history. A reader of any check ticket sees the criterion and every dated run against it in one place. 2. **Runs are idempotent.** A repeated run updates its own row rather than appending a duplicate, so run counts reflect distinct validation events. 3. **Rollup is automatic and admits partial coverage.** An on-child-update runbook and a scheduled sweep both maintain KSI status, and the rollup can read Partially Satisfied. Partial evidence stays visible as partial rather than resolving to a pass or a fail. Automated checks run at least every 3 days (VDR-TFR-MVX at Class C on 20x; VDR-TFR-MVF monthly on Rev5). Manual checks run at least quarterly, matching the non-machine validation cadence (VDR-TFR-NMV). --- ## Automated evidence architecture Two automated paths feed the tree, which is how each KSI reaches the two automated validation methods Class C requires (FRC-CSX-VVK). Manual attestation is a third, supplementary path. ### Path A: scheduled machine checks The checks are a custom Stratus **Powerpipe mod**. Pass and fail criteria are coded as the mod's control definitions and version controlled, so the assertion behind every automated run is reviewable and has a change history. ```mermaid flowchart LR A["Powerpipe mod
version-controlled
pass and fail criteria"] --> B["Container image"] B --> C["Runs in-boundary
on ECS"] C --> D["Results written to S3
inside the boundary"] D --> E["Authorized HaloGRC environment
retrieves via cross-account role"] E --> F["Validation runs
on the check tickets"] ``` The container runs in-boundary on ECS and writes its results to S3. The authorized HaloGRC environment retrieves those results through a cross-account role on a schedule that meets the requirements, typically daily. Two properties follow from that direction of travel: no boundary credentials are stored in HaloGRC, and nothing pushes outward from the boundary to a monitoring service. !!! note "Why daily, when the rule says 3 days" VDR-TFR-MVX sets a floor of once every 3 days for machine-based information resources at 20x Class C. Retrieving daily clears that floor with margin and keeps the freshest evidence in front of reviewers. The daily schedule is an internal setting, not the rule. ### Path B: event-driven validation generators Operating the system produces evidence. Eight deployed generators write dated validation runs when the operational record they watch changes: | Generator | Writes evidence on | |---|---| | User Access Request | Access request decisions | | Change Request | Change Request logging and subsequent updates | | Vulnerability Deviation | Deviation approval outcomes | | Issue Remediation SLA | Remediation SLA outcomes on Issues | | Issue Evaluation Coverage | Coverage of open vulnerabilities by a completed evaluation | | Security Improvement Project Trigger | Status changes on security improvement Projects and their tasks | | Security Improvement Cadence Sweep | The scheduled improvement-cadence check | | Alert and Incident AAR | After Action Report completion | Each generator writes runs against the KSIs and FedRAMP rules its source record carries, so evidence lands on the obligations the work actually satisfies. Change Request evidence behavior is documented in the Change Management Policy and Procedures; After Action Report evidence behavior is documented in the Incident Response Policy and Procedures. ### Path C: manual attestation Checks that no automation can assert are validated by a named reviewer on the manual cadence, recorded as a run with method Manual, a note, and a reference to the evidence examined. Manual runs supplement the automated methods; they do not count toward the FRC-CSX-VVK automated-method minimum. ### Pipeline health Failures of the checks or of the ingestion surface as failed validation runs and open Issues on the vulnerability pipeline, on that pipeline's SLAs and deviation rules (P-9). Monitoring that has stopped working is therefore visible as a finding with a remediation clock rather than as a quiet gap in the run history. --- ## Recurring compliance tasks Each system carries **three cadence parents** as Data Request tickets: FedRAMP Annual, Quarterly, and Monthly Continuous Monitoring. Each parent is SLA-tracked and carries framework attribution at the program level. Under each parent, a **system-generated child task ticket** exists per obligation. Children are created by the system from the parent, pre-assigned through the Continuous Monitoring team and its agent assignment role, and carry the instruction for the task in the ticket body. **Child categories are whatever fits the task.** A training-records review sits in a training category, an inventory review in an inventory category. Because attribution is driven by category, the evidence of each task lands on the exact controls, requirements, KSIs, and rules that task satisfies rather than on a single blanket continuous monitoring mapping (P-11). The task sets in use: | Cadence | Tasks | Traceability | |---|---|---| | Annual | Independent assessment; penetration test; contingency plan functional exercise testing; contingency plan training; incident response plan testing; incident response training; general and role-based security trainings; security training records archive and review; plan and policy reviews (baseline configuration, configuration management plan, contingency plan, incident response plan, and reviewing and updating all information security policies and procedures); unsupported network traffic flow review; access agreements; account recertification | CA-2, CA-8, CP-4, IR-3, AT-4, the -1 control of each family, PS-6, AC-2 | | Quarterly | Developer and integrator privilege review; non-privileged account compliance review; public content review | CM-5(5), AC-2, AC-22 | | Monthly | Inventory and scan data review; privileged account compliance review; unnecessary functions and ports, protocols, and services review; security state report to organizational officials; POA&M update and submission | CM-8, RA-5, AC-6(7), CM-7(1), CA-7, CA-5 | Together these tasks carry the non-machine verification and validation the rules require at least every 3 months (VDR-TFR-NMV). Log review evidence for the KSI-MLA family comes from the monitoring integrations and scheduled checks alongside these tasks. !!! warning "Deadlines notify; they do not escalate by themselves" Task deadlines are SLA-tracked, and notifications **can be configured** for overdue and breached tickets. There is no built-in escalation logic. A missed deadline surfaces as a breached SLA and whatever notification has been configured; acting on it is a human responsibility owned by the Continuous Monitoring team and the ISSO. --- ## Metrics over time Two Halo-native **Statistics Tables** take scheduled **weekly** snapshots, each row timestamped for its period: | Statistics table | Content | |---|---| | `CTValidationMetrics` | Per-KSI, per-rule, and per-control validation status and counts, by system and baseline | | `CTTicketMetrics` | Open Issue, Change Request, Alert, and Incident counts by type, category, and status | Administrator dashboards graph that history: Validation Metrics Over Time, Ticket Metrics Over Time, a KSI status donut, and SLA, approval, and issues-due widgets. The accumulated validation history runs past the 6-month floor FRC-CSX-MOT sets at Class C. **Trend views are available to administrators today.** A Trust Center variant of the ticket-metrics-over-time report exists in the report catalog, but customer-facing publication of trend views is not live. Metrics reach customers today through the reports the organization delivers, not through a self-service trend view. **The Security Decision Record does not read the statistics tables.** Its KSI metrics build directly from the assets (Components, Implemented Requirements, and Implementation Statements) and their associated tickets. That is the source for what the record requires at Class C: a summary of each metric over the past 30 days, a summary up to the past year where available, and the daily metric data up to the past year where available (SDR-CSX-KMT, MUST). The statistics tables serve trending and the dashboards. --- ## Ongoing Certification Report The organization supplies an Ongoing Certification Report to all necessary parties every 3 months, covering the entire period since the previous summary, in a consistent human-readable format (CCM-OCR-AVL, MUST). The report carries high-level summaries of at least the following: - changes to FedRAMP Certification Data; - planned changes to FedRAMP Certification Data during at least the next 3 months; - accepted vulnerabilities; - transformative changes; - updated recommendations or best practices for security, configuration, usage, or similar aspects of the offering; - a list of all agencies directly using the product; - FedRAMP Reportable Incidents, or an attestation that no such incidents occurred; and - lessons learned and changes planned or made as a result of FedRAMP Reportable Incidents, where any occurred. ### Assembly **The source reports needed to produce the report are available in the report catalog.** Assembling the quarterly report from them is documented procedure carried out by a person; the report is not a single generated artifact today. | Source report | Supplies | |---|---| | Significant Changes | Changes to certification data, transformative changes | | Accepted Vulnerabilities | Accepted vulnerabilities with their acceptance rationale | | Reportable Incidents | FedRAMP Reportable Incidents, or the basis for an attestation that none occurred | | Historical Vulnerability Activity | Detection and response activity across the period | | Vulnerability Details, in its Agency, Automation, and MCP variants | Per-vulnerability detail at the disclosure level appropriate to the audience | | Validation and ticket metrics over time | Posture trend across the period | The ISSO reviews and signs the assembled report before delivery. ### Publication, feedback, and limits - **Next report date.** The target date for the next Ongoing Certification Report is published with the other public FedRAMP Certification Data (CCM-OCR-NRD, MUST). Publishing it is documented procedure. - **Feedback mechanism.** An asynchronous mechanism for all necessary parties to give feedback or ask questions about each report is supplied (CCM-OCR-FBM, MUST). Operating that channel per report is documented procedure. - **Anonymized feedback summary.** An anonymized and desensitized summary of the feedback, questions, and answers is supplied as an addendum to the report or in the next report (CCM-OCR-AFS, MUST). The organization keeps the addendum current through the quarter rather than only at report time. - **Report cycle.** The organization holds a regular 3-month cycle spread out from the beginning, middle, or end of the quarter rather than clustering with every other provider (CCM-OCR-SOR, SHOULD). - **Responsible disclosure.** The report does not irresponsibly disclose sensitive information that would likely have an adverse effect on the offering (CCM-OCR-LSI, MUST NOT). Report content may be supplied to the public or other parties only where the organization determines that doing so is not likely to have an adverse effect (CCM-OCR-RPS, MAY). --- ## Quarterly Review At Class C the organization must host a synchronous Quarterly Review every 3 months, open to all necessary parties, covering the aspects of the most recent Ongoing Certification Reports it determines are of most relevance to agencies (CCM-QTR-MTG, MUST at Class C; SHOULD at Class B; MAY at Class A). **This is a documented procedure that follows the requirements.** It is a commitment carried out by people on a calendar, not an automated practice. | Obligation | Commitment | Force | |---|---|---| | Host the review every 3 months, open to all necessary parties | Scheduled per the ODV table | MUST at Class C (CCM-QTR-MTG) | | Supply registration information | A registration link or a downloadable calendar file with meeting information, supplied to all necessary parties | MUST (CCM-QTR-REG) | | Publish the next review date | Target date published with the other public FedRAMP Certification Data | MUST (CCM-QTR-NRD) | | Limit disclosure | No irresponsible disclosure of sensitive information likely to have an adverse effect on the offering | MUST NOT (CCM-QTR-NID) | | Schedule around the report | Scheduled at least 3 business days after releasing the Ongoing Certification Report and within 10 business days of that release | SHOULD (CCM-QTR-SAR) | --- ## Security improvement Security improvements run as **Projects** in the `Security Improvement` category, with the `Security Improvement>Effectiveness Review` subcategory for effectiveness work, each broken into tasks. **The tasks can be anything.** Improvement work is typically driven by reviewing the metrics and digging into the trends the dashboards expose, and it is classified by category rather than by a fixed task taxonomy. The program is not limited to a predefined list of improvement types. Two runbooks turn that activity into evidence: - the **Security Improvement Project Trigger** writes dated validation evidence on status changes to an improvement Project or its tasks, evidencing that improvements are persistently made; and - the **Security Improvement Cadence Sweep** flags a quarter with no improvement activity as an explicit validation failure. Both target KSI-SVC-EIS. The design point is that an empty quarter produces a failed run rather than silence, so absence of improvement is visible in the same place as its presence. --- ## Automated validation evidence Operating this process produces machine validation evidence automatically, on the two automated paths above. Every run is dated, carries its method, and accumulates as pass and fail history on the check ticket that owns it. Rollups derive from those runs and never replace them. What the evidence supports, and what it does not: | Claim | Status | |---|---| | At least two automated validation methods for each KSI (FRC-CSX-VVK, MUST at Class C) | Evidenced by the scheduled Powerpipe checks plus the event-driven generators | | Machine-based resources verified and validated at least every 3 days on 20x (VDR-TFR-MVX, MUST) | Evidenced by the retrieval schedule, typically daily | | Non-machine resources verified and validated at least every 3 months (VDR-TFR-NMV, MUST) | Evidenced by the recurring compliance tasks and manual runs | | At least 6 months of KSI metric history (FRC-CSX-MOT, MUST at Class C) | Evidenced by the weekly statistics tables and the administrator dashboards | | Automated verification and validation of the Security Decision Record for FedRAMP rules (FRC-CSX-VVR, SHOULD) | Partially evidenced: the event-driven generators write runs against FedRAMP rules where the operational record carries them | | Ongoing Certification Report and Quarterly Review obligations (CCM-OCR, CCM-QTR) | Documented procedure, assembled from the available source reports. No generated report artifact and no automated meeting practice is claimed | **Validation generation writes evidence. It does not enforce anything.** No automated control blocks a missed task, a stale check, or an unassembled report. A gap surfaces as a failed validation run, a breached SLA, or an open Issue after the fact. Enforcement is human and sits with the Continuous Monitoring team and the ISSO. --- ## Records, retention, and metrics Per KSI, the record retains the KSI identifier and name, the owner, the rollup status and its history, every child check and its definition, and every dated run with method, pass and fail counts, status, note, and reference. Per recurring task, the record retains the task instruction, the assignee, the deadline and SLA outcome, the result recorded, and the attribution derived from its category. Validation and ticket snapshots are retained as timestamped statistics-table rows, which is what makes metric history available past the FRC-CSX-MOT floor. Monitoring metrics reviewed with these procedures: KSI rollup distribution and its movement, automated versus manual run mix per KSI, failed-run rate and time to a passing re-run, evidence pipeline freshness against the machine cadence, recurring task completion rate and SLA breaches by cadence, improvement Project activity per quarter, and Ongoing Certification Report and Quarterly Review delivery against their target dates. --- ## 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. The annual plan and policy review task under the Annual cadence parent is where that review is tracked. --- ## FedRAMP coverage CCM provider rules, Ongoing Certification Reports: Report Availability (MUST), Next Report Date (MUST), Feedback Mechanism (MUST), Anonymized Feedback Summary (MUST), Limit Sensitive Information (MUST NOT), Spread Out Reports (SHOULD), Responsible Public Certification Report Sharing (MAY) (CCM-OCR). CCM provider rules, Quarterly Reviews: Quarterly Review Meeting (MUST at Class C, varies by class), Meeting Registration Info (MUST), Next Review Date (MUST), No Irresponsible Disclosure (MUST NOT), Schedule Around Reports (SHOULD), Additional Content (SHOULD), Record or Transcribe Reviews (SHOULD), Restrict Third Parties (SHOULD NOT), Share Recordings Responsibly (MAY), Share Content Responsibly (MAY) (CCM-QTR). FedRAMP Certification verification and validation: Automated Verification and Validation of Key Security Indicators (MUST at Class C), Metrics Over Time for Key Security Indicators (MUST at Class C), Automated Verification and Validation of FedRAMP Rules (SHOULD) (FRC-CSX). Vulnerability detection timeframes: Persistent Machine Verification and Validation for 20x (MUST) and for Rev5 (MUST), Non-Machine Verification and Validation (MUST) (VDR-TFR); Failures Are Vulnerabilities (VDR-CSO-FAV) via the vulnerability pipeline. Security Decision Record: Key Security Indicator Metrics (MUST at Class C) (SDR-CSX-KMT). KSI-MLA: Authorizing Log Access, Evaluating Configurations, Logging Event Types, Operating SIEM Capability, Reviewing Logs. KSI-SVC-EIS: Evaluating and Improving Security. Underlying NIST: CA-2, CA-5, CA-7, CA-8, AU-6, AT-4, AC-2, AC-6(7), AC-22, CM-5(5), CM-7(1), CM-8, CP-4, IR-3, RA-5, PS-6. CMMC: CA.L2-3.12.1, CA.L2-3.12.3. ## Internal Memo Source: continuous-monitoring-and-reporting-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 - Continuous Monitoring - FedRAMP Rev5 Class C - FedRAMP 20x Class C - KSI-MLA-ALA - KSI-MLA-EVC - KSI-MLA-LET - KSI-MLA-OSM - KSI-MLA-RVL - CCM-OCR-AFS - CCM-OCR-AVL - CCM-OCR-FBM - CCM-OCR-LSI - CCM-OCR-NRD - CCM-OCR-RPS - CCM-OCR-SOR - CCM-QTR-ACT - CCM-QTR-MTG - CCM-QTR-NID - CCM-QTR-NRD - CCM-QTR-REG - CCM-QTR-RTP - CCM-QTR-RTR - CCM-QTR-SAR - CCM-QTR-SCR - CCM-QTR-SRR - CA-02 - CA-05 - CA-07 - CA-08 - AU-06 - AT-04 - AC-02 - AC-06 - AC-22 - CM-05 - CM-07 - CM-08 - CP-04 - IR-03 - RA-05 - PS-06