Operations Meetings¶

This document establishes the organization's policy for running a system on GRC-ITSM through a regular Operations Meeting, and the procedure for preparing, holding, and closing it. It is cross-cutting: the meeting reviews obligations that the other documents in this section define, and this document sets only when each is looked at, what is discussed, and where the outcome is recorded. The cadence is an organization-defined value; weekly and bi-weekly are the recommended options.

Download the KB article (Markdown)

Purpose¶

This document establishes the organization's policy for running a system on GRC-ITSM through a regular Operations Meeting, and the procedure for preparing, holding, and closing that meeting. The meeting is where the people responsible for a certified system look at its current state together, decide what to do about anything that threatens certification or falls behind schedule, and record those decisions on the tickets they concern.

The meeting reviews obligations that other documents define. Vulnerability response, change management, incident response, continuous monitoring, package maintenance, access management, and inventory each have their own policy and procedures. This document does not restate them. It sets when the meeting looks at each area, what is discussed, and where the outcome is recorded.

GRC-ITSM is the source of truth. The status report the meeting works from is rendered from the system's tickets, validations, and projects. Decisions go back onto those records. There is no separate tracker.

Framework applicability¶

The Operations Meeting is internal to the organization and its operations partner. It is not the FedRAMP Quarterly Review, which is a separate synchronous session open to all necessary parties and is governed by the Continuous Monitoring and Reporting Policy and Procedures.

Policy¶

• P-1. Every operated system has an Operations Meeting on a defined cadence. The cadence is an organization-defined value; weekly or bi-weekly is recommended. A meeting is never skipped silently. A canceled meeting is recorded on its task with the reason and the next date.
• P-2. The meeting is a record. Each period has one Project in GRC-ITSM per system, and each meeting is a Project Task under it. The task carries the agenda before the meeting, the meeting note after it, and the time spent.
• P-3. The meeting works from the status report, not from memory. The report is rendered from the system's current GRC-ITSM records before every meeting. Nothing is reviewed from recollection, and no figure in the room comes from anywhere but the report or the ticket it links to.
• P-4. Certification risks come first. On a compliance profile, items that breach or are about to breach a binding FedRAMP rule are reviewed before workload. Each such item leaves the meeting with an owner and a date.
• P-5. The agenda is fixed; the content changes. Every meeting works the same standing agenda. The specifics under each item come from the report for that period.
• P-6. Every decision has an owner, a due date, and a ticket. A decision or action that names no owner or date is not closed. A decision that concerns no ticket is routed to one or recorded as raised.
• P-7. Outcomes are recorded on the tickets they concern. Each discussed ticket receives one note with the outcome for that ticket. The meeting task receives the meeting note. Nothing is recorded in a parallel document.
• P-8. Notes carry outcomes, never discussion. A note states the decision, action, owner, and due date. It never quotes anyone, never lists attendees, and never records anything about a ticket other than that ticket.
• P-9. Discussion between meetings is captured the same way. A decision reached by email, in chat, or in an ad-hoc meeting is recorded on the ticket with its source named, and appears in the next report's decisions section.
• P-10. Time is logged against the period budget. Preparation, the meeting, and the debrief are logged on the meeting task and roll up to the Project budget.
• P-11. The meeting reads other projects; it does not run them. Open Projects on the system (onboarding, security improvement, remediation, engagement) are reviewed for tasks due and overdue and budget position. Decisions on their tasks are recorded on those tasks. The meeting never re-parents or re-creates another project's work.
• P-12. The procedure reviews itself. The ISSO reviews this document for effectiveness on the cadence in the ODV table, together with the meeting metrics.

Organization-defined values¶

Roles and responsibilities¶

• Operations lead. Owns the period Project and each meeting task. Prepares the report, runs the meeting, posts the outcomes, logs the time. Named as the agent on both tickets.
• ISSO. Decides escalations on certification risks, signs the Ongoing Certification Report the period closes with, and owns this procedure's review.
• System owner. Receives the report, approves exceptions, and owns decisions that commit budget or accept risk.
• Continuous Monitoring team. Standing attendees. Own the recurring obligation tickets and the validation posture the meeting reviews.
• Engineering and security leads. Own the vulnerability, change, and incident tickets discussed and take the actions assigned.
• Ticket owners. Receive one note per discussed ticket and act on it.

The status report¶

The report is the meeting's only input. It is rendered from GRC-ITSM before every meeting and re-issued after the meeting with the outcomes added.

Executive pages. A reporting-period strip (period, meeting date, distribution, and on FedRAMP 20x the next Ongoing Certification Report date). Headline numbers with the change since the last meeting: open inbox items, tickets breaching SLA, KSIs Not Satisfied or open POA&M items, tickets awaiting approval by type, access requests awaiting approval, and KSIs Satisfied. A certification-risk block with the Certification-Critical, At Risk, and Watch counts. Actions this period: what, why now, owner, ticket. What changed since the last meeting. A bottom line.

Detail sections. One section per area, each opening with what changed and closing with a Meeting Notes table for that section. On a FedRAMP profile: certification risk register, security metrics, upcoming Issues, Key Security Indicators or POA&M, vulnerabilities, deviations and accepted vulnerabilities, significant changes, incidents, recurring ConMon obligations, certification package and reviews, then decisions and actions, tasks due and overdue, change requests and patch windows, user access requests, approvals pending, ongoing projects, and since last meeting. Every section always renders; an empty one says "No action items".

Appendices. System information, the class timeframes that applied (remediation, incident report windows, verification cadences), and the certification-risk tier definitions with the version of the FedRAMP Consolidated Rules they were computed from.

Certification-risk tiers¶

The register on a compliance profile tiers open items by how directly they threaten certification. A tier is derived from the strength of the FedRAMP rule involved, the system's Certification Class, its track, and whether the rule family is yet binding. A record enters the register only when a rule the corpus states or times is breached or about to be; work driven by internal thresholds stays in its home section as workload.

Three stated exceptions raise or hold a tier: an Overdue Vulnerability at PAIN 4 or 5 is Certification-Critical although the remediation timeframe is a SHOULD, because FedRAMP defines the state and requires its disclosure; a Known Exploited Vulnerability past its CISA due date is Certification-Critical because the due date is mandated by CISA; a reporting-completeness MUST (a missing report field, an unpublished target date, missing history) is At Risk, and becomes Certification-Critical only when its report is due within 7 days.

Before the meeting¶

1. The operations lead renders the status report from current GRC-ITSM records and distributes it to the standing attendees within the lead time in the ODV table.
2. The meeting task is created under the period Project with the meeting date as its target date and the standing agenda as its checklist. The task body carries the report's Actions list, the register rows, the open projects, and what changed since the last meeting.
3. Anything discussed between meetings (email, chat, ad-hoc meetings) is gathered so its outcomes can be confirmed and posted at the debrief.
4. Attendees read the executive pages before the meeting. The meeting does not re-read the report aloud.

The standing agenda¶

Nine items, in this order. The checklist on the meeting task is this list.

Items 5 and 6 apply to compliance profiles. A system with no compliance program runs the other seven.

After the meeting¶

Debrief. The operations lead turns the meeting and any between-meeting discussion into outcomes: decisions, actions with owner and due date, information items, and items raised without a ticket. Each outcome is matched to its ticket. An outcome whose ticket is uncertain is confirmed with the person who raised it before anything is posted.

Per-ticket note. Each discussed ticket receives one note headed by its source and date:

The body states the decision, action, or noted item, then the owner and due date. It never quotes anyone, never lists participants beyond the action owner, and never mentions any other ticket's business. A decision reached in chat and repeated in the meeting is one note with both sources.

Meeting note. The meeting task receives the meeting note: a one-line state of the system, a table of the tickets discussed with their outcome, owner, and due date, the Decisions list, the Actions list, and the Raised list.

Time entry. Preparation, meeting, and debrief hours are logged on the meeting task and roll up to the period Project's budget.

Final report. The status report is re-issued with the Meeting Notes tables filled: one row per outcome per section, with its source and whether it has been posted to the ticket. It is reviewed for accuracy and voice before it goes to its distribution list.

Between meetings¶

A decision about the system does not wait for the meeting to become a record. When it is reached by email, in chat, or in an ad-hoc meeting, it is captured with its source and posted to the ticket per the ODV table, either at once or with the next debrief. The next report lists it in Decisions and actions since last meeting with the source named, so a reader can see what was decided in the room and what was decided between meetings. Anything that already reached a ticket as a note or an email action needs no second capture.

Recurring ConMon obligations in the meeting¶

The recurring obligations themselves, their cadence parents, their child tasks, and their categories are defined in the Continuous Monitoring and Reporting Policy and Procedures. The meeting looks at them under agenda item 6:

• a cadence parent that has not been created for the current period;
• an open child past its target date, with the FedRAMP rule it is tagged to when it carries one;
• a child due before the next meeting;
• the date of the last Ongoing Certification Report and the published date of the next one, against the 3-month cadence.

A child past its target date that is tagged to a binding rule is treated as At Risk: the tag supplies the rule's force, but the due date is the organization's own schedule, so the item is not Certification-Critical on that basis alone.

Records, retention, and metrics¶

Metrics reviewed at the procedure review: meetings held against the cadence, actions closed by their due date, Certification-Critical items and their time to owner assignment, obligations overdue at meeting time, and hours logged against budget.

Requirements the meeting evidences¶

Every rule id, force, class applicability, and timeframe below was read from FedRAMP Consolidated Rules 2026.07.14.01. "B / C / D" means the rule binds Classes B, C, and D and no Class A list names it; "all classes" means Class A is bound too through an FRC-CLA list or a Class A variant. Rule families carry effective dates; before a family binds, its items are reviewed with the adoption period noted and the report appendix prints the gate that applied. The meeting satisfies none of these rules by itself. It evidences a recurring, recorded review of each and drives the action; the discharge is described in the document named.

Authority, review, and revision¶

The ISSO owns this document. It is reviewed on the cadence in the ODV table and when the FedRAMP Consolidated Rules, the system, or the meeting metrics warrant.

Related documents¶

• Continuous Monitoring and Reporting Policy and Procedures
• Certification Package and Security Decision Record Maintenance Policy and Procedures
• Change Management Policy and Procedures
• Incident Response Policy and Procedures
• Vulnerability Detection, Evaluation, and Response Policy and Procedures
• Certification Data Sharing and Trust Center Policy and Procedures
• Access Management Policy and Procedures
• Asset Inventory and Assessment Scope Policy and Procedures

FedRAMP coverage¶

Rule ids, forces, class variants, and timeframes cited in this document were read from the FedRAMP Consolidated Rules for 2026, version 2026.07.14.01. CMMC references are to 32 CFR Part 170 and the CMMC Frequently Asked Questions v5.