Governance and risk

What the risk decision needs to explain

Suppose an administrative interface is exposed. That describes the condition, but it does not yet explain the consequence. Someone might make an unauthorized configuration change, which could interrupt service for customers. Now there is a specific problem against which to evaluate the proposed control.

CSF 2.0 includes governance alongside Identify, Protect, Detect, Respond and Recover. Governance assigns oversight and authority to this work. It does not, however, decide how much risk an organization should accept or provide the evidence needed to make that decision. Those questions still need accountable people and information about the actual business.

Temporary support should have a defined end

Consider a fictional software company whose vendor needs administrative access to diagnose a failure. The vendor requests a permanent account. The service owner instead proposes an account that expires, approval for each session and a record of administrative changes. This is a teaching example, not a Cognatory engagement.

The vendor can still make authorized changes, so the proposal has not removed every risk. The owner accepts that remaining exposure for the diagnostic task, and the platform team is responsible for expiry. If the vendor takes on more work, the access decision needs to be made again. The original approval only covers the original task.

Keep the reason with the decision

Someone reviewing this account later should be able to tell why it exists, who approved it and what is supposed to happen next. A short record can supply that context without relying on the person who opened the ticket.

• Business activity and system boundary covered by the decision.
• Risk scenario and the evidence supporting it.
• Selected response, responsible owner and implementation deadline.
• Remaining risk and the person authorized to accept it.
• Events that require another review, including expiry, an architecture change, a failed test or new evidence.

Check that the account behaves as agreed

Once the account expires, try to use it. Review a sample session and confirm that the owner received its activity record. Keep the timestamps and test account identifier so the result can be checked. A ticket marked complete is not enough if the supposedly expired account still works.

Overdue decisions, expired exceptions and old evidence are useful things to measure separately. Combining them into one unexplained score makes it difficult to see what needs attention, especially when the business consequences differ. If the decision uses a financial estimate, retain its assumptions and uncertainty as well.