Malware and Unauthorized Software Control for SOC 2

What this control should accomplish

Malicious and unapproved software is prevented or detected across covered endpoints and production workloads, and actionable detections reach an owner who investigates and records the result.

How to implement Malware and Unauthorized Software Control

1. 1

   Define the protected population

   Identify company endpoints and supported production workloads that need malware protection, including operating-system limitations and an explicit handling approach for uncovered systems.

   You should end up with: A coverage inventory that reconciles assets with enrolled and healthy protection agents.

2. 2

   Configure prevention and tamper controls

   Enable real-time scanning, behavioral detection, signature and engine updates, tamper protection, quarantine, and appropriate exclusions; restrict who can disable or modify these settings.

   You should end up with: Policy configuration and administrator-role evidence for malware prevention.

3. 3

   Monitor agent health and detections

   Alert on malware events, disabled or stale agents, failed updates, repeated exclusions, and unprotected assets, and route each actionable event to an accountable responder.

   You should end up with: Health and detection dashboards plus alert-routing configuration.

4. 4

   Investigate and close alerts

   Record triage, affected host and user, containment, removed artifacts, cause, and final disposition, including a reason when a detection is considered benign.

   You should end up with: Completed investigation records linked to original detections and remediation actions.

5. 5

   Control unauthorized software

   Maintain visibility into installed software, restrict installation for higher-risk devices and workloads, and investigate tools that are prohibited, unlicensed, unsupported, or inconsistent with job need.

   You should end up with: Software inventory findings, restriction settings, and removal or exception records.

Evidence to keep, and what it should prove

Build the evidence set in three layers: what defines the control, who approved or reviewed it, and what proves it operated. Collect operating records when the work happens so they remain dated, attributable, correctly scoped, and traceable to the underlying activity.

Before sharing, remove unrelated personal or customer data, never expose passwords, tokens, or secret values, preserve enough source context to authenticate the record, and use the secure exchange approved for the engagement.

Which records should you prepare for the audit?

How an auditor may test this control

Use this checklist to prepare for procedures an auditor may perform. The exact steps and sample selection depend on your engagement scope and the service auditor's professional judgment.

• Confirm the intended control outcome

  Determine whether the control is designed to achieve this result: Malicious and unapproved software is prevented or detected across covered endpoints and production workloads, and actionable detections reach an owner who investigates and records the result.

• Confirm ownership and operating cadence

  Compare the documented owner with the intended role (Infrastructure / Security Operations / IT), then compare dated records with the stated cadence: Continuous/ongoing; periodic review by risk.

• Establish the complete audit record set

  Reconcile the complete endpoint and supported-workload inventory to healthy protection agents, then reconcile native alert and software-detection exports, including suppressed and benign records, to response tickets and verified final state.

• Prepare the as-of-date evidence for a Type 1 engagement

  As of the selected date, retain the complete current protection-agent and software coverage export, effective prevention policies, and the latest malware or unauthorized-software investigation with validated closure.

• Prepare period evidence for a Type 2 engagement

  Include every covered endpoint and supported workload at each required health review, every agent disablement, stale check-in, failed update, malware alert, unauthorized-software detection, suppression, benign disposition, quarantine, containment, remediation, and approved exception during the review period.

• Inspect the operating / technical evidence

  Dated proof that the control actually ran, such as tickets, logs, settings, exports, reports, and test results.

  • Inspect EDR/anti-malware dashboard

    For each selected record, confirm it demonstrates The current covered endpoint and workload population reports to the protection service with active policy, healthy agents, current engines, and visible coverage gaps.

    • Asset and owner
    • Operating system or workload type
    • Policy assignment
    • Agent and engine health
    • Protection status
    • Last check-in timestamp

  • Inspect malware alerts

    For each selected record, confirm it demonstrates Every detected malicious or suspicious event records the affected asset and user, detection detail, severity, protective action, assigned responder, and final disposition.

    • Alert ID and timestamp
    • Asset and user
    • Detection and severity
    • Preventive or containment action
    • Responder
    • Disposition

  • Inspect unauthorized software detections

    For each selected record, confirm it demonstrates Installed or executed software outside approved need is detected on an attributable asset and is investigated, removed, restricted, or formally excepted.

    • Detection ID and date
    • Asset and owner
    • Software and version
    • Detection basis
    • Decision
    • Removal or exception status

  • Inspect remediation tickets

    For each selected record, confirm it demonstrates Malware, unhealthy protection, and unauthorized-software findings were assigned, contained or corrected, validated, and closed with a reasoned outcome.

    • Ticket and alert ID
    • Affected asset
    • Assigned responder
    • Containment or correction
    • Completion timestamp
    • Validation and closure reason

• Trace the control from design to operation

  Use the categories that apply to this control: connect any policy or design artifact to its approval or review record, then trace a selected operating record through execution, result, and any exception or remediation.

Common implementation and evidence gaps

• Agents are installed but unhealthy, outdated, disabled, or missing from newly issued and replacement devices.
• Detections are delivered to an email address or console that no one owns or monitors consistently.
• Production servers, developer workstations, or alternate operating systems are omitted without an explicit risk decision.
• Detections are closed without documenting whether malware was removed, the host was contained, or the alert was benign.
• The company has endpoint protection but no usable inventory of unauthorized or unsupported software.

Before you call this control ready

• Does the protected-asset count reconcile with the endpoint and production-workload inventory?
• Can users or local administrators disable protection without detection?
• Would a stale agent, failed update, or new malware detection reach a named responder?
• Can sampled alerts be traced through triage, containment, remediation, and final disposition?
• How are prohibited, unsupported, or unnecessary applications identified and removed?

Trust Services Criteria references

These identifiers help you navigate related Trust Services Criteria. They do not reproduce the criteria or prove that this control fully addresses them in your environment.

• CC6.8
• CC7.1
• CC7.2

Confirm final scope, mappings, and testing expectations with your service auditor. SOC 2® is an AICPA trademark; GreenHat Security is not affiliated with or endorsed by AICPA.

Related controls to review next