ISO 27001 A.8.26: application security needs, explained for startups

A.8.26 Application security requirements

Security needs are written down before a feature is built. What proves it: security requirements captured for new features, and an example.

A certification auditor samples security requirements in tickets or specifications. A file that usually does the job: a feature specification or ticket template with its security requirements section filled in.

How to put it in place

Each step leaves a record, and the record is what the auditor samples rather than the step itself. Inside Polara, the control card for A.8.26 walks you through it in this order.

1. Add a security section to your feature template: data handled, access needed and how it could be abused.
2. Fill it in before building.
3. Check it during code review.

The free ISO 27001 readiness assessment asks one question that evidences it:

• Which of these run on your code: dependency scanning, secret scanning, static analysis, written security requirements?

Policies, connectors and the SOC 2 overlap

In the ISO 27001 policy pack, the Secure Development and Change Management Policy covers A.8.26. An auditor reads the policy for the rule, then samples the records to see the rule was followed.

The same evidence counts toward SOC 2. The Trust Services criterion that cover this ground: CC8.1, change management.

Technological controls

A.8.26 is one of the 34 technological controls in Annex A. The controls built into your systems: access, devices, malware, vulnerabilities, backups, logging, networks, encryption and secure development. Exports and settings screenshots prove most of them.

Nearby controls in the same theme:

• A.8.23, web filtering
• A.8.24, encryption
• A.8.25, secure development
• A.8.27, secure architecture
• A.8.28, secure coding
• A.8.29, security testing

Before it: A.8.25, secure development. After it: A.8.27, secure architecture. Every control, by theme, is on the Annex A controls page.