Security testing in development and acceptance

Plain-language summary

Defining and running security tests during development and before accepting any new or changed system into production, to confirm the agreed security requirements work and that no obvious vulnerabilities go live.

What the clause is really asking

This control has two halves: security testing built into development, and acceptance testing before a system goes live. Where you develop, security tests run during development: code analysis, vulnerability scanning, testing of authentication, access control and input handling, and for significant or internet-facing systems a penetration test. Where you acquire, acceptance testing applies even if you never write a line of code: before go-live, test that the security requirements set under 8.26 are met — MFA works, roles grant only what they should, logging records the events you need, data is encrypted — and scan the system for known vulnerabilities. So while organisations that do not develop often exclude 8.25 and 8.28, this control usually stays in for its acceptance half. Tests should run in a test environment (8.31) with protected test data (8.33). The common misunderstanding is that functional user acceptance testing covers security; it rarely checks what a user should not be able to do. Financial-sector clients working under the FSCA and Prudential Authority Joint Standard 2 of 2024 increasingly expect suppliers to show this evidence.

What auditors look for

Auditors ask for the security testing approach and then for the go-live records of the most recent new system or major change. They look for a test plan that includes security cases derived from the requirements, the results, defects raised and how they were resolved, and a formal acceptance sign-off naming who accepted the residual risk. For internet-facing systems they ask for vulnerability scan or penetration test results from before launch. They check that testing did not use live personal information without control. The hard question: what security defect did testing find on the last project, and was it fixed before go-live or accepted by someone with the authority to accept it?

Typical evidence

Security testing procedure or test strategy; test plans with security test cases traced to requirements; test results and defect logs; vulnerability scan and penetration test reports with remediation; acceptance sign-off records with residual risk acceptance; test environment and test data records; retest evidence for fixed defects.

How to comply — recommendations

Add a security section to your user acceptance test template: for each security requirement from 8.26, a test case — try to log in without MFA, attempt a function outside your role, check the audit log captured the change, confirm stored data is encrypted. Run an authenticated vulnerability scan on any new server or application before go-live. Commission a penetration test for new internet-facing systems and major releases, and retest the fixes. Make go-live conditional on a signed acceptance that lists open security defects and who accepted them. Keep the complete pack in the project file.

Common nonconformities

No security testing before go-live; user acceptance testing covers function only; security requirements not traced to test cases; penetration test findings not remediated or retested; acceptance signed by someone without authority to accept the risk; testing done in production or with uncontrolled live personal information; no record of test results.

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.