ISO 27001 Annex A 5.25 – Assessment And Decision On Information Security Events

ISO 27001 Annex A 5.25 Assessment And Decision On Information Security Events

This rule is about assessing incidents and then deciding if they are an information security incident and prioritising them for action.

What is ISO 27001 Annex A 5.25?

The latest version of the ISO 27001 standard is ISO/IEC 27001:2022 (published in October 2022).

In the ISO/IEC 27001:2022 Standard the control is titled “Assessment And Decision On Information Security Events”.

What is the ISO 27001 Annex A 5.25 control objective?

The formal definition and control objective in the standard is: “The organisation should assess information security events and decide if they are to be categorised as information security incidents.

What is the purpose of ISO 27001 Annex A 5.25?

The purpose of ISO 27001 Annex A 5.25 is “To ensure effective categorisation and prioritisation of information security events.

Is ISO 27001 Annex A 5.25 Mandatory?

ISO 27001 Annex A control 5.25 (Assessment And Decision On Information Security Events in the 2022 standard) is not automatically mandatory in the same way the clauses in the main body of the standard (clauses 4 through 10) are.

The mandatory part of the standard requires you to consider ISO 27001 Annex A 5.25 and all other Annex A controls, but you have the flexibility to exclude it if it is not applicable to your organisation’s specific risks and context.

Key Parts of the Rule

To follow this rule, you should have clear plans and policies. Here are some important steps:

A security problem (or “incident”) is an event that could harm your data’s secrecy, accuracy, or availability. The effect of a problem changes based on what happened, which data was affected, and how quickly you react.

You decide a problem’s priority based on two simple things: its impact and its urgency.

  • Impact means how bad the results are.
  • Urgency means how fast you need to fix the problem.

What is a Security Problem?

In your ISO 27001 plan (specifically, Annex A 5.24 on roles), you named contacts who will check each event. You can use these examples to know when an event is a true security problem:

  • A virus.
  • Someone getting into systems or data without permission.
  • Ransomware attacks.
  • A system stopping or going down.
  • Social tricks to get information.
  • Data being shared without permission.
  • Data being changed without permission.
  • Users being blocked from systems or services.

How to Check Security Events

The people you named in your ISO 27001 plan will lead and check these events. You should use the following steps as a guide when checking an event:

  • Impact: Check how serious the event is. Think about the results, like losing secrecy, data being wrong, or systems being unavailable.
  • Urgency: Think about how fast you need to find a solution.
  • Priority: You figure out the priority by checking the impact and the urgency.

Security Assessment Formula

You can use this simple math rule:

IMPACT x URGENCY = PRIORITY

Making a Decision

Your contact person must make a clear decision about each event after checking it. This decision must include:

  • If the event is an actual security problem.
  • The problem’s new priority level.
  • The right steps you should take to fix the problem.

Recording Your Results

You must write down the results of your checks and decisions. You keep these records so you can look back at them, check if you did things right, learn from past mistakes, and make your processes better.

You should record this information:

  • The day and time the event happened.
  • What the event was.
  • The event’s impact.
  • The event’s urgency.
  • The event’s priority.
  • The final decision you made.
  • What you did to fix the problem.

Conclusion

This guide gives you simple rules for finding the impact and priority of a security problem. You should use this guide along with your full security incident management plan.

If you want to read more about security management, the related standard is ISO/IEC 27035.

What an Auditor Will Check

An auditor will want to see proof that you are following these rules. They will look for:

1. Documented Roles and Steps

The auditor will check your written documents. They want to see that you have reviewed and approved these papers. Most importantly, you must show them the rules that match what you actually do, not just what you think sounds good.

2. Proof That Your Steps Work

They will ask you for proof of how you handle security problems, like an incident management process. You must pick one real example and walk them through the whole thing. This proves that you followed your own steps and that your process worked correctly.

3. Showing You Learned From Mistakes

The auditor will check that you wrote down lessons you learned. They will look to see that these lessons led to continual improvements or corrective actions. The auditor wants to know that you did more than just respond to the problem. You must show that you learned from the mistake and improved your system so that the problem is less likely to happen again.