Does AssetSonar replace Microsoft Intune or Jamf Pro for patch evidence?

No. AssetSonar works alongside them. It integrates with Microsoft Intune, Jamf Pro, Google Endpoint Management, and Microsoft SCCM to import devices into one centralized inventory, and it can detect devices deleted in Intune or Google Workspace so IT can act on stale records. Vulnerability detection and patch deployment in AssetSonar Patch Management run through the AssetSonar ITAM Agent, which scans installed software against the NIST National Vulnerability Database. Many campuses keep their MDM for enrollment and configuration and use AssetSonar to tie each device's patch and vulnerability record to its owner, location, and history. Before buying, confirm which in-scope devices will run the agent, because a device synced only from an MDM may not carry vulnerability data.

How does patch evidence differ between a SOC 2 Type I and a Type II report?

A SOC 2 Type I report evaluates whether controls are suitably designed at a single point in time. Patch evidence for Type I usually covers the policy, the defined device scope, and a demonstration that patching and reporting work. A Type II report also tests operating effectiveness across an examination period that typically runs from three to twelve months. Auditors typically sample specific months, vulnerabilities, or devices and expect a record for each one. A tool that only shows current status cannot answer for a device in the second month of the period, so retained, time-stamped history matters far more for Type II. AssetSonar records each patching event against the specific device in its inventory; confirm its retention covers the full period.

How do auditors check that a system-generated patch report is complete and accurate?

Auditors treat a report produced by the organization's own tools as information produced by the entity (IPE) and usually test it before relying on it. Common checks include the filters and parameters used, the date and time the report ran, whether its device count matches an independent source such as the asset inventory or directory, and whether a sample of devices traces back to the source system. A report with undocumented filters, or one that quietly drops offline devices, can fail this test even when every patch was applied. Saving the report configuration with each export, and reconciling the report's population against the asset inventory, shortens this part of the audit.

Which SOC 2 Trust Services Criteria does patch evidence usually support?

Patch evidence most often supports CC7.1 in the AICPA 2017 Trust Services Criteria (with revised points of focus, 2022). CC7.1 covers detection and monitoring procedures that identify newly discovered vulnerabilities and configuration changes that introduce them. Patch deployments can also support CC8.1, the change-management criterion, when the organization treats patches as changes that require authorization, testing, and approval. The final mapping belongs in the organization's control matrix and is agreed with the auditor, so one device-level patch report may serve as evidence for more than one control. Mapping it early prevents IT from producing slightly different versions of the same report for each control.

How should SOC 2 patch remediation timelines be set if the framework does not define them?

Remediation timelines are set in the organization's own vulnerability-management policy, based on risk. Most policies define windows by severity, often using CVSS scores, and shorten them for vulnerabilities known to be actively exploited, such as those listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The exact number of days is a policy decision. Auditors test whether the organization meets the windows it set, so an aggressive timeline the team routinely misses produces more findings than a realistic one it meets. AssetSonar's Patch Dashboard shows vulnerability aging, which helps IT see which open items are approaching their policy window.

What counts as a compensating control for a device that cannot be patched?

A compensating control reduces the specific risk a missing patch leaves open. On a campus, examples include moving a lab machine to an isolated network segment, blocking its internet access, removing local administrator rights, disabling the vulnerable service or feature, limiting who can sign in, and increasing monitoring on that device. The exception record should state which risk each control addresses, how the control is verified, and who accepted the remaining risk. Auditors generally expect risk acceptance from someone with the authority to accept it, such as the information security lead or system owner, rather than only the technician who deferred the patch.

How should BYOD and unmanaged devices be handled in SOC 2 patch scope?

Central IT usually cannot patch or scan personal devices used by students, faculty, and staff, so most organizations either exclude them from the in-scope system or control how they reach in-scope data. The exclusion should be explicit: state it in the SOC 2 system description and support it with technical controls, such as network access rules or conditional access that admits only managed, compliant devices to in-scope applications. An unexplained gap between the device inventory and the patch report invites auditor questions. AssetSonar's Microsoft Intune integration can sync devices as company-owned or employee-owned, which helps keep the two populations separate in reports.

Who should own patch evidence when university departments manage their own devices?

On many campuses, departments, labs, and research groups buy and manage their own devices, while the SOC 2 control is owned centrally. Evidence holds up best when one central owner defines the in-scope population and the evidence standard, and each department is accountable for remediation and exceptions on its own devices. That split should be written into the control description. Where departments use different management consoles, central IT needs one inventory that records the owner, department, and location of each device, so a failed patch reaches the right team and an auditor can see who was responsible for it.

How does AssetSonar help IT decide which campus vulnerabilities to patch first?

AssetSonar combines three inputs that usually sit in different tools: severity, exposure, and asset context. Each vulnerability carries a CVSS severity from Critical to Low, is mapped to every device running the affected software so IT can see how many endpoints one CVE exposes, and shows each device's owner and related tickets. That lets a team patch, for example, administrative devices that handle sensitive records before an isolated lab machine with the same CVE. AssetSonar lets IT schedule patches for specific device groups and times, so lab and classroom machines can be patched outside teaching hours.

How long should SOC 2 patch evidence be retained?

SOC 2 does not set a universal retention period. At a minimum, evidence must cover the full Type II review period and remain available until the auditor completes fieldwork and issues the report. Many organizations keep it longer, under their own records policy, so they can compare consecutive audit periods, and universities may also have institutional or legal record-keeping requirements. A common gap is that a patch tool's own history retention is shorter than the audit period. Check each tool's retention setting before the period starts, and schedule periodic exports of patch history to a controlled repository if the tool cannot hold the full period.

AssetSonar Blog Soc 2 Patch Compliance Evidence

A Green Patch Dashboard Is Not SOC 2 Evidence

Published on November 13, 2026

Last updated on November 13, 2026

Danish Amir
7 minutes

Table of Contents

The auditor’s request sounds simple: show how you know your endpoints were patched.

The IT team opens its patch compliance dashboard. It reads 97% compliant. That number is useful, but on its own it is not evidence that a patch-management control operated as described.

The follow-up questions arrive quickly. Which devices make up the other 3%? Were they offline, failed, or formally exempted? Which patches were missing, and which vulnerabilities did they leave open? When was each device remediated, and who approved any exception? How does the team know a deployment marked successful actually fixed the issue?

Those answers live in device-level records. SOC 2 evidence begins where the compliance percentage ends.

Key Takeaways:

SOC 2 does not prescribe a patch report or a universal remediation deadline. Auditors test whether an organization’s own patch-management control is well designed and operates consistently.
A compliance percentage is only as accurate as the inventory behind it. In education, proving which devices are in scope comes before proving they are patched.
The Patch Evidence Chain tests audit readiness across eight links per device: scope, identity, state, action, attribution, result, closure, and exception.
Governed exceptions, with an owner, a reason, and a review date, strengthen a control.
A deployment proves remediation only when the installed version or CVE status is verified on the device, after any reboot.
Every patch status needs an “as of” timestamp.
The strongest buying test is tracing one Critical CVE from detection to closure, exported without manual reconciliation.
AssetSonar supports patch-control evidence; it does not make an organization SOC 2 compliant.

Does SOC 2 require a specific patch report?

No. SOC 2 examinations are based on the AICPA Trust Services Criteria, and each organization designs controls that fit its own systems and risks. There is no prescribed patch-report template and no single remediation deadline that applies to every organization.

That changes what IT should prepare. An auditor evaluates whether the vulnerability and patch-management control is designed appropriately and whether it operated consistently across the audit period. Owning a tool with a “SOC 2 report” button settles neither question. Patch timelines, evidence retention, and exception rules come from the organization’s own control design, agreed with its auditor.

The practical question is narrower: can our systems produce records that show the control working, device by device?

Start with the device population

In education, the audit-scope problem usually appears before the patch problem.

A single campus may run administrative Windows laptops, faculty Macs, computer labs, classroom and library machines, shared systems, loaner pools, research endpoints, and devices bought and managed by individual departments. Records for these devices are often split across Intune, Jamf, Google Workspace, and departmental spreadsheets, with no single system holding ownership, location, and history for the whole fleet.

That fragmentation matters because a compliance percentage is calculated against a denominator. If the inventory is incomplete, the percentage is mathematically precise and operationally wrong. A lab of unenrolled machines simply never enters the calculation.

Before IT can prove devices are patched, it has to prove which devices belong in the report.

The Patch Evidence Chain: What a SOC 2 patch compliance report should include

The Patch Evidence Chain is a framework for testing whether patch data can stand up as SOC 2 audit evidence. It treats evidence as eight linked records for every in-scope device. Where a link is missing, the auditor has to take that part on trust.

Scope. Which endpoints should the control cover, and how was that population defined?
Identity. Can each record be tied to one real, uniquely identified device with an owner and location?
State. What was installed or missing, and which CVE or security issue applied to that device?
Action. What remediation did IT attempt, and when?
Attribution. Which administrator, policy, or automated job initiated the change?
Result. Did the action succeed, fail, stay pending, or require a reboot?
Closure. Was the endpoint checked again and verified as remediated?
Exception. If the device remains exposed, why, and who owns that decision?

Most teams already hold data for several of these links. The gap is that the links live in different systems, so proving one device’s history means reconciling exports by hand.

Patch exceptions are part of the evidence

Exceptions are inevitable on a campus. A teaching lab might depend on an application that only supports an older software version, and the team cannot safely patch it during finals week.

The weak response is to leave the device red on the dashboard indefinitely. To an auditor, an unexplained red device looks like a control that stopped operating.

A governed exception records why the patch was deferred, names an owner, describes compensating controls where appropriate, sets a review or remediation date, and logs the eventual closure.

A control does not become credible because exceptions disappear. It becomes credible because exceptions are visible and governed.

Is a successful deployment proof of remediation?

Not automatically. “Deployed” can mean the package was sent, the installer finished, the endpoint checked in, the software version changed, or the vulnerability closed. Only the last two show that the exposure is gone.

Campus labs add a further trap. Many run reboot-to-restore software that returns each machine to a frozen image on restart. A patch installed outside the image maintenance process can report success in the morning and be gone after the next reboot. For these devices, closure evidence must be captured after a restart, or the fix must go into the base image itself.

Stronger evidence confirms the outcome on the endpoint by checking the installed version or the CVE status after the action ran.

Data freshness belongs in the audit conversation

Every patch status is a claim about a moment in time. Useful evidence states that moment: the last endpoint scan, the last check-in, the report generation date, and the vulnerability feed update.

The academic calendar makes this harder. Faculty laptops that leave campus for the summer may not check in for weeks, so their last known status can be months old when audit fieldwork begins in the fall.

Platforms document freshness differently. Microsoft’s Intune update reports note that their data sources arrive on different schedules, and Windows Autopatch reports process device data in batches. Jamf Pro patch reporting shows each computer’s last check-in beside its installed version.

“Compliant” without “as of when?” is incomplete evidence.

Which platforms give Education IT the strongest patch evidence?

Platforms differ in which links of the chain they document well and how much reconciliation they leave to IT. The table below reflects each vendor’s public documentation as of November 2026.

Platform	Best for	Chain links documented	Question to ask in a demo
AssetSonar	Connecting asset inventory with patch evidence	Scope, identity, state, attribution, closure	How are exceptions recorded, and how long is patch history retained?
ManageEngine Endpoint Central	Granular system-level compliance reporting	State, result	How are devices without an installed agent reflected in the report?
NinjaOne	Operational endpoint patch reporting	State, result, attribution	How does each device record tie to CVE context and the campus asset inventory?
Microsoft Intune / Windows Autopatch	Microsoft-centric campuses	State, result, freshness	How are non-Windows and unenrolled devices covered?
Jamf Pro	Apple-heavy campuses	State, freshness	How are Windows devices and CVE context covered?

AssetSonar

AssetSonar is EZO’s IT asset management platform, which also includes IT service management and software asset management. Its Patch Management module detects vulnerabilities on Windows, macOS, and Linux endpoints, maps them to CVEs with CVSS scores from the NIST National Vulnerability Database, and shows each CVE with the affected device, its owner, the installed version, and related tickets. Patching events are recorded against the device with what changed, when, and by whom. A deployment counts as successful only when the agent reports success and AssetSonar verifies the version or CVE closure.

AssetSonar supports evidence for patch-management controls under frameworks such as SOC 2 and ISO 27001. It does not make an organization SOC 2 compliant.

ManageEngine Endpoint Central

Endpoint Central’s predefined patch reports include a System Compliance report, a System Health report with missing patches per system, and a list of systems requiring a reboot.

NinjaOne

NinjaOne’s patch reports show installed, approved, pending, and failed patches by device, with last scan date, scan result, and pending reboots.

Microsoft Intune and Windows Autopatch

Intune and Windows Autopatch provide per-device update status and failure reporting, with exportable quality update data and documented reporting latency.

Jamf Pro

Jamf Pro reports on configured third-party macOS software titles, identifies computers that need updates, and shows each computer’s installed version and last check-in.

Run the Critical-CVE audit test

Stop asking vendors whether they can generate a SOC 2 patch report. Give every vendor the same scenario instead:

A critical vulnerability affected 120 endpoints across administrative offices, two teaching labs, and the library during the audit period. Show the evidence from detection through closure.

Ask each platform to produce, from its own data:

Every affected device, with owner and location
Last check-in and the CVE detected
Deployment date and the administrator or system that initiated it
Success or failure for each device
Exceptions, with owners and review dates
Verification of remediation
An export an auditor can review

Then ask: could we hand this output to an auditor without rebuilding it in Excel?

Don’t buy “SOC 2 software.” Buy evidence your control can use.

Vendor evaluations go faster when four things stay separate:

Tool capability: the evidence the software can produce.
Control design: how the organization defines patch timelines, exceptions, and responsibilities.
Operating effectiveness: whether the process ran consistently across the audit period.
Audit evidence: the records that prove it.

No platform supplies control design or operating effectiveness. A good platform makes both easier to run and easier to demonstrate.

The software does not pass the audit. Your control does. The software’s job is to make that control easier to operate and easier to prove.

Before the next audit cycle, pick one patch exception on your campus today. Can you show who owns it, why it exists, and when it will close?

Test AssetSonar against your campus patch-control evidence

Bring a real campus device group or patch exception to an AssetSonar demo and see what you can document at the device, user, vulnerability, and remediation level.

Was this helpful?

Thanks for your feedback!

Danish Amir

Product Management Lead

EZO

Danish Aamir is a product management leader at EZO who writes about AI in IT service management, enterprise asset intelligence, and the convergence of ITAM and ITSM. His work explores how connected asset, user, and software context can help organizations move beyond basic ticket automation toward governed, context-aware service delivery.

Frequently Asked Questions

Does AssetSonar replace Microsoft Intune or Jamf Pro for patch evidence?
No. AssetSonar works alongside them. It integrates with Microsoft Intune, Jamf Pro, Google Endpoint Management, and Microsoft SCCM to import devices into one centralized inventory, and it can detect devices deleted in Intune or Google Workspace so IT can act on stale records. Vulnerability detection and patch deployment in AssetSonar Patch Management run through the AssetSonar ITAM Agent, which scans installed software against the NIST National Vulnerability Database. Many campuses keep their MDM for enrollment and configuration and use AssetSonar to tie each device's patch and vulnerability record to its owner, location, and history. Before buying, confirm which in-scope devices will run the agent, because a device synced only from an MDM may not carry vulnerability data.
How does patch evidence differ between a SOC 2 Type I and a Type II report?
A SOC 2 Type I report evaluates whether controls are suitably designed at a single point in time. Patch evidence for Type I usually covers the policy, the defined device scope, and a demonstration that patching and reporting work. A Type II report also tests operating effectiveness across an examination period that typically runs from three to twelve months. Auditors typically sample specific months, vulnerabilities, or devices and expect a record for each one. A tool that only shows current status cannot answer for a device in the second month of the period, so retained, time-stamped history matters far more for Type II. AssetSonar records each patching event against the specific device in its inventory; confirm its retention covers the full period.
How do auditors check that a system-generated patch report is complete and accurate?
Auditors treat a report produced by the organization's own tools as information produced by the entity (IPE) and usually test it before relying on it. Common checks include the filters and parameters used, the date and time the report ran, whether its device count matches an independent source such as the asset inventory or directory, and whether a sample of devices traces back to the source system. A report with undocumented filters, or one that quietly drops offline devices, can fail this test even when every patch was applied. Saving the report configuration with each export, and reconciling the report's population against the asset inventory, shortens this part of the audit.
Which SOC 2 Trust Services Criteria does patch evidence usually support?
Patch evidence most often supports CC7.1 in the AICPA 2017 Trust Services Criteria (with revised points of focus, 2022). CC7.1 covers detection and monitoring procedures that identify newly discovered vulnerabilities and configuration changes that introduce them. Patch deployments can also support CC8.1, the change-management criterion, when the organization treats patches as changes that require authorization, testing, and approval. The final mapping belongs in the organization's control matrix and is agreed with the auditor, so one device-level patch report may serve as evidence for more than one control. Mapping it early prevents IT from producing slightly different versions of the same report for each control.
How should SOC 2 patch remediation timelines be set if the framework does not define them?
Remediation timelines are set in the organization's own vulnerability-management policy, based on risk. Most policies define windows by severity, often using CVSS scores, and shorten them for vulnerabilities known to be actively exploited, such as those listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The exact number of days is a policy decision. Auditors test whether the organization meets the windows it set, so an aggressive timeline the team routinely misses produces more findings than a realistic one it meets. AssetSonar's Patch Dashboard shows vulnerability aging, which helps IT see which open items are approaching their policy window.
What counts as a compensating control for a device that cannot be patched?
A compensating control reduces the specific risk a missing patch leaves open. On a campus, examples include moving a lab machine to an isolated network segment, blocking its internet access, removing local administrator rights, disabling the vulnerable service or feature, limiting who can sign in, and increasing monitoring on that device. The exception record should state which risk each control addresses, how the control is verified, and who accepted the remaining risk. Auditors generally expect risk acceptance from someone with the authority to accept it, such as the information security lead or system owner, rather than only the technician who deferred the patch.
How should BYOD and unmanaged devices be handled in SOC 2 patch scope?
Central IT usually cannot patch or scan personal devices used by students, faculty, and staff, so most organizations either exclude them from the in-scope system or control how they reach in-scope data. The exclusion should be explicit: state it in the SOC 2 system description and support it with technical controls, such as network access rules or conditional access that admits only managed, compliant devices to in-scope applications. An unexplained gap between the device inventory and the patch report invites auditor questions. AssetSonar's Microsoft Intune integration can sync devices as company-owned or employee-owned, which helps keep the two populations separate in reports.
Who should own patch evidence when university departments manage their own devices?
On many campuses, departments, labs, and research groups buy and manage their own devices, while the SOC 2 control is owned centrally. Evidence holds up best when one central owner defines the in-scope population and the evidence standard, and each department is accountable for remediation and exceptions on its own devices. That split should be written into the control description. Where departments use different management consoles, central IT needs one inventory that records the owner, department, and location of each device, so a failed patch reaches the right team and an auditor can see who was responsible for it.
How does AssetSonar help IT decide which campus vulnerabilities to patch first?
AssetSonar combines three inputs that usually sit in different tools: severity, exposure, and asset context. Each vulnerability carries a CVSS severity from Critical to Low, is mapped to every device running the affected software so IT can see how many endpoints one CVE exposes, and shows each device's owner and related tickets. That lets a team patch, for example, administrative devices that handle sensitive records before an isolated lab machine with the same CVE. AssetSonar lets IT schedule patches for specific device groups and times, so lab and classroom machines can be patched outside teaching hours.
How long should SOC 2 patch evidence be retained?
SOC 2 does not set a universal retention period. At a minimum, evidence must cover the full Type II review period and remain available until the auditor completes fieldwork and issues the report. Many organizations keep it longer, under their own records policy, so they can compare consecutive audit periods, and universities may also have institutional or legal record-keeping requirements. A common gap is that a patch tool's own history retention is shorter than the audit period. Check each tool's retention setting before the period starts, and schedule periodic exports of patch history to a controlled repository if the tool cannot hold the full period.