ISO 27001 Annex A 8.8 Management of Technical Vulnerabilities

Home / ISO 27001 Annex A Controls / ISO 27001 Annex A 8.8 Management of Technical Vulnerabilities

ISO 27001 Management of Technical Vulnerabilities

The focus for this ISO 27001 Annex A Control is being aware of technical vulnerabilities you have and the addressing them as is appropriate to you. As one of the ISO 27001 controls this is about assessing vulnerabilities and managing them.

You will learn what ISO 27001 Annex A 8.8 is, how to simply and easily implement it for ISO 27001 certification and I will show you some common gotchas so you can avoid them.

What is ISO 27001 Annex A 8.8 Management of Technical Vulnerabilities?

ISO 27001 Annex A 8.8 Management of Technical Vulnerabilities is an ISO 27001 control that looks to make sure you understand what vulnerabilities exist in your technology and make informed decisions to manage them.

ISO 27001 Annex A 8.8 Purpose

The purpose of Annex A 8.8 Management of Technical Vulnerabilities is to ensure information and other associated assets are protected from the exploitation of technical vulnerabilities.

ISO 27001 Annex A 8.8 Definition

The ISO 27001 standard defines Annex A 8.8 as:

Information about technical vulnerabilities of information systems in use should be obtained, the organisations exposure to such vulnerabilities should be evaluated and appropriate measures should be taken.

ISO 27001:2022 Annex A 8.8 Management of Technical Vulnerabilities

DO IT YOURSELF ISO27001

Stop Spanking £10,000’s on Consultants and Platforms

ISO 27001 Toolkit Business Edition

How to implement ISO 27001 Annex A 8.8

With management of technical vulnerabilities there are a couple of things to consider and the complexity of the control will be based on what you do and how complex your environment is.

Let’s consider first what you do. If you create software or hardware then there is a chunk of extra stuff that you are going to have to do here ranging from how you manage releases, patches, updates and communications. Remembering that this is guidance, take a common sense approach to your releases. I am not going to delve too deeply into this as for the majority this use case won’t apply but suffice to say you will need a strong, documented process and consider things like:

  • Vulnerability reporting – when people find them in your stuff how do they report them
  • Vulnerability management – what you do when someone tells you they found something
  • Vulnerability communication – what and how you tell people that there is a vulnerability in your stuff
  • Vulnerability roles and responsibilities – who is doing what

In more general terms let us now look to the things that impact everyone.

Know what technology you have

We start at the beginning by knowing what we have. Why? Because we cannot protect what we do not know. You will need asset registers that record what you have and we have covered this elsewhere in

The basic guide for this step is know what assets you have.

Configure your assets properly before use

Solid technical vulnerability management is part of the standard and links to this control by removing services that are not needed, blocking those not needed that cannot be removed and having solid configuration and technical management practices in place.

Know what vulnerabilities you have

When you implement your vulnerability management process you need to put in place the identification of those vulnerabilities. There are varying degrees of depth that you can go into here. Let us take a look at some ways we can identify vulnerabilities.

Vendor Alerts

Vendors as a rule will continually release patches and updates to address vulnerabilities that are found in their products. They will either alert you in the technology itself and / or send you communications such as emails or updates on their websites. Be sure you have included this in your process. It is a simple and quick win.

Specialist forums

It really depends here but for some technologies there are communities and forums that are set up. Some are official, some unofficial, but these can be great sources of information and early warnings and remediations.

Penetration Tests

Penetration tests are an old school way of identifying vulnerabilities. There are different approaches, from annual tests to on going or periodic tests. These usually address configuration vulnerabilities, ie the way you have set the technology up and are using it, but they are can on occasion find more fundamental flaws. Include these if they are appropriate to you.

Vulnerability Scanners

There are technologies that you can consider that will do continuous or periodic scanning of your environment for vulnerabilities. We are moving up the tiers of complexity and cost here, but based on risk this maybe something that you would want to implement.

Threat Intelligence

With the introduction of ISO 27001 clause 5.7 threat intelligence having access to bulletins, news letters and sources of information on emerging malware threats should be incorporated into processes and risk planning so that you can have a process of continual improvement and vulnerability management that will seek to mitigate those threats.

Assess Vulnerabilities

Once you know what vulnerabilities there are, your process should be to assess them. In assessing them we are doing a risk assessment to understand the risk the vulnerability poses. Once we know the risk of the vulnerability we can then prioritise it and plan our mitigation. Use good risk management practices. It maybe that you can accept the risk. The output of this step should be a risk score, prioritisation and risk decision.

Address the Vulnerability

Once you have made a decisions on what to do about the vulnerability then put in place a plan and action it. It maybe that you accept the risk, and therefore follow your risk management process for risk acceptance. Alternatively, it maybe that you need to address the vulnerability directly by implementing a patch or configuration change. Using your change management process you complete your remediation. There are things to consider here which are covered more in change management but we raise them for awareness being things like the timings, the need to test the change, the ability to back it out, the communication of it, the acceptance of it. This will be built into your processes but the point of this step is that once you have identified and assessed a vulnerability, you will address it.

ISO 27001 Templates

ISO 27001 templates have the advantage of being a massive boost that can save time and money so before we get into the implementation guide we consider these pre written templates that will sky rocket your implementation. This ISO 27001 Toolkit has been specifically designed so you can DIY your ISO 27001 certification, build your ISMS in a week and be ISO 27001 certification ready in 30 days.

How to pass an audit of ISO 27001 Annex A 8.8

Time needed: 1 day

How to comply with ISO 27001 Annex A 8.8

  1. Have effective asset management and know what assets you have

    Have an asset management process that includes an asset register.

  2. Configure your assets appropriately before use

    Implement an asset management process that configures assets before they are used. You will document what your configuration standards are and apply them.

  3. Have steps in place to identify vulnerabilities

    Put in place the ability to identify vulnerabilities. Examples include using threat intelligence, vulnerability scanners, penetration tests, being part of specialist groups and forums and vendor newsletters and alerts.

  4. Risk assess and priorities found vulnerabilities

    When you identify a vulnerability perform a risk assessment of it.

  5. Action risk acceptance or vulnerability mitigation management to address them

    Based on the assessment follow your risk mitigation plan.

  6. Implement controls proportionate to the risk posed

    The vulnerabilities will be prioritised based on risk and controls implemented proportionate to that risk.

  7. Keep records

    For audit purposes you will keep records. Examples of the records to keep include changes, updates, monitoring, review and audits.

  8. Test the controls that you have to make sure they are working

    Perform internal audits that include the testing of the controls to ensure that they are working.

Top 3 Mistakes People Make for ISO 27001 Annex A 8.8

The top 3 mistakes people make for ISO 27001 Annex A 8.8 are

1. Penetration Testing

The act of a penetration test is not actually a mistake but conducting it annually is. A point in time audit once a year maybe the bare minimum you can get away with but it is not best practice and usually tests are conducted in test environments or controlled environments that do not reflect reality. Sure you want to do them but think carefully what you are trying to achieve with it. If it is to tick a client need then great but if you truly want it to add value to the vulnerability management process and protecting you then engage your supplier with THAT requirement and follow their guidance.

2. You never apply patches

Patches and patch management is the most simple and straightforward way to meet the control but not having it work or patches not applied is the biggest mistake we see that fails people come audit. Do not assume you have patched and it works before the audit happens, check it. You may be surprised.

3. Your document and version control is wrong

Keeping your document version control up to date, making sure that version numbers match where used, having a review evidenced in the last 12 months, having documents that have no comments in are all good practices.

Get the Help of the ISO 27001 Ninja

Book your FREE 30 Minute ISO 27001 Strategy Call and let me show you how you can do it 30x cheaper and 10x faster that you ever thought possible.

Controls and Attribute Values

Control typeInformation
security properties
Cybersecurity
concepts
Operational
capabilities
Security domains
PreventiveAvailabilityProtectThreat and vulnerability managementProtection
IntegrityIdentifyDefence
ConfidentialityGovernance and Ecosystem

ISO 27001:2022 requirements

Organisational Controls - A5

ISO 27001 Annex A 5.1 Policies for information security

ISO 27001 Annex A 5.2 Information Security Roles and Responsibilities

ISO 27001 Annex A 5.3 Segregation of duties

ISO 27001 Annex A 5.4 Management responsibilities

ISO 27001 Annex A 5.5 Contact with authorities

ISO 27001 Annex A 5.6 Contact with special interest groups

ISO 27001 Annex A 5.7 Threat intelligence – new

ISO 27001 Annex A 5.8 Information security in project management

ISO 27001 Annex A 5.9 Inventory of information and other associated assets – change

ISO 27001 Annex A 5.10 Acceptable use of information and other associated assets – change

ISO 27001 Annex A 5.11 Return of assets

ISO 27001 Annex A 5.11 Return of assets

ISO 27001 Annex A 5.13 Labelling of information

ISO 27001 Annex A 5.14 Information transfer

ISO 27001 Annex A 5.15 Access control

ISO 27001 Annex A 5.16 Identity management

ISO 27001 Annex A 5.17 Authentication information – new

ISO 27001 Annex A 5.18 Access rights – change

ISO 27001 Annex A 5.19 Information security in supplier relationships

ISO 27001 Annex A 5.20 Addressing information security within supplier agreements

ISO 27001 Annex A 5.21 Managing information security in the ICT supply chain – new

ISO 27001 Annex A 5.22 Monitoring, review and change management of supplier services – change

ISO 27001 Annex A 5.23 Information security for use of cloud services – new

ISO 27001 Annex A 5.24 Information security incident management planning and preparation – change

ISO 27001 Annex A 5.25 Assessment and decision on information security events 

ISO 27001 Annex A 5.26 Response to information security incidents

ISO 27001 Annex A 5.27 Learning from information security incidents

ISO 27001 Annex A 5.28 Collection of evidence

ISO 27001 Annex A 5.29 Information security during disruption – change

ISO 27001 Annex A 5.31 Identification of legal, statutory, regulatory and contractual requirements

ISO 27001 Annex A 5.32 Intellectual property rights

ISO 27001 Annex A 5.33 Protection of records

ISO 27001 Annex A 5.34 Privacy and protection of PII

ISO 27001 Annex A 5.35 Independent review of information security

ISO 27001 Annex A 5.36 Compliance with policies and standards for information security

ISO 27001 Annex A 5.37 Documented operating procedures 

Technology Controls - A8

ISO 27001 Annex A 8.1 User Endpoint Devices

ISO 27001 Annex A 8.2 Privileged Access Rights

ISO 27001 Annex A 8.3 Information Access Restriction

ISO 27001 Annex A 8.4 Access To Source Code

ISO 27001 Annex A 8.5 Secure Authentication

ISO 27001 Annex A 8.6 Capacity Management

ISO 27001 Annex A 8.7 Protection Against Malware

ISO 27001 Annex A 8.8 Management of Technical Vulnerabilities

ISO 27001 Annex A 8.9 Configuration Management 

ISO 27001 Annex A 8.10 Information Deletion

ISO 27001 Annex A 8.11 Data Masking

ISO 27001 Annex A 8.12 Data Leakage Prevention

ISO 27001 Annex A 8.13 Information Backup

ISO 27001 Annex A 8.14 Redundancy of Information Processing Facilities

ISO 27001 Annex A 8.15 Logging

ISO 27001 Annex A 8.16 Monitoring Activities

ISO 27001 Annex A 8.17 Clock Synchronisation

ISO 27001 Annex A 8.18 Use of Privileged Utility Programs

ISO 27001 Annex A 8.19 Installation of Software on Operational Systems

ISO 27001 Annex A 8.20 Network Security

ISO 27001 Annex A 8.21 Security of Network Services

ISO 27001 Annex A 8.22 Segregation of Networks

ISO 27001 Annex A 8.23 Web Filtering

ISO 27001 Annex A 8.24 Use of CryptographyISO27001 Annex A 8.25 Secure Development Life Cycle

ISO 27001 Annex A 8.26 Application Security Requirements

ISO 27001 Annex A 8.27 Secure Systems Architecture and Engineering Principles

ISO 27001 Annex A 8.28 Secure Coding

ISO 27001 Annex A 8.29 Security Testing in Development and Acceptance

ISO 27001 Annex A 8.30 Outsourced Development

ISO 27001 Annex A 8.31 Separation of Development, Test and Production Environments

ISO 27001 Annex A 8.32 Change Management

ISO 27001 Annex A 8.33 Test Information

ISO 27001 Annex A 8.34 Protection of information systems during audit testing