ISO 27001 Annex A 8.26 Defining security requirements for applications
What it says
Information security requirements shall be identified, specified and approved when developing or acquiring applications.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishEnsure security needs are clear and approved when creating or buying applications.
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.
Free. Save your status, tasks and notes.
Why it matters
Undefined application security requirements can cause insecure design, data breaches, compliance failures, costly rework, and loss of customer trust.
How to implement
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.
Keep it running
Define, document and approve application security requirements (privacy, authn/authz, logging, encryption) during SDLC and procurement, and trace them to tests and sign-off.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
The documented risk assessment related to the application.
Look at
Whether it comprehensively covers all relevant security threats and vulnerabilities.
Good evidence
A detailed and thorough assessment that aligns with ISO 27002:2022 guidance.
- Check 2 of 5What an auditor asks for
Ask for
The documented security requirements specification for the application.
Look at
Whether it includes necessary security features such as authentication and data protection mechanisms.
Good evidence
A well-structured document that addresses all key areas mentioned in ISO 27002:2022.
- Check 3 of 5What an auditor asks for
Ask for
Records of the approvals process for security requirements.
Look at
Whether the approvals are completed by authorised personnel. GOOD is when there is a traceable record of approvals by relevant stakeholders, indicating a robust review process.
- Check 4 of 5What an auditor asks for
Ask for
Procurement documentation that includes security evaluations of vendors.
Look at
How the documentation ensures vendors are vetted against security standards. GOOD procurement documents show thorough vendor evaluations against ASD Essential Eight.
- Check 5 of 5What an auditor asks for
Ask for
Records of compliance checks with Australian regulations like OAIC guidelines.
Look at
The alignment between documentation and compliance requirements. GOOD is when all necessary compliance requirements are documented and met, demonstrating adherence to local laws.
Mappings
Closest match in ASD Information Security Manual: ISM-0971, Use OWASP standards in web application development, which this control covers in full and more.
ISO/IEC 42001: 1 mapping
This control partially overlaps A.6.2.2.
Annex A 6.2.2's requirement to document AI system specifications overlaps with Annex A 8.26's focus on specifying and approving security requirements during application development.
ASD Information Security Manual: 23 mappings
This control is broader than ISM-0971.
Annex A 8.26 requires organisations to identify, specify and approve security requirements for applications during development or acquisition. ISM-0971 supports this by requiring use of the OWASP Application Security Verification Standard, which provides a concrete baseline and structure for defining and assessing web application security requirements. ISM-0971 is limited to web applications and a particular standard, while Annex A 8.26 is technology-agnostic and includes procurement as well as development.
This control is broader than ISM-1424.
ISM-1424 requires web server software to implement specific web security response headers (e.g. Content-Security-Policy, HSTS and X-Frame-Options) to protect web applications. Annex A 8.26 requires security requirements for applications to be identified, specified and approved, which would include requirements for browser-facing controls such as security headers for web applications. ISM-1424 is a concrete, technical subset of the broader application security requirements definition activity in Annex A 8.26.
This control is broader than ISM-1552.
ISM-1552 requires all web application content to be delivered exclusively using HTTPS to protect confidentiality and integrity in transit. Annex A 8.26 requires identifying and approving application security requirements during development or acquisition, which would commonly include a requirement for HTTPS-only delivery. ISM-1552 is a single concrete requirement, whereas Annex A 8.26 is broader and covers the full process of defining and approving multiple security requirements for applications.
This control is broader than ISM-1850.
ISM-1850 requires the OWASP Top 10 risks to be mitigated as part of web application development. ISO/IEC 27001:2022 Annex A 8.26 requires identifying, specifying and approving information security requirements when developing or acquiring applications, which would typically include requirements to mitigate OWASP Top 10 for web applications. Annex A 8.26 is broader because it addresses security requirements for all applications and acquisition scenarios, not just OWASP Top 10 or web-specific risks.
This control is broader than ISM-1851.
ISM-1851 requires web API developers to mitigate the OWASP API Security Top 10 risks. Annex A 8.26 requires identifying and approving information security requirements when developing or acquiring applications, which would include specifying API security requirements (e.g. authentication, authorisation, rate limiting, logging). ISM-1851 is a specific set of API risk requirements, whereas Annex A 8.26 is a broader requirements engineering control spanning all application types and acquisition.
This control is broader than ISM-1917.
ISM-1917's focus on supporting specific PQC and strong algorithms by 2030 through procurement and development can be captured within ISO/IEC 27001:2022 Annex A 8.26, which mandates defining security requirements for new applications. Annex A 8.26 is broad, addressing all security requirements, whereas ISM-1917 is a specific cryptography mandate.
This control is broader than ISM-2046.
ISM-2046 demands that impersonation features do not result in sensitive data being logged, with appropriate permissions set on the logs. Annex A 8.26 is broader, requiring security requirements to be identified when developing or acquiring applications, potentially including log redaction and access restrictions for impersonation functions. ISM-2046 represents a specific application requirement under the broader scope of Annex A 8.26.
This control is broader than ISM-2059.
ISM-2059 requires organisations to restrict file types and conduct malware scanning. Annex A 8.26 supports this by necessitating the identification of security requirements, which include those related to file uploads. ISM-2059 is a concrete control, while Annex A 8.26 sets a foundation for these requirements.
This control is broader than ISM-2063.
ISM-2063 requires web applications to set session cookies with HttpOnly, Secure and SameSite flags by default where supported. Annex A 8.26 requires application security requirements to be identified, specified and approved during development or acquisition, which would include specifying secure session and cookie handling requirements. ISM-2063 is a specific, technical requirement, while Annex A 8.26 is broader and lifecycle-focused (requirements definition and approval).
This control is broader than ISM-2064.
ISM-2064 specifies a concrete security requirement for web sessions: cookies must only carry digitally signed opaque bearer tokens. Annex A 8.26 requires organisations to identify, specify and approve application security requirements, which is the governance mechanism by which a requirement like ISM-2064 would be captured for a web application. ISM-2064 is an implementation-level requirement, whereas Annex A 8.26 covers the broader requirements-definition process across applications.
This control is broader than ISM-2065.
ISM-2065 requires web applications using opaque bearer session cookies (not digitally signed) to generate non-sequential random session identifiers with at least 128 bits of entropy (preferably 256 bits) to resist guessing/brute force. Annex A 8.26 requires that application security requirements are identified, specified and approved during development or acquisition, which is the point in the SDLC where a concrete requirement like "session identifiers must have ≥128 bits entropy and be generated using a CSPRNG" is documented, approved, and made testable/traceable. In practice, Annex A 8.26 provides the requirements governance mechanism and assurance hook (requirements and acceptance criteria) through which the specific entropy control in ISM-2065 is mandated and verified, but it does not itself prescribe entropy values or session token design details.
- ISM-2113Configuring AI applications to require human approval before high-impact actionsBroader than
This control is broader than ISM-2113.
ISM-2113 requires AI applications to be configured so that a human must approve sensitive or high-impact actions before execution. This relates to Annex A 8.26 because making "human approval before high-impact actions" a mandatory control is an application security requirement that should be identified, specified and approved during application development or acquisition. Annex A 8.26 is broader because it covers the full set of security requirements for applications, whereas ISM-2113 is a specific requirement focused on human-in-the-loop authorisation for consequential AI actions.
- ISM-1634System owners select and tailor controls in consultation with authorising officerPartially overlaps
This control partially overlaps ISM-1634.
ISM-1634 requires system owners, in consultation with the authorising officer, to select and tailor security controls for each system to meet security and resilience objectives. Selecting and tailoring controls is effectively the identification and approval of security requirements that Annex A 8.26 requires when developing or acquiring applications. ISM-1634 applies to every system throughout its life, while Annex A 8.26 focuses on applications at the development or acquisition stage.
This control partially overlaps ISM-1739.
ISM-1739 requires the security architecture for a system to be approved before the system is developed. ISO/IEC 27001:2022 Annex A 8.26 requires security requirements to be identified, specified, and approved when developing or acquiring applications, which is typically a key input to the security architecture that ISM-1739 seeks to have approved. Annex A 8.26 is broader as it covers application requirements approval (including acquisition), whereas ISM-1739 is an architecture approval gate for the system prior to development.
This control partially overlaps ISM-2033.
Annex A 8.26 requires information security requirements to be identified, specified and approved when developing or acquiring applications. ISM-2033 directly relates by requiring software security requirements to be documented, stored securely and maintained across the SDLC, which is a key mechanism for specifying and controlling those requirements. ISM-2033 emphasises documentation, secure storage and ongoing maintenance, while Annex A 8.26 additionally stresses up-front identification and formal approval, including for acquisition scenarios.
This control partially overlaps ISM-2110.
ISM-2110 requires user applications to be hardened using ASD and vendor hardening guidance, including resolving conflicts by choosing the most restrictive configuration. ISO/IEC 27001:2022 Annex A 8.26 requires security requirements for applications to be identified, specified and approved when developing or acquiring applications, which can include hardening and secure configuration baselines. The overlap is around defining and applying security requirements for applications, but ISM-2110 is operational hardening guidance-focused, while Annex A 8.26 is broader across the application lifecycle (development/acquisition requirements) and governance/approval.
This control supports ISM-1568.
ISM-1568 requires organisations to procure applications and technology from suppliers that demonstrate a commitment to secure products and services. Annex A 8.26 supports this by requiring security requirements to be identified, specified and approved when acquiring (or developing) applications, giving concrete criteria to assess suppliers and products during procurement. ISM-1568 is supplier-assurance focused, while Annex A 8.26 is requirements-definition focused and can be applied regardless of supplier maturity.
This control supports ISM-1849.
ISM-1849 requires the use of OWASP Top 10 Proactive Controls as a practical security baseline during web application development. Annex A 8.26 requires information security requirements to be identified, specified, and approved for applications, and OWASP controls can be used as a source of explicit non-functional security requirements (e.g. access control, data protection, logging). ISM-1849 is one prescriptive set of requirements, whereas Annex A 8.26 is broader and covers the full requirements lifecycle and approval process.
This control supports 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 threat environment. ISO/IEC 27001:2022 Annex A 8.26 requires security requirements for applications to be identified, specified and approved, and ongoing threat model review helps validate that requirements remain sufficient and drives updates when new threats or design changes emerge. The ISO control is centred on requirements definition/approval, while ISM-2039 is centred on continuous threat-driven validation and update during build and change.
- ISM-2045Keep security measures and features intact when supporting application backwards compatibilitySupports
This control supports ISM-2045.
ISM-2045 requires organisations to ensure that maintaining backwards compatibility in applications does not weaken existing security measures or features. ISO/IEC 27001:2022 Annex A 8.26 relates by requiring security requirements to be identified and approved during application development or acquisition, which is where backwards compatibility requirements and constraints should be captured and assessed. Annex A 8.26 is broader and more process-focused across the full set of application security requirements, whereas ISM-2045 is a specific safeguard against security regression introduced by compatibility decisions.
This control depends on ISM-1238.
ISM-1238 requires organisations to apply threat modelling in the SDLC to identify potential risks early in development. Annex A 8.26 requires identifying, specifying and approving information security requirements when developing or acquiring applications, and threat modelling is a common mechanism to discover and justify those requirements (e.g., authentication strength, input validation, logging). The difference is that Annex A 8.26 is about requirements governance and approval, while ISM-1238 is the analysis technique that feeds requirements.
This control depends on ISM-1924.
ISM-1924 requires generative AI solutions to evaluate user prompts and mitigate adversarial inputs intended to elicit unintended behaviour or sensitive/harmful content. Annex A 8.26 is a prerequisite because defining and approving security requirements for applications is where prompt-injection resistance and safety requirements should be specified for an AI application. Annex A 8.26 applies to all application acquisitions/development, whereas ISM-1924 is one concrete requirement that should be captured within those application security requirements.
This control depends on 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 logout terminates sessions across connected services. Annex A 8.26 requires information security requirements to be identified, specified, and approved when developing or acquiring applications. This is the governance mechanism needed to ensure SLO is explicitly captured as a non-functional security requirement in SSO application designs/procurements. ISM-2067 states the specific technical outcome (federated/coordinated logout), while Annex A 8.26 ensures the requirement is defined early enough to be implemented and tested.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.
Get help with this control
ISO 27001 training
Mindset Cyber runs PECB-accredited ISO/IEC 27001 training that maps directly to the controls in this library.