Skip to main content
Comply Defense
Category: Incident Response & Reporting

Malware Submission

Also known as: Malware Sample Submission, File Submission for Malware Analysis
Simply put

Malware submission is the process of sending a suspicious file or piece of code to an analysis service so that experts or automated systems can determine whether it is harmful. Organizations and services then use the results to understand the threat, remove it, and recover affected systems. Submissions may go to government resources such as CISA or to private and vendor-operated analysis platforms.

Formal definition

Malware submission refers to the act of providing a suspected malicious file, sample, or code artifact to a malware analysis capability for examination. Analysis may be dynamic (executing the sample in an instrumented environment such as a sandbox) or otherwise processed by automated security systems and human researchers to classify the sample as malicious, clean, or incorrectly detected. As reflected in the evidence, CISA's Malware Analysis service delivers dynamic analysis of malicious code along with recommendations for malware removal and recovery, while third-party platforms (for example, sandbox and hybrid-analysis services, vendor submission portals) accept samples and may produce reports containing hashes, indicators of compromise (IOCs), and behavioral findings. This entry describes the general concept only; it does not cover data-handling, CUI or classified information restrictions, or the specific submission procedures and authorizations that apply to a given system, and readers should verify handling requirements and service-specific terms against current authoritative sources before submitting samples.

Why it matters

Malware submission is a foundational step in incident response and threat analysis because it converts a suspicious, unexplained file into actionable intelligence. Without submitting a sample to an analysis capability, defenders are often left guessing whether a file is benign, a false positive, or an active threat requiring containment. Submission to a service such as CISA's Malware Analysis capability can produce not only a classification of the code but also recommendations for malware removal and recovery, which directly supports the eradication and recovery phases of incident handling.

The results of submission also feed broader detection and defense. Analysis reports frequently include file hashes, indicators of compromise (IOCs), and behavioral findings that organizations can use to hunt for related activity across their environment, update detection rules, and share information with partners. In this way, a single submission can improve protection well beyond the originally affected system.

Compliance and security officers should note that submission carries handling considerations. A suspected malicious file may itself contain or be embedded in sensitive data, and submitting it to an external platform involves transmitting that artifact to a third party. This entry describes the general concept only and does not address data-handling, CUI, or classified information restrictions; readers must verify the handling requirements and service-specific terms that apply to their systems before submitting any sample.

Who it's relevant to

Information System Security Managers and SOC Analysts
These practitioners rely on malware submission to classify suspicious files, obtain IOCs and behavioral findings, and drive detection updates and threat hunting. They should confirm which analysis service is appropriate and verify data-handling requirements before transmitting any sample externally.
Incident Responders
During an incident, submission to a capability such as CISA's Malware Analysis service can provide a classification of the code as well as recommendations for removal and recovery, directly supporting eradication and recovery activities.
Compliance Officers
Because a submitted file may contain or be embedded in sensitive information and is transmitted to a third party, compliance officers should ensure that submission practices align with applicable data-handling restrictions. This entry does not cover CUI or classified information restrictions, which must be verified against current authoritative sources.
Government Contractors
Contractors handling suspicious artifacts on covered systems need to confirm the specific submission procedures, authorizations, and service terms that apply to their contracts and systems before sending samples to external or vendor-operated analysis platforms.

Inside Malware Submission

Suspected Malicious Artifact
The file, executable, script, document, email attachment, or other object believed to contain or exhibit malicious behavior that is provided for analysis. In most workflows the artifact is packaged and transmitted in a controlled manner to prevent accidental execution.
Submission Metadata
Contextual information accompanying the artifact, which generally includes the source or point of detection, timestamps, observed behavior, and the reporting system or user. This context supports triage and analysis but the specific required fields vary by receiving organization or program.
Receiving Entity or Analysis Capability
The organization, sandbox, incident response team, or government reporting channel to which the artifact is submitted. In the federal and defense space this may involve agency security operations centers or designated reporting mechanisms; readers should confirm the correct destination against current organizational and contractual requirements.
Handling and Sensitivity Markings
Indicators of how the artifact and associated data must be protected, which can differ when the material relates to Controlled Unclassified Information (CUI), defense systems under the RMF, or classified systems under the NISPOM. Handling obligations generally follow the sensitivity of the environment where the artifact was found.
Chain of Custody and Handling Record
Documentation of who handled the artifact, when, and how it was transferred, which is generally important where the submission may support incident reporting, forensic, or contractual obligations. Specific retention and documentation requirements should be verified against applicable policy.

Common questions

Answers to the questions practitioners most commonly ask about Malware Submission.

Does submitting a malware sample to a government or vendor analysis service satisfy an organization's incident reporting obligations?
Not necessarily. Malware submission is a technical analysis activity and is generally distinct from formal incident reporting requirements. For example, defense contractors handling Controlled Unclassified Information (CUI) may have separate cyber incident reporting obligations, and civilian agencies operate under their own FISMA-related reporting and CISA coordination expectations. Submitting a sample for analysis does not automatically fulfill those reporting duties, which typically have their own timelines, recipients, and content requirements. Verify your specific reporting obligations against the applicable contract clauses, agency policy, and current authoritative guidance.
Is malware submission a harmless step that carries no data-handling risk?
No. Malware samples and their associated artifacts can contain sensitive, proprietary, or even controlled information embedded in the file or its context, so submission is not automatically risk-free. Depending on the system involved, a sample could implicate CUI, classified data under the NISPOM, or other protected information, and different public, government, and vendor submission channels apply different handling and sharing rules. Treat the classification and sensitivity of the sample and its metadata as a distinct concern from the malware analysis itself, and confirm handling requirements before submitting.
How should an organization decide which submission channel to use for a given sample?
The appropriate channel generally depends on the sensitivity of the sample, the type of system it came from, and any applicable reporting or sharing rules. Public multi-vendor analysis services may allow broad sharing that is inappropriate for sensitive material, while government or vendor channels may offer more controlled handling. Organizations should weigh the information sensitivity, whether the sample may contain CUI or other protected data, and their contractual or agency obligations before selecting a channel, and should confirm the specific handling terms of any service used.
What should be documented when a malware sample is submitted?
In most implementations, organizations benefit from recording details such as the date and time of submission, the channel used, who authorized and performed the submission, a description of the sample and its source system, and any handling or sensitivity determinations made beforehand. Such documentation supports continuous monitoring, incident records, and later audit or assessment activities. The precise records required will vary by agency policy, contract terms, and internal procedures, so confirm expectations against your applicable requirements.
How does malware submission fit into an organization's incident response process?
Malware submission is typically one supporting step within a broader incident response and analysis workflow, rather than a standalone control. Analysis results can inform containment, eradication, and recovery decisions and may feed into required reporting. However, submitting a sample does not replace the coordinated response steps, and it should be integrated with, not substituted for, an organization's documented incident response procedures and any separate reporting obligations.
Who should be authorized to submit malware samples on behalf of an organization?
Because submission can involve sensitive data-handling and external sharing decisions, organizations generally restrict this activity to designated roles operating under defined procedures, rather than allowing ad hoc submission by any user. Coordination with the information system security manager, incident response personnel, and, where relevant, authorizing officials helps ensure that sensitivity determinations and channel choices are made appropriately. Specific authorization requirements should be defined in internal policy and confirmed against applicable agency or contractual guidance.

Common misconceptions

Submitting malware to an analysis service or reporting channel satisfies an organization's incident reporting obligations.
Malware submission is an analysis or triage activity and is generally distinct from formal incident reporting. Defense contractors handling CUI, for example, may have separate reporting obligations under contractual clauses such as DFARS 252.204-7012, and civilian agency systems have their own FISMA-based reporting expectations. Readers should confirm the applicable reporting requirements and timelines against current official sources.
Any suspected malware can be uploaded to a public or third-party analysis service without restriction.
Uploading an artifact may expose sensitive, proprietary, or controlled data, and public services often share submitted samples broadly. When the artifact contains or relates to CUI, classified information, or otherwise protected data, submission to external services may be prohibited or restricted; handling generally must follow the sensitivity of the source environment and applicable policy.
A clean result from an analysis tool means the artifact is definitively safe.
Analysis outputs indicate what a given capability observed and are not an absolute determination of safety. Evasive or targeted malware may not exhibit malicious behavior in a given environment, so results should be treated as one input to a broader assessment rather than a final verdict.

Best practices

Confirm the correct submission destination and any contractual or agency-specific reporting channels before transmitting an artifact, and distinguish analysis submission from formal incident reporting obligations.
Assess the sensitivity of the artifact and its source environment first, and avoid uploading material to external or public services when it may contain CUI, classified, or otherwise protected data.
Package and transmit suspected malware in a controlled, contained manner that prevents accidental execution during handling and transfer.
Capture relevant submission metadata, such as source, timestamps, and observed behavior, to support accurate triage and downstream analysis.
Maintain handling and chain-of-custody records where the artifact may support incident, forensic, or contractual processes, and retain them per applicable policy.
Treat analysis results as one input rather than a definitive safety verdict, and verify current handling, reporting, and destination requirements against authoritative organizational and regulatory sources.