Understanding ISO 27701 Clause 6.11.2 Requirements
Development activities spread over multiple distinct environments represent a significant for organisations that deal with different data categories, and possess a need to move data between testing, development and production environments.
At each stage of the development process, PII and privacy-related assets need to be safeguarded, and afforded the same level of protection regardless of the environment they find themselves in.
What’s Covered in ISO 27701 Clause 6.11.2
ISO 27701 6.11.2 is a wide-ranging control that encompasses multiple aspects of development and testing operations.
ISO 27701 6.11.2 contains no fewer than 9 separate sub-clauses, each of which contains information from ISO 27002 that deals with aspects of development security, presented within the scope of privacy information management and PII security:
- ISO 27701 6.11.2.1 – Secure development policy (ISO 27002 Control 8.25)
- ISO 27701 6.11.2.2 – System change control procedures (ISO 27002 Control 8.32)
- ISO 27701 6.11.2.3 – Technical review of applications after operating platform changes (ISO 27002 Control 8.32)
- ISO 27701 6.11.2.4 – Restrictions of changes to software packages (ISO 27002 Control 8.32)
- ISO 27701 6.11.2.5 – Secure systems engineering principles (ISO 27002 Control 8.27)
- ISO 27701 6.11.2.6 – Secure development environment (ISO 27002 Control 8.31)
- ISO 27701 6.11.2.7 – Outsourced development (ISO 27002 Control 8.30)
- ISO 27701 6.11.2.8 – System security testing (ISO 27002 Control 8.29)
- ISO 27701 6.11.2.9 – System acceptance testing (ISO 27002 Control 8.29)
Two sub-clauses (6.11.2.1 and 6.11.2.6) contain guidance that is relevant to elements of UK GDPR legislation – we’ve provided the articles below, for your convenience.
Please note that GDPR citations are for indicative purposes only. Organisations should scrutinise the legislation and make their own judgement on what parts of the law applies to them.

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.

ISO 27701 Clause 6.11.2.1 – Secure Development Policy
References ISO 27002 Control 8.25
Organisations need to ensure that the development life cycle is created with privacy protection in mind.
To achieve this, organisations should:
- Operate with separate development, testing and development environments (see ISO 27002 Control 8.31).
- Publish guidance on privacy protection throughout the development life cycle, including methodologies, coding guidelines and programming languages (see ISO 27002 Controls 8.28, 8.27 and 5.8).
- Outline security requirements in the specification and design phase (see ISO 27002 Control 5.8).
- Implement security checkpoints in all relevant projects (see ISO 27002 Control 5.8).
- Undertake system and security testing, including code scans and penetration tests (see ISO 27002 Control 5.8).
- Offer secure repositories for all source code (see ISO 27002 Controls 8.4 and 8.9).
- Exercise stringent version control procedures (see ISO 27002 Control 8.32).
- Offer staff privacy protection and application security training (see ISO 27002 Control 8.28).
- Analyse a developers ability to locate, mitigate and eradicate vulnerabilities (see ISO 27002 Control 8.28).
- Document any prevailing or future licensing requirements (see ISO 27002 Control 8.30).
Applicable GDPR Articles
- Article 25 – (1)
Relevant ISO 27002 Controls
- ISO 27002 5.8
- ISO 27002 8.4
- ISO 27002 8.9
- ISO 27002 8.27
- ISO 27002 8.28
- ISO 27002 8.30
- ISO 27002 8.31
ISO 27701 Clause 6.11.2.2 – System Change Control Procedures
References ISO 27002 Control 8.32
Robust change management procedures should be implemented that guarantee the confidentiality, integrity and availability of PII and privacy-related information, both within privacy information processing facilities and privacy information systems.
Organisational change control processes and procedures should include:
- Thorough impact assessments.
- How changes are authorised.
- How changes are communicated to all relevant parties.
- Acceptance testing (see ISO 27002 Control 8.29).
- Change deployment plans.
- Contingency planning.
- A thorough record of all change-related activity.
- Updates to all supporting user and operating documentation, continuity plans and BUDR procedures (see ISO 27002 Controls 5.37 and 5.20).
Relevant ISO 27002 Controls
- ISO 27002 5.20
- ISO 27002 5.37
- ISO 27002 8.29

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.

ISO 27701 Clause 6.11.2.3 – Technical Review of Applications After Operating Platform Changes
References ISO 27002 Control 8.32
See ISO 27701 Clause 6.11.2.2
ISO 27701 Clause 6.11.2.4 – Restrictions of Changes to Software Packages
References ISO 27002 Control 8.32
See ISO 27701 Clause 6.11.2.2
ISO 27701 Clause 6.11.2.5 – Secure Systems Engineering Principles
References ISO 27002 Control 8.27
Organisational system should be designed, documented, implemented and maintained with privacy protection in mind.
Engineering principles should analyse:
- A broad range of security controls that are required to protect PII against specific and generalised threats.
- How well-equipped security controls are to deal with major security events.
- Targeted controls that are distinct to individual business processes.
- Where on the network and how security controls should be implemented.
- How various controls work in harmony with one another.
Engineering principles should take into account:
- Architectural integration.
- Technical security measures (encryption, IAM, DAM etc).
- How well equipped the organisation is to implement and maintain the chosen solution.
- Industry best-practice guidelines.
Secure systems engineering should encompass:
- Well-established industry-standard architectural principles.
- A wide-ranging design review that pinpoints vulnerabilities and helps to form an end-to-end approach to adherence.
- Full disclosure of any security controls that do not meet the expected requirements.
- System hardening.
Organisation’s should default towards a ‘zero trust’ approach to security, by:
- Not relying on gateway security in isolation.
- Continually seeking verification across all systems.
- Enforcing end-to-end encryption across all relevant system.
- Categorising each request for information or access as if it had originated from outside the organisation, from a non-trusted source.
- Operating along the principles of ‘least privilege’, and utilising dynamic access control techniques (see ISO 27002 Controls 5.15, 5.18 and 8.2).
- Always enforcing robust authentication controls, including MFA (see ISO 27002 Control 8.5).
Where the organisation outsources development to third-party organisations, efforts should be made to ensure that the partner’s security principles are aligned with the organisation’s own.
Applicable GDPR Articles
- Article 25 – (1)
Relevant ISO 27002 Controls
- ISO 27002 5.15
- ISO 27002 5.18
- ISO 27002 8.2
- ISO 27002 8.5
ISO 27701 Clause 6.11.2.6 – Secure Development Environment
References ISO 27002 Control 8.31
To safeguard PII and privacy-related assets, organisations need to ensure that development, testing and production environments are segregated and secured.
To achieve this, organisation’s should:
- Segregate different environments in separate domains.
- Build processes that govern how software is moved from development to production.
- Utilise testing and staging environments (see ISO 27002 Control 8.29).
- Prevent testing in production environments.
- Operate strict controls over the use of utility applications in live environments.
- Clearly label each environment across various systems, assets and applications.
- Prevent the copying of sensitive data (especially PII) from the live environment into other environments, without the use of proper controls to safeguard its integrity and availability.
Protecting Development and Testing Environments
To safeguard data in development and testing environments, organisations should:
- Operate with a broad-ranging patching policy.
- Ensure that all systems and applications are securely configured to best practice guidelines.
- Closely manage access to development and testing environments.
- Ensure that any changes to said environments are monitored.
- Enact a wide-ranging set of BUDR protocols.
- Ensure that no single employee is able to make changes to the development and production environments without management review and a thorough approvals process.
ISO makes it explicitly clear that development and testing staff pose a disproportionate risk to PII – either directly due to malicious actions, or inadvertently due to mistakes in the development process.
It is vitally important that no single employee has the ability to make amendments both to and within development and production environments without proper authorisation, including a review of the required changes and multi-step approval (see ISO 27002 Control 8.33).
Organisations should take great care to ensure the integrity and availability of PII throughout the development and testing process, including multiple live production environments, training environments and segregation of duties.
Relevant ISO 27002 Controls
- ISO 27002 8.29

Manage all your compliance, all in one place
ISMS.online supports over 100 standards and regulations, giving you a single platform for all your compliance needs.

ISO 27701 Clause 6.11.2.7 – Outsourced Development
References ISO 27002 Control 8.30
If the need arises to outsource development, organisations need to ensure that the third-parties security practices are in alignment with their own.
Organisations should clearly communicate their requirements from the outset, and continually assess the development partner’s ability to do what is expected of them.
Organisations should consider:
- Licensing, ownership and IP rights (see ISO 27002 Control 5.32).
- Contractual points that deal with design, coding and testing (see ISO 27002 Controls 8.25 and 8.29).
- Providing third parties with an up-to-date threat model.
- Testing requirements, both upon delivery and ongoing – acceptance testing, vulnerability testing, internal malware testing and security assurance reports (see ISO 27002 Control 8.29).
- Source code safeguards, such as an escrow service that protects against loss of business on the part of the developer.
- The organisation’s right to audit any development processes.
- A list of security requirements for the development environment (see ISO 27002 Control 8.31);
- And legislative, regulatory or pre-existing contractual obligations.
Relevant ISO 27002 Controls
- ISO 27002 5.32
- ISO 27002 8.25
- ISO 27002 8.29
- ISO 27002 8.31
ISO 27701 Clause 6.11.2.8 – System Security Testing
References ISO 27002 Control 8.29
Organisations need to ensure that, when code is being deployed and/or moved in any way from a development environment to the live environment, privacy protection is treated as a priority and PII is safeguarded against any loss of integrity or availability.
Testing should include:
- Standardised network security functions (e.g. user login, encryption) (see ISO 27002 Controls 8.5, 8.3 and 8.24).
- Secure coding.
- Secure configurations across all network devices and security components (see ISO 27002 Controls 8.9, 8.20 and 8.22).
Test Plans
All test plans should be directly proportional to the system they’re testing, and the scale of the change or dataset they’re targeted towards.
Testing plans should include a range of automation tools, and be comprised of:
- A comprehensive testing schedule.
- Expected results across a variety of conditions.
- Testing criteria, for evaluation purposes.
- Follow-up actions, based on expected or anomalous results.
In-house development testing should always be verified by a third-party specialist. Such tests should include:
- Security flaw identification (code reviews etc).
- Vulnerability scanning.
- Structured penetration tests.
ISO recommends that all testing should be carried out in an environment that mirrors the production environment in as many ways as is possible, to ensure an accurate and practical series of outputs with which to gauge performance on (see ISO 27002 Control 8.31).
Relevant ISO 27002 Controls
- ISO 27002 8.3
- ISO 27002 8.5
- ISO 27002 8.9
- ISO 27002 8.20
- ISO 27002 8.22
- ISO 27002 8.24
- ISO 27002 8.31
ISO 27701 Clause 6.11.2.9 – System Acceptance Testing
References ISO 27002 Control 8.29
See ISO 27701 Clause 6.11.2.8
Supporting Controls From ISO 27002 and GDPR
ISO 27701 Clause Identifier | ISO 27701 Clause Name | ISO 27002 Requirement | Associated GDPR Articles |
---|---|---|---|
6.11.2.1 | Secure Development Policy | 8.25 – Secure Development Life Cycle for ISO 27002 | Article (25) |
6.11.2.2 | System Change Control Procedures | 8.32 – Change Management for ISO 27002 | None |
6.11.2.3 | Technical Review of Applications After Operating Platform Changes | 8.32 – Change Management for ISO 27002 | None |
6.11.2.4 | Restrictions of Changes to Software Packages | 8.32 – Change Management for ISO 27002 | None |
6.11.2.5 | Secure Systems Engineering Principles | 8.27 – Secure System Architecture and Engineering Principles for ISO 27002 | Article (25) |
6.11.2.6 | Secure Development Environment | 8.31 – Separation of Development, Test and Production Environments for ISO 27002 | None |
6.11.2.7 | Outsourced Development | 8.30 – Outsourced Development for ISO 27002 | None |
6.11.2.8 | System Security Testing | 8.29 – Security Testing in Development and Acceptance for ISO 27002 | None |
6.11.2.9 | System Acceptance Testing | 8.29 – Security Testing in Development and Acceptance for ISO 27002 | None |
How ISMS.online Helps
In order to achieve ISO 27701 you must build a Privacy Information Management System (PIMS). With our preconfigured PIMS you can quickly and easily organise and manage customer, supplier and staff information to fully comply with ISO 27701.
You can also accommodate the growing number of global, regional and sector-specific privacy regulations we support on the ISMS.online platform.
To achieve certification to ISO 27701 (privacy) you must first achieve certification to ISO 27001 (information security). The good news is that our platform can help you do both.
Find out more by booking a hands on demo.