LEARN. PRACTICE. GROW.Separate the finding from the risk response
A finding can remain factually correct even when the organization accepts residual risk. Acceptance does not turn a failed test into a successful one or erase the original observation. In a fictional example, a legacy system temporarily remains without a control improvement while migration is prepared. The competent owner evaluates exposure, alternatives, restrictions and conditions for maintaining the decision. The auditor checks whether the risk response was addressed appropriately within the audit mandate, without becoming the risk owner. The organization may administratively treat an action as accepted, but reporting should distinguish that state from verified remediation. Readers need to understand the actual outcome rather than infer that every closed action represents an effective correction.
Check authority, scope and conditions
An acceptance record should support assessment of who decided, which risk was considered, which assets and versions are included, what conditions apply and when the decision needs review. An implementer’s technical competence does not automatically provide authority to accept business exposure. Nor should acceptance be assumed to waive legal or contractual obligations. In the lab, risk-owner is a permitted fictional authority and implementer is not. F has valid acceptance for v2; K fails the authority rule. These names only exercise example logic. A real environment would require examination of delegation, limits, approval authenticity and evidence that the decision maker understood the relevant exposure. The database flag alone cannot establish those human and organizational conditions.
Reassess when time or context changes
Acceptance depends on the assumptions supporting it. Increased exposure, a version change, a new dependency or expiry can require reassessment before relying on the earlier decision. The example represents time with integers: acceptance starts at starts and ceases at expires. At time 30, G no longer has valid acceptance; F retains it until just before 40. Changing F to v3 also invalidates the modeled version match. These boundaries are not legal deadlines. They demonstrate why a report needs an as-of point and a check of current validity. An exception should not be silently extended simply because remediation remains unfinished. Escalation should make the changed circumstances and available responses visible to the responsible decision maker.
Report delays without losing exposure
The exercise dashboard contains eleven closed tickets, while analysis distinguishes one closure-review candidate, one valid acceptance and nine overdue items under the fictional rule. Counts alone do not establish priority: a critical control can require attention before several low-impact issues. Relate age, due date, criticality, dependencies, current response and missing evidence. When work is rescheduled, retain the original deadline, new commitment and corresponding authorization; changing dates without history hides delays. Assigning an action to a supplier does not remove internal responsibility for following up the outcome. Reporting should identify who needs to decide, what support is required and what remains exposed while remediation is unproven. This supports management action without presenting administrative progress as reduced risk.
Use the exercise to prepare real decisions
Both saved runs passed 34 checks using local SQLite. Repetition demonstrates behavior for these data and rules without validating bank controls, people or a real opinion. Compare F and G before and after expiry, then change the version and observe how the decision changes. Write an update separating implementation, retesting, acceptance and next action. For B, propose investigation of the later failure without deleting earlier evidence. For K, identify the need for a decision by appropriate authority. In actual work, combine technical results with interviews, documentation and tests suited to the objective. Follow-up should continue until sufficient evidence supports a bounded conclusion or a limitation is explicitly reported. A successful local run does not decide which conclusion a real audit can issue.
python3 content/labs/cisa-remediation-followup/run.py
# F: valid acceptance, not remediation. G: expired. K: authority mismatch.
# The cutoff, expiry and due-date rules are fictional teaching conventions.
# Inspect evidence.json and the rollback probes before drafting follow-up actions.A v2 exception expires before migration to v3. The report retains risk visibility and requests authorized reassessment; it neither carries acceptance forward automatically nor changes the earlier test result.
Common pitfalls
Treating acceptance as remediation; relying on assumed authority; renewing through silence; changing deadlines without history; prioritizing only by ticket count; confusing synthetic outcomes with actual effectiveness.
Related topics: Risk management · Management reporting · Control monitoring
Risk response should remain valid and visible. The auditor follows up outcomes and limitations without converting administrative status into a control guarantee.
Reference: Risk Management Framework for Information Systems and Organizations · CISA outline effective August 1, 2024