Overview
Patch Management Process is the structured approach used to identify, evaluate, test, and apply security and system patches to reduce operational and security risks. It ensures vulnerabilities are remediated in a timely, documented, and auditable manner in alignment with SOC 2 CC7.1.
Step-by-Step Process
Inventory systems and dependencies
The Engineering Lead maintains an up-to-date inventory of in-scope infrastructure, applications, operating systems, and third-party dependencies. This inventory defines which assets are subject to monthly patching and vulnerability scanning.
Role: Engineering Lead
Monitor for available patches
Engineering reviews automated alerts and dashboards from approved tools to identify newly released patches and vulnerabilities. The output is a list of applicable patches with severity ratings.
Role: Engineering Lead
Assess patch criticality
Identified patches are reviewed to determine severity, exploitability, and business impact. Patches are prioritized based on risk, with critical and high findings scheduled for expedited remediation.
Role: Engineering Lead
Test patches in non-production
Patches are applied in a staging or test environment to confirm system stability and compatibility. Testing results are documented before any production deployment.
Role: Engineering Lead
Approve and schedule deployment
Approved patches are scheduled for production deployment during defined maintenance windows. Any required change approvals are recorded prior to deployment.
Role: Engineering Lead
Deploy patches to production
Patches are deployed to production systems using approved tools and automation. Deployment logs are retained as evidence of completion.
Role: Engineering Lead
Verify remediation and document results
Post-deployment scans or reports are reviewed to confirm vulnerabilities are resolved. Evidence is archived to support SOC 2 audit requirements.
Role: Engineering Lead
What You Need Before Starting
- System and application asset inventory
- Access to Dependabot, Snyk, and AWS Systems Manager
- Defined patching and maintenance window schedule
- Severity classification criteria for vulnerabilities
Evidence Your Auditor Expects
- Dated Dependabot pull request showing merged security update
- Snyk vulnerability report export with scan date and remediation status
- AWS Systems Manager Patch Compliance report with timestamp
- Change approval record or ticket referencing patch deployment date
How This Looks In Your Tools
Dependabot
In GitHub, navigate to the repository and select Settings > Security & analysis. Enable Dependabot alerts and Dependabot version updates.
Review open Dependabot pull requests under the Pull requests tab. Validate the dependency update, review the security advisory details, and merge the pull request once tests pass.
Retain the merged pull request ID and merge timestamp as evidence of patch application.
Snyk
Log in to Snyk and navigate to Projects from the left-hand menu. Select the relevant project to view identified vulnerabilities.
Review the Vulnerabilities tab, filter by severity, and select issues requiring remediation. Follow Snyk’s recommended fix or upgrade guidance.
After remediation, trigger a re-scan using the Re-test now button and export the updated report with the scan date.
AWS Systems Manager
In the AWS Console, go to AWS Systems Manager > Patch Manager. Select Patch compliance to view current patch status across instances.
Create or review an existing Patch Baseline under Patch Manager > Patch baselines, then associate it with a maintenance window.
Execute the patching operation via Maintenance Windows > Execute, and download the Patch Compliance report with execution timestamps.
Common Audit Findings
- Patches not applied within defined timeframe
- This occurs when patch priorities or maintenance windows are not clearly defined. Prevent this by documenting severity-based timelines and enforcing monthly reviews.
- Lack of evidence for patch testing
- Auditors often see missing proof of pre-production testing. Retain test results or screenshots from staging environments before production deployment.
- Incomplete system inventory
- Systems may be excluded from patching due to outdated inventories. Regularly review and update asset inventories to ensure full coverage.
- Unresolved high-risk vulnerabilities
- High or critical findings may remain open due to unclear ownership. Assign a clear process owner and track remediation to closure.