ISO 27001 A.8.29: Test security before accepting a system
Security testing provides evidence that a system's important protections work before it is accepted for use. ISO 27001 Annex A.8.29 concerns defining and implementing security testing within the development life cycle. The useful question is what the test established about the agreed requirements, not simply whether a testing activity occurred.
What A.8.29 requires in practice
Annex A control A.8.29 expects security testing processes to be defined and implemented within the development life cycle, covering both development and acceptance. The point is evidence: before a system is accepted for use, the organisation should be able to show that its important protections work.
Defining a process means deciding what will be tested, by whom, against which requirements and with what acceptance criteria. Implementing it means the testing occurs and its results influence the release decision. Tests should reflect the application security requirements, so checks cover identity, permissions, information handling and behaviour when something fails, including actions that should be refused.
The outputs are a test approach scaled to the importance of the change, results with findings handled, and a recorded acceptance decision. Any technical assessment needs an explicitly authorised scope. Applicability follows risk treatment and the Statement of Applicability.
Begin with the security requirements
Use application security requirements to identify what must be demonstrated. Relevant checks may concern identity, permissions, information handling, configuration or behaviour when a dependency fails. Select tests according to the system's importance and the potential effect of the change.
Define expected outcomes before running the test. Testing only the path that should succeed can miss a permission boundary or an error condition. Include representative actions that should be refused or handled safely, using appropriate accounts and non-sensitive information wherever possible.
Why security testing before acceptance matters to the business
A system accepted without meaningful security testing moves the discovery of weaknesses to the live environment, where customers and attackers may find them first. Testing before acceptance is cheaper than responding afterwards and gives decision makers a factual basis for approving release. It also protects commercial relationships, because customers can be told what was checked rather than reassured in general terms. Teams benefit too: clear acceptance criteria prevent arguments about whether something is ready. At audit, test records tied to requirements show that release decisions are informed rather than habitual.
How to implement A.8.29
Start from the requirements and keep testing proportionate to the risk of each change. The following sequence is a reasonable base. Keep the approach proportionate: a small change to a low-risk screen does not need the same scrutiny as a new payment feature. Agree the levels of testing in advance so that teams are not negotiating them under release pressure, and review them after problems found late.
- Take the application security requirements and list what must be demonstrated for each.
- Choose test types according to the system's importance and the effect of the change.
- Define expected outcomes before testing, including cases that should be refused or handled safely.
- Use appropriate accounts and non-sensitive test information.
- Confirm in writing the authorised scope for any technical assessment.
- Record the results and route each finding to an owner with a decision to fix, accept or defer.
- Make acceptance conditional on review of the results by an accountable person.
- Re-test corrected findings and improve the approach from what the results reveal.
Illustrative software example: a role that should not export
A fictional software team develops an export feature. Functional testing confirms that a permitted user receives the expected file, and an automated scan reports no relevant issue. The agreed requirement also says that a restricted role must not obtain the export.
The team adds an authorised test for that role and discovers that one access path does not enforce the intended restriction. It corrects the issue and verifies the affected behaviour before acceptance. The example shows why security testing must examine the actual requirement rather than infer it from a successful function or unrelated scan result.
Illustrative construction example: a supplier demonstration differs from deployment
A hypothetical construction company acquires a document platform. The supplier demonstrates suitable sharing restrictions in its own environment, but the customer's proposed deployment uses different settings and external-user arrangements. The procurement team initially considers the demonstration sufficient acceptance evidence.
The company agrees representative tests in an appropriately configured environment and records differences that affect the conclusion. It verifies relevant access and sharing scenarios before operational use. The evidence now relates to the intended deployment, with clear limitations where some provider-controlled elements cannot be directly tested.
Protect the test environment and information
A test environment should be sufficiently representative to support reliable conclusions while avoiding unnecessary exposure or disruption. Understand material differences from production. A simplified environment may be useful for a particular test, but its result should not be extended to untested configurations or integrations.
Coordinate with environment separation and test information. Protect accounts, data and tools used during the assessment. Where a test could affect a live service, define authorisation, operational safeguards and stop conditions before starting; testing is not a reason to disregard normal control.
Make security evidence useful to release decisions
Discuss security-testing governance with Sterling. Scoped consulting can connect requirements, documentation, employee learning and agreed Effivity ISO & GRC automation software. The offered authorised vulnerability assessment covers agreed scanning and findings review; it does not silently promise penetration testing. Continuing support covers defined preparation while certification remains independent. Enrol in ISO/IEC 27002 Information Security Controls to understand testing within the technological controls.
Common nonconformities with A.8.29
Findings tend to show testing that occurred but did not support a decision. These usually arise where testing was treated as a final hurdle and not as a decision input, so an auditor traces a recent release from requirement to test result to approval.
- Testing limited to the path that should succeed, with no checks that restricted actions are refused.
- Test results with no recorded decision on open findings.
- Release approved before testing finished.
- Technical assessments performed without a written, authorised scope.
- No link between the tests and the agreed security requirements.
Frequently asked questions
Does a clean vulnerability scan prove an application is secure?
No. It provides evidence within the scan's scope and limitations. Important business logic, access requirements and configuration may need other forms of verification.
Can security testing happen during development?
Yes. Integrating checks during development can reveal issues earlier. Acceptance still needs appropriate evidence for the version and environment intended for use.
What should happen when a finding is not fixed before release?
Make an accountable decision about the residual risk, scope and treatment. A deferred issue should have an owner and review conditions rather than disappear from the acceptance record.
Make findings part of the release decision
Record the result, relevant finding, responsible owner and treatment. Verify a correction rather than closing the issue solely because a developer says the code changed. Where a concern remains, the acceptance decision should identify the limitation and an authorised response to the residual risk.
Useful evidence includes the requirements tested, version and environment, methods, outcomes, finding treatment and acceptance decision. These are practical evidence choices rather than a prescribed report template. Preserve enough context for a reviewer to understand what the result does and does not establish.
Common failures include reports unrelated to the deployed version, repeated deferral of the same weakness and test accounts or data left behind after completion. Use operational control to connect testing with release and subsequent change. Security testing improves confidence within its scope; it cannot prove the absence of every vulnerability.