Defining Security Requirements for Applications
Ensure security needs are clear and approved when creating or buying applications.
Plain language
When developing or acquiring new applications, it's crucial to clearly define and approve security requirements. This ensures that sensitive information remains confidential and protected from threats like viruses or data breaches. If this isn't done, the application's integrity could be compromised, leading to potential financial loss or reputational damage for the organisation.
Framework
ISO/IEC 27001:2022
Control effect
Preventative
ISO 27001 domain
Technological controls
Classifications
N/A
Official last update
24 Oct 2022
Control Stack last updated
19 Mar 2026
Maturity levels
N/A
Official control statement
Information security requirements shall be identified, specified and approved when developing or acquiring applications.
Why it matters
Undefined application security requirements can cause insecure design, data breaches, compliance failures, costly rework, and loss of customer trust.
Operational notes
Define, document and approve application security requirements (privacy, authn/authz, logging, encryption) during SDLC and procurement, and trace them to tests and sign-off.
Implementation tips
- The IT manager should assess the security needs of a new application by conducting a risk assessment. This means evaluating potential threats and vulnerabilities the application might face and determining how serious they could be. Use the insights from ISO 27002:2022 to guide this assessment process.
- IT staff should collaborate with information security specialists to define clear security requirements. This involves specifying necessary security features like authentication measures that confirm user identities and access limits. Following the guidelines in the Privacy Act 1988 can help ensure legal compliance.
- Procurement teams must incorporate security criteria in their purchasing decisions when acquiring applications. This process involves ensuring that potential vendors provide sufficient security guarantees or certifications, aligning with Australian Cyber Security Centre (ASD) Essential Eight recommendations.
- The IT department needs to establish a process to review and approve all security requirements before the development or acquisition of applications begins. Develop a checklist that includes considerations from ISO 27002:2022, such as protecting data in transit and ensuring input validation.
- Compliance officers should ensure that applications meet all relevant legal and regulatory requirements. This involves checking that applications adhere to regulations set forth by the Office of the Australian Information Commissioner (OAIC), ensuring data privacy and protection requirements are met.
Audit / evidence tips
-
Askthe documented risk assessment related to the application
Gooda detailed and thorough assessment that aligns with ISO 27002:2022 guidance
-
Askthe documented security requirements specification for the application
Gooda well-structured document that addresses all key areas mentioned in ISO 27002:2022
-
Askrecords of the approvals process for security requirements
-
Askprocurement documentation that includes security evaluations of vendors
-
Askrecords of compliance checks with Australian regulations like OAIC guidelines
Cross-framework mappings
How Annex A 8.26 relates to controls across ISO/IEC 27001, Essential Eight, and ASD ISM.
ASD ISM
| Control | Notes | Details |
|---|---|---|
| layers Partially meets (15) expand_less | ||
| ISM-0246 | ISM-0246 requires that an emanation security threat assessment is sought as early as possible in the system lifecycle when required | |
| ISM-1239 | ISM-1239 requires robust web application frameworks to be used when developing web applications | |
| ISM-1424 | ISM-1424 requires web server software to implement specific web security response headers (e.g | |
| ISM-1552 | ISM-1552 requires all web application content to be delivered exclusively using HTTPS to protect confidentiality and integrity in transit | |
| ISM-1597 | ISM-1597 requires credentials to be obscured as they are entered into systems, which is an explicit security requirement for authenticati... | |
| ISM-1806 | ISM-1806 requires default user accounts or credentials for user applications to be changed, disabled or removed during initial setup | |
| ISM-1850 | ISM-1850 requires the OWASP Top 10 risks to be mitigated as part of web application development | |
| ISM-1851 | ISM-1851 requires web API developers to mitigate the OWASP API Security Top 10 risks | |
| ISM-1917 | ISM-1917's focus on supporting specific PQC and strong algorithms by 2030 through procurement and development can be captured within ISO/... | |
| ISM-2046 | ISM-2046 demands that impersonation features do not result in sensitive data being logged, with appropriate permissions set on the logs | |
| ISM-2055 | ISM-2055 requires using build provenance (when available) for imported third-party software components during development to ensure they ... | |
| ISM-2063 | ISM-2063 requires web applications to set session cookies with HttpOnly, Secure and SameSite flags by default where supported | |
| ISM-2064 | ISM-2064 specifies a concrete security requirement for web sessions: cookies must only carry digitally signed opaque bearer tokens | |
| ISM-2065 | ISM-2065 requires web applications using opaque bearer session cookies (not digitally signed) to generate non-sequential random session i... | |
| ISM-2072 | ISM-2072 requires AI model artefacts to be stored in a non-executable file format to prevent arbitrary code execution | |
| sync_alt Partially overlaps (2) expand_less | ||
| ISM-1739 | ISM-1739 requires the security architecture for a system to be approved before the system is developed | |
| ISM-2033 | Annex A 8.26 requires information security requirements to be identified, specified and approved when developing or acquiring applications | |
| handshake Supports (12) expand_less | ||
| ISM-0471 | ISM-0471 requires the use of only high assurance cryptographic algorithms in cryptographic equipment, applications and libraries | |
| ISM-0481 | ISM-0481 requires that applications and libraries use only approved high assurance cryptographic protocols | |
| ISM-0971 | Annex A 8.26 requires organisations to identify, specify and approve security requirements for applications during development or acquisi... | |
| ISM-1238 | ISM-1238 requires organisations to apply threat modelling in the SDLC to identify potential risks early in development | |
| ISM-1568 | ISM-1568 requires organisations to procure applications and technology from suppliers that demonstrate a commitment to secure products an... | |
| ISM-1849 | ISM-1849 requires the use of OWASP Top 10 Proactive Controls as a practical security baseline during web application development | |
| ISM-2027 | ISM-2027 requires that software artefacts are verified for authenticity and integrity before being imported into the authoritative source | |
| ISM-2028 | ISM-2028 requires third-party software artefacts to be tested using SAST, DAST and SCA before being imported and throughout the SDLC | |
| ISM-2039 | ISM-2039 requires the software threat model to be reviewed throughout the SDLC to ensure it remains aligned to the as-built system and th... | |
| ISM-2041 | Annex A 8.26 requires security requirements to be identified, specified and approved for applications being developed or acquired | |
| ISM-2045 | ISM-2045 requires organisations to ensure that maintaining backwards compatibility in applications does not weaken existing security meas... | |
| ISM-2059 | ISM-2059 requires organisations to restrict file types and conduct malware scanning | |
| extension Depends on (2) expand_less | ||
| ISM-1924 | ISM-1924 requires generative AI solutions to evaluate user prompts and mitigate adversarial inputs intended to elicit unintended behaviou... | |
| ISM-2067 | ISM-2067 requires web applications that support Single Sign-On (SSO) to equally support Single Logout (SLO) to ensure that a user’s logou... | |
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.