Skip to content
Software development
ASD ISMISM-2057

ASD ISM 2057 Document, build and test all input validation rules

What it says

All input validation rules are documented, implemented in code, and tested using both positive and negative unit tests and integration tests.

Quoted as published. Everything else on this page is written by Control Stack.

What it means

In plain English

Every rule for checking incoming data must be written down, built into the software, and tested with both valid and invalid inputs.

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.

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.

How to implement

  1. 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).

  2. 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.

  3. 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.

  4. 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.

  5. 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.

Keep it running

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.

Evidence and audit

  1. Check 1 of 5What an auditor asks for

    Ask for

    the document that lists all input validation rules.

    Look at

    whether it names every input the software accepts and states a clear rule for each (type, length, allowed characters, format).

    Good evidence

    is a current, complete list that maps to the inputs you can see in the live application, not a vague one-line policy.

  2. Check 2 of 5What an auditor asks for

    Ask for

    the developers to show you where a specific rule from the document is enforced in the code.

    Look at

    whether the code actually rejects bad data at the entry point.

    Good evidence

    is the reviewer pointing to the exact line of code matching the documented rule with no gaps.

  3. Check 3 of 5What an auditor asks for

    Ask for

    to see the positive unit tests.

    Look at

    whether there is a test confirming valid data is accepted for each rule.

    Good evidence

    shows recent passing tests covering the full range of inputs, not just one or two examples.

  4. Check 4 of 5What an auditor asks for

    Ask for

    to see the negative unit tests.

    Look at

    whether bad inputs (too long, wrong characters, blank, malicious strings) are tested and confirmed rejected.

    Good evidence

    demonstrates deliberate attempts to break each rule, all caught by the tests.

  5. Check 5 of 5What an auditor asks for

    Ask for

    the integration test results that exercise validation across connected components.

    Look at

    whether data is validated end to end, not just in a single module.

    Good evidence

    is a recent test run report showing both valid and invalid data handled correctly through the whole flow.

Mappings

Closest match in ISO/IEC 27001: A.8.29, Security testing in development and acceptance, which this control covers in full and more.

ISO 27001

ISO/IEC 27001: 3 mappings

  • A.8.29Security testing in development and acceptanceBroader than
  • A.8.25Secure development lifecyclePartially meets
  • A.8.28Secure coding practices in software developmentPartially meets

Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.