Environment Business Technology

PORT AND TERMINALS + LOGISTICS + BANK

ENTERPRISE ARCHITECTURE POLICY NAME DESIGNATION DATE

Approved IT Steering Committee IT Steering Committee July 2021

Reviewed Christo Viljoen Group Chief Information Officer June 2021

Compiled Rowena Bisschoff IT Risk and Security Manager June 2021

1. PURPOSE

This policy is designed to enhance Grindrod’s overall alignment of IT and business needs to achieve business strategy by providing Enterprise Architecture (EA) principles and how they should be applied in the business. Enterprise architecture (EA) is the practice of analysing, designing, planning, and implementing enterprise analysis to successfully execute on business strategies. EA assists the business on how to structure IT projects and policies to achieve its desired results and to stay on top of industry trends and disruptions using architecture principles and practices, a process also known as Enterprise Architectural Planning (EAP). These strategies support digital transformation, automation, IT growth, support, and the modernisation of IT as a support department. Enterprise Architecture domains can be represented as layers where each layer delegates work to the layer below. In each layer, the components, the processes, and the services can be defined at a coarse-grained level and decomposed into finer-grained components, processes, and services.

Environment

Business

Data

Information

Technology


012

The Enterprise Architecture (EA) layers can be defined as follows: 1. The Environment Layer is the external entities and activities monitored, supported, or directed by the

business. 2. The Business Layer defines the business strategy and organisation, key business processes, and

governance and standards. Another way of defining it is the business functions offering services to each other and to external entities.

3. The Data layer defines the structure of logical and physical data assets and any related data management resources also known as Business information and other valuable stored data.

4. The Information System Layer defines business applications offering information services to each other and to business functions. This can also be described as the Application systems architecture which provides a blueprint for deploying individual systems, including the interactions among application systems as well as their relationships to essential business processes.

5. The Technology layer describes the architecture of the hardware, software, and network infrastructure necessary to support the deployment of mission-critical applications. The Technology Layer describes the platform applications offering platform services to each other and to business applications.

Many EA frameworks combine data and application domains into a single (digitised) information system layer, sitting below the business (usually a human activity system) and above the technology (the platform IT infrastructure). We believe that separating these out facilitates addressing the surfacing challenges related to data that are in the present and future environment such as data privacy. The lifecycle of data as a commodity is changing rapidly as evidenced by global shifts into the preservation of privacy and the use of aggregated data in machine learning. 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. This policy applies to all Grindrod or Third-Party hosted information system components, including but not limited to Grindrod and personal devices (such as mobile equipment, desktops, and notebooks), cloud solutions, software applications, software utilities and tools. Any data, systems and services that are considered as production, revenue generating components or any component that if it failed or was unavailable would adversely affect business operations must remain under the direct control of Grindrod IT. Exceptions to this policy will require approval by the Grindrod Technology Architecture Board (GTAB). 3. OBJECTIVES

The objective of this policy is to establish awareness, controls and the requirements for software and system architecture design, acquisition and development which can be defined as follows:

• To ensure that the business is aligned with digital transformation strategies and technological growth. • To ensure that Grindrod IT is involved at the inception of projects to guide the business on the correct

process and governance to follow to acquire, maintain and decommission application or infrastructure technology.


012

• To ensure Grindrod avoids duplication of effort, to manage limited funds and resources effectively. • To ensure that long term supportability is planned to support and maintain operations and readiness needs

throughout the lifecycle of the system, technology, or solution at an affordable cost. Upgrade paths must be planned for in advance to address product obsolescence (i.e., legacy systems).

• To create a map of IT assets and business processes and a set of governing principles that drive an ongoing discussion about business strategy and how it can be expressed through technology and innovation.

• To allow more open collaboration between business units and IT. • To give business the ability to prioritise investments and minimise costs such as cyber insurance. • To homogenise security practices to obtain cyber insurance. • To evaluate existing architecture against long-term goals more easily. • To establish processes to evaluate and procure technology. • To provide a comprehensive or holistic view of IT architecture to all business units outside of IT. • To provide a benchmarking framework to compare results against other organisations or standards. • To ensure security requirements are defined. • To ensure appropriate due diligence is performed to validate security controls or other aspects prior to

purchasing software development services, software packages, applications, commercial Off-The-Shelf (COTS) packages and technologies. If the COTS software contains severe security vulnerabilities it can introduce significant risk into an organisation's software supply chain. The risks are compounded when COTS software is integrated or networked with other software products to create a new composite application or a system of systems.

• To ensure that interoperability is possible for the ease of sharing information and services. • To address the risks introduced into the organisation with the often innocent or well-intentioned practice

of Shadow IT. Please see FAQ for a description of Shadow IT • To prohibit the use of shadow IT.

4. RESPONSIBLE FOR REVIEW

This policy will be maintained by the IT Risk and Security Manager and reviewed at a minimum, annually.

5. RESPONSIBLE FOR IMPLEMENTATION Group Chief Information Officer (CIO)

• The provision of an annual update to the Executive Committee of any recording of any incident 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.


012

Change Advisory Board (CAB) • Review and approve change requests. • Ensure that all relevant documentation and criteria for the change have been considered in accordance

with the requirements of this policy. Grindrod Technology Architecture Board (GTAB)

• Involvement at inception of projects in the design and selection stages. • Advise, review, and provide procurement alternatives. • Review and approve change requests. • Ensure that all relevant documentation and criteria for the change have been considered in accordance

with the requirements of this policy. 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.

• Take appropriate action against any user that is found to have contravened this policy. Employees, contractors and third parties

• Employees, contractors 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.

6. POLICY STATEMENTS 6.1 Enterprise Architecture Strategy

Grindrod’s strategy considers the latest innovations in business processes, organisational structure, information systems, security, and technologies. It also recommends standard language and best practices for business processes, including analysing where processes can be integrated or eliminated throughout the organisation. The goal of Grindrod’s Enterprise Architecture Plan (EAP) strategy is to improve the efficiency, security, timeliness, and reliability of business information. EA offers support for re-designs and re-organisation, especially during major organisational changes, mergers, or acquisitions. It brings more discipline into the organisation by standardising and consolidating processes for more consistency. Grindrod also uses EA in system development, IT management and decision-making, and IT risk management to eliminate errors, system failures and security breaches. It can also help businesses navigate complex IT structures or to make IT more accessible to other business units.

6.2 Zero Trust Architecture Strategy

Zero Trust is a security model that helps prevent data breaches by eliminating the concept of trust from an organisation’s network architecture. Based on the principle of “never trust, always verify”, Zero Trust requires all users, even those inside the organisation’s enterprise network, to be authenticated, authorised, and continuously validating security configuration and posture, before being granted or keeping access to applications and data. This approach leverages advanced technologies such as multifactor authentication, identity, and access management (IAM), and next-generation endpoint security technology to verify the user’s identity and maintain system security. Unlike traditional security models that operate on the outdated


012

assumption that everything inside an organisation’s network should be trusted, the Zero Trust architecture model recognises trust as a vulnerability.

Unauthorised software on information systems must be promptly identified and be prevented from executing in accordance with the list of authorised software programs and rules authorising the terms and conditions of usage. Systems must employ a deny-all, allow-by-exception policy to prohibit execution of known unauthorised software. Reviews and updates to the list of authorised software programs must be performed annually. For the Grindrod group to assume its full responsibility of the end-to-end Enterprise Architecture of all Grindrod systems and service platforms, it is required that all new technology acquisition follows the EA process. This will ensure that the appropriate governance body is aware of and approves the acquisition, that the solution adheres to architecture standards, and that all technology is listed in the Application Register. A formal technology assessment will be required for all technology that has a high business impact. Overall business operations are changing, and the goal of enterprise architecture planning is to start with corporate goals and move backwards to the optimal technology solution. This is not just an IT activity, but it gives IT a new role to play within the organisation to harness new technologies such as: • Smart device and mobile emerging technologies will prompt digital transformation. • The initial adoption of cloud computing typically involves the use of a Software as a service (SaaS)

application or migration of an existing system into cloud infrastructure. While these activities present some significant challenges, they are still relatively simple compared to a full transformation into a cloud-first operation. The top challenge for Grindrod as we utilise cloud solutions is integration with existing systems, showing that in-depth planning is needed to maximise the benefits of a cloud strategy.

• Most companies are in the early stages of adoption with Internet of Things (IoT), with few companies actively starting IoT initiatives and most waiting on the side-lines while they build knowledge around the technology. However, it is clear even in these early days that IoT typically starts from a business objective rather than an existing IT practice. This focus on corporate goals along with the broad range of technology needed for a full IoT implementation creates a compelling case for strategic planning.

• Data can be utilised to predict future trends and statistics with the aid of artificial intelligence machine learning branches such as deep learning where an AI function that mimics the workings of the human brain in processing data for use in detecting objects, recognising speech, translating languages, and making decisions. Deep neural learning is also able to learn without human supervision, drawing from data that is both unstructured and unlabelled. Prescriptive analytics which represent the highest form of business analytics by combining statistical data with predictive data can be used in determining the best course of action to achieve specific business objectives.

• By adopting Robotic Process Automation (RPA) businesses can automate routine business processes to streamline business operations and reduce costs. Grindrod has embarked on various projects to utilise RPA to support process integration and workflow.

6.3 Technical Debt

Technical debt conceptualises the trade-off between the short-term benefit of rapid delivery and long-term value. The term can be used to describe gaps which exist in the use, development, acquisition, and retirement of technology, whether it be hardware, software systems or the skills required to support them.


012

As the requirements of Grindrod evolve in respect of its business, customers, supply chain and employees, so to must the technology which supports it. Updated and efficient technology must be identified to support the changing requirements. Investments should be reprioritised in replacing legacy systems, infrastructure, and skill sets. Abandoning obsolete, dysfunctional systems, processes, and methodologies where features have become obsolete or application systems which are no longer supported result in multiple security vulnerabilities. These should be replaced by improved, efficient and more capable upgrades or technology.

6.4 Enterprise Architecture Planning

Enterprise Architecture long-term planning will be a new exercise for most firms. • Only 34% of firms claim to currently build IT architecture strategies beyond a 12-month window.

Although the pace of technology is increasing, it is still difficult to consider far-reaching changes to an IT environment without a broader horizon. Companies cite need for improvement across all four functional areas of IT, and one of the primary benefits of architectural planning is the ability to prioritise investments across different areas.

• To expedite the process and ensure the right level of quality and due diligence, the Grindrod Technology Architecture Board (GTAB) will oversee the execution of the process with support from the Grindrod IT team.

To ensure efficiency of the process, the following guiding principles are to be applied in the design and execution of the process: • Balance the governance according to the scope and impact of the acquisition. • Provide a framework for engagement between regions, business functions, and the approval

authorities. • Follow a business-centric approach to decision making to provide a holistic view on how IT and

technology supports the business. • Balance complex business requirements to make corporate strategy operational. • Ensure new technology aligns with standard architectures to reduce complexity and improve agility. • Consider and create leverage across regions and drive standard operating methods. The solution selected should adhere to the guiding principles of our Enterprise Architecture: • Accelerate our ability to service our clients and manage our business. • Ensure and be part of an end-to-end approach to architecture, technology & data standards & process

frameworks. • Ensure our systems and services are developed in completeness. • Achieve alignment, consistency, inter-operability, and leverage across the group. • Improve investment returns and business agility through architecture approval authorities.

6.5 Architects

In Larger organisations, there may also be separate EA roles having special domain knowledge, such as Business Architect, Application Architect, Information Architect, or Infrastructure Architect.

The Grindrod Technology Architecture Board (GTAB) should comprise of the following roles:


012

• Solutions Architect • Enterprise Architect • Software Architect • Head of Infrastructure • Service Delivery Manager • Senior Engineer • IT Risk and Security Manager • Applications Manager • Vendor Representatives • Specialists – as required.

7. PROCESS 7.1 Overview 7.1.1 The purpose of the EA assessment is to ensure that the solution selected adheres to the guiding

principles of our Enterprise Architecture. 7.1.2 The assessment is conducted in stages for efficiency; a fail fast approach is taken with clear approval

gates at the end of each stage.

7.2 Process Flow

7.3 Assessment Stages 7.3.1 Technology adoption approval request

• Input • A completed Request Form provides input to trigger the Assessment and Approval

process. • Outcomes

• The following outcomes are expected: • The new technology request is logged in the Technology Assessment request register. • A team member is assigned to support the requester through the request process and

prepare assessment documentation. • The request pathway is identified, and the appropriate committee is notified of the

request and expected submission dates. 7.3.2 Technology adoption approval

• Authority • Grindrod Technology Architecture Board (GTAB)

• The appropriate sub-committee of the Grindrod Technology Architecture Board (GTAB) is responsible for the technology adoption approval.

• Scope

REQUEST ASSESS APPROVE


012

• The assessment confirms: • A new technology is required to address the capability identified. • No other technology exists within the current architecture that addresses the capability,

or the current technology implemented does not fulfil the requirement sufficiently anymore and will be retired on implementation of the new technology.

• The overall business case, including price point and benefit to the business, makes business sense.

• The vendor has been endorsed and meets the minimum requirements (e.g., RFQ, BBBEEE, cyber minimum requirements)

• An authorised Grindrod Technology Architecture Board (GTAB) representative counter-signs contract

• Input • A completed EA Assessment template provides input for the decision. The level of detail

required in the assessment is guided by the process support team based on the impact of the technology on the overall architecture. This could be as simple as the initial request, or could require a complete functional, technical and infrastructure review.

• Outcomes • The following outcomes are expected. The impact decision is based on the discretion of the

committee: • Approval - subject to commercial, architecture and risk approval - for high value

technology (all projects > R1m capital expenditure) • Approval - subject to architecture and risk approval - for high impact technology • Approval - subject to risk approval - for low impact technology • Decline or deferred (i.e., the commencement of certain projects may be dependent on

the completion of other projects which need to be prioritised) 7.3.3 High value commercial approval


• Scope • All technology acquisitions with a capital value of more than 200k must be approved by

the Grindrod Technology Architecture Board (GTAB). The Limits of Authority (LoA) provides guidance for the approval of purchases and a representative from Grindrod IT can provide technical input.

• The assessment confirms: • The overall business case, including price point and benefit to the business, makes

business sense. • Input

• A complete business case provides input to the assessment. The process support team will guide the requester to complete the business case.

• Outcome • The following outcomes are expected: • Approval, subject to architecture and risk approval • Decline or deferred (i.e., the commencement of certain projects may be dependent on

the completion of other projects which need to be prioritised) 7.3.4 Architectural approval

• Authority


012

• Grindrod Technology Architecture Board (GTAB) • Scope

• The assessment confirms: • The overall business case, including price point and benefit to the business, makes

business sense. • The technology fits within the architecture strategy without negative impact to other

business critical systems, or • The technology is appropriate to address a short-term capability whilst a long-term

strategy is developed. • All contracts with third party suppliers must be reviewed by Grindrod IT and Legal to

ensure that privacy requirements are appropriately addressed, backout plans are included, data ownership is addressed. Strict termination clauses must be included in terms of the source code.

• Input • A completed EA Assessment template provides input for the decision. The level of detail

required in the assessment is guided by the process support team based on the impact of the technology on the overall architecture. This may require a complete functional, technical and infrastructure review.

• A guideline is required to facilitate software selection for the various business entities. • Outcome

• Approval, subject to risk approval • Decline or deferred (i.e., the commencement of certain projects may be dependent on

the completion of other projects which need to be prioritised) 7.3.5 Risk Approval


• Scope • The risk assessment focuses on various elements such as

• Interoperability, • Procurement and contractual obligations, • Environmental impact, • Legal, regulatory and compliance, • Sustainability, • Data privacy and protection, • Cybersecurity • Vendor risk in terms of supply chain risks

• Outcome • The risk assessments provide recommendations to the Grindrod Technology

Architecture Board (GTAB) as to the suitability of the technology, or any implementation requirements that must be adhered to.

7.4 Decision Validation


• Scope


012

• This gate is the final approval of the technology acquisition. • Input

• Grindrod Technology Architecture Board (GTAB) recommendations • Outcome

• Approve • Decline or deferred (i.e., the commencement of certain projects may be dependent on

the completion of other projects which need to be prioritised) 7.5 Software or Systems Acquisition

• Deviation from a preferred partner must be cleared by the Grindrod Technology Architecture Board (GTAB) during the capex review. This is to provide for beneficial terms such as licensing, warranty, rebates, discounts, and support to be managed through service level agreements (SLA).

• A legal contract must be agreed between the relevant Grindrod Business entity and the Third-Party facilitated by Procurement and Legal. Copyright of or a new license to use new developments must be held by the relevant Grindrod Business entity. Annual reviews of licensing must be performed to ensure that all users are appropriately licensed.

• Third-Party development agreements or package implementation for business-critical systems shall provide a provision to place a copy of the source and executable programs in escrow, based on business requirements. These provisions will allow the organisation to access that escrow should the Third party fail to maintain the software. This will support Grindrod’s continuity requirements.

• Prior to any software or system acquisition, appropriate due diligence that validates the security controls implemented in the software or system must be performed. As a minimum, the following is required:

• Validation that the requirements are met prior to acceptance of any software application or system.

• Validation that any software development has been performed according to industry best practice and followed a secure software development lifecycle.

• Validation that the software development lifecycle includes testing for code errors and common vulnerabilities.

• Validation that any code errors have been fixed. • Validation that the system or software is compatible and complies with other Grindrod

requirements including: • Does not require administrative privileges to run. • External connectivity can be provided through proxied connections. • Authentication of users will integrate with Active Directory. • Encryption is supported where authentication credentials are transmitted, or restricted

and confidential data is in scope. • The application or system can be maintained and supported. • Does not generate excessive network traffic or use high latency protocols.

7.6 Software or Systems Development

• Grindrod IT must be consulted at the start of any new Systems development project or at the start of significant alterations to an existing system. Significant alteration implies a deviation from prior agreed systems architecture.

• Grindrod IT will be responsible for providing leadership and guidance on governance and architectural aspects of the system at the start of any Systems Development effort.


012

• New systems architecture must be presented to the Grindrod Technology Architecture Board (GTAB) for approval. This board will provide guidance via a process of identification of Grindrod duplicate systems, system development synergies, architecture conflicts and architecture best practices.

• A Grindrod IT approved project management (PM) methodology must be followed, and the Group Business Applications Manager must be made aware of the project. The project documentation must be available for Grindrod IT inspection.

• All software or code developed which will run on production systems must be developed according to the Software Development Lifecycle. At a minimum, this plan should address the areas of preliminary analysis or feasibility study; risk identification including business impact assessment and mitigation; communication plan; systems analysis; general design; detail design; development; quality assurance, security testing for common published vulnerabilities, acceptance testing; change control; implementation; roll-back plan and post-implementation maintenance and review. This methodology ensures that the software will be adequately documented and tested before it is used in a “live” environment.

• The normal backup and disaster recovery procedures must be followed prior to implementation to allow for roll-back or recovery procedures.

• Automated tools should be used for security testing of developed code during the software development lifecycle where appropriate.

• All production systems must have designated Owners and Custodians for the information they process. Owners must perform periodic risk assessments of production systems to determine whether the controls employed are adequate.

• All production systems must have an access control system to restrict access to the system as well as restrict the privileges available to users. Role Based Access Control (RBAC) must be in place to assign users to roles based on their organisational functions and determine authorisation based on those roles.

• A designated access control administrator (who is not a regular User on the system in question) must be assigned for all critical systems.

• For a new or enhanced information system, all security requirements must be identified and justified in the requirements phase of the project.

• To prevent loss, modification, or misuse of user data in applications, security control measures must be designed, implemented, and tested. This includes validation of data entry, the internal processing and output data as well as procedures to control the installation of software on operational systems.

• Validation checks are to be incorporated into systems to detect any corruption of information through error or deliberate process.

• Where resources permit, the production, development, and test environments must be separated. This will ensure that security is rigorously maintained for the production system, while the development and test environments can maximise productivity with fewer security restrictions. Where these distinctions have been established, development and test staff must not be permitted to have access to production systems. Developers must not have change access to the production systems and database. Where administration of systems is performed by the company that developed the system, the administration and development must be segregated through the use of separate user accounts.

• Validations must be performed during processing of information and output data must be validated to ensure that data integrity was maintained.

• File names must clearly distinguish between those that contain data for production purposes and those used for testing.

• Access to software source code must be restricted. Business critical applications should assess the level of protection required as part of the risk assessment process, (i.e., escrow protection in case of supplier becoming insolvent).


012

7.7 Shadow IT / Introduction of new IT Grindrod does not encourage the use of Shadow IT to support the current approved network and system infrastructure and software (i.e., including software applications, Cloud solutions, tools, utilities) in place. Any unauthorised software applications and services installed and used with the intent of supporting current and future business strategy (processes and objectives) will be regarded as Shadow IT. Only software applications, cloud solutions and services approved by Business and IT that are managed by Grindrod IT and approved Third-Party service providers shall be used. Please see FAQ for a description of Shadow IT. The principles of IT Governance required by King IV include the responsibility to oversee results of managements implementation (including integration, business resilience, monitoring for responsiveness to cyber security and social media risks, third-party and outsourced service provider risks, value delivered from technology investments and projects, disposal of obsolete technology and information, ethical and responsible use, and compliance with laws). The practice of Shadow IT makes it challenging to adequately govern the IT environment. The following would be considered the use of Shadow IT:

• Use or storage of data on software applications not approved by business and IT management. • An implementation or change of IT which by design obfuscates the presence of a device from Grindrod

IT’s administrative control or sight. • The unnecessary replication or transfer of data which may incur substantial use of resources and

introduces risk. • Using Microsoft credentials to sign up for unapproved applications. • Implementing a hardware or software solution without involving Grindrod IT at the initial planning /

proposal stage. Shadow IT Risks According to research firm Gartner Inc, “by 2020, a third of successful attacks experienced by enterprises will be on their shadow IT resources”. With the increase in remote work, this risk has increased exponentially.

• Third-Party software or applications obtained from the internet or external sources may be laden with malware or spyware which may result in severe consequences to the network and business operations.

• The protection of data is at risk which may result in non-compliance to applicable laws and regulations which may further result in a fine, criminal offence and reputational damage.

• Software applications or procured Cloud solutions may be utilised without the consideration of existing system integrations, system logic dependencies, data complexities and security controls.

• Installed third-party software or applications may not be effectively managed with timely backups, secure and timely decommissioning or an effective vulnerability and patch management programme which may place data and the network at risk of a cyber threat.

Measures to safeguard against Shadow IT:

• No data must be processed, viewed, or amended in unauthorised software or applications. • The installation of software or applications for business or personal use is prohibited, only authorised

software and applications may be installed.


012

• The functionality/access to export or import data from software and applications must be restricted and permitted based on approval or such functionality must be restricted to appropriate users.

• The list of authorised software applications must be reviewed annually and communicated to all business units/users.

• Grindrod IT must utilise network monitoring tools with the aid of firewalls, vulnerability analysis tools and Active Directory group policies or other methods to identify unauthorised software applications, services, or unknown devices.

8. MINIMUM REQUIREMENTS AND EXCLUSIONS At a minimum, all Grindrod suppliers must adhere to the following ISO or quality standards where applicable based on the type of service provided:

9. DEFINITIONS These are a few definitions which are provided for clarity. Shadow IT Refers to information technology infrastructure, software applications (including tools and utilities), web applications and cloud solutions that are used and managed without the knowledge or approval from IT or Business Management. Machine Learning

•Globalorcountryspecificstandardsrelatingtoproductsorservicesrendered.Environment

•Globalorcountryspecificstandardsrelatingtoproductsorservicesrendered.•KingIVCorporateGovernanceoverITPrinciples.Business•POPIARequirements•TheNISTPrivacyFramework:AToolforImprovingPrivacythroughEnterpriseRiskManagement• GrindrodDataclassificationandDataretentionpolicies

Data•MachineLearning•ISO27001InformationSecurityManagementSystems•ISOIEC20000-1ITServiceManagementInformation•IoT-dependentondesignandperlayere.g.IEEE802.15.4forwireless•ISO/IEC11801-1:2017Informationtechnology:GenericcablingforcustomerpremisesTechnology


012

Is an application of artificial intelligence that provides systems with the ability to automatically learn and improve from experience without being explicitly programmed. Retrofitting Risks Retrofitting is updating or adding equipment, sensors, services, new technology or features to existing hardware or older systems so that we are able to make use of new technologies for example, power plant retrofit, improving power plant efficiency, increasing output, or reducing emissions. Many systems that have been retrofitted for compatibility with the Industrial Internet of Things (Industrial Internet of Things - IIoT) are not well protected. Older systems were originally designed to operate in isolation during a time of low cyber-attack risk. Connected devices can create vulnerabilities if substantial security systems are not in place.

10. LEGISLATIVE AND REGULATORY REQUIREMENTS 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 • The Cybercrimes Bill • Cyber Insurance Requirements

In particular the following aspects of POPIA are addressed through this policy Condition 7: Security Safeguards Section 19. - Security measures on integrity and confidentiality of personal information (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. (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.


012

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. 11. RELATED POLICIES, PROCEDURES, FORMS, GUIDELINES, AND OTHER RESOURCES The following resources support this policy: Corporate Policies/Guidelines/Manuals

• Protection of Personal Information Policy • PAIA Manual • POPIA Booklet

IT Policies

• IT012 - Support • IT019 - IT Risk Management Charter • IT022 - Information Security Policy • IT023 - IT Governance Charter

Frameworks supporting EA: The four leading Enterprise Architect Planning (EAP) methodologies: • The Open Group Architectural Framework (TOGAF): TOGAF provides principles for designing, planning,

implementing and governing enterprise IT architecture. The TOGAF framework helps businesses create a standardised approach to EA with a common vocabulary, recommended standards, compliance methods, suggested tools and software and a method to define best practices. The TOGAF framework is widely popular as an enterprise architect framework, and according to The Open Grindrod it has been adopted by more than 80 percent of the world’s leading enterprises.

• The Zachman Framework for Enterprise Architecture: The Zachman framework is named after one of the original founders of enterprise architecture and it is another popular EA methodology. It is better understood as a “taxonomy,” according to CompTIA, and it spans six architectural focal points and six primary stakeholders to help standardise and define the IT architecture components and outputs.

• Federal Enterprise Architecture Framework (FEAF): FEAF was introduced in 1996 as a response to the Clinger-Cohen act, which introduced mandates for IT effectiveness in federal agencies. It was designed for the U.S. government, but it can also be applied to private companies that want to use the framework.

• Gartner: After acquiring The Meta Group in 2005, Gartner established best practices for EAP and adapted them into the company’s general consulting practices. While it is not an individual framework, CompTIA recognises it as a “practical” methodology that focuses on business outcomes with “few explicit steps or components.”

These are four of the most referenced and recognised EA methodologies, but others exist. For example, there is the European Space Agency Architectural Framework (ESAAF), the Ministry of Defence Architecture Framework (MODAF) and the SAP Enterprise Architecture Framework. These frameworks are specifically


012

targeted to individual industries or products, targeting more of a niche market than the more generalised EA methodologies listed above.

12. FREQUENTLY ASKED QUESTIONS (FAQ) The following commonly asked questions are answered here: WHY DO WE NEED ENTERPRISE ARCHITECTURE? Business leaders use many different types of information to make decisions in a dynamic environment. An organisation needs an Enterprise Architect to bring together the enterprise knowledge (vested in its people, policies, and operations), with knowledge of technology to improve the business and enable key decision makers to effectively steer the organisation. Many organisations do not leverage the full power of the data they already have available. The Enterprise Architect serves as both a systems engineer and knowledge management expert who can leverage this untapped potential to bridge the gap between data and decision-making. An Enterprise Architect is a skilled communicator and analyst who can leverage, extract, and develop knowledge for the organisation by linking various enterprise facets such as strategy, operations, finance, supply-chain, customer-support, and technology, and communicates the information in a way that’s useable by key decision-makers. From a Cognitive science foundation, knowledge is of two types: declarative and procedural. Declarative knowledge consists of facts, descriptions, or propositions. Procedural knowledge pertains to the knowledge of “how” and is context specific. It defines the process to use the declarative knowledge in context. It is required to transform declarative knowledge elements into something useful to accomplish the task at-hand. In an Enterprise context, as the declarative knowledge is fragmented across people, technology and strategy, an Enterprise Architecture creates procedural knowledge by bringing clarity through an agreed-upon declarative knowledgebase, and a process by which the entire organisation uses the enterprise’s “declarative” knowledge to perform successfully in a dynamic environment. To date, various Enterprise Frameworks have only attempted to create such a procedure and there exists no standard procedure to bring the organisation’s declarative knowledge to bear for organisation’s true progress and create value out of an EA. WHAT IS SHADOW IT AND WHY IS IT A PROBLEM? Easy access to cloud ‘XaaS’ computing platforms has allowed business functions to utilise applications that have not gone through the traditional route of having been approved/authorised by the Grindrod IT department. This process is often referred to as ‘Shadow IT’. Whilst this activity can bring immediate benefit to the business function, the risk to the Group is two-fold.

1. The likelihood that business functions work in silos, allowing a proliferation of ‘XaaS’ platforms that provide either similar or the same functionality, meaning a disproportionate amount of possibly irrelevant information is shared.

2. The lack of due diligence on both the ‘XaaS’ platform and the underlying vendor, meaning that information may not be secure when stored in the platform.


012

WHAT IS FAIL FAST? Fail fast is a philosophy that values extensive testing and incremental development to determine whether an idea has value. An important goal of the philosophy is to cut losses when testing reveals something is not working and quickly try something else, a concept known as pivoting. WHAT IS ARE THE KING IV PRINCIPLES RELATING TO IT GOVERNANCE? Section 12 of the King IV Corporate Governance Principles sets out the following: 12.1 Set the approach and approve the policy for technology and information governance (including adoption

of appropriate frameworks and standards). 12.2 Delegate to management effective technology and information implementation. 12.3 Oversee results of managements implementation (including integration, business resilience, monitoring

for responsiveness to cyber security and social media risks, third-party and outsourced service provider risks, value delivered from technology investments and projects, disposal of obsolete technology and information, ethical and responsible use, and compliance with laws).

12.4 Oversee management of information (including use, information architecture, protection of privacy and security).

12.5 Oversee management of technology (including technology architecture, sourcing risks, developments, and disruptions).

12.6 Consider receiving periodic, independent assurance on the effectiveness of the technology and information, including outsourcing.

12.7 Disclose overview of governance and management; areas of current and future focus; significant changes, acquisitions, incident management; monitoring and response thereto.

13. DOCUMENT CONTROL Document No: IT025 Creation Date: June 2021 Next Revision Date: June 2022

Environment Business Technology

Documents

Transcript of Environment Business Technology