ISO 27001:2022 Annex A 8.29 is the control that requires security testing during development and before acceptance. The control says security testing processes must be defined and built into the development life cycle, so that new systems, upgrades and new versions are checked against their security requirements before they go live.
What Is the Purpose of Annex A 8.29?
The purpose of Annex A 8.29 is to check that applications and code meet their information security requirements when they are released into the production environment. Organisations do this by defining and following a security testing process for new applications, databases, software and code.
Attackers look for flaws such as weak authentication in source code, and they also try to persuade users to take actions that give them access to data or networks. If an application or IT system goes live with vulnerabilities, sensitive information is at risk. Security testing finds and fixes weaknesses in code, networks, servers and applications before systems reach the real world.
Does ISO 27001 Require Penetration Testing?
Not by name. ISO/IEC 27001:2022 does not use the words penetration testing in its clauses or in Annex A. Annex A 8.29 requires defined security testing processes in development, and ISO/IEC 27002:2022 guidance lists penetration testing, alongside code review and vulnerability scanning, as something to consider for in-house development.
Annex A controls are not applied automatically. Under clause 6.1.3 of ISO 27001:2022, an organisation decides which controls it needs to treat its risks, checks that list against Annex A so nothing necessary is missed, and records the result in a Statement of Applicability, with a justification for any Annex A control it excludes.
Penetration testing also appears in the ISO/IEC 27002:2022 guidance for control 8.8 (management of technical vulnerabilities), which suggests planned, documented and repeatable penetration tests or vulnerability assessments carried out by competent, authorised people. The same guidance warns that this kind of testing can itself put a system’s security at risk, which is why tests on live systems need planning and agreement; see protecting systems during audit testing.
So whether you run penetration tests, how often and on which systems is a decision that follows from your risk assessment. A customer doing due diligence may still ask to see a recent test report. For step-by-step guidance, see how to implement Annex A 8.29.
Who Owns Annex A 8.29?
ISO/IEC 27002:2022 does not name a role that owns control 8.29. Each organisation chooses an owner, for example the person responsible for information security, who makes sure a security testing process is set up, kept up to date and applied to all new information systems, whether they are built in-house or by third parties.
ISO 27001 made easy
An 81% Headstart from day one
We’ve done the hard work for you, giving you an 81% Headstart from the moment you log on. All you have to do is fill in the blanks.
What Does Annex A 8.29 Require?
The guidance in ISO 27002 control 8.29 names three areas that security testing should cover:
- Security functions, such as user authentication (Annex A 8.5), access restriction (Annex A 8.3) and the use of cryptography (Annex A 8.24).
- Secure coding (Annex A 8.28).
- Secure configurations (Annex A 8.9, 8.20 and 8.22), including operating systems, firewalls and other security components.
What Should a Test Plan Include?
The amount of testing should match the importance and nature of the system and the possible impact of the change. A security test plan should include:
- A detailed schedule of the activities and tests to be carried out.
- The inputs to use and the outputs you expect under a range of conditions.
- The criteria for judging the results.
- The decision on any further action once the results are in.
The table below is an illustrative example of how those elements can be laid out for a web application. It is not taken from the standard.
| Test | Input | Expected output | Pass criteria | Decision |
|---|---|---|---|---|
| Login lockout | Repeated failed log-ins to one account | Further attempts are blocked | Lockout starts at the agreed threshold and the event is logged | Pass: accept. Fail: raise a ticket, fix and re-test |
| Access restriction | A standard user requests an admin-only page | Access is refused | No admin data is returned and the attempt is logged | Pass: accept. Fail: block release until fixed |
| Cryptography | A connection attempt using an outdated protocol version | The connection is refused | Only approved protocol versions are accepted | Pass: accept. Fail: change the configuration and re-test |
| Secure configuration | Vulnerability scan of the test server | No default accounts or unneeded open ports | No high-severity findings left open | Pass: accept. Fail: fix, re-scan and record the result |
In-House Development
The development team should carry out the first round of security testing to check the system meets its security requirements. Independent acceptance testing should follow, to confirm the system does what it is meant to do and nothing more (see Annex A 5.8).
For in-house development, consider:
- Code reviews to find security flaws, including how the code handles unexpected inputs and conditions.
- Vulnerability scans to find insecure configurations and system weaknesses.
- Penetration tests to find insecure code and design.
Outsourcing
Organisations should follow an acquisition procedure when they delegate development or buy IT components from outside suppliers.
Contracts with suppliers should cover the security requirements the organisation has identified, in line with Annex A 5.20.
Products and services should be assessed against those requirements before they are bought.
How Can Software Teams Put Annex A 8.29 Into Practice?
The standard does not say which tools to use or how often to test. The points below are examples of common practice for software teams, not requirements of ISO 27001.
- Static analysis (SAST): run code analysis tools on each code change, for example as part of the build, so flaws are caught before review.
- Dynamic testing (DAST): scan a running test build before each release to find issues that only show up when the application runs.
- Vulnerability scanning: scan servers, containers and third-party components in the test environment before go-live.
- Penetration testing: plan tests before major releases or significant changes, and at a regular interval set by your risk assessment.
- Evidence to keep: test plans, test reports, tickets for each security defect found and proof that each fix was re-tested. ISO/IEC 27002:2022 guidance says the remediation of security-related defects should be verified.
What Else Does the Guidance Say About Test Environments?
Testing should take place in a test environment that is as close as possible to the production environment the system is going into, so the results are reliable and the system does not bring new vulnerabilities into the organisation. Annex A 8.31 covers keeping development and test environments separate from production.
Organisations can set up several test environments for different kinds of testing, such as functional and performance testing. These environments can be virtual, each configured to simulate a different operating environment.
The test environments, tools and technologies also need to be tested and monitored themselves, so the testing can be trusted. How many layers of these checks are worth doing depends on how sensitive the systems and data are.
Free yourself from a mountain of spreadsheets
Embed, expand and scale your compliance, without the mess. IO gives you the resilience and confidence to grow securely.
What Changed From ISO 27001:2013?
ISO 27001:2022 Annex A 8.29 replaces ISO 27001:2013 Annex A 14.2.8 and 14.2.9 in the newest revision.
| ISO 27001:2013 control | 2013 control name | ISO 27001:2022 control |
|---|---|---|
| Annex A 14.2.8 | System security testing | Annex A 8.29 |
| Annex A 14.2.9 | System acceptance testing | Annex A 8.29 |
For the older controls, see ISO 27001:2013 Annex A 14.2.8 and ISO 27001:2013 Annex A 14.2.9.
Structural Changes
ISO 27001:2022 brings security testing together in one control. ISO 27001:2013 covered it in two controls: System Security Testing (Annex A 14.2.8) and System Acceptance Testing (Annex A 14.2.9).
ISO 27001:2022 Annex A 8.29 Brings More Comprehensive Requirements
In contrast to ISO 27001:2013, the ISO 27001:2022 revision contains more comprehensive requirements and advice on:
- A security testing plan that should include a variety of elements.
- Criteria for assessing security when developing IT systems in-house.
- What should be included in the security testing process.
- Using several test environments for different kinds of testing.
ISO 27001:2013 Was More Detailed in Relation to Acceptance Testing
Contrary to ISO 27001:2022, ISO 27001:2013 was more detailed regarding system acceptance testing. It included security testing for incoming components.
What Are All the ISO 27001:2022 Annex A Controls?
Open each section below for more information on each individual ISO 27001:2022 Annex A control.
| Annex A Control Type | ISO/IEC 27001:2022 Annex A Identifier | ISO/IEC 27001:2013 Annex A Identifier | Annex A Name |
|---|---|---|---|
| Organisational Controls | Annex A 5.1 |
Annex A 5.1.1 Annex A 5.1.2 |
Policies for Information Security |
| Organisational Controls | Annex A 5.2 | Annex A 6.1.1 | Information Security Roles and Responsibilities |
| Organisational Controls | Annex A 5.3 | Annex A 6.1.2 | Segregation of Duties |
| Organisational Controls | Annex A 5.4 | Annex A 7.2.1 | Management Responsibilities |
| Organisational Controls | Annex A 5.5 | Annex A 6.1.3 | Contact With Authorities |
| Organisational Controls | Annex A 5.6 | Annex A 6.1.4 | Contact With Special Interest Groups |
| Organisational Controls | Annex A 5.7 | NEW | Threat Intelligence |
| Organisational Controls | Annex A 5.8 |
Annex A 6.1.5 Annex A 14.1.1 |
Information Security in Project Management |
| Organisational Controls | Annex A 5.9 |
Annex A 8.1.1 Annex A 8.1.2 |
Inventory of Information and Other Associated Assets |
| Organisational Controls | Annex A 5.10 |
Annex A 8.1.3 Annex A 8.2.3 |
Acceptable Use of Information and Other Associated Assets |
| Organisational Controls | Annex A 5.11 | Annex A 8.1.4 | Return of Assets |
| Organisational Controls | Annex A 5.12 | Annex A 8.2.1 | Classification of Information |
| Organisational Controls | Annex A 5.13 | Annex A 8.2.2 | Labelling of Information |
| Organisational Controls | Annex A 5.14 |
Annex A 13.2.1 Annex A 13.2.2 Annex A 13.2.3 |
Information Transfer |
| Organisational Controls | Annex A 5.15 |
Annex A 9.1.1 Annex A 9.1.2 |
Access Control |
| Organisational Controls | Annex A 5.16 | Annex A 9.2.1 | Identity Management |
| Organisational Controls | Annex A 5.17 |
Annex A 9.2.4 Annex A 9.3.1 Annex A 9.4.3 |
Authentication Information |
| Organisational Controls | Annex A 5.18 |
Annex A 9.2.2 Annex A 9.2.5 Annex A 9.2.6 |
Access Rights |
| Organisational Controls | Annex A 5.19 | Annex A 15.1.1 | Information Security in Supplier Relationships |
| Organisational Controls | Annex A 5.20 | Annex A 15.1.2 | Addressing Information Security Within Supplier Agreements |
| Organisational Controls | Annex A 5.21 | Annex A 15.1.3 | Managing Information Security in the ICT Supply Chain |
| Organisational Controls | Annex A 5.22 |
Annex A 15.2.1 Annex A 15.2.2 |
Monitoring, Review and Change Management of Supplier Services |
| Organisational Controls | Annex A 5.23 | NEW | Information Security for Use of Cloud Services |
| Organisational Controls | Annex A 5.24 | Annex A 16.1.1 | Information Security Incident Management Planning and Preparation |
| Organisational Controls | Annex A 5.25 | Annex A 16.1.4 | Assessment and Decision on Information Security Events |
| Organisational Controls | Annex A 5.26 | Annex A 16.1.5 | Response to Information Security Incidents |
| Organisational Controls | Annex A 5.27 | Annex A 16.1.6 | Learning From Information Security Incidents |
| Organisational Controls | Annex A 5.28 | Annex A 16.1.7 | Collection of Evidence |
| Organisational Controls | Annex A 5.29 |
Annex A 17.1.1 Annex A 17.1.2 Annex A 17.1.3 |
Information Security During Disruption |
| Organisational Controls | Annex A 5.30 | NEW | ICT Readiness for Business Continuity |
| Organisational Controls | Annex A 5.31 |
Annex A 18.1.1 Annex A 18.1.5 |
Legal, Statutory, Regulatory and Contractual Requirements |
| Organisational Controls | Annex A 5.32 | Annex A 18.1.2 | Intellectual Property Rights |
| Organisational Controls | Annex A 5.33 | Annex A 18.1.3 | Protection of Records |
| Organisational Controls | Annex A 5.34 | Annex A 18.1.4 | Privacy and Protection of PII |
| Organisational Controls | Annex A 5.35 | Annex A 18.2.1 | Independent Review of Information Security |
| Organisational Controls | Annex A 5.36 |
Annex A 18.2.2 Annex A 18.2.3 |
Compliance With Policies, Rules and Standards for Information Security |
| Organisational Controls | Annex A 5.37 | Annex A 12.1.1 | Documented Operating Procedures |
| Annex A Control Type | ISO/IEC 27001:2022 Annex A Identifier | ISO/IEC 27001:2013 Annex A Identifier | Annex A Name |
|---|---|---|---|
| People Controls | Annex A 6.1 | Annex A 7.1.1 | Screening |
| People Controls | Annex A 6.2 | Annex A 7.1.2 | Terms and Conditions of Employment |
| People Controls | Annex A 6.3 | Annex A 7.2.2 | Information Security Awareness, Education and Training |
| People Controls | Annex A 6.4 | Annex A 7.2.3 | Disciplinary Process |
| People Controls | Annex A 6.5 | Annex A 7.3.1 | Responsibilities After Termination or Change of Employment |
| People Controls | Annex A 6.6 | Annex A 13.2.4 | Confidentiality or Non-Disclosure Agreements |
| People Controls | Annex A 6.7 | Annex A 6.2.2 | Remote Working |
| People Controls | Annex A 6.8 |
Annex A 16.1.2 Annex A 16.1.3 |
Information Security Event Reporting |
| Annex A Control Type | ISO/IEC 27001:2022 Annex A Identifier | ISO/IEC 27001:2013 Annex A Identifier | Annex A Name |
|---|---|---|---|
| Physical Controls | Annex A 7.1 | Annex A 11.1.1 | Physical Security Perimeters |
| Physical Controls | Annex A 7.2 |
Annex A 11.1.2 Annex A 11.1.6 |
Physical Entry |
| Physical Controls | Annex A 7.3 | Annex A 11.1.3 | Securing Offices, Rooms and Facilities |
| Physical Controls | Annex A 7.4 | NEW | Physical Security Monitoring |
| Physical Controls | Annex A 7.5 | Annex A 11.1.4 | Protecting Against Physical and Environmental Threats |
| Physical Controls | Annex A 7.6 | Annex A 11.1.5 | Working In Secure Areas |
| Physical Controls | Annex A 7.7 | Annex A 11.2.9 | Clear Desk and Clear Screen |
| Physical Controls | Annex A 7.8 | Annex A 11.2.1 | Equipment Siting and Protection |
| Physical Controls | Annex A 7.9 | Annex A 11.2.6 | Security of Assets Off-Premises |
| Physical Controls | Annex A 7.10 |
Annex A 8.3.1 Annex A 8.3.2 Annex A 8.3.3 Annex A 11.2.5 |
Storage Media |
| Physical Controls | Annex A 7.11 | Annex A 11.2.2 | Supporting Utilities |
| Physical Controls | Annex A 7.12 | Annex A 11.2.3 | Cabling Security |
| Physical Controls | Annex A 7.13 | Annex A 11.2.4 | Equipment Maintenance |
| Physical Controls | Annex A 7.14 | Annex A 11.2.7 | Secure Disposal or Re-Use of Equipment |
| Annex A Control Type | ISO/IEC 27001:2022 Annex A Identifier | ISO/IEC 27001:2013 Annex A Identifier | Annex A Name |
|---|---|---|---|
| Technological Controls | Annex A 8.1 |
Annex A 6.2.1 Annex A 11.2.8 |
User Endpoint Devices |
| Technological Controls | Annex A 8.2 | Annex A 9.2.3 | Privileged Access Rights |
| Technological Controls | Annex A 8.3 | Annex A 9.4.1 | Information Access Restriction |
| Technological Controls | Annex A 8.4 | Annex A 9.4.5 | Access to Source Code |
| Technological Controls | Annex A 8.5 | Annex A 9.4.2 | Secure Authentication |
| Technological Controls | Annex A 8.6 | Annex A 12.1.3 | Capacity Management |
| Technological Controls | Annex A 8.7 | Annex A 12.2.1 | Protection Against Malware |
| Technological Controls | Annex A 8.8 |
Annex A 12.6.1 Annex A 18.2.3 |
Management of Technical Vulnerabilities |
| Technological Controls | Annex A 8.9 | NEW | Configuration Management |
| Technological Controls | Annex A 8.10 | NEW | Information Deletion |
| Technological Controls | Annex A 8.11 | NEW | Data Masking |
| Technological Controls | Annex A 8.12 | NEW | Data Leakage Prevention |
| Technological Controls | Annex A 8.13 | Annex A 12.3.1 | Information Backup |
| Technological Controls | Annex A 8.14 | Annex A 17.2.1 | Redundancy of Information Processing Facilities |
| Technological Controls | Annex A 8.15 |
Annex A 12.4.1 Annex A 12.4.2 Annex A 12.4.3 |
Logging |
| Technological Controls | Annex A 8.16 | NEW | Monitoring Activities |
| Technological Controls | Annex A 8.17 | Annex A 12.4.4 | Clock Synchronization |
| Technological Controls | Annex A 8.18 | Annex A 9.4.4 | Use of Privileged Utility ProgramsAccess Rights |
| Technological Controls | Annex A 8.19 |
Annex A 12.5.1 Annex A 12.6.2 |
Installation of Software on Operational Systems |
| Technological Controls | Annex A 8.20 | Annex A 13.1.1 | Networks Security |
| Technological Controls | Annex A 8.21 | Annex A 13.1.2 | Security of Network Services |
| Technological Controls | Annex A 8.22 | Annex A 13.1.3 | Segregation of Networks |
| Technological Controls | Annex A 8.23 | NEW | Web filtering |
| Technological Controls | Annex A 8.24 |
Annex A 10.1.1 Annex A 10.1.2 |
Use of Cryptography |
| Technological Controls | Annex A 8.25 | Annex A 14.2.1 | Secure Development Life Cycle |
| Technological Controls | Annex A 8.26 |
Annex A 14.1.2 Annex A 14.1.3 |
Application Security Requirements |
| Technological Controls | Annex A 8.27 | Annex A 14.2.5 | Secure System Architecture and Engineering PrinciplesLearning From Information Security Incidents |
| Technological Controls | Annex A 8.28 | NEW | Secure Coding |
| Technological Controls | Annex A 8.29 |
Annex A 14.2.8 Annex A 14.2.9 |
Security Testing in Development and Acceptance |
| Technological Controls | Annex A 8.30 | Annex A 14.2.7 | Outsourced Development |
| Technological Controls | Annex A 8.31 |
Annex A 12.1.4 Annex A 14.2.6 |
Separation of Development, Test and Production Environments |
| Technological Controls | Annex A 8.32 |
Annex A 12.1.2 Annex A 14.2.2 Annex A 14.2.3 Annex A 14.2.4 |
Change Management |
| Technological Controls | Annex A 8.33 | Annex A 14.3.1 | Test Information |
| Technological Controls | Annex A 8.34 | Annex A 12.7.1 | Protection of Information Systems During Audit Testing |
Why choose ISMS.online for Annex A 8.29?
ISMS.online simplifies the ISO 27001:2022 implementation process. It gives you:
- A cloud-based framework for your ISO 27001:2022 implementation.
- Documentation of your information security management system processes.
- Checklists to work through against accepted standards.
- A head start from the moment you log on: the hard work is done, so you fill in the blanks.
- A way to embed, expand and scale your compliance without the mess.
- The resilience and confidence to grow securely.
To see how ISMS.online can help with your ISO 27001:2022 implementation, book a demo.
FAQs
Can automated tools do all of the security testing?
ISO/IEC 27002:2022 guidance says an organisation can use automated tools, for example tools that analyse code or scan for vulnerabilities, as part of security testing. The same guidance also lists code review for in-house development and independent acceptance testing, so automated tools support the testing process rather than replace the other checks.
Can we be certified to ISO 27001 without a penetration test?
No clause of ISO/IEC 27001:2022 makes penetration testing mandatory. Certificates are issued by accredited certification bodies, not by ISMS.online. If you choose penetration testing as part of meeting Annex A 8.29 or 8.8, keep the test reports and the records of fixes.