ISO 27701, Clause 6.11.2 – Security in Development and Support Processes

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

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

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:

1. Licensing, ownership and IP rights (see ISO 27002 Control 5.32).
2. Contractual points that deal with design, coding and testing (see ISO 27002 Controls 8.25 and 8.29).
3. Providing third parties with an up-to-date threat model.
4. Testing requirements, both upon delivery and ongoing – acceptance testing, vulnerability testing, internal malware testing and security assurance reports (see ISO 27002 Control 8.29).
5. Source code safeguards, such as an escrow service that protects against loss of business on the part of the developer.
6. The organisation’s right to audit any development processes.
7. A list of security requirements for the development environment (see ISO 27002 Control 8.31);
8. 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

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.