How to Prove Your Systems Are Actually Secure Before You Go Live
ISO 27001 Control 8.29 Security testing in development and acceptance is about one simple idea:
Don’t wait until production to find out where you’re vulnerable.
This control expects you to bake security testing into your development and release process, not bolt it on at the very end or do a one-off pen test for the audit.
It links very closely to:
- 8.25 – Secure development life cycle (how you build and change systems)
- 8.26 – Application security requirements (what “secure” should mean for each system)
- 8.28 – Secure coding (how you actually write the code)
This article turns ISO 27001 Control 8.29 into a practical guide you can use to design – or sanity-check – your approach to security testing.
What ISO 27001 Control 8.29 Actually Expects
In plain English, ISO 27001 Control 8.29 – Security testing in development and acceptance wants you to:
- Run security tests during development, not just functional tests.
- Perform security testing again at integration and acceptance stages.
- Make sure what you test actually matches your security requirements (from 8.26).
- Use an appropriate mix of manual and automated techniques (SAST, DAST, scanning, pen tests, etc.).
- Protect test environments and data, so testing itself doesn’t create risk.
- Apply this to in-house development and third-party/outsourced solutions.
Auditors will typically look for:
- Evidence that security testing is built into your SDLC / change process.
- Testing artefacts: reports, logs, tickets, sign-off records.
- A clear link between security requirements → testing → acceptance criteria.
Step 1 – Define a Security Testing Strategy That Fits Your Risk
Before diving into tools, you need a simple, risk-based strategy:
- Which systems need what level of security testing?
– Public-facing, payment, or personal data systems will need more depth.
– Low-risk internal tools may only need lightweight checks. - When will you test?
– During development (per build or per significant change).
– Before major releases or go-live.
– On a regular cycle (e.g. annual or after major changes) for deeper tests like pen tests. - Who is responsible?
– Development teams for day-to-day security testing in CI/CD.
– Security team or external specialists for independent testing and high-risk systems.
Capture this in a short security testing standard that developers, testers and suppliers can actually follow.
Step 2 – Build Security Testing into Development
This is all about catching issues as early as possible, while they’re cheap to fix.
Typical activities during development:
Static testing and code-centric checks
- Static Application Security Testing (SAST)
– Run on every commit, every build, or at least every merge to main.
– Flag common coding vulnerabilities before code runs anywhere. - Secure code reviews
– Peer reviews with a clear security checklist (auth, access control, error handling, logging, input validation, etc.).
– Extra scrutiny for high-risk components (auth modules, crypto, payment logic). - Dependency and configuration checks
– Use dependency scanning to pick up known issues in third-party libraries.
– Review application and infrastructure config for obvious misconfigurations (default accounts, debug settings, open ports). - Unit and component tests for security features
– Explicit tests that confirm things like:
– “Unauthorised users can’t access this endpoint”
– “Password reset behaves correctly”
– “Encryption functions are called where they should be”
If you’ve documented security requirements (8.26), this is where they start showing up as automated tests and review criteria.
Step 3 – Expand Security Testing at Integration & Acceptance
Once components are joined together, new classes of security issues appear. Here you move from “does this function look safe?” to “does the entire system behave safely?”.
Typical activities:
Dynamic and behavioural testing
- Dynamic Application Security Testing (DAST)
– Test the running application in a realistic environment (test/staging).
– Look for issues such as injection flaws, XSS, insecure redirects, weak session handling. - Penetration testing (where justified)
– For high-risk or externally exposed systems.
– Simulated attacks to see how far an attacker can get and what impact they could have. - Fuzz testing
– Feed random or malformed inputs to APIs or parsers to see how the system responds.
– Useful for protocol-heavy or input-heavy components.
Security-specific scenarios
- Authorisation and privilege escalation tests
– Verify that users can’t gain access to other users’ data or unintended functions.
– Test role changes, “horizontal” access (other users’ records), and “vertical” access (admin functions). - Session management tests
– Check session timeouts, cookie flags, token expiry and logout behaviour.
– Validate protections against session fixation or hijacking. - Integration and third-party tests
– Verify that connections to payment gateways, identity providers, external APIs and cloud services are secure and correctly configured.
This is where you demonstrate that your end-to-end system satisfies ISO 27001 Control 8.29, not just the individual code modules.
Step 4 – Pre-Deployment Security Checks and Acceptance
Before you hit “go live”, have a clear security acceptance gate.
This usually includes:
- Vulnerability scanning
– Automated scanning of the application and infrastructure for known issues.
– Confirm no high or critical vulnerabilities remain unresolved (or that you have documented risk treatment if they must temporarily remain). - Authentication and access control checks
– Confirm the final configuration matches your security requirements.
– Ensure test accounts, backdoors and debug modes are removed or disabled. - Data protection validation
– Encryption in transit enforced (TLS), and in rest where required.
– Logging does not store sensitive data in clear text. - Hardening and configuration verification
– Confirm system, container or cloud hardening baselines are applied.
– Validate network rules, security groups, firewalls and WAF policies. - Logging and monitoring verification
– Ensure that security-relevant events are logged and forwarded to your SIEM or central logging.
– Test that alerts are generated for key conditions (e.g. repeated login failures, blocked access).
Document the security acceptance criteria in advance, and record whether each release or project has met them.
Step 5 – Protect Test Environments and Test Data
Control 8.29 isn’t just about what you test – it also cares about how safely you test.
Pay attention to:
- Environment isolation
– Test and staging environments should be separated from production.
– Access to them should still be controlled – they’re often favoured attacker targets. - Test data management
– Avoid using real personal or sensitive data where possible.
– If production data must be used, anonymise or mask it. - Configuration parity
– Test environments should be close enough to production to give realistic results, especially for security configuration. - Tools and credentials
– Ensure security testing tools don’t leave sensitive data in logs or exports.
– Rotate any credentials used during testing afterwards if they have broad access.
You want to show that security testing reduces risk overall, not that it introduces new exposures.
Step 6 – Use the Right Mix of Tools and Techniques
You don’t need every tool on the market; you need a sensible blend based on your environment and risk.
Common categories:
- Static analysis tools (SAST) – look at code for vulnerabilities.
- Dynamic analysis tools (DAST) – test the running app from the outside.
- Software Composition Analysis (SCA) – highlight vulnerable open-source libraries.
- Infrastructure and cloud scanners – check servers, containers and cloud resources for misconfigurations and missing patches.
- Penetration testing frameworks – used by internal or external testers to manually probe your security.
For ISO 27001 Control 8.29, the important bit is:
- You’ve chosen appropriate tools,
- They’re integrated into your normal processes, and
- You actually act on the findings.
Step 7 – Extend Security Testing to Suppliers and Third Parties
If you’re using third-party or outsourced development, this control still applies – you just enforce it through contracts and acceptance checks.
Good practice:
- Include security testing in contracts
– State that software must undergo defined security testing before delivery.
– Require access to test results and details of any outstanding issues. - Retain the right to test
– Reserve the right to perform your own independent security testing before acceptance. - Agree on remediation expectations
– Define how quickly high and critical issues must be fixed.
– Clarify responsibilities for long-term vulnerability management.
You’re effectively saying: “We don’t accept software as secure just because you say so – we test it.”
Step 8 – Make Security Testing Continuous, Not One-Off
Control 8.29 is not a “pre-certification tick-box”. It fits into a continuous improvement loop:
- In CI/CD pipelines
– Run static analysis, dependency checks and basic dynamic tests automatically.
– Fail or flag builds based on severity thresholds. - On a scheduled basis
– Periodic vulnerability scans and pen tests, especially for high-risk systems.
– Testing after major architectural or functional changes. - After incidents and near-misses
– Add new test cases and checks to prevent recurrence.
– Update your testing strategy based on lessons learned.
This demonstrates that security testing is a living control, aligned with ISO 27001’s broader continual improvement approach.
Quick Implementation Checklist for ISO 27001 Control 8.29
Use this to assess where you stand on security testing in development and acceptance:
- ISO 27001 Control 8.29 (Security testing in development & acceptance) is covered in a documented security testing standard/strategy.
- Security testing is integrated into your SDLC / change process, not handled as an ad hoc activity.
- During development, you use SAST, code reviews and dependency scanning to catch issues early.
- During integration and acceptance, you perform dynamic testing, and where appropriate pen tests, fuzzing and privilege escalation tests.
- Before go-live, you have clear security acceptance criteria, including vulnerability thresholds, access control checks and logging verification.
- Test environments are isolated, access-controlled, and use masked or anonymised data where possible.
- Security testing tools and techniques are chosen based on risk and technology, and findings are tracked and remediated.
- Outsourced or third-party-developed software is subject to security testing requirements in contracts and independent verification before acceptance.
- Security testing is ongoing (CI/CD integration, regular scans, periodic pen tests), not just a one-off before certification.
- Lessons from incidents, findings and new threats feed back into updated test cases and strategy.
Bringing It All Together
ISO 27001 Control 8.29 – Security testing in development & acceptance – is about proving that your systems do what your security requirements say they should before you unleash them on real users and data.
If you:
- Embed security testing into your normal development and release flow,
- Use a sensible mix of tools and manual techniques,
- Protect your test environments and data, and
- Apply the same standards to suppliers and third parties,
you’ll have strong evidence for this control – and a far smaller chance of discovering your biggest vulnerabilities for the first time in production.
Explore the ISO 27001 Control Group Purposes