Vulnerability Assessment and Penetration Testing Procedure

1. Purpose

This procedure sets out how technical vulnerabilities in the Organisation's systems are found, rated, fixed and proven fixed, and how penetration tests are authorised and conducted without harm to live services. Its aim is that weaknesses are closed in proportion to the risk they carry, within known times, with evidence.

2. Scope

• In scope: servers, endpoints, network and security devices, cloud services and configurations, containers and images, internet-facing and internal applications and APIs, databases, wireless networks, and customer-facing platforms owned or operated by the Organisation.
• In scope people: the information security team, system and application owners, operations and engineering teams, and any external tester engaged by the Organisation.
• Out of scope: systems owned by customers or suppliers unless the contract grants written permission to test; social engineering and physical intrusion tests, which require separate written approval from the Head of Information Security and Human Resources; and denial-of-service testing against production, which is prohibited unless explicitly planned.
• Applies to development, test, staging and production environments, with the testing intensity set in the schedule below.

3. Terms and Definitions

4. Roles and Responsibilities

5. Vulnerability Assessment and Penetration Testing

5.1 Preparation for vulnerability management

Scanning only works against assets that are known and reachable. Preparation makes sure the right things are scanned, safely and with permission.

1. Define scopeTake the asset list from the Asset Management Procedure and classify each asset as Critical, High, Medium or Low by the data it holds and the service it supports. Review scope at least [monthly] and after every major change.
2. AuthoriseObtain written permission from the system owner for scan times and methods; cloud and hosted providers' testing rules are checked before scanning their platforms.
3. Select toolsUse approved vulnerability scanners, container and image scanners, code and dependency scanners, and configuration compliance tools; keep their vulnerability feeds updated at least [daily].
4. Set credentialsCreate dedicated scan accounts with least privilege and read-only rights, stored in the secrets vault and monitored for use outside scan windows.
5. SchedulePublish the scan calendar to operations and the service desk, avoiding peak business periods; agree a safe scanning profile for fragile systems.
6. Cover discoveryRun network discovery at least [monthly] to find unmanaged devices and report them to the asset owner within [2 working days].

5.2 Vulnerability scanning

The frequency and depth of scanning depend on the asset class. The table gives defaults that the adopter may tighten.

• Scan results are collected automatically into the vulnerability register; assets missing from two consecutive scans are investigated within [5 working days].
• Failed or incomplete scans are rerun within [2 working days]; a repeatedly failing scan is raised as a finding in itself.
• Scan results are classified Confidential and shared only on a need-to-know basis.

5.3 Vulnerability evaluation

The vulnerability management lead validates each finding, removes false positives, and sets a priority rating. The technical score is adjusted for the Organisation's context, never lowered without a recorded reason.

• Threat intelligence under the Threat Intelligence Policy is checked at least [daily] for vulnerabilities being actively exploited; those are treated as one level more severe and fast-tracked.
• Each validated finding is recorded with asset, owner, severity, proof, recommended fix and due date, and assigned within [1 working day].

5.4 Vulnerability mitigation

Mitigation is the fix, or a measure that removes the risk. The time to act runs from the date the finding is validated, or from the vendor patch release if later.

1. FixApply the vendor patch or configuration change through the Patch Management Procedure and the Change Management Procedure; emergency changes are allowed for Critical findings.
2. MitigateIf no patch exists or downtime is not possible, apply a compensating control such as a firewall rule, web application firewall rule, feature disablement or enhanced monitoring, and record when it will be replaced by a permanent fix.
3. VerifyThe vulnerability management lead rescans the asset within [3 working days] of the stated fix and closes the finding only when the scan or retest shows it is gone.
4. ReportUpdate the register, notify the system owner and include the result in the monthly report.

5.5 Penetration testing

Penetration testing complements scanning by showing whether weaknesses can be chained into real harm. Every test needs written approval before it starts.

5.5.1 Rules of engagement

• Written rules of engagement are signed by the Head of Information Security and the system owner before testing, and contain: objectives, systems and addresses in scope, systems explicitly out of scope, permitted techniques, test windows, named testers and their source addresses, emergency stop contacts and reporting format.
• Testers must be bound by an NDA and have relevant qualifications or demonstrable experience; their staff are screened as required by the Supplier Relationship Management Procedure.
• Denial-of-service, destructive actions, data exfiltration of real restricted data, and testing of third-party systems are not allowed unless explicitly written into the rules.
• Testers stop at once and call the emergency contact if they find evidence of an existing compromise, cause an outage, or reach data beyond scope.
• Test data, credentials and findings are protected at the Confidential level; evidence is held on encrypted media and destroyed or returned within [30 days] of final report.
• The security operations team is told of the test window unless the test is designed to assess detection, in which case only the Head of Information Security and a named white-cell contact know.
• A final report is delivered within [10 working days] of test end, with executive summary, method, ranked findings, proof, and fix recommendations; findings enter the vulnerability register with the same timelines as above.
• A retest of Critical and High findings is carried out within [60 days] of the report.

5.6 Identification, analysis and treatment of exception and accepted risk

A vulnerability that cannot be fixed within the required time follows this route. An exception is a temporary extension; an accepted risk is a decision to live with the residual weakness.

1. IdentifyThe system owner requests an exception before the due date, stating why the fix is not possible and the date it will be done.
2. AnalyseThe vulnerability management lead assesses exploit likelihood and business impact, lists compensating controls and checks for chaining with other findings.
3. DecideApproval levels: Low by system owner; Medium by Head of Information Security; High by Head of Information Security and the business unit head; Critical by senior management.
4. TreatControls are implemented, the exception is recorded in the risk register with an expiry of no more than [90 days] for Critical and High, and [180 days] for others.
5. ReviewThe risk is reviewed at expiry and at least [quarterly]; it is re-approved, fixed or the system is withdrawn.

6. Measures

7. Records and Evidence

Annexure A: Vulnerability register

Annexure B: Penetration test rules of engagement

Annexure C: Vulnerability exception request

8. Exception

Exceptions to this document are allowed only where compliance is not practicable and the risk has been assessed. A request must state what is to be excepted, why, the risk it creates, the compensating controls, and an end date no later than [6 months]. It is approved in writing by the document owner and the risk owner, recorded in the exceptions register, and reviewed at the end date. An exception does not change the document.

9. Enforcement

Compliance is monitored through internal audits, management review and routine checks by the document owner. Non-compliance is reported through the incident or non-conformity process and handled under the organisation's disciplinary procedure, and under the terms of any contract for people who are not employees. Serious or repeated non-compliance may lead to loss of access and, where the law is broken, to referral to the authorities.

10. Review

This document is reviewed at least every [12 months], and when there is a significant change to the organisation, its systems, its risks or the law, or after an incident that shows it was not effective. Each review is recorded in the revision history.

ISO/IEC 27001:2022 references

Related documents

• Patch Management Procedure
• Patch Management Policy
• Secure Configuration Policy
• Risk Management Policy
• Incident Management Procedure
• Threat Intelligence Policy
• System Development and Maintenance Procedure
• Change Management Procedure