ASD Essentials IT.PRO-01.2 Use Secure Build and Deployment Processes to Enforce Security Controls Consistently
What it says
Secure build and deployment processes to enforce controls consistently across systems.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishBuilds, deploys and changes systems through secure, controlled processes with testing and approval, so security controls are applied consistently across systems.
Systems are built from approved templates, such as a standard laptop setup, and changed through one controlled process, not by hand. Each change is kept in version control, a tool that records every change and who made it. To meet this, every change is tested, security checked and approved before it goes live. Afterwards, the team confirms the protections are really in place on every system the change reached.
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
Without a controlled process, systems end up set up differently, and some lose protections others have. Untested or unapproved changes can weaken security unnoticed. The weakest system becomes the way in, and a bad change is hard to trace or undo.
How to implement
The platform engineering lead should set up a controlled build for every type of asset.
Each system is then built from an approved template, such as a standard server image, that already includes the required security settings.
Engineers should keep every build file, settings file and release script in version control.
A second engineer reviews each change, and only authorised staff can change approved versions.
The change owner should test each change away from live systems.
Run a security check before release, such as a settings scan against the approved build, and set the release tool (which rolls out changes) to block failures.
The change manager should approve each settings change before release, and the release tool should only roll out tested, approved versions from version control.
System administrators follow each system's plan for managing changes and settings.
System owners should confirm after each release that the security settings are in place on every system it reached.
Use reports that compare each system with the approved build, and roll out again to fix any gap.
Keep it running
Treat the controlled process as the only route for builds and settings changes. Urgent fixes take a faster test and approval path within it, never a manual edit on a live system. Roll it out in ASD's priority order: internet-facing and sign-in systems first, then critical and admin systems, then business systems and staff devices. Keep the after-release check results with each change record, so the team can show which approved version every system runs.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the build and release process and the approved builds for each type of asset.
Look at
Whether some asset types, such as firewalls or laptops, are still built and changed by hand.
Good evidence
Every relevant type of asset is built and changed through the controlled process.
- Check 2 of 5What an auditor asks for
Ask for
Request a list of recent live changes from release and system logs, with their change records.
Look at
Whether any changes skipped the process, such as manual edits on live systems or unrecorded releases.
Good evidence
Every sampled change, urgent fixes included, went through the controlled process.
- Check 3 of 5What an auditor asks for
Ask for
Ask for the version control history of sampled build and settings files.
Look at
Whether settings exist only on live systems, or changes lack a recorded author, reason or reviewer.
Good evidence
Settings are in version control, and each change shows its author, reason and reviewer.
- Check 4 of 5What an auditor asks for
Ask for
Request the test results, security check results and approvals for the sampled changes.
Look at
Whether only basic function testing was done with no security check, or approval came after release.
Good evidence
Each change was tested, security checked and approved before release.
- Check 5 of 5What an auditor asks for
Ask for
Ask for the after-release check reports for recent releases in each relevant ASD domain.
Look at
Whether anyone confirms protections after release, and whether similar systems show different or missing protections.
Good evidence
After-release checks show the same protections on every system, and gaps are fixed.
ASD indicators of good practice (7)
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-1No controlled build or deployment process exists for applicable assets.
- NE-2Changes to systems are applied ad hoc, without any version control, testing or approval.
Partially effective(2)
- PE-1A controlled deployment process exists but is not consistently followed for all changes.
- PE-2Version control is in place but pre-deployment security verification is not performed.
Fully effective(3)
- FE-1A controlled build and deployment process is in place and consistently followed.
- FE-2Configuration changes are subject to version control, testing and approval before deployment.
- FE-3Security controls are confirmed to be implemented consistently across systems following deployment processes.
Mappings
Closest match in ISO/IEC 27001: A.8.9, Configuration Management for Secure IT Systems, which partially overlaps with this control.
ISO/IEC 27001: 3 mappings
This control partially overlaps A.8.9.
IT.PRO-01.2 requires secure build and deployment processes that enforce security controls consistently across systems. Consistent, secure builds are a primary means of implementing the security configurations required by ISO/IEC 27001 Annex A 8.9. Annex A 8.9 also requires configurations to be established, documented, monitored and reviewed over time, while IT.PRO-01.2 focuses on the build and deployment processes themselves.
This control partially overlaps A.8.19.
IT.PRO-01.2 requires secure build and deployment processes that enforce security controls consistently across systems. Securing the deployment process directly addresses the secure management of software installation on operational systems required by ISO/IEC 27001 Annex A 8.19. IT.PRO-01.2 also covers system builds and consistent control enforcement, while Annex A 8.19 applies to any software installation on operational systems, however it occurs.
This control partially overlaps A.8.25.
IT.PRO-01.2 requires secure build and deployment processes that enforce security controls consistently across systems. Securing build and deployment pipelines forms 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 covers the wider development life cycle, including design, coding and testing, while IT.PRO-01.2 also extends to consistent control enforcement when deploying any system.
ASD Information Security Manual: 4 mappings
- ISM-1211System Administration Performed Under Change and Configuration Management PlanPartially overlaps
This control partially overlaps ISM-1211.
IT.PRO-01.2 requires secure build and deployment processes that enforce controls consistently across systems; ISM-1211 supports that consistency, requiring system administration activities to follow the system's change and configuration management plan.
This control partially overlaps ISM-1409.
IT.PRO-01.2 requires secure build and deployment processes that enforce controls consistently across systems; ISM-1409 defines hardening that such processes can enforce for operating systems, using ASD and vendor guidance with the most restrictive taking precedence.
This control partially overlaps ISM-1635.
IT.PRO-01.2 requires secure build and deployment processes that enforce controls consistently across systems; ISM-1635 is the underlying duty, with system owners implementing security controls for each system and its operating environment.
This control partially overlaps ISM-1914.
IT.PRO-01.2 requires secure build and deployment processes that enforce controls consistently across systems; ISM-1914 supports this for operating systems, requiring approved configurations to be developed, implemented and maintained.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.