logo

XXX-A.12 Operations Security-1.0

1

COMPANY HEADER

XXX- OPERATIONS SECURITY MANAGEMENT -1.0

Based on ISO 27001:2022 standard

Disclaimer: This document contains confidential and proprietary data and unauthorized use and disclosure of such
information may result in damage or considerable loss to Orgname. The term “Confidential Information” denotes
any and all technical and business information disclosed in any manner or form including, but not limited to,
business strategies, methodologies, trade secrets, pricing, software programs, and relationships with third parties,
client lists and related information, information pertaining to vendors, employees and affiliates. The Confidential
Information shall be held in confidence and shall not be used other than for the purposes intended, and as
specifically stated in the proposal. Further, the Confidential Information may only be released to employees and
persons on a need-to-know basis, who shall be obliged to maintain the information confidential, and the
Confidential Information shall not be released or disclosed to any other third party without the prior written
consent of Orgname.
 logo
XXX-A.12 Operations Security-1.0
2

DOCUMENT INFORMATION

Revision Number 1.0

Document Name Operations Security Management-1.0

Document ID XXX-A.12 Operations Security Management-1.0

Issued Date

Effective Date

Owner Delivery

Reviewed By CISO

Approved By

Document Status

Document Classification Internal(C2)

DOCUMENT HISTORY

Version Approved Date Type of Change Author Reviewed By

Number

1.0 Baseline CISO

 logo
XXX-A.12 Operations Security-1.0
3

CONTENTS
A.5.8 INFORMATION SECURITY IN PROJECT MANAGEMENT 4
A 5.23 Information security for use of cloud services 5
A.8.6 Capacity Management 7
A.8.9 Configuration Management 7
8.15 Logging 8
8.25 Secure Development Life Cycle 9
8.26 Application security requirements 10
8.27 Secure system architecture and engineering principles 11
8.28 Secure coding 11
8.29 Security testing in development and acceptance 13
8.30 Outsourced development 13
8.31 Separation of development, test and production environments 14
8.32 Change management 14
8.33 Test information 15
8.34 Protection of information systems during audit testing 16
 logo
XXX-A.12 Operations Security-1.0
4

A.5.8 INFORMATION SECURITY IN PROJECT MANAGEMENT

Policy
Information security should be integrated into project management.

Purpose
To ensure information security risks related to projects and deliverables are effectively addressed in project
management throughout the project life cycle.

Procedure
Information security IS integrated into project management to ensure information security risks are addressed as
part of the project management.

This is applied to all types of projects regardless of its complexity, size, duration, discipline or application area (e.g.
a project for a core business process, ICT, facility management or other supporting processes).

The project management in <org name> require that:

 information security risks are assessed and treated at an early stage and periodically as part of project risks
throughout the project life cycle;
 information security requirements [e.g. application security requirements, requirements for complying with
intellectual property rights, etc.] are addressed in the early stages of projects;
 information security risks associated with the execution of projects, such as security of internal and external
communication aspects are considered and treated throughout the project life cycle;
 progress on information security risk treatment is reviewed and effectiveness of the treatment is evaluated
and tested.
The appropriateness of the information security considerations and activities should be followed up at predefined
stages by suitable persons or governance bodies, such as the project steering committee.

[PROJECT RISK REGISTER- PAR-Risk Assessment section]

Responsibilities and authorities for information security relevant to the project are defined and allocated to
specified roles.

 The specific controls relevant to the project are identified along with the exclusions with justifications
 Information security requirements are also gathered from the incident reviews, vulnerability management and
contingency plannings that are needed to secure the project / product architecture relevant to the project
environment.
 the required protection needs of information and other associated assets involved, particularly in terms of
confidentiality, integrity and availability;
 the extent of controls required towards the identity of entities in order to derive the authentication
requirements;
 access provisioning and authorization processes, for customers and other potential business users as well as
for privileged or technical users such as relevant project members, potential operation staff or external
suppliers;
 logo
XXX-A.12 Operations Security-1.0
5

 informing users of their duties and responsibilities;

 requirements derived from business processes, such as transaction logging and monitoring,
 non- repudiation requirements;
 requirements mandated by other information security controls (e.g. interfaces to logging and monitoring or
data leakage detection systems);
 compliance with the legal, statutory, regulatory and contractual environment in which the organization
operates;
level of confidence or assurance required for third parties to meet the organization’s information security policy
and topic-specific policies including relevant security clauses in any agreements or contracts.

A 5.23 INFORMATION SECURITY FOR USE OF CLOUD SERVICES

Policy
Processes for acquisition, use, management and exit from cloud services should be established in accordance with
the organization’s information security requirements.

Purpose
To specify and manage information security for the use of cloud services.

Procedure
<Org name> establishes and communicates policy on the use of cloud services to all relevant interested parties.

<Org name> defines and communicates how it intends to manage information security risks associated with the
use of cloud services.

The use of cloud services involve shared responsibility for information security and collaborative effort between
the cloud service provider and the organization acting as the cloud service customer. It is essential that the
responsibilities for both the cloud service provider and the organization, acting as the cloud service customer, are
defined and implemented appropriately.

<Org Name> defines

 all relevant information security requirements associated with the use of the cloud services;

 cloud service selection criteria and scope of cloud service usage;

 roles and responsibilities related to the use and management of cloud services;
 which information security controls are managed by the cloud service provider and which are managed by the
organization as the cloud service customer;
 how to obtain and utilize information security capabilities provided by the cloud service provider;
 how to obtain assurance on information security controls implemented by cloud service provider;
 how to manage controls, interfaces and changes in services when <Orgname> uses multiple cloud services,
particularly from different cloud service providers;
 procedures for handling information security incidents that occur in relation to the use of cloud services;
 its approach for monitoring, reviewing and evaluating the ongoing use of cloud services to manage
information security risks;
 how to change or stop the use of cloud services including exit strategies for cloud services.
 logo
XXX-A.12 Operations Security-1.0
6

For all cloud services, <Org Name> reviews cloud service agreements with the cloud service provider(s). A cloud
service agreement addresses the confidentiality, integrity, availability and information handling requirements of
the organization, with appropriate cloud service level objectives and cloud service qualitative objectives.

<Org name> also undertakes relevant risk assessments to identify the risks associated with using the cloud service.
Any residual risks connected to the use of the cloud service are clearly identified and accepted by the appropriate
management of the organization.

An agreement between the cloud service provider and <Org name>, acting as the cloud service customer, includes
the following provisions for the protection of the organization’s data and availability of services:

 providing solutions based on industry accepted standards for architecture and infrastructure
 managing access controls of the cloud service to meet the requirements of the organization;
 implementing malware monitoring and protection solutions;
 processing and storing the <Orgname> sensitive information in approved locations (e.g. particular country or
region) or within or subject to a particular jurisdiction;
 providing dedicated support in the event of an information security incident in the cloud service environment;
 ensuring that the organization’s information security requirements are met in the event of cloud services
being further sub-contracted to an external supplier (or prohibiting cloud services from being sub-contracted);
 supporting <Orgname> in gathering digital evidence, taking into consideration laws and regulations for digital
evidence across different jurisdictions;
 providing appropriate support and availability of services for an appropriate time frame when <Orgname>
wants to exit from the cloud service;
 providing required backup of data and configuration information and securely managing backups as
applicable, based on the capabilities of the cloud service provider used by the organization, acting as the cloud
service customer;
 providing and returning information such as configuration files, source code and data that are owned by the
organization, acting as the cloud service customer, when requested during the service provision or at
termination of service.

<Org Name>, acting as the cloud service customer, considers whether the agreement should require cloud service
providers to provide advance notification prior to any substantive customer impacting changes being made to the
way the service is delivered to the organization, including:

 changes to the technical infrastructure (e.g. relocation, reconfiguration, or changes in hardware or software)
that affect or change the cloud service offering;
 use of peer cloud service providers or other sub-contractors (including changing existing or using new parties

 The organization using cloud services should maintain close contact with its cloud service providers. These
contacts enable mutual exchange of information about information security for the use of the cloud services
including a mechanism for both cloud service provider and the organization, acting as the cloud service
customer, to monitor each service characteristic and report failures to the commitments contained in the
agreements.

Procedure

 A categorization and prioritization scheme of information security incidents is agreed for the identification of
the consequences and priority of an incident. The scheme includes the criteria to categorize events as
 logo
XXX-A.12 Operations Security-1.0
7

information security incidents. The point of contact assesses each information security event using the agreed
scheme.

A.8.6 CAPACITY MANAGEMENT

POLICY
The use of resources are monitored and adjusted in line with current and expected capacity requirements.

PURPOSE
To ensure the required capacity of information processing facilities, human resources, offices and other facilities.

PROCEDURE

Capacity requirements for information processing facilities, human resources, offices and other facilities are
identified, taking into account the business criticality of the concerned systems and processes.

 System tuning and monitoring are be applied to ensure and, where necessary, improve the availability and
efficiency of systems.

 The <Orgname> performs stress-tests of systems and services to confirm that sufficient system capacity is
available to meet peak performance requirements.

 Detective controls are put in place to indicate problems in due time.

 Projections of future capacity requirements take account of new business and system requirements and
current and projected trends in the organization’s information processing capabilities.
 Particular attention is be paid to any resources with long procurement lead times or high costs. Therefore,
managers, service or product owners monitor the utilization of key system resources.
 Managers use capacity information to identify and avoid potential resource limitations and dependency on key
personnel which can present a threat to system security or services and plan appropriate action.
 Providing sufficient capacity can be achieved by increasing capacity or by reducing demand. The following are
considered to increase capacity:
 hiring new personnel;

 obtaining new facilities or space;

 acquiring more powerful processing systems, memory and storage;

 making use of cloud computing, which has inherent characteristics that directly address issues of capacity.

 Enhanced subscription requirements on Cloud computing has elasticity and scalability which enable on-
demand rapid expansion and reduction in resources available to particular applications and services.
The following is considered to reduce demand on the organization’s resources:
 deletion of obsolete data (disk space);

 disposal of hardcopy records that have met their retention period (free up shelving space);
 decommissioning of applications, systems, databases or environments;
 optimizing batch processes and schedules;
 optimizing application code or database queries;
 logo
XXX-A.12 Operations Security-1.0
8

 denying or restricting bandwidth for resource-consuming services if these are not critical (e.g. video
streaming).

A documented capacity management plan is be considered for mission critical systems.

A.8.9 CONFIGURATION MANAGEMENT

POLICY

Configurations, including security configurations, of hardware, software, services and networks are established,
documented, implemented, monitored and reviewed.

PURPOSE
To ensure hardware, software, services and networks function correctly with required security settings, and
configuration is not altered by unauthorized or incorrect changes.

PROCEDURE
<Orgname> defines and implements processes and tools to enforce the defined configurations (including security
configurations) for hardware, software, services (e.g. cloud services) and networks, for newly installed systems as
well as for operational systems over their lifetime.

Roles, responsibilities and procedures are in place to ensure satisfactory control of all configuration changes.

8.15 LOGGING

POLICY
Logs that record activities, exceptions, faults and other relevant events should be produced, stored, protected and
analysed.

PURPOSE
To record events, generate evidence, ensure the integrity of log information, prevent against unauthorized access,
identify information security events that can lead to an information security incident and to support investigations.

PROCEDURE
<Orgname> determines the purpose for which logs are created, what data is collected and logged, and any log-
specific requirements for protecting and handling the log data. This is documented in this policy on logging.

Event logs include for each event, as applicable:

 user IDs;

 system activities;
 dates, times and details of relevant events (e.g. log-on and log-off);
 device identity, system identifier and location;

 network addresses and protocols.

The following events are considered for logging:

 successful and rejected system access attempts;
 logo
XXX-A.12 Operations Security-1.0
9

 successful and rejected data and other resource access attempts;

 changes to system configuration;
 use of privileges;
 use of utility programs and applications;
 files accessed and the type of access, including deletion of important data files;
 alarms raised by the access control system;
 activation and de-activation of security systems, such as anti-virus systems and intrusion detection systems;
 creation, modification or deletion of identities;
 transactions executed by users in applications. In some cases, the applications are a service or product
provided or run by a third party.
 It is important for all systems to have synchronized time sources as this allows for correlation of logs between
systems for analysis, alerting and investigation of an incident.

Protection of logs
 Users, including those with privileged access rights, do not have permission to delete or de-activate logs of
their own activities as they could potentially manipulate the logs on information processing facilities under
their direct control.

 All logs are protected and reviewed to maintain accountability for the privileged users.

 Controls aim to protect against unauthorized changes to log information and operational problems with the
logging facility including:
o alterations to the message types that are recorded;
o log files being edited or deleted;
o failure to record events or over-writing of past recorded events if the storage media holding a log file
is exceeded.
 Audit logs are archived because of requirements on data retention or requirements to collect and retain
evidence.

 Where <Orgname> needs to send system or application logs to a vendor to assist with debugging or
troubleshooting errors, logs are de-identified where possible using data masking techniques for information
such as usernames, internet protocol (IP) addresses, hostnames or <Orgname> name, before sending to the
vendor.
 If Event logs contain sensitive data and personally identifiable information, appropriate privacy protection
measures are taken.

Log analysis
 Log analysis is done to analyse and interpret the information security events, to help identify unusual activity
or anomalous behaviour, which can represent indicators of compromise.

 Log analysis are supported by specific monitoring activities to help identify and analyse anomalous behaviour,
which includes:
o reviewing successful and unsuccessful attempts to access protected resources [e.g. domain name
system (DNS) servers, web portals and file shares];
o checking DNS logs to identify outbound network connections to malicious servers, such as those
associated with botnet command and control servers;
o examining usage reports from service providers (e.g. invoices or service reports) for unusual activity
within systems and networks (e.g. by reviewing patterns of activity);
 logo
XXX-A.12 Operations Security-1.0
10

o including event logs of physical monitoring such as entrance and exit to ensure more accurate
detection and incident analysis;
o correlating logs to enable efficient and highly accurate analysis.

8.25 SECURE DEVELOPMENT LIFE CYCLE

POLICY
Rules for the secure development of software and systems should be established and applied.

PURPOSE

To ensure information security is designed and implemented within the secure development life cycle of software
and systems.

PROCEDURE
Secure development is a requirement to build up a secure service, architecture, software and system. To achieve
this, the following aspects are considered:

 separation of development, test and production environments

 guidance on the security in the software development life cycle:
o security in the software development methodology;
o secure coding guidelines for each programming language used;
 security requirements in the specification and design phase;;
 security checkpoints in projects;
 system and security testing, such as regression testing, code scan and penetration tests
 secure repositories for source code and configuration;
 security in the version control;

 required application security knowledge and training;

 developers’ capability for preventing, finding and fixing vulnerabilities;

 licensing requirements and alternatives to ensure cost-effective solutions while avoiding future licensing
issues

 Development can also take place inside applications, such as office applications, scripting, browsers and
databases.

8.26 APPLICATION SECURITY REQUIREMENTS

POLICY

Information security requirements should be identified, specified and approved when developing or acquiring
applications.

PURPOSE

To ensure all information security requirements are identified and addressed when developing or acquiring
applications.
 logo
XXX-A.12 Operations Security-1.0
11

PROCEDURE
Application security requirements should be identified and specified. These requirements are usually determined
through a risk assessment. The requirements should be developed with the support of information security
specialists.

Application security requirements include, as applicable:

 level of trust in identity of entities [e.g. through authentication ;
 identifying the type of information and classification level to be processed by the application;
 need for segregation of access and level of access to data and functions in the application;
 resilience against malicious attacks or unintentional disruptions [e.g. protection against buffer overflow or
structured query language (SQL) injections];
 legal, statutory and regulatory requirements in the jurisdiction where the transaction is generated, processed,
completed or stored;
 need for privacy associated with all parties involved;
 the protection requirements of any confidential information;
 protection of data while being processed, in transit and at rest;
 need to securely encrypt communications between all involved parties;
 input controls, including integrity checks and input validation;
 automated controls (e.g. approval limits or dual approvals);
 output controls, also considering who can access outputs and its authorization;
 restrictions around content of "free-text" fields, as these can lead to uncontrolled storage of confidential data
(e.g. personal data);
 requirements derived from the business process, such as transaction logging and monitoring, nonrepudiation
requirements;
 requirements mandated by other security controls (e.g. interfaces to logging and monitoring or data leakage
detection systems);
 error message handling. Transactional services

Additionally, for applications offering transactional services between the <Orgname> and a partner, the following
should be considered when identifying information security requirements:

 the level of trust each party requires in each other’s claimed identity;
 the level of trust required in the integrity of information exchanged or processed and the mechanisms for
identification of lack of integrity (e.g. cyclic redundancy check, hashing, digital signatures);
 authorization processes associated with who can approve contents of, issue or sign key transactional
documents;
 confidentiality, integrity, proof of dispatch and receipt of key documents and the non-repudiation (e.g.
contracts associated with tendering and contract processes);

 the confidentiality and integrity of any transactions (e.g. orders, delivery address details and confirmation
of receipts);
 requirements on how long to maintain a transaction confidential;
 insurance and other contractual requirements.
 Electronic ordering and payment applications
 requirements for maintaining the confidentiality and integrity of order information;

 the degree of verification appropriate to verify payment information supplied by a customer; c) avoidance
of loss or duplication of transaction information;
 logo
XXX-A.12 Operations Security-1.0
12

 storing transaction details outside of any publicly accessible environment (e.g. on a storage platform
existing on the organizational intranet, and not retained and exposed on electronic storage media directly
accessible from the internet);

 where a trusted authority is used (e.g. for the purposes of issuing and maintaining digital signatures or
digital certificates) security is integrated and embedded throughout the entire end- to-end certificate or
signature management process.

8.27 SECURE SYSTEM ARCHITECTURE AND ENGINEERING PRINCIPLES

POLICY

Principles for engineering secure systems should be established, documented, maintained and applied to any
information system development activities.

PURPOSE
To ensure information systems are securely designed, implemented and operated within the Security engineering
principles should be established, documented and applied to information system engineering activities. Security
should be designed into all architecture layers (business, data, applications and technology). New technology
should be analysed for security risks and the design should be reviewed against known attack patterns.
8.28 SECURE CODING

Policy
Secure coding principles are applied to software development.

Purpose
To ensure software is written securely thereby reducing the number of potential information security
vulnerabilities in the software.

Procedure
The <Orgname> has established organization-wide processes to provide good governance for secure coding. A
minimum secure baseline is established and applied. Additionally, such processes and governance are extended to
cover software components from third parties and open source software.

Planning and before coding

Secure coding principles are used both for new developments and in reuse scenarios. These principles are applied
to development activities both within the <Orgname> and for products and services supplied by the <Orgname>
to others. Planning and prerequisites before coding should include:
 organization-specific expectations and approved principles for secure coding to be used for both in-house and
outsourced code developments;

 common and historical coding practices and defects that lead to information security vulnerabilities;
 configuring development tools, such as integrated development environments (IDE), to help enforce the
creation of secure code;
 following guidance issued by the providers of development tools and execution environments as applicable;

o maintenance and use of updated development tools (e.g. compilers);

o Qualification of developers in writing secure code;
 logo
XXX-A.12 Operations Security-1.0
13

o secure design and architecture, including threat modelling;

o secure coding standards and where relevant mandating their use;
o use of controlled environments for development.

During coding
Considerations during coding include:
 secure coding practices specific to the programming languages and techniques being used;
 using secure programming techniques, such as pair programming, refactoring, peer review, security iterations
and test-driven development;
 using structured programming techniques;
 documenting code and removing programming defects, which can allow information security vulnerabilities to
be exploited;
 prohibiting the use of insecure design techniques (e.g. the use of hard-coded passwords, unapproved code
samples and unauthenticated web services).

Testing is conducted during and after development. Static application security testing (SAST) processes can identify
security vulnerabilities in software.

Before software is made operational, the following are evaluated:

 attack surface and the principle of least privilege;

 conducting an analysis of the most common programming errors and documenting that these have been
mitigated.

Review and maintenance

 After code has been made operational:

 updates are securely packaged and deployed;

 reported information security vulnerabilities are handled
 errors and suspected attacks are logged and logs regularly reviewed to make adjustments to the code as
necessary;
 source code is protected against unauthorized access and tampering (e.g. by using configuration management
tools, which typically provide features such as access control and version control).

8.29 SECURITY TESTING IN DEVELOPMENT AND ACCEPTANCE

POLICY
Security testing processes should be defined and implemented in the development life cycle.

PURPOSE
To validate if information security requirements are met when applications or code are deployed to the production
environment.

PROCEDURE

New information systems, upgrades and new versions should be thoroughly tested and verified during the
development processes. Security testing should be an integral part of the testing for systems or components.
 logo
XXX-A.12 Operations Security-1.0
14

Security testing is conducted against a set of requirements, which can be expressed as functional or non-
functional. Security testing includes testing of:
 security functions [e.g. user authentication access restriction and use of cryptography]
 secure coding;
 secure configurations including that of operating systems, firewalls and other security components.

Test plans should be determined using a set of criteria. The extent of testing should be in proportion to the
importance, nature of the system and the potential impact of the change being introduced.

The test plan includes:

 detailed schedule of activities and tests;

 inputs and expected outputs under a range of conditions;

 criteria to evaluate the results;
 decision for further actions as necessary.

8.30 OUTSOURCED DEVELOPMENT

Policy
The <Orgname> should direct, monitor and review the activities related to outsourced system development.

Purpose
To ensure information security measures required by the <Orgname> are implemented in outsourced system
development.

Procedure
Where system development is outsourced, the <Orgname> communicates and agree requirements and
expectations, and continually monitor and review whether the delivery of outsourced work meets these
expectations.

The following points are considered across the organization’s entire external supply chain:
 licensing agreements, code ownership and intellectual property rights related to the outsourced content;

 contractual requirements for secure design, coding and testing practices;

 provision of the threat model to consider by external developers;
 acceptance testing for the quality and accuracy of the deliverables;
 provision of evidence that minimum acceptable levels of security and privacy capabilities are established (e.g.
assurance reports);
 provision of evidence that sufficient testing has been applied to guard against the presence of malicious
content (both intentional and unintentional) upon delivery;
 provision of evidence that sufficient testing has been applied to guard against the presence of known
vulnerabilities;
 escrow agreements for the software source code (e.g. if the supplier goes out of business); i) contractual right
to audit development processes and controls;
 security requirements for the development environment ;
 taking consideration of applicable legislation (e.g. on protection of personal data).
 logo
XXX-A.12 Operations Security-1.0
15

8.31 SEPARATION OF DEVELOPMENT, TEST AND PRODUCTION ENVIRONMENTS

Policy
Development, testing and production environments should be separated and secured.

Purpose
To protect the production environment and data from compromise by development and test activities.

Procedure
The level of separation between production, testing and development environments that is necessary to prevent
production problems should be identified and implemented.

defining, documenting and implementing rules and authorization for the deployment of software from
development to production status;
The following items are considered:
 adequately separating development and production systems and operating them in different
 domains (e.g. in separate virtual or physical environments);
 testing changes to production systems and applications in a testing or staging environment prior to being
applied to production systems;
 not testing in production environments except in circumstances that have been defined and approved;
 compilers, editors and other development tools or utility programs not being accessible from production
systems when not required;
8.32 CHANGE MANAGEMENT

Policy
Changes to information processing facilities and information systems should be subject to change management
procedures.

Purpose
To preserve information security when executing changes.

Procedure
Introduction of new systems and major changes to existing systems should follow agreed rules and a formal
process of documentation, specification, testing, quality control and managed implementation. Management
responsibilities and procedures should be in place to ensure satisfactory control of all changes.

The change control procedures should include:

 planning and assessing the potential impact of changes considering all dependencies;

 authorization of changes;
 communicating changes to relevant interested parties;
 tests and acceptance of tests for the changes;
 implementation of changes including deployment plans;
 emergency and contingency considerations including fall-back procedures;
 maintaining records of changes that include all of the above;
 ensuring that operating documentation and user procedures are changed as necessary to remain
appropriate;
 logo
XXX-A.12 Operations Security-1.0
16

 ensuring that ICT continuity plans and response and recovery procedures are changed as necessary to
remain appropriate.

Production environment includes operating systems, databases and middleware platforms. The controls are
applied for changes of applications and infrastructures.

8.33 TEST INFORMATION

Policy
Test information should be appropriately selected, protected and managed.

Purpose
To ensure relevance of testing and protection of operational information used for testing.

Procedure

Test information should be selected to ensure the reliability of tests results and the confidentiality of the relevant
operational information. Sensitive information (including personally identifiable information) should not be copied
into the development and testing environments.

The following guidelines should be applied to protect the copies of operational information, when used for testing
purposes, whether the test environment is built in-house or on a cloud service:

 applying the same access control procedures to test environments as those applied to operational
environments;
 having a separate authorization each time operational information is copied to a test environment;
 logging the copying and use of operational information to provide an audit trail;
 protecting sensitive information by removal or masking if used for testing;
 properly deleting operational information from a test environment immediately after the testing is complete
to prevent unauthorized use of test information.

Test information should be securely stored (to prevent tampering, which can otherwise lead to invalid results) and
only used for testing purposes.

System and acceptance testing can require substantial volumes of test information that are as close as possible to
operational information.

8.34 PROTECTION OF INFORMATION SYSTEMS DURING AUDIT TESTING

Policy
Audit tests and other assurance activities involving assessment of operational systems should be planned and
agreed between the tester and appropriate management.

Purpose
To minimize the impact of audit and other assurance activities on operational systems and business processes.

Procedure
The following guidelines are observed:
 logo
XXX-A.12 Operations Security-1.0
17

 agreeing audit requests for access to systems and data with appropriate management;
 agreeing and controlling the scope of technical audit tests;
 limiting audit tests to read-only access to software and data. If read-only access is not available to obtain the
necessary information, executing the test by an experienced administrator who has the necessary access
rights on behalf of the auditor;

 if access is granted, establishing and verifying the security requirements (e.g. antivirus and patching) of the
devices used for accessing the systems (e.g. laptops or tablets) before allowing the access;
 only allowing access other than read-only for isolated copies of system files, deleting them when the audit is
completed, or giving them appropriate protection if there is an obligation to keep such files under audit
documentation requirements;

 identifying and agreeing on requests for special or additional processing, such as running audit tools;
 running audit tests that can affect system availability outside business hours;
 monitoring and logging all access for audit and test purposes.