Monitor

The system keeps changing after an authorization decision. So do its users, mission, dependencies, and threats. A conclusion that made sense earlier may need another look. Monitor keeps the risk conversation connected to what is happening now, including changes people are proposing before they become part of the operation.

NIST’s Monitor guidance connects ongoing awareness of the system and its environment with control assessments, analysis, reporting, risk responses, and ongoing authorization decisions. NIST’s Monitor step describes the expected outcomes.

Decide what would be useful to know

Use the monitoring strategy established earlier to decide what to assess or observe, how often, and who will review the results. Consider the risk, rate of change, applicable requirements, and authorization conditions. Different controls can need different kinds of evidence and different review frequencies.

Ask what action each measure is meant to support. Who receives it? What would cause them to investigate, correct something, or raise a decision to the AO? Collecting more information only helps when someone can interpret it and do something with the result.

Bring change back into the conversation

Consider changes to the mission, information, components, dependencies, and control providers. Work out how a proposed or actual change affects risk and the existing control implementation, then involve the responsible officials through the change process. The size of the technical change alone may not tell you the size of its consequences.

Some changes can be handled within established monitoring and change procedures. Others may require another look at the boundary, categorization, control selection, assessment, or authorization. Use the impact analysis and applicable direction to determine the response. The seven steps remain available whenever new information challenges an earlier answer.

Keep the record connected to reality

Verify corrective actions, update the relevant plans and assessment results, and report meaningful changes in risk. Preserve the history so someone can see what was found, what was changed, and why the conclusion moved. An open issue needs a credible next action; a closed issue needs support for its closure.

Carry those responsibilities through the end of the system’s life. Disposal and decommissioning bring decisions about information, records, components, and remaining dependencies. Follow the applicable retention and handling requirements, and make the transfer or end of responsibility explicit.

How this applies on SAP networks

NIST keeps the focus on whether the controls and risk decision still hold as the system changes. JSIG turns that into SAP operating direction: analyze security impacts, consult the appropriate officials about security-related changes, reassess controls, and maintain the authorization records. Monitoring results keep the AO involved in the risk decision. The same accountability carries through disposal and the retention of evidence. 2016 JSIG §2.3.6 gives the SAP-specific instructions for this step.

Let’s talk it through

Pick a question and compare how you’d approach it. Ask what information would change your answer.

• Which piece of evidence would become misleading first if the system changed tomorrow?
• What change could look routine to one team but alter another team’s risk?
• How would we know that monitoring has led to a useful decision instead of simply producing another report?

What do we carry forward?

Bring what monitoring teaches you back to the people who own the mission and the risk. Revisit the relevant step when an earlier answer no longer fits. That feedback is how the framework stays useful throughout the system’s life.

The Monitor section of Body of Evidence & Artifacts connects this work to the artifacts and body of evidence (BOE) you produce and maintain.