Application security requirements

Plain-language summary

Working out, writing down and approving the security requirements an application must meet before you build or buy it — authentication, access roles, logging, data protection, transaction integrity — so that selection and acceptance are judged against them.

What the clause is really asking

This control applies whether you develop an application or acquire one, which is why it is rarely excludable even for organisations that write no code. Before a new ERP, HR system, customer portal or SaaS tool is chosen, the control asks you to identify security requirements from your risk assessment, information classification, legal obligations and business needs, specify them, and have them approved — then use them to select and accept the product. Typical requirements: single sign-on and MFA; role-based access and segregation of duties; audit logging; encryption; data location and retention; validation of input and protection of transactions (orders, payments, approvals) against tampering or replay; secure integration; vendor support and patching. For anything holding personal information, POPIA section 19 and the operator rules in sections 20 and 21 feed directly into the list. The common misunderstanding is that requirements come from the vendor's datasheet; they come from you. ISO 9001 users will recognise the pattern from design inputs and the information given to external providers.

What auditors look for

Auditors pick the most recent application your organisation built or acquired and ask for the security requirements set before the decision, who approved them and how the chosen product was assessed against them. They look for a requirements checklist in the procurement or project file. They check a couple of requirements in the live system: is MFA enforced, are roles as specified, is logging on? For online transactions they ask how order or payment integrity is protected. If the answer is that the vendor handles security, they ask to see the evidence you obtained. The hard question: which requirement did the chosen product fail, and what did you decide about it?

Typical evidence

Application security requirements checklist or template; completed requirements for recent acquisitions and developments with approval; vendor responses or assessments against the requirements; risk assessment and classification inputs; procurement or project files showing requirements used in selection; acceptance test records against requirements; recorded decisions on unmet requirements.

How to comply — recommendations

Create a one-page application security requirements checklist covering identity (SSO, MFA), access roles, logging, encryption, data location and retention, integration, transaction integrity, vendor patching and support, and POPIA operator terms. Make it mandatory in procurement and projects: no purchase order for a new application without a completed checklist. Scale it by risk — a low-risk tool needs ten minutes, a new ERP needs a workshop. Have the business owner and IT approve it. Feed the same list into acceptance testing (8.29) so requirements are checked before go-live. Record a risk decision for any requirement the product fails.

Common nonconformities

No security requirements defined before acquiring or building applications; requirements copied from vendor marketing rather than derived from risk assessment; checklist exists but not used in procurement; requirements never approved; requirements not verified at acceptance; transaction integrity for online orders or payments not considered; unmet requirements not risk-assessed or recorded.

Resources for this clause

• ArticleISO/IEC 27001:2022 Annex A explained: the 93 controls in plain English, theme by theme, with the 114-to-93 map and the attribute tags
• ArticleThe Statement of Applicability, explained — what ISO/IEC 27001 clause 6.1.3 requires, the four ways an SoA fails Stage 1, and how to build one from the risk register
• ArticleISO/IEC 27001:2022 explained for people who already run ISO 9001: what is the same, what is new, and how to get certified
• Toolkit · $39Risk & SoA ToolkitScore your information security risks on a documented method, pick the Annex A controls that treat them, and the Statement of Applicability writes its own first draft — every justification citing the risks behind it.
• Toolkit · $29ISMS Metrics & Evidence TrackerThe three things an ISMS has to show after certification, in one workbook: measures with a live Green / Amber / Red status, management review minutes that cover every required input, and an evidence register that gives every control an owner, a rhythm and a due date.
• Free downloadAnnex A 93 Controls Quick ReferenceOne A3 page: all 93 Annex A controls in their four themes, the eleven new in 2022 flagged, and the ISO/IEC 27002:2022 attribute legend — the poster for the wall beside the Statement of Applicability.
• Free downloadISO 27001 Gap Analysis ChecklistWhere you stand against ISO/IEC 27001:2022 in one afternoon — the 30 management-system requirements and all 93 Annex A controls, scored, with owners, dates and a readiness figure that calculates itself.
• Free masterclass · ~27 minISO 27001 MasterclassYou already know four fifths of ISO 27001. Here is the other fifth — the risk method, the SoA, the 93 controls, the evidence rhythm, POPIA, and a 44-week path.
• Free appAudit ManagerPlan the programme, anchor each finding to its clause and drive the NC to closure.