A vendor patch calendar is a single shared view of when each product you run publishes security fixes: fixed days such as the second Tuesday of the month, quarterly cycles and rolling feeds that have no fixed day. Build it from your inventory and each vendor's own documentation, then review it quarterly.
Why a calendar helps
Most patch pain is surprise. Teams that know a big release lands Tuesday can reserve people and test capacity. Teams that find out on Wednesday are already behind. A calendar also exposes collisions, for example two large releases on the same day.
The rhythms, from vendor pages
These patterns come from the vendor pages fetched on 19 October 2026.
| Source | Rhythm | Notes |
|---|---|---|
| Microsoft | Second Tuesday monthly | Optional preview in the fourth week, out-of-band as needed |
| SAP | Second Tuesday monthly | Patch Day notes and support package notes |
| Oracle | Third Tuesday of Jan, Apr, Jul, Oct (CPU) and Feb, Mar, May, Jun, Aug, Sep, Nov, Dec (CSPU) | Pre-release announcement the Thursday before |
| Ubuntu | Rolling security notices | Mailing list, Atom and RSS available |
| Debian | Rolling security advisories | debian-security-announce list and an RSS feed |
| GitHub Dependabot | On discovery | Alerts when a new advisory matches a dependency |
Rolling sources need a different tool. For these you do not look at the calendar, you wire the feed to a place someone reads. Our guide to subscribing to Ubuntu and Debian advisories shows how.
Build it in five steps
- List what you run. Start with operating systems, databases, ERP, browsers, language runtimes and the SaaS tools that publish advisories.
- For each, find the vendor's official security page. Skip blogs and forums.
- Record the cadence in plain words and the next three dates.
- Assign an owner and a backup per source.
- Put fixed dates in a shared calendar with a reminder the day before.
Mark which entries are fixed-day and which are rolling. Rolling entries get a feed subscription and a named reader instead of a date.
Keep it honest
A calendar goes stale quietly. Oracle added a Critical Security Patch Update cycle in 2026 on top of its quarterly one, and a calendar built last year would miss it. Two habits keep yours current:
- Review the calendar once a quarter against each vendor page.
- When a vendor changes cadence, update it the same week and tell the owners.
What the calendar cannot do
It cannot tell you about unscheduled releases or exploited vulnerabilities. For those, watch the CISA Known Exploited Vulnerabilities catalog and your vendors' alert channels, and decide ahead of time who acts. The fixed calendar handles the routine, and the alert path handles the rest.
Try it yourself
Click through it at your own pace, or open it full screen.
See how monitoring keeps a view current without someone rebuilding it by hand.
Safeguard's asset discovery and SBOM scanning feed the inventory that a patch calendar depends on, and a free scan is a place to begin.
Quick check
Do all vendors patch on the second Tuesday?
No. Microsoft and SAP use the second Tuesday, Oracle uses the third Tuesday of specific months, and Linux distributions publish on a rolling basis.
How often should I review the calendar?
Quarterly is a reasonable default, and again whenever a vendor announces a change in cadence.
Sources
- Microsoft Learn, Update release cycle for Windows clients
- SAP, SAP Security Notes and News
- Oracle, Security Alerts and Critical Patch Updates
- Ubuntu, Security notices
- Debian, Security information
- GitHub Docs, Configuring notifications for Dependabot alerts
Last reviewed: 19 October 2026.
