ASD ISM 2016 Ensure input validation and sanitisation for security
What it says
Validation and sanitisation are performed on all input received over a local network by software.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishSoftware must check and clean all local network inputs to prevent security issues.
Ensuring that all information entering your software from your local network is checked and cleaned is like making sure no mud gets on your carpet: it helps keep everything inside safe and tidy. If you skip this step, you might let in harmful data, which could lead to software crashes or even allow some malicious person to control your system.
Free. Save your status, tasks and notes.
Why it matters
Poor input validation and sanitisation allow attackers to execute malicious code, leading to data breaches and significant business disruption.
How to implement
IT team should identify all pathways where data enters the system from the local network.
This includes things like forms on websites or data input from other software. Map out these points to ensure all are accounted for.
System developers need to create rules for what valid input should look like.
This can involve setting limits on what data is allowed, like ensuring phone numbers don't contain letters. Clearly define these rules in your software requirements.
Software testers should routinely check that input validation is working as intended.
They can do this by attempting to enter both valid and invalid data to see if the system correctly accepts or rejects it.
Managers should ensure staff understand the importance of input validation.
Conduct training sessions that explain why and how data entering the system can be dangerous if not properly checked.
Procurement officers should ensure any software being considered for purchase includes input validation capabilities.
Request this information from the vendor in clear terms and ensure it is part of the evaluation criteria during software selection.
Keep it running
Validate and sanitise all local-network inputs using allow-lists; centralise checks at every entry point; fuzz test and log rejected or anomalous values.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
A list of all input points identified by the IT team.
Look at
Whether every entry point from the network to the system is covered. Good means no gaps in the listed input sources and all being accounted for.
- Check 2 of 5What an auditor asks for
Look at
Whether these rules are comprehensive and address all types of input.
Good evidence
Includes clear guidelines that cover common and uncommon input scenarios.
- Check 3 of 5What an auditor asks for
Ask for
Results of testing routines from software testers.
Look at
The records of both successful and unsuccessful validation tests. Good results will show that invalid inputs were predictably rejected and valid inputs were accepted.
- Check 4 of 5What an auditor asks for
Look at
Attendance logs and training materials.
Good evidence
Outcome shows regular sessions with most relevant staff having attended.
- Check 5 of 5What an auditor asks for
Ask for
Procurement officers for software procurement criteria documentation.
Look at
Whether input validation features are a stated requirement.
Good evidence
Document lists clear input validation as a mandatory feature in software systems.
Mappings
Closest match in ISO/IEC 27001: A.8.25, Secure development lifecycle, which this control partially meets.
ISO/IEC 27001: 2 mappings
This control partially meets A.8.25.
ISM-2016 requires software to validate and sanitise all inputs received over a local network. ISO/IEC 27001:2022 Annex A 8.25 requires an organisation to establish and apply secure development lifecycle rules, within which input validation requirements are commonly defined, implemented, and verified. Annex A 8.25 is broader as it covers governance and end-to-end SDLC practices (e.g. design, testing, release) whereas ISM-2016 is a specific technical requirement for input handling.
This control partially meets A.8.28.
ISM-2016 requires validation and sanitisation to be performed on all input received over a local network by software. ISO/IEC 27001:2022 Annex A 8.28 requires secure coding principles to be applied to software development, which would typically include input validation and sanitisation as a core secure coding practice. Annex A 8.28 is broader because it covers many secure coding principles beyond input handling, while ISM-2016 is specifically focused on the control to prevent input-driven vulnerabilities.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.