---
title: "ISO 27001 Annex A 8.26: define, implement and validate app security"
canonical: https://www.grcmana.io/vault/iso-27001/annex-a-8-26-application-security-requirements
published: 2023-08-02
updated: 2026-10-07
author: "Harry West"
framework: "ISO 27001"
control: "A.8.26 Application security requirements"
journeyStage: implementation
---

# ISO 27001 Annex A 8.26: define, implement and validate app security

## Key takeaways

Annex A 8.26 asks you to decide, write down and approve application security requirements before you build or buy software. For built software that means testable acceptance criteria in the backlog. For bought software it means vendor vetting before the contract is signed.

- **Purpose** — Annex A 8.26 asks you to work out, write down and approve an application's security requirements before you build or buy it, basing them on a risk assessment.
- **Scope** — The control widens the older public-network scope to every application, including commercial SaaS you acquire and internal services, so vendor vetting before signing becomes part of the requirement.
- **Audit sampling** — Auditors sample one recent build and one recent purchase, tracing requirements, approval and verification end to end, and checking that the vendor assessment predates the contract.
- **Automation** — Ticket templates, pipeline verification mapped to criteria, a procurement gate and recorded sign-off turn requirements evidence into a by-product of shipping software and buying tools.

The due-diligence questionnaire asks how you decide what security an application needs before it is built or bought. You point to a Jira board and a procurement spreadsheet, and neither mentions security. This guide to ISO 27001 Annex A 8.26 shows how to define, implement and validate application security requirements for software you build and software you buy.

It is written for technical founders, CISOs, heads of engineering and compliance managers at regulated UK firms and B2B SaaS companies. You get the requirements baseline, the vendor check, the audit sampling pattern and the automation that produces the evidence as a by-product.

## What are the ISO 27001:2022 Annex A 8.26 application security requirements?

ISO 27001:2022 Annex A 8.26 asks you to work out, write down and approve the security requirements for an application before you build or buy it. The requirements come from a risk assessment and cover what the application must do securely. Someone with authority signs them off. A.8.26 defines the requirements; A.8.25 governs how software is built.

Security expertise should shape them, but the control does not ask for a bespoke document per project. What matters is that the decision exists, in writing, before the build starts or the contract is signed.

A security property nobody wrote down is one you are hoping a developer or vendor guessed.

What the requirements cover depends on the application's job. Settle how strongly users must be identified, what data the application holds and at what classification, and who can reach which functions. Then add the legal and privacy duties that follow that data, and the classic attacks, such as injection, it must resist. The baseline checklist below turns this into a reusable list.

The control sits beside three neighbours. Its requirements feed the development rules of A.8.25 and lean on the cryptography choices of A.8.24. They enter projects through information security in project management (A.5.8). Auditors sample A.8.26 separately from A.8.25, so keep the requirements record distinct from your secure development policy.

## What changed from the 2013 public-network controls to A.8.26?

The 2013 edition split application security across 14.1.2, securing application services on public networks, and 14.1.3, protecting application services transactions. ISO 27001:2022 folds both into A.8.26. It widens the scope to every application, including SaaS you buy and internal services, not only systems on public networks.

The widening matters most for the acquisition half. Read narrowly, the 2013 pair could be met by hardening a public web front end. The SaaS tools holding client data never came into view. The old scope line was network location. The 2022 line is the application's job and the data it holds.

Internal services come in too. An internal API that never touches the public internet still handles data, enforces access and writes logs. Web applications, mobile apps, desktop software and APIs all need stated requirements, in proportion to their risk.

One concern from the old public-network controls survives intact: protecting data in transit. The [NCSC Cloud Security Principle 1: Data in transit protection](https://www.ncsc.gov.uk/collection/cloud/the-cloud-security-principles/principle-1-data-in-transit-protection) says user data crossing networks should be protected against tampering and eavesdropping. It names three measures: encryption, network protection and authentication. In practice, that means modern TLS on every external endpoint and authenticated endpoints at both ends of an integration. The old transaction concern also returns, as the payment layer covered below.

## How do you identify ISO 27001 Annex A application security requirements?

Build one baseline checklist from your risk assessment and reuse it on every project. It covers authentication and sessions, role-based access, encryption, input and output control, logging, error behaviour and data-classification fit. OWASP ASVS works as a reference catalogue. Tier it by risk so scrutiny stays proportionate.

The [OWASP Application Security Verification Standard (ASVS)](https://owasp.org/projects/asvs) gives you a basis for testing web application technical security controls. It also gives developers a list of requirements for secure development. Lift its wording rather than inventing your own. A page or two derived from your risk assessment is enough.

The baseline we recommend for a 50-person firm looks like this:

- **Authentication and sessions:** strong credentials, multi-factor authentication where the data justifies it, and sensible session expiry.
- **Role-based access:** least-privilege roles, with access checks enforced on the server rather than only in the interface.
- **Encryption:** TLS in transit and encryption at rest for sensitive data.
- **Input and output:** validation of everything that comes in and control over what goes out.
- **Logging:** security-relevant events captured, including audit logs on privilege changes.
- **Error behaviour:** failures that reveal nothing useful to an attacker.
- **Data-classification fit:** controls that match the classification of the data the application holds.
- **Privacy and legal duties:** UK GDPR and any other obligations that follow the data into each jurisdiction.

Risk tiering keeps the effort honest. Anything touching client data, money or personal data gets the full checklist plus a threat-modelling pass at design. Internal low-stakes tooling gets the short form.

Write the tiering down so proportionality is a decision rather than an accident. Auditors ask how you decide how much scrutiny an application gets, and a one-page tier table answers that question.

Two pitfalls are worth designing out. The first is the pasted generic template. When every project carries the same requirements regardless of what the application does, nobody reads them and reviewers check nothing. Tiering plus a short application-specific addendum fixes that.

The second is the free-text field. A comments box or notes field that nobody thought about quietly fills with personal data. The problem then surfaces as a GDPR issue rather than a security ticket. Add a baseline line for every free-text field covering what may be entered, who can read it and how long it is kept.

The expensive failures trace back to this stage. An application that stored card data in a public bucket is the classic example, and nobody rejected a requirement there. Nobody wrote one.

## What extra requirements do payment and transactional applications need?

Transactional and payment applications add a layer on top of the baseline. Each party must prove its identity to the other, and signatures and hashes keep records intact. A party cannot later deny a transaction, records are never duplicated or lost, and payment data sits away from anything publicly reachable.

Most of this lands on your cryptography choices. Hashes show whether a record has changed, and digital signatures add proof of who made it. Certificate-based mutual authentication proves identity in both directions. Make the algorithm and key-management decisions once, under A.8.24. Keep payment details well away from anything internet-facing, in a separate store behind an internal tier.

Ask these questions at design time:

- **Mutual identity:** how does each party prove who it is to the other?
- **Tamper-evidence:** what stops a record being silently altered?
- **Non-repudiation:** what evidence shows a party made the transaction?
- **Completeness:** what prevents duplicated or lost transaction records?
- **Data placement:** where is payment data stored relative to anything publicly reachable?

Payment features draw specific auditor questions about integrity and where data sits. Have the answers in the requirements record before the audit, not assembled during it.

## How do you vet SaaS and bought software before the contract is signed?

Run a vendor security check before you commit, scaled to what the tool will hold. Ask about SSO support, encryption claims, certifications held, data location and breach history. A note-taking app and a payroll system do not deserve the same depth, and the assessment must predate the contract.

Procurement moves fast. A tool adopted without security vetting becomes your compliance problem the day client data enters it. You cannot fix a vendor's design later. For many firms, SaaS tools are where client data actually ends up. That is the gap the 2022 wording closed.

Build the questionnaire around five checks:

- **SSO support:** can staff sign in through your identity provider, and can access be removed centrally?
- **Encryption claims:** how is data protected in transit and at rest?
- **Certifications held:** which independent attestations exist, and what do they cover?
- **Data location:** where is the data stored and processed?
- **Breach history:** what incidents has the vendor disclosed, and how were they handled?

Tie the depth to the data. A tool that will hold client records, personal data or money gets the full questionnaire and a named approver. A tool that holds nothing sensitive gets the short form.

Record the outcome, not just the answers. The assessment should end with a decision (approved, approved with conditions or rejected), a named approver and a date. That date is what the auditor compares with the contract.

The pitfall to avoid is lopsided coverage: a tidy requirements process for engineering while purchases walk in unvetted. A team with a secure backlog and an unreviewed SaaS estate has covered only half the control.

Put the trigger where the purchase starts. A questionnaire that first appears at contract stage arrives too late. Attach it to the purchase request, and brief whoever raises those requests on when it applies.

## How do you embed ISO 27001 application security into the ISMS and your backlog?

Put security acceptance criteria on the ticket or user story, such as hashed passwords, login rate limiting and audit logs on privilege changes. A named approver accepts the requirements before build. Criteria that reviewers actually check replace a requirements traceability matrix at this scale, and testing verifies the shipped result.

Requirements belong where the work happens. A ticket template with a security criteria field puts the requirement in front of the engineer at the moment of writing code. The [NCSC Secure Development Principles](https://www.ncsc.gov.uk/collection/developers-collection/principles/secure-development-is-everyones-concern) make the same point. They advise defining security requirements at the start of delivery and during it, because without them security practices are unlikely to take hold.

Typical acceptance criteria on a ticket read like this:

- Passwords are hashed with a modern algorithm.
- Login attempts are rate limited.
- Privilege changes write an entry to the audit log.
- Every endpoint enforces role checks on the server.

At this scale the approver can be a security lead or a fractional CISO. A ticket status or approval comment is enough of a record, as long as it predates the build.

Verification then confirms the shipped result through pipeline scans, penetration tests or acceptance checks. The testing itself sits under A.8.29, so link its evidence to the criterion rather than duplicating it.

Requirements that are stated but never verified are promises, not a control.

Fold the whole thing into the ISMS with three artefacts: the baseline checklist as a policy section, the risk tiering and the vendor questionnaire. Projects reach them through your project-management process, so no separate governance track is needed. A short briefing for engineers, architects and anyone who raises purchase requests means the checklist gets applied without security chasing every project.

Three pitfalls make the process decorative:

- **Written after shipping:** requirements drafted to satisfy the audit rather than shape the build, which the trail's timestamps give away.
- **Over-engineered paperwork:** a formal requirements-management tool and traceability matrix for a team of eight.
- **No named approver:** criteria exist, but nobody accepted them, so the sign-off record is missing.

At this scale, criteria on tickets plus a one-page checklist satisfy both auditors and enterprise security reviewers without any extra tooling.

## What will an auditor ask about ISO 27001 Annex A 8.26?

Auditors sample one recent build and one recent purchase and trace each end to end: requirements stated, approval recorded, verification performed. On the buy side they check the vendor assessment predates the contract. With no requirements process the finding grades major; a single skipped vetting or sign-off gap grades minor.

Expect these questions in the room:

- "Show me the security requirements for the last significant thing you built."
- "You adopted a new SaaS tool this year. What vetting happened before the contract?"
- "How do you decide how much security scrutiny an application gets?"
- "Who signs off that requirements are adequate, and where is the record?"
- "How do you verify the delivered application meets what was specified?"

Have this evidence ready:

- The baseline requirements checklist or policy section, with the risk tiering that scales it.
- Sampled tickets or user stories showing security acceptance criteria for a recent feature.
- A completed vendor questionnaire for a recent SaaS purchase, with the assessment outcome.
- Threat-modelling notes or design-review records for a higher-risk application.
- Sign-off records showing who approved and when, plus test evidence such as scan output or a penetration test report.

Grading follows certification-body practice. A missing process, with projects and purchases proceeding on assumption, grades major. A purchase that skipped vetting, criteria missing from one project or a sign-off gap grades minor. Several minors can add up to a major where the sample shows the process is decorative.

## How can you automate application security requirements with GRC engineering?

Requirements management automates well because the artefacts already live in tickets and pipelines. Four pieces do the work: a checklist as a ticket template, pipeline checks mapped to criteria, a procurement gate and sign-off as a recorded workflow state. Evidence then becomes a by-product of shipping and buying.

Each one works like this:

- **Checklist as ticket template.** New feature epics and purchase requests open with the security criteria fields attached. The requirement cannot be skipped silently, and coverage is queryable.
- **Verification wired to criteria.** Pipeline scans and test suites map to the stated requirements. The build record answers "was requirement X verified?" rather than memory.
- **Procurement gate.** A new-vendor request cannot reach contract stage without the security assessment attached.
- **Sign-off as workflow state.** Approval is a recorded step by a named role. The auditor gets a queryable log of who accepted what, and when.

Standing this up is modest work. The baseline checklist and vendor questionnaire take about a week. Embedding them into backlog habits and the procurement flow takes roughly a month of nudging. Do it alongside the A.8.25 work and before the next big build or purchase. Retrofit is exactly what the control exists to prevent.

This is the build that GRC engineering delivers: requirements as workflow rather than paperwork. When an enterprise buyer asks for evidence of your security requirements, you export a query instead of assembling a folder.

| Automation | Where it lives | Evidence it produces |
| --- | --- | --- |
| Ticket template | Issue tracker | Security criteria on every feature epic |
| Verification mapping | CI/CD pipeline | Scan and test results tied to each criterion |
| Procurement gate | Purchase workflow | Vendor assessment dated before the contract |
| Sign-off state | Workflow log | Named approver and timestamp |

## Frequently asked questions

### Does A.8.26 apply if we only buy SaaS and build nothing?

Yes, and your vendor vetting is how you meet it. Start with an inventory of every tool that holds client or personal data. Rank the tools by data sensitivity and run the questionnaire on the highest-risk ones first. Where a tool fails a check, record the residual risk and any compensating controls, because you cannot change the vendor's design.

### Who should own A.8.26 in a 50-person regulated firm?

Split it three ways. Security leadership, in-house or fractional, owns the checklist and the sign-off. Product and engineering own applying the criteria to tickets, and whoever raises purchase requests owns triggering the vendor check. Put all three duties on one person's plate and the control tends to stall.

### Does A.8.26 replace PCI DSS for payment applications?

No, the obligations stack. PCI DSS, the card industry's mandatory standard, governs the card data specifics. A.8.26 makes those obligations part of your stated requirements, so they are designed in rather than discovered at assessment. Add the PCI DSS requirements to the payment tier of your checklist.

### Does A.8.26 cover software an outsourced developer builds for us?

Yes. The requirements apply however the software is produced, so write them into the statement of work and make acceptance depend on meeting them. Directing and monitoring the developer's work is a separate control, A.8.30, so keep the two records apart.