Risk Calculations and Post Incident Response
About 13% of the CIS-SIR exam — see all 7 domains.
Severity and risk calculation
A security incident's severity can be calculated automatically by severity calculators: when a saved incident matches a calculator's conditions (for example, a CI tied to a highly critical business service), the calculator elevates the Risk score, Business impact, and Priority fields. The risk score itself is calculated from configurable weights (Risk Score Weights, or the newer Risk Score Calculator with weighted criteria). Both are rule-driven and configurable. The goal is consistent, defensible prioritization rather than analyst guesswork.
- Risk score / severity is derived from business impact (affected service criticality, asset value) and incident attributes.
- Calculators are configurable: implementers tune the inputs and weights to match the organization's risk model.
- (VERIFY) the exact calculator names, default fields, and weight tables for your release, as these have evolved.
Business criticality and the CMDB
Because security incidents reference CMDB CIs, the business criticality of the affected CI/service feeds severity. A compromised business-critical server produces a higher severity than the same compromise on a low-value asset. This CMDB linkage is the bridge that makes risk-based prioritization possible.
Post Incident Review (PIR)
When an incident moves to the Review state, Post Incident Review captures lessons learned: what happened, how it was handled, what worked, and what should change. PIR is structured (assessments sent to reviewers, plus a generated PIR report attached to the incident at closure) so that findings are consistent and actionable. The output drives continuous improvement: updated runbooks, new playbook steps, tuned calculators, closed gaps. Know that PIR is a defined phase after recovery and before closure (it maps to the Review state, and incomplete PIR assessments block closing the incident) and is part of standardized incident handling, not an ad-hoc afterthought.
Closure and resolution
Closing a security incident requires recording closure information (resolution, close code/notes) and, depending on configuration, completing the review. Every response task must be closed or canceled before the incident itself can close; follow-on work belongs on a change or problem record. SLAs stop on closure. Proper closure data is what feeds dashboards, PA, and PIR metrics.
Sample questions from this domain
Three of the 39 in this domain, with the reasoning. The full set is in the question bank.
What is the purpose of the security incident risk calculator?
- A. To compute a risk score for a security incident based on configured factors and weights ✓
- B. To look up the reputation of each observable against the configured threat lookup sources
- C. To rank available analysts by skills, location, and coverage area for auto-assignment
- D. To measure time to respond and time to resolve against the targets in each SLA definition
Why: The risk calculator computes a risk score for a security incident from configured factors and weights (for example, the Risk Score Weights for Business impact and Priority, or the criteria and weightage in the newer Risk Score Calculator rule), and the score aids analysts in prioritizing work. Checking an observable's reputation is a threat lookup against lookup sources. Ranking analysts by skills, location, and coverage area is auto-assignment. Timeliness targets are measured by SLA definitions.
What is the primary purpose of a Post Incident Review (PIR) in SIR?
- A. To approve the closure of a security incident by having a manager sign off on the close code and the close notes entered
- B. To record the root cause on the incident so that a related problem record gets raised when the incident is closed
- C. To capture lessons learned, evaluate response effectiveness, and identify improvements after an incident is resolved ✓
- D. To reassess the incident's risk score after recovery so that the CISO dashboard shows its final business impact value
Why: A Post Incident Review captures lessons learned, evaluates response effectiveness, and identifies improvements once the incident has been handled; it appears when the incident moves to the Review state and consists of assessments plus a PIR report that, when PIR reporting is configured, is attached as a PDF at closure. It is not a manager sign-off on the close code and close notes, which the analyst enters at closure. Problems and changes are created from the incident as related records when needed; the review does not raise them. The risk score aids prioritization during the response and is not reassessed by the review.
Which two factors might a security incident risk calculator consider when scoring an incident? (Choose two)
- A. The skills recorded on the assigned analyst's user profile
- B. The location rating used to auto-assign the analyst
- C. The number of published articles in the knowledge base
- D. The severity or category of the incident ✓
- E. The criticality or business impact of affected configuration items ✓
Why: Risk calculations weigh attributes of the incident and what it affects, such as the business impact or criticality of affected configuration items and the incident's severity or category (the base risk score also uses priority and the type of incident). An analyst's skills and the location rating are auto-assignment criteria for choosing who works the incident; they say nothing about the incident's risk. The size of the knowledge base is unrelated to any one incident.