The vendor vulnerability management requirements 2-10-3 require an organization to maintain an approved, repeatable process for finding technical vulnerabilities, rating their risk, assigning remediation, installing security patches, and receiving trusted vulnerability alerts. Where a vendor operates, hosts, supports, or maintains an in-scope asset, the organization must ensure the vendor provides the evidence and remediation support needed to meet the control; accountability for compliance remains with the organization.
Under Essential Cybersecurity Controls (ECC – 2 : 2024), Practice 2-10-3 is not satisfied by owning a vulnerability scanner or receiving occasional vendor patch notices. An external assessor will expect approved policy and procedures, recurring assessment evidence across applications, servers, databases, and networks, risk-based remediation records, and proof that fixes were validated.
What does ECC Practice 2-10-3 officially require?
The official requirement for ECC 2-10-3 states: “The cybersecurity requirements for technical vulnerabilities management must include at least the following.”
In plain English, this means the organization’s cybersecurity requirements document, policy, and supporting procedures must define the full vulnerability-management lifecycle. The lifecycle must be formally approved by the head of the organization or an authorized deputy, not merely drafted by the cybersecurity team.
- Periodic vulnerability assessments: The organization must assess applications, devices and servers, databases, and organizational networks at planned intervals. It must identify appropriate tools, connect or deploy them against relevant assets, and retain periodic assessment reports.
- Classification by criticality: Findings must be rated using more than a raw scanner score. Reports should consider the vulnerability description, exploitability, expected organizational impact, affected asset classification, network segmentation, and Common Vulnerability Scoring System (CVSS) rating.
- Risk-based remediation: Vulnerability reports must be shared with the teams that own the affected applications, endpoints, infrastructure, databases, or networks. Those teams must agree remediation dates and plans based on vulnerability and asset criticality, while cybersecurity tracks completion.
- Security patch management: Patch management cannot operate separately from vulnerability management. The organization must analyze findings, identify systems needing patches, plan implementation with affected teams, and connect patching to change-management procedures where required.
- Trusted vulnerability intelligence: The organization must subscribe to reliable alert sources, including national cybersecurity entities, vendors and original equipment manufacturers, sector groups, and cybersecurity service providers or tools.
For an auditor, the important distinction is between a capability and a controlled process. A scanner demonstrates capability. Approved requirements, defined coverage, scheduled scans, assigned owners, remediation evidence, exception governance, and post-remediation validation demonstrate a controlled process.
Who must meet vendor vulnerability management requirements 2-10-3, and when do they apply?
ECC Practice 2-10-3 applies to the organization implementing ECC and to its information and technology assets: applications, devices, servers, databases, and networks. It applies whether those assets are internally managed, hosted in a cloud environment, maintained by a managed service provider, delivered as a software service, or supported by a supplier.
The control does not transfer to a vendor simply because the vendor operates the technology. If a third party hosts a citizen portal, manages endpoint infrastructure, administers a database, or supplies a managed security service, the organization should define vulnerability-management obligations in contracts, service descriptions, operating procedures, or security schedules. The organization needs sufficient evidence to show that in-scope assets are assessed, classified, remediated, and retested.
Typical triggers include scheduled scanning intervals, release of a new application or infrastructure component, discovery of a high-risk vulnerability, a vendor security advisory, a national alert, a significant configuration change, or an incident indicating a possible exploitable weakness. The ECC does not prescribe one universal scanning frequency or remediation deadline. Those values should be risk-based, documented in policy, approved, and consistently applied.
| Event | Expected control response | Useful audit evidence |
|---|---|---|
| Monthly authenticated server scan finds CVSS 9.8 vulnerability | Validate the finding, identify exposure and segmentation, assign the infrastructure owner, set a risk-based due date, patch through change control, and rescan. | Tenable or Qualys report, ticket record, change approval, patch log, and clean post-remediation scan. |
| OEM releases an urgent firewall advisory | Assess whether affected models and software versions are present, determine exposure, apply mitigation or patch, and document decisions. | Vendor alert, asset inventory extract, risk assessment, implementation plan, and validation record. |
| Managed-service provider operates a database platform | Obtain assessment and patch status, verify agreed remediation actions, and retain oversight evidence in the organization’s vulnerability register. | Service report, contractual requirement, remediation tickets, meeting minutes, and evidence of retesting. |
What does compliant vulnerability management look like in practice?
An assessor normally looks for a consistent chain from policy to technical evidence. The following examples illustrate the level of evidence that would usually support the vendor vulnerability management requirements 2-10-3.
1. An approved policy establishes scope, roles, and intervals
Al Noor Municipal Authority, an illustrative 1,200-employee municipal entity, maintains a cybersecurity policy approved electronically by its deputy chief executive. The policy requires authenticated infrastructure scanning monthly, external perimeter scanning weekly, web application scanning before production release and quarterly thereafter, and critical vulnerability reassessment after remediation. It explicitly covers internally hosted systems and systems operated by contracted suppliers.
Its vulnerability management procedure identifies Cybersecurity as the process owner; Infrastructure, Network, Database, Endpoint, and Application teams as remediation owners; and Procurement as responsible for ensuring vendor contracts contain reporting and remediation clauses. This is stronger than a policy that merely says “patch systems regularly.”
2. Assessment coverage can be reconciled to the asset inventory
The authority uses Tenable Nessus for authenticated scans of Windows Server 2022, Red Hat Enterprise Linux, network devices, and Microsoft SQL Server databases. It uses Burp Suite Enterprise Edition for its externally accessible payment and permit applications. The audit team can reconcile the scanner target lists to the configuration management database and identify exclusions, such as legacy operational devices that require passive assessment or vendor-approved maintenance windows.
Authenticated scan profile: "Production Servers - Monthly" Credentialed checks: Enabled Scan schedule: First Saturday, 02:00 Targets: CMDB tag = Production Severity threshold for ticket creation: CVSS 7.0 or higher Excluded assets: OT segment; assessed by passive monitoring and vendor maintenance reports Ticket integration: ServiceNow Vulnerability Response
Compliance does not require every asset to be scanned with the same tool. It requires the organization to identify suitable technologies, connect them to applicable assets, and document an alternative method where direct scanning would be unsafe or impractical.
3. Classification reflects exposure and business impact, not CVSS alone
Gulf Regional Water Company, an illustrative semi-government utility with 850 employees, receives a CVSS 8.1 finding affecting an internet-facing remote-access gateway. Its vulnerability team raises the classification to critical because the gateway is externally reachable, protects privileged access, and is not sufficiently isolated from sensitive administrative systems. A separate CVSS 8.1 finding on a segmented test server is classified lower after documented review because it has no internet exposure and limited business impact.
The assessment report records the vulnerability identifier, technical description, exploitability, affected asset name, asset owner, CVSS, network zone, business impact, and final internal priority. This demonstrates the classification mechanism required by 2-10-3-2 and shows why a spreadsheet containing only scanner severity is often insufficient.
4. Remediation, patching, and verification form one evidence trail
For the remote-access gateway finding, the Network team receives a ServiceNow ticket containing the vulnerability description, named asset, classification, and required completion date. The team schedules the vendor firmware update through the approved change process, confirms backup and rollback steps, installs the patch, and attaches the implementation evidence. Cybersecurity then performs a targeted rescan and records that the finding is closed only after the vulnerable version is no longer detected.
If a patch cannot be installed on time, the record should show a formally approved exception, compensating controls, risk owner acceptance, a revised remediation date, and periodic review. An open ticket without an owner, due date, or risk decision is not evidence that the organization is managing the vulnerability.
5. Trusted alerts are monitored and acted upon
A compliant organization maintains a current list of subscribed channels, such as national cybersecurity authority notifications, national CERT or NCSC advisories, Microsoft Security Response Center alerts, Cisco PSIRT notices, Oracle Critical Patch Updates, and vulnerability intelligence provided through its security tools. The list should identify the monitored mailbox, portal account, or tool feed; the responsible team; and the workflow for converting relevant alerts into assessment or remediation actions.
For a vendor-managed system, the organization should also retain the supplier’s advisory, confirmation of affected versions, mitigation recommendation, remediation timetable, and post-fix evidence. A vendor statement that it “monitors vulnerabilities” is not enough unless the organization can show how that statement is tested and followed through.
What evidence should an internal auditor prepare for an external assessment?
- Approved cybersecurity policy covering periodic assessment, vulnerability classification, remediation, patching, and trusted alert subscriptions.
- Formal approval by the organization head or delegated representative, such as an approval workflow, signed document, or official email.
- Vulnerability management and patch management procedures linked to change-management processes.
- Periodic assessment plans, scanner configurations, asset coverage records, and reports for applications, servers, databases, and networks.
- Reports showing classification based on CVSS, exploitability, asset criticality, impact, and network segmentation.
- Remediation tickets, owner assignments, timelines, approved exceptions, patch/change records, and before-and-after assessment results.
- A maintained list of authorized and trusted vulnerability-alert sources, including supplier and OEM channels.
- Contracts or service reports showing how vendors provide vulnerability, patch, and remediation evidence for assets they operate.
FAQ: What do auditors ask about ECC 2-10-3?
Does ECC 2-10-3 require vulnerability scanning?
Yes. It requires periodic vulnerability assessment and detection using identified technologies and tools, covering applications, devices and servers, databases, and organizational networks. The organization should document the assessment plan, intervals, coverage, and results.
Does CVSS alone meet vulnerability classification requirements?
No. CVSS is specifically expected, but classification should also reflect exploitability, expected organizational impact, affected asset classification, and network segmentation. The final priority should be explainable from the assessment record.
Do vendors have to remediate vulnerabilities under ECC 2-10-3?
Vendors may perform remediation where they operate or support assets, but the organization remains responsible for demonstrating compliance. Contracts and operational processes should require timely notification, remediation planning, evidence, and validation support.
What proof is needed to close a vulnerability finding?
Closure should include evidence that the remediation or compensating control was implemented and that the vulnerability was reassessed. A post-patch scan, targeted validation result, or documented technical verification is generally stronger than a ticket marked “resolved.”
Next step: Build an assessment-ready evidence pack by tracing one recent critical vulnerability from alert or scan detection through classification, remediation, and post-remediation validation.
