Implementing ISO 27001 Annex A 8.26 is the strategic process of defining and formally approving information security requirements before the development or acquisition of applications. This control mandates integrating security specifications into project lifecycles, ensuring software is secure by design. The primary business benefit is preventing costly vulnerabilities and ensuring regulatory compliance from the outset.
ISO 27001 Annex A Application security requirements Implementation Checklist
Use this implementation checklist to achieve compliance with ISO 27001 Annex A 8.26. This control mandates that information security requirements are identified, specified, and formally approved before the development or acquisition of applications begins.
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.
ISO 27001 Annex A 8.26 SaaS / GRC Platform Implementation Failure Checklist
| Control Requirement | The ‘Checkbox Compliance’ Trap | The Reality Check |
|---|---|---|
| Defining Requirements | SaaS tool asks “Did you identify requirements?” (Yes/No). | The Project Manager clicked “Yes” to speed up the launch, but the actual Jira tickets contain zero security constraints. |
| Authentication | SaaS tool verifies you have a “Password Policy”. | The new app uses a standalone user database with unsalted MD5 hashes because nobody specified integration with the corporate IdP. |
| Input Validation | SaaS tool checks for a “Secure Coding Policy” document. | The policy exists in a folder, but the new marketing form is vulnerable to SQL injection because no technical requirement was written for the agency building it. |
| SaaS Vetting | SaaS tool stores the vendor’s SOC2 report. | The SOC2 report is 18 months old and excludes the specific module you are actually buying, but nobody read the fine print. |
| Encryption | SaaS tool checks if the website uses HTTPS. | The connection is encrypted, but the application is saving credit card numbers in plain text logs for “debugging purposes.” |
| Transaction Security | SaaS tool asks “Are transactions secure?”. | A user can replay a payment API request 50 times because no “idempotency key” or nonce requirement was specified in the API design. |
| Error Handling | SaaS tool checks for an “Incident Response Plan”. | The application crashes and displays the full backend code and database structure to the user, aiding an attacker, because secure error handling wasn’t a requirement. |
DO IT YOURSELF ISO 27001
STOP SPANKING £10,000s on CONSULTANTS and ISMS ONLINE PLATFORMS
About the author
