The alert arrives late in the day: a vulnerability in the firm's VPN or firewall has been added to CISA's Known Exploited Vulnerabilities Catalog. The managed service provider says it is checking. The device dashboard shows a familiar product name, but nobody in the room knows the exact model, software version, or whether a vendor-managed update already ran.
"Please patch soon" is not a response plan.
CISA describes its catalog as the authoritative source for vulnerabilities known to have been exploited in the wild and recommends using it as an input to vulnerability-management priorities.[2] A catalog entry does not prove that your device was attacked. It does mean the decision deserves a named owner, a short clock, and evidence.
For a small SEC-registered investment adviser, that evidence also supports a wider duty. The SEC's amended Regulation S-P requires covered institutions to maintain written incident-response policies and procedures designed to detect, respond to, and recover from unauthorized access to or use of customer information.[3] Whether a particular vulnerability event triggers the firm's incident process, customer notice, a regulatory filing, or another obligation is a decision for the firm's compliance and legal advisers. The technology team still has to establish what is exposed and what happened.
This exercise is a vulnerability-response drill, not an instruction to test an exploit against a production device. Use a real asset record and a fictional CISA notice, or use a closed vulnerability that the firm has already remediated. Do not run proof-of-concept code, scan systems you do not own, or change a live security gateway without the system owner's approval.
Start with one question: do we own the affected product?
Give the team a fictional notice containing a vendor, product, affected versions, date added, required action, and links to the vendor advisory. Do not provide the answer from the asset inventory.
Ask the IT lead or provider to identify every matching device and return five facts:
- model and serial or asset identifier;
- installed software and firmware version;
- internet-facing address or service, recorded in a restricted system rather than the exercise notes;
- business function and users who depend on it;
- administrator and support provider responsible for changes.
NIST's patch-management guidance begins with knowing when vulnerabilities affect the organization's applications, operating systems, and firmware.[1] It also recommends maintaining current software inventories and recording technical and business characteristics for each asset.[1] A purchase invoice is not enough. It may identify the product family while saying nothing about the running version, an old standby appliance, or a virtual instance created during a migration.
Set a time limit for the inventory check. The drill has found a control gap if the team cannot determine whether the firm owns the affected product without searching email, calling a former employee, or trusting a provider's unverified "all clear."
Open a response record before making the change
Create one record for the event. It can be a ticket, incident case, or change record, provided the firm can protect it and find it later. Record the source notice, affected asset, current version, exposure, business owner, technical owner, decision time, planned action, approver, validation evidence, and any follow-up investigation.
Do not paste passwords, private keys, complete configurations, public IP addresses, or customer information into the ticket. Link to restricted records instead.
The SEC's final rule requires covered institutions' response procedures to assess the nature and scope of an incident, identify affected customer-information systems and information types, and take appropriate containment steps.[3] A newly disclosed flaw is not automatically an incident involving unauthorized access. Still, opening a record prevents the early facts from disappearing if logs or later evidence change that assessment.
The response owner should also ask a blunt question: is there any sign the device may already have been accessed? Check the vendor's advisory for indicators and required forensic steps. Review available authentication, configuration, administrative, and network logs before rebooting or clearing them. If the team finds an unknown administrator, unexplained configuration change, suspicious login, missing logs, or another indicator named by the vendor, move from routine patching into the firm's incident-response process. Preserve evidence and involve qualified incident-response, compliance, insurance, and legal contacts under the firm's plan.
Choose among patch, mitigation, or removal
The cleanest result is often a vendor-supported update, but the team should not jump from a CISA entry to a blind installation.
Retrieve the advisory and update only from the vendor or an approved distribution channel. Confirm the affected versions, prerequisites, expected reboot, configuration impact, and rollback or recovery method. NIST recommends validating a patch's authenticity and integrity, testing when appropriate, and planning for operational side effects before deployment.[1]
Then make the decision visible:
- Patch now if a supported fix is available and the approved change can be made safely.
- Apply the vendor's temporary mitigation if a fix is unavailable or cannot yet be installed.
- Remove the device or service from exposure if neither option reduces risk enough.
- Escalate an exception when the firm accepts delay. Name the decision maker, compensating controls, next review time, and business reason.
NIST treats patching as one of several risk responses. Its examples also include disabling a vulnerable feature, adding controls, isolating the asset, upgrading, or removing the exposed function.[1] It recommends planning emergency patching, emergency mitigation, and unpatchable-asset scenarios before a crisis.[1]
The managed service provider can recommend and perform work, but the firm should retain the decision record. "The provider handles it" does not show which device was checked, which action was approved, or whether it worked.
Verify the result from both sides
A completed ticket is not technical verification.
Ask the administrator to capture the post-change version and relevant configuration state. Confirm that the update or mitigation survived the required restart. From an authorized external testing point, verify that the intended service is available and that a disabled interface or feature is no longer exposed. Check that remote users can connect, multifactor authentication still works, administrative access remains restricted, and logging continues.
NIST separates implementation from verification: for a patch, verification means confirming that it is installed and has taken effect.[1] NIST also advises continued monitoring so an old version is not restored from backup or a device is not reset to a vulnerable state.[1]
If the firm has a standby gateway, replacement appliance, disaster-recovery image, or stored configuration, include it in the check. An unused device can reintroduce the same flaw during the next outage.
Finish by recording the evidence reviewed, the final version or mitigation, who validated it, when monitoring will be rechecked, and whether the event exposed a weakness in inventory, vendor communication, logging, change approval, or recovery documentation.
Run the drill before the next notice
A 30-minute tabletop can expose most of the handoff problems without touching production. Give the owner, compliance lead, and IT provider the fictional notice. Start the clock. Ask them to locate the device, open the response record, choose an action, name the approver, describe the evidence they would preserve, and state how they would verify the result.
Do not score the exercise on whether everyone remembered a CISA acronym. Score it on whether the team could answer:
- Do we have the affected product and version?
- Who can authorize and perform the change?
- What evidence must be preserved before the change?
- What makes this an incident rather than a vulnerability ticket?
- How will we prove the response worked?
- When will we check again?
The useful output is a short correction list: an inventory field to add, a provider contact to update, a log-retention gap to fix, or an approval path to clarify. The next CISA entry should start a known workflow, not an email chain that begins with "Does anyone know who manages the VPN?"
For practical guidance on cyber risk and safer AI use, subscribe to Cyber & AI Insights.
If your firm wants an independent review of its vulnerability-response handoffs and evidence, schedule a conversation with Your Data Guardian.