A reliable antivirus deployment should be tested, not simply assumed. This checklist shows how to verify that endpoint protection is installed, active, updated, able to quarantine a harmless test file, and reporting alerts to the people responsible for responding—without introducing real malware.
Overview
Antivirus validation is a controlled operational check. It is different from trying to infect a business PC, downloading suspicious samples, or opening a malicious link. The goal is to confirm that the protection you purchased and configured works as intended across the full path: endpoint, security service, management console, and human notification workflow.
The EICAR test file is the usual starting point. EICAR is a standardized, harmless test string designed so security products can recognize it as a test detection. It is not malware, but antivirus software may block, quarantine, or report it in much the same way as a detected file. Obtain the test material only from the official EICAR website or your security vendor's documented test process. Do not copy test strings from untrusted pages, alter them, or use real malware for validation.
Before testing, define the scope. Select a disposable test workstation or an approved business device, record its operating system and protection policy, and tell the relevant IT or security contact when the test will occur. Avoid testing during an incident, a critical business process, or a period when an automated quarantine could disrupt an important application.
If your organization uses Microsoft Defender for Business or another managed platform, the endpoint check should be paired with a console check. A local pop-up proves only that the device displayed an event. A management-console alert, event record, or email notification provides stronger evidence that the organization can see and act on the detection. For broader planning, compare this workflow with the antivirus versus EDR guide for small business.
Checklist by scenario
1. Verify installation and baseline health
- Confirm the approved antivirus or endpoint protection product is installed on the test device.
- Check that the expected license, subscription, or business policy is applied.
- Confirm real-time protection is enabled and not paused by the user, another product, or a troubleshooting setting.
- Review the last update time for malware definitions, engines, or protection intelligence.
- Check that the device has recently communicated with the vendor cloud or management service.
- Record the device name, user or test account, operating system, agent version, policy name, and test time.
On Windows, review the installed security product and Windows Security status, then confirm the device appears healthy in the relevant business console. On macOS, check the vendor's status window or menu-bar agent and confirm that required permissions and system extensions are approved. The exact labels vary by product, so use the vendor's current documentation rather than assuming that one platform's settings apply to another.
2. Run a safe EICAR detection test
- Use an approved test device and notify anyone who may receive the alert.
- Temporarily save no real business data in the test location.
- Follow the official EICAR instructions for creating or downloading the test file. Do not use a real malware sample.
- Observe whether real-time protection blocks the file, prevents access, or moves it to quarantine.
- Record the detection name, action taken, timestamp, device, user, and policy involved.
- Do not restore, execute, email, or upload the test file after detection.
A security product may detect the test immediately, block its creation, or treat it differently depending on policy and operating system. Any of these outcomes can be valid if they are documented and visible to the responsible team. If the file is not detected, stop rather than escalating to real samples. First check that the file was created according to the official instructions, that real-time protection was active, and that the selected policy permits the expected test behavior.
3. Test the management console and notifications
- Confirm the detection appears in the endpoint protection console.
- Check that the event is associated with the correct device and user.
- Verify that the console shows a clear action, such as blocked or quarantined.
- Confirm the configured email, mobile, ticketing, or workflow notification reaches its intended destination.
- Measure the time between endpoint detection, console visibility, and human receipt of the alert.
- Confirm the event can be exported or retained as evidence for an audit or control review.
Do not treat a notification as successful merely because an email arrived. Check whether it contains enough context to support a decision: device, account, detection, time, severity or status, and recommended next step. If your team uses EDR, managed antivirus, or a security information and event management platform, verify the handoff between those systems as well.
4. Test policy enforcement on a second device
Repeat a smaller version of the check on a device in another relevant group, such as a remote worker laptop, a newly onboarded PC, or a standard user account. The purpose is to identify policy differences. A test device can appear healthy while other machines have delayed updates, different exclusions, disabled notifications, or incomplete enrollment.
For server-specific requirements, use a separate approved procedure. Do not apply a workstation test casually to production servers. Review the Windows Server antivirus compatibility guide before planning that work.
What to double-check
When a test produces an unexpected result, work through the control chain instead of immediately changing settings.
- Protection status: Is real-time scanning enabled, or is the interface showing only that the product is installed?
- Update status: Is the engine or protection intelligence current enough for the organization's policy, and did the device obtain it from the expected service?
- Exclusions: Does a file, folder, process, or extension exclusion prevent the test from being inspected?
- Policy scope: Is the test device assigned to the intended group, or has a local setting overridden the central policy?
- Connectivity: Can the endpoint reach the vendor's cloud and can the console receive events?
- Permissions: On macOS and other tightly controlled platforms, are the vendor's required permissions and extensions approved?
- Alert routing: Is the notification address active, monitored, and included in the correct severity threshold?
- Response ownership: Does someone know who reviews the alert, isolates a device, and documents the outcome?
Keep evidence concise. A useful record includes the test plan, device details, policy version or name, screenshots or event identifiers, notification recipient, timestamps, result, and corrective action. Store the record according to your organization's retention rules, and remove the test file after the procedure is complete.
This exercise should also expose gaps in the wider endpoint standard. Use the small business antivirus policy template to define who owns updates, exclusions, alert triage, and exceptions.
Common mistakes
- Using real malware: A real sample can cause data loss, spread to shared systems, or trigger an incident. The safe test file is sufficient for the basic control check.
- Testing only the local interface: A green status screen does not prove that central reporting or notifications work.
- Testing only one device: Remote workers, new enrollments, and devices in different policy groups may behave differently.
- Disabling protection without a rollback plan: If troubleshooting requires a temporary change, record who approved it, limit its duration, and restore the setting immediately.
- Ignoring exclusions: Broad exclusions can undermine malware protection and make a test misleading. Review and justify every exception.
- Restoring the test file: Quarantine is the expected safe destination. Do not restore or execute it simply to see what happens.
- Failing to define a response: An alert that nobody owns is not a dependable control. Assign a person or queue before testing.
If a real infection is suspected, stop validation work and follow the incident process. Isolate the affected device when appropriate, preserve relevant evidence, and use a documented recovery runbook such as the Windows malware removal checklist or the ransomware recovery plan for small business.
When to revisit
Run this checklist before a new endpoint protection rollout, after onboarding a device group, and after changing policies, exclusions, alert thresholds, email routing, or identity permissions. It is also useful after replacing a security product, moving to a new management console, or discovering that an expected alert was delayed or missing.
Many small teams schedule a lightweight review during quarterly or seasonal planning. Repeat the full test when workflows or tools change, and include at least one representative remote device if remote work is part of the environment. Revisit the procedure whenever the vendor changes its console, operating-system permissions, test-file instructions, or supported integration methods.
Finish each review with one of three outcomes: pass, pass with documented limitation, or fail requiring remediation. Assign an owner and due date for every limitation or failure, then retest the affected control. A short, repeatable record is more useful than an occasional unstructured experiment because it shows whether endpoint protection remains active, visible, and actionable over time.
