Vulnerability Management Procedure

Approval #

Revision History #

Review cycle: Every year, and when the Cybersecurity and Infrastructure Security Agency (CISA) changes Binding Operational Directive (BOD) 26-04.

Mandate. The CISO issues this procedure to carry out the Vulnerability Management Policy (POL-VM-001). The vulnerability management team runs it. The requirements behind it are:

• Cybersecurity and Infrastructure Security Agency (CISA) Binding Operational Directive (BOD) 26-04, Prioritizing Security Updates Based on Risk, and CISA’s Implementation Guidance for Prioritizing Security Updates Based on Risk.
• BOD 23-01, on asset discovery and vulnerability detection.
• BOD 23-02, on management interfaces that can be reached from the internet.
• BOD 25-01, on secure cloud configurations.
• BOD 26-02, on edge devices that no longer receive vendor support.
• National Institute of Standards and Technology (NIST) Special Publication (SP) 800-53 controls RA-5, RA-5(2), RA-5(3), RA-5(5), RA-5(11), SI-2, SI-2(2), and SI-2(3).

BOD 26-04 required agencies to revise their procedures to its risk model by August 9, 2026. Its remediation deadlines and asset tags become mandatory on December 7, 2026.

1. Purpose and Scope #

Use this procedure to find vulnerabilities, set a due date for each one, fix or isolate it, confirm the fix, and report to CISA. The people who use it are the vulnerability management team, system and platform administrators, System Owners, Information System Security Officers (ISSOs), the Security Operations Center (SOC), and the incident response team.

In scope:

• Every Internet Protocol (IP) addressable asset that is not ephemeral, on a network that the Organization operates or that a provider operates for it. This includes servers, workstations, laptops (including laptops used off the network), virtual machines, network devices, printers, IP telephones, and cameras, on premises or in the cloud.
• Mobile devices, where the vulnerability scanner can examine them.
• Cloud infrastructure that the Organization controls, and the Organization’s share of platform and software services under the shared responsibility model.
• Container images, in the build pipeline and the registry.
• Weaknesses without a Common Vulnerabilities and Exposures (CVE) ID, such as misconfigurations, web application flaws, and weak identity settings. BOD 26-04 Table 1 covers only findings with a CVE ID. The Organization’s own timeframes cover the rest.

Out of scope: systems that are physically air-gapped (a logically separated network is in scope), guest wireless networks that are physically separate from Organization networks, and national security systems.

2. Roles and Responsibilities #

3. Definitions #

4. Tools and Systems of Record #

5. Detect Vulnerabilities on Every Asset #

The vulnerability management team runs scanner agents on every server, workstation, and laptop. The agents report installed software and vulnerabilities continuously, so the team sees a new vulnerability without waiting for a scan. For assets that cannot run an agent, the team runs authenticated network scans. The team meets the minimum in this table for each activity. Continuous agent detection exceeds the BOD 23-01 minimums, but the minimums still apply to every asset without an agent.

To find assets that a discovery scan misses, the team also uses the EDR tools, the MDM tool, passive network discovery, and the inventories of the Organization’s cloud accounts.

1. Keep coverage complete. Each week, the vulnerability management team compares the assets in the vulnerability scanner with the authoritative inventory and the CDM asset list. For each asset with no detection method, the ISSO opens a ticketing system gap ticket. The ISSO keeps the ticket open until the team covers the asset or the System Owner accepts the gap in writing.
2. Keep agents reporting. Administrators include the scanner agent in every standard server image and endpoint build, so each new asset reports from its first start. An agent that has not reported for more than 7 days is a coverage gap, and the ISSO opens a gap ticket for it.
3. Cover cloud workloads through their images. Administrators build cloud workloads from images that include the agent, and the team scans each image before use. For a workload too short-lived to scan, the team relies on the scan of its image.
4. Make every scan authenticated. System Owners authorize dedicated scanning accounts for their components. Administrators use these accounts for scanning only and protect them as privileged accounts. When a scan cannot log in, the ISSO opens a ticketing system ticket. The team scans the asset again after administrators fix the access problem. An unauthenticated result does not count as coverage.
5. Use only approved methods. For specialized equipment that cannot take an agent or credentials, the team uses another method only after CISA approves it, as BOD 23-01 requires.
6. Keep detection content current. Each day, the team confirms that the scanner detection content is no more than 24 hours behind the vendor’s latest release. The team repeats any scan that ran on outdated content.
7. Keep CDM current. After each discovery cycle, the team confirms that results reach the CDM Agency Dashboard within 72 hours of the end of the cycle. The team investigates any break in the feed as soon as it finds one.

Evidence: the scanner coverage and authentication reports, the daily content checks, the weekly coverage reconciliation, the gap tickets in the ticketing system, and the CDM feed status.

6. Take In New Vulnerability Information #

6.1 Act on each KEV catalog addition #

CISA aims to add a vulnerability to the KEV catalog within 24 hours of confirming that it meets the catalog’s criteria. CISA can also add an older CVE at any time. These targets match the first step of CISA’s forensic triage guidance.

6.2 Add CISA’s enrichment data to each CVE #

The vulnerability management team runs automation that reads two values for each CVE ID from the CVE record: Automatable and Technical impact. CISA’s Vulnrichment Program publishes these values. The automation applies them to the findings in the vulnerability scanner. CISA always publishes the values for a CVE ID in the KEV catalog. Until CISA publishes them for any other CVE ID, the team treats Automatable as no and Technical impact as total, as CISA does. CISA updates CDM within three business days after it completes its enrichment. The team then re-checks the due date.

6.3 Act on Emergency Directives #

CISA sets the actions, deadlines, and reports in each Emergency Directive, and every Emergency Directive is mandatory. The CISO assigns an owner on the day CISA issues it. When the directive’s deadline is earlier than the due date this procedure gives, the directive’s deadline applies. The owner reports to CISA exactly as the directive specifies.

Each Emergency Directive (ED) below was on CISA’s list of active directives on October 21, 2026. Each owner keeps the directive’s required actions in place for the affected products until CISA closes it.

The CISO checks CISA’s directives page each month and updates this table when CISA issues or closes a directive. Executive Order 14409 of June 2, 2026 directs CISA to issue directives that speed the cyber defense of civilian federal systems. The CISO adds each new directive to this procedure.

6.4 Work with CISA Cyber Hygiene #

• CISA scans the Organization’s public addresses through its Cyber Hygiene service, as an attacker would see them. Administrators must not block its source addresses, add them to an allow list, or open ports for them.
• The SOC may suppress SIEM alerts from the published Cyber Hygiene source addresses. The addresses change without notice, so the SOC checks the list in each weekly report against its suppression rules.
• If any system blocks a Cyber Hygiene address, administrators remove the block. The vulnerability management team tells CISA which addresses the system blocked, at vulnerability@cisa.dhs.gov, so CISA can restart scanning.
• The vulnerability management team loads each weekly report into the vulnerability scanner and reconciles every finding. The team marks any asset with a Cyber Hygiene finding as publicly exposed.
• Each quarter, and whenever CISA asks, the CISO attests the Organization’s publicly exposed IP addresses and domain names. The CISO uses CISA’s Cyber Hygiene scope-change process and lists every addition and removal since the previous quarter.
• The CISO submits updated Cyber Hygiene acceptance letters when CISA asks for them.
• Cyber Hygiene also checks the settings that CISA BOD 18-01 requires. Administrators serve every public website and web service over Hypertext Transfer Protocol Secure (HTTPS) only, with Hypertext Transfer Protocol (HTTP) Strict Transport Security (HSTS).
• Administrators turn off SSLv2, SSLv3, 3DES, and the Rivest Cipher 4 (RC4) cipher on web and mail servers. They set mail servers to offer encryption through the Start Transport Layer Security (STARTTLS) command.
• For every second-level domain, administrators publish a Sender Policy Framework (SPF) record. They also publish a Domain-based Message Authentication, Reporting, and Conformance (DMARC) policy of “reject”.
• The vulnerability management team records each missing BOD 18-01 setting as a finding in the vulnerability scanner. The team rates its severity and gives it the Organization’s timeframe for that severity, as for any weakness without a CVE ID. The System Owner fixes it by the due date.

6.5 Act on Ransomware Vulnerability Warning Pilot notices #

CISA notifies agencies of internet-facing systems with vulnerabilities or misconfigurations that ransomware actors commonly use. The team treats the named asset as publicly exposed and sets its due date in the usual way. The SOC checks the asset for signs of compromise the same day.

6.6 Take in vulnerability disclosure reports #

The vulnerability management team logs each report received under the Vulnerability Disclosure Policy (POL-VDP-001) in the ticketing system and validates it. The team records each valid report as a finding under this procedure. A finding without a CVE ID gets the Organization’s timeframe for its severity.

6.7 Watch vendor advisories and exploitation inside the Organization #

The team follows the vendors’ security advisories for every product in the inventory. If the SOC sees an attacker exploiting an open vulnerability in the Organization’s environment, the SOC reports an incident under the Incident Response Plan (PLAN-IR-001). The team then handles each affected asset as a “3 days and forensic triage” finding, even if Table 1 gives a longer timeline.

Evidence: the ticket times for each KEV addition, the Cyber Hygiene weekly reports and scope attestations, the Emergency Directive reports, and the disclosure reports in the ticketing system.

7. Set Each Finding’s Due Date #

7.1 Answer the four decision points #

Each finding with a CVE ID has four answers in the vulnerability scanner. The platform sets them automatically from the sources below, and the team’s automation loads any value the platform does not take directly. Each working day, the vulnerability management team reviews the answers on new findings and corrects any that are wrong. The team records the reason for each correction on the finding.

1. In the KEV? From the KEV catalog.
2. Publicly exposed? From the asset’s exposure tag, scanner external scanning, CDM, and Cyber Hygiene, judged under CISA’s Internet Exposure Reduction Guidance. If any source shows the asset as exposed, the answer is yes. The team treats an asset of unknown exposure as exposed, which is stricter than CISA’s default.
3. Automatable? From the CVE record. The answer is no until CISA publishes a value.
4. Technical impact? From the CVE record. The answer is total until CISA publishes a value.

7.2 Read the timeline from Table 1 #

In Table 1 of BOD 26-04, CISA sets the longest time allowed for each combination of answers. Days are calendar days.

7.3 Read the Organization’s timeframe #

Under its RA-5 parameters, the Organization sets a timeframe for every finding, with or without a CVE ID. The timeframe depends on the severity that the vulnerability scanner assigns.

7.4 Take the earliest deadline #

The due date is the start date plus the shortest of these deadlines:

• The Table 1 timeline, for a finding with a CVE ID.
• The Organization’s timeframe for the finding’s severity.
• Any deadline in an Emergency Directive or other CISA direction.

The start date is the earlier of two dates: the date the vulnerability scanner first detected the finding, and the date CISA added its CVE ID to the KEV catalog.

“Fix on system upgrade” never extends an Organization timeframe. For example, a critical finding that Table 1 places at “fix on system upgrade” is still due in 30 days. CISA allows any agency to remediate faster than Table 1 requires, and the Organization’s timeframes are faster for many findings.

Within a timeline, the team may order the work using other exploitation data from the vulnerability scanner, such as the Exploit Prediction Scoring System (EPSS). The team never uses that data to move a due date later.

7.5 Re-check the due date when the facts change #

• When CISA adds a finding’s CVE ID to the KEV catalog, the team moves the due date to the earlier of the current due date and the due date in the KEV catalog entry.
• When the team learns that an asset is publicly exposed, it re-checks the due date, which usually becomes earlier.
• When a mitigation changes a decision point, for example by removing the asset from the internet, the Table 1 timeline can become longer. The Organization’s timeframe stays the same.
• The team records each due-date change on the ticket with the fact that changed. No one may move a due date later for any other reason.

7.6 Worked examples #

Evidence: the decision-point answers and due date on each finding in the vulnerability scanner, and the due-date changes recorded on each ticket.

8. Triage Assets for Compromise #

The incident response team must triage every “3 days and forensic triage” finding and every asset where the SOC has seen exploitation. Administrators must remediate or mitigate the asset within 3 days. The incident response team must decide whether an attacker compromised it. The targets below are CISA’s recommended times, counted from the KEV addition (Implementation Guidance for Prioritizing Security Updates Based on Risk). CISA requires an adequate triage, and the targets are guidance. When the KEV entry gives its own triage steps, the team follows them.

The incident response team writes a forensic triage report with these parts:

• The incident timeline.
• The timeline of response actions.
• The technical findings: who did what, where, and when.
• The containment and mitigation done so far.
• The recommended next steps.

The team keeps the report as a record with the incident. The team preserves logs as the Agency Logging Plan (PLAN-LOG-001) requires.

High Value Assets and mission-critical systems. The System Owner of each HVA and mission-critical system keeps a plan for triaging and patching that system within 3 days. The Authorizing Official approves the plan. In it, the System Owner records an advance decision between keeping the system available and isolating it to protect its integrity.

Evidence: the forensic triage report, the evidence log, the incident record, and each approved HVA plan.

9. Fix or Mitigate Each Finding #

9.1 Open the remediation ticket #

For each vulnerability, or group with the same fix on the same system, the vulnerability scanner opens a remediation ticket in the ticketing system. On each ticket, the team records the CVE ID, the affected assets, the four decision-point answers, the due date, and the owning team.

9.2 Deliver fixes due in more than 3 days #

• Endpoints: administrators release the update through the MDM tool deployment rings, first to a pilot group and then to everyone else. They confirm each endpoint’s update state in the MDM tool.
• Servers, network devices, and cloud workloads: administrators test the update before production. They deploy it through a normal change that the Configuration Control Board approves.
• Administrators record the change number and the completion on the ticket.
• If an update fails or breaks a system, administrators roll it back under the change, apply a mitigation, and record both on the ticket. The original due date still applies.

9.3 Deliver fixes due in 3 days #

• Administrators use the emergency change process in the Configuration Management Procedures (PROC-CM).
• Administrators shorten the deployment rings so the pilot and the full release happen on the same day.
• For a mission-critical system, administrators follow the plan that the Authorizing Official approved. They test critical systems by hand where needed and patch the rest through automation, so staff time goes to the critical systems.

9.4 Mitigate when a fix is not available in time #

• For a vulnerability in the KEV catalog, the only accepted mitigation is the required action in its catalog entry. If administrators cannot complete that action by the due date, they must remove the asset from the network.
• For any other vulnerability, administrators isolate it. They decommission the asset, remove the vulnerable software, segment or isolate the asset, or place it behind a software-defined perimeter or a proxy.
• Administrators record the mitigation on the ticket, and the team re-checks the due date if a decision point changed. The team closes a finding only after remediation, so the finding stays open while a mitigation is in place.
• When the flaw is in a component built into another vendor’s product, the System Owner gets the fix from the vendor that supplied the product.
• Interim protections, such as EDR prevention rules, SIEM detections, or web application firewall rules, reduce risk while a fix is pending. They do not count as the KEV catalog’s required action. They change a due date only if they change a decision point.

9.5 Replace or isolate end-of-support software and devices #

Vendors no longer release security updates for end-of-support software and devices, so patching cannot fix them.

• System Owners decommission end-of-support edge devices under the End-of-Support Edge Device Plan (PLAN-EOS-001) and BOD 26-02. The deadlines are:
  • By February 5, 2027: each device on CISA’s end-of-support list whose support ended on or before that date.
  • By August 5, 2027: every identified end-of-support edge device.
  • From February 5, 2028: each edge device on or before its end-of-support date.
• System Owners replace or isolate other end-of-support software. The ISSO tracks it as a POA&M item until it is gone.
• The CISO reports these counts in the Federal Information Security Modernization Act (FISMA) CIO metrics on end-of-life and end-of-support assets.

9.6 Secure management interfaces exposed to the internet #

BOD 23-02 covers management interfaces that anyone can reach from the internet, over the web, Secure Shell (SSH), Remote Desktop Protocol (RDP), Telnet, or another management protocol. Within 14 days of finding such an interface, or of a CISA report about it, the System Owner must take one of these two actions.

• Take the interface off the internet, so that only an internal network can reach it. CISA recommends an isolated management network.
• Protect the interface with zero trust access control, through a policy enforcement point separate from the interface. CISA prefers this action.

System Owners must make new devices meet this rule before they connect. BOD 23-02 does not cover the management portals of cloud service offerings.

9.7 Meet the cloud configuration baselines #

For cloud tenants in BOD 25-01 scope, administrators implement every mandatory SCuBA policy and report the SCuBA results to CISA. They meet each new mandatory policy by the date CISA sets. Administrators bring a new tenant up to the baselines and under continuous monitoring before it receives an authorization. The Authorizing Official may accept the risk of a deviation. Administrators explain each deviation in the results they report to CISA.

9.8 Fix weaknesses without a CVE ID #

The team gives misconfigurations, web application flaws, and weak identity settings the Organization’s timeframe for their severity. Administrators and ISSOs handle them with the same ticket, verification, and POA&M steps as every other finding.

Evidence: the remediation tickets with their change numbers and completion dates, the deployment records in the MDM tool, the mitigation records, and the end-of-support inventory.

10. Verify and Close Findings #

1. The team closes a finding only after the vulnerability scanner stops detecting it, on the agent’s next report or a follow-up authenticated scan. For a decommissioned asset, the team closes the finding once the asset is gone from the inventory and from CDM.
2. The team does not close a finding because an administrator marked its ticket done. If the vulnerability scanner still detects the vulnerability, the team reopens the ticket, and the original due date still applies.
3. False positives. The ISSO documents why a finding is not real, with evidence such as the installed version or a configuration export. The vulnerability management team approves the exception in the vulnerability scanner, which suppresses the finding. The ISSO re-validates each suppression at the system’s annual assessment.
4. Recurrence. The team treats a vulnerability that returns after closure as a new finding with a new due date. The ISSO records the cause, for example an image rebuilt from an old template, and opens a corrective ticket.
5. The team measures the time from first detection to confirmed fix for every finding, using the dates in the vulnerability scanner, and compares it with the timeframes.

Evidence: the detection history in the vulnerability scanner for each closed finding, the reopened tickets, the approved false-positive exceptions with their evidence, and the corrective tickets for recurrences.

11. Handle Missed Due Dates and Risk Acceptance #

1. When a finding will miss its due date, the ISSO opens a POA&M item in the GRC system no later than the due date. The ISSO follows the POA&M Management Procedure (PROC-POAM-001) and records the reason, the interim mitigation, and the completion date in the item.
2. Each week, the CISO reviews past-due findings with System Owners. The CISO escalates any past-due finding with a directive deadline to the Authorizing Official at once.
3. Risk acceptance. Only the CIO, as Authorizing Official, may accept the risk of an unremediated finding. The CIO records the acceptance in the GRC system, with the compensating controls and an expiration date.
4. No extension of directive deadlines. The CIO cannot use a risk acceptance to extend a directive deadline, and CISA grants no waivers for directive actions. If administrators cannot remediate a KEV finding in time, they must apply the catalog’s required action or remove the asset from the network. For a special case, the CISO asks CISA for help and an agreed time frame at CyberDirectives@cisa.dhs.gov.
5. The team keeps accepted and past-due findings visible in the vulnerability scanner. The team reports them to CISA where a directive’s reporting template requires it.

Evidence: the POA&M items, the signed risk acceptances in the GRC system, the weekly past-due review notes, and any correspondence with CISA.

12. Manage Vulnerabilities in Third-Party and Cloud Services #

• The vulnerability management team keeps an inventory of the Organization’s systems that third parties host. This includes services authorized under the Federal Risk and Authorization Management Program (FedRAMP). The team gets vulnerability status from each provider through collaborative continuous monitoring.
• FedRAMP-authorized services: the team works through the FedRAMP Program Management Office. FedRAMP requires providers to follow its Vulnerability Detection and Response (VDR) and Vulnerability Evaluation and Reporting (VER) rules, which carry out BOD 26-04, from December 7, 2026, with a grace period to March 7, 2027. The team reads the provider reports as described in Read FedRAMP Provider Vulnerability Reports.
• Services without FedRAMP authorization: the System Owner works directly with the provider. The System Owner requires the provider to meet the same requirements and to document and report every deviation to the Organization.
• Reporting: a commercial provider reports its outstanding vulnerabilities to the Organization, and the Organization reports them to CISA. When another federal agency provides the service, that agency reports to CISA.
• Contracts: Contracting Officers review the contracts for systems in scope. They add the remediation deadlines and status reporting to service agreements that lack them.

The Organization’s share of vulnerability management depends on the service model:

Evidence: the inventory of systems that third parties host, the provider vulnerability reports, the FedRAMP continuous monitoring deliverables, and the contract clauses.

12.1 Read FedRAMP Provider Vulnerability Reports #

Each FedRAMP provider reports its vulnerability work at least monthly in a human-readable report (FedRAMP Consolidated Rules for 2026, VER-TFR-MHR). Most providers also offer the same data in a machine-readable format for automated retrieval (FedRAMP Consolidated Rules for 2026, VER-TFR-MRH). For each vulnerability, the report gives the PAIN rating, whether it is internet-reachable and likely exploitable, and whether it is overdue or accepted (FedRAMP Consolidated Rules for 2026, VER-RPT-VDT, VER-RPT-AVI).

The provider’s timeframes run from evaluation and depend on its certification class (FedRAMP Consolidated Rules for 2026, VDR-TFR-PVR). FedRAMP says agencies should not treat the classes as one-for-one replacements for impact levels. Classes B and C cover most moderate systems:

N1 and N0 have no timeframe. The Organization’s own due dates in Set Each Finding’s Due Date apply to the parts of the service the Organization manages, by the service model table above. The same PAIN scale sets how fast a provider reports an incident to the Organization (FedRAMP Consolidated Rules for 2026, IEC-CSO-IIR).

Evidence: the retrieved reports, filtered lists, review records, POA&M items, risk decisions, incident records, and escalations.

13. Follow the Recurring Schedule #

Scanner agents, KEV matching, and SOC monitoring run all the time. Each role also does the following work on a fixed schedule.

14. Report to CISA and OMB #

The owners below send these reports to CISA and the Office of Management and Budget (OMB):

Exposure tags. System Owners tag each asset reachable from outside the network with four values. The values are organization and sub-organization, environment (production or development), exposure (public or internal), and asset type (server, application, or network device). System Owners set them as scanner asset tags, and the team sends the same tags to CDM. The team reports every asset to CDM with all its IP addresses, including private ones.

CISA contacts:

• CyberDirectives@cisa.dhs.gov: directive questions and special cases.
• central@cisa.dhs.gov: signs of compromise a directive asks for. The incident report itself goes through the CISA Incident Reporting Form.
• vulnerability@cisa.dhs.gov: Cyber Hygiene.

Evidence: each submitted report with its date, the CDM submission records, and the CISO’s attestations.

15. Measure Performance #

The CISO tracks the program with these measures:

16. Keep Records #

Each record is kept in the system below. The record owners keep records under the Organization’s records schedule.

17. Related Documents #

18. References #

These are the sources this document cites, with a link to each official text.

• CISA BOD 18-01: Enhance Email and Web Security, October 16, 2017.
• CISA BOD 23-01: Improving Asset Visibility and Vulnerability Detection on Federal Networks, October 3, 2022.
• CISA BOD 23-02: Mitigating the Risk from Internet-Exposed Management Interfaces, June 13, 2023.
• CISA BOD 25-01: Implementing Secure Practices for Cloud Services, December 17, 2024.
• CISA BOD 26-02: Mitigating Risk From End-of-Support Edge Devices, February 5, 2026.
• CISA BOD 26-04: Prioritizing Security Updates Based on Risk, June 10, 2026.
• CISA ED 24-01: Mitigate Ivanti Connect Secure and Ivanti Policy Secure Vulnerabilities, January 19, 2024.
• CISA ED 25-02: Mitigate Microsoft Exchange Vulnerability, August 7, 2025.
• CISA ED 25-03: Identify and Mitigate Potential Compromise of Cisco Devices, September 25, 2025.
• CISA ED 26-01: Mitigate Vulnerabilities in F5 Devices, October 15, 2025.
• CISA ED 26-03: Mitigate Vulnerabilities in Cisco SD-WAN Systems, February 25, 2026.
• CISA Incident Reporting System: Incident Reporting Form (CISA Services Portal): Incident Reporting Form (CISA Services Portal), August 29, 2024.
• CISA Known Exploited Vulnerabilities Catalog, updated continuously.
• Executive Order 14409: Promoting Advanced Artificial Intelligence Innovation and Security, June 2, 2026.
• Federal Incident Notification Guidelines, April 1, 2017.
• Federal Information Security Modernization Act of 2014 (44 U.S.C. § 3551 et seq.), December 18, 2014.
• FedRAMP Consolidated Rules for 2026 (including 20x Key Security Indicators), June 24, 2026.
• Implementation Guidance for Prioritizing Security Updates Based on Risk, June 10, 2026.
• NIST SP 800-40 Rev. 4: Guide to Enterprise Patch Management Planning: Preventive Maintenance for Technology, April 6, 2022.