ASD ISM 2058 Ensure data validation before deserialisation
What it says
Data sources and serialised data inputs are validated before being deserialised.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishCheck data is correct before converting it from storage format to usable format to prevent issues.
This control is about ensuring that any data you collect or receive is checked carefully before it's converted into a format that your computer systems use. This matters because if the data is not checked, it could contain harmful elements that might damage your systems or allow unauthorised access.
Free. Save your status, tasks and notes.
Why it matters
If serialised inputs aren't validated before deserialisation, attackers can exploit unsafe deserialisation to execute code, tamper with data, or compromise systems.
How to implement
System owners should identify the sources of incoming data for their applications.
They can do this by listing all the external systems and users that send data and specifying the type of data they send. This helps in setting up necessary checks.
The IT team should create rules or scripts to validate the data format when it arrives.
They can do this by developing and testing scripts that check data against expected patterns or formats before any further processing.
Managers should ensure staff are trained in data validation techniques.
This can be done by organising workshops or providing simple guides that explain how to check and handle data securely.
System owners need to implement logging for data validation activities.
This involves setting up the system to keep records of all validation checks performed, which can then be reviewed if there are any issues.
The IT team should regularly update the data validation processes to adapt to new threats.
This involves reviewing validation scripts and patterns periodically to ensure they are up-to-date and effective against recent data threats.
Keep it running
Validate and allowlist expected schema/types before deserialising. Reject unexpected fields/classes and use safe deserialisers with integrity checks on untrusted inputs.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
The data validation procedure documentation: Request the written process details for how data is checked before being used.
Look at
Clear steps on what checks are done and who is responsible.
Good evidence
Includes a recent document with clear roles and step-by-step validation processes.
- Check 2 of 5What an auditor asks for
Ask for
To see the list of incoming data sources: Request the list or registry that identifies where data is coming from and its characteristics.
Look at
Completeness in terms of coverage of all data sources.
Good evidence
Shows a regularly updated list that corresponds with current business activities.
- Check 3 of 5What an auditor asks for
Ask for
Recent logs showing data validation activity: Request logs or reports generated during data validation.
Look at
The patterns of checks conducted and any errors or warnings recorded.
Good evidence
Logs reflecting regular checks and responses to any issues encountered.
- Check 4 of 5What an auditor asks for
Ask for
About staff training records on data handling: Request evidence that staff have been trained on data validation practices.
Look at
Dates, attendance records, and training content.
Good evidence
Includes recent training sessions with high attendance and relevant content.
- Check 5 of 5What an auditor asks for
Ask for
To see updates or reviews of validation scripts: Request records of changes or improvements to validation scripts.
Look at
The frequency and details of updates.
Good evidence
Includes scheduled reviews documented with dated changes and explanations.
Mappings
Closest match in ISO/IEC 27001: A.8.28, Secure coding practices in software development, which this control partially meets.
ISO/IEC 27001: 1 mapping
This control partially meets A.8.28.
ISM-2058 requires that data sources and serialised data inputs are validated before being deserialised to prevent malformed or malicious payloads being processed. This relates to Annex A 8.28 because input validation and safe handling of untrusted data (including deserialisation) are core secure coding principles applied during software development. Annex A 8.28 is broader, covering many secure coding practices beyond deserialisation-specific validation (e.g. authentication, authorisation, error handling and cryptographic misuse prevention).
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.