A computer virus is malicious code that copies itself into other files or programs and spreads when those files run. In cybersecurity, it is a self-replicating threat that usually needs a user action or host process to activate, then may corrupt data, disrupt systems, or enable further compromise.
What a computer virus is in practice
A computer virus is a form of malware that embeds itself into other files or programs so it can spread when the host is opened or executed. Unlike some other malware families, its spread is usually tied to infected content being used again by a person or process.
That dependency on execution makes the virus especially important in environments where shared files, removable media, legacy software, or untrusted attachments are still part of daily operations. The defining security issue is not only the payload, but also the way the malicious code reuses legitimate software as a delivery vehicle.
How a virus spreads and survives
A virus typically attaches itself to a host file, inserts code that runs when that file is launched, and then looks for new files or programs to infect. Some variants target executables, while others use document macros, scripts, or other file formats that can be triggered by user action.
Persistence depends on repeated execution opportunities. If the infected host keeps circulating inside email, file shares, backups, or software packages, the virus can continue to propagate even after the initial infection is discovered. The propagation model is what separates a virus from malware that only lives in memory or only runs once.
For a broader taxonomy of malicious code, the Malware Guide is the most direct reference point because it places viruses alongside worms, trojans, loaders, and other families that security teams often need to distinguish quickly.
Why computer viruses are dangerous
Viruses are dangerous because they combine infection with replication. A single compromised file can spread across endpoints, shared folders, and collaboration channels, turning ordinary user activity into a propagation path. That makes containment harder than with malware that stays isolated on one system.
The impact can range from data corruption and application failure to broader compromise if the virus drops additional payloads or creates conditions for follow-on malware. In real environments, the operational damage often comes from the secondary effects: broken applications, quarantined files, interrupted workflows, and trust loss in common file types.
Detection and containment of infected files
Detection usually starts with antivirus and endpoint telemetry, but file lineage, sandbox analysis, and suspicious execution events matter just as much. Security teams look for unusual file modification patterns, unexpected child processes, macro execution, and repeated alerts tied to the same source file or share.
Containment often means isolating hosts, blocking known malicious hashes or filenames, and removing the infected files from circulation. Where the virus has touched shared repositories or packaged software, teams should assume the contamination may extend beyond the first alerted endpoint and review the full distribution path before restoring trust in the content.
Recovery and prevention measures
Recovery is not just cleanup. Teams should restore from known-good backups, reimage heavily affected systems when necessary, and confirm that any secondary malware is absent before returning devices to production. If the virus modified application files, installers, or shared documents, those assets need integrity verification as part of recovery.
Prevention is strongest when user execution opportunities are reduced. Application allowlisting, macro controls, email filtering, restricted script execution, patched software, and least-privilege workstation use all reduce the chance that a viral payload can start and spread. The goal is to make it hard for malicious code to find both a host and a way to run.
For teams building a larger malware defense programme, the NIST control catalog provides useful anchors for system integrity, configuration discipline, auditability, and access controls through NIST SP 800-53 Rev 5 Security and Privacy Controls.
Risk and Threat Considerations
Computer viruses remain risky because they exploit trusted execution paths, especially shared files, removable media, and routine user actions. Their spread can be quiet at first, then become disruptive once infected content is reused across multiple systems or business processes.
Failure mechanism: The malware gains a foothold inside a legitimate file or program, then activates when that host is opened or run, allowing repeated reinfection and wider propagation through normal workflows.
Impact: Organisations can face data loss, corrupted software, interrupted operations, and secondary compromise if the virus carries or enables additional malicious payloads.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8, NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-10 — Malware Defenses | Viruses are a core malware problem requiring preventive and detective controls. |
| Recommendation — Deploy malware defenses to block, detect, and contain infected files and execution paths. | ||
| NIST SP 800-53 Rev 5 | SI-3 — Malicious Code Protection | This control directly addresses detection and blocking of malicious code such as viruses. |
| SI-7 — Software, Firmware, and Information Integrity | Viruses threaten file and program integrity by modifying trusted content. | |
| Recommendation — Implement malicious code protection to scan, block, and quarantine infected content. Verify integrity of software and files before allowing them to run or circulate. | ||
| NIST CSF 2.0 | PR.DS-06 — Integrity is protected | Viruses undermine integrity of files, software, and operational data. |
| Recommendation — Protect integrity checks so modified or infected files are detected before execution. | ||
| MITRE ATT&CK | T1059 — Command and Scripting Interpreter | Many viruses rely on script or interpreter execution to activate payloads and spread. |
| Recommendation — Map suspicious script execution to T1059 and investigate the initial activation chain. | ||
Practitioner Guidance
Why practitioners should care: The practical problem with a virus is not just removing one infected endpoint, it is proving that the infected file no longer exists in circulation. Treat distribution paths, shared storage, and backup sets as part of the incident scope, not just the first machine that triggered an alert.
What to watch for: Repeated detections of the same file, unusual macro or script execution, and infections that reappear after cleanup usually indicate the contaminated object is still being exchanged somewhere in the environment.
Practitioner takeaway: Virus response is only complete when the infected artifact, the host it ran on, and every place it was copied or reused have all been addressed.
Related resources from NHI Mgmt Group
- How do you know if computer-use governance is actually working?
- How should security teams govern computer-use models that change access inside enterprise systems?
- How can organisations decide whether a computer-use model belongs in production IAM?
- Who should approve computer-use automation for privileged identity tasks?