How to prepare endpoints for SOC 2 and FedRAMP audits

An endpoint security audit isn't just about showing which patches and configurations are in place. Assessors also need evidence of which devices were checked, when the data was collected, and whether vulnerability remediation actually worked. That gets tricky when devices are offline, inventory records are outdated, and successful deployments don't always mean the intended security outcome was achieved. A solid security audit checklist helps you connect the dots and build an evidence trail that holds up to scrutiny.

What should an endpoint security audit checklist include?

An endpoint security audit checklist should link each in-scope device to its required security state, the check performed, the evidence collected, and any unresolved findings. Think of it as the paper trail for what you did.

The following table shows examples of how endpoint checks relate to SOC 2 control themes and NIST security controls, not an official compliance crosswalk or complete assessment checklist. SOC 2 requirements depend on the scope of your engagement. The NIST references illustrate potential relevance to FedRAMP Rev5, while FedRAMP 20x follows a different certification approach. Confirm the applicable requirements before collecting evidence.

One clarification that trips people up: Installed software may be present while protection is not verified, and a completed deployment may not have produced the intended security outcome. Your assessor will notice the difference.

How do SOC 2 and FedRAMP change endpoint audit preparation?

SOC 2 and FedRAMP can involve similar endpoint evidence, but they assess different scopes and use different requirements. Establish the applicable engagement or program requirements before deciding which devices, checks, and records belong in the evidence package.

SOC 2 evaluates the controls a service organization has in place for the system being assessed rather than certifying individual devices. The scope of the assessment determines which of the five Trust Services categories are covered. A Type 1 report evaluates whether those controls are suitably designed as of a specific date. A Type 2 report also evaluates whether the controls operated effectively over a defined period, so auditors need evidence from across that period rather than just a current snapshot.

FedRAMP applies to cloud service offerings, not individual laptops. When preparing for an assessment, review administrative endpoints, management systems, information flows, and third-party dependencies to determine which resources handle federal customer data or could affect its security. That means some corporate endpoints may be relevant even if they're outside the production environment, while others may fall outside the assessment scope.

FedRAMP also has two certification approaches, Rev5 and 20x, with different requirements and adoption deadlines under the Consolidated Rules for 2026. Confirm which requirements apply to your cloud service offering, and use "FedRAMP Certified" only when referring to a service that has earned that designation.

How do you prepare endpoints and collect audit evidence with PDQ?

Prepare endpoints through a repeatable process: establish scope, verify device coverage, assess required settings, remediate findings, confirm results, and preserve evidence. Each step produces artifacts the assessor will want to see.

1. Confirm scope, requirements, and permitted tooling

Start by identifying the in-scope system, endpoint population, assessment date or period, control owners, required security states, and evidence expectations. This step happens before you touch any devices.

Before deploying a management agent in a FedRAMP-related environment, review the service's role, privileges, data flows, and dependencies under the applicable scoping rules. PDQ's cloud service handles device scan data and deployment-related information, making those flows relevant to the review. The PDQ product security guide supports vendor due diligence.

Output: An agreed scope and evidence plan, including approved tooling and responsible owners.

2. Reconcile the endpoint population

Use PDQ's inventory to identify managed devices, then compare that population with your organization's authoritative asset records. An agent-based inventory only shows enrolled devices, not necessarily every in-scope endpoint.

Account for missing agents, stale records, offline devices, duplicates, remote devices, and retired assets. Preserve the assessed population so later changes to group membership do not obscure which devices were reviewed.

For a more detailed look at inventorying devices and installed software, check out our guide to auditing software and hardware.

Output: A reconciled endpoint population and a documented list of coverage gaps.

3. Assess devices against documented requirements

Define the expected security settings before determining whether a device meets your requirements. Use built-in inventory for supported data and custom PowerShell scanners for organization-specific Windows checks.

PowerShell scanner scripts must return structured PowerShell objects and should collect data without modifying devices. Test your scripts on representative devices, including what happens when a check fails or a setting isn't supported. PDQ limits scanner output to 100 rows and 36 columns per device, so verify that your results are complete before relying on them as audit evidence.

Record failed checks and stale or unavailable data as unknown or not assessed rather than treating missing evidence as a pass. Otherwise, you could end up explaining to an assessor why 47 devices have no encryption status but were marked compliant.

Output: Findings tied to a requirement, device, collection time, and evidence source.

4. Remediate findings through approved changes

Once you've identified security gaps, prioritize the findings and plan how to address them. Test each change, get the necessary approvals, and identify affected devices before deploying fixes. This is where building a patch management plan pays off.

With PDQ, you can use the Windows updates tab to review and install applicable Windows updates or deploy application packages to fix outdated software. If your PDQ plan includes vulnerability management, you can also identify affected devices and use those findings to guide remediation.

Account for maintenance windows, required reboots, staged deployments, and recovery options in case something goes wrong. Review deployment results to identify failures and devices that need follow-up. Keep in mind that SOC 2 doesn't specify a universal patching deadline, while FedRAMP remediation timelines depend on the severity of the vulnerability and applicable requirements.

For example, say an audit reveals an outdated PDF reader on 200 devices. You document the finding, reference the approved change ticket, and use PDQ to deploy the updated software. Preserve the approval record, targeted device list, and deployment results to show what action was taken and which devices need further attention.

Output: A documented change with an owner, approval reference, affected devices, deployment results, and verification evidence.

5. Verify the required security outcome

After remediation, refresh the relevant inventory or finding and confirm the expected version, setting, or protection state.

Distinguish failed, offline, pending-reboot, and verified-remediated devices. PDQ's Windows update workflow distinguishes update states, so do not treat pending reboot and installed as the same outcome; assessors will notice.

Record unresolved findings with an owner, reason, required approval, compensating measures where applicable, and a review date. An ignored vulnerability is not a remediated vulnerability.

Output: Verified closure or a documented unresolved finding.

6. Preserve evidence and repeat the process

Move required records into an approved evidence repository before relevant product history becomes unavailable. Link each artifact to its control or requirement and related ticket.

Assign owners and a recurring schedule for checking devices, reviewing exceptions, and collecting evidence. Type 2 assessments do not care what you did once; they care what you did consistently.

Output: A traceable record of what was assessed, what changed, and whether the required outcome was achieved.

What should an endpoint audit evidence package contain?

An endpoint evidence package should connect the assessed population, the requirement tested, the observed result, and any remediation or exception. If an assessor cannot trace from requirement to evidence to outcome, the evidence does not count.

Organize the package into three groups:

• Scope and control context: Requirements, population definition, date or period covered, owner, baseline, and approved procedure.

• Observed evidence: Inventory snapshots, configuration results, vulnerability findings, deployment records, and post-change verification.

• Review and exceptions: Approvals, unresolved issues, risk decisions, review dates, and follow-up records.

A few evidence-management practices to keep in mind:

Store evidence in an access-controlled repository and follow your organization's retention requirements. Keep credentials, recovery keys, and unnecessary sensitive information out of routine exports.

Which endpoint tools work best for security audits?

Endpoint audit tools should help you identify in-scope devices, assess their security state, track remediation, and preserve supporting evidence. Look for device coverage, data freshness, configuration visibility, remediation verification, traceability, and reporting and retention options that fit your assessment requirements.

That evidence collection adds up. According to PDQ's State of Sysadmin research, 49% of sysadmins say keeping up with compliance and audits takes too much time. Choosing tools that make it easier to collect, organize, and retrieve evidence can help reduce the manual work involved.

PDQ supports endpoint audit preparation with device and software inventory, patching, deployment, and reporting. Depending on your plan, vulnerability management can also help identify affected devices and guide remediation. Pair PDQ's endpoint data with access records from identity systems, protection status from security platforms, centralized logs, and change approvals from your ticketing system to build a more complete evidence trail.

Ultimately, the goal isn't finding one tool that does everything. It's building a workflow that lets your team demonstrate which devices were assessed, what was found, who approved the response, what changed, and how the results were verified.