At some point, someone has to decide whether the risk of operating the system is acceptable. That conversation deserves more than a stack of completed documents. What work will the system support? What could still go wrong? What can we do about it? Authorize brings those questions to the official responsible for making the decision.
NIST’s Authorize guidance places accountability with a senior official who evaluates security and privacy risk, considers responses, and approves or denies authorization for a system or the use of common controls. NIST’s Authorize step describes the expected outcomes.
The package supports the decision. The authorizing official makes it.
Make the risk understandable
Bring together the system’s purpose and scope, the assessment results, and the planned responses to outstanding issues. Explain the potential consequences to operations, assets, individuals, and other affected parties. Connect a finding to the harm it could contribute to, and be clear about the conditions and uncertainty behind that explanation.
The quality of this conversation depends on how well the pieces agree. If the assessment describes a different implementation than the plan, or a proposed fix has no owner or resources, the package leaves important questions unanswered. Give the authorizing official, or AO, a clear picture of the current state and the realistic choices available.
Be clear about who is making the call
The system owner and the people supporting the assessment inform the decision. The AO is accountable for deciding whether the risk is acceptable within the applicable authority and organizational direction. A recommendation, a completed assessment, or an approaching deadline doesn’t make that decision on the AO’s behalf.
Talk through the alternatives and their consequences. Could the intended operation be limited while an issue is addressed? Is further remediation or assessment needed before a decision can be supported? What does delaying operation mean for the mission? Make those tradeoffs explicit rather than allowing them to disappear behind a status label.
Make the decision usable after the meeting
An authorization decision needs an identifiable scope, its terms and conditions, and the applicable duration or ongoing-authorization arrangements. The people operating the system need to understand what they must maintain, what they must report, and which limitations they must observe.
A Plan of Action and Milestones (POA&M) tracks corrective work; recording an issue there doesn’t itself grant permission to operate with it. The decision and the follow-up responsibilities need to be clear. Make sure the monitoring approach can provide the information the AO expects to receive.
How this applies on SAP networks
NIST puts an accountable risk decision at the center of authorization. JSIG carries that principle into the SAP authorization process by directing how the package is assembled and submitted, how the AO evaluates risk, and how the decision is recorded. Explicit risk acceptance belongs to the AO. The outcome, conditions, and duration give the operating team direction it can act on after the review. 2016 JSIG §2.3.5 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.
- What would the AO need to know that a list of control findings might leave out?
- Which proposed response depends on resources or promises that haven’t been secured yet?
- What new information would make us recommend revisiting the decision?
What do we carry forward?
Take the decision and its conditions into Monitor. If authorization is denied or more work is needed, return to the relevant steps with clear responsibilities. When operation is authorized, the evidence and reporting need to keep supporting that decision over time.
The Authorize section of Body of Evidence & Artifacts connects this work to the artifacts and body of evidence (BOE) you produce and maintain.