---
title: "ISO 27001 Annex A 8.29: Security testing in development and acceptance"
canonical: https://www.grcmana.io/vault/iso-27001/annex-a-8-29-security-testing-in-development-and-acceptance
published: 2023-08-09
updated: 2026-10-07
author: "Harry West"
framework: "ISO 27001"
control: "A.8.29 Security testing in development and acceptance"
journeyStage: implementation
---

# ISO 27001 Annex A 8.29: Security testing in development and acceptance

## Key takeaways

ISO 27001 Annex A 8.29 requires security testing to be defined and embedded throughout the development lifecycle, with pass/fail criteria that gate every release. In practice that means static analysis and dependency scanning in CI, dynamic testing against staging, independent acceptance sign-off, and periodic penetration testing — scaled to the risk of the system. It applies equally to software you build and software you buy.

- **Control type** — Preventive — catches exploitable flaws before deployment, when they are findings rather than incidents
- **2022 change** — Merges two 2013 controls (system security testing and acceptance testing) into one lifecycle-wide requirement
- **Typical tooling** — SAST, SCA and DAST wired into CI, plus an annual independent penetration test (£5–15k for a mid-market firm)
- **Scope** — Covers software you develop, software you outsource, and software you buy — acquired code must be evaluated too

**The security section of an enterprise due-diligence questionnaire has a habit of arriving mid-deal:** ***where is your latest penetration test report? How is code tested before release?***

**If the honest answer is "our developers are careful," you already know how that reads on the other side of the table.**

ISO 27001 Annex A 8.29 is the control that changes that answer. Its premise is simple: nothing reaches production on the assumption that it's secure — that has to be demonstrated.

In practice, that means security testing defined across the development lifecycle: not one big test before launch.

Build it once, and it answers every buyer who asks.

This guide covers what the control requires, how a lean firm implements it without an enterprise security team, and the evidence auditors sample when they test it.

It's written for regulated service providers — firms answerable to the FCA, the ICO, or both — and B2B software firms of roughly 25–250 people: the size where the pipeline has to do most of the work.

## What does ISO 27001 Annex A 8.29 require?

ISO 27001 Annex A 8.29 requires security testing processes to be defined and implemented across the development lifecycle, verifying before release that security functions behave as specified, code is free of known vulnerabilities, and configurations are secure. It applies to new systems, upgrades, and software you buy or outsource.

The purpose of the control is to validate that security requirements are actually met when applications or code move to production. Your testing regime needs to verify three things, in proportion to how much the system matters:

- **The security functions themselves** — authentication, access restrictions, cryptography — behave as specified.
- **The code** is free of known-vulnerable patterns and dependencies.
- **The configurations** the system ships with are secure.

The standard expects structure around that testing: documented test plans with expected outcomes and defined pass/fail criteria, developer-level testing during the build, and independent acceptance testing before release.

A release gate with no defined failure condition isn't a gate.

Two scope points catch firms out. First, the control applies to new systems, upgrades and new versions — not just greenfield builds.

Second, it applies to software you buy or have built for you: acquired code needs security requirements in the contract and an evaluation against them before you accept delivery.

A.8.29 sits in a chain of development controls. It picks up where A.8.28 (secure coding) leaves off, runs in the separated environments A.8.31 requires, and produces the test evidence that A.8.32 (change management) consumes at the release gate.

## Why is Annex A 8.29 critical for B2B software vendors?

Annex A 8.29 matters because it converts security from a claim into evidence. Enterprise buyers ask for penetration test reports and secure-SDLC proof in almost every serious procurement, and ISO 27001 auditors treat the control as core for any firm with development in scope.

For a software vendor, security testing is sales infrastructure.

Two fears usually sit under this control, and both deserve naming. The engineering fear: that security testing means friction — gates that slow the release train a growing firm depends on. The commercial fear: that one exploitable flaw undoes years of trust-building with the customers that matter most.

A.8.29, implemented the modern way, answers both at once — the testing runs inside the pipeline the developers already use, and the evidence it throws off is exactly what enterprise buyers ask to see.

The cost curve makes the same argument. A critical flaw found by a CI scan costs an hour. The same flaw found by a customer's security team costs the relationship. Found by an attacker, it costs an incident, disclosure obligations, and possibly a conversation with the ICO.

Auditors treat this as a core control for any organisation with development in scope — and they test whether the gate is real, not whether the tooling exists.

## How do you implement A.8.29 security testing to pass an audit?

To implement Annex A 8.29, define pass/fail testing criteria in your secure development policy, automate static analysis (SAST) and dependency scanning (SCA) in CI, run dynamic testing (DAST) against staging, keep peer review on security-critical paths, and commission an independent penetration test annually. At a 25–250 person firm, the pipeline does most of this for you.

That last point is the one worth pausing on. Most of this control is configuration, not headcount.

The modern toolchain has quietly turned A.8.29 from a security-team problem into an engineering-workflow one:

**Describe the regime in your secure development policy.** Which tests run at which lifecycle stage, who's responsible, and — critically — the pass/fail criteria. The criteria are what auditors check first.

**Let the pipeline do the volume.** Static analysis (SAST) and dependency scanning (SCA) on every build; dynamic testing (DAST) against staging for the runtime and API layer. All three exist as commodity tooling that bolts onto GitHub or GitLab CI in days, not months.

**Keep the human layer for what machines miss.** Peer code review with security on the checklist, and developer tests around the security-critical paths: login, permission checks, crypto usage, tenant boundaries.

**Test somewhere that resembles production.** Staging should mirror production configuration (that's A.8.31's job), with masked or synthetic data — never live personal data.

**Scale depth to risk.** Routine releases ride the automated gates plus review. New architecture, new external surfaces or high-risk changes get deeper attention. Commission an independent penetration test annually and after major architectural change — at this scale, that cadence satisfies both auditors and enterprise customers.

**Make acceptance explicit.** A named person signs off that criteria are met before release. Highs and criticals get fixed and retested, or formally risk-accepted. Silence is not acceptance — and the person who wrote the change shouldn't be the person who accepts it.

**Cover acquired software.** Security requirements in the development contract, and an evaluation against them before you accept delivery.

Starting from zero, the sequence is: wire the automated gates first — SAST and SCA take one to two weeks including tuning — then add DAST and the acceptance workflow. Budget £5–15k for the annual penetration test at this scale.

From that point on, every build is quietly collecting the evidence your next audit — and your next enterprise deal — will ask for.

## Choosing your testing methods

| Method | What it does | Where it runs |
| --- | --- | --- |
| Static application security testing (SAST) | Analyses source code for vulnerable patterns without executing it | CI, on every build |
| Software composition analysis (SCA) | Flags known vulnerabilities in the open-source libraries you depend on | CI, on every build |
| Dynamic application security testing (DAST) | Probes the running application the way an attacker would | Staging, per release cycle |
| Peer code review | Human judgement on security-critical paths machines can't assess | Every security-relevant change |
| Penetration testing | Independent, goal-driven testing of the whole system | Annually and after major change |

You don't need all of everything.

The combination that satisfies the control for most mid-market firms is SAST and SCA on every build, DAST against staging, review on the way in, and the annual pen test on top.

## What A.8.29 evidence do ISO 27001 auditors look for?

ISO 27001 auditors test Annex A 8.29 by sampling: expect them to pick a recent release and trace it end to end — scan results, review record, acceptance sign-off — and separately pick a high-severity finding and follow it to closure. The evidence below is what that sample will touch.

Have these ready:

- The testing section of your ISMS secure development policy, with its pass/fail criteria.
- Pipeline output: scan reports and history. The strongest exhibit is a build that **failed** the security gate and the fix that followed — evidence of a block proves the gate is real.
- Peer review records and test runs for security-relevant changes.
- The latest penetration test report, its scoping, and the remediation trail.
- Acceptance sign-offs tying named approvers to releases, and risk acceptances for anything shipped with known issues.
- For outsourced or purchased software: the contractual security requirements and the pre-acceptance evaluation.

Questions to expect in the room:

- "Walk me through what happens between a developer merging code and it reaching production — where does security testing bite?"
- "Show me a release that failed a security check. What happened next?"
- "Who signs off a release, and against what criteria?"
- "When was your last penetration test, what did it find, and where are those findings now?"
- "How do you know the libraries you depend on aren't the vulnerability?"

## Common pitfalls

- **Security testing as a pre-launch event** rather than a pipeline property — one big test at the end finds problems precisely when they're most expensive to fix.
- **Live customer data in staging**, unmasked. That turns a test environment into a data-protection incident waiting for a leak, and auditors specifically look for it.
- **Gates with no teeth.** Scanners run, reports accumulate, nothing ever blocks. If no release has ever failed the gate, the auditor will conclude there isn't one.
- **Third-party blindness** — no dependency scanning, no evaluation of agency-built code before acceptance, on the assumption someone else tested it.
- **Staging that doesn't resemble production**, so configuration-level flaws surface only after deployment.
- **Developers accepting their own work**, collapsing the independence the control exists to create.

## Automating A.8.29 with GRC engineering

Annex A 8.29 is the most natively automatable control in ISO 27001: the same CI/CD pipeline that runs the tests can enforce the pass/fail criteria, collect the evidence, and track remediation.

The pipeline is the control — and that changes what compliance costs:

- **Gates as configuration.** SAST, SCA and DAST thresholds encoded in CI mean the pass/fail criteria execute themselves, and every run leaves timestamped evidence.
- **Evidence with zero collection effort.** Scan reports, blocked builds and approval records accumulate as a by-product of working. The auditor's sample becomes a link, not a hunt.
- **Vulnerability SLA tracking.** Findings flow into the tracker with severity clocks; breached remediation windows escalate automatically — exactly the remediation loop the standard wants to see.
- **Continuous assurance for customers.** The same telemetry answers enterprise due-diligence questionnaires — current scan posture, last pen test, open finding counts — from a dashboard rather than a scramble.

## Frequently asked questions

### What kinds of testing does ISO 27001 Annex A 8.29 actually require?

In practice: static code analysis and dependency scanning in CI, dynamic testing against staging, peer review of security-relevant changes, functional checks of security features, and periodic penetration testing. The mix scales with what the system does and how much it matters.

### Do we need a penetration test for every release?

No. Routine releases ride automated scanning and peer review; independent penetration testing belongs on an annual cycle and after major architectural change. Per-release pen testing is over-engineering for most mid-market firms.

### Is A.8.29 mandatory for ISO 27001 certification?

If development is in scope of your ISMS, yes — auditors treat it as a core control and will sample releases to test whether the gate is real. Firms with genuinely no development activity can justify exclusion in the Statement of Applicability.

### Does A.8.29 apply to software we buy or outsource?

Yes. Security requirements belong in the supplier contract, and delivery should be evaluated against them before acceptance. "The agency tested it" without evidence doesn't survive an audit sample.

### What changed from ISO 27001:2013?

Two 2013 controls — system security testing and system acceptance testing — merged into one, with more explicit expectations around structured test plans, environment separation, and testing woven through the lifecycle rather than saved for the end.