How to Work Out What “Secure” Actually Means for Your Application
ISO 27001 Control 8.26 Application security requirements is about answering a very simple question before you build or buy anything:
“What does this application need to do to be secure – for our data, our users, and our regulators?”
Most security problems in applications come from one thing: nobody clearly defined the security requirements up front. Developers guessed. Vendors glossed over details. Security were asked to “sign it off” at the end.
This control expects you to treat security requirements as first-class requirements, right alongside functionality, performance, and usability – whether you’re developing software in-house, customising a SaaS platform, or buying off-the-shelf systems.
This guide walks through what ISO 27001 Control 8.26 is really asking for and how to define practical, risk-based application security requirements that developers and suppliers can actually work with.
What ISO 27001 Control 8.26 Actually Requires
In plain English, ISO 27001 Control 8.26 – Application security requirements expects you to:
- Identify and document security requirements for applications you develop, configure or procure.
- Base those requirements on risk, data classification, and legal/regulatory needs.
- Cover key areas like identity and access, data protection, input/output handling, logging, transaction security and privacy.
- Get those requirements approved and integrated into your development or procurement process.
- Make sure they are kept up-to-date as threats, regulations and functionality change.
In other words: don’t just say “the app must be secure”; specify how.
Step 1 – Start with Risk, Data and Context
Before jumping into technical detail, you need a clear picture of:
- What the application does
– Business processes it supports.
– Who uses it (internal, customers, partners, public). - What data it will handle
– Personal data? Payment details? Commercially sensitive information?
– Data classification (e.g. public, internal, confidential). - Where it lives and runs
– On-premises, cloud, hybrid, third-party hosted, mobile, browser.
– Internet-facing vs internal-only. - What could go wrong
– Data breach, fraud, service disruption, unauthorised changes, reputational damage.
– Any specific industry or regulatory expectations (e.g. PCI DSS for payments, sector regulators).
From an ISO 27001 Control 8.26 perspective, this is your risk-informed starting point for requirements. You’re not designing yet – you’re clarifying what needs protecting and why.
Step 2 – Define Identity and Access Requirements
Almost every application needs clear identity and access rules. Typical requirements include:
- Authentication
– Supported methods (e.g. username/password + MFA, SSO via your IdP, biometrics for mobile).
– Password policies if local accounts are used (length, complexity, lockout, reset). - Authorisation
– Role-based or attribute-based access control (who can see/do what).
– Least privilege by default – no “everyone is an admin” designs. - Session management
– Session timeouts and idle timeouts.
– Re-authentication for high-risk actions (e.g. changing contact details, approving payments). - Credential handling
– Secure storage (hashed and salted) for passwords if you manage them.
– No hard-coded credentials or shared generic admin accounts.
Write these as concrete requirements – the kind developers, integrators or vendors can build against and auditors can test later.
Step 3 – Define Data Protection and Privacy Requirements
Next, specify how the application must protect the data it handles.
Think in terms of:
- Data classification and handling
– Which data elements are confidential or sensitive.
– Where they can be stored, and for how long. - Encryption
– Data at rest (e.g. database fields, files, backups).
– Data in transit (TLS for web/API calls, secure protocols for integration). - Data minimisation and privacy by design
– Only collect the data you actually need.
– Support for data subject rights where relevant (access, deletion, rectification). - Masking and tokenisation
– Masking sensitive fields in logs, screens, and reports.
– Use of tokenisation where raw data isn’t needed. - Regulatory obligations
– Any explicit requirements under GDPR, HIPAA, PCI DSS, or sector-specific rules.
These become part of your application security requirements, not an afterthought during go-live discussions.
Step 4 – Define Requirements for Input, Output and Data Access
Many classic vulnerabilities come from how applications accept, use and present data.
For ISO 27001 Control 8.26, define requirements around:
- Input validation and sanitisation
– All input is validated server-side (length, type, format, allowed characters).
– Protection against injection (SQL, command, LDAP, etc.) and XSS. - Output encoding
– Proper encoding for HTML, JSON, XML, etc. to prevent injection via outputs. - Data access and segregation
– Strong requirements for direct object access (no “/customer/123” exposing someone else’s data).
– Application-level checks that link data access to the logged-in user’s role and permissions. - File uploads and downloads
– Type and size checks for uploads.
– Virus/malware scanning where appropriate.
– Storage locations and permissions for uploaded files. - Free-text fields
– Any restrictions on storing sensitive data in arbitrary text fields.
– Consider redaction or monitoring if needed.
These requirements help developers and suppliers design data access patterns that are deliberately safe, rather than accidentally dangerous.
Step 5 – Define Requirements for Transaction Security (Where Relevant)
If your application supports transactions (financial or otherwise significant), you need specific requirements.
Examples:
- Transaction integrity
– Mechanisms to ensure transactions can’t be silently altered (e.g. checksums, signing, idempotent operations). - Non-repudiation
– Use of digital signatures, strong authentication or approval workflows for high-value actions. - Fraud detection and anomaly handling
– Requirements for monitoring unusual activity (e.g. multiple failed attempts, unusual transaction patterns). - Logging and traceability
– Ability to reconstruct who did what, when, and from where, for key actions.
Even for non-financial systems, it’s often useful to state what counts as a “critical action” (e.g. changing security settings, deleting data) and define extra security around it.
Step 6 – Define Logging, Monitoring and Error-Handling Requirements
Applications don’t exist in isolation – they sit in an ecosystem with SIEM, monitoring, and incident response.
Application security requirements should cover:
- Security logging
– What events must be logged (logins, failed logins, admin actions, access denials, configuration changes).
– The level of detail required (who, what, when, where). - Integration with central monitoring
– Format and delivery of logs to SIEM or central log platforms.
– Time synchronisation for accurate timelines. - Log protection
– Requirements to prevent tampering or unauthorised access to logs.
– Retention periods linked to regulatory or forensic needs. - Error handling
– No sensitive information in error messages or stack traces.
– Generic user-facing errors; detailed info logged only on the back end.
Defining this early avoids the common situation where an app goes live and security teams discover they can’t see anything useful when something goes wrong.
Step 7 – Cover Legal, Regulatory and Procurement Considerations
ISO 27001 Control 8.26 applies whether you’re building or buying.
For in-house development:
- Make sure each application’s security requirements reference relevant laws and standards.
- State clearly if the system will process regulated data (e.g. payments, health information).
For third-party or SaaS solutions:
- Treat your application security requirements as part of the specification sent to vendors.
- Check vendor responses and contracts against your requirements:
– Do they meet your authentication, logging, encryption, and data residency needs?
– Can they provide evidence (certifications, reports) where needed?
You want a clear line from risk → requirement → vendor capability rather than “we assume it’s secure because they’re a big name”.
Step 8 – Make Security Requirements Part of the SDLC, Not a Side Document
Finally, ISO 27001 Control 8.26 only really works if application security requirements are baked into your secure development life cycle (Control 8.25).
To do that:
- Capture requirements in the same tools as your other requirements (backlog, specs, user stories), not in a separate forgotten document.
- Make security requirements testable – so QA, security and product owners can validate them.
- Update requirements when:
– Functionality changes significantly.
– New threats or vulnerabilities become relevant.
– Regulations change.
Treat application security requirements as living artefacts that guide design, build, testing and acceptance – not just something you write once to tick a box.
Quick Implementation Checklist for ISO 27001 Control 8.26
Use this to gauge how well you’re defining application security requirements:
- ISO 27001 Control 8.26 (Application security requirements) is covered in your SDLC / development and procurement processes.
- Security requirements for each application are based on risk, data classification and regulatory needs.
- Identity and access requirements (authentication, authorisation, session handling, credential storage) are explicitly documented.
- Data protection and privacy requirements (encryption, minimisation, retention, masking) are clearly defined.
- Requirements exist for input validation, output encoding, file handling and data access controls.
- Transaction-specific security requirements are defined where the application processes payments or other critical actions.
- Logging, monitoring and error-handling requirements are specified and integrated with central security monitoring.
- Legal and regulatory requirements (e.g. GDPR, PCI DSS) are reflected in the application’s security requirements.
- Application security requirements are used for both in-house development and third-party/SaaS procurement.
- Security requirements are maintained and updated as the application and its environment evolve.
Bringing It All Together
ISO 27001 Control 8.26 – Application security requirements – exists to stop you discovering, at the end of a project, that “secure” meant completely different things to different people.
If you:
- Start from risk and data,
- Define clear, concrete security requirements across identity, data protection, behaviour, logging and compliance, and
- Embed those requirements into your SDLC and supplier selection,
you’ll end up with applications that are designed to be secure, not hurriedly patched after the fact – and you’ll have a clear, auditable story to show how application security is planned and controlled under your ISMS.
Explore the ISO 27001 Control Group Purposes