ISO 27001 Annex A 8.26 – Application Security Requirements focuses on identifying and defining information security requirements when developing, acquiring, or changing applications.
The objective is to ensure that security requirements are considered before and during application development or acquisition, rather than discovering security gaps after the application has already been deployed.
For startups and SaaS companies, this is particularly important because applications often process customer information, business data, credentials, financial information, or other sensitive information.
What is ISO 27001 Annex A 8.26?
Annex A 8.26 requires organizations to identify, specify, and approve information security requirements for applications.
These requirements should be considered when:
- Developing a new application
- Purchasing software
- Implementing a SaaS application
- Modifying an existing application
- Integrating a new API
- Adding a new feature
- Changing application architecture
- Introducing a new technology
- Replacing an existing application
In simple terms:
Before building or buying an application, determine what security the application needs.
Simple Explanation
Consider a company developing a customer portal.
The product team may define requirements such as:
- Users must be able to log in.
- Customers can view their information.
- Administrators can manage accounts.
- Users can upload documents.
- The application connects to an external API.
These are functional requirements.
A.8.26 asks the organization to also consider security requirements such as:
- How will users authenticate?
- What information can each user access?
- How will administrator access be protected?
- How will sensitive information be encrypted?
- How will security events be logged?
- How will sessions be managed?
- How will APIs be authenticated?
- What happens after repeated failed login attempts?
- How will vulnerabilities be identified and remediated?
Therefore:
Functional Requirements + Security Requirements = Complete Application Requirements
Why Are Application Security Requirements Important?
Applications are often directly exposed to customers, employees, partners, APIs, or the Internet.
Security weaknesses can result in:
- Unauthorized access
- Data leakage
- Account takeover
- Privilege escalation
- Fraud
- Malware
- Information disclosure
- API abuse
- Business disruption
- Regulatory issues
- Customer security concerns
Security requirements help prevent these issues from being considered only after development is complete.
What Does A.8.26 Require?
The organization should determine appropriate security requirements for applications based on factors such as:
- Information being processed
- Business purpose
- Application risk
- User types
- Regulatory requirements
- Contractual requirements
- Threat environment
- Integration requirements
- Authentication requirements
- Availability requirements
- Confidentiality requirements
- Integrity requirements
The requirements should be documented appropriately and communicated to the people responsible for developing, acquiring, configuring, or implementing the application.
Activities Required to Implement A.8.26
1. Identify Applications
Maintain an inventory of important applications.
For example:
| Application | Purpose | Owner | Data Type | Criticality |
|---|---|---|---|---|
| Customer Portal | Customer services | Product | Customer data | High |
| HR System | Employee management | HR | Employee data | High |
| CRM | Sales management | Sales | Business data | Medium |
| Internal Wiki | Knowledge management | IT | Internal information | Low |
The inventory helps determine which applications require more detailed security requirements.
2. Classify the Information
Security requirements should be based partly on the information handled by the application.
For example:
| Information | Example |
|---|---|
| Public | Marketing information |
| Internal | Internal procedures |
| Confidential | Business information |
| Sensitive | Customer/employee information |
| Highly sensitive | Financial or regulated information |
An application processing sensitive customer information will generally require stronger security requirements than an application containing only public information.
3. Identify Application Users
Determine who will use the application.
Users may include:
- Employees
- Customers
- Administrators
- Contractors
- Partners
- Vendors
- Developers
- API clients
- Service accounts
Different users may require different security controls.
For example:
Customer → Customer data
Support employee → Assigned customer information
Administrator → Administrative functions
API service → Limited machine-to-machine access
4. Define Authentication Requirements
Determine how users and systems will authenticate.
Requirements may include:
- Strong passwords
- MFA
- SSO
- Identity provider integration
- API authentication
- Service accounts
- Certificate-based authentication
- Session management
- Account lockout/rate limiting
- Privileged access controls
The appropriate method should depend on application risk.
5. Define Authorization Requirements
Authentication answers:
Who are you?
Authorization answers:
What are you allowed to access?
Application security requirements should define appropriate authorization.
Examples:
- Customer can access only their own records.
- Employee can access information required for their role.
- Administrator can perform privileged functions.
- Support staff cannot modify financial information.
- API clients can access only approved endpoints.
This is particularly important for multi-tenant SaaS applications.
6. Define Data Protection Requirements
Determine how information should be protected.
Requirements may include:
- Encryption in transit
- Encryption at rest
- Data masking
- Secure storage
- Data retention
- Secure deletion
- Backup protection
- Data loss prevention
- Access restrictions
For sensitive information, requirements should clearly specify the expected protection.
7. Define Logging and Monitoring Requirements
Applications may need to generate security-relevant logs.
Examples:
- Login attempts
- Failed authentication
- Privilege changes
- Administrative actions
- Sensitive data access
- Configuration changes
- API activity
- Security events
Requirements should identify what needs to be logged and how logs will be protected and monitored.
This connects closely with A.8.15 – Logging and A.8.16 – Monitoring activities.
8. Define Availability Requirements
Security is not limited to confidentiality.
Application requirements may also address:
- Availability
- Backup
- Recovery
- Disaster recovery
- Redundancy
- Capacity
- Business continuity
- Recovery objectives
For example, a critical payment application may require significantly stronger availability and recovery requirements than an internal knowledge portal.
9. Define Privacy and Regulatory Requirements
Applications may process information subject to:
- GDPR
- India’s DPDP Act
- HIPAA
- PCI DSS
- RBI requirements
- Industry-specific requirements
- Customer contractual requirements
The applicable requirements should be identified before development or acquisition.
For example, an application processing payment card information may require specific security controls beyond a normal internal application.
10. Define API Security Requirements
Modern applications frequently depend on APIs.
API security requirements may include:
- Authentication
- Authorization
- TLS
- Rate limiting
- Input validation
- API key management
- Token management
- Logging
- Monitoring
- Schema validation
- Error handling
For external APIs, the organization should also consider the security requirements of the third-party provider.
11. Define Security Requirements for Third-Party Applications
A.8.26 also becomes important when an organization buys or subscribes to software rather than developing it internally.
Before implementing a significant application, the organization may assess:
- Authentication capabilities
- MFA
- Encryption
- Access controls
- Logging
- Data location
- Backup
- Incident management
- Vulnerability management
- Security certifications
- Privacy requirements
- Integration security
- Data deletion capabilities
Evidence may include:
- SOC 2 report
- ISO 27001 certificate
- Security questionnaire
- Penetration testing summary
- Vendor security documentation
- Contractual security clauses
Example: SaaS Startup
Imagine a SaaS startup developing a customer management platform.
The application processes:
- Customer names
- Email addresses
- Account information
- Business documents
- User credentials
Before development begins, the company defines:
Authentication
- MFA for administrators
- Strong authentication for users
- Secure session management
Authorization
- Role-based access
- Tenant isolation
- Least privilege
Data Protection
- TLS for communication
- Encryption at rest
- Protected backups
Logging
- Login events
- Administrative activity
- Sensitive-data access
- Security events
API Security
- Authenticated APIs
- Authorization checks
- Rate limiting
- API monitoring
Vulnerability Management
- Dependency scanning
- SAST
- Security testing
- Vulnerability remediation
These requirements become part of the application’s development and acceptance criteria.
Application Security Requirements Template
A simple template can be used:
| Requirement Area | Security Requirement |
|---|---|
| Authentication | MFA for privileged users |
| Authorization | Role-based access |
| Data Protection | Encryption in transit and at rest |
| Passwords | Secure password storage |
| Sessions | Secure session management |
| Logging | Security events logged |
| Monitoring | Critical events monitored |
| API | Authentication and authorization |
| Availability | Defined recovery requirements |
| Backup | Protected and tested backups |
| Vulnerability | Security testing before release |
| Privacy | Applicable privacy requirements |
| Access | Least privilege |
| Third Party | Security assessment required |
Application Security Requirements Register
Organizations can maintain a register such as:
| Application | Owner | Data Classification | Security Requirements | Review Status |
|---|---|---|---|---|
| Customer Portal | CTO | Confidential | MFA, RBAC, encryption, logging | Approved |
| HR Platform | HR/IT | Sensitive | SSO, RBAC, encryption, audit logs | Approved |
| Mobile App | Product | Confidential | API security, authentication, secure storage | In Review |
When Should A.8.26 Be Triggered?
Application security requirements should be considered when:
- Developing a new application
- Purchasing new software
- Introducing SaaS
- Adding major functionality
- Changing architecture
- Integrating an API
- Processing new types of information
- Changing authentication mechanisms
- Introducing mobile applications
- Moving applications to the cloud
- Introducing AI functionality
- Changing regulatory requirements
- Receiving new customer security requirements
- Changing business processes
- Replacing an existing application
Startup-Focused Quick Summary
A startup does not need a huge application-security department to implement A.8.26.
A practical approach is:
Before Building or Buying → Identify Data → Identify Users → Identify Risks → Define Security Requirements → Approve → Build/Configure → Test → Deploy
At minimum, document requirements for:
- Authentication
- Authorization
- Data protection
- Logging
- API security
- Vulnerability management
- Availability
- Backup/recovery
- Privacy/regulatory requirements
Minimum Startup Implementation
For a small SaaS company, start with an Application Security Requirements Checklist covering:
1. Access
- Authentication
- MFA for privileged access
- Authorization
- Least privilege
2. Data
- Classification
- Encryption
- Retention
- Secure deletion
3. Application
- Secure coding
- Input validation
- Error handling
- Session security
4. API
- Authentication
- Authorization
- TLS
- Rate limiting
5. Monitoring
- Security logging
- Monitoring
- Alerting
6. Testing
- Vulnerability scanning
- SAST/DAST where appropriate
- Penetration testing based on risk
7. Business Continuity
- Backup
- Recovery
- Availability requirements
Simple Rule
Before you build or buy an application, define what security the application must provide.
A.8.25 vs A.8.26 vs A.8.27 vs A.8.28 vs A.8.29
These controls are closely related but address different parts of application security.
| Control | Primary Focus |
|---|---|
| A.8.25 | Secure development lifecycle |
| A.8.26 | Application security requirements |
| A.8.27 | Secure system architecture and engineering principles |
| A.8.28 | Secure coding |
| A.8.29 | Security testing in development and acceptance |
A simple way to remember them:
A.8.25 → How security is managed throughout development
A.8.26 → What security the application needs
A.8.27 → How the system should be securely designed
A.8.28 → How developers should write secure code
A.8.29 → How security should be tested
Audit Evidence for A.8.26
An auditor may review:
- Application inventory
- Application security requirements
- Business requirements
- Security requirements
- Architecture documentation
- Data classification
- Risk assessments
- Threat models
- API security requirements
- Authentication requirements
- Authorization models
- Privacy requirements
- Regulatory requirements
- Vendor security assessments
- Security questionnaires
- Application testing reports
- Security acceptance criteria
- Release approval records
The evidence should demonstrate that application security requirements were identified and addressed, not merely documented as a policy statement.
ISO 27001 A.8.26 Audit Checklist
| Audit Question | Evidence |
|---|---|
| Are application security requirements defined? | Security requirements |
| Are requirements identified before development/acquisition? | Project records |
| Are information security risks considered? | Risk assessment |
| Are data protection requirements defined? | Requirements/documentation |
| Are authentication requirements defined? | Application design |
| Are authorization requirements defined? | RBAC/access design |
| Are logging requirements defined? | Logging requirements |
| Are API security requirements defined? | API specification |
| Are availability requirements considered? | BCP/availability requirements |
| Are regulatory requirements identified? | Compliance assessment |
| Are third-party applications assessed? | Vendor assessment |
| Are security requirements tested? | Test results |
| Are security requirements included in acceptance criteria? | UAT/release records |
| Are requirements reviewed when applications change? | Change/project records |
Common Mistakes
1. Starting Development Without Security Requirements
Developers may build functionality first and attempt to add security later.
Better approach: define important security requirements before development begins.
2. Focusing Only on Authentication
Having a login page does not make an application secure.
Security requirements should also consider:
- Authorization
- Data protection
- Logging
- APIs
- Sessions
- Vulnerabilities
- Availability
- Privacy
3. Ignoring Multi-Tenant Security
For SaaS companies, tenant isolation is critical.
A user from Company A should not be able to access Company B’s information.
Application requirements should explicitly address tenant isolation where applicable.
4. Ignoring Third-Party Applications
Security requirements also apply when software is purchased or consumed as SaaS.
Better approach: define minimum security requirements for important third-party applications.
5. Requirements Are Not Tested
A company may document:
“The application must use MFA.”
But there may be no evidence that MFA actually works.
Better approach:
Requirement → Implementation → Testing → Evidence
6. One Checklist for Every Application
Not every application has the same risk.
A public SaaS platform processing sensitive information may require significantly stronger security requirements than an internal low-risk tool.
Better approach: use risk-based requirements.
Practical Implementation Model
A.8.26 can be implemented using:
Identify Application
↓
Identify Information
↓
Identify Users
↓
Assess Risk
↓
Identify Regulatory/Contractual Requirements
↓
Define Security Requirements
↓
Approve Requirements
↓
Build / Buy / Configure
↓
Test Requirements
↓
Accept & Deploy
↓
Review When Application Changes
Policy vs Process vs Requirement vs Evidence
| Layer | Example |
|---|---|
| Policy | Application Security Policy |
| Process | Application Security Requirements Process |
| Requirement | MFA required for administrators |
| Technical Control | MFA configuration |
| Testing | MFA security test |
| Evidence | Test result / configuration screenshot |
This is an important distinction during an ISO 27001 audit.
A policy saying “applications must be secure” is not sufficient by itself.
The organization should be able to demonstrate how security requirements are identified, implemented, and verified.
Useful Resources
Draft Application Security Policy
[Insert Draft Application Security Policy Link]
Application Security Requirements Template
[Insert Application Security Requirements Template Link]
Application Security Checklist
[Insert Application Security Checklist Link]
SaaS Security Requirements Checklist
[Insert SaaS Security Requirements Checklist Link]
API Security Checklist
[Insert API Security Checklist Link]
Vendor Application Security Assessment
[Insert Vendor Security Assessment Link]
Related ISO 27001 Controls
A.8.26 should be considered together with:
- A.5.8 – Information security in project management
- A.5.15 – Access control
- A.5.23 – Information security for use of cloud services
- A.5.31 – Legal, statutory, regulatory and contractual requirements
- A.8.2 – Privileged access rights
- A.8.3 – Information access restriction
- A.8.4 – Access to source code
- A.8.8 – Management of technical vulnerabilities
- A.8.9 – Configuration management
- A.8.15 – Logging
- A.8.16 – Monitoring activities
- A.8.24 – Use of cryptography
- A.8.25 – Secure development life cycle
- A.8.27 – Secure system architecture and engineering principles
- A.8.28 – Secure coding
- A.8.29 – Security testing in development and acceptance
- A.8.31 – Separation of development, test and production environments
- A.8.32 – Change management
Final Takeaway
ISO 27001 Annex A 8.26 ensures that application security is defined as a requirement before and during application development or acquisition.
For startups and SaaS companies, a simple approach is:
Understand the application → Understand the data → Understand the risks → Define security requirements → Build or configure → Test → Approve → Monitor → Review
The key principle is simple:
Don’t build the application first and ask what security it needs later. Define the security requirements before the application is built, purchased, or significantly changed.