6.5 Security testing

Requirement

The relevant entities shall establish, implement and apply a policy and procedures for security testing.

Guidance

• Take into account industry-recognised standards when developing the testing policy (56).
• Establish and maintain a testing programme appropriate to the entity’s size, complexity and maturity (57).

Examples of evidence

• Documented security testing and procedures based on relevant standards and good practices.
• Guidelines and standards that the entity adheres to for conducting security tests.

Requirement

The relevant entities shall: (a) establish, based on the risk assessment carried out pursuant to point 2.1, the need, scope, frequency and type of security tests; (b) carry out security tests according to a documented test methodology, covering the components identified as relevant for secure operation in a risk analysis; (c) document the type, scope, time and results of the tests, including assessment of criticality and mitigating actions for each finding; (d) apply mitigating actions in case of critical findings.

Guidance

• Make sure that network and information systems undergo continuous testing, particularly in environments utilizing continuous integration / continuous deployment practices. Regular testing should be conducted at set-up, after significant upgrades or modifications and following maintenance, to maintain robust security and performance.
• Consider a range of security tests (e.g. vulnerability assessments, penetration testing, code review, ethical hacking, bug bounty programmes, cyber attack simulations, red teaming, protocol conformance testing or cyber response exercises) and select the most appropriate one (or more) to test the specific procedure, service or tool over time.
• Entity-wide scoped tests should be carried out at planned intervals or when significant incidents or changes occur.
• Conduct internal and/or external audits throughout the entity’s networks, systems and processes in an ad-hoc manner.
• Record evidence while testing. The need, scope, frequency, type and results are to be documented in a manner that is comprehensible to an expert third party.
• Use criteria to assess the results of the tests similar to the criteria for performing cybersecurity risk assessments (guidance on point 2.1.2 of the Annex to the regulation).
• Assess, follow up and remediate high-criticality findings with respect to the confidentiality, integrity, authenticity or availability of the service provided.
• Document the assessment of criticality and mitigating actions for each finding. Ensure that risk assessment results and risk treatment plans are updated accordingly (Annex to the regulation, point 2.1).
• When testing reveals an underlying security issue in a free and open source component, these findings must be shared with the relevant open source project. If a patch is developed to address the issue, the relevant code should also be shared with the relevant open source project, in a manner suitable for integration.
• Where appropriate, any automated security tests written by entities for open source components that they use, should be shared with the relevant open source projects.

Examples of evidence

• Documented security testing policy and procedures that include the elements referred to in point 5.2 (a) of the Annex to the regulation.
• Documentation defining the roles and responsibilities of personnel involved in security testing.
• Plans or schedules for upcoming or completed regular or ad hoc tests.
• List of reports from past security tests This should cover various types of testing (e.g. vulnerability assessments, penetration testing and code reviews).
• Internal or external audit reports.

Requirement

The relevant entities shall review and, where appropriate, update their security testing policies at planned intervals.

Guidance

• Review the security testing policy and procedures at least once every two years.

Examples of evidence

• Updated security-testing policy and procedures, review comments, and/or change logs.
• Security-testing policy and procedures, including when tests must be carried out, test plans, test cases and test report templates.

Tips: guidance

• For systems with external integrations (e.g. cloud services) beyond the organization’s control, ensure that all external application programming interface endpoints are thoroughly tested.
• Determine the auditable security events that are adequate for supporting investigations of security incidents.
• Implement tools for automated testing, such as code analysis tools or vulnerability scanners.
• Ensure the policy is approved by, communicated to and acknowledged by relevant personnel and third parties.
• Ensure that the development and testing environment(s) is/are separate from the production environment.
• Review the security-testing policy and procedures when significant incidents or major changes to the network and information system occur.

Tips: examples of evidence

• In addition to the elements referred to in point 6.5.2 (c) of the Annex to the regulation, documented policy that includes at least (indicative, non-exhaustive list):
  • approved parties (internal or third);
  • confidentiality levels for assessment; and
  • test results and the objectives of security assessments and tests.
• Relevant staff aware of the security-testing procedures and tools.
• Documented audit requirements.
• A list of tools used for security testing, including their purpose and how they are maintained and updated.
• Valid licences for commercial testing tools or subscriptions to security services.
• Review showing that the security tools are in use and configured to perform the actions intended.
• Records showing updates to the security policy and procedures based on lessons learnt and new threats.