ASD ISM 1635 System owners implement security controls for each system and environment
What it says
System owners implement security controls for each system and its operating environment.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishThe person accountable for a system must actually put its agreed security controls in place, covering both the system itself and the environment it runs in.
Every system has a system owner, the person accountable for it. This control says that owner is responsible for making sure the security controls chosen for that system are genuinely implemented, not just written down in a plan. It applies in two places: the system itself (the servers, applications, accounts and data) and the operating environment around it (the network it sits on, the facilities that house it, the platforms it depends on and the people and processes that run it). Why it matters: security controls are selected during design and risk assessment, but a control that has been selected and documented protects nothing until someone implements it. Gaps most often appear when nobody is clearly accountable, or when a system is protected in isolation while its surrounding environment (a shared network, a hosting platform, a server room) is left unaddressed. Naming the system owner as the accountable party closes that gap, and requiring coverage of the operating environment stops attackers from simply going around the system's own defences.
Free. Save your status, tasks and notes.
Why it matters
If system owners do not implement the controls agreed for their systems and operating environments, the organisation ends up with a documented security posture that does not match reality. Systems go live or keep running with known protections missing, any authorisation to operate is based on a false picture, and an attacker can exploit the unimplemented control or the unprotected environment to compromise the system and the information it holds. Accountability also blurs, so the gap may stay open for a long time before anyone notices.
How to implement
The system owner confirms with the security team which security controls have been selected for their system, and takes on the job of getting each of those controls implemented rather than leaving it to the design or risk assessment stage.
Each system owner takes the list of security controls selected for their system and adds the controls that apply to its operating environment (network, hosting platform, facility, supporting services), producing a single implementation checklist per system.
The system owner works with technical teams to implement each control on the checklist, recording who implemented it, when, and how, and marking any control that is not yet in place with a target date.
Where an operating-environment control is delivered by another team or a provider, the system owner obtains written confirmation that it is in place and covers their system, and files that confirmation against the checklist item.
The system owner re-runs the implementation checklist whenever the system or its operating environment changes (new network, new platform, new site, new functionality) and updates the implementation records before the changed system is used.
Keep it running
In practice this is an ongoing responsibility rather than a one-off task. Each system needs a named owner, and that owner needs a clear list of the security controls that apply to the system and to its operating environment, with implementation status tracked for each one. Day to day, the owner (or the teams working on the owner's behalf) implement controls before the system is used, confirm they are working, and keep them in place as the system and its environment change, for example when it moves to a new network, a new hosting platform or a new site. Where a control for the operating environment is delivered by someone else (a network team, a facilities team, a cloud provider), the system owner still needs to confirm it is in place for their system rather than assume it. Implementation status should be visible to whoever authorises the system to operate and should be revisited whenever the system, its environment or its control set changes.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask the system owner of a sampled system to walk through how they implemented a selection of its security controls, and to show the controls in place on the live system.
Look at
Compare the implemented configuration or verification results against the selected control, checking that it is actually in effect rather than only documented as planned.
Good evidence
The system owner can demonstrate each sampled control operating on the system and its operating environment, and can explain how they got it implemented.
- Check 2 of 5What an auditor asks for
Ask for
Ask a sample of system owners for the list of security controls that apply to their system and its operating environment.
Look at
Look for controls covering both the system itself and its surroundings, such as network, hosting platform and facility controls, not just the application or server.
Good evidence
The list is specific to the system, includes operating-environment controls, and the owner can explain where each control comes from.
- Check 3 of 5What an auditor asks for
Ask for
Ask for implementation records for the sampled systems, such as a control implementation checklist or status report.
Look at
Check that each control has a recorded implementation status, an implementer and a date, and that gaps are flagged rather than left blank.
Good evidence
Controls are marked implemented with supporting detail, and any not-yet-implemented controls have an owner and a target date.
- Check 4 of 5What an auditor asks for
Ask for
Ask how the system owner confirms controls delivered by other teams or providers for the operating environment.
Look at
Look for written confirmations, service agreements or evidence that the owner verified the environment control covers their system.
Good evidence
The owner holds evidence that shared or outsourced environment controls are in place for their system rather than assuming it.
- Check 5 of 5What an auditor asks for
Ask for
Ask for records from a recent change to a sampled system or its environment, such as a migration or network change.
Look at
Check whether the implementation checklist was revisited and controls confirmed or re-implemented after the change.
Good evidence
Implementation status was reviewed and updated as part of the change, before the changed system was used.
Mappings
Closest match in ISO/IEC 27001: A.7.6, Security measures for working in secure areas, which this control covers in full and more.
ISO/IEC 27001: 3 mappings
This control is broader than A.7.6.
ISM-1635 requires system owners to implement controls for systems and their operating environments. Annex A 7.6 focuses on designing and implementing security measures for working in secure areas, which is one environmental control a system owner may need. ISM-1635 is broader because it applies across all environments and across technical and operational controls.
This control is broader than A.8.8.
ISM-1635 requires system owners to implement controls to protect systems and their environments. Annex A 8.8 focuses on vulnerability exposure management, which is one category of controls a system owner would implement under ISM-1635. ISM-1635 is broader as it extends to all relevant environmental safeguards, not restricted to technical vulnerabilities.
This control is broader than A.8.19.
ISM-1635 requires system owners to implement security controls for each system and its operating environment. Annex A 8.19 is a specific operational control area within that obligation, requiring secure procedures and measures for installing software on production systems. ISM-1635 is broader because it is not limited to software installation and covers all environmental and system controls.
ASD Essential Eight: 2 mappings
This control is broader than E8-AC-ML1.2.
ISM-1635 requires system owners to implement controls that protect each system and its operating environment. E8-AC-ML1.2 specifies an application control coverage requirement to reduce execution of unauthorised code in common writeable paths. ISM-1635 is broader because it includes all relevant environmental controls, not only application control placement decisions.
This control is broader than E8-RA-ML1.5.
ISM-1635 requires system owners to implement controls for each system and its operating environment. E8-RA-ML1.5 requires privileged users to use separate privileged and unprivileged operating environments, which is a specific administrative-environment control that reduces credential theft risk. ISM-1635 is broader because it covers all required controls for the system and environment.
ASD Essentials for enterprise IT: 2 mappings
- IT.PRO-01.2Use secure build and deployment processes to enforce security controls consistentlyPartially overlaps
This control partially overlaps IT.PRO-01.2.
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.
- IT.PRO-04.2Deploy approved configuration baselines to all infrastructure, operating systems and applicationsPartially overlaps
This control partially overlaps IT.PRO-04.2.
IT.PRO-04.2 requires approved configuration baselines to be deployed on infrastructure, operating systems and applications; ISM-1635 requires system owners to implement security controls for each system and its operating environment, a broader duty that baselines help meet.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.