Building software without testing security is like building a house and only checking if the front door locks after the family has moved in. ISO 27001 Annex A 8.29 (Security testing in development and acceptance) ensures that small businesses catch security flaws when they are cheap to fix—before the software goes live.
For a small business, this control is not about hiring an army of ethical hackers. It is about building simple checkpoints into your development process to ensure your product is safe for your customers.
What is ISO 27001 Annex A 8.29?
Annex A 8.29 requires you to define and implement security testing processes across the entire development lifecycle. The standard states that security testing must be performed during development and acceptance processes.
In simple terms: You must test that your security rules work. If you require a password to be 12 characters long, you must test that the system actually rejects an 8-character password. If you encrypt data, you must verify it is actually unreadable.
Why “Fixing it Later” Destroys ROI
Small businesses often rush to launch, planning to “fix bugs later.” In security, this is dangerous. Fixing a security vulnerability during the design phase costs pennies. Fixing it after a data breach can cost your entire business.
Annex A 8.29 encourages a concept called “Shift Left”—moving testing earlier in the timeline. Instead of waiting for a final “Security Audit” week before launch, you test small pieces of code as they are written.
How to Implement Security Testing on a Budget
You do not need expensive enterprise tools. Here is a practical workflow for small teams:
1. Define Security Acceptance Criteria
Before writing code, define what “secure” looks like. These are your pass/fail conditions.
Example: “The login page must lock an account after 5 failed attempts.”
2. Test During Development
Developers should check their own work against these criteria. Use free or low-cost automated tools (SAST – Static Application Security Testing) to scan code for common errors like SQL injection vulnerabilities as it is being written.
3. Acceptance Testing (The Gatekeeper)
Before software moves from the Test environment to the Live environment, it must pass Acceptance Testing. This includes:
- Functional Testing: Does the button work?
- Security Testing: Does the button allow someone to bypass permissions?
If the security tests fail, the software is rejected. It does not go live. No exceptions.
What to Test: A Simple List for SMEs
If you are unsure where to start, ensure your acceptance testing covers these basics (often based on the OWASP Top 10):
- Authentication: Can I log in without a password? Can I brute-force a password?
- Access Control: Can a regular user access the Admin dashboard by guessing the URL?
- Input Validation: What happens if I type malicious code into the “Contact Us” form?
- Encryption: Is customer data encrypted in the database?
DO IT YOURSELF
STOP SPANKING £10,000s on CONSULTANTS and ISMS ONLINE PLATFORMS
What the Auditor Will Ask
The auditor needs to see that you do not just trust your developers blindly. They want evidence of a process. Be prepared for:
- “Show me the security criteria you defined for this project.”
- “Show me the test results. Did you find any bugs? If so, show me the record of them being fixed.”
- “Show me the formal ‘sign-off’ where a manager accepted the software for release.”
Summary Checklist for SMEs
- Create specific security criteria for every new feature (not just functional criteria).
- Scan code using automated tools during development.
- Perform manual security checks during the User Acceptance Testing (UAT) phase.
- Reject any release that fails critical security tests.
- Keep records of all test results for your audit.
About the author
Stuart Barker is a veteran practitioner with over 30 years of experience in systems security and risk management.
Holding an MSc in Software and Systems Security, Stuart combines academic rigor with extensive operational experience. His background includes over a decade leading Data Governance for General Electric (GE) across Europe, as well as founding and exiting a successful cyber security consultancy.
As a qualified ISO 27001 Lead Auditor and Lead Implementer, Stuart possesses distinct insight into the specific evidence standards required by certification bodies. He has successfully guided hundreds of organizations – from high-growth technology startups to enterprise financial institutions – through the audit lifecycle.
His toolkits represents the distillation of that field experience into a standardised framework. They move beyond theoretical compliance, providing a pragmatic, auditor-verified methodology designed to satisfy ISO/IEC 27001:2022 while minimising operational friction.
