ASD Essentials IT.PRO-01.1 Design Systems with Telemetry, Least Privilege, Data Protection and Minimal Attack Surface
What it says
Design systems securely to provide visibility, enforce authorised access, protect data, minimise required and default privileges, limit exposed services and remove unnecessary functionality.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishDesigns systems securely so they log security events by default, enforce authorised access, protect data, and keep privileges, services and features minimal.
Security is planned into every system from the start, not added later. Each system logs security events by default and protects its data. It lets in only approved people and apps, and each account gets only the access it needs. To meet this, every system has anything it does not need switched off, such as built-in guest accounts or unused remote access. Design decisions are recorded and reviewed at each change.
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
Default settings, unneeded services and broad access rights give attackers easy ways in, routes to other systems and more power once inside. Without security logging, a break-in can go unnoticed, and unprotected data can be read, changed or stolen.
How to implement
The chief architect or IT lead should set a secure design standard that every new system and significant change must pass.
System owners record each design decision and exception in the system security plan, and update it at every change.
Security architects should list the security events each type of system must log by default, such as sign-ins and admin actions.
Make sure every system, old or new, sends them to security monitoring.
Identity and platform teams should make every way into a system require sign-in and an access check.
Give people and apps only the access they need, and remove, disable or change default accounts and admin rights before go-live.
System administrators should lock down each system using ASD and vendor guidance, switching off or removing anything it does not need.
Open needed services only to the networks that use them, then work through every existing system.
System owners and data owners should map the data each system collects, stores and shares, and keep only what it needs.
Protect it when stored and sent to match how sensitive it is, such as encrypting customer records.
Keep it running
System owners apply the design review to bought systems as well as built ones, and record a reason for anything unneeded that stays switched on. Watch for settings changing over time. New features, connections to other systems and vendor updates can quietly switch services back on, add accounts or change logging. Follow ASD's priority order for existing systems: internet-facing and sign-in systems first, then critical and admin systems, then business systems and staff devices.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the design records of sampled systems from each ASD domain, including one recently changed.
Look at
Whether systems run default settings with no recorded design decisions, or only some systems were designed securely.
Good evidence
Every sampled system has recorded design decisions, reviewed when it last changed.
- Check 2 of 5What an auditor asks for
Ask for
Ask for the logging requirements, the list of systems sending logs and recent security events.
Look at
Whether logging is off or left out of the design, or some systems send no logs.
Good evidence
Security logging is on by default, and every system in the asset list sends logs.
- Check 3 of 5What an auditor asks for
Ask for
Ask for each sampled system's accounts and permissions, including default accounts and those used by apps.
Look at
Whether default accounts or rights remain, accounts have extra access, or any way in skips access checks.
Good evidence
Every way in checks access, and default and required access is kept to a minimum.
- Check 4 of 5What an auditor asks for
Ask for
Request each sampled system's approved service list, settings export and recent scan results.
Look at
Whether unneeded services or features run with no recorded reason, or clean-up has been patchy rather than systematic.
Good evidence
Each system opens only needed services and runs only needed features, and exceptions have recorded reasons.
- Check 5 of 5What an auditor asks for
Ask for
Ask for each sampled system's data list and the protections its design called for.
Look at
Whether the planned protections are actually set up, and whether the system keeps data it does not need.
Good evidence
The planned data protections are in place, and the system holds only the data it needs.
ASD indicators of good practice (9)
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(3)
- NE-1Systems are deployed with default configurations and no evidence of security design considerations.
- NE-2Unnecessary services, protocols or functionality remain enabled with no documented rationale.
- NE-3Security telemetry is not enabled or is not considered as part of system design.
Partially effective(3)
- PE-1Security is considered during system design but not consistently applied across all assets.
- PE-2Some unnecessary services have been disabled but a systematic review has not been completed.
- PE-3Security telemetry is partially enabled but gaps in coverage exist.
Fully effective(3)
- FE-1Systems are designed and deployed with exposed services limited, required and default permissions minimised, data protections in place, authorised access enforced, and only required functionality enabled.
- FE-2Security telemetry is enabled by default.
- FE-3Evidence exists that security design decisions are recorded and reviewed during system changes.
Mappings
Closest match in ISO/IEC 27001: A.8.25, Secure Development Lifecycle, which this control partially meets.
ISO/IEC 27001: 6 mappings
This control partially meets A.8.25.
IT.PRO-01.1 requires systems to be designed securely to provide visibility, enforce authorised access, protect data, minimise privileges, limit exposed services and remove unnecessary functionality. Secure design is one part of the secure development of software and systems for which ISO/IEC 27001 Annex A 8.25 requires rules to be established and applied. Annex A 8.25 spans the whole development life cycle, while IT.PRO-01.1 concentrates on secure design outcomes.
This control partially meets A.8.27.
IT.PRO-01.1 requires systems to be designed securely to provide visibility, enforce authorised access, protect data, minimise required and default privileges, limit exposed services and remove unnecessary functionality. These are specific secure engineering outcomes of the kind ISO/IEC 27001 Annex A 8.27 requires to be established as principles and applied to all information system development. Annex A 8.27 is broader because it also requires the principles themselves to be documented and maintained, while IT.PRO-01.1 names particular design objectives.
This control partially overlaps A.5.15.
IT.PRO-01.1 requires systems to be designed securely, including enforcing authorised access, protecting data and minimising privileges. Building enforcement of authorised access into system design overlaps with the implementation of the access control rules required by ISO/IEC 27001 Annex A 5.15. Annex A 5.15 also requires the rules to be established from business and information security requirements and covers physical access, while IT.PRO-01.1 addresses wider secure design outcomes such as visibility and attack surface reduction.
This control partially overlaps A.8.2.
IT.PRO-01.1 requires systems to be designed securely, including minimising required and default privileges alongside enforcing authorised access, protecting data and reducing exposed services and functionality. Its privilege minimisation outcome overlaps directly with ISO/IEC 27001 Annex A 8.2, which requires the allocation and use of privileged access rights to be restricted and managed. IT.PRO-01.1 applies least privilege at design time as one of several secure design outcomes, while Annex A 8.2 governs the ongoing allocation and use of privileged access rights.
This control partially overlaps A.8.3.
IT.PRO-01.1 requires systems to be designed securely to enforce authorised access and protect data, among other outcomes. These outcomes overlap with ISO/IEC 27001 Annex A 8.3, which requires access to information and other associated assets to be restricted in accordance with the topic-specific policy on access control. Annex A 8.3 focuses on restricting access according to that policy, while IT.PRO-01.1 also covers visibility, privilege minimisation and attack surface reduction.
This control partially overlaps A.8.9.
IT.PRO-01.1 requires systems to be designed securely, including limiting exposed services and removing unnecessary functionality. These hardening outcomes are part of the security configurations that ISO/IEC 27001 Annex A 8.9 requires to be established, documented, implemented, monitored and reviewed. Annex A 8.9 covers the full configuration management process for hardware, software, services and networks, while IT.PRO-01.1 also covers design objectives such as visibility, access enforcement and data protection.
ASD Essential Eight: 1 mapping
This control partially overlaps E8-RA-ML3.1.
IT.PRO-01.1 requires secure system design that enforces authorised access and minimises required and default privileges; E8-RA-ML3.1 covers the privilege part, limiting privileged access to systems, applications and data repositories to what users and services need for their duties.
ASD Information Security Manual: 4 mappings
This control partially overlaps ISM-0041.
IT.PRO-01.1 requires secure system design that enforces authorised access, protects data, minimises privileges and limits exposed services; ISM-0041 documents it, requiring a system security plan covering each system's purpose, boundary, management and applicable security controls.
This control partially overlaps ISM-0380.
IT.PRO-01.1 requires secure system design that minimises privileges, limits exposed services and removes unnecessary functionality; ISM-0380 applies this to operating systems, requiring unneeded user accounts, components, services and functionality to be disabled or removed.
This control partially overlaps ISM-1409.
IT.PRO-01.1 requires secure system design that minimises privileges, limits exposed services and removes unnecessary functionality; ISM-1409 supports this for operating systems, hardening them with ASD and vendor guidance, with the most restrictive guidance prevailing in conflicts.
This control partially overlaps ISM-2021.
IT.PRO-01.1 requires secure system design that protects data, minimises privileges and removes unnecessary functionality; ISM-2021 supports the data protection aim, with system owners implementing and maintaining data minimisation practices for each system.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.