Document, Build and Test All Input Validation Rules
Every rule for checking incoming data must be written down, built into the software, and tested with both valid and invalid inputs.
Plain language
Input validation means checking that any data entering your software (like a form field, file upload, or web address) is the right type, length and format before the software acts on it. This control says every one of those checking rules must be written down, actually built into the code, and then tested with both good data (that should be accepted) and bad data (that should be rejected). It matters because attackers feed software unexpected or malicious data to break it or steal information, and untested validation is one of the most common ways software gets compromised.
Framework
ASD Information Security Manual (ISM)
Control effect
Preventative
Classifications
NC, OS, P, S, TS
ISM last updated
June 2026
Control Stack last updated
18 June 2026
E8 maturity levels
N/A
Guideline
Guidelines for software developmentOfficial control statement
All input validation rules are documented, implemented in code, and tested using both positive and negative unit tests and integration tests.
Why it matters
Untested or missing input validation lets attackers feed malicious data into the software, enabling data theft, fraud, or system compromise such as SQL injection.
Operational notes
Re-run the positive and negative tests on every code change and update the rules document whenever a new input is added, so validation never falls out of step with the software.
Implementation tips
- A business analyst or lead developer should write down every input validation rule in a single requirements document, listing each input the software accepts (form fields, uploaded files, web addresses, search boxes) and the exact rule for each (allowed type, maximum length, permitted characters, required format).
- Developers should build each documented rule directly into the code at the point where data first enters the system, rejecting anything that does not match the rule rather than trying to clean it up, so that nothing slips through unchecked.
- Developers should write positive unit tests that confirm the software accepts correctly formatted data, and negative unit tests that confirm it rejects bad data such as overly long entries, wrong characters, blank fields, and known attack patterns, covering every rule in the document.
- The development team should add integration tests that send data through the whole connected system (for example from the web page through to the database) to confirm validation still holds when the parts work together, not just in isolation.
- A team lead should keep the validation rules document, the code, and the tests in step by reviewing them together whenever a new input is added or an existing one changes, so the three never drift apart.
Audit / evidence tips
- Askthe document that lists all input validation rulesLook atwhether it names every input the software accepts and states a clear rule for each (type, length, allowed characters, format)Goodis a current, complete list that maps to the inputs you can see in the live application, not a vague one-line policy
- Askthe developers to show you where a specific rule from the document is enforced in the codeLook atwhether the code actually rejects bad data at the entry pointGoodis the reviewer pointing to the exact line of code matching the documented rule with no gaps
- Askto see the positive unit testsLook atwhether there is a test confirming valid data is accepted for each ruleGoodshows recent passing tests covering the full range of inputs, not just one or two examples
- Askto see the negative unit testsLook atwhether bad inputs (too long, wrong characters, blank, malicious strings) are tested and confirmed rejectedGooddemonstrates deliberate attempts to break each rule, all caught by the tests
- Askthe integration test results that exercise validation across connected componentsLook atwhether data is validated end to end, not just in a single moduleGoodis a recent test run report showing both valid and invalid data handled correctly through the whole flow
Cross-framework mappings
How ISM-2057 relates to controls across ISO/IEC 27001, ISO/IEC 42001, Essential Eight, and ASD ISM.
ISO 27001
| Control | Notes | Details |
|---|---|---|
layersPartially meets(3)expand_less | ||
| Annex A 8.25 | ISM-2057 mandates comprehensive input validation rules are documented, correctly implemented, and tested with both positive and negative ... | |
| Annex A 8.28 | ISM-2057 requires documented input validation rules that are implemented in code and verified through positive and negative unit or integ... | |
| Annex A 8.29 | ISM-2057 focuses on ensuring input validation is specified, implemented, and tested using positive and negative unit or integration tests | |
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.
Related ASD ISM controls in Software development
See all Guidelines for software development controls, or browse the full ASD ISM library.