ISO 27001 Penetration Testing Requirements – Risk Crew

A common question that comes up when implementing ISO 27001 is: Should I include security penetration testing in my Information Security Management System (ISMS) programme to comply with the ISO 27001 standard and meet auditor expectations? The answer is both yes and no — depending on how you look at it. The standard does not state “thou shalt conduct security penetration testing of thy systems” but regardless of this omission, it has to be done.

Why? Because good risk management includes security testing. The new 2022 standard places emphasis on exercising risk management in the decision process for determining which security controls to implement and why. It stresses the need to implement processes to quantify the risks to systems and the information they process and manage them accordingly. Badly configured or unpatched systems for example present significant risks if they go undetected and unaddressed. Things like poor coding and programming practices can introduce security vulnerabilities into a network specifically if the application interacts with 3^rd parties outside of the organisation. These days, everybody is connected to everybody, and the inherent risks associated with that fact should be addressed in the ISMS.

The 2022 standard’s revised emphasis on implementing a more granular and risk-driven approach to controls and considering and including greater areas of responsibility (such as 3^rd party connection) puts greater emphasis on the purpose and value of conducting security penetration testing.

Now that we all understand the importance of testing let’s now explore the control requirements and recommendations of penetration testing for ISO 27001 Compliance.

ISO 27001 Penetration Testing Requirements

You see there are three specific controls in the standard where verification of their implementation and effectiveness can more or less only be achieved by conducting network security penetration testing. These are:

• 8.9 – Configuration management
• 8.20 – Networks security and;
• 8.21 – Security of network services.

All of the security controls, practices and procedures recommended in these control areas can and should be confirmed through security penetration testing. It’s the surest and most cost-effective methodology. Consequently, it has become the accepted best practice of demonstrating compliance to these control areas and one of the key considerations of your approach to the standard.

As we all know, the standard requires organisations to routinely conduct internal audits of their compliance against the requirements and to document the findings. A good security penetration testing report provides the documented evidence required by an auditor to demonstrate compliance with these three controls mentioned above (as well as numerous others).

So yes, conducting routine and comprehensive security penetration testing is “ipso facto” for demonstrating compliance to the IS0 27001:2022 standard through “Optimus praxis”.

Website Security Penetration Testing for ISO 27001

If you are wondering if this same logic extends to a requirement for conducting security penetration testing of the organisation’s website(s) — the answer is yes.  In fact, the return on investment for conducting detailed web application security penetration testing is significantly higher as it allows you to also demonstrated compliance to controls:

• 8.26 – Application security requirements
• 8.27 – Secure system architecture and engineering principles
• 8.28 – Secure coding
• 8.29 – Secure testing in development and acceptance
• 8.32 – Change management and;
• 8.33 – Test information

Compliance with most if not all of the policies, practices and controls recommended in these sections can be evidenced by conducting a web application security penetration test. The key, of course, is to ensure these aspects are included in the testing scope by your service provider and that the report clearly confirms the applicable controls tested and documents the associated findings. Unfortunately, few organisations think of this prior to testing – but that’s for another blog.

ISO 27001 Penetration Testing Frequency

How often should testing be conducted for ISO 27001 compliance? The answer is most likely not what you think. Currently, the common wisdom is that systems within the scope of compliance with the ISO 27001 standard should be subject to quarterly security vulnerability scanning and annual security penetration testing – or after any significant change.

Once again, while this is not now nor has it ever been explicitly stated anywhere in the standard, it has come to be commonly accepted by auditors as best practice. However, even a thorough reading of the updated standard should leave you questioning that wisdom.

After reading the revised standard it should be crystal clear that any and all determinations regarding how often your organisation should conduct any security testing (network, web application, cloud etc…) should be “risk-driven”.

As noted earlier, the 2022 version puts a stronger emphasis on organisations implementing a strong, proactive risk management approach in all areas of their ISMS. Everything should be assessed and addressed according to its potential inherent risks. The clear message in this version is for organisations to put more resources into assessing risks and addressing them accordingly.

Security penetration testing results enable the Information Security Manager to identify and assess the risks associated with a system or website and act accordingly. It highlights weaknesses or vulnerabilities that could be exploited to the benefit of attackers and the detriment they can cause to the organisation. Whether vulnerabilities are a result of poor programming, missing patches or incorrect software configurations. Either way, they pose a potential risk to the organisation.

So, the answer to the question of how frequently should testing be conducted for compliance with the ISO 27001 standard is — whenever it needs to be – in order to sufficiently manage the potential security risks to the system. Maybe your organisation should be conducting security penetration testing twice or three times a year – or maybe not. Maybe you should be testing your web application six times a year – or maybe not.

It’s like the simple and obvious answer to: How long is a piece of string? Just measure it. Good information security policies and procedures are based on the results of risk assessments.  The frequency your organisation tests should be determined by the clear risks associated with NOT testing. Do you know them? Have you documented them? If you have, you know the answer to the question. Many organisations don’t however. They fall back on the industry practice of annual testing and do not fully understand that their systems and the risk landscape demand more.

Security Testing Compliance Benefits

While there are numerous and significant benefits to conducting comprehensive and routine security penetration testing, the ISO 27001 compliance benefits should be obvious. A programme of regular testing functions as an extremely effective “risk management” tool in the ISMS strongbox. Testing can also be used to provide assurances to interested parties and serve as concrete evidence of your continuous improvement processes.

Most importantly though, conducting good security penetration testing can catch human error: poor administration or configuration, a missing patch – the small things that could have big consequences. Testing should be the very essence of your ISMS – you could never really be compliant without it.

Learn more about our ISO 27001 services