Search every question across sub-FAQs

Start with the operational decision: define what Post Incident Review means in your ISO/IEC 27035 scope, who owns it, and what record proves the decision is current.

For incident work, decide the timer and escalation path before an event occurs: classification, severity, legal-notification review, containment owner, communications owner, recovery owner, and evidence custodian. This keeps the answer useful in audits, customer reviews, incidents, supplier reviews, and management review.

The evidence should show the process operating. For this artifact, the strongest record usually includes incident policy, response plan, severity matrix, triage records, escalation logs, notifications, containment and recovery notes, lessons learned, and retained logs.

Avoid evidence that only repeats a requirement. A reviewer should be able to see the actual owner, date, system, supplier, AI system, service, incident, risk, or control sample behind the answer.

The person who can fund, operate, and correct the process should own the decision; governance should review consistency and exceptions.

For high-impact changes, approval should include the teams affected by the evidence: security, privacy, resilience, supplier management, AI governance, legal, risk, or business service owners as relevant.

Review it at planned intervals and whenever the underlying scope, service, supplier, control, risk, AI system, personal data flow, incident process, or customer commitment changes.

A stale record is worse than a short record. If the facts change, update the evidence and mark what changed so the next reviewer can trust the page.

Start with the operational decision: define what Retained Logs means in your ISO/IEC 27035 scope, who owns it, and what record proves the decision is current.

For retained incident logs, decide in advance which event records, timestamps, triage notes, escalation decisions, containment actions, recovery evidence, and lessons-learned records must be preserved, who can access them, and when legal or privacy review is needed.

The evidence should show the process operating. For this artifact, the strongest record usually includes incident policy, response plan, severity matrix, triage records, escalation logs, notifications, containment and recovery notes, lessons learned, and Retained Logs.

Avoid evidence that only repeats a requirement. A reviewer should be able to see the actual owner, date, system, supplier, AI system, service, incident, risk, or control sample behind the answer.

The person who can fund, operate, and correct the process should own the decision; governance should review consistency and exceptions.

For high-impact changes, approval should include the teams affected by the evidence: security, privacy, resilience, supplier management, AI governance, legal, risk, or business service owners as relevant.

Review it at planned intervals and whenever the underlying scope, service, supplier, control, risk, AI system, personal data flow, incident process, or customer commitment changes.

A stale record is worse than a short record. If the facts change, update the evidence and mark what changed so the next reviewer can trust the page.

Start with a simple scoring approach: classify the incident by how much it affects critical services, sensitive data, operational continuity, and the organization's ability to recover quickly.

Use the same factors every time so similar incidents get similar treatment. NIST SP 800-61r3 points incident teams to risk evaluation factors such as asset criticality, functional impact, data impact, stage of observed activity, threat actor characterization, and recoverability when prioritizing incidents and deciding when to escalate or elevate response activities.

A practical rule is that higher severity usually means broader business impact, more urgent response, more difficult recovery, or a greater likelihood that the activity will spread, persist, or cause regulatory, legal, or customer-notification consequences. Lower severity usually means the event is limited in scope, easier to contain, and unlikely to affect critical services or sensitive data.

The evidence should show the process operating. For this artifact, the strongest record usually includes incident policy, response plan, severity matrix, triage records, escalation logs, notifications, containment and recovery notes, lessons learned, and retained logs.

Avoid evidence that only repeats a requirement. A reviewer should be able to see the actual owner, date, system, supplier, AI system, service, incident, risk, or control sample behind the answer.

The person who can fund, operate, and correct the process should own the decision; governance should review consistency and exceptions.

For high-impact changes, approval should include the teams affected by the evidence: security, privacy, resilience, supplier management, AI governance, legal, risk, or business service owners as relevant.

Review it at planned intervals and whenever the underlying scope, service, supplier, control, risk, AI system, personal data flow, incident process, or customer commitment changes.

A stale record is worse than a short record. If the facts change, update the evidence and mark what changed so the next reviewer can trust the page.