Change Management, Test Data, and Log Security with ISO27001 Controls A.8.32-A.8.34

Controls A.8.32 to A.8.34 focus on three often overlooked yet critical areas: how changes are managed, how test information is handled, and how log data is protected. When poorly managed, these areas can introduce serious security gaps, from accidental data exposure in test environments to unauthorised changes and tampered logs that hinder incident investigation. In this post, we break down each control, share practical tips for implementation, and highlight how they contribute to the overall strength and integrity of your ISMS.

A.8.32 Change management

This clause aims to preserve information security when executing changes.

All aspects of your ISMS should have agreed rules and documented processes when changes are made to them. This includes when new systems are introduced to them.

The change control procedures for different systems within your business may differ between departments, or on what systems are changing.

For example, the change control process for releasing changes to a production environment - the deployment process will differ greatly from the process to change documentation within the ISMS – document control, which will differ from managing changes to code in source control – development process. That is even before we consider change process for ICT infrastructure. Where possible, the change control procedures should be integrated.

Fundamentally, change control procedures should include:

Planning and assessing the impact of the changes
Authorisation of the changes
Communicating changes with relevant interested parties
Testing and acceptance of tests as outlined in A.8.29
Plans for implementation of the changes
Emergency, continuity, and contingency plans, including fall-back procedures. This was covered in more detail in control A.5.30.
Maintaining records of changes
Updating documentation and procedures

A.8.33 Test information

The clause has the objective to ensure that you protect the data used for testing.

There are two main elements to this, covering

Data used within testing and non-production environments such as testing, staging and demonstration environments.
Data and artifacts created as a result of system testing.

Data used within testing systems

Security of data should be a consideration when considering what data to use in testing environments.

Ideally, testing data should be “fake” and created for the purposes of testing. Occasionally though, data sourced from production systems can be used for testing. For instance, in replicating issues which can’t be reproduced using other means. However, protections and controls should be in place to protect this data, to ensure that no customer data is inadvertently exposed or put at risk.

Before doing so, any production data should be anonymised, and other integrations into other systems either internal or external removed, or replaced by integrations into testing systems. We have seem companies who use un-anonymised customer data production (including personal information) for developer and internal testing, because they preferred to see real names in their demonstration systems.

Test reports and other testing artifacts

If you capture all your testing in test reports, ensure that they are securely stored but at the same time easily recoverable. This can be done by ensuring access controls are adequate for them.

Development teams and testers may need access to them, should they need to refer to them, but does anyone else really need to access them?

Additionally, and arguably most importantly, you should have controls in place to ensure that any data taken from production systems which may be used for testing is adequately protected, and anonymised where applicable.

A.8.34 Protection of information systems during audit testing

The objective here is to minimise the impact of audit activities on operational systems. This is reasonably straight-forward but can be overlooked.

Before running any audit tests, you should ensure that the appropriate access is agreed, along with the scope of the tests. This is important, as any tests run can have an effect on system availability and performance.

To further limit the risk of having audit data within your system, all audit tests should be done with only read-only access, or executed by authorised, experienced staff who have the appropriate access rights on behalf of the auditor.

All of these activities should be planned, and agreed to by appropriate level of management, with any effects on systems or logging and monitoring of systems considered and addressed where appropriate.