ASD Essentials IT.PRO-07.1 Restrict Execution to Supported, Verified and Authorised Software with Time-Bound Exceptions
What it says
Permit only supported, verified and organisation-authorised software to execute on systems, with exceptions minimised, formally risk accepted, time-bound, monitored and regularly reviewed.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishLets only supported, checked and approved software run on systems, keeping exceptions rare, signed off, time-limited, watched and regularly reviewed.
Computers, servers and network devices run only software the organisation has approved. It must still be supported by its maker and checked as genuine and unaltered. Everything else is blocked, such as a program in an email attachment or an unknown script. To meet this, blocking covers every applicable system and the approved list is reviewed on schedule. Any exception is rare, formally accepted as a risk, time-limited, watched and reviewed.
Free. Save your status, tasks and notes.
Where this action applies
What's in each domain?ASD orders the work by domain: apply this action to each ticked domain, phase by phase.
- Phase 3
Why it matters
Where any software can run, one harmful email attachment can let an attacker in to run their own tools. Gaps in coverage and open-ended exceptions let them slip past, and unsupported software has flaws that will never be fixed.
How to implement
The software asset owner should add software to the approved list only after a security check and formal approval.
Record its support status and how it is verified, review the list on schedule and remove anything unneeded or unsupported.
Endpoint and server teams should set application control (software blocking) to block, not just log, on every applicable system.
Cover programs, scripts, installers, drivers, libraries and macros, and on appliances such as firewalls allow only signed, supported vendor software.
Application control administrators should allow signed software by its publisher's digital signature, excluding unsupported versions.
Allow unsigned items by a file fingerprint (hash) matching the vendor's published one, never by file name alone or a folder users can change.
The security team should limit each exception to named software, systems and users, such as one finance app on two laptops.
Record it in a register, with the delegated risk owner's formal risk acceptance and an expiry date.
Security operations should alert when application control is switched off or tampered with, and watch each exception's use against its scope and expiry.
Exception owners should review each one on the set cycle, then renew or remove it.
Keep it running
The software asset owner keeps the approved list as the single source of truth, and sends new requests, version changes and end-of-support notices through it. Roll out blocking in ASD's priority order: internet-facing and sign-in systems first, then critical and admin systems, then business systems and staff devices. Confirm that any blocking already in place covers each ASD domain. Watch for systems slipping back into audit-only mode, which logs but does not block.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the approved software list, how software gets approved and the latest review records.
Look at
Whether the list is missing or overdue for review, or includes unapproved or unsupported software.
Good evidence
The list is reviewed on schedule, and every entry is approved, supported and verified.
- Check 2 of 5What an auditor asks for
Ask for
Request the coverage report against the asset list, and a test of unapproved software.
Look at
Whether systems lack blocking or run audit only, or unapproved, unsupported or altered files still run.
Good evidence
Blocking covers every applicable system, and unapproved, unsupported or altered software is stopped.
- Check 3 of 5What an auditor asks for
Ask for
Ask for the rule export and verification records for a sample of recently approved software.
Look at
Whether rules trust file names or user-writable folders, or unsigned items were allowed without a hash check.
Good evidence
Every permitted item is verified by a trusted method, such as publisher signature or hash.
- Check 4 of 5What an auditor asks for
Ask for
Request the exceptions register, with risk acceptances and expiry dates for a sample.
Look at
Whether exceptions lack formal approval or an expiry date, outlive their expiry, or are scoped too broadly.
Good evidence
Exceptions are few, narrowly scoped, formally risk accepted and time-limited.
- Check 5 of 5What an auditor asks for
Ask for
Ask how exception use is watched, and for the latest review records.
Look at
Whether exceptions go unwatched, miss their review cycle, or are renewed without a fresh risk acceptance.
Good evidence
Exceptions are watched and reviewed on the set cycle, and their number is kept low.
ASD indicators of good practice (10)
The indicators below are quoted as published from ASD's Assessment evidence guide for enterprise IT. These optional indicators help an assessor judge the action in each domain where it applies: if any not effective statement is true, the action is rated not effective; if every applicable fully effective statement is true and no other statement is, it is rated fully effective; otherwise it is rated partially effective. ASD says the indicators "do not replace expert judgement, nor are they intended to serve as a checklist".
Not effective(2)
- NE-1Unsupported, unverified or unauthorised software can execute without restriction.
- NE-2The list of approved software does not exist.
Partially effective(4)
- PE-1Execution restriction controls are deployed but do not cover all applicable assets.
- PE-2The organisation maintains a list of approved software, but it has not been reviewed within timeframes defined by the organisation.
- PE-3Execution restrictions are in place but integrity verification of approved software is not performed.
- PE-4Exceptions to execution restrictions are granted without formal approval or time-bounding.
Fully effective(4)
- FE-1Controls restrict execution to supported, organisation-authorised and integrity-verified software on all applicable assets.
- FE-2The organisation maintains a list of approved software and reviews it within the timeframes defined by the organisation.
- FE-3Integrity of permitted software is verified using trusted mechanisms appropriate to the software and its source.
- FE-4Exceptions are formally approved, documented, time-bound and reviewed on a regular cycle defined by the organisation.
Mappings
Closest match in ISO/IEC 27001: A.8.19, Secure Software Installation Procedures, which partially overlaps with this control.
ISO/IEC 27001: 2 mappings
This control partially overlaps A.8.19.
IT.PRO-07.1 requires that only supported, verified and organisation-authorised software can execute on systems, with exceptions minimised, formally risk accepted, time-bound, monitored and regularly reviewed. It shares common ground with Annex A 8.19, as both aim to limit operational systems to approved software. Annex A 8.19 focuses on procedures and measures for managing software installation, while IT.PRO-07.1 controls what is permitted to execute regardless of how it reached the system.
This control supports A.8.7.
IT.PRO-07.1 requires that only supported, verified and organisation-authorised software can execute on systems, with exceptions minimised and regularly reviewed. Application control of this kind is a strong preventive measure against malware, directly supporting Annex A 8.7 by stopping unauthorised executables from running. Annex A 8.7 is focused on malware and requires protection to be supported by user awareness, while IT.PRO-07.1 addresses software authorisation more broadly, including unsupported software.
ASD Essential Eight: 18 mappings
This control partially overlaps E8-AC-ML1.1.
IT.PRO-07.1 requires that only supported, verified and organisation-authorised software can execute; E8-AC-ML1.1 requires application control to be implemented on workstations, enforcing the authorisation part on one class of system.
This control partially overlaps E8-AC-ML1.2.
IT.PRO-07.1 requires that only supported, verified and organisation-authorised software can execute; E8-AC-ML1.2 applies application control to user profiles and temporary folders used by operating systems, web browsers and email clients, enforcing the authorisation part in those locations.
This control partially overlaps E8-AC-ML1.3.
IT.PRO-07.1 requires that only supported, verified and organisation-authorised software can execute; E8-AC-ML1.3 restricts execution of executables, libraries, scripts, installers, compiled HTML, HTML applications and control panel applets to an organisation-approved set, enforcing the authorisation part.
This control partially overlaps E8-AC-ML2.1.
IT.PRO-07.1 requires that only supported, verified and organisation-authorised software can execute; E8-AC-ML2.1 requires application control to be implemented on internet-facing servers, enforcing the authorisation part on one class of system.
This control partially overlaps E8-AC-ML2.2.
IT.PRO-07.1 requires that only supported, verified and organisation-authorised software can execute; E8-AC-ML2.2 applies application control to all locations other than user profiles and temporary folders used by operating systems, web browsers and email clients, enforcing the authorisation part in the remaining locations.
This control partially overlaps E8-AC-ML2.3.
IT.PRO-07.1 requires that only supported, verified and organisation-authorised software can execute; E8-AC-ML2.3 requires Microsoft's recommended application blocklist to be implemented, a supporting measure that blocks the applications on that list.
This control partially overlaps E8-AC-ML2.4.
IT.PRO-07.1 requires that only supported, verified and organisation-authorised software can execute, with exceptions regularly reviewed; E8-AC-ML2.4 requires application control rulesets to be validated at least annually, overlapping on periodic review of what may run.
This control partially overlaps E8-AC-ML3.1.
IT.PRO-07.1 requires that only supported, verified and organisation-authorised software can execute; E8-AC-ML3.1 requires application control to be implemented on non-internet-facing servers, enforcing the authorisation part on one class of system.
This control partially overlaps E8-AC-ML3.2.
IT.PRO-07.1 requires that only supported, verified and organisation-authorised software can execute; E8-AC-ML3.2 restricts the execution of drivers to an organisation-approved set, applying the authorisation part to drivers.
This control partially overlaps E8-AC-ML3.3.
IT.PRO-07.1 requires that only supported, verified and organisation-authorised software can execute; E8-AC-ML3.3 requires Microsoft's vulnerable driver blocklist to be implemented, a narrower measure that blocks the vulnerable drivers on that list.
This control partially overlaps E8-RM-ML1.2.
IT.PRO-07.1 requires that only supported, verified and organisation-authorised software can execute; E8-RM-ML1.2 blocks Microsoft Office macros in files originating from the internet, a narrower control on which code can run.
This control partially overlaps E8-RM-ML1.3.
IT.PRO-07.1 requires that only supported, verified and organisation-authorised software can execute; E8-RM-ML1.3 requires Microsoft Office macro antivirus scanning to be enabled, a supporting check on macro code.
This control partially overlaps E8-RM-ML2.1.
IT.PRO-07.1 requires that only supported, verified and organisation-authorised software can execute; E8-RM-ML2.1 blocks Microsoft Office macros from making Win32 API calls, a related restriction on what macro code can do.
- E8-RM-ML3.1Restrict Microsoft Office macros to only trusted or sandboxed environmentsPartially overlaps
This control partially overlaps E8-RM-ML3.1.
IT.PRO-07.1 requires that only supported, verified and organisation-authorised software can execute; E8-RM-ML3.1 lets Microsoft Office macros execute only if sandboxed, in a Trusted Location or digitally signed by a trusted publisher, a narrower restriction on which macros can run.
- E8-RM-ML3.2Check Microsoft Office macros for malicious code before signing or trustingPartially overlaps
This control partially overlaps E8-RM-ML3.2.
IT.PRO-07.1 requires that only supported, verified and organisation-authorised software can execute; E8-RM-ML3.2 requires Microsoft Office macros to be checked for malicious code before being digitally signed or placed in Trusted Locations, a verification step for macros.
This control partially overlaps E8-RM-ML3.3.
IT.PRO-07.1 requires that only supported, verified and organisation-authorised software can execute; E8-RM-ML3.3 lets only the privileged users who check Microsoft Office macros for malicious code write to and modify content in Trusted Locations, protecting the approved set of macros.
- E8-RM-ML3.4Untrusted Publisher Macros Cannot Be Enabled via Message Bar or Backstage ViewPartially overlaps
This control partially overlaps E8-RM-ML3.4.
IT.PRO-07.1 requires that only supported, verified and organisation-authorised software can execute; E8-RM-ML3.4 ensures Microsoft Office macros signed by an untrusted publisher cannot be enabled via the Message Bar or Backstage View, a narrower case of that rule.
- E8-RM-ML3.5Block enabling of non-V3 signed Microsoft Office macros via Message BarPartially overlaps
This control partially overlaps E8-RM-ML3.5.
IT.PRO-07.1 requires that only supported, verified and organisation-authorised software can execute; E8-RM-ML3.5 ensures Microsoft Office macros signed with anything other than V3 signatures cannot be enabled via the Message Bar or Backstage View, a narrower case of that rule.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.