Vulnerabilities, Patching and Your Website

Lesson 01 reported the headline: in Verizon's 2026 report, covering incidents from November 1, 2024 to October 31, 2025, about 31 percent of breaches started with an exploited vulnerability, and credential abuse fell to 13 percent (Verizon; the 13 percent figure comes from a trade-press summary, SecurityWeek). Press accounts of the same report say the median time to fully patch rose to 43 days from 32, and that organizations fully fixed only 26 percent of the KEV entries Verizon observed, down from 38 percent. Those last three figures reached us through secondary reporting. Treat them as directional until you read the report itself. The direction is clear enough. Attackers are getting faster, and defenders are taking longer.

That gap is a management problem before it is a technical one. The IT team can install patches. Only someone with authority can decide that the warehouse scanner system will go down Saturday night, that the ten-year-old firewall will be replaced this quarter, or that the sales portal is worth a security review before the next feature ships. This lesson covers the program that sits behind those decisions. Lesson 02 describes the layers where patching sits, lesson 03 covers the asset inventory this program feeds on, and lesson 11 covers what to do when a patch arrives too late. For hands-on update steps on individual machines, the practical modules are small business module 72, lesson 03 and home computer module 71, lesson 02.

A patch program in management terms

NIST Special Publication 800-40 Revision 4, published in April 2022 by Murugiah Souppaya and Karen Scarfone, defines enterprise patch management as identifying, prioritizing, acquiring, installing and verifying patches, updates and upgrades. The authors call patching preventive maintenance and a cost of doing business, and they name the usual fight: business owners see patching as a risk to uptime, while security and technology managers see it as a risk reducer (NIST SP 800-40 Rev. 4). The guide's answer is to plan the argument in advance instead of having it fresh every Patch Tuesday.

The planning unit is the maintenance group: a set of assets with similar characteristics that share the same maintenance needs. A group might be "office laptops," "warehouse handhelds that cannot reboot during shifts," "customer-facing web servers," or "the production line controller that the vendor will not let us patch." NIST says that instead of calling certain assets exceptions, you should give them their own group, with their own plan. For each group you choose one of four plans.

Plan (NIST SP 800-40 Rev. 4)	When it applies	What it looks like in a 140-person firm
Routine patching	Normal monthly releases	A few pilot machines get the patch first (NIST calls them canary assets), then everyone else within a set window, with a forced install after a grace period.
Emergency patching	A severe or actively exploited flaw with a patch available	Same steps on a compressed clock. NIST suggests the canary test could last a few minutes to a few hours, with wider rollout in hours or days.
Emergency mitigation	No patch yet, or the patch is flawed or disruptive	Turn off the affected feature, block the port, or isolate the asset. NIST says to plan to replace the mitigation with a permanent fix, on a schedule.
Unpatchable assets	The vendor no longer supports it, or it must run without interruption	Long-term controls such as network segmentation, approved in advance, with a periodic check on whether they still work and whether the asset is still worth its cost.

The five parts of the program

1. An asset list. You cannot patch what you have not found. The inventory from lesson 03 is the input, and for this purpose it needs three extra columns: whether the asset is reachable from the internet, who owns it, and its support end date. CIS Controls v8 puts the inventory first for a reason, and its Control 7 (Continuous Vulnerability Management) begins at safeguard 7.1 with "Establish and Maintain a Vulnerability Management Process" and 7.2 with "Establish and Maintain a Remediation Process." Both sit in Implementation Group 1, the starter set (CIS Control 7 listing; this listing is for v8, and CIS says the safeguard total is the same in v8.1, so confirm the numbering against the current v8.1 workbook).
2. Deadlines by severity. A table, approved by the owner or the operations lead, that says how many days each class of finding may stay open. A suggested table follows.
3. A risk-based sort. Severity scores alone do not tell you what to fix first, as the next section shows.
4. Exceptions with an owner. Anything that misses its deadline needs a written exception: the reason, the compensating control, an expiry date, and the signature of the business owner of the system, not the IT manager.
5. Proof. Scan or patch-tool reports before and after, kept for at least a year. That evidence answers the insurer, the auditor and the regulator in one stroke.

Prioritize with three signals, not one

Three free sources help you decide what comes first.

CVSS, the Common Vulnerability Scoring System, rates how bad a flaw could be on a 0 to 10 scale. A 9.8 sounds urgent, and thousands of flaws score that high, most of which nobody ever exploits. EPSS, the Exploit Prediction Scoring System from the Forum of Incident Response and Security Teams (FIRST), is a machine-learning model that gives each CVE a number from 0 to 1, the estimated probability of exploitation in the wild within 30 days, and a percentile rank. The scores are updated daily and are free through a download or an API (FIRST EPSS). The third source is the KEV catalog, which is not a prediction at all. It lists flaws already used in attacks.

CISA adds a vulnerability to the catalog when three conditions hold: it has a CVE ID, there is reliable evidence of active exploitation in the wild, and a clear remediation exists, such as a vendor update. A public proof-of-concept is not required, and scanning or research alone does not count as exploitation (CISA KEV). The directive behind the catalog, Binding Operational Directive 22-01, binds federal civilian executive branch agencies only. It set a default of six months for flaws with CVE IDs assigned before 2021 and two weeks for everything else, with CISA able to adjust the dates (BOD 22-01). CISA states that state, local, tribal and territorial governments and private industry are not bound, and it strongly recommends that they treat KEV remediation as a requirement in their own plans.

The catalog is big and moving fast. The feed CISA publishes (catalog version 2026.10.16, as of this writing) held 1,748 entries. We counted 361 flagged as used in known ransomware campaigns, and 307 added in the twelve months since October 19, 2025. Microsoft has the most entries at 390, and vendors known for edge devices appear often: Cisco 101, Ivanti 36, Fortinet 32, Citrix 27, SonicWall 19, Palo Alto Networks 16. Those counts come from our own tally of the feed on the date shown and will drift daily. The due dates CISA assigns have also tightened. Of the 264 entries added in 2026, 139 carry a due date three days after the add date, 78 carry 14 days and 44 carry 21 days. For comparison, of the 245 added in 2025, 226 carried 21 days. The lesson for a business: when a KEV entry matches a system you run, the clock is measured in days.

The National Vulnerability Database (NVD) at NIST is where most scanners get their CVE details. As a worked check, its record for CVE-2021-44228 (Log4Shell) shows a published date of December 10, 2021, a base score of 10.0, a status of "Analyzed," and a KEV add date of the same day with a due date of December 24, 2021 (NVD API, retrieved October 2026). Scanner output is only as good as these feeds, so a tool that stopped updating is worse than no tool, because it gives false comfort.

A deadline table you can adopt

No law sets one national patch deadline for businesses. The rules and standards set principles. The Safeguards Rule requires vulnerability assessments at least every six months (below). PCI DSS v4.0.1 requirement 6.3.1 requires you to identify and risk-rank vulnerabilities, and requirement 6.3.3 requires critical or high-security patches (as ranked under 6.3.1) within one month of release, with all other applicable patches installed in a time frame set by your own risk assessment (the wording comes from a published compilation of v4.0.1, so confirm it in your copy of the standard). NIST gives no day counts. So the numbers below are a starting point for your own policy, not a legal minimum.

Class of finding	Internet-facing system	Internal system	Who signs a late exception
On the KEV catalog	Patch or mitigate within 3 days	Within 14 days	Owner or CEO, expires within 14 days
Critical (CVSS 9.0 and above), not on KEV	14 days	30 days	Business owner of the system
High (7.0 to 8.9), or EPSS high	30 days	60 days	Business owner of the system
Medium (4.0 to 6.9)	60 days	90 days	IT manager
Low	Next maintenance cycle	Next maintenance cycle	IT manager
Unsupported (end-of-life) with exposure	Decision within 30 days: replace, isolate or accept (see below)	Decision within 60 days	Owner

Write the "mitigate" option into the policy. When a patch breaks the line-of-business application, turning off a vulnerable feature or blocking access may be the right interim step, as NIST's emergency mitigation plan allows. The mitigation needs an end date.

The right-hand column of the board slide is not the 57 percent. It is the signed exceptions. A business that can show seven findings, three late with named owners and dates, is in a better position with an insurer or a regulator than one that claims 100 percent and cannot back it up.

Scan, penetration test, red team, bug bounty

The four terms get used loosely, and vendors sell one under the name of another. NIST SP 800-115, the federal technical guide to security testing, dates to September 2008 and is old, but its structure of planning, discovery, attack and reporting still describes how a good test is run (NIST SP 800-115). Use it as a vocabulary guide, not as a current tooling manual.

What	What it buys	Typical frequency	Rough cost (unsourced; get three quotes)	Scope questions
Vulnerability scan	An automated list of known flaws and misconfigurations. Cheap, fast and repeatable. Produces false positives.	Monthly or continuous; quarterly at minimum	A few hundred to a few thousand dollars a year for a tool or service	Internal, external or both? Authenticated (with a login) or not? Which systems?
Penetration test	A skilled person tries to break in and chain flaws together. Shows real impact and finds logic flaws a scanner cannot.	Yearly, and after major changes	Often $10,000 to $40,000 for a small scope; more for large or web-heavy scope	Network, web application, wireless, social engineering? Rules of engagement? Retest included?
Red team exercise	A stealthy, goal-driven simulation of a real attacker that also tests your detection and response.	Rarely; mature programs only	Substantially more than a penetration test	Is anyone watching the alerts? Without that, buy a penetration test instead.
Bug bounty	The public reports flaws for a reward. Good for a product that outsiders already use.	Continuous	Platform fees plus rewards that you set	Needs a vulnerability disclosure policy first and staff to triage reports.

Which rules ask for what? The Safeguards Rule, 16 CFR 314.4(d)(2), says the monitoring and testing shall include continuous monitoring or periodic penetration testing and vulnerability assessments. Absent effective continuous monitoring, you must conduct annual penetration testing of your information systems, determined each year from the risk assessment, and vulnerability assessments, including systemic scans or reviews reasonably designed to find publicly known vulnerabilities, at least every six months, and whenever there are material changes to operations or business arrangements, or circumstances you know or have reason to know may have a material impact on the program (16 CFR 314.4). Lesson 06 explains who the Safeguards Rule covers. One carve-out matters here: under 16 CFR 314.6, financial institutions that keep customer information on fewer than 5,000 consumers are exempt from paragraph (d)(2), the testing requirement.

PCI DSS v4.0.1 is more specific. Requirement 11.3.1 calls for internal vulnerability scans at least once every three months, with high-risk and critical findings resolved and rescanned. Requirement 11.3.2 calls for external scans at least every three months by a PCI SSC Approved Scanning Vendor (ASV). Penetration testing is at least once every 12 months under 11.4.2 and 11.4.3 (these wordings come from a Microsoft Learn compilation of the standard and a PCI SSC presentation, because the standard itself was not reachable for us; check them against your copy). The PCI SSC blog also notes that since the future-dated requirements took effect, merchants that complete SAQ A are expected to have quarterly ASV scans under 11.3.2 (PCI SSC, August 2024). For the broader PCI picture see lesson 05, PCI DSS and payment security.

How to read a penetration test report

A report that is a 300-page scanner printout is a poor purchase. A useful one has a short executive summary in plain words, a list of findings ranked by business impact, a reproduction path for each, and a clear fix. Before you accept it, check the following.

• Does the scope in the report match the scope in the contract? Systems left out should be named.
• Is each finding tied to an asset you recognize and an owner you can name?
• Are the dates stated, and does the test period fit the PCI or Safeguards Rule cycle?
• Did the testers chain issues, such as a reused password leading to a file share and then to the finance server, or only list single flaws?
• Is a retest included? Evidence that a finding is closed is a second short report that says "retested on this date, fixed." Without it, you hold a to-do list.
• Who at the tester performed the work, and what are their credentials? You are entitled to ask.

Put the tester's report, your remediation tickets and the retest result in one folder. That folder is the single best artifact for the insurer's renewal questionnaire and a customer's security review.

Questions to ask your IT provider or testing vendor

• Which of our assets are scanned, how often, and is the scan authenticated? Show us what is missing from scope.
• How many open findings are on the KEV catalog today, how old is the oldest, and who owns it?
• What is our median time to close a critical finding over the last four quarters, and how do you calculate it?
• Does the test cover the web application and the customer portal, or only the network?
• Will you retest after we fix findings, and is that included in the fee?
• Who holds the scanner's administrator credentials, and where is the scanner's own data stored?

End-of-life software and hardware

When a vendor stops issuing security fixes, every new flaw found afterward stays open for the life of the product. Attackers know the date. Microsoft states that Windows 10 and Exchange Server 2016 and 2019 reached end of support on October 14, 2025, and that after that date those products receive no security updates, bug fixes or technical support (Microsoft Learn). Microsoft also runs a paid Extended Security Updates program for Windows 10; Microsoft Learn's enablement page lists three yearly coverage periods, but this lesson did not verify the price, the end dates or consumer terms, so check Microsoft's current page before you budget. Some vendors, Microsoft included, have offered limited paid extensions for specific server products such as Exchange 2016 and 2019; this lesson did not verify any, so ask your vendor, and treat an extension as a bridge, not a fix. Also at risk are the unglamorous devices: a ten-year-old router, a network storage box whose maker has closed, a conference room controller or a digital signage player that has not been updated since installation.

Situation	Replace	Isolate	Accept in writing
Internet-facing and unsupported (VPN, firewall, mail server, web server)	Default answer. Do it within weeks.	Only as a bridge: remove it from the internet and put it behind a supported gateway.	Almost never. If the owner insists, expiry within 30 days.
Internal, holds sensitive data, vendor gone	Plan within the budget year	Separate network segment, no internet, no email on the machine, limited accounts	Short term, with a compensating control
Machine tied to an expensive instrument (a lab or production line controller)	When the instrument is retired	Strong choice: dedicated segment, one-way data transfer, backups tested	Acceptable if isolated, with a review every 6 months
Low-value internal device, no data (a label printer on its own network)	At next refresh	Optional	Acceptable, listed in the register
Cardholder data environment (PCI scope)	Required unless a compensating control passes assessment	Segmentation must be validated	No. It will fail the assessment.

The reason to run this table at a management meeting is that every cell involves money and downtime. The cheapest control, removing an unsupported device from the internet, is often free. The most expensive, a forklift replacement, can be scheduled into the budget over two or three years if it appears in the risk register now. The same register entry, with an owner and a date, is what lets you answer an underwriter's question about unsupported systems truthfully.

Your internet-facing attack surface

The attack surface is everything an outsider can reach. It is usually larger than the owner believes. Marketing set up a campaign microsite in 2021. A contractor left a test server. A forgotten remote desktop port is open on the second firewall. The first job is to list what is exposed, using the same techniques an attacker would: your domain names, DNS records, certificates, the address ranges your internet provider assigned to you, and your cloud accounts.

Free help exists. CISA offers Cyber Hygiene scanning at no cost to U.S. federal, state, local, tribal and territorial governments and to public and private sector critical infrastructure organizations. The service scans internet-facing assets only, covering host and vulnerability status for public static IPv4 addresses, plus web application scanning for flaws including those in the OWASP Top Ten. Sign-up is by email to vulnerability@cisa.dhs.gov with the subject line "Requesting Cyber Hygiene Services," and CISA says services usually start within three business days of signing up (CISA). A business outside those categories is not eligible, and a private tool or a managed provider does the same job.

Edge devices: the favorite door

An edge device sits on the boundary between your network and the internet: firewalls, VPN gateways, routers, load balancers. They are reachable by design, they run privileged software, and many have limited logging, which makes them valuable to attackers. On February 4, 2025 the NSA, with the Australian Signals Directorate's cyber center, Canada's Centre for Cyber Security and partners including CISA and agencies in the United Kingdom, New Zealand and other countries, published three documents on edge device security: executive guidance, practitioner guidance and a "Security Considerations for Edge Devices" paper. The executive guidance lists seven strategies (hardening guidance, updates and patches count as one): know the edge, procure secure-by-design devices, apply hardening guidance, updates and patches, implement strong authentication, disable unneeded features and ports, secure management interfaces, and centralize monitoring (NSA release). The release page did not discuss end-of-life devices, so the replace-or-isolate advice above is this course's, not that guidance's.

The KEV feed shows the pattern. Cisco, Ivanti, Fortinet, Citrix, SonicWall and Palo Alto Networks together account for 231 of the 1,748 entries, and several of them involve remote access products. For a manager, translate that into four standing rules. Keep a list of every edge device with its model, firmware version and support end date. Subscribe the IT provider to the vendor's security notices and to CISA's alerts. Require phishing-resistant multifactor authentication on every remote access path (lesson 14 covers identity and access). Send the device's logs somewhere the device itself cannot erase them (lesson 11 covers detection). And when the vendor announces an actively exploited flaw in your gateway, treat the day it is announced as the start of an incident-style response, with a decision within hours, not at the next maintenance window.

Domains, DNS and certificates

• Domain registration. Record who owns each domain name, the registrar account, the renewal date and the account's multifactor setting. A domain that lapses can be bought by someone else and used to receive your email. Turn on registrar lock and auto-renew.
• DNS records. Review every record twice a year. Delete entries that point to cloud services you no longer use, because an attacker can sometimes claim the abandoned service and take over your subdomain.
• Certificates. An expired certificate is an outage and a trust problem. Keep a calendar or use automatic renewal. Know every certificate that covers a customer-facing system.
• Email authentication. Three DNS-based records tell receiving mail systems which servers may send mail for your domain. SPF lists the permitted sending servers. DKIM adds a cryptographic signature to each message. DMARC says what to do when a message fails both and sends you reports. Google's published sender requirements say that bulk senders, defined at about 5,000 messages per day to Gmail addresses, must authenticate with SPF, DKIM and DMARC, a requirement in effect since February 2024 (Google Workspace Admin Help). The practical point for any size of business: without a DMARC record set to quarantine or reject, anyone can send email that appears to come from your domain, and your customers will receive it. See module 72, lesson 05 for the setup steps.

As a management metric, report the DMARC policy for each sending domain (none, quarantine or reject) and the percent of legitimate mail that passes. A domain stuck at "none" for a year signals that nobody finished the project.

Website and e-commerce security

The website is the part of the business strangers see first, and they can attack it at any hour. Four decisions drive most of the risk.

Hosted platform or self-hosted site

Option	Who patches	Main risk	When it fits
Hosted platform (a store or site builder run by the vendor)	The vendor patches the core. You manage accounts, apps and content.	Weak admin passwords, third-party apps, vendor outage or lock-in	Most businesses under 500 employees whose site is not their product
Self-hosted content management system on a managed host	Shared: the host patches the server, you or your agency patch the CMS, themes and plugins	Out-of-date plugins and themes; abandoned add-ons	Sites needing custom features, with an agency under a maintenance contract
Self-hosted on your own servers or cloud	You do, everything	All of the above, plus the operating system and web server	Firms with in-house engineering and a patch process like the one in this lesson
Custom-built application	You or the developer, including every library	Code flaws, dependency flaws, secrets in the code	A product or portal that is the business. Needs the secure development habits below.

Plugins deserve a line of their own. Every plugin, theme and add-on is someone else's code running with your site's authority. Keep an inventory with the plugin name, the maker, the version and the last update date. Remove what you do not use. Prefer plugins with active maintenance. Set updates for the CMS core to install automatically where the vendor supports it, and test plugin updates on a staging copy first.

The OWASP Top 10 in plain words

The Open Worldwide Application Security Project (OWASP) publishes a ranked list of the most serious web application risks. The current edition at the project's site is the 2025 list. It names ten categories (OWASP Top 10:2025). The page we read did not give a release date, so we do not state one.

ID and name	In plain words	A management question
A01 Broken Access Control	A user can see or change what they should not, such as another customer's order.	Has anyone tested that one customer cannot open another's records?
A02 Security Misconfiguration	Default passwords, open storage, debug pages left on.	Who checks settings after each change?
A03 Software Supply Chain Failures	A flaw or a malicious change in a library, plugin or build tool you rely on.	Do we list our components and watch for notices?
A04 Cryptographic Failures	Sensitive data sent or stored without proper protection.	Is customer data encrypted in transit and at rest?
A05 Injection	Attacker input is run as a command or database query.	Does the developer use safe query methods and input checks?
A06 Insecure Design	The feature was built without thinking about abuse.	Is there a security review before a new feature ships?
A07 Authentication Failures	Weak login, no lockout, no multifactor option.	Do customers and staff have a second factor?
A08 Software or Data Integrity Failures	Updates or data accepted without checking they are genuine.	Are builds and updates signed or verified?
A09 Security Logging and Alerting Failures	Attacks happen and nobody sees them.	Who gets the alert, and how fast?
A10 Mishandling of Exceptional Conditions	Errors leak information or leave the system in an unsafe state.	What does the site show when something breaks?

You do not need to teach the list to every manager. You need your agency or developer to say which categories their testing covers, and to give you the date of the last test.

Web application firewall and content delivery network

A web application firewall (WAF) filters web traffic and blocks common attack patterns before they reach the site. A content delivery network (CDN) spreads copies of your site across many servers and absorbs floods of traffic. Many providers sell them together. They reduce risk and buy time when a new flaw appears, because a WAF rule can block the attack pattern while the patch is tested. They do not fix the underlying flaw. Ask the vendor three questions: is it in blocking mode or only alerting, who reviews the blocked-traffic reports, and what happens when a rule blocks a legitimate customer?

Payment page scripts

If you take cards on your own web page, the scripts on that page can steal them. This was the lesson of web-skimming attacks, where an attacker alters or hijacks a script loaded from a third party. PCI DSS v4.0.1 answers with two requirements that became mandatory on March 31, 2025, when the future-dated requirements took effect. The PCI SSC blog of August 20, 2024 states that of the 64 new requirements in v4.0, 51 were future-dated to that date. Requirement 6.4.3 requires that each payment page script loaded and executed in the consumer's browser be managed: confirmed as authorized, checked for integrity, and kept in an inventory with a written business or technical justification. Requirement 11.6.1 requires a change- and tamper-detection mechanism that alerts personnel to unauthorized modification of the HTTP headers and the contents of payment pages as received by the consumer's browser, run at least once every seven days or at a frequency set by a targeted risk analysis (wording from a Microsoft Learn compilation; the last sentence of 11.6.1 is cut off on that page, so check your copy of the standard).

The Council's FAQ 1588 (February 2025) narrows the effect for small merchants. Under SAQ A, a merchant whose page embeds a processor's payment form in an inline frame must confirm the site is not susceptible to attacks from scripts. It can do that by using techniques such as those in 6.4.3 and 11.6.1, or by obtaining confirmation from its PCI compliant processor that the processor's solution, implemented as instructed, protects the page. The criterion does not apply to a merchant that redirects customers to the processor's page, or that fully outsources payment. The FAQ adds that a provider of third-party scripts unrelated to payment is not treated as a third-party service provider for SAQ A if those scripts cannot affect card data (PCI SSC FAQ 1588). The manager's task: ask the web team for a list of every script that runs on the checkout page, who approved each, and what alerts when one changes. Lesson 05 covers which SAQ you complete.

Contract clauses for web agencies and developers

Most small businesses buy web work from an outside agency or freelancer, and the agency often holds the admin keys. The contract decides who carries the risk. Lesson 09 gives the general vendor contract clause table. For web work, add these.

Clause	What it should say	Why
Ownership and access	You own the domain, hosting account, code repository and admin accounts. The agency uses named accounts you can disable.	Prevents a hostage situation at the end of the contract
Maintenance and patching	The agency patches core, plugins and themes on a stated schedule, with critical security fixes inside the deadlines in your policy.	Puts the patch duty in writing
Security testing	Applications are tested against the OWASP Top 10 before launch and after major changes, with a report delivered to you.	Evidence for customers and insurers
Secure development	No secrets (passwords, keys) in source code; dependencies scanned; code reviewed before release.	Avoids the common developer mistakes
Payment page controls	The agency lists, justifies and monitors every script on the payment page and tells you before adding one.	Matches PCI requirements 6.4.3 and 11.6.1
Incident notice	The agency tells you within a short, fixed time (for example 24 hours) of any suspected compromise, and preserves logs.	Your own legal clocks start from your discovery; see lesson 11
Subcontractors	No subcontractor gets access without your written approval.	Supply chain control
Exit	On termination the agency hands over code, content, credentials and documentation within a set number of days.	Ends dependence

If you build software or sites for clients

Web and audio-visual integrators, consultants and agencies carry a second layer of duty: the product they deliver may be installed in a client's building or attached to a client's network. Three habits cover most of it.

Follow a secure development framework. NIST SP 800-218, the Secure Software Development Framework version 1.1 (February 2022), describes a core set of high-level practices that can be built into any development process, to reduce vulnerabilities in released software and limit the damage from those that go undetected (NIST SP 800-218). The page did not mention a revision, but this lesson did not search for drafts, so check NIST for a newer version. Practical elements for a small shop: code review by a second person before release, no passwords or keys in source code (use a secrets manager or the platform's vault), automated scanning of third-party libraries for known flaws, and build steps that others can repeat.

Keep a software bill of materials. CISA describes an SBOM as a nested inventory, a list of ingredients that make up software components. Lesson 09 gave the Log4Shell and xz examples that show why: when the next flaw lands, the question is whether it is in anything you shipped, and a list answers it in minutes. For a firm that builds, most build tools can produce the list automatically. The CISA SBOM page we read dates from 2022 and does not describe more recent federal minimum-element updates, so we do not claim a current federal template (CISA SBOM). Ask what your clients' contracts demand, and match that.

Consider the Secure by Design pledge and a disclosure policy. CISA's voluntary Secure by Design pledge asks software makers to work toward seven goals: multi-factor authentication, default passwords, reducing entire classes of vulnerability, security patches, a vulnerability disclosure policy, vulnerability reporting through CVE records, and evidence of intrusions through logs and log retention. The page says the pledge is voluntary and not legally binding, and that CISA does not enforce or verify adherence. On disclosure, it says a manufacturer should, within one year of signing, publish a policy that authorizes public testing of its products, commits not to pursue legal action against good-faith efforts to follow the policy, provides a clear reporting channel, and allows public disclosure in line with coordinated-disclosure practice (CISA). A small firm need not sign the pledge to copy the goals as an internal checklist.

A vulnerability disclosure policy is short. It says where to send a report, what you will do and in what time, and that you will not take action against someone who tests in good faith and stops short of damaging data. Pair it with a security.txt file on your site. RFC 9116, published in April 2022, defines it: a plain-text file served over HTTPS at /.well-known/security.txt, with two required fields, Contact (how to report) and Expires (a date after which the file is considered stale) (RFC 9116). Setting it up takes under an hour, and it turns a stranger's discovery into a message to you instead of a post online.

Metrics for the board

Lesson 13 gave a general dashboard and lesson 18 will carry the full catalog. For this program, five numbers do most of the work. Keep definitions stable so quarters compare.

Metric	Definition	Target to propose	Data source	Owner
Mean (and median) time to patch	Days from patch availability, or from detection, to verified fix, by severity class	KEV in days, critical in 14 to 30	Patch tool and scanner reports	IT manager
Percent of critical findings closed inside the deadline	Findings closed on time divided by all critical findings that came due in the quarter	90 percent or higher, with every miss excepted in writing	Ticket system	IT manager
Open KEV findings	Count of KEV matches on your assets, and age of the oldest	Zero past deadline	Scanner matched to the CISA feed	Security lead
Internet-facing end-of-life assets	Count of exposed assets past vendor support	Zero	Asset inventory and attack surface scan	Operations lead
Exceptions open and expired	Signed exceptions in force, and those past their expiry date	No expired exceptions	Exception register	Owner or CEO

A 90-day start for a firm with no program

Window	Action	Owner	Evidence
Days 1 to 15	List every internet-facing asset, domain and certificate. Add support end dates. Pull the KEV feed and match it to the list.	IT manager	Inventory with owner and support date columns
Days 16 to 30	Approve the deadline table and the exception form. Name who signs.	Owner or CEO	Signed policy page
Days 31 to 45	Start monthly authenticated scans, internal and external. Clear every KEV match first.	IT provider	Scan reports; closed tickets
Days 46 to 60	Decide replace, isolate or accept for each end-of-life item. Remove unneeded services from the internet.	Operations lead and owner	Decision log with dates
Days 61 to 75	Review the website: plugin inventory, payment page script list, WAF mode, agency contract clauses. Publish security.txt.	Web lead	Script list; security.txt live
Days 76 to 90	Book the annual penetration test with a retest. Report the five metrics to the board for the first time.	Security lead	Signed engagement; one-page dashboard

Questions and answers

Do we have to follow the KEV catalog if we are a private business?

No law makes it binding on you directly. Binding Operational Directive 22-01 applies to federal civilian executive branch agencies. CISA strongly recommends that private organizations prioritize KEV entries and build KEV remediation into their plans. A federal contract, a customer's security addendum or an insurer's application may turn that recommendation into a duty for you, and after a breach, a missed KEV entry is hard to defend as reasonable security.

How fast is fast enough?

No rule gives one number for every business. The Safeguards Rule sets a rhythm for assessment rather than a patch time. PCI DSS v4.0.1 requirement 6.3.3 asks for critical or high-security patches within one month of release. For flaws on the KEV list, the deadlines CISA assigned in 2026 entries mostly ran three to 21 days. A policy of three days for KEV items on internet-facing systems, with a written exception for anything later, is defensible and achievable for most firms with an automated patch tool.

Is a vulnerability scan enough for compliance?

Only for the scan requirements. The Safeguards Rule's alternative to continuous monitoring requires both annual penetration testing and vulnerability assessments at least every six months. PCI DSS has its own scan frequencies (quarterly) and a separate annual penetration test requirement. Check which rules reach you using lesson 06 and lesson 05.

What should a penetration test cost?

For a small scope, often $10,000 to $40,000. That range is a rough, unsourced working figure; get three quotes and compare scope, not price. A web application with logins and payment features costs more than a network of 30 laptops. A quote that does not name scope, test dates, a retest and the tester's qualifications is a quote for a scanner printout.

Our IT provider says patching is included. What do we ask for?

Ask for the monthly patch report by system group, the list of exceptions with reasons, the count of open KEV findings and the date each was closed. Ask who tests patches before they go to everyone and how a bad patch is backed out. "Included" is a price. The report is the product.

Can we just pay for the extended update program for old Windows machines?

Microsoft says a paid Extended Security Updates program exists for Windows 10. This lesson did not verify its current commercial price or term, so check Microsoft's page. Treat it as a bridge to replacement, not a destination, and record an end date in the risk register. It does nothing for unsupported hardware that is not Windows.

Who is responsible when a plugin on our site is hacked?

You are the one who answers to customers, card brands and regulators, whatever the contract says about the agency. The contract decides who pays you back. That is why the maintenance, notice and exit clauses above matter, and why the plugin inventory should live with you, not only with the agency.

Do we need a bug bounty?

Rarely. A bug bounty fits a product with many outside users and a team to triage reports. Start with a vulnerability disclosure policy and a security.txt file. They cost almost nothing, and they give a researcher a way to tell you what they found.

Hard questions

If attackers move this fast, isn't a three-day deadline fantasy for a 140-person company?

It is demanding, and it is achievable for the narrow class that matters. KEV matches on internet-facing systems are a handful per quarter at most (Ridgeway had seven across all assets in its quarter). The effort is bounded: keep an inventory, use an automated patch tool or managed service, hold a standing weekend window, and prepare the mitigation option for cases where the patch will break something. If the company cannot meet three days, the honest answer is a signed exception and a mitigation, which is what the policy asks for. Setting 30 days for everything because three days feels hard is the worse choice.

Patches break things. Isn't the cure sometimes worse than the disease?

Sometimes a patch causes an outage, and NIST's guidance accepts that by describing canary testing and by giving flawed patches their own plan, emergency mitigation. The answer is a small test group and a way back, not a long delay. Unpatched internet-facing systems carry the larger risk, and leaving a flaw open is itself a decision the business made.

Why spend on a penetration test when we already scan every month?

The scan checks for flaws somebody has already named. The test checks whether a person can get from a stolen password to your finance share, which no scan will show. Rules treat them as separate items for that reason. If budget is tight, run the scans well and book the test for the system that holds the most sensitive data, not for everything.

We run an e-commerce site through a processor's embedded form. Doesn't the processor carry all the PCI risk?

Not all. FAQ 1588 says an SAQ A merchant with an embedded form must confirm its page is not susceptible to script attacks, either by using techniques like requirements 6.4.3 and 11.6.1 or by getting confirmation from its compliant processor that the processor's solution protects the page when implemented as instructed. A chat widget or analytics tag that you added to the checkout page is yours. Get the processor's confirmation in writing and keep it with the SAQ.

Doesn't publishing a disclosure policy invite attacks?

It invites reports, and the flaws already exist whether or not you publish. Attackers do not wait for permission. The Secure by Design pledge treats a disclosure policy as part of the baseline, and it asks makers to promise not to pursue good-faith testers. The risk of a researcher who finds a flaw and has nowhere to send it is higher than the risk of the policy.

What this lesson could not verify

Marked plainly, as the course requires. First, the BOD 22-01 timelines and the KEV criteria were read from CISA's pages, but the CISA directive page did not state its issue date, so none is given here. Second, the KEV counts and due-date patterns are our own tally of CISA's JSON feed on one date and will change. Third, the Verizon figures other than 31 percent came from trade-press summaries (SecurityWeek and SC Media), not from the report. Fourth, the PCI DSS requirement wordings for 6.4.3, 6.3.3, 11.3 and 11.6.1 came from the PCI SSC's FAQ and blog and from secondary compilations, because the standard's PDF was not reachable; confirm them against your copy of v4.0.1. Fifth, we did not verify the commercial price or term of Windows 10 Extended Security Updates, the EPSS model version, the CVSS 4.0 handling at NVD, or whether NIST has issued a revision to SP 800-218. Sixth, the cost ranges for scans, penetration tests and the Ridgeway figures are rough or invented and carry no source. Seventh, the CIS Control 7 safeguard list was read from a v8 listing, not the v8.1 workbook.