How do you ship an emergency dependency patch during a SOC 2 window?

Use an expedited change path that you defined in advance: a named approver, minimum testing, a pull request record, and a follow-up review within a few days. Speed is fine. Skipping the record is what causes exceptions. Write the path before the window opens so the emergency is a sample, not a surprise.

Why emergencies are an audit topic

A critical vulnerability in a library you ship will arrive during your window at some point. Auditors know this and often sample emergency changes on purpose, because that is when controls get bypassed. A team that handled it cleanly shows the control works under pressure.

Define the expedited path in policy

Write a short paragraph in your change management policy:

• What qualifies: an actively exploited flaw, a critical vulnerability in a reachable component, or a production outage.
• Who can approve: a named role, with a backup.
• What testing is the minimum: for example, the automated suite plus a smoke test of the affected feature.
• What happens afterward: a retrospective review by someone who did not write the change, within a set number of days.

CISA says organizations should use its Known Exploited Vulnerabilities catalog as an input to prioritization. Many teams use presence on that list, or a vendor statement of active exploitation, as the trigger for the expedited path.

The sequence during an incident

1. Open a ticket first, even a one line one, and note the time.
2. Confirm exposure: do you ship the affected version, and is the vulnerable code reachable?
3. Branch, upgrade or patch, and open a pull request.
4. Get the named approver to review. Approval in a chat thread alone is not enough, so approve on the PR or paste a link.
5. Run required checks. If a check is skipped for speed, write why on the PR.
6. Deploy, then confirm the fix with a rescan.
7. Close the ticket with times and links.

What to avoid

• Pushing straight to the default branch with an admin bypass and no PR. If bypass must exist, log its use and review each one.
• Skipping the ticket because "we will write it up later". Later rarely happens.
• Closing the alert without a rescan.

After the fire

Hold a short review. Did the path work? Were any steps skipped? If a gap showed up, fix the process and note the change. An auditor will treat a documented improvement better than a clean record that looks too tidy.

Try it yourself

Open the demo and follow a newly disclosed issue from detection to a fix you can act on. Notice how much of the evidence trail is produced during the response itself.

Click through it at your own pace, or open it full screen.

Where Safeguard fits

Safeguard's zero-day discovery, reachability analysis and fix pull requests can shorten the confirm and fix steps, and its evidence automation keeps the trail. Autonomous remediation is off by default with every category on Manual. Free scan: https://gold.safeguard.sh/scan.

Quick check

Sources

• CISA, Known Exploited Vulnerabilities Catalog
• GitHub Docs, About protected branches
• AICPA and CIMA, SOC suite of services

Last reviewed: 19 October 2026.