1. Objective and Scope

The objective of this procedure is to describe purpose and process related to the BFC internal controls (users accesses management, customizing activities, sensitive actions from BFC Administration team…).

Both maintenance and customizing activities must be performed in compliance with internal controls designed with Data Compliance and Audit team and audited twice a year by Solvay external auditors (mid-year and year-end cycles).

 

2. BFC Internal Controls

BFC Administration team is the control owner of the following internal controls: Audit

  •  SEC-01 (APP.05) Password Management
  • SEC-03 (APP.01) Functional Profiles 
  • SEC-04 (APP.10) Access Rights
  • SEC-07 (APP.01) Access Requests 
  • SEC-09 Authorization contact 
  • SEC-10 (APP.03) Audit Trails
  • SEC-11 (APP.02) Users Deactivation
  • PPC-Maintenance controls (APP.10)


2.1 SEC-01 (APP.05) Password Management

Purpose: Check the compliance of BFC users passwords with Solvay Security policy 

This Control is restricted to “Internal Users” (authentication type "internal") as “External Users” (authentication type "external") are using the Single Sign On.

Description: The BFC Administration team reconciles an extract of password settings from the BFC_Production system and the password guidelines included in the security policy: all the directives must be respected.

Control type: (Completeness, Accuracy, Validation, and Restricted Access): Completeness, Accuracy and Restricted Access

Frequency: Yearly (when Solvay’s password policy changes)

Note: use of special characters (such as @ #) can not be forced as it prevents users to use retrieves of BFC figures in Excel


Control evidence: 

In “Action” menu / “Password Manager” option, the BFC Administration team defines length of Internal password as well as their validity duration. 

After 90 days using the same password, BFC will automatically oblige the Internal user to change his / her password. Without this renewal, the Internal user cannot connect anymore to BFC.

 



  • The Single Sign On enables users to use their Solvay personal login and password (the one used to connect to their computer) to connect also to BFC. 
  • When they will change their Windows password, it will be automatically taken into account by BFC too.

Evidence stored in GDrive: https://drive.google.com/drive/folders/1GI_ZB6EsHhhHrVKSolXdjofT3ip0LFNI


2.2 SEC-03 (APP.01) Functional Profiles

Purpose: All the Functional Profiles creation/modification requests are formally validated by the GAR Consolidation Manager (appointed as KUF = Key User Function).

Description: The BFC Administration team, before updating the role into the system, checks manually the presence of incompatibilities in the role design, according to the matrix of incompatible actions. In case of some incompatibilities are found he/she informs the Consolidation Manager (KUF) who validates them.

A functional profile defines the types of rights to perform specific tasks in the application. For example, whether or not a user is authorized to create, change or delete data in schedules. 

The major risk to be managed is to avoid to introduce in Functional profiles (through creation / modification) incompatible rights without any authorization from KUF.

Control type: (Completeness, Accuracy, Validation, and Restricted Access): Validation, Accuracy

Frequency: On Flow, ie everytime there’s a need to change or create a functional profile


A) Functional Profiles created in BFC since its implementation in 2005


B) Functional Profiles currently used (31/05/2022)


C) Description of Functional Profiles currently used (31/05/2022)


Evidence stored in GDrive: https://drive.google.com/drive/folders/19Dc-vvsciksgLYn2UK4uYbuZbLyxGdw2


2.3 SEC-04 (APP.10) Access Rights

Purpose: Matrix of incompatible transactions by critical level is maintained and updated in order to include each new critical transaction.

Description: The file “IT FC SEC-04 Access Rights 2022” is a validation of the updated matrix of incompatibilities by the Key User Function (Consolidation manager):

  1. The "Responsibilities Matrix" tab is a Description of the Functional Profiles that are used in BFC.
  2. The content in BFC is validated at each Audit Sprint to check if the Functional Profiles are correctly implemented in the system.
  3. This matrix is signed by the Consolidation Manager (KUF), scanned and published in Google Drive each time there's an update (change or creation of a functional profile) generation a new version.

The "Functional Profiles Definitions" tab is a detailed description of the Functional Profiles.

Control type (Completeness, Accuracy, Validation, and Restricted Access): Validation

Evidence stored in GDrive: https://drive.google.com/drive/folders/1cZ5Dm7QTzifrxoy6yjRXabrdURMwPlo2


Frequency: On Flow, ie each time we change or create a functional profile (consistent with SEC-03)


2.4 SEC-07 (APP.01) Access Requests 

Purpose: Access rights given to users are formally validated by the BFC Administration team. 

Description: Access requests are sent by e-mail or BMC Helix ticket (transferred by IS BFC Admin) to the BFC-Admin mailbox, normally the request is performed by the user with his/her manager in copy (manager as defined in Solvay One Organizational chart).

Important Notes:

  • If the manager is not in copy (it happens often with the transferred tickets), the BFC Administration team must request his/her approval before communicating the access given. 
  • To check the user's manager or missing details like User ID, email, BFC Admin can use SuccessFactors (Solvay HR) application / "Org Chart" section through this link https://performancemanager.successfactors.eu/:


  • Any request requiring access to critical data (Administrators and users requiring access to owner groups CONSO or CONSO+) or critical actions (Administrators and users requiring access to functional profile CONSOLIDEUR) must be approved by the Consolidation Manager (KUF) => SEC-03 & SEC-04.
  • Since the implementation of the Single Sign On, before creating a new user, the BFC Administration team must request IT team through ticket in Service One to add this new user to the Active directory (AD)  - “BFC User Group”  - refer to the following procedure Users access Management in BFC-6.REQUEST TO ADD THE USER IN THE ACTIVE DIRECTORY GROUP
  • Active directory (AD) is a list of all Solvay users’ accounts (but also computers, servers, printers, shared directories…). It authenticates and authorizes all users and computers by assigning and enforcing security polices, installing and updating software... For example:  when user logs into a computer, AD checks the submitted password and determinates whether the users is a system administrator or a regular user.


Control type: (Completeness, Accuracy, Validation, and Restricted Access): Validation and Restricted Access

Frequency: On demand @ each user access request

Evidence stored in GDrive: https://drive.google.com/drive/folders/1eGfCz_979YQ-M4EW3KDpFNCXKugxZuls


2.5 SEC-09 Review of sensitive accesses

Purpose:  Users list with sensitive accesses is reviewed by conso manager before each quarter closure

Description: Although accesses are granted upon managers approval (in case of sensitive accesses upon Consolidation manager approval as well) and users deactivation occurs on a regular basis the users list with sensitive accesses (access to change data at conso level) is reviewed by conso manager before each quarter closure. The aim of this control is to not keep sensitive accesses no longer needed to users who have changed their role.


Control type: (Completeness, Accuracy, Validation, and Restricted Access): Validation and Restricted Access

Frequency: Quarterly 

Validation process:

  1. BFC Administration team sends a screen copy of users granted role ""CONSOLIDEUR"" or ""CONSO-SAISIE" or "ADMIN" by e-mail to GAR Consolidation manager requesting his review and approval 
  2. GAR Consolidation manager's answer with validation and/or request for necessary authorization updates, is sent back to BFC Administration
  3. BFC Administration team proceeds with updates, when needed, in the system and resent the print screen with new updated list of users to Consolidation manager

Evidence stored in GDrive: https://drive.google.com/drive/folders/14oLPoNU-cUuCIE6a0fxK5XPsgr1JHQPD


ADDITIONAL QUARTERLY PROCESS - INSIDER DEALING (FSMA)

  • The Insider dealing list (requested by FSMA authorities in Belgium) is requested by CORPORATE SECRETARY to the BFC Administration team.
  •  BFC Admin team is not the owner of this control but has to provide, each quarter, the information regarding BFC users having privileged access to financial data.
  • BFC Administrator has to extract users having access to full Solvay Group data (access groups = CONSO / CONSO+ / ADMINISTRATORS) and update this GSheet file shared by Corporate Secretary adding the new users and removing the old ones (people who have changed position or left the group), informing the date on which data access was added/removed and to which organizational department belongs to. 


2.6 SEC-11 (APP.02) Users Deactivation 

Purpose 1: Deactivation done on a regular basis for leavers and movers.

Description: The Solvay Group members who have access to BFC should be compliant with their status and their position on HR tools. The objective of this Internal Control is to reconcile the users status on BFC according to their HR status and identify the users that should be deactivated from BFC. 

Deactivation is done based on the lists provided by IT Internal Control team (Risk and Compliance):

  • every week for leavers
  • every month for movers.


Leavers process (Internals & Externals) - weekly

  • BFC leavers lists are produced every week by robot, reviewed and sent by the IT Internal Control team  to BFC Administration team by email. 
  • In addition to the identification of users to be deactivated the list includes verification of last logon date versus separation date. 
  • BFC Admin proceeds with the user's deactivation as soon as possible within a week.


Movers - monthly

  • List is sent by IT Internal Control team  to BFC Admin on a monthly basis.
  • BFC Admin analyses the list to identify which users should be subject to access updates. Some may have already requested the update.
  • Following the analysis BFC Admin sends an email to the user with his/her manager in cc asking if the BFC access could be deactivated or not. 


Evidence stored in GDrive: https://drive.google.com/drive/folders/1-rNxb171Sv2R7VsMEJV1K8r4QevYZLlf


In BFC “Security/Users” module, deactivation will be proceeded the following in the user profile:

  • Owner Group: PARTI or INTER-MOVERS
  • Functional Profile: DESACTIVE 
  • Data Access Group: RIEN

and the user must be blocked in order to be prevented from accessing BFC.


Control type: (Completeness, Accuracy, Validation, and Restricted Access): Validation and Restricted Access

Frequency: Weekly (leavers) / Monthly (movers)


Purpose 2: Temporarily deactivation on BFC when the user has not connected during the last 6 months

  • When the user has not connected during the last 6 months his/her access has to be temporarily deactivated on BFC. Note that on GUDSIS the status may be still ACTIVE, but the user can have a new position that doesn´t request the access to BFC so frequently; temporary leave (maternity, sickness) can also justify those cases. Before deactivating a user without any connection during the last 6 months, BFC Administration team sends an email to those users asking them to logon to BFC within the next 7 days in order to retain their accounts.
  • Frequency : early June / early December
  • Message sent to users prior to deactivation:

Dear Colleague,

Please note that your account for accessing the BFC application has been inactive for more than 6 months. If you have lost the access link, you may connect to BFC by copying and opening this URL https://financialconsolidation.solvay.com/FCPROD/

To avoid disruption of your accountkindly login to BFC within the next 7 days to retain your account. Account will be suspended without further notice thereafter. If your account is being suspended, you may re-submit your access request to $SBS FinanceSL Fin Acc SU BFC Admin  

  *Please ignore this message if you have connected to BFC before receiving it  

  • In BFC “User” module, if the user has still not connected 7 days after the reception of the above message, his/her profile will be updated as follows:
    • Owner Group: NET
    • Functional Profile: No change
    • Data Access Group: No change
    • and the user must be blocked in order to be prevented from accessing BFC.


Exceptions

 “TINSTALL user”: 

The user TINSTALL must remain always active

  • This user ID is the one used by SBS IS Infra teams to test that the technical installation of BFC application on users’ PC is correct.
  • Note that this user only contains rights to connect to BFC application, without any other rights to modify any objects or to display any data. 

“ADMIN user”: 

The user ADMIN must remain always active

  • Admin is a special, technical user, it is created automatically when BFC application is installed and database created. Some administrative tasks can be performed only by Admin User, mostly related to application installation and upgrade


Evidence stored in GDrive: https://drive.google.com/drive/folders/1-rNxb171Sv2R7VsMEJV1K8r4QevYZLlf


2.7 SEC-10 (APP.03) Audit Trails 


Purpose: Audit trails on critical activities (deletion of objects) on a regular basis to ensure that all the actions made are justified.

Description: This control traces the sensitives actions in the PRODUCTION environment performed by:

  • Users with ADMINISTRATION functional profiles (full rights & restricted rights): ADMIN / ADM-xxx / ADM-LEGER
  • Users with IT functional profiles
  • Users having double accesses to BFC (2 logins)
  • Users ID starting with TESTxx and user TINSTALL


As we have several controls checking that people access are justified: initial approval manager (+ conso manager if critical accesses); regular leavers & movers report; quarterly review for the most critical ones, we consider that critical actions are the deletion of objects.


Note that IT/TEST/TINSTALL profiles don’t have a significant impact in terms of modifications in BFC:

  • The IT profile has access to all the data, however only in consulting mode;
  • TINSTALL user has no access to change any objects or to access to any data;
  • TESTxx users are only activated on demand by BFC Administration to solve issues raised by BFC end users (eg “I can not see packages”, “I can not see this x company in my list”…). TESTxx user is temporarily activated with the same rights than the requestor to experience/see the same. Once issue solved, the TEST user is deactivated.


Control Report Process

  1. IT BFC Admin extracts a SQL List - "Even report" from Log module;
  2. This list contains all actions performed (who and when);
  3. Actions considered critical have to be identified;
  4. Once the list is restricted to these critical actions, it should be analyzed for possible anomalies – BFC Administration team Comments;


Control type: (Completeness, Accuracy, Validation, and Restricted Access): Completeness, Accuracy and Validation

Frequency: Quarterly

  • Period 01/02 - 30/04: 1st working day of May
  • Period 01/05 - 31/07: 1st working day of August
  • Period 01/08 - 31/10: 1st working day of November
  • Period 01/11 - 31/01: 1st working day of February


Evidence stored in GDrive: https://drive.google.com/drive/folders/18WARFfNuvQhiqYi3RE8qAxi903Ey8QY4


2.8 PPC-Maintenance controls (APP.10)

Purpose

The BFC Administration team is responsible to manage the maintenance of BFC:

  1. The customizing and the main changes to the BFC structure should be duly documented and justified; 
  2. The control shall be carried out in relation with the requestor;
  3. The control is sized according to the risks.


Types of modifications

The maintenance categories are grouping as follows :

[A] Recurring reporting set-up M (monthly)/ Q (quarterly) / Y (yearly)

[B] Correction of errors

[C] Improvements 

[D] Some kind of structure update and customizing (examples: new IFRS rules, new Finance projects) represent critical / sensitive maintenances on BFC. 


"Recurring maintenances" – Customizing with no impact in the data already in the Production environment:

  • Monthly recurring activities: creation of scopes, exchange rates tables, new companies
  • Creation and/or Modification of schedules;
  • Changes in the Structure: New dimension member; new characteristic member; Filters creation;
  • Changes in the Set of Rules: Creation of new consolidation rules
  • Changes in the Category Scenario: New controls/new headings/new formulas ...

  

Critical / sensitive maintenances ” – Customizing with impact in the data already in the Production environment: 

  • Changes in the Structure: Creation of new objects (Dimensions; Characteristics, Reference table...); Changes in existing filters;
  • Changes in the Set of Rules: Changes in the existing consolidation rules;
  • Changes in the Category Scenario: controls / headings & analysis schemes / formulas/ account Families …
  • Complex Projects;


A BFC project can be defined as: 

  • A formal request from a BFC end user (belonging to the “Authorized requestors” list defined below) expressed through a functional specification; 
  • A complex request requiring the modification of the Dimension Builder and Category Scenario objects, with the corresponding technical specifications; 
  • A request whose implementation in Production passes through tests in the Simulation environment and formalized validations. The concept of BFC projects obviously does not cover version migrations;
  • It´s the combination of those 3 criteria that determines whether we are in a recurring maintenance or in a project.


List of Authorized requestors:

(a) CONSO Brussels: Mario Tondo / Nicolas Donck /Elisa Canova /Bernard Marechal 

CONSO Luxembourg - Tax reporting: Anne Calicis

(b) CONTROLLING Financier: Farid Guenfoud 

(c) CONTROLLING Business: Nicolas Bourgois

(d) BFC-Admin: Caroline MATHIEU-STOÏSSICH /Célia Guerra 


Operating mode of the BFC Administration team


[A] Reporting set-up Monthly / Quarterly / Yearly

 [A1] ACTUAL’s (IFRS purposes) M/ Q / Y – Monthly Process

The BFC Admin team is responsible for preparing the Reporting set-up required for each reporting cycle:

 * Opening of reporting periods on WD-4 – Done directly in Production

 * Reporting packages creation and generation on WD-2 – Done directly in Production

 * Creation of exchange rates on WD-1

 * Creation of consolidation scopes on WD1

 * Creation of Consolidation/ Intercos Reconciliation definitions on WD1 – Done directly in Production

 * Creation/update of objects in the Dimension builder: Companies, Sites, Business activities

Note that the Risks related to the management of a monthly / quarterly and yearly reporting sessions are low impact. Any errors detected can be easily corrected.


[A2] RSB (Controlling purposes) – Quarterly Process

[A3] PREV(Controlling purposes) – Yearly Process

  • The formalization of the modifications done to these two types of reporting sessions are managed by the Corporate Controlling (KUF: Nicolas Bourgois);
  • The BFC Administration team is responsible to perform the necessary changes;
  • Once the changes are made, Corporate Controlling validates that the changes are in line with expectations and gives the GO for piloting to Production;
  • Evidence: Controlling agreement (KUF: Nicolas Bourgois) to pilot to Production;


[B] Correction of errors

[C] Improvements (with no impact in the Reporting Content)

Error corrections and improvements are usually based on the feedback from the Reporting cycles. For example, a control to be modified, a data collection to be improved in the reporting packages, a new report to be created, corrections of existing descriptions. 

These corrections / improvements are safe from both BFC settings and data integrity point of view. Otherwise, it is no longer a question of corrections / improvements but of a BFC project.

The associated controls must be minimal and not heavy to ensure fast services to requestors.

As a general principle, the piloting actions for [B] Corrections and [C] Improvement  are carried out in the same way as the type [A] Reporting Set-up.

The control consists in verifying that the changes have been implemented and informing the requestor.


[D] Structure Update and Customizing

The changes linked to the Structure Update and Customizing are expressed by a KUF (Consolidation / Tax / Financial Controlling / Corporate Controlling). 

The implementations are more complex but generally not risky as: 

  • The updates are made outside of the closing periods with a compulsory testing part
  • Consequent updates are never implemented over a quarterly reporting period;
  • A reversal / step back is always possible.


The changes are managed by the KUS (BFC Administrator), documenting the changes with: 

  1. A) Definition of the need  (expressed by the requestor);
  2. B) Functional analysis;
  3. C) Technical BFC specifications; 
  4. D) Tests (to be performed by both Administrator and Requestor)
  5. E) Evidences: 
  • Once the requestor validates that the changes are in line with expectations and gives the GO for piloting to Production;
  • Piloting of objects impacted by the change from TOP to PROD;
  • Evidence: Requestor agreement (KUF) to pilot to Production

Internal Control:

In order to simplify the process, several types of tasks have been created in BFC according to the related process and to the requester: 

  • EXPL-ADMIN: for the reporting set-up or other recurring tasks / corrections and improvements;
  • EXPL-CONSO: for requests expressed by the Consolidation team (KUF : Mario Tondo / Nicolas Donck / Bernard Marechal / Elisa Canova);
  • EXPL-CTRLFIN: for requests linked to the Financial controlling (KUF : Farid Guenfoud);
  • EXPL-GESTION: for requests linked to the Corporate controlling (KUF : Nicolas Bourgois);
  • EXPL-TAXES: for requests linked to the Taxes (KUF : Anne Calicis);


The BFC Administration team uses always these tasks and their content is transferred to Production. In Production, those tasks are automatically archived and therefore their content is traceable.

The BFC Admin team has to archive the Requester’s final approval as well as the  print screens of the piloted objects in Production. 


Evidence stored in GDrive: https://drive.google.com/drive/folders/1G67YgvhE3tVvBJkyYUp6tLwHsLnOTf2c