Incidents Happen: Objectives, measurements and planning (part 3 of 3)

13 July 2023

6-minute read

Information security incidents can be inevitable. Take every setback as an opportunity for improvement, with NQA Regional Assessor Michael Harper guiding you there.

Welcome back to ‘Incidents Happen’: a 3-part blog series brought to you by NQA.

While this series focuses on information security, the principles apply to any context. A machine tool not behaving as expected, a release of waste, an accident at work… incidents like these can occur anywhere and at any time.

In Part 3 of the series, we cover:

The difference between objectives and measurements.
An effective way to lay out the stages of implementation.
Our real-life incident scenario from Part 2 (here) in practice.

This is the final part of our ‘Incidents Happen’ series. Enjoy!

Need to catchup first? Read Part 1 (the basics) and Part 2 (the scenario).

The difference between objectives vs. measurements

When it comes to objectives and measurements, you can think of them this way:

Objective = a specifical goal for the benefit of the business.
Measurement = assessing the effectiveness of the implemented objective.

Recap: a real-life incident scenario

NQA recommends creating a programme to outline each stage of objective implementation.

Let’s use the real-life incident scenario from Part 2*:

A salesman (Henry) was caught emailing himself confidential information to take to his new employer. Decision-makers at his current company (Speed29) wanted to reduce the risk of something similar happening again. They set a new objective to select, install and configure a suitable data loss prevention tool by the end of 2023.

*The examples, business names and incidents portrayed in this article are fictitious. No identification with actual businesses, products or services is intended or should be inferred.

The NQA-approved method of objective implementation

PHASE 1: Expand on the objective

All ISO standards are fairly similar when it comes to objectives.

According to Clause 6.2 of ISO 27001 (Information Security Management Systems) and other ISO standards, objectives must be:

Aligned with the relevant policy

The data loss prevention tool will enhance information security and demonstrate continual improvement.

Measurable (if possible)

The organisation will have either completed the objective or not, with progress points included in the programme.

Relevant

An incident has occurred; the data loss prevention tool will be introduced to reduce the risk of it happening again.

Communicated

The incident, risk and objective have been documented. They are also agenda items on the management review.

Updated

The data loss prevention tool plan is a dynamic working document that’s reviewed and updated regularly.

PHASE 2: Write the plan

Objective: Select, install and configure a suitable data loss prevention tool by the end of 2023.

Step 1: Identify suitable products

Resources: Websites, trade shows and time
Responsible: Information Security Manager (ISM) and Chief Technology Officer (CTO)
When: End of June 2023
Evaluation: ISM and CTO to compare different vendors

Step 2: Watch vendor demonstrations

Resources: CTO, ISM, IT team members, time and rooms
Responsible: ISM
When: End of July 2023
Evaluation: Team members agree on suitable vendors to obtain quotes from

Step 3: Obtain quotes from suitable vendors

Resources: Time
Responsible: ISM
When: End of August 2023
Evaluation: ISM receives the quotes

Step 4: Select the vendor

Resources: Time
Responsible: CFO (Chief Financial Officer), CTO and ISM
When: End of September 2023
Evaluation: A vendor has been selected based on price, value and functionality

Step 5 would then be to install the data loss prevention tool software.

PHASE 3: Check if the tool works

Monitoring is referred to in Clause 9.1 of ISO standards.

Under Clause 9.1, decision-makers within an organisation must choose what, how and when they will monitor. They also confirm who will conduct the monitoring – and who will analyse the results.

In the context of our real-life incident scenario, this could be:

What (KPI)

False positive alerts to be less than 5% of the total alerts.
- False positive = when a scanning tool incorrectly flags a security vulnerability (i.e. there is no bug, or functionality is actually working).

How (method)

Reports from the data loss protection tool.

When

Reports shall be obtained monthly.

Who

IT Support will run the reports as part of their monthly monitoring and reporting tasks.

Results analysis

The ISM will receive and review the reports each month, with the results tracked and presented at management review.

The outcome? A more robust information security management system for your organisation.

Final thoughts from NQA

There you have it: a comprehensive breakdown of incidents, from setting an objective to creating a programme.

Thank you for taking part in our ‘Incidents Happen’ series. While we have focused on information security, the principles apply to any organisation – no matter the context.

Want a recap? Visit Part 1 (the basics) or Part 2 (a real-life scenario) of the series.

If your organisation needs advice on Information Security, arrange a call-back today.