Risk Response and Reporting · Topic 7 of 9
Risk Action Plans and Risk Data Collection and Validation
CRISC risk action plans and risk data: tracking treatment, validating execution, and collecting, aggregating, analysing and validating risk data.
- 5 min
- Action plans need tasks, owners, resources, dates, expected residual risk and success measures.
- Completion is validated with evidence, then residual risk is reassessed.
- Aggregation requires a common taxonomy and scales and can reveal concentrations.
What it is
A risk action plan, or treatment plan, turns a chosen risk response into specific tasks with owners, resources and deadlines. The practitioner collaborates with risk owners on the plan and then validates that the response was carried out as agreed.
Risk data is the information behind every rating, KRI and report: incidents, losses, test results, scan output, KRI values and assessment results. It must be collected from reliable sources, aggregated across the organization, analysed for meaning and validated for accuracy before anyone relies on it.
How it works
Contents of a risk action plan
| Element | Example |
|---|---|
| Risk reference | R-017 Unauthorized access to HR data |
| Response | Mitigate |
| Actions | Implement role-based access; quarterly access review |
| Owner per action | HR systems manager; HR director |
| Resources and budget | 2 weeks of IAM engineer time |
| Milestones and due dates | Roles defined by 15/01/2027; live by 31/03/2027 |
| Expected residual risk | Medium, within appetite |
| Success measure | Access review completion KPI above 95% |
Plans should be prioritized by risk, approved by the risk owner and linked to the risk register.
Tracking and validating execution
The practitioner tracks progress against milestones and escalates delays according to the risk policy. Delays matter because residual risk stays above appetite until the plan is complete.
Completion is validated with evidence: the control is in place, tested and operating, not just reported as "done". After validation, the residual risk is reassessed and the register updated. If the response did not reduce risk as expected, the risk owner decides on further action.
Collecting risk data
| Source | Data |
|---|---|
| Incident and problem management | Event counts, causes, impact |
| Loss event databases | Financial losses, near misses |
| Control testing and audits | Pass and fail results, deficiencies |
| Security tools | Vulnerability scans, SIEM alerts, endpoint data |
| Business systems | Transaction volumes, error rates, downtime |
| External sources | Threat intelligence, industry loss data |
Collection should be as automated as possible, use defined owners and frequencies, and keep the data's context, such as when it was captured and from which system.
Aggregation
Aggregation combines data from many sources and units to show the enterprise picture. It needs a common taxonomy and common scales; otherwise numbers cannot be added or compared. Aggregation can reveal concentrations, such as several business units depending on the same vulnerable system, that no single report shows.
Care is needed: averaging ratings can hide a single severe risk, and simple addition can double count risks that share a cause.
Analysis
Analysis looks for trends, correlations and outliers. A KRI that is still green but rising steadily may matter more than one that briefly touched amber. Root cause analysis of incidents shows whether problems come from a few common control weaknesses.
Validation
| Check | Question |
|---|---|
| Accuracy | Does the data match the source? |
| Completeness | Are all units, systems and periods included? |
| Timeliness | Is the data current enough to act on? |
| Consistency | Are definitions and scales the same everywhere? |
| Integrity | Could the data have been altered or filtered? |
Validation methods include reconciling to source systems, sampling and re-checking records, and independent review. Data reported by the same team whose performance it measures deserves extra scrutiny.
A worked example
Five business units report their open high-rated vulnerabilities each month for the board's risk dashboard. The totals have fallen by half in one quarter, which looks like great progress.
When the practitioner validates the data against the scanning tool, two units turn out to have changed their definition of "high" from CVSS 7.0 and above to 9.0 and above. The data is restated on a common definition, the true trend is flat, and a data standard with a single owner is agreed so the dashboard stays consistent.
How the exam asks about this
- "What is the BEST way to confirm that a risk action plan has been completed?" Obtain evidence that the controls are implemented and operating as intended.
- "Which is MOST important before aggregating risk data from several business units?" A common taxonomy, definitions and rating scales.
- "Risk figures improve sharply with no obvious reason. What should the practitioner do FIRST?" Validate the data against its sources and definitions.
What to remember for the exam
- Action plans need tasks, owners, resources, dates, expected residual risk and success measures.
- Completion is validated with evidence, then residual risk is reassessed.
- Aggregation requires a common taxonomy and scales and can reveal concentrations.
- Averages can hide severe individual risks.
- Validate data for accuracy, completeness, timeliness, consistency and integrity.
A report is only as good as its data. If an option suggests acting on figures that have not been validated, a better answer is usually to verify the data first.
Common mistakes
Closing actions on status updates. "Done" in a tracker is not evidence the control works.
Aggregating incompatible data. Different definitions make totals meaningless.
Watching only thresholds. Trends often warn earlier than a threshold breach.
Check yourself
Why must completion of a risk action plan be validated?
Because residual risk only falls if the controls are actually in place and working, which status reports alone do not prove.
What can aggregation of risk data reveal that unit-level reports cannot?
Concentrations of risk, such as many units depending on the same weak system or supplier.
Name three qualities to check when validating risk data.
Accuracy, completeness and timeliness, as well as consistency of definitions and integrity of the data.
Topic 7 of 9 in Risk Response and Reporting
Test yourself on Risk Response and Reporting
The full ISACA CRISC question bank has 1,000 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by ISACA. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.