Skip to main content
Policy Authority
Category: Controls Management

Application Control

Also known as: Application Whitelisting, Application Allowlisting
Simply put

Application control is a security practice that restricts which software, scripts, and code are permitted to run on an organization's systems, endpoints, or network. Rather than trying to detect and block known malicious programs, it commonly works by allowing only approved applications to execute and preventing everything else. This entry covers application control in the cybersecurity sense and does not address the separate, distinct concept of 'application controls' used in financial-reporting and audit contexts (input, processing, output, and authorization controls embedded within business applications).

Formal definition

In the information security context, application control is a set of security tools and policies that regulate which applications, executables, scripts, and code are allowed to run on endpoints, servers, or across a network, typically enforcing a deny-by-default or allowlisting posture in which only explicitly permitted software may execute. It may also restrict the code that runs in the system core and can be delivered as an endpoint capability or a network-based monitoring and control service. Implementations vary by vendor and platform, and this definition does not cover specific product configuration, tooling selection, or the audit-domain meaning of 'application controls' (data completeness, accuracy, validity, and authorization controls internal to business applications), which is a separate control family that shares a similar name.

Why it matters

Application control addresses a persistent limitation of detection-based defenses: signature and behavior-based tools can only block threats they recognize, leaving a window for novel or previously unseen malicious code to execute. By commonly enforcing a deny-by-default posture in which only explicitly approved applications, scripts, and executables may run, application control shifts the security model from identifying what is bad to permitting only what is known and authorized. This approach is often positioned as a foundational element of Zero Trust security, where nothing executes implicitly.

Because the practice restricts not only user-facing applications but, in some implementations, the code that runs in the system core, it can materially reduce the attack surface available to malware, ransomware, and unauthorized software. Whether delivered as an endpoint capability or as a network-based monitoring and control service, it gives organizations a means of governing what runs across endpoints, servers, and networks rather than reacting after execution has occurred.

A recurring source of confusion for GRC practitioners is that the phrase "application control(s)" also names an unrelated audit and financial-reporting control family concerned with the completeness, accuracy, validity, and authorization of data inside business applications. This entry addresses only the cybersecurity execution-control sense. Practitioners should confirm which meaning a given source intends before applying guidance, as the two families share a name but serve different objectives.

Who it's relevant to

Information security and IT operations teams
Teams responsible for endpoint and server security use application control to restrict which software may execute, applying an allowlisting or deny-by-default posture to reduce the risk of unauthorized or malicious code running in the environment.
Security architects designing Zero Trust programs
Because application control is often positioned as a foundation of Zero Trust security, where nothing runs implicitly, architects rely on it to enforce that only approved applications and code execute across endpoints and networks.
Risk managers and compliance officers
Those assessing the organization's control environment need to understand application control as an execution-restriction measure and to distinguish it clearly from the separately named audit and financial-reporting application controls, so that control mappings and assurance activities reference the correct family.
Network administrators
Where application control is delivered as a network-based service, administrators use it to monitor and control the use of applications across the network, complementing endpoint-level enforcement.

Inside Application Control

Allowlisting (approved execution set)
The defining component of application control in the cybersecurity sense: an explicitly approved inventory of applications, executables, scripts, libraries, and installers permitted to run. Anything not on the approved set is prevented from executing under a deny-by-default posture.
Deny-by-default enforcement
The operating principle that execution is blocked unless expressly authorized, inverting the traditional deny-known-bad model used by signature-based antivirus. This is the enforcement stance emphasized in guidance such as NIST SP 800-167 and the ACSC Essential Eight.
Attribute-based identification rules
The criteria used to identify approved software, which may include cryptographic file hashes, publisher or code-signing certificates, file paths, or a combination. The chosen attributes determine how precisely the control distinguishes authorized from unauthorized code.
Policy modes (enforcement vs. audit)
Operational settings that determine whether the control actively blocks disallowed execution (enforcement) or only logs what would have been blocked (audit or monitor mode), commonly used during tuning before full enforcement.
Exception and change handling
The process for adding, removing, or temporarily permitting software in the approved set, including how new business applications and legitimate updates are onboarded without weakening the deny-by-default posture.
Logging and telemetry
Records of allowed and blocked execution events that support monitoring, incident investigation, and tuning of the ruleset. This telemetry is where application control commonly intersects with broader detection and response activities.

Common questions

Answers to the questions practitioners most commonly ask about Application Control.

Is application control the same as the application controls that auditors test inside business systems for data completeness and accuracy?
No. This entry covers application control in the cybersecurity sense: an endpoint security capability that restricts which executables, scripts, and software can run on a system, typically on a deny-by-default (allowlisting) basis. That is distinct from the audit and financial-reporting concept often called 'application controls' (input, processing, output, and authorization controls embedded within a business application to help ensure completeness, accuracy, validity, and authorization of transactions). The two share a similar phrase but refer to unrelated control families. Guidance for one should not be applied to the other.
Does application control mean the same thing as antivirus or traditional signature-based malware detection?
Not quite. Antivirus and signature-based tools generally operate on a deny-known-bad model, blocking software identified as malicious. Application control, in the cybersecurity sense described here, more commonly operates on an allow-known-good model, permitting only approved software to execute and blocking everything else by default. The two approaches can be complementary, but they rest on different underlying assumptions and are not interchangeable.
How is an approved software list typically built and maintained for application control?
Organizations commonly establish an initial baseline by inventorying software already running in a known-good environment, then define allow rules using attributes such as cryptographic hash, publisher signature, file path, or a combination. Maintenance is generally an ongoing process, because approved software changes with patches, upgrades, and new business needs. Many programs pair the ruleset with a change process so that additions and removals are reviewed and recorded. This entry does not endorse specific tools or prescribe rule attributes for any particular environment.
How can application control be deployed without disrupting business operations?
A common approach is phased rollout: deploying first in an audit or monitor-only mode to observe what would be blocked, tuning the ruleset accordingly, and only then moving to enforcement. Piloting on a representative set of systems, engaging application owners early, and establishing an exception path for legitimate but unlisted software can reduce operational disruption. Specific timelines and thresholds vary by organization and are outside the scope of this entry.
Who is typically responsible for managing application control within an organization?
Day-to-day configuration and operation usually sit with an IT or information security function as a first line management activity. Where a second line risk or compliance function exists, it may set policy expectations and monitor adherence, while internal audit, as an independent assurance function, may evaluate whether the control is designed and operating effectively. These responsibilities should be kept distinct: the function operating the control is not the function providing independent assurance over it. Exact role allocation depends on the organization's structure and size.
How is the effectiveness of application control commonly evaluated over time?
Effectiveness is often assessed by reviewing whether the tool is running in enforcement mode across the intended scope, examining blocked-execution and exception logs, verifying that the ruleset reflects current approved software, and confirming that changes follow the defined process. Coverage gaps, stale rules, and overly broad exceptions are typical weaknesses to look for. No control guarantees prevention of all unauthorized execution; evaluation should treat application control as one layer among others. This entry does not provide specific testing procedures or legal advice.

Common misconceptions

Application control is the same as the audit concept of application controls that ensure the completeness, accuracy, validity, and authorization of data processed inside business applications (input, processing, and output controls).
These are two distinct control families that unfortunately share a similar phrase. This entry addresses application control in the cybersecurity sense: an endpoint allowlisting or deny-by-default execution control, as described in sources such as NIST SP 800-167 and the ACSC Essential Eight. The audit and financial-reporting concept of application controls embedded within business processes is a separate topic and is out of scope for this entry.
Application control is just another name for antivirus or anti-malware software.
Traditional antivirus typically relies on detecting known-bad indicators, whereas application control commonly operates on a deny-by-default basis, permitting only an approved set of software to execute. The approaches are complementary rather than equivalent, and many organizations deploy both.
Once configured, application control is a set-and-forget capability that guarantees a system cannot be compromised.
No single control guarantees security. Application control requires ongoing maintenance of the approved set as software changes, careful handling of updates and exceptions, and monitoring of logs. Poorly maintained rules can either block legitimate work or be loosened to the point of losing effectiveness.

Best practices

Begin in audit or monitor mode to build an accurate picture of legitimate software before switching to enforcement, reducing the risk of blocking business-critical applications.
Prefer stronger identification attributes such as cryptographic hashes or trusted publisher certificates over path-based rules alone, since path rules can be more easily circumvented.
Establish a defined process for onboarding new applications and handling routine updates so that the approved set stays current without resorting to broad, permissive exceptions.
Review and prune the approved set and any temporary exceptions periodically to prevent accumulation of unnecessary or outdated permissions.
Collect and monitor allowed and blocked execution telemetry, and integrate it with broader detection and response processes to support investigation and tuning.
Treat application control as one layer within a defense-in-depth approach rather than a standalone safeguard, and align its deployment with recognized guidance such as NIST SP 800-167 or the ACSC Essential Eight where applicable to the organization's context.
a promotional banner asking how ready are you for PCI DSS 4.0? With a call-to-action to get the checklist now.