ASD ISM 1826 Select vendors committed to secure design for servers
What it says
Vendors that have demonstrated a commitment to Secure by Design and Secure by Default principles and practices, including secure programming practices and either memory-safe programming languages or less preferably memory-safe programming practices, are used for server applications.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishChoose server vendors who ensure secure designs and use safe programming practices.
When choosing companies to buy your computer servers from, make sure they are serious about safety from the very start. This matters because if the computer servers are not built securely, they can be more easily hacked, which could lead to loss of customer information, downtime, or financial trouble.
Free. Save your status, tasks and notes.
Why it matters
Choosing server app vendors without Secure by Design/Default increases bug density and memory-safety flaws, enabling RCE, data loss and outages.
How to implement
IT teams should ask vendors about their security practices: Contact vendor representatives to learn about how they ensure their server products are secure from the start.
Inquire about their use of memory-safe programming languages or techniques.
Managers should evaluate vendor security certifications: Ensure that vendors have relevant security certifications such as ISO 27001 or attestations that show their commitment to secure designs.
Request documentation or proof of certification from vendors.
System administrators should test the security features: Once servers are purchased, they should be tested in a controlled environment to confirm advertised security features are present and working.
Use tools to verify if security settings are enabled by default.
Procurement teams should keep records of vendor assessments: Create a file or database entry for each vendor that lists their security practices, certifications, and evaluation results.
This ensures there is a record to refer back to for future purchases.
Keep it running
Require evidence of Secure by Design/Default (SDLC, secure coding, VDP). Prefer memory-safe languages; otherwise verify mitigations and testing for memory bugs.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Vendor security policy documents: Request copies of vendor documentation that describe their Secure by Design and Secure by Default policies.
Look at
Specific mentions of security features and practices included in their server products.
Good evidence
Contains detailed descriptions of how security is integrated into server design.
- Check 2 of 5What an auditor asks for
Ask for
Vendor compliance reports: Request any reports that show the vendor's compliance with security standards.
Look at
The dates and any comments regarding compliance issues.
Good evidence
Would show up-to-date, clean compliance reports with recognitions by third parties.
- Check 3 of 5What an auditor asks for
Ask for
To see records of vendor evaluations: Review procurement records to see the criteria used to assess server vendors.
Look at
Whether security practices were a determining factor in vendor selection.
Good evidence
Means seeing detailed assessments focusing on security.
- Check 4 of 5What an auditor asks for
Ask for
To see server security configuration tests: Request demonstration results of security configurations on newly purchased servers.
Look at
The test results to see if advertised security features were present.
Good evidence
Shows comprehensive tests confirming security settings are as specified.
- Check 5 of 5What an auditor asks for
Ask for
To see meeting minutes from procurement discussions.
Look at
Records from meetings where server vendors were discussed, noting any focus on security.
Good evidence
Has minutes showing security was a key topic of discussion with actions assigned to verify it.
Mappings
Closest match in ISO/IEC 27001: A.5.19, Managing information security in supplier relationships, which this control partially meets.
ISO/IEC 27001: 6 mappings
This control partially meets A.5.19.
ISM-1826 requires organisations to choose server vendors that demonstrate commitment to Secure by Design and secure programming practices (preferably memory-safe languages). Annex A 5.19 requires processes and procedures to manage information security risks arising from supplier products and services generally. ISM-1826 fits within supplier relationship risk management but is narrower and more prescriptive about secure design evidence specifically for server applications.
This control partially meets A.5.21.
ISM-1826 requires organisations to select server application vendors committed to Secure by Design/Secure by Default practices, including secure programming and preference for memory-safe languages. Annex A 5.21 requires managing information security risks across the broader ICT supply chain, including products and services sourcing. ISM-1826 is a specific supplier selection criterion focused on vendor engineering practices for server applications, while Annex A 5.21 covers end-to-end supply chain risk management beyond secure design.
This control partially meets A.5.22.
ISM-1826 requires selecting vendors whose server applications are engineered with Secure by Design/Secure by Default and strong secure programming practices. Annex A 5.22 requires the organisation to monitor, review, evaluate and manage changes in supplier security practices and service delivery over time. ISM-1826 addresses the upfront selection decision, while Annex A 5.22 extends into ongoing supplier governance after selection.
This control partially overlaps A.8.28.
ISM-1826 requires selecting vendors for server applications who apply secure programming practices and, preferably, use memory-safe programming languages. Annex A 8.28 requires secure coding principles to be applied to software development. ISM-1826 supports Annex A 8.28 by driving procurement towards products built with secure coding, but Annex A 8.28 applies to the organisation's development activities generally and does not specifically address vendor selection or secure-by-default vendor commitment evidence.
This control partially overlaps A.8.30.
ISM-1826 requires choosing server application vendors that demonstrate secure design and secure programming practices, including preference for memory-safe languages. Annex A 8.30 requires the organisation to direct, monitor and review outsourced system development activities. They overlap where server applications are custom-built or developed by vendors on the organisation's behalf, but ISM-1826 focuses on vendor selection criteria whereas Annex A 8.30 is about governance and oversight of the development work regardless of the vendor's secure-by-design maturity.
This control supports A.8.27.
ISM-1826 requires the organisation to select server vendors that demonstrate Secure by Design/Secure by Default and strong secure programming practices. Annex A 8.27 requires establishing and applying secure system architecture and engineering principles across information system development activities. ISM-1826 supports Annex A 8.27 by ensuring third-party server applications are more likely to align with secure engineering principles, but Annex A 8.27 is broader and includes the organisation's own architecture decisions and engineering practices beyond vendor choice.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.