Document application security requirements by writing, for each project you build or buy, a short list of security needs before work starts. Record it in a requirements spec or ticket, tie it to a risk, and keep it where an auditor can find it. ISO 27001 control 8.26 asks for exactly that.
What control 8.26 covers
The control applies to software you develop and software you acquire. The risk it targets is plain: if requirements are not set up front, security gets missed during purchasing or building.
A Security Requirements Specification is recommended but not mandatory. Most companies do not need a separate policy for this control. The method for finding requirements can sit in the secure development policy.
Build versus buy
| Situation | What to record | Typical home |
|---|---|---|
| You build an application | Security requirements per feature or project | Spec or epic ticket |
| You buy or subscribe | Security needs used to choose the product | Procurement checklist |
| You extend an existing system | Requirements for the change | Change ticket |
Where requirements come from
Sources worth checking when you write the list:
- Laws and contracts that apply to the data you handle
- Customer commitments made in security reviews
- Results of your risk assessment
- Lessons from past incidents or findings
- The sensitivity of the data the application will touch
Keep each requirement testable. "Encrypt personal data in transit" can be checked. "Be secure" cannot.
What an auditor checks
Auditors look for evidence that security requirements were considered in acquired and developed software. If they cannot find it, they treat it as a nonconformity.
A good pack has three items. First, the method, in the secure development policy. Second, two or three recent project specs showing real requirements. Third, a link from at least one requirement to a test or a review, so the loop closes.
Try it yourself
Open the demo and see how one control maps to evidence across frameworks. Notice how a single requirement can point at several framework controls.
Click through it at your own pace, or open it full screen.
Where tooling helps
Safeguard offers compliance and evidence automation and policies that check requirements in the pipeline. The requirements themselves come from your team. Try the free scan at gold.safeguard.sh/scan.
Quick check
Does 8.26 apply to purchased software?
Yes. It covers software you develop and software you acquire, so buying decisions should reference security requirements.
Do I need a separate policy for application security requirements?
Usually not. The method can live in your secure development policy, with the requirements recorded per project.
Sources
Last reviewed: 19 October 2026.
