SOC 2 Automatic Patching: Do Unattended Security Updates Need a Change Ticket?

A bare-metal SaaS company preparing for its first SOC 2 Type 2 asked us a direct question: its Ubuntu servers install security updates every night through unattended-upgrades, so does each of those updates need its own change ticket? The answer is no. SOC 2 automatic patching fits CC8.1 when the company documents it as a pre-approved standard change, limits its scope, keeps the logs of what was installed, watches for failures and reviews the results on a schedule.

Does SOC 2 CC8.1 Require a Change Ticket for Every Automatic Security Update?

SOC 2 CC8.1 requires changes to be authorized, tested, approved and implemented, and it does not say the approval has to happen one change at a time. The criterion reads: The entity authorizes, designs, develops or acquires, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures to meet its objectives. The point of focus on patching, Manages Patch Changes, asks for a process ... to identify, evaluate, test, approve, and implement patches in a timely manner on infrastructure and software.

Automatic patching can meet both when the approval sits on the procedure. IT service management already has a name for this: a standard change. ServiceNow's documentation defines it as a pre-authorized change that is low risk, relatively common and follows a specified procedure or work instruction. The company assesses and approves the procedure once, and each run inside that procedure needs no new approval.

The SOC 2 CC8.1 change management guide covers the full criterion. The SOC 2 patch management guide for on-prem covers tiers, SLAs and maintenance windows for patches that go through a ticket.

Why Automatic Patching and SOC 2 Change Management Pull in Opposite Directions

Automatic patching and SOC 2 change management pull against each other because one removes the human step and the other asks for evidence of a human decision. Security teams want critical fixes on servers within hours. A change process built on tickets and approvals adds days.

Companies usually end up in one of three places:

• Automatic updates on, policy silent. Ubuntu Server applies security updates automatically by default, so many teams have unattended-upgrades running without knowing it. The change management policy says every production change needs a ticket, and the auditor finds changes with no ticket.
• Automatic updates turned off to satisfy the policy. Patches now wait for the monthly change window, and the vulnerability scanner reports findings older than the patch SLA.
• Automatic updates on and documented as a standard change. The policy names the procedure, the scope and the evidence. This is the only one of the three that satisfies both security and the auditor.

How to Write Automatic Patching Into the Change Management Policy as a Standard Change

A standard change entry for automatic patching names the procedure, the systems it covers, what it may install, when it may reboot, who owns it and what evidence it leaves. Add it as a section of the change management policy, or as a standard change catalogue entry the policy points to.

The last row keeps the standard change honest. Widening the repositories or removing an exclusion changes the risk the original approval covered, so the change to the automatic patching configuration is itself a normal change with its own ticket.

How to Configure Unattended-Upgrades, Dnf-Automatic and WSUS to Match the Policy

Each common tool has settings that map directly to the policy table. The configuration file, kept under version control or in configuration management, becomes the evidence that the systems match the documented scope.

Ubuntu and Debian: unattended-upgrades

Ubuntu's unattended-upgrades reads /etc/apt/apt.conf.d/50unattended-upgrades for behaviour and /etc/apt/apt.conf.d/20auto-upgrades for whether and how often it runs. The default allowed origins are the -security pocket and ESM where available; -updates, -proposed and -backports are commented out.

• Scope: keep the allowed origins at -security. Add packages the policy excludes, such as kernel or database packages, to Unattended-Upgrade::Package-Blacklist.
• Reboots: Unattended-Upgrade::Automatic-Reboot is false by default. If the policy allows reboots, set Automatic-Reboot-Time to the approved window.
• Monitoring: set Unattended-Upgrade::Mail and MailReport (on-change, always or only-on-error).
• Logs: each run writes to /var/log/unattended-upgrades/unattended-upgrades.log, with package manager output in unattended-upgrades-dpkg.log. APT also records installs and upgrades with versions in /var/log/apt/history.log.

RHEL, Rocky, Alma and Fedora: dnf-automatic

dnf-automatic reads /etc/dnf/automatic.conf and runs from systemd timers such as dnf-automatic-install.timer.

• Scope: set upgrade_type = security so only security advisories install. upgrade_type = default installs all available updates.
• Install: apply_updates = yes installs; the notify-only and download timers let staging and production run different modes.
• Reboots: reboot accepts never, when-changed or when-needed. Use never unless the timer is set inside the approved window.
• Monitoring and logs: emit_via sends results by email, command or motd. dnf history list and dnf history info show each transaction.

Windows Server: WSUS automatic approval rules

WSUS Automatic Approvals approve updates for chosen computer groups by classification and product, with an optional deadline.

• Scope: create rules for the Security Updates and Critical Updates classifications only, approved first for a test group.
• What to keep out: Microsoft warns that the Upgrades classification includes Windows feature updates, and auto-approving it can upgrade devices to a new OS version.
• Evidence: the WSUS Update Status Summary report shows which computers installed which updates.

Baseline settings for these files belong in the hardening standard. The SOC 2 configuration baselines guide for bare metal covers keeping them under drift checks.

What SOC 2 Auditors Sample for Automatic Patching

SOC 2 auditors sample automatic patching the same way they sample any recurring control: they read the design, then pick dates or hosts from the observation period and ask for evidence. Expect requests like these:

1. The policy entry for automatic patching as a standard change, with the date and approver.
2. The configuration on sampled hosts, showing the repositories, exclusions and reboot settings match the policy.
3. Run logs for sampled dates, such as /var/log/apt/history.log entries or dnf history info output, showing what installed on each date.
4. Failure handling: an alert from a failed run and the ticket or note that resolved it.
5. Periodic reviews: the monthly sign-offs that someone looked at what was applied and what failed.
6. Normal change tickets for anything outside scope, such as the last kernel upgrade or a database version upgrade.

Vulnerability scan results back this up. If the scanner shows security fixes landing within the patch SLA, the automatic process is doing its job; the SOC 2 vulnerability scanning guide for on-prem covers that side. Package logs on servers sit outside what most GRC platforms read, so plan how they are collected. The guide to SOC 2 evidence collection on-prem covers dated evidence for those systems.

What Breaks a SOC 2 Automatic Patching Standard Change

A SOC 2 automatic patching standard change breaks when the running configuration installs more than the approval covered, or when the evidence is missing. These are the gaps that turn into audit exceptions:

The guide to SOC 2 change management with tickets covers the normal and emergency change paths that pick up everything outside the standard change.

How to Set Up SOC 2 Automatic Patching Before the Observation Period

SOC 2 automatic patching takes a few days to set up properly, and it needs to be in place before the observation period starts so every sampled date has evidence. A practical order:

1. Find what is already running. Check each host for unattended-upgrades, dnf-automatic timers or WSUS approval rules, and record the current settings.
2. Write the standard change entry in the change management policy, using the table above, and record a dated approval.
3. Align the configuration to the policy: security repositories, exclusions, reboot window, notifications.
4. Stage first. Point staging hosts at an earlier schedule than production.
5. Fix log retention and send package logs to central logging.
6. Add failure alerts and schedule the monthly review with a named owner and backup.
7. Run one dry run. unattended-upgrade --dry-run shows what would install without changing anything.

SOC 2 Automatic Patching Comes Down to One Approval and Continuous Evidence

SOC 2 automatic patching lets security fixes land in hours and still meets CC8.1, because the approval covers the procedure and the logs cover each run. The work is in the scope limits, the logs and the monthly review, and that work is small compared with ticketing every nightly update. The SOC 2 for bare metal and on-prem infrastructure page lists the other controls that change when you run your own servers.

Related Guides

• SOC 2 Vulnerability Risk Acceptance: What to Do When There Is No Vendor Fix
• Datadog for SOC 2 Vulnerability Scanning: Datadog vs Wazuh vs Nessus On-Prem

Frequently Asked Questions

Do automatic security updates need a change ticket for SOC 2?

No. Automatic security updates can be documented as a pre-approved standard change in the change management policy. The approval covers the procedure: security repositories only, named exclusions, a reboot window and monitoring. Each run is then evidenced by package logs, such as /var/log/apt/history.log or dnf history, with no separate ticket.

Is unattended-upgrades acceptable for SOC 2?

Yes, unattended-upgrades is acceptable for SOC 2 when its scope matches a documented standard change. Keep the allowed origins at the security pocket, exclude packages the policy reserves for normal changes, set reboot behaviour to the approved window, enable mail reports, and retain the logs in /var/log/unattended-upgrades/ for the full observation period.

Should kernel updates be applied automatically under SOC 2?

SOC 2 does not decide this; the company's policy does. Many companies exclude kernel packages from automatic updates because they need a reboot, and handle them through a normal change with a maintenance window. If kernel updates stay in scope, allow automatic reboots only inside a defined window and record that in the policy.

What evidence do SOC 2 auditors want for automatic patching?

SOC 2 auditors want the policy entry approving automatic patching as a standard change, the configuration on sampled hosts, package logs showing what installed on sampled dates, failure alerts and how they were resolved, and monthly review sign-offs. Vulnerability scan results showing fixes within the patch SLA support the evidence.

Does SOC 2 set a deadline for applying security patches?

No. SOC 2 sets no patch deadline. The CC8.1 point of focus asks for patches to be implemented in a timely manner, and the company defines what timely means in its own policy, usually as SLAs by severity. The auditor then tests against those SLAs.

Sources

• AICPA, 2017 Trust Services Criteria (With Revised Points of Focus, 2022)
• ServiceNow, Change types (standard change definition)
• ITSM.tools, ITIL 4 change enablement
• Ubuntu Server documentation, Automatic updates
• Ubuntu manpages, unattended-upgrade(8)
• GoLinuxCloud, APT history and rollback on Linux
• DNF documentation, DNF Automatic
• DNF5 documentation, history command
• Microsoft Learn, Approve and deploy updates in WSUS