A.8.29 Security testing in development and acceptance

What A.8.29 security testing asks for before a system goes live

A.8.29 asks the organization to define security testing processes and then carry them out within the development life cycle, including the acceptance of new systems, upgrades and new versions against security requirements. If you are the compliance lead or engineer who must show this, the first job is to establish that testing is written down as a process with named steps, owners and pass or fail criteria, and that records show it ran before each release or handover. The control covers both building software and taking delivery of it, so a vendor release or an infrastructure change can fall within it even when your own developers wrote nothing. The reason this matters is practical. A defect found during acceptance is usually cheaper to fix than one found after go-live, and a weakness that was never tested tends to stay invisible until someone outside the organization finds it. The reason it is hard is scope. Many teams define security testing for customer-facing applications but never define it for the platform underneath: the operating system build, the container images, the identity configuration, the network changes, or the patch that a vendor ships every quarter. Those gaps are where an assessor will look first.

A.8.29 merges two controls from the 2013 edition, A.14.2.8 System security testing and A.14.2.9 System acceptance testing, so an organization that already had evidence for those two should check whether the new single control still covers both the functional and security side of acceptance. The control sits beside A.8.26 Application security requirements, which sets the security criteria that tests are measured against, A.8.28 Secure coding, which governs how the code is written, and A.8.33 Test information, which governs the data used in test environments. Read together, these four controls describe a chain: requirements, secure construction, testing with controlled data, and acceptance before production. Before you draft the procedure, confirm three things with the control owners: which systems are in scope for acceptance testing (applications only, or infrastructure and third-party releases too), which security requirements each test is checked against, and who has authority to stop a release that fails. Those answers determine the evidence you will need later, such as test plans, scan outputs, sign-off records and remediation tickets. The ISO/IEC 27002:2022 guidance on the control is the natural next read for the intent behind these decisions.

Which systems, teams and suppliers A.8.29 covers in practice

A.8.29 applies to whatever your organization builds, changes or accepts into service, so the first work is deciding what counts as a system in scope. The decisions below change who runs each test, what evidence exists and what an assessor will ask for, and they should be agreed with your auditor before the Statement of Applicability is finalized.

In-house application code

Code your teams write for internal tools or customer-facing products is the core of A.8.29. Decide which repositories, services and release pipelines fall inside the security testing process, and which stages (static analysis, dependency checks, dynamic testing before release) apply to each. Your own developers and security staff own these tests, and the pipeline records are the evidence. Confirm with your auditor whether pre-release scans on every merge or on each release candidate meet your defined process.

Infrastructure as code

Terraform, Ansible and similar templates define production systems, so misconfigurations written there are security defects in a system you build. Include the repositories that produce cloud resources and network rules, and test them before they are applied. Your platform engineering team owns the checks, and the pipeline output and approval records show acceptance. Ask your auditor whether configuration templates count as development output under your scope statement.

Third-party and purchased software

Commercial products and open-source components you deploy are usually not written by you, yet acceptance testing against your security requirements still applies before they go live. Define the acceptance criteria, such as authentication settings, logging and hardening baselines, and record the results. Vulnerability tracking for installed products sits alongside this, and tools such as Fleet can match installed software against vulnerability sources. Confirm with your auditor how purchased software is handled in the acceptance process.

Upgrades and new versions of existing platforms

Each upgrade or new version of a running platform is a change that needs security testing before it reaches production, even when the product itself is already trusted. Decide which upgrades trigger acceptance testing, for example major versions, changes to authentication or changes to network exposure, and which follow a lighter route. The operations or platform team usually owns these tests, and the signed-off test results become the acceptance record. Confirm the trigger criteria with your auditor.

Outsourced development

When a supplier writes code or configuration for you, A.8.29 still requires testing, but the contract determines who runs it and what evidence you receive. Specify in the contract which security tests the supplier performs, what reports you receive and what acceptance tests you run yourself before going live. Your procurement and security teams own the terms, and the supplier's test reports feed your acceptance records. Confirm with your auditor how supplier-run tests count toward your evidence, since A.8.30 covers the same supplier relationship.

How an assessor tests security testing during development and acceptance

This table lists what an assessor asks to see for A.8.29, the evidence that answers each request, and the findings that most often appear when testing is defined on paper but not carried out. Read each row as a question the assessor will put to the organization, then check whether your records answer it for recent releases, upgrades and emergency changes.

Assessor focus	What the assessor asks to see	Common finding
Defined testing process	A written security testing procedure inside the development life cycle, naming who runs each test type, which tools are used and where results are recorded	Testing is described in policy, but no procedure ties it to the actual pipeline or release steps
Test types by change category	A mapping of change types (new system, major feature, minor change, vendor upgrade) to the tests required for each, such as static analysis, dependency scanning, dynamic testing or penetration testing	All changes receive the same treatment, or high-risk changes skip dynamic testing without a recorded reason
Acceptance criteria	Security requirements stated before build, with pass or fail thresholds and sign-off by a named owner before a system goes live	Acceptance is limited to functional checks, and security requirements were never written down
Test execution records	Pipeline logs, scan reports, test plans and results tied to specific commits or builds, with open findings tracked to closure or formal risk acceptance	Testing is defined but not run, or results exist for some builds and not for the release that shipped
Emergency changes	The emergency change path, the retrospective testing performed afterward and the approval that accepted residual risk	Acceptance is skipped for emergency changes and no retrospective test is recorded
Vendor and third-party upgrades	Acceptance records for each upgrade or new version, including the security test results or the supplier evidence the organization reviewed	No records exist for vendor upgrades because the team treats them as routine maintenance
Sampling of recent releases	The assessor selects a sample of recent releases and upgrades, then traces each one back to its test results, acceptance sign-off and any open findings	Records cannot be produced for the sampled items, even though the process document is complete
Test data handling	Evidence that test environments and test data used during security testing are controlled, consistent with A.8.33 Test information	Production data is copied into test tooling without approval or deletion evidence

Implementing security testing in the development life cycle

The sequence below turns A.8.29 from a statement of intent into a working process: a testing standard, criteria for each system, automated checks in the pipeline, targeted manual testing for higher-risk releases, a documented sign-off for new systems and upgrades, and a register of exceptions. Each step ends with a record an assessor can sample.

Define the security testing standard and test types
The information security or application security lead writes a short testing standard that names the test types the organization uses, such as static analysis, dependency and vulnerability scanning, dynamic testing of running applications and APIs, and manual penetration testing. It maps each change category, such as a new internet-facing application, a routine upgrade or an internal tool, to the tests it must pass. Engineering leads review it and the document is approved under the organization's policy process. Done means an approved standard exists, with a version and owner, and every development team can point to the test matrix that applies to its work.
Set security acceptance criteria for each system
For each system or application in scope, the system owner and security team agree a criteria document that states what 'secure enough to release' means. It covers requirements inherited from A.8.26 such as authentication, authorization, data protection and logging, plus thresholds for findings, for example that no unresolved high-severity finding may ship without a recorded risk acceptance. The criteria are written before testing starts so that results are judged against agreed rules rather than against whatever the team happens to find. The output is a criteria document per system, linked from the system's record in the asset inventory.
Integrate automated checks into the delivery pipeline
Engineering configures the pipeline so that automated security checks run on every merge request or build. Static analysis can be run with Semgrep Community Edition, which scans a range of languages including Java, JavaScript, TypeScript, Python, Go and Terraform and can run in CI/CD to scan repositories continuously. Dependency and vulnerability checks run against the software bill of materials, and dynamic checks run against a test environment. Protected branches in GitLab Community Edition stop unreviewed changes from reaching the release branch. The pipeline configuration file, a sample of failed and passed runs, and the rule set in use are the evidence that the checks are operating, not just documented.
Schedule manual and external tests for higher-risk releases
Changes that touch authentication, payments, sensitive personal data, internet exposure or core infrastructure receive manual testing before release, either by an internal tester or an independent firm. The scope, method and tester are recorded in a test plan that is agreed before the test begins. Testers work in a non-production environment that holds test data, not production records, consistent with the test information control A.8.33. The report lists findings with severity, owner and due date. The test plan and report are retained so an assessor can see that higher-risk releases were tested by someone other than the developer who wrote the code.
Run the acceptance and sign-off workflow
Before a new system goes live, or an upgrade or new version is promoted, the change owner collects the test results, the criteria document and any open findings into one acceptance package. The security reviewer and the system owner each sign it, and operations confirms that the release matches what was tested. For upgrades, the package also compares the new version against the previous one, so that regressions in security settings are caught. The completed package, with dated signatures, is the sign-off record. It should be filed with the change request so that an auditor can trace a production release back to its evidence.
Handle exceptions through a managed register
When a release cannot meet the criteria, for example because a vendor fix is not yet available, the team does not ship on informal agreement. The exception is written into an exception register with the finding, the business reason, the compensating controls, the approver and an expiry or review date. A senior risk owner approves it, and the register is reviewed at a defined interval set in the testing standard. Expired exceptions are escalated. The register itself is evidence of control operation: an auditor will look for exceptions, check that each has an approver, and test whether the compensating controls were in place.

Evidence that satisfies A.8.29 and how to keep it current

An auditor tests A.8.29 by sampling real releases, not by reading the policy alone. The artifacts below connect the testing procedure to each change that shipped, so every sampled release can be traced from requirement to test to sign-off. Owners should refresh each record on the cadence set by the release process, and the organization, not the implementation partner, keeps them current between audits.

Security testing procedure

The documented procedure defines which tests run at which pipeline stage, which tools are approved, what severity blocks a release, and who may accept residual risk. It is the document an auditor reads first, so it must match what the pipeline actually does. Review it at least once a year and whenever a tool or stage changes, and record the approval and version. Check that it names the owner for each test type, such as the application security lead for static analysis and the platform team for container and host scans.

Pipeline logs showing scans ran

Scan logs from CI/CD runs prove that testing happened for each change, not just that it was planned. Keep the job output, the tool version, the ruleset version and the commit hash for every release candidate, retained for the period the organization sets in its records policy. Semgrep Community Edition can run in pipelines to scan repositories continuously, so the pipeline configuration file and its run history are the natural evidence. Confirm that failed or skipped jobs are logged too, because gaps in the record are what sampling finds.

Findings and their resolution

Each finding needs a record from detection through fix, retest and closure, linked to the release it affected. Auditors look for findings that were opened and closed with a reason, not findings that disappeared. Track severity, owner, due date and the commit or merge request that resolved it. GitLab protected branches help here by requiring merges through reviewed paths, so the merge record shows who approved the fix. Review open findings against the procedure's deadlines at each release gate.

Signed acceptance test reports

Before a system or version goes live, acceptance testing against the stated security requirements should produce a written report with test cases, results, the tester, and a named approver who accepts the outcome. This is the record that links A.8.29 to A.8.26 requirements. Auditors sample these per release, so every production release needs its own signed report. Confirm that the approver is someone other than the developer and that test data complies with A.8.33 rules.

Records for upgrades and new versions

Upgrades, patches and new versions of platforms and libraries are changes that also need security testing and acceptance. Keep a register that lists each upgrade, the vulnerability or feature driving it, the test results and the rollback plan. Vulnerability tools such as Fleet and Wazuh can show which hosts run affected software before and after the change, which gives the register its supporting data. Update the register at every upgrade and reconcile it against the asset inventory at least once a quarter.

Exception approvals

When a release ships with an open finding or a skipped test, the exception must be recorded with its justification, the risk owner who accepted it, an expiry date and a compensating control. Auditors test exceptions closely because they show whether management actually governs risk. Review active exceptions at each release cycle and close those past expiry. Confirm with the certification body how it expects exceptions to be dated and approved before the first audit.

What meeting A.8.29 costs in money and effort

This table lists the cost components of building and evidencing A.8.29, who is paid for each, whether it is one-time or recurring, and what pushes it up or down. No cost figures are given, so use the drivers to shape a written scope and quote. The main takeaway is that most of the recurring cost comes from release frequency and the number of systems, not from the initial setup.

Cost component	Who is paid or who bears it	One-time or recurring	What drives it up or down
Tooling or licenses	Software vendor or hosting provider; internal team if self-hosted	Recurring if commercial; one-time setup for self-hosted tools	Number of repositories and scanned applications rises cost for commercial tiers. Community editions such as Semgrep Community Edition and GitLab Community Edition lower license spend, but confirm feature fit with the vendor.
Engineering time to build pipeline checks	Internal platform or development team, or an implementation partner under a fixed-scope agreement	One-time, with later changes as the pipeline evolves	Number of languages, build systems and pipelines to cover. Reusable pipeline templates shorten the work for each new repository.
Defining security test criteria and acceptance criteria	Internal security lead, with input from product and development owners	One-time, then reviewed on a schedule	Number of system types and regulated data classes. Reusable acceptance criteria for common system types reduce rework across releases.
Acceptance testing of each release or upgrade	Internal QA, security engineers or a partner, depending on who runs the tests	Recurring, per release	Release frequency and the size of each change. Automated checks in CI/CD reduce manual effort per release, but manual review of high-risk changes still needs time.
External penetration or application testing	Independent testing provider, chosen by the organization	Recurring, usually per test cycle	Number of internet-facing applications and APIs, release cadence, and whether the test covers new major versions. Scope it in writing so the provider knows which releases and systems are in scope.
Vulnerability tracking for deployed software	Internal operations team; tooling vendor if commercial	Recurring	Number of endpoints and installed applications. Self-hosted inventory and vulnerability tools can cover this with internal staff time, but alert triage takes ongoing effort.
Evidence upkeep	Internal compliance or security staff, or an implementation partner	Recurring	Number of releases, test runs and exceptions that need recorded decisions. Storing evidence automatically from pipelines and ticketing systems lowers manual collection.
Auditor sampling time	Certification body or independent auditor, billed under its own agreement	Recurring, tied to audit cycles	Number of releases sampled and how easily records can be retrieved. Clear, linked records for each release reduce the time auditors spend searching.
Preparation for audit	Internal team, possibly supported by a partner that does not issue certification	Recurring before each audit	Gaps in acceptance records and unresolved findings from earlier tests. Regular internal reviews keep the preparation effort small.

Open-source tools that produce A.8.29 evidence

A.8.29 asks for security testing to be defined and built into development, and for new systems and changes to be tested against security requirements before acceptance. The tools below can generate records of review, scanning and vulnerability findings, but each one covers only a slice of that work. Auditors will look for the acceptance criteria, the decisions made on findings and the human testing that sits around these records.

GitLab protected branches

Protected branches are a control point for code change approval. Maintainers can restrict which roles may push or merge to a branch, block direct pushes by setting push access to no one, and keep force pushes disabled unless explicitly allowed. The resulting merge history shows that changes passed through a defined route before reaching a release branch. Confirm the approval rules and merge request settings against current GitLab documentation for your version, since the evidence depends on how these settings are configured and enforced.

Semgrep Community Edition scanning

Semgrep Community Edition scans source code in languages including Go, Java, JavaScript, TypeScript, Python, C/C++, C#, Ruby, Rust, PHP, Kotlin, Swift and Terraform, using community or custom rules. It can run in CI/CD pipelines to scan repositories continuously, so each merge or build can leave a stored scan result. Those results show that security checks ran before acceptance. They do not show that the rules cover your threat model, so check rule coverage for each language your team ships, and document how findings are triaged.

Wazuh vulnerability detection

Wazuh vulnerability detection correlates the software inventory collected by each agent with the Wazuh CTI vulnerability repository, or with a locally hosted offline copy. It identifies vulnerabilities in the operating system and installed applications of monitored endpoints. For A.8.29, the output is evidence that acceptance-tested systems are monitored after release. Confirm whether your deployment can use the offline copy, and record how detected vulnerabilities are routed into remediation or risk acceptance.

Fleet vulnerable software detection

Fleet detects vulnerable software on enrolled hosts by matching installed software against sources including the NVD, OVAL definitions, Microsoft security bulletins, Amazon Linux advisories and OSV. The record links a host's software inventory to published advisories, which helps show that new or upgraded systems were checked against known vulnerabilities before they were accepted. Fleet does not decide whether a release is fit for use. Confirm which advisory sources apply to your operating systems and keep a written acceptance decision for each flagged item.

Who defines, runs and checks security testing for a release

The organization owns A.8.29. Its security function and engineering leadership decide what testing is required, what a release must pass before it reaches production, and who may accept residual risk when a finding is not fixed. These decisions cannot be delegated to a vendor, because the certification body will ask the organization to show who made them and on what basis.

Testing policy: Define which security tests apply to which system types, such as code scanning, dependency checks, dynamic testing of web and API interfaces, and infrastructure checks.
Acceptance criteria: Set the security conditions a new system, upgrade or version must meet before sign-off, and record them in the change or release procedure.
Risk decisions: Decide in writing whether an open finding blocks release, is fixed later with a date, or is accepted by a named owner.
Sign-off: Assign the people who approve releases against those criteria and keep their approvals as records.
Review: Confirm that the policy still matches the systems in scope after major changes.

Before engaging anyone, confirm that a named owner can explain each release decision from the records alone.

Where organizations fall short on secure acceptance testing

Most gaps under A.8.29 are not missing tools. They are missing decisions: which systems are in scope, who accepts a change, and what happens to findings after a test runs. The cards below cover six gaps we see most often, with a practical fix and the evidence an assessor would expect to see for each.

Testing defined only for web applications

Many programs define security testing for public web apps and forget internal APIs, batch jobs, mobile clients, infrastructure as code and cloud configuration. A.8.29 applies to all systems developed or acquired. Write a test matrix by system type, listing the test type (static analysis, dependency checks, dynamic testing, configuration review) and the owner. Evidence: the approved matrix, plus pipeline configurations showing each system class is covered.

Vendor upgrades accepted without a security check

Upgrades from vendors often go live after a functional check only, even when they change authentication, encryption defaults or exposed services. Require a documented acceptance step for every new version, covering a security-focused test run, a review of release notes for security changes and sign-off before production. Evidence: acceptance records per release that name the tester, the tests run and the approver.

Scanners run but findings never triaged

Scan output piles up in a dashboard that nobody owns, so findings are neither fixed nor formally accepted. Set severity thresholds that block release, assign an owner to each finding, and record every risk acceptance with a reviewer and an expiry date. Open-source platforms such as Wazuh and Fleet can feed vulnerability data into this workflow for deployed endpoints. Evidence: triage log with owner, decision and closure date for each finding.

Emergency changes skip acceptance

Urgent fixes are pushed straight to production with the promise of a review that never happens. Protected branches in tools such as GitLab can block direct pushes and require merge approval, but emergency paths often bypass them. Define an emergency procedure that still requires a minimum security check, and schedule a retrospective review within a set period. Evidence: emergency change records with a later review sign-off for each one.

Production data copied into test environments

Teams copy production databases into test or staging to get realistic results, which moves personal and confidential data into weaker environments. Under A.8.29, acceptance tests should use synthetic or masked data where possible, and any production copy should be approved, protected and deleted after testing. Related controls A.8.33 and A.8.31 cover the detail. Evidence: test data approval records and deletion confirmations.

Acceptance criteria never written down

Teams test features against functional specifications but never record the security requirements a system must meet, so a passing test has no defined standard to measure against. Link acceptance criteria to the security requirements set under A.8.26, such as authentication, input validation and logging. Ask each system owner to confirm the criteria before testing starts. Evidence: signed acceptance criteria per system, traceable to the tests that verify them.

Questions buyers ask about A.8.29 cost, effort and outside help

How much work does A.8.29 add for a small team?

For a small team, the work is mostly defining a testing process once and then running it on every release, not a large one-time project. The main drivers are how many systems are in scope, how often code ships, how many applications are internet-facing, and whether security requirements already exist for new features. Recurring effort includes triaging scanner findings, retesting fixes, keeping acceptance criteria current and recording results. Ask any consultant to break their quote into defining the process, configuring tools, running the first tests and handing over evidence, so you can see what recurs after the engagement ends.

Can we meet A.8.29 in-house with open-source tools?

Often yes, provided someone owns the process and the tools produce records an assessor can read. Open-source options such as Semgrep Community Edition can run in CI/CD pipelines to scan repositories continuously, and GitLab Community Edition protected branches can restrict who pushes or merges code. Dependency and endpoint vulnerability matching can be covered by tools such as Fleet or Wazuh, though you must confirm each tool's language, platform and rule coverage for your environment. What usually stays hard in-house is independent review of the test design, dynamic testing of running applications and documenting acceptance decisions, so decide early which of these your own staff can perform credibly.

How long does preparing for A.8.29 take?

Preparation length depends on how mature your development life cycle already is, not on a fixed duration. Teams with defined security requirements, a working CI/CD pipeline and recorded release approvals need less time to show a testing process than teams that build releases manually. Other drivers include the number of products, the number of environments, whether acceptance testing is documented for upgrades and third-party software, and how much remediation the first test cycle uncovers. Ask any provider for a written timeline tied to a defined scope, and check which steps depend on your engineering and product teams' availability.

What do engineering and product owners need to commit?

Engineering owns how tests run in the pipeline and how findings are fixed, while product owners define the security requirements that acceptance testing checks against. In practice, engineers need time to triage findings, agree which findings block a release and fix or document them, and product owners need to specify security expectations for new features, upgrades and new versions before development starts. Leadership must approve who can accept risk when a finding remains open. Without these named roles, testing produces reports that nobody acts on, which is the weakness assessors look for first.

Will an auditor accept automated scans alone for A.8.29?

Automated scans are useful evidence but rarely sufficient alone, because A.8.29 asks for security testing to be defined and implemented across the development life cycle, including acceptance against security requirements. An assessor will usually want to see the documented test process, the requirements tested against, scan results linked to specific releases, how findings were resolved or accepted, and who signed off. Scans cover known patterns, so a sound approach also records manual review or penetration testing where risk warrants it. Confirm the expected depth with your certification body before you design the process, since they make the final judgment.

What should we check before hiring an implementation partner?

Check that the partner works from a written scope with agreed deliverables and timelines before work starts, and that it states clearly which parts it prepares and which parts you own. DeployOpen plans and implements open-source platforms inside your own infrastructure, runs security testing, and prepares systems and evidence for compliance assessments, but it does not issue audit reports or certifications; independent auditors and certification bodies do. Ask who will operate the tooling after handover, how evidence is stored in your environment, and whether the partner has any independence conflict with your certification body. Request a quote that separates one-time setup from ongoing support or retainer work.

How DeployOpen scopes and prepares A.8.29 evidence

DeployOpen works on A.8.29 as an implementation partner: it helps define the security testing process, builds the testing pipeline and acceptance gates inside your own infrastructure, and documents the evidence an assessor will ask for. Your organization keeps ownership of the control, and only an independent certification body can issue a certificate.

How we scope

Agree in writing which systems, applications and release paths fall under A.8.29 security testing and acceptance.
Confirm which security requirements from A.8.26 and A.8.28 each acceptance test will check against.
Name the owner who approves acceptance of new systems, upgrades and new versions before work starts.

How we build

Configure repository protections such as GitLab protected branches so that changes to tested code follow the agreed path.
Add static analysis, for example Semgrep in CI/CD, with rules matched to your languages and internal standards.
Set up vulnerability detection for deployed endpoints with Wazuh or Fleet, using a locally hosted vulnerability data source where your environment requires it.

How we hand over

Deliver a written testing procedure, acceptance criteria and a record template for each release gate.
Provide pipeline configuration, scan reports and acceptance sign-offs in the formats your assessor can sample.
Walk your team through the evidence set so your internal owners can run and explain the process after handover.

How we support

Engagements are fixed-scope, so changes to tools or release paths are handled through a written change to scope.
Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Ask your certification body or assessor to confirm which evidence they accept before finalizing the design.