ISO 27001 A.8.26: Specify application security before acceptance
Application security requirements define what protection an application needs before it is developed or acquired. ISO 27001 Annex A.8.26 concerns identifying, specifying and approving those requirements. A statement that the application must be secure is too broad to guide a supplier, developer or acceptance decision.
What A.8.26 requires in practice
Annex A control A.8.26 expects information security requirements to be identified, specified and approved whenever applications are developed or acquired. Three actions are named: identify, specify and approve. Identifying means understanding what the application handles and who may do what. Specifying means writing the expectations clearly enough to guide design, procurement and testing. Approving means someone accountable accepts them before work proceeds.
The control covers both bought and built applications, which matters because many organisations adopt software through procurement rather than coding. For acquired products the requirements shape supplier selection and acceptance; for built products they steer design and testing.
The outputs are a documented set of requirements for each relevant application, approval by an accountable owner, and traceability into design, purchasing and acceptance decisions. Applicability follows risk treatment and the Statement of Applicability.
Understand the information and the permitted actions
Identify the information the application will receive, store, process and disclose. Determine who should perform which actions and what level of confidence is needed in their identity. Consider both ordinary users and administrators, including external parties and system-to-system interactions where relevant.
Translate that understanding into specific expectations. For example, a role may be allowed to view an assigned case while being unable to export all customer records. The requirement should describe the intended behaviour clearly enough to influence design and testing. Link these decisions with information access restriction.
Cover the complete transaction and information lifecycle
Look beyond the main screen. Inputs, outputs, interfaces, error messages and free-text fields can all affect protection. A workflow may need validation, approval limits or evidence of a completed transaction. The appropriate requirements depend on the purpose and consequences of incorrect or unauthorised processing.
Consider retention, deletion, recovery and relevant logging. An application can meet the immediate functional requirement while leaving important information difficult to recover or remove later. Identify applicable legal, contractual and privacy obligations in the organisation's context; do not treat a generic vendor statement as a complete evaluation of those needs.
Why application security requirements matter to the business
An application that is accepted without agreed security expectations is judged on appearance and price, and problems appear later in production. Clear requirements help suppliers quote accurately, help developers build the right thing the first time and give testers something to check against. They also stop disputes, because everyone can see what was asked for. For customers whose data passes through the application, defined requirements are evidence that protection was planned. At audit, requirements that trace through to acceptance show that procurement and development are part of the ISMS, not outside it.
How to implement A.8.26
The goal is a short, specific set of requirements per application, approved before commitment. Follow this path. Keep the requirements short enough to be read by the people who will use them, and specific enough to be tested. A single page per application is often more useful than a long catalogue that nobody opens.
- List the information the application will receive, store, process and disclose, and its sensitivity.
- Identify the user groups, administrators, external parties and system-to-system links involved.
- State who may perform which actions, and how confident the application must be in their identity.
- Express each expectation in verifiable terms, for example a role that can view assigned cases but cannot export every record.
- Include requirements for logging, handling of errors and protection of information in transit and storage where relevant.
- For acquired software, include the requirements in the selection criteria and agreement.
- Obtain approval from an accountable owner before development or purchase proceeds.
- Carry the requirements forward into design reviews and acceptance testing, and update them when scope changes.
Illustrative construction example: buying a project document platform
A fictional construction company evaluates a platform for drawings and project correspondence. The buying team focuses on storage capacity and collaboration features, but subcontractors should see only the projects and information assigned to them. General password protection does not establish that boundary.
The company specifies representative access relationships, external-sharing conditions and evidence needed for relevant actions. It asks the supplier to demonstrate those scenarios using safe sample information and records any limitations before purchase. The decision now reflects the intended project workflow rather than an assumption that a broadly secure platform automatically fits the company's access model.
Illustrative software example: preventing duplicate business actions
A hypothetical software team develops a workflow that submits important customer instructions. The team initially tests only whether one submission succeeds. The business owner identifies that repeated or interrupted requests could create duplicate processing, with consequences beyond the application's visual interface.
The team defines the required handling of repeated submissions and the evidence needed to establish the final state. It designs and tests suitable behaviour before acceptance. This example concerns a business-specific integrity requirement; it does not prescribe one coding technique or claim that every application needs an identical transaction design.
Make acceptance evidence traceable
Useful evidence links each important requirement with its agreed consulting and documentation work and verification. A requirements register or work-item system can help, but no particular format is prescribed. The record should let a reviewer understand whether an expectation was met, changed or left subject to an authorised residual-risk decision.
Use security testing to check representative permitted and prohibited behaviour. A test report that covers only general scanning may leave business access or transaction requirements unanswered. Preserve the context of the test, including the version and configuration assessed.
Common failures include copying a generic checklist without considering the application, approving requirements after release and accepting a feature demonstration as proof of every configured environment. Use operational control to connect acceptance with the actual service. Requirements should improve a concrete buying or development decision, rather than create paperwork detached from the application.
Common nonconformities with A.8.26
Typical findings concern requirements that are missing, vague or ignored. These arise most often with purchased applications, because buying is treated as an operational decision rather than a security one, so an auditor asks to see requirements for a recent acquisition.
- A general statement that the application must be secure, with nothing specific to check.
- Purchased software adopted with no security requirements stated at selection.
- Requirements written but never approved by an accountable owner.
- Requirements not reflected in testing, so acceptance cannot show they were met.
- No update when scope or user groups changed.
Frequently asked questions
Does A.8.26 apply when we buy software rather than build it?
Yes. Acquired applications still need identified and approved security requirements, with appropriate evaluation of supplier capability and customer configuration.
Is a supplier's security questionnaire enough?
It can contribute information, but verify the requirements important to your use. General answers may not demonstrate the actual access, transaction or data-handling behaviour needed.
Can security requirements change during development?
Yes. Control material changes, approve the revised expectation and update implementation and verification accordingly. Avoid leaving important changes as undocumented assumptions.
Make application decisions with clearer acceptance criteria
Discuss application security requirements with Sterling, including scoped consulting, documentation, employee learning and agreed Effivity ISO & GRC automation software. The wider ISO 27001 programme can include authorised vulnerability scanning and findings review, with continued support through defined preparation; certification remains independent. Enrol in ISO/IEC 27002 Information Security Controls to connect application requirements with the technological controls.