In this ultimate how to implement guide to ISO 27001 Annex A 8.26 Application security requirements, you will learn directly from an ISO 27001 Lead Auditor:
Table of contents
- 1. Define Security Requirements in Specifications
- 2. Mandate Authentication Standards
- 3. Specify Input Validation Rules
- 4. Secure Transaction Services
- 5. Enforce Cryptographic Requirements
- 6. Address Supply Chain Risks (SBOM)
- 7. Define Output Sanitisation
- 8. Vet Third-Party (SaaS) Acquisitions
- 9. Identify Legal and Regulatory Constraints
- 10. Formal Security Sign-Off
1. Define Security Requirements in Specifications
Control Requirement: Security requirements must be explicitly defined alongside functional requirements in the project scope.
Required Implementation Step: Update your project initiation templates (PRDs) or Jira Epic templates to include a mandatory “Non-Functional Security Requirements” section. This must detail specific needs such as “Must support SSO,” “Must encrypt field X,” or “Must log action Y.”
Minimum Requirement: No new software project starts without a documented list of security constraints.
2. Mandate Authentication Standards
Control Requirement: Applications must verify the identity of users to a level of trust appropriate for the data sensitivity.
Required Implementation Step: Specify that all new internal applications must integrate with the corporate Identity Provider (IdP) via OIDC or SAML. For public-facing apps, mandate MFA (Multi-Factor Authentication) for all administrative or financial access roles.
Minimum Requirement: Hardcoded credentials and local user databases are explicitly forbidden in the requirements phase.
3. Specify Input Validation Rules
Control Requirement: The application must sanitise all data inputs to prevent injection attacks.
Required Implementation Step: Write a requirement that all API endpoints and form fields must validate data against a strict “allow-list” (e.g., only alphanumeric characters). Explicitly ban the acceptance of raw HTML or SQL commands in the design document.
Minimum Requirement: The design specification requires the use of a framework that handles auto-escaping.
4. Secure Transaction Services
Control Requirement: Applications handling high-value transactions must prevent fraud and dispute.
Required Implementation Step: For financial or critical data updates, require “Non-Repudiation” mechanisms. This typically involves logging the exact IP, timestamp, and user session ID, or requiring a digital signature/re-authentication step before the transaction commits.
Minimum Requirement: Critical actions require a “Sudo mode” (re-entry of password) or separate approval step.
5. Enforce Cryptographic Requirements
Control Requirement: Data must be protected by encryption protocols that meet current standards.
Required Implementation Step: Define the exact encryption standards to be used (e.g., “AES-256 for data at rest,” “TLS 1.3 for data in transit”). Do not leave this decision to individual developers; specify the allowed cipher suites in the architecture document.
Minimum Requirement: A specific requirement banning HTTP and TLS 1.0/1.1 is written into the spec.
6. Address Supply Chain Risks (SBOM)
Control Requirement: Security requirements must extend to third-party libraries and components.
Required Implementation Step: Require the generation of a Software Bill of Materials (SBOM) for the application. Mandate that no library with a “High” or “Critical” CVE (Common Vulnerabilities and Exposures) score can be used in the production build.
Minimum Requirement: The build process must fail if vulnerable dependencies are detected.
7. Define Output Sanitisation
Control Requirement: Data output must be handled to prevent Cross-Site Scripting (XSS) and privacy leaks.
Required Implementation Step: Specify that all data rendered in the browser must be contextually encoded. Additionally, mandate that error messages displayed to users must not contain stack traces, database dumps, or system paths.
Minimum Requirement: “Generic Error Messages only” is a documented requirement.
8. Vet Third-Party (SaaS) Acquisitions
Control Requirement: Purchasing software requires the same security diligence as building it.
Required Implementation Step: Create a “SaaS Security Questionnaire” that vendors must complete before a contract is signed. This must verify their encryption standards, backup procedures, and ability to support your SSO; if they fail, the purchase is blocked.
Minimum Requirement: Procurement cannot issue a Purchase Order without a Security Approval signature.
9. Identify Legal and Regulatory Constraints
Control Requirement: The application must comply with all relevant data protection laws (e.g., GDPR, CCPA).
Required Implementation Step: Consult with the Data Protection Officer (DPO) during the design phase to identify PII (Personally Identifiable Information). If PII is handled, require features for “Right to be Forgotten” (data deletion) and “Data Portability” (export) to be built into the app.
Minimum Requirement: The app design includes a mechanism to permanently delete user data upon request.
10. Formal Security Sign-Off
Control Requirement: Development or purchase cannot proceed without formal security authorisation.
Required Implementation Step: Implement a “Gate 0” review where the CISO or Lead Architect reviews the security requirements against the proposed design. The project is only authorised to move to the “Build” or “Buy” phase once this approval is logged.
Minimum Requirement: A recorded “Approved” status on the security requirements document.
About the author
