PORT AND TERMINALS + LOGISTICS + BANK

SAP PROGRAM CHANGE MANAGEMENT POLICY AND PROCEDURE NAME DESIGNATION DATE

Approved IT Steercom IT Steercom July 2021

Reviewed Christo Viljoen Group Chief Information Officer

May 2021

Revised Rowena Bisschoff IT Risk and Security Manager

May 2021

Reviewed Roslyn Ferreira Manager: Group Business Applications

July 2020

Approved Exco Exco April 2019

Approved IT Steercom IT Steercom October 2018

Approved Andrew Ehrich Group Chief Information Officer

October 2017 – 2nd Draft Approved

Approved Andrew Ehrich Group Chief Information Officer

16 November 2016 – 1st Draft Approved

Compiled Roslyn Ferreira Manager: Group Business Applications

15 November 2016

1. PURPOSE

This policy is designed to inform and manage SAP system changes by ensuring that formal procedures and adequate controls are in place when planning, initiating, developing, testing, and implementing changes to prevent system downtime, data corruption or loss. This policy should be considered in conjunction with the Grindrod Systems and Software Change Management Policy, the Grindrod SAP Development Standards, and the Grindrod Enterprise Architecture Policy. The primary purpose of this policy is to:

• Manage and control the efficiency of the software development lifecycle (SDLC) of all program changes ensuring that maximum benefit is derived without disruption to business operations and IT services as well as encourage effective communication and collaboration amongst all stakeholders involved.

• Ensure that changes are implemented and maintained in a standardised, secure, repeatable manner with minimal impact to the business.

• Ensure commitment to the delivery of quality services which will be demonstrated through this SAP Program Change Management Policy with the provision of appropriate resources and procedures to manage and maintain services.

PORT AND TERMINALS + LOGISTICS + BANK

012

2. SCOPE This policy applies to all employees, contractors, third parties and service providers of Grindrod, its subsidiaries and joint ventures as appropriate and to all Grindrod, third party and personal devices that are used to access Grindrod networks and data as well as the support staff tasked to support these services. Grindrod makes use of various third parties, both internal and external, in the delivery of services to its customers. Where this involves the operation of a service management process, or a part of the process on behalf of Grindrod, this is identified in the underpinning contract and detailed in the Scope of Work document. In all cases, Grindrod retains the governance of the change management and release management processes by demonstrating:

• Accountability for the processes • Control of the definition of and interface to the processes • Performance and compliance monitoring • Control over process improvements • This will be evidenced by documents and records such as contracts, meeting minutes and performance

reports. The standards and procedures contained in this policy apply to all application components of the SAP system that can be altered or modified in terms of its functionality or operation in meeting the requirements, goals, or objectives of the business. 3. OBJECTIVES

The objective of this policy is to establish awareness and controls to ensure that:

• Clear Project Governance to make sure that changes are managed and implemented as they were defined and agreed to and are aligned to Grindrod Strategic Objectives.

• Projects and program changes do not place the existing environment at risk or negatively impact current business operations.

• Multiple System landscapes exist to develop, test, and manage the changes made to the core systems. • Development teams adhere to IT General Controls and supporting frameworks adopted by Grindrod

Group. • Governance and project learnings are enhanced through the change control process. • Resources are utilised effectively through prior learnings. This includes technical, data and change

resources to ensure that the skillset is retained for follow-up projects. • A support environment is established to utilise skillsets developed from previous projects. • Changes are managed through an understanding of the project build history, design, and the impact of

changes. Change Advisory Board (CAB)

• The Change Advisory Board (CAB) has been established to manage changes to the core system. • The Change control rules that include PMO, Support and senior consultants drive the process. • The Quorum of a CAB shall comprise 50% of business unit representatives.

PORT AND TERMINALS + LOGISTICS + BANK

012

• The Quorum of an emergency CAB shall comprise 50% of business unit representatives. • An emergency electronic CAB (eCAB) shall comprise a minimum of four (4) responses which must include

the system owner.

4. RESPONSIBLE FOR REVIEW

This policy will be maintained by the Manager: Group Business Applications and will be reviewed annually by IT Risk and Security Manager, annually. 5. RESPONSIBLE FOR IMPLEMENTATION

Group Chief Information Officer (CIO)

• The provision of an annual update to the Executive Committee of any deviation or contravention related to this policy that has caused a significant business impact across the Group.

IT Department

• Monitor and report on compliance with this policy. IT Risk and Security Management

• Monitor and report on compliance with this policy. • Provide capability to meet the requirements of this policy. • Implement this policy. • Approve exceptions to this policy.

Head: Group Business Applications

• Shall perform a systematic review of performance on a regular basis to ensure that quality objectives are being met and quality issues are identified through formal audits and management processes. Management review can take several forms including departmental and other management meetings.

• Shall have overall authority and responsibility for the implementation and management of the SAP Configuration Standard, specifically:

• The identification, documentation, and fulfilment of process requirements. • The Implementation, management and improvement of change and release management processes. • The Integration of the change management and release management processes. • Compliance with statutory, regulatory, and contractual requirements. • Reporting to top management on performance and improvement of change and release management

processes. Heads of Department, Regional Support and Business Units

• Are responsible for ensuring that their employees, and any third parties contracted by them are made aware of and adhere to the requirements of this policy.

• Are responsible for ensuring that all relevant processes and procedures include the need to protect the environment from the implementation of unapproved changes.

• Must ensure that development teams adhere to the procedures and standards set out in this policy. • Take appropriate action against any user that is found to have contravened this policy.

PORT AND TERMINALS + LOGISTICS + BANK

012

Employees and third parties • Employees and third parties are responsible for adhering to the requirements of this policy. • All suppliers are responsible for delivering their services in a way that complies with this policy. • Failure to comply with this policy may result in disciplinary action up to and including termination of

employment or contract at Grindrod. 6. POLICY STATEMENTS 6.1 System Development Methodology There are a number of systems development approaches, e.g., waterfall, agile, and unified process. Generally, these approaches follow a systems development life cycle (SDLC), and although the list (and delineation) of SDLC phases or workflows may vary between approaches, it can be generally agreed that the following seven workflows are included within SDLC:

• planning, • requirements gathering and analysis, • design, • implementation, • testing, • deployment, and • operations and maintenance.

These may be structured as linear, sequential phases or within an iterative approach. 6.1.1 Planning Phase

In the planning phase a determination for the need for a new system to meet stakeholder needs is made. The purpose of this workflow is to determine the scope of the problem and come up with potential solutions with an eye to the overall value of the system to the business. Resources, costs, time, and benefits are considered at this stage.

6.1.2 Requirements Gathering and Analysis Phase

The requirements gathering and analysis phase involves the determination of a complete and accurate list of system requirements. This workflow is a process of gathering information, identifying problems, understanding the processes involved and recommending feasible solutions. The result of this phase is a logical design for the system or the change.

6.1.3 Design Phase

In the design phase, using a detailed analysis of the problem situation along with systems requirements, a detailed description of what is needed to solve the problem at hand is produced including inputs, outputs, databases, applications, forms, dependencies, code schemes and processing specifications. This phase transforms the logical design from the requirements gathering and analysis phase into a physical design. The result of this phase should include the defined change request, functional and technical specifications.

6.1.4 Implementation Phase

The implementation phase is where the actual coding and/or configuration of the system takes place to create a working system that solves for the demands of the problem. All code must be reviewed against

PORT AND TERMINALS + LOGISTICS + BANK

012

development standards and have peer review. The result of this phase should include the developed code or solution.

6.1.5 Testing Phase

The testing phase is to ensure the reliability and quality of the system. Here components are integrated and tested to determine whether they perform as expected and achieve the system’s goals. The result of this phase should include the outcome of functional, quality assurance and user acceptance testing.

6.1.6 Deployment Phase

The deployment phase is where the new system is put into production and users are trained. Transition from any existing system to the new system takes place at this time as well as documentation for the system.

6.1.7 Operations and Maintenance Phase The handover to Operations and Support will be done in this phase. During the maintenance phase the system is reviewed for any errors that need correction and needs for future functionality and features are determined on an ongoing basis.

6.2 Normal Change Request or Project Support

6.2.1 The process is initiated by logging a change request which must address the following criteria:

• Requirements • Business purpose • Functional and Technical specifications • Dependencies • Priority to be assessed (e.g., normal change versus emergency change) • Proposed cost and impact (e.g., environment, health and safety, legislation, or security) • Risk assessment

6.2.2 All Stakeholders involved must provide input into the planning and evaluation of the system change by

addressing the following areas: • Design • Scheduling • Communication • Testing • Implementation • Roll-Back

6.2.3 The proposed change must be submitted to the Change Advisory Board (CAB) for review and approval

assessing all aspects of the change request such as: • Business purpose • Function and technical requirements • Dependencies • Cost versus business value • Impact (e.g., environment, health and safety, legislation, or security) • Risks

PORT AND TERMINALS + LOGISTICS + BANK

012

• The configuration of customisable settings (IMG) for the SAP support subproject must be created in the IMG configuration guide. This must be performed by an authorised SAP consultant. Activities are discussed with the lead functional consultant for the area relating to the change.

6.2.4 SAP consultant performs functional testing in DEV and records the testing on the transport form.

6.2.5 A request is emailed to the lead functional consultant for the transport to be moved to QA. The lead functional consultant leader evaluates quality of the work and testing based on the following:

• Relevance to scope of the call/CAB document; • Impact on other projects; and • Ensures config notes are updated and reviews integration testing (cross modular/interface).

6.2.6 Group Business Applications Manager requests move to QA. The transport is done by the basis team.

6.2.7 End user testing is done in QA and checked by the consultant. Results are added to the transport request

document. Exceptions to the rule can be defined by the lead functional consultant and signed off by the Group Business Applications Manager. This is limited to technical changes such as spend categories or changes such as default account assignments.

6.2.8 Group Business Applications Manager or proxy reviews end user testing and full documentation pack and instructs Basis to move to Production. Detail record keeping will then include the call on the transport form, CAB document (this will be a given for all ABAP changes) with functional and technical specifications, test documentation by end user/consultant and a link to the configuration notes. The SAP blueprint document (Configuration document) should be updated for significant changes (where there is a significant deviation from the process) at this point to ensure a living blueprint exists.

6.2.9 The lead functional consultant performs handover to support and operations with consideration to aspects including backup, patching, and capacity management where applicable.

6.2.10 Group Business Applications Manager performs post implementation review of the change ensuring that:

• Change objectives have been met. • Whether the change was effectively managed. • Lessons learnt are acknowledged by the team for future changes. • Actions required to maximise benefit of the change have been identified.

PORT AND TERMINALS + LOGISTICS + BANK

012

Normal Change Request Process

New requirement

identified

Change made

and logged

Log SAP call

CAB

Needed?

CAB

Needed?

CAB

Approved

Change made

and logged

Remove

changes

Transport reviewed by

Technical team / PMO

Final impact

assessment by

Support Manager

Transport reviewed

by

users/consultants

Transport to Production

Transport to Dev / QA

• Transport form

• Config document

• Transport form

• Config document

• CAB Document

• Transport form

• Config document

• All testing • CAB doc

• End user test

• Test • Update

config document

• Added to weekly CAB overview list.

NO

NO

NO

YES

YES

YES

PORT AND TERMINALS + LOGISTICS + BANK

012

6.3 Emergency Change Support • Emergency changes will comply with the normal change procedure as per 1.2, however emergency

changes will be authorised by the system owner prior to implementation. Where the emergency change is for a project, a parallel process will be followed to ensure that the project manager assesses the impact of the emergency change.

• All required supporting documentation for the emergency change (i.e., Transport form, functional and technical specifications, etc) must be completed prior to implementation, exceptional cases may occur where documentation may be completed after implementation.

• At least two approvers are required for emergency changes or their delegates. • Emergency changes are to be presented at CAB. • A list of the transports which have not been approved at CAB must be updated with comments for

subsequent review and approval. • Emergency changes should be reviewed to ensure that all relevant documentation has been prepared to

support the change.

Emergency Change

Development (DEV)

Quality (QAS)

Production (PRD)

Emergency

Requirements Log SAP call

Refer back to

consultant. Emerge

ncy?

Change

applied.

Reviewed by

Technical Team

Transport

reviewed by

users/

consultants.

Assessment by

PMO for Project

/ Governance

impact

• Transport form

• Config document

• All Testing • Call

Details

Transport to Production

Transport to Dev / QA

Reviewed by Support Manager and evaluated. Assumption – Emergency Correction can never be done by a e-CAB.

PORT AND TERMINALS + LOGISTICS + BANK

012

6.4 Governance • All changes and releases will have identified owners to ensure focus on the desired outputs of the

processes and functions. • Enterprise Applications Information Management shall provide service operations (delivery and

management) with the technical capability to conform to the process policy statements. • A formal review will be done once every 12 months by the Policy Governance Team to measure and

report on shortcomings in the processes and procedures. • Informal reviews will be done by the Service and Release Specialists to ensure compliance to this policy

and agreed procedures and that corrective actions are taken to mitigate risks to Grindrod.

6.5 Change Freeze Periods • Change Freeze periods are defined as “No Change” periods. This is to ensure maximum stability and

availability of services during business-critical periods. • Additional approval is needed during a change freeze period and must be accompanied by a motivation.

6.6 Retired Modules

• Modules which are no longer in use must be appropriately retired e.g., the Central User Administration

setup is appropriately de-configured, and any related activities are reviewed on a regular basis. • Field attributes and switches for Central User Administration must be appropriately de-configured and any

related activities are to be reviewed on a regular basis. 7. INTEGRATION WITH ITGC FRAMEWORK This policy integrates with the Grindrod IT General Controls (ITGC) Framework which is aligned to Control Objectives for Information and Related Technology (COBIT). The following ITGC components are covered by this document:

• "SAP FI Application - Program Change Policy and Procedure (COBIT –BAI01.01): Requests for program changes to all software follow a standard change request process. The Program Change Policy and Procedure are reviewed, at a minimum, on an annual basis."

• "Segregated Environments (COBIT –BAI03.07) There is a test and production environment for all financially significant systems. A review of the existence of 2 separate environments is performed on an annual basis."

Three System Landscape Breakdown (ERP) depiction

BW (DEV)

Development

BW (QA)

Quality (QAS)

BW (PRD)

Production (PRD)

Transport layer includes: Ø Dev to QA to PRD Ø ALE layer to follow transport layer Ø Each transport is managed as a sub item of a project Business Warehouse System: Ø Linked to the test system as indicated

PORT AND TERMINALS + LOGISTICS + BANK

012

• "Emergency Change Approval (COBIT –BAI06.02) Emergency change requests are documented and subject to formal change management procedures after implementation."

• "SAP FI Application - Approval for migration to Production (COBIT –BAI07.01) All changes to be migrated to the production environment are approved by an appropriate, authorised individual, as per the change management policy."

• "SAP FI Application - Systems documentation and technical specification are updated (COBIT – BAI07.06) Relevant system documentation and technical specifications must be updated as and when a change occurs."

• "SAP FI Application - User Testing is performed (COBIT –BAI07.05) For system changes. Testing is performed either by users or the SAP support team (dependant on the nature of the change). This testing is documented and signed off prior to go-live.”

8. BREACH OF POLICY Disciplinary action, as set out in the applicable HR Policy and in contracts/ agreements with third parties, will be at the discretion of Grindrod following any non-compliance of this Policy. 9. LEGISLATION AND REGULATORY

This policy has been put in place to ensure compliance with relevant legislation and best practice, including:

• The Electronic Communications and Transactions Act 25 of 2002 • The Companies Act 71 of 2008 • The Protection of Personal Information Act 4 of 2013 • The Promotion of Access to Information Act 2 of 2000 • JSE Listing Requirements • The King IV Report on Corporate Governance • Cybercrimes Bill • Cyber Insurance Requirements

In particular the following aspects of POPIA are addressed through this policy: Condition 7: Security Safeguards Security measures on integrity and confidentiality of personal information Section 19. (1) A responsible party must secure the integrity and confidentiality of personal information in its possession or

under its control by taking appropriate, reasonable technical and organisational measures to prevent— (a) loss of, damage to or unauthorised destruction of personal information; and (b) unlawful access to or processing of personal information.

(2) In order to give effect to subsection (1), the responsible party must take reasonable measures to— (a) identify all reasonably foreseeable internal and external risks to personal information in its possession

or under its control. (b) establish and maintain appropriate safeguards against the risks identified. (c) regularly verify that the safeguards are effectively implemented; and (d) ensure that the safeguards are continually updated in response to new risks or deficiencies in previously

implemented safeguards.

PORT AND TERMINALS + LOGISTICS + BANK

012

(3) The responsible party must have due regard to generally accepted information security practices and procedures which may apply to it generally or be required in terms of specific industry or professional rules and regulations.

Legislative and regulatory compliance is necessary to avoid breaches of legal, statutory, regulatory, or contractual obligations related to information security and of any security requirements, as well as to ensure that information security is implemented and operated in accordance with the organisational policies and procedures. 10. DEFINITIONS

10.1 Change Management The process of controlling modification to software and documentation to ensure that information resources are protected against improper modification before, during and after system implementation. 10.2 Change Advisory Board (CAB) A team responsible for assessing change requests in relation to business need, cost/benefit, viability, and the potential impact to existing systems or processed. The CAB advises the Applications Manager to approve, defer, reject, or cancel changes as well as provide recommendations related to the change implementation. 10.3 Emergency Change A change that is required in response to a critical system malfunction or failure in order to prevent widespread service disruption. 10.4 Project Management Office (PMO) A project management office (PMO) is a group or department that defines, maintains, and ensures project management standards. Responsible for retaining project documentation and offers direction and key metrics in the execution of the Organisations projects.

10.5 Quality Assurance (QA) The assurance provided by Quality management that the developed change meets the intended requirements of the business.

10.6 Client In commercial, organisational, and technical terms, a self-contained unit in an R/3 system with separate master records and its own set of tables. 10.7 EarlyWatch It is a service that entails having your R/3 installation regularly inspected by SAP employees, in other to ensure high system availability and high data throughput at all time. 10.8 Doc (Intermediate Document) An IDoc is a data container for data exchange between SAP systems or between an SAP system and an external system. 10.9 OSS (Online Service System) SAP's Online Service System offers fast and effective help for R/3 System problems. It is also the basic element of communications between customers, partners, and SAP.

PORT AND TERMINALS + LOGISTICS + BANK

012

10.10 Transport It is a request to transport objects from the software development environment, identified as the source system, to the specified target system. 10.11 Workflow It consists of time and logical sequence of work items, which are processed by human agents or mechanical processing units.

10.12 "Auth_Chk" Authorisation Check. This is the validation process that SAP performs, which checks the "User Authorisation Buffer" to determine whether the user has access to the requested authorisation object. 10.13 User Authorisation Buffer "This is a virtual record in memory, detailing the user specific access and authorisations, that is created when the user logs into SAP, to speed up the validation process every time the user attempts to access a transaction or object, as memory is quicker to read than the database. 10.14 SAP Transactions A transaction is an application at application level. Example: Enter an invoice, post a good receipt, Create a confirmation. To go to the initial screen of an application, you can either navigate through the menus by choosing the appropriate menu options or enter the appropriate four-character transaction code in the command field. Example: MIRO = Enter an invoice, using transactions, the data flow is controlled between various application components. 10.15 SAP Authorisation Objects An element of the authorisation concept. Authorisation objects enable you to define complex authorisations by grouping up to 10 authorisation fields in an AND relationship to check whether a user is allowed to perform a certain action. Example: restrict/enable the user to create and/or change and/or display, further restrict users to only certain business areas or plants, etc. To pass an authorisation test for an object, the user must satisfy the authorisation check for each field in the object. 10.16 SAP Roles Roles are collections of activities, i.e., transactions, used in business scenarios. Due to the vast number transactions within SAP and in order to facilitate better access control, individual transactions are not assigned to users. Instead, SAP Roles are created/designed and then assigned to users in order to provide them with access to only a specific collection of transactions, reports, tables, etc. that are required by the user to perform their function and can therefore be restricted accordingly through the use of Authorisation Objects. 10.17 Workflow Sequence of automated logical steps, processed by the SAP System, using the evaluation of conditions to assign work items to approvers based on the hierarchical information flow and corresponding approval process of a company. Example: When a Purchase Requisition (cheque req., journal, etc.) is created in SAP, workflow is activated, thereby sending an SAP notification to the appropriate approvers SAP Inbox (based on the Release Strategies in the Organisational Structure/Hierarchy) informing the approver that the document requires an action, acceptance, or rejection, before any further processing can occur, i.e., posting to the G/L, preparation of a Purchase Order, etc. Workflow is monitored by the workflow manager and can be controlled flexibly with event-related response mechanisms.

PORT AND TERMINALS + LOGISTICS + BANK

012

10.18 Release Strategy A plan defining the release codes with which a purchase requisition item, a complete purchase requisition, or a complete external purchasing document must be released (that is, approved) and the sequence in which release is to be affected using these codes. Example: you can establish a release strategy for all purchase requisitions with a value in excess of a certain figure. 10.19 Release Code A two-character identifier with which a person responsible for processing a document can release (approve) an item of a purchase requisition, a complete purchase requisition, or a complete external purchasing document, or cancel a release (that is, revoke an approval). If a link to SAP Business Workflow has been defined for the release code, the person can refuse to effect release (withhold approval), thus rejecting the item or document. Workflow will then notify the originator of this document of the approvers’ action, for corrective action to be taken. 10.20 ABAP A programming language developed by SAP for application development. All R/3 applications are written in Advanced Business Application Programming (ABAP). 11. RELATED POLICIES, PROCEDURES, FORMS, GUIDELINES, AND OTHER RESOURCES

The following resources support this policy: Corporate Policies/Guidelines/Manuals • Protection of Personal Information (PoPI) Policy • PAIA Manual • POPIA Booklet IT Policies • IT012 - Support • IT014 - Administrative Rights • IT019 - IT Risk Management Charter • IT022 - Information Security Policy • IT031 - Grindrod Change Management Policy • IT032 - Third Party Access and Support Policy • IT025 - Enterprise Architecture Policy 12. DOCUMENT CONTROL

Document No: IT020 Revision No: 01 Previous Revision Date: 20 July 2020 Next Revision Date: May 2022