Jingga/Organization-Guide
1
0
Fork 0
mirror of https://github.com/Karaka-Management/Organization-Guide.git synced 2026-03-07 11:58:40 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

update

Browse Source
This commit is contained in:
Dennis Eichhorn 2022-08-17 00:06:18 +02:00
parent eeef844305
commit fac5c6d5d3
30 changed files with 456 additions and 263 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
Policies & Guidelines/IT/Backup & Data Recovery.md
View File

@ -52,22 +52,6 @@ The data should be stored in such a way that only authorized personnel has acces
The data reconstruction is documented in a reconstruction tutorial in the IT processes. During the reconstruction it may be necessary to put a higher priority on files and data which are more important for the ongoing organization activities (e.g. customer data, source code data).
## Flowchart (daily backup)
```mermaid
graph TD;
CHECK_CHANGES([System: Check changes])-->CREATE_LOCAL_BACKUP[System: Create/update backup];
CREATE_LOCAL_BACKUP-->VALIDATE_LOCAL[System: Validate local backup];
VALIDATE_LOCAL-->IS_VALID1{System: Is valid?};
IS_VALID1--Yes-->COPY_ONLINE[System: Copy backup to cloud];
IS_VALID1--No-->REPORT[System: Inform IT department];
COPY_ONLINE-->VALIDATE_ONLINE[System: Validate remote backup];
VALIDATE_ONLINE-->IS_VALID2{System: Is valid?};
IS_VALID2--No-->REPORT;
```
2022-01-01 - Version 1.0

33
Policies & Guidelines/IT/Change Management.md
View File

@ -10,22 +10,6 @@ Potential documents to be changed are:
* [Permission List](../../Processes/IT/Permission%20List.md)
### Flowchart
```mermaid
graph TD;
REQUEST_HOD([Request from HOD])--->IT_CHECKS{IT: Other approvals necessary?};
REQUEST_STAFF([Request from employee])-->APPROVAL_HOD[Approval by HOD];
APPROVAL_HOD-->IT_CHECKS;
IT_CHECKS--Yes-->FORWARD[IT: Forward request];
FORWARD-->APPROVAL_RESPONSIBLE[Approval by responsible person];
APPROVAL_RESPONSIBLE-->VALIDATE{IT: Is approved and appropriate?};
IT_CHECKS--No-->VALIDATE;
VALIDATE--Yes-->IMPLEMENT[IT: Implement permission changes];
VALIDATE--No-->INFORM([IT: Inform employee and HOD]);
IMPLEMENT-->INFORM;
```
## Software
Software changes include software updates, new software or functional/feature changes. Change requests can be made by any employee but must get approved by the respective HOD. If the change request is justified the IT department performs the change in a testing environment where the employee or HOD can test the change.
@ -46,24 +30,7 @@ Potential documents to be changed are:
* [Approved Customer Software](../../Processes/Support/Approved%20Customer%20Software.md)
* [Key Supplier Evaluation](../../Processes/Purchase/Key%20Supplier%20Evaluation.md)
### Flowchart
```mermaid
graph TD;
REQUEST_HOD([Request from HOD])--->IT_CHECKS{IT: Other approvals necessary?};
REQUEST_STAFF([Request from employee])-->APPROVAL_HOD[Approval by HOD];
APPROVAL_HOD-->IT_CHECKS;
IT_CHECKS--Yes-->FORWARD[IT: Forward request];
FORWARD-->APPROVAL_RESPONSIBLE[Approval by responsible person];
APPROVAL_RESPONSIBLE-->VALIDATE{IT: Is approved and appropriate?};
IT_CHECKS--No-->VALIDATE;
VALIDATE--Yes-->IMPLEMENT[IT: Implement change in test environment];
VALIDATE--No-->INFORM([IT: Inform employee and HOD]);
IMPLEMENT-->INFORM;
INFORM-->TEST[Employee/HOD: Test change];
TEST-->VALIDATE_TEST[IT: Test successful?];
VALIDATE_TEST--Yes-->MIGRATE[IT: Migrate change to live];
```
2022-01-01 - Version 1.0

2
Policies & Guidelines/Whistleblower System.md
View File

@ -1,6 +1,6 @@
# Whistleblower System
The whistleblower System is a way to allow anyone to report illegal behavior or behavior which goes against the processes, policies and guidelines by any affiliated person or affiliated company to the organization. The complaint can be done anonymous or with the name of the reporter. Generally, it is recommended to provide your name when making a complaint which allows the persons in charge of the whistleblower system to contact the reporting person in case of additional questions. If the name is not provided investigations can become difficult to complete.
The whistleblower system is a way to allow anyone to report illegal behavior or behavior which goes against the processes, policies and guidelines by any affiliated person or affiliated company to the organization. The complaint can be done anonymous or with the name of the reporter. Generally, it is recommended to provide your name when making a complaint which allows the persons in charge of the whistleblower system to contact the reporting person in case of additional questions. If the name is not provided investigations can become difficult to complete.
## Contact system

1
Processes/01_Development.md
View File

@ -141,3 +141,4 @@ Developers may only rely on the dependencies defined in [IT Equipment & Software
* [Tutorials](./Development/Tutorials)
2022-01-01 - Version 1.0

24
Processes/01_Development_Risk Control Matrix.md
View File

@ -1,17 +1,17 @@
# Development Risk Control Matrix
| No. | R | Category | Risk Event | L | C | O | Cause | Mitigation Type | Mitigation Strategy | L* | C* | Changes | Comments | ES | EY |
| ---- | ----------------- | ------------------------------ | ------------------------------------------------------------ | ---- | ---- | ----------------- | ----------------------------- | ---------------------------- | ------------------------------------------------------------ | ---- | ---- | ------- | ------------------------------------------------------------ | ---- | ---- |
| 1 | CTO | Operational Risk (Development) | Unauthorized source code and development asset access. | 1 | 1 | Many times a day | Unmanaged access permissions. | Preventing (System & Manual) | Only authorized people gain access to confidential source code and development assets. | 1 | 1 | | Not all source code and development assets are considered confidential and may be publicly accessible. The confidential aspects are determined by the CTO. | yes | yes |
| 2 | CTO | Operational Risk (Development) | Undefined terms of intellectual property for code contributions. | 1 | 3 | Many times a day | | Preventing (Manual) | The terms of intellectual property for all contributions are well defined. | 1 | 1 | | | yes | yes |
| 3 | Developer | Operational Risk (Development) | Inconsistent code styles (which increases frictions between developers) | 5 | 1 | Many times a day | | Preventing (Manual) | Code style definitions are publicly available. | 2 | 1 | | | yes | yes |
| 4 | CTO/Code reviewer | Operational Risk (Development) | Inconsistent code styles (which increases frictions between developers) | 5 | 1 | Many times a day | | Preventing (System & Manual) | Code styles are automatically tested with code style checkers. Optionally on the developer side but mandatory and automatic during the code merging. | 2 | 1 | | | yes | yes |
| 5 | CTO/Code reviewer | Operational Risk (Development) | Inconsistent code styles (which increases frictions between developers) | 5 | 1 | Many times a day | | Preventing (Manual) | Code styles are checked which allows handling exceptions and special cases. | 2 | 1 | | Not all code style options can be reasonably checked and defined. In some cases it's also possible to have false positive code style violations for edge cases. Manual checks during the code review by the responsible person may lead to additional code style changes or ignoring some code style "violations" if deemed reasonable. | yes | yes |
| 6 | Developer | Operational Risk (Development) | Faulty code due to code changes, additions, removal. | 5 | 1 | Many times a day | | Preventing (Manual) | Code testing definitions are publicly available. Minimum line coverage forces developers to write at least a certain amount of tests to check their code. | 2 | 1 | | | yes | yes |
| 7 | CTO/Code reviewer | Operational Risk (Development) | Faulty code due to code changes, additions, removal. | 5 | 1 | Many times a day | | Preventing (System & Manual) | Code tests are automatically run with testing tools. Optionally on the developer side but mandatory and automatic during the code merging. This includes static tests which require no self-written tests and developer written tests. | 2 | 1 | | | yes | yes |
| 8 | CTO/Code reviewer | Operational Risk (Development) | Faulty code due to code changes, additions, removal. | 5 | 1 | Many times a day | | Preventing (Manual) | Code tests are manually checked and performed which allows handling exceptions and special cases. | 2 | 1 | | | yes | yes |
| 9 | CTO/Code reviewer | Operational Risk (Development) | Faulty code due to code changes, additions, removal. | 5 | 4 | Many times a day | | Preventing (Manual) | A demo application allows code reviewer to test code changes from a end-user point of view in conjunction with the whole application, other modules and dummy data. | 2 | 1 | | | yes | yes |
| 10 | CTO/Code reviewer | Operational Risk (Development) | Unauthorized code gets accepted. | 5 | 2 | Many times a day | | Preventing (System & Manual) | Manual and automatic code checks/tests and manual review by authorized and qualified developers ensures high quality and that only code authorized by these developers gets accepted. Developers who can accept code changes are carefully selected and their permissions are handled in the version control software. | | | | | yes | yes |
| No. | R | Category | Risk Event | L | C | O | Cause | Mitigation Type | Mitigation Strategy | L* | C* | Changes | Comments | ES | EY | Evidences |
| ---- | ----------------- | ------------------------------ | ------------------------------------------------------------ | ---- | ---- | ----------------- | ----------------------------- | ---------------------------- | ------------------------------------------------------------ | ---- | ---- | ------- | ------------------------------------------------------------ | ---- | ---- | --------- |
| 1 | CTO | Operational Risk (Development) | Unauthorized source code and development asset access. | 1 | 1 | Many times a day | Unmanaged access permissions. | Preventing (System & Manual) | Only authorized people gain access to confidential source code and development assets. | 1 | 1 | | Not all source code and development assets are considered confidential and may be publicly accessible. The confidential aspects are determined by the CTO. | yes | yes | |
| 2 | CTO | Operational Risk (Development) | Undefined terms of intellectual property for code contributions. | 1 | 3 | Many times a day | | Preventing (Manual) | The terms of intellectual property for all contributions are well defined. | 1 | 1 | | | yes | yes | |
| 3 | Developer | Operational Risk (Development) | Inconsistent code styles (which increases frictions between developers) | 5 | 1 | Many times a day | | Preventing (Manual) | Code style definitions are publicly available. | 2 | 1 | | | yes | yes | |
| 4 | CTO/Code reviewer | Operational Risk (Development) | Inconsistent code styles (which increases frictions between developers) | 5 | 1 | Many times a day | | Preventing (System & Manual) | Code styles are automatically tested with code style checkers. Optionally on the developer side but mandatory and automatic during the code merging. | 2 | 1 | | | yes | yes | |
| 5 | CTO/Code reviewer | Operational Risk (Development) | Inconsistent code styles (which increases frictions between developers) | 5 | 1 | Many times a day | | Preventing (Manual) | Code styles are checked which allows handling exceptions and special cases. | 2 | 1 | | Not all code style options can be reasonably checked and defined. In some cases it's also possible to have false positive code style violations for edge cases. Manual checks during the code review by the responsible person may lead to additional code style changes or ignoring some code style "violations" if deemed reasonable. | yes | yes | |
| 6 | Developer | Operational Risk (Development) | Faulty code due to code changes, additions, removal. | 5 | 1 | Many times a day | | Preventing (Manual) | Code testing definitions are publicly available. Minimum line coverage forces developers to write at least a certain amount of tests to check their code. | 2 | 1 | | | yes | yes | |
| 7 | CTO/Code reviewer | Operational Risk (Development) | Faulty code due to code changes, additions, removal. | 5 | 1 | Many times a day | | Preventing (System & Manual) | Code tests are automatically run with testing tools. Optionally on the developer side but mandatory and automatic during the code merging. This includes static tests which require no self-written tests and developer written tests. | 2 | 1 | | | yes | yes | |
| 8 | CTO/Code reviewer | Operational Risk (Development) | Faulty code due to code changes, additions, removal. | 5 | 1 | Many times a day | | Preventing (Manual) | Code tests are manually checked and performed which allows handling exceptions and special cases. | 2 | 1 | | | yes | yes | |
| 9 | CTO/Code reviewer | Operational Risk (Development) | Faulty code due to code changes, additions, removal. | 5 | 4 | Many times a day | | Preventing (Manual) | A demo application allows code reviewer to test code changes from a end-user point of view in conjunction with the whole application, other modules and dummy data. | 2 | 1 | | | yes | yes | |
| 10 | CTO/Code reviewer | Operational Risk (Development) | Unauthorized code gets accepted. | 5 | 2 | Many times a day | | Preventing (System & Manual) | Manual and automatic code checks/tests and manual review by authorized and qualified developers ensures high quality and that only code authorized by these developers gets accepted. Developers who can accept code changes are carefully selected and their permissions are handled in the version control software. | | | | | yes | yes | |
## Abbreviations

38
Processes/02_Purchase_Risk Control Matrix.md
View File

@ -1,24 +1,24 @@
# Purchase Risk Control Matrix
| No. | R | Category | Risk Event | L | C | O | Cause | Mitigation Type | Mitigation Strategy | L* | C* | Changes | Comments | ES | EY |
| ---- | -------------------------------------- | --------------------------- | ------------------------------------------------------------ | ---- | ---- | ---------------- | ----- | ---------------------------- | ------------------------------------------------------------ | ---- | ---- | ------- | -------- | ---- | ---- |
| 1 | Employee | Operational Risk (Purchase) | Purchasing not the optimal investment product due to no market research. *"Optimal" includes product/service quality, vendor reliability, price, ...* | 1 | 1 | Many times a day | | Preventing (Manual) | Compare products and vendors | 1 | 1 | | | yes | yes |
| 2 | See purchase approval table | Operational Risk (Purchase) | Unauthorized purchase (budget risks, fraud, compliance, ...) | 1 | 1 | Many times a day | | Preventing (Manual) | Authorize purchases according to the purchase approval table. This functions as control and separation of responsibilities. | 1 | 1 | | | yes | yes |
| 3 | Employee | Operational Risk (Purchase) | Critical information related to a purchase are not stored or difficult to find. | 1 | 1 | Many times a day | | Preventing (Manual & System) | Documents and important information related to a purchase are stored in the IT system referring the purchase. | 1 | 1 | | | yes | yes |
| 4 | Purchase | Operational Risk (Purchase) | Invalid invoice contents (formal and other mistakes/deviations) | 1 | 1 | Many times a day | | Preventing (System) | Automatic IT system checks. | 1 | 1 | | | yes | yes |
| 5 | Purchase | Operational Risk (Purchase) | Invalid invoice contents (formal and other mistakes/deviations) | 1 | 1 | Many times a day | | Preventing (Manual) | Additional manual invoice approval by purchase clerk. | 1 | 1 | | | yes | yes |
| 6 | Head of department + Head of purchase | Operational Risk (Purchase) | Deviations between order and invoice | 1 | 1 | Many times a day | | Preventing (Manual) | Approval by responsible staff. | 1 | 1 | | | yes | yes |
| 7 | Finance | Operational Risk (Finance) | Invalid posting. | 1 | 1 | Many times a day | | Preventing (System) | The IT system generates an automatic posting suggestion. | 1 | 1 | | | yes | yes |
| 8 | Finance | Operational Risk (Purchase) | Invalid posting suggestion. | 1 | 1 | Many times a day | | Preventing (Manual) | The accountant can adjust the posting suggestion from the IT system. | 1 | 1 | | | yes | yes |
| 9 | Head of finance | Operational Risk (Purchase) | Invalid posting. | 1 | 1 | Many times a day | | Preventing (System & Manual) | The head of finance checks a selection invoice postings randomly. | 1 | 1 | | | yes | yes |
| 10 | Finance | Operational Risk (Purchase) | Missing invoice payments. | 1 | 1 | Weekly | | Preventing (System) | The IT system generates a list of invoices for payment. | 1 | 1 | | | yes | yes |
| 11 | Finance | Operational Risk (Purchase) | Invalid cash back or forex calculations. | 1 | 1 | Weekly | | Preventing (System) | The IT system automatically calculates the cash back or forex differences. | 1 | 1 | | | yes | yes |
| 12 | Finance | Operational Risk (Purchase) | Invalid payment suggestion. | 1 | 1 | Weekly | | Preventing (Manual) | The accountant can add or remove payments. | 1 | 1 | | | yes | yes |
| 13 | Finance + Head of finance | Operational Risk (Purchase) | Invalid payments | 1 | 1 | Weekly | | Preventing (System & Manual) | Both accountant and head of finance approve the payments. The payment list shows which invoices got manually added, excluded and adjusted. | 1 | 1 | | | yes | yes |
| 14 | Purchase | Operational Risk (Purchase) | Missing supplier information (e.g. important tax information) | 1 | 1 | Many times a day | | Preventing (System) | The IT system requires mandatory information before invoices can be created for a supplier. | 1 | 1 | | | yes | yes |
| 15 | Purchase | Operational Risk (Purchase) | Invalid supplier information | 1 | 1 | Many times a day | | Preventing (System) | The IT system performs automatic checks. | 1 | 1 | | | yes | yes |
| 16 | Head of purchase | Operational Risk (Purchase) | False positive supplier errors. | 1 | 1 | Many times a day | | Preventing (Manual) | Manual supplier approval by head of purchase | 1 | 1 | | | yes | yes |
| 17 | Purchase | Operational Risk (Purchase) | Critical changes to suppliers (e.g. sanctions) | 1 | 1 | Daily | | Preventing (System) | The IT system automatically checks suppliers against sanction lists every day. | 1 | 1 | | | yes | yes |
| No. | R | Category | Risk Event | L | C | O | Cause | Mitigation Type | Mitigation Strategy | L* | C* | Changes | Comments | ES | EY | Evidences |
| ---- | -------------------------------------- | --------------------------- | ------------------------------------------------------------ | ---- | ---- | ---------------- | ----- | ---------------------------- | ------------------------------------------------------------ | ---- | ---- | ------- | -------- | ---- | ---- | --------- |
| 1 | Employee | Operational Risk (Purchase) | Purchasing not the optimal investment product due to no market research. *"Optimal" includes product/service quality, vendor reliability, price, ...* | 1 | 1 | Many times a day | | Preventing (Manual) | Compare products and vendors | 1 | 1 | | | yes | yes | |
| 2 | See purchase approval table | Operational Risk (Purchase) | Unauthorized purchase (budget risks, fraud, compliance, ...) | 1 | 1 | Many times a day | | Preventing (Manual) | Authorize purchases according to the purchase approval table. This functions as control and separation of responsibilities. | 1 | 1 | | | yes | yes | |
| 3 | Employee | Operational Risk (Purchase) | Critical information related to a purchase are not stored or difficult to find. | 1 | 1 | Many times a day | | Preventing (Manual & System) | Documents and important information related to a purchase are stored in the IT system referring the purchase. | 1 | 1 | | | yes | yes | |
| 4 | Purchase | Operational Risk (Purchase) | Invalid invoice contents (formal and other mistakes/deviations) | 1 | 1 | Many times a day | | Preventing (System) | Automatic IT system checks. | 1 | 1 | | | yes | yes | |
| 5 | Purchase | Operational Risk (Purchase) | Invalid invoice contents (formal and other mistakes/deviations) | 1 | 1 | Many times a day | | Preventing (Manual) | Additional manual invoice approval by purchase clerk. | 1 | 1 | | | yes | yes | |
| 6 | Head of department + Head of purchase | Operational Risk (Purchase) | Deviations between order and invoice | 1 | 1 | Many times a day | | Preventing (Manual) | Approval by responsible staff. | 1 | 1 | | | yes | yes | |
| 7 | Finance | Operational Risk (Finance) | Invalid posting. | 1 | 1 | Many times a day | | Preventing (System) | The IT system generates an automatic posting suggestion. | 1 | 1 | | | yes | yes | |
| 8 | Finance | Operational Risk (Purchase) | Invalid posting suggestion. | 1 | 1 | Many times a day | | Preventing (Manual) | The accountant can adjust the posting suggestion from the IT system. | 1 | 1 | | | yes | yes | |
| 9 | Head of finance | Operational Risk (Purchase) | Invalid posting. | 1 | 1 | Many times a day | | Preventing (System & Manual) | The head of finance checks a selection invoice postings randomly. | 1 | 1 | | | yes | yes | |
| 10 | Finance | Operational Risk (Purchase) | Missing invoice payments. | 1 | 1 | Weekly | | Preventing (System) | The IT system generates a list of invoices for payment. | 1 | 1 | | | yes | yes | |
| 11 | Finance | Operational Risk (Purchase) | Invalid cash back or forex calculations. | 1 | 1 | Weekly | | Preventing (System) | The IT system automatically calculates the cash back or forex differences. | 1 | 1 | | | yes | yes | |
| 12 | Finance | Operational Risk (Purchase) | Invalid payment suggestion. | 1 | 1 | Weekly | | Preventing (Manual) | The accountant can add or remove payments. | 1 | 1 | | | yes | yes | |
| 13 | Finance + Head of finance | Operational Risk (Purchase) | Invalid payments | 1 | 1 | Weekly | | Preventing (System & Manual) | Both accountant and head of finance approve the payments. The payment list shows which invoices got manually added, excluded and adjusted. | 1 | 1 | | | yes | yes | |
| 14 | Purchase | Operational Risk (Purchase) | Missing supplier information (e.g. important tax information) | 1 | 1 | Many times a day | | Preventing (System) | The IT system requires mandatory information before invoices can be created for a supplier. | 1 | 1 | | | yes | yes | |
| 15 | Purchase | Operational Risk (Purchase) | Invalid supplier information | 1 | 1 | Many times a day | | Preventing (System) | The IT system performs automatic checks. | 1 | 1 | | | yes | yes | |
| 16 | Head of purchase | Operational Risk (Purchase) | False positive supplier errors. | 1 | 1 | Many times a day | | Preventing (Manual) | Manual supplier approval by head of purchase | 1 | 1 | | | yes | yes | |
| 17 | Purchase | Operational Risk (Purchase) | Critical changes to suppliers (e.g. sanctions) | 1 | 1 | Daily | | Preventing (System) | The IT system automatically checks suppliers against sanction lists every day. | 1 | 1 | | | yes | yes | |
## Abbreviations

52
Processes/03_Sales_Risk Control Matrix.md
View File

@ -1,31 +1,31 @@
# Sales Risk Control Matrix
| No. | R | Category | Risk Event | L | C | O | Cause | Mitigation Type | Mitigation Strategy | L* | C* | Changes | Comments | ES | EY |
| ---- | ------------------------------- | --------------------------- | ------------------------------------------------------------ | ---- | ---- | ---------------- | ----- | ---------------------------- | ------------------------------------------------------------ | ---- | ---- | ------- | ------------------------------------------------------------ | ---- | ---- |
| 1 | Sales | Operational Risk (Sales) | Invalid offer | 1 | 1 | Many times a day | | Preventing (System) | Use default offers. | 1 | 1 | | | yes | yes |
| 2 | Sales | Operational Risk (Sales) | No flexibility in case of none-standard customer requests. | 1 | 1 | Many times a day | | Preventing (Manual) | Custom offers for customers. | 1 | 1 | | | yes | yes |
| 3 | Head of Sales / Head of Finance | Operational Risk (Sales) | Prices too low / discounts too large | 1 | 5 | Many times a day | | Preventing (System & Manual) | Default prices and standard discounts are stored in the IT system responsible for the offer generation. | 1 | 1 | | | yes | yes |
| 4 | CEO | Operational Risk (Sales) | Prices too low / discounts too large | 1 | 5 | Many times a day | | Preventing (System & Manual) | Deviations from the pricing policy require additional electronic approval in the system by the head of sales or head of finance. Without this electronic approval the offer cannot get created. | 1 | 1 | | | yes | yes |
| 5 | Head of Sales / Head of finance | Operational Risk (Sales) | Default prices are too low / default discounts are too large | 1 | 5 | Many times a day | | Preventing (System & Manual) | Changes to default prices and default discounts can only be entered into the IT system by the head of sales or head of finance. | 1 | 1 | | | yes | yes |
| 6 | Sales | Operational Risk (Sales) | Changes to offers, order confirmations, offers etc. | 1 | 1 | Many times a day | | Preventing (System) | Changes are only possible as long as they are not marked as delivered in the IT system. | 1 | 1 | | | yes | yes |
| 7 | Sales | Operational Risk (Sales) | Other aspects of the offer are invalid (i.e. wrong customer, bad credit score of customer, ...) | 1 | 5 | Many times a day | | Preventing (System) | The offer is none-binding and only becomes binding with the order confirmation where additional checks are performed. | 1 | 1 | | | yes | yes |
| 8a | Sales | Operational Risk (Sales) | Invalid order from customer (e.g. changes to the offer) | 1 | 1 | Many times a day | | Preventing (Manual) | The order from the customer must be checked by a sales clerk. | 1 | 1 | | | yes | yes |
| 8b | Sales | Operational Risk (Sales) | Invalid order from customer (e.g. changes to the offer) | 1 | 1 | Many times a day | | Preventing (System) | Online orders from the shop are automatically generated by the IT system according to the allowed prices and products etc. | 1 | 1 | | | yes | yes |
| 9 | Sales | Operational Risk (Sales) | Invalid tax calculation | 1 | 1 | Many times a day | | Preventing (System) | The IT system automatically calculates the taxes based on the item and customer settings. | 1 | 1 | | | yes | yes |
| 10 | Sales | Operational Risk (Sales) | Invalid automatic tax calculation | 1 | 1 | Many times a day | | Preventing (Manual) | An accountant can adjust the taxes if necessary. | 1 | 1 | | *This can be necessary for special cases such as chain transactions.* | yes | yes |
| 11 | Head of sales | Operational Risk (Sales) | Changes between order confirmation and invoice. | 1 | 1 | Many times a day | | Preventing (System & Manual) | Changes between order confirmation and invoice must be approved by the head of sales before the invoice can get created. | 1 | 1 | | | yes | yes |
| 12 | Accounting | Operational Risk (Finance) | Invalid posting. | 1 | 1 | Many times a day | | Preventing (System) | The IT system automatically generates the posting for invoices based on item and customer settings. | 1 | 1 | | | yes | yes |
| 13 | Accounting | Operational Risk (Finance) | Unpaid invoice. | 1 | 1 | Every 2 Weeks | | Revealing (System) | The IT system automatically generates reminders every 2 weeks. | 1 | 1 | | | yes | yes |
| 14 | Accounting | Operational Risk (Finance) | Customer continues to receive products despite not paying invoices. | 1 | 1 | Every 2 Weeks | | Preventing (System) | The IT system automatically locks the customer account preventing further customer orders. | 1 | 1 | | | yes | yes |
| 15 | Accounting | Operational Risk (Finance) | Customers don't pay after reminder. | 1 | 1 | Every 2 Weeks | | Revealing (Manual) | Invoices can get handed over to a lawyer for collection based on the decision of the head of finance. | 1 | 1 | | | yes | yes |
| 16 | Accounting | Operational Risk (Finance) | Invalid payment matching. | 1 | 1 | Many times a day | | Preventing (System) | The IT system generates suggestions for matching payments with customers/invoices. | 1 | 1 | | | yes | yes |
| 17 | Accounting | Operational Risk (Finance) | Invalid payment suggestion matching. | 1 | 1 | Many times a day | | Preventing (Manual) | The account can manually adjust the payment matching. | 1 | 1 | | | yes | yes |
| 18 | Sales | Operational Risk (Purchase) | Missing customer information (e.g. important tax information) | 1 | 1 | Many times a day | | Preventing (System) | The IT system requires mandatory information before invoices and order confirmations can be created for a customer. | 1 | 1 | | | yes | yes |
| 19 | Sales | Operational Risk (Purchase) | Invalid customer information | 1 | 1 | Many times a day | | Preventing (System) | The IT system performs automatic checks. | 1 | 1 | | | yes | yes |
| 19a | Sales | Operational Risk (Sales) | Invalid customer data | 1 | 5 | Many times a day | | Preventing (System) | Customer data gets compared with the information provided from credit rating agencies, company registration forms etc. | 1 | 1 | | | yes | yes |
| 19b | Sales | Operational Risk (Sales) | Customer default | 1 | 5 | Many times a day | | Preventing (System) | Only customers with a credit score of XXXX-Crefo / XXXX-Coface / XXXX-Schufa get approved during the order confirmation. | 1 | 1 | | | yes | yes |
| 20 | Head of sales | Operational Risk (Purchase) | False positive customer errors. | 1 | 1 | Many times a day | | Preventing (Manual) | Manual customer approval by head of sales | 1 | 1 | | | yes | yes |
| 21 | Sales | Operational Risk (Purchase) | Critical changes to customer (e.g. sanctions) | 1 | 1 | Daily | | Preventing (System) | The IT system automatically checks customers against sanction lists every day. | 1 | 1 | | | yes | yes |
| No. | R | Category | Risk Event | L | C | O | Cause | Mitigation Type | Mitigation Strategy | L* | C* | Changes | Comments | ES | EY | Evidences |
| ---- | ------------------------------- | --------------------------- | ------------------------------------------------------------ | ---- | ---- | ---------------- | ----- | ---------------------------- | ------------------------------------------------------------ | ---- | ---- | ------- | ------------------------------------------------------------ | ---- | ---- | --------- |
| 1 | Sales | Operational Risk (Sales) | Invalid offer | 1 | 1 | Many times a day | | Preventing (System) | Use default offers. | 1 | 1 | | | yes | yes | |
| 2 | Sales | Operational Risk (Sales) | No flexibility in case of none-standard customer requests. | 1 | 1 | Many times a day | | Preventing (Manual) | Custom offers for customers. | 1 | 1 | | | yes | yes | |
| 3 | Head of Sales / Head of Finance | Operational Risk (Sales) | Prices too low / discounts too large | 1 | 5 | Many times a day | | Preventing (System & Manual) | Default prices and standard discounts are stored in the IT system responsible for the offer generation. | 1 | 1 | | | yes | yes | |
| 4 | CEO | Operational Risk (Sales) | Prices too low / discounts too large | 1 | 5 | Many times a day | | Preventing (System & Manual) | Deviations from the pricing policy require additional electronic approval in the system by the head of sales or head of finance. Without this electronic approval the offer cannot get created. | 1 | 1 | | | yes | yes | |
| 5 | Head of Sales / Head of finance | Operational Risk (Sales) | Default prices are too low / default discounts are too large | 1 | 5 | Many times a day | | Preventing (System & Manual) | Changes to default prices and default discounts can only be entered into the IT system by the head of sales or head of finance. | 1 | 1 | | | yes | yes | |
| 6 | Sales | Operational Risk (Sales) | Changes to offers, order confirmations, offers etc. | 1 | 1 | Many times a day | | Preventing (System) | Changes are only possible as long as they are not marked as delivered in the IT system. | 1 | 1 | | | yes | yes | |
| 7 | Sales | Operational Risk (Sales) | Other aspects of the offer are invalid (i.e. wrong customer, bad credit score of customer, ...) | 1 | 5 | Many times a day | | Preventing (System) | The offer is none-binding and only becomes binding with the order confirmation where additional checks are performed. | 1 | 1 | | | yes | yes | |
| 8a | Sales | Operational Risk (Sales) | Invalid order from customer (e.g. changes to the offer) | 1 | 1 | Many times a day | | Preventing (Manual) | The order from the customer must be checked by a sales clerk. | 1 | 1 | | | yes | yes | |
| 8b | Sales | Operational Risk (Sales) | Invalid order from customer (e.g. changes to the offer) | 1 | 1 | Many times a day | | Preventing (System) | Online orders from the shop are automatically generated by the IT system according to the allowed prices and products etc. | 1 | 1 | | | yes | yes | |
| 9 | Sales | Operational Risk (Sales) | Invalid tax calculation | 1 | 1 | Many times a day | | Preventing (System) | The IT system automatically calculates the taxes based on the item and customer settings. | 1 | 1 | | | yes | yes | |
| 10 | Sales | Operational Risk (Sales) | Invalid automatic tax calculation | 1 | 1 | Many times a day | | Preventing (Manual) | An accountant can adjust the taxes if necessary. | 1 | 1 | | *This can be necessary for special cases such as chain transactions.* | yes | yes | |
| 11 | Head of sales | Operational Risk (Sales) | Changes between order confirmation and invoice. | 1 | 1 | Many times a day | | Preventing (System & Manual) | Changes between order confirmation and invoice must be approved by the head of sales before the invoice can get created. | 1 | 1 | | | yes | yes | |
| 12 | Accounting | Operational Risk (Finance) | Invalid posting. | 1 | 1 | Many times a day | | Preventing (System) | The IT system automatically generates the posting for invoices based on item and customer settings. | 1 | 1 | | | yes | yes | |
| 13 | Accounting | Operational Risk (Finance) | Unpaid invoice. | 1 | 1 | Every 2 Weeks | | Revealing (System) | The IT system automatically generates reminders every 2 weeks. | 1 | 1 | | | yes | yes | |
| 14 | Accounting | Operational Risk (Finance) | Customer continues to receive products despite not paying invoices. | 1 | 1 | Every 2 Weeks | | Preventing (System) | The IT system automatically locks the customer account preventing further customer orders. | 1 | 1 | | | yes | yes | |
| 15 | Accounting | Operational Risk (Finance) | Customers don't pay after reminder. | 1 | 1 | Every 2 Weeks | | Revealing (Manual) | Invoices can get handed over to a lawyer for collection based on the decision of the head of finance. | 1 | 1 | | | yes | yes | |
| 16 | Accounting | Operational Risk (Finance) | Invalid payment matching. | 1 | 1 | Many times a day | | Preventing (System) | The IT system generates suggestions for matching payments with customers/invoices. | 1 | 1 | | | yes | yes | |
| 17 | Accounting | Operational Risk (Finance) | Invalid payment suggestion matching. | 1 | 1 | Many times a day | | Preventing (Manual) | The account can manually adjust the payment matching. | 1 | 1 | | | yes | yes | |
| 18 | Sales | Operational Risk (Purchase) | Missing customer information (e.g. important tax information) | 1 | 1 | Many times a day | | Preventing (System) | The IT system requires mandatory information before invoices and order confirmations can be created for a customer. | 1 | 1 | | | yes | yes | |
| 19 | Sales | Operational Risk (Purchase) | Invalid customer information | 1 | 1 | Many times a day | | Preventing (System) | The IT system performs automatic checks. | 1 | 1 | | | yes | yes | |
| 19a | Sales | Operational Risk (Sales) | Invalid customer data | 1 | 5 | Many times a day | | Preventing (System) | Customer data gets compared with the information provided from credit rating agencies, company registration forms etc. | 1 | 1 | | | yes | yes | |
| 19b | Sales | Operational Risk (Sales) | Customer default | 1 | 5 | Many times a day | | Preventing (System) | Only customers with a credit score of XXXX-Crefo / XXXX-Coface / XXXX-Schufa get approved during the order confirmation. | 1 | 1 | | | yes | yes | |
| 20 | Head of sales | Operational Risk (Purchase) | False positive customer errors. | 1 | 1 | Many times a day | | Preventing (Manual) | Manual customer approval by head of sales | 1 | 1 | | | yes | yes | |
| 21 | Sales | Operational Risk (Purchase) | Critical changes to customer (e.g. sanctions) | 1 | 1 | Daily | | Preventing (System) | The IT system automatically checks customers against sanction lists every day. | 1 | 1 | | | yes | yes | |
## Abbreviations

38
Processes/04_Support & Service_Risk Control Matrix.md
View File

@ -1,24 +1,24 @@
# Support & Service Risk Control Matrix
| No. | R | Category | Risk Event | L | C | O | Cause | Mitigation Type | Mitigation Strategy | L* | C* | Changes | Comments | ES | EY |
| ---- | ---- | ------------------------------------ | ------------------------------------------------------------ | ---- | ---- | ---------------- | ----- | ------------------- | ------------------------------------------------------------ | ---- | ---- | ------- | -------- | ---- | ---- |
| 1 | CTO | Operational Risk (Support & Service) | No legal basis for accessing customer data during customer support & service. | 1 | 1 | Daily | | Preventing (Manual) | Every customer must sign the Customer Data Protection Policy before they can receive support & service | 1 | 1 | | | yes | yes |
| 2 | CTO | Operational Risk (Support & Service) | No legal protection regarding liabilities and responsibilities during customer support & service. | 1 | 1 | Daily | | Preventing (Manual) | Every customer must sign the Customer Service Agreement before they can receive support & service | 1 | 1 | | | yes | yes |
| 3 | CTO | Operational Risk (Support & Service) | Unauthorized people make support & service requests. | 1 | 1 | Many times a day | | Preventing (Manual) | Only authorized are allowed to do support & service requests | 1 | 1 | | | yes | yes |
| 4a | CTO | Operational Risk (Support & Service) | Not well defined goals and tasks resulting in miscommunication, high costs and unmet expectations. | 1 | 1 | Many times a day | | Preventing (Manual) | Define goals, tasks, specifications and costs in writing in an offer. | 1 | 1 | | | yes | yes |
| 4b | CTO | Operational Risk (Support & Service) | The goals, tasks, specifications and costs are estimated with significant deviations. | 1 | 1 | Many times a day | | Preventing (Manual) | Only personnel with sufficient experience is allowed to make these estimations | 1 | 1 | | | yes | yes |
| 5 | CTO | Operational Risk (Support & Service) | The customer disputes the provided service. | 1 | 1 | Many times a day | | Preventing (Manual) | The customer must approve the offer in writing. | 1 | 1 | | | yes | yes |
| 6 | CTO | Operational Risk (Support & Service) | Environment setup & configuration by inexperienced employees | 1 | 1 | Daily | | Preventing (Manual) | Only employees with sufficient experience are allowed to perform the environment setup & configuration. | 1 | 1 | | | yes | yes |
| 7 | CTO | Operational Risk (Support & Service) | The customer disputes the provided service. | 1 | 1 | Many times a day | | Preventing (Manual) | Software setup & configuration is only allowed together with the customer. | 1 | 1 | | | yes | yes |
| 8 | CTO | Operational Risk (Support & Service) | Installation of unapproved software on the customer server causing issues. | 1 | 1 | Many times a day | | Preventing (Manual) | Only approved software is allowed to get installed on the customer servers | 1 | 1 | | | yes | yes |
| 9 | CTO | Operational Risk (Support & Service) | Bad, risky or faulty software gets approved for the installation at customers. | 1 | 1 | Quarterly | | Preventing (Manual) | Only the CTO is allowed to approve software to be installed on customer hardware after testing. | 1 | 1 | | | yes | yes |
| 10 | CTO | Operational Risk (Support & Service) | Insufficient hardware resources for the application | 1 | 1 | Daily | | Preventing (Manual) | Tested system requirements are provided for the customers. | 1 | 1 | | | yes | yes |
| 11 | CTO | Operational Risk (Support & Service) | Leaking customer data incl. server login names and passwords. | 1 | 1 | Daily | | Preventing (Manual) | No customer data incl. server login names or passwords are stored on the organization side. | 1 | 1 | | | yes | yes |
| 12 | CTO | Operational Risk (Support & Service) | Not all necessary steps are executed during the application setup or faulty. | 1 | 1 | Daily | | Preventing (Manual) | A Application Install Checklist is provided which has to be used during the install process. | 1 | 1 | | | yes | yes |
| 13 | CTO | Operational Risk (Support & Service) | The trainings don't cover important aspects. | 1 | 1 | Daily | | Preventing (Manual) | Trainings must be held according to the Training Manuals defined by the CTO. | 1 | 1 | | | yes | yes |
| 14 | CTO | Operational Risk (Support & Service) | The maintenance doesn't cover important aspects. | 1 | 1 | Daily | | Preventing (Manual) | Maintenance must be performed according to the Maintenance Checklist defined by the CTO. | 1 | 1 | | | yes | yes |
| 15 | HOCS | Operational Risk (Support & Service) | Support requests from customers are handled by people who don't have the necessary skills or experiences. | 1 | 1 | | | Preventing (Manual) | Support requests are assigned according to experiences and skillsets by team leaders, senior employees or the HOCS. | 1 | 1 | | | yes | yes |
| 16 | CTO | Operational Risk (Support & Service) | The provided support is not satisfactory for the customers. | 1 | 1 | | | Revealing (Manual) | Customers have the option to provide feedback after every closed support request. | 1 | 1 | | | yes | yes |
| No. | R | Category | Risk Event | L | C | O | Cause | Mitigation Type | Mitigation Strategy | L* | C* | Changes | Comments | ES | EY | Evidences |
| ---- | ---- | ------------------------------------ | ------------------------------------------------------------ | ---- | ---- | ---------------- | ----- | ------------------- | ------------------------------------------------------------ | ---- | ---- | ------- | -------- | ---- | ---- | --------- |
| 1 | CTO | Operational Risk (Support & Service) | No legal basis for accessing customer data during customer support & service. | 1 | 1 | Daily | | Preventing (Manual) | Every customer must sign the Customer Data Protection Policy before they can receive support & service | 1 | 1 | | | yes | yes | |
| 2 | CTO | Operational Risk (Support & Service) | No legal protection regarding liabilities and responsibilities during customer support & service. | 1 | 1 | Daily | | Preventing (Manual) | Every customer must sign the Customer Service Agreement before they can receive support & service | 1 | 1 | | | yes | yes | |
| 3 | CTO | Operational Risk (Support & Service) | Unauthorized people make support & service requests. | 1 | 1 | Many times a day | | Preventing (Manual) | Only authorized are allowed to do support & service requests | 1 | 1 | | | yes | yes | |
| 4a | CTO | Operational Risk (Support & Service) | Not well defined goals and tasks resulting in miscommunication, high costs and unmet expectations. | 1 | 1 | Many times a day | | Preventing (Manual) | Define goals, tasks, specifications and costs in writing in an offer. | 1 | 1 | | | yes | yes | |
| 4b | CTO | Operational Risk (Support & Service) | The goals, tasks, specifications and costs are estimated with significant deviations. | 1 | 1 | Many times a day | | Preventing (Manual) | Only personnel with sufficient experience is allowed to make these estimations | 1 | 1 | | | yes | yes | |
| 5 | CTO | Operational Risk (Support & Service) | The customer disputes the provided service. | 1 | 1 | Many times a day | | Preventing (Manual) | The customer must approve the offer in writing. | 1 | 1 | | | yes | yes | |
| 6 | CTO | Operational Risk (Support & Service) | Environment setup & configuration by inexperienced employees | 1 | 1 | Daily | | Preventing (Manual) | Only employees with sufficient experience are allowed to perform the environment setup & configuration. | 1 | 1 | | | yes | yes | |
| 7 | CTO | Operational Risk (Support & Service) | The customer disputes the provided service. | 1 | 1 | Many times a day | | Preventing (Manual) | Software setup & configuration is only allowed together with the customer. | 1 | 1 | | | yes | yes | |
| 8 | CTO | Operational Risk (Support & Service) | Installation of unapproved software on the customer server causing issues. | 1 | 1 | Many times a day | | Preventing (Manual) | Only approved software is allowed to get installed on the customer servers | 1 | 1 | | | yes | yes | |
| 9 | CTO | Operational Risk (Support & Service) | Bad, risky or faulty software gets approved for the installation at customers. | 1 | 1 | Quarterly | | Preventing (Manual) | Only the CTO is allowed to approve software to be installed on customer hardware after testing. | 1 | 1 | | | yes | yes | |
| 10 | CTO | Operational Risk (Support & Service) | Insufficient hardware resources for the application | 1 | 1 | Daily | | Preventing (Manual) | Tested system requirements are provided for the customers. | 1 | 1 | | | yes | yes | |
| 11 | CTO | Operational Risk (Support & Service) | Leaking customer data incl. server login names and passwords. | 1 | 1 | Daily | | Preventing (Manual) | No customer data incl. server login names or passwords are stored on the organization side. | 1 | 1 | | | yes | yes | |
| 12 | CTO | Operational Risk (Support & Service) | Not all necessary steps are executed during the application setup or faulty. | 1 | 1 | Daily | | Preventing (Manual) | A Application Install Checklist is provided which has to be used during the install process. | 1 | 1 | | | yes | yes | |
| 13 | CTO | Operational Risk (Support & Service) | The trainings don't cover important aspects. | 1 | 1 | Daily | | Preventing (Manual) | Trainings must be held according to the Training Manuals defined by the CTO. | 1 | 1 | | | yes | yes | |
| 14 | CTO | Operational Risk (Support & Service) | The maintenance doesn't cover important aspects. | 1 | 1 | Daily | | Preventing (Manual) | Maintenance must be performed according to the Maintenance Checklist defined by the CTO. | 1 | 1 | | | yes | yes | |
| 15 | HOCS | Operational Risk (Support & Service) | Support requests from customers are handled by people who don't have the necessary skills or experiences. | 1 | 1 | | | Preventing (Manual) | Support requests are assigned according to experiences and skillsets by team leaders, senior employees or the HOCS. | 1 | 1 | | | yes | yes | |
| 16 | CTO | Operational Risk (Support & Service) | The provided support is not satisfactory for the customers. | 1 | 1 | | | Revealing (Manual) | Customers have the option to provide feedback after every closed support request. | 1 | 1 | | | yes | yes | |
## Abbreviations

70
Processes/05_HR_Risk Control Matrix.md
View File

@ -1,40 +1,40 @@
# HR Risk Control Matrix
| No. | R | Category | Risk Event | L | C | O | Cause | Mitigation Type | Mitigation Strategy | L* | C* | Changes | Comments | ES | EY |
| ---- | ---- | --------------------- | ------------------------------------------------------------ | ---- | ---- | ---- | ----- | --------------------------- | ------------------------------------------------------------ | ---- | ---- | ------- | -------- | ---- | ---- |
| 1 | DHR | Operational Risk (HR) | Unauthorized search for new employees. | 1 | 1 | | | Preventing (Manual) | Only selected people can authorize the employee search. | 1 | 1 | | | yes | yes |
| 2 | DHR | Operational Risk (HR) | Job postings are not posted according to the legal requirements. | 1 | 1 | | | Preventing (Manual) | Job postings must be posted internally and at the agency for labor. | 1 | 1 | | | yes | yes |
| 3 | DHR | Operational Risk (HR) | The job postings are inconsistent or miss important information. | 1 | 1 | | | Preventing (Manual) | The DHR maintains a standard job posting layout. | 1 | 1 | | | yes | yes |
| 4 | DHR | Operational Risk (HR) | The job postings are inconsistent or miss important information. | 1 | 1 | | | Preventing (Manual) | The DHR maintains a standard job descriptions for the different positions which should be used as a basis. | 1 | 1 | | | yes | yes |
| 5 | DHR | Operational Risk (HR) | Not matching applications are considered for the job posting. | 1 | 1 | | | Preventing (Manual) | The HR department reviews every application and filters obviously mismatching applications. | 1 | 1 | | | yes | yes |
| 6 | DHR | Operational Risk (HR) | Applications of candidates get rejected only because of minor mismatches. | 1 | 1 | | | Preventing (Manual) | Minor mismatches are allowed if the candidate fits the overall position. | 1 | 1 | | | yes | yes |
| 7 | DHR | Operational Risk (HR) | Applications are handled with biases. | 1 | 1 | | | Preventing (Manual) | Applications are anonymized by the HR department. | 1 | 1 | | | yes | yes |
| 8 | DHR | Operational Risk (HR) | Applicants don't receive a feedback leading to bad reviews. | 1 | 1 | | | Preventing (Manual) | The HR department has to reject mismatching applications in a timely manner using a default rejection text. | 1 | 1 | | | yes | yes |
| 9 | DHR | Operational Risk (HR) | Applicants are sanctioned. | 1 | 1 | | | Revealing (System + Manual) | Applicants are checked by the HR department in a software for sanctions. | 1 | 1 | | | yes | yes |
| 10 | DHR | Operational Risk (HR) | References of applicants are invalid. | 1 | 1 | | | Revealing (Manual) | The HR department performs random checks of references. | 1 | 1 | | | yes | yes |
| 11 | DHR | Operational Risk (HR) | Applicants are chosen despite majority differences in the selection committee. | 1 | 1 | | | Preventing (Manual) | All selection committee members have equal voting rights. | 1 | 1 | | | yes | yes |
| 12 | DHR | Operational Risk (HR) | Missing critical contractual aspects. | 1 | 1 | | | Preventing (Manual) | The HR department has to use a sample contract which contains all important contractual standard aspects. | 1 | 1 | | | yes | yes |
| 13 | DHR | Operational Risk (HR) | The applicant receives an unapproved contract. | 1 | 1 | | | Preventing (Manual) | The DHR must approve a contract before it can be sent to the applicant. | 1 | 1 | | | yes | yes |
| 14a | DHR | Operational Risk (HR) | An applicant gets employed who didn't get selected by the majority of the selection committee. | 1 | 1 | | | Preventing (Manual) | The DHR checks if the applicant got selected through a majority vote by the selection committee. | 1 | 1 | | | yes | yes |
| 14b | DHR | Operational Risk (HR) | The applicant didn't submit any credentials for aspects mentioned in their CV. | 1 | 1 | | | Preventing (Manual) | The DHR checks if the applicant submitted the credentials for aspects mentioned in their CV. | 1 | 1 | | | yes | yes |
| 14c | DHR | Operational Risk (HR) | The credentials are invalid. | 1 | 1 | | | Preventing (Manual) | The DHR checks if the credentials were successfully verified (random checks) | 1 | 1 | | | yes | yes |
| 14d | DHR | Operational Risk (HR) | The contract signed by the applicant is unaltered. | 1 | 1 | | | Preventing (Manual) | The DHR checks if the contract is unaltered. | 1 | 1 | | | yes | yes |
| 14e | DHR | Operational Risk (HR) | No or altered NDA is signed. | 1 | 1 | | | Preventing (Manual) | The DHR checks if the unaltered NDA is signed. | 1 | 1 | | | yes | yes |
| 14f | DHR | Operational Risk (HR) | No or altered CLA is signed. | 1 | 1 | | | Preventing (Manual) | The DHR checks if the unaltered CLA is signed. | 1 | 1 | | | yes | yes |
| 14g | DHR | Operational Risk (HR) | No or altered privacy policy is signed. | 1 | 1 | | | Preventing (Manual) | The DHR checks if the unaltered privacy policy is signed. | 1 | 1 | | | yes | yes |
| 14h | DHR | Operational Risk (HR) | Employee has a criminal record which prevent their employement. | 1 | 1 | | | Preventing (Manual) | The DHR checks if criminal record certificate is negative. | 1 | 1 | | | yes | yes |
| 14i | DHR | Operational Risk (HR) | Employee has sanctions which prevent their employment. | 1 | 1 | | | Preventing (Manual) | The DHR checks if sanction check is negative. | 1 | 1 | | | yes | yes |
| 14j | DHR | Operational Risk (HR) | The applicant tax id is missing. | 1 | 1 | | | Preventing (Manual) | The DHR checks if the applicants tax id is available. | 1 | 1 | | | yes | yes |
| 14k | DHR | Operational Risk (HR) | The applicant has no work permit even though it is required for this employee. | 1 | 1 | | | Preventing (Manual) | The DHR checks if the work permit is available. | 1 | 1 | | | yes | yes |
| 15 | DHR | Operational Risk (HR) | The contract for the applicant is signed by unauthorized personnel. | 1 | 1 | | | Preventing (Manual) | The DHR only hands over the contract for signing to authorized personnel. | 1 | 1 | | | yes | yes |
| 16 | DHR | Operational Risk (HR) | Training plans are inconsistent or miss critical components. | 1 | 1 | | | Preventing (Manual) | A sample training plan must be used as a basis. | 1 | 1 | | | yes | yes |
| 17 | DHR | Operational Risk (HR) | The employee is not completely trained. | 1 | 1 | | | Preventing (Manual) | The employee must sign the training plan after completion confirming their training. | 1 | 1 | | | yes | yes |
| 18 | DHR | Operational Risk (HR) | The employee doesn't receive any feedback regarding their performance. | 1 | 1 | | | Preventing (Manual) | Annual employee evaluations take place by supervisors. | 1 | 1 | | | yes | yes |
| 19 | DHR | Operational Risk (HR) | The employee evaluation and performance is not shared with the HR department which leads to problems during salary negotiations. | 1 | 1 | | | Preventing (Manual) | The employee evaluation must be handed over by the supervisor to the HR department who store this evaluation in the employee file. | 1 | 1 | | | yes | yes |
| 20 | DHR | Operational Risk (HR) | The employee evaluation doesn't take place. | 1 | 1 | | | Preventing (Manual) | The HR department checks that all evaluations have taken place and reminds the supervisors. | 1 | 1 | | | yes | yes |
| 21 | DHR | Operational Risk (HR) | The employee evaluation by the supervisor and the employees self-assessment are apart. | 1 | 1 | | | Preventing (Manual) | The employee must provide a self-evaluation before the employee evaluation takes place which allows both sides to reconcile the differences. | 1 | 1 | | | yes | yes |
| 22 | DHR | Operational Risk (HR) | The organization is unattractive for employees. | 1 | 1 | | | Preventing (Manual) | Employees have a annual chance to create a anonymous company evaluation which gets evaluated by the HR department and discussed in the executive committee meeting. | 1 | 1 | | | yes | yes |
| 23 | DHR | Operational Risk (HR) | The employee gets put on sanction lists after joining the company. | 1 | 1 | | | Revealing (System) | All employees are checked automatically every day by a sanction software. | 1 | 1 | | | yes | yes |
| No. | R | Category | Risk Event | L | C | O | Cause | Mitigation Type | Mitigation Strategy | L* | C* | Changes | Comments | ES | EY | Evidences |
| ---- | ---- | --------------------- | ------------------------------------------------------------ | ---- | ---- | ---- | ----- | --------------------------- | ------------------------------------------------------------ | ---- | ---- | ------- | -------- | ---- | ---- | --------- |
| 1 | DHR | Operational Risk (HR) | Unauthorized search for new employees. | 1 | 1 | | | Preventing (Manual) | Only selected people can authorize the employee search. | 1 | 1 | | | yes | yes | |
| 2 | DHR | Operational Risk (HR) | Job postings are not posted according to the legal requirements. | 1 | 1 | | | Preventing (Manual) | Job postings must be posted internally and at the agency for labor. | 1 | 1 | | | yes | yes | |
| 3 | DHR | Operational Risk (HR) | The job postings are inconsistent or miss important information. | 1 | 1 | | | Preventing (Manual) | The DHR maintains a standard job posting layout. | 1 | 1 | | | yes | yes | |
| 4 | DHR | Operational Risk (HR) | The job postings are inconsistent or miss important information. | 1 | 1 | | | Preventing (Manual) | The DHR maintains a standard job descriptions for the different positions which should be used as a basis. | 1 | 1 | | | yes | yes | |
| 5 | DHR | Operational Risk (HR) | Not matching applications are considered for the job posting. | 1 | 1 | | | Preventing (Manual) | The HR department reviews every application and filters obviously mismatching applications. | 1 | 1 | | | yes | yes | |
| 6 | DHR | Operational Risk (HR) | Applications of candidates get rejected only because of minor mismatches. | 1 | 1 | | | Preventing (Manual) | Minor mismatches are allowed if the candidate fits the overall position. | 1 | 1 | | | yes | yes | |
| 7 | DHR | Operational Risk (HR) | Applications are handled with biases. | 1 | 1 | | | Preventing (Manual) | Applications are anonymized by the HR department. | 1 | 1 | | | yes | yes | |
| 8 | DHR | Operational Risk (HR) | Applicants don't receive a feedback leading to bad reviews. | 1 | 1 | | | Preventing (Manual) | The HR department has to reject mismatching applications in a timely manner using a default rejection text. | 1 | 1 | | | yes | yes | |
| 9 | DHR | Operational Risk (HR) | Applicants are sanctioned. | 1 | 1 | | | Revealing (System + Manual) | Applicants are checked by the HR department in a software for sanctions. | 1 | 1 | | | yes | yes | |
| 10 | DHR | Operational Risk (HR) | References of applicants are invalid. | 1 | 1 | | | Revealing (Manual) | The HR department performs random checks of references. | 1 | 1 | | | yes | yes | |
| 11 | DHR | Operational Risk (HR) | Applicants are chosen despite majority differences in the selection committee. | 1 | 1 | | | Preventing (Manual) | All selection committee members have equal voting rights. | 1 | 1 | | | yes | yes | |
| 12 | DHR | Operational Risk (HR) | Missing critical contractual aspects. | 1 | 1 | | | Preventing (Manual) | The HR department has to use a sample contract which contains all important contractual standard aspects. | 1 | 1 | | | yes | yes | |
| 13 | DHR | Operational Risk (HR) | The applicant receives an unapproved contract. | 1 | 1 | | | Preventing (Manual) | The DHR must approve a contract before it can be sent to the applicant. | 1 | 1 | | | yes | yes | |
| 14a | DHR | Operational Risk (HR) | An applicant gets employed who didn't get selected by the majority of the selection committee. | 1 | 1 | | | Preventing (Manual) | The DHR checks if the applicant got selected through a majority vote by the selection committee. | 1 | 1 | | | yes | yes | |
| 14b | DHR | Operational Risk (HR) | The applicant didn't submit any credentials for aspects mentioned in their CV. | 1 | 1 | | | Preventing (Manual) | The DHR checks if the applicant submitted the credentials for aspects mentioned in their CV. | 1 | 1 | | | yes | yes | |
| 14c | DHR | Operational Risk (HR) | The credentials are invalid. | 1 | 1 | | | Preventing (Manual) | The DHR checks if the credentials were successfully verified (random checks) | 1 | 1 | | | yes | yes | |
| 14d | DHR | Operational Risk (HR) | The contract signed by the applicant is unaltered. | 1 | 1 | | | Preventing (Manual) | The DHR checks if the contract is unaltered. | 1 | 1 | | | yes | yes | |
| 14e | DHR | Operational Risk (HR) | No or altered NDA is signed. | 1 | 1 | | | Preventing (Manual) | The DHR checks if the unaltered NDA is signed. | 1 | 1 | | | yes | yes | |
| 14f | DHR | Operational Risk (HR) | No or altered CLA is signed. | 1 | 1 | | | Preventing (Manual) | The DHR checks if the unaltered CLA is signed. | 1 | 1 | | | yes | yes | |
| 14g | DHR | Operational Risk (HR) | No or altered privacy policy is signed. | 1 | 1 | | | Preventing (Manual) | The DHR checks if the unaltered privacy policy is signed. | 1 | 1 | | | yes | yes | |
| 14h | DHR | Operational Risk (HR) | Employee has a criminal record which prevent their employement. | 1 | 1 | | | Preventing (Manual) | The DHR checks if criminal record certificate is negative. | 1 | 1 | | | yes | yes | |
| 14i | DHR | Operational Risk (HR) | Employee has sanctions which prevent their employment. | 1 | 1 | | | Preventing (Manual) | The DHR checks if sanction check is negative. | 1 | 1 | | | yes | yes | |
| 14j | DHR | Operational Risk (HR) | The applicant tax id is missing. | 1 | 1 | | | Preventing (Manual) | The DHR checks if the applicants tax id is available. | 1 | 1 | | | yes | yes | |
| 14k | DHR | Operational Risk (HR) | The applicant has no work permit even though it is required for this employee. | 1 | 1 | | | Preventing (Manual) | The DHR checks if the work permit is available. | 1 | 1 | | | yes | yes | |
| 15 | DHR | Operational Risk (HR) | The contract for the applicant is signed by unauthorized personnel. | 1 | 1 | | | Preventing (Manual) | The DHR only hands over the contract for signing to authorized personnel. | 1 | 1 | | | yes | yes | |
| 16 | DHR | Operational Risk (HR) | Training plans are inconsistent or miss critical components. | 1 | 1 | | | Preventing (Manual) | A sample training plan must be used as a basis. | 1 | 1 | | | yes | yes | |
| 17 | DHR | Operational Risk (HR) | The employee is not completely trained. | 1 | 1 | | | Preventing (Manual) | The employee must sign the training plan after completion confirming their training. | 1 | 1 | | | yes | yes | |
| 18 | DHR | Operational Risk (HR) | The employee doesn't receive any feedback regarding their performance. | 1 | 1 | | | Preventing (Manual) | Annual employee evaluations take place by supervisors. | 1 | 1 | | | yes | yes | |
| 19 | DHR | Operational Risk (HR) | The employee evaluation and performance is not shared with the HR department which leads to problems during salary negotiations. | 1 | 1 | | | Preventing (Manual) | The employee evaluation must be handed over by the supervisor to the HR department who store this evaluation in the employee file. | 1 | 1 | | | yes | yes | |
| 20 | DHR | Operational Risk (HR) | The employee evaluation doesn't take place. | 1 | 1 | | | Preventing (Manual) | The HR department checks that all evaluations have taken place and reminds the supervisors. | 1 | 1 | | | yes | yes | |
| 21 | DHR | Operational Risk (HR) | The employee evaluation by the supervisor and the employees self-assessment are apart. | 1 | 1 | | | Preventing (Manual) | The employee must provide a self-evaluation before the employee evaluation takes place which allows both sides to reconcile the differences. | 1 | 1 | | | yes | yes | |
| 22 | DHR | Operational Risk (HR) | The organization is unattractive for employees. | 1 | 1 | | | Preventing (Manual) | Employees have a annual chance to create a anonymous company evaluation which gets evaluated by the HR department and discussed in the executive committee meeting. | 1 | 1 | | | yes | yes | |
| 23 | DHR | Operational Risk (HR) | The employee gets put on sanction lists after joining the company. | 1 | 1 | | | Revealing (System) | All employees are checked automatically every day by a sanction software. | 1 | 1 | | | yes | yes | |
## Abbreviations

12
Processes/06_Finance.md
View File

@ -100,21 +100,21 @@ The taxes should be estimated based on the EBIT and the local tax rate. Correcti
### Deadline
The deadline is the 4th work day of the following month.
The deadline is the 5th work day of the following month.
### Responsibilities
The tasks and responsibilities can be found in the [Monthly Closing Checklist](Finance/Financial%20Closing/Monthly%Closing%20Checklist.md). The checklist must be signed by every responsible person after completing the defined task. (**R7**)
The tasks and responsibilities can be found in the [Monthly Closing Checklist](./Finance/Financial%20Closing/Monthly%20Closing%20Checklist.md). The checklist must be signed by every responsible person after completing the defined task. (**R7**)
## Annual closing
### Deadline
The deadline is the 4th work day of the new fiscal year.
The deadline is the 5th work day of the new fiscal year.
### Responsibilities
The tasks and responsibilities can be found in the [Monthly Closing Checklist](Finance/Financial%20Closing/Monthly%Closing%20Checklist.md) and additionally the [Annual Closing Checklist](Finance/Financial%20Closing/Annual%Closing%20Checklist.md). The checklists must be signed by every responsible person after completing the defined task. (**R8**)
The tasks and responsibilities can be found in the [Monthly Closing Checklist](./Finance/Financial%20Closing/Monthly%20Closing%20Checklist.md) and additionally the [Annual Closing Checklist](./Finance/Financial%20Closing/Annual%20Closing%20Checklist.md). The checklists must be signed by every responsible person after completing the defined task. (**R8**)
## Annual financial audit
@ -124,7 +124,7 @@ The deadline for the audit preparation is 3 days before the audit takes place.
### Responsibilities
The tasks and responsibilities can be found in the [Annual Audit Checklist](Finance/Financial%20Closing/Annual%20Audit%20Checklist.md). The checklist must be signed by every responsible person after completing the defined task. (**R9**)
The tasks and responsibilities can be found in the [Annual Audit Checklist](./Finance/Financial%20Closing/Annual%20Audit%20Checklist.md). The checklist must be signed by every responsible person after completing the defined task. (**R9**)
## Reporting
@ -136,7 +136,7 @@ The deadline is the 5th work day of the following month.
### Responsibilities
The tasks and responsibilities can be found in the [Monthly Reporting Checklist](Finance/Reporting/Monthly%20Reporting%20Checklist.md). The checklist must be signed by every responsible person after completing the defined task. (**R10**)
The tasks and responsibilities can be found in the [Monthly Reporting Checklist](./Finance/Reporting/Monthly%20Reporting%20Checklist.md). The checklist must be signed by every responsible person after completing the defined task. (**R10**)

119
Processes/06_Finance_Flowchart.md
View File

@ -1,7 +1,124 @@
# Finance Flowchart
## Budget
```mermaid
graph TD;
ASDF
DEFINE_TIMELINE([CFO: Defines timeline])-->CREATE_BUDGET_TEMPLATES[Finances: Create budget templates];
CREATE_BUDGET_TEMPLATES-->PRODUCT_TEMPLATE[CTO: Product budget]
PRODUCT_TEMPLATE-->SALES_TEMPLATE[CSO: Sales budget];
SALES_TEMPLATE-->MARKETING_TEMPLATE[CSO+HOM: Marketing budget];
CREATE_BUDGET_TEMPLATES-->HR_TEMPLATE[DHR: HR budget];
CREATE_BUDGET_TEMPLATES-->HOD_TEMPLATE[HOD: Department budget];
CREATE_BUDGET_TEMPLATES-->FINANCE_TEMPLATE[CFO: OPEX, etc. budget];
MARKETING_TEMPLATE-->COMBINE1[Finances: Combines budgets];
HR_TEMPLATE-->COMBINE1;
HOD_TEMPLATE-->COMBINE1;
FINANCE_TEMPLATE-->COMBINE1;
COMBINE1-->MEETINGS1[CEO+CFO: Individual meetings with HOD];
MEETINGS1-->IS_GOOD1{CEO: Is accepted?};
IS_GOOD1--No-->REITERATE[HOD: Re-iterate];
REITERATE-->MEETINGS1;
IS_GOOD1--Yes-->BUDGET_DOC[CFO: Create budget document];
BUDGET_DOC-->IS_GOOD2{CEO: Is accepted?};
IS_GOOD2--No-->BUDGET_DOC;
IS_GOOD2--Yes-->IS_GOOD3{Shareholder: Is accepted?};
IS_GOOD3--No-->REITERATE;
IS_GOOD3--Yes-->IMPLEMENT([CEO+CFO+HOD: Implement]);
```
```mermaid
gantt
dateFormat YYYY-MM-DD
title Sample: Annual financial budget
excludes weekends
axisFormat %m-%d
section General
Define timeline : des1, 2022-09-01, 1h
Prepare budget sheets : des2, 2022-09-01, 5d
section Budget by HOD
Product development : des3, after des2, 7d
Sales : des4, after des3, 7d
Marketing : des5, after des4, 7d
HR : des6, after des2, 14d
HOD : des7, after des2, 14d
OPEX, etc. : des8, after des2, 14d
Send back to finance :crit, des9, after des8, 1d
Combine budgets : des10, after des9, 3d
section Meetings
Product development : des11, after des10, 1d
Sales : des12, after des11, 1d
Marketing : des13, after des12, 1d
HR : des14, after des13, 1d
Head of departments : des15, after des14, 1d
Finance : des16, after des15, 1d
section Finalization
Re-iterate budget : des17, after des16, 10d
CEO meetings : des18, after des17, 4d
Re-iterate budget : des19, after des18, 5d
CEO meetings : des20, after des19, 2d
section Approval
Budget document : des21, after des20, 10d
CEO approval : des22, after des21, 1d
Re-iterate document : des23, after des22, 2d
CEO approval :crit, des24, after des23, 1d
Shareholder approval : des25, after des24, 5d
Re-iterate budget : des26, after des25, 15d
Shareholder approval :crit, des27, after des26, 2d
Implementation :crit, des28, after des27, 5d
```
## Monthly closing
```mermaid
graph TD;
CLOSING([Finance: Closing])-->VERIFY_KEY_FIGURES1[Finance: Verify key figures];
CLOSING-->MONTH_END_POSTINGS[Finance: Create month end postings];
VERIFY_KEY_FIGURES1-->CREATE_REPORTING[CFO: Create reporting];
MONTH_END_POSTINGS-->CREATE_REPORTING;
CREATE_REPORTING-->VERIFY_KEY_FIGURES2[CFO: Verify reporting];
VERIFY_KEY_FIGURES2-->SUBMIT1([CFO: Submit reporting to executive committee]);
VERIFY_KEY_FIGURES2-->SUBMIT2([CFO: Submit department KPI to HOD]);
```
```mermaid
gantt
dateFormat YYYY-MM-DD
title Sample: Monthly financial closing
excludes weekends
axisFormat %d
section General
Inform HOD about closing : des1, 2022-08-01, 1h
Verify bank : des2, 2022-08-03, 1h
section Postings
Normal invoices : des3, 2022-08-01, 3d
Wages : des4, 2022-08-02, 4h
Bad debt : des5, 2022-08-02, 2h
Accruals & deferrals : des6, 2022-08-03, 3h
Depreciation : des7, after des6, 2h
section Reporting
Sales : des8, 2022-08-04, 1h
Income statement : des9, after des8, 1h
Balance : des10, after des9, 1h
Investments : des11, after des10, 30m
Cash : des12, after des11, 30m
HR reporting : des13, after des12, 1h
KPI reports : des14, after des13, 1h
Verify reporting : des15, after des14, 1h
section Submit
Submit to ExeCom : des16, 2022-08-05, 1h
Submit KPI to HOD : des17, 2022-08-05, 1h
```
2022-01-01 - Version 1.0firefod

24
Processes/06_Finance_Risk Control Matrix.md
View File

@ -1,17 +1,17 @@
# Finance Risk Control Matrix
| No. | R | Category | Risk Event | L | C | O | Cause | Mitigation Type | Mitigation Strategy | L* | C* | Changes | Comments | ES | EY |
| ---- | ---- | -------------------------- | ------------------------------------------------------------ | ---- | ---- | ---- | ----- | ------------------------------------------------------------ | ------------------------------------------------------------ | ---- | ---- | ------- | -------- | ---- | ---- |
| 1 | CFO | Operational Risk (Finance) | The company doesn't have a budget as a basis for their operations. | 1 | 1 | | | | The deadline for the budget finalization is defined with enough time until the new business year starts. | 1 | 1 | | | yes | yes |
| 2 | CFO | Operational Risk (Finance) | The budget is not approved/reviewed. | 1 | 1 | | | | The budget must be approved by the management. | 1 | 1 | | | yes | yes |
| 3 | CFO | Operational Risk (Finance) | No approved budget. | 1 | 1 | | | Budget amendments are necessary. Budget didn't get finished on time. | The management can approve a intermediate budget until the final budget is created and approved. | 1 | 1 | | | yes | yes |
| 4 | CFO | Operational Risk (Finance) | The responsibilities during the budgeting process are not defined. | 1 | 1 | | | | The tasks and responsibilities are defined in a budget checklist. | 1 | 1 | | | yes | yes |
| 5 | CFO | Operational Risk (Finance) | The budget is not broken down on a monthly basis making it difficult to validate the performance. | 1 | 1 | | | | The budget is split up on a single month basis. | 1 | 1 | | | yes | yes |
| 6 | CFO | Operational Risk (Finance) | Important information are missing. | 1 | 1 | | | | Budget information are collected from different departments. | 1 | 1 | | | yes | yes |
| 7 | CFO | Operational Risk (Finance) | The monthly closing tasks are not well defined. | 1 | 1 | | | | A monthly closing checklist exists defining the responsibilities. | 1 | 1 | | | yes | yes |
| 8 | CFO | Operational Risk (Finance) | The annual closing tasks are not well defined. | 1 | 1 | | | | An annual closing checklist exists defining the responsibilities. | 1 | 1 | | | yes | yes |
| 9 | CFO | Operational Risk (Finance) | The annual financial audit tasks are not well defined. | 1 | 1 | | | | An audit checklist exists defining the responsibilities. | 1 | 1 | | | yes | yes |
| 10 | CFO | Operational Risk (Finance) | The reporting tasks are not well defined. | 1 | 1 | | | | A reporting checklist exists defining the responsibilities. | 1 | 1 | | | yes | yes |
| No. | R | Category | Risk Event | L | C | O | Cause | Mitigation Type | Mitigation Strategy | L* | C* | Changes | Comments | ES | EY | Evidences |
| ---- | ---- | -------------------------- | ------------------------------------------------------------ | ---- | ---- | ---- | ------------------------------------------------------------ | --------------- | ------------------------------------------------------------ | ---- | ---- | ------- | -------- | ---- | ---- | --------- |
| 1 | CFO | Operational Risk (Finance) | The company doesn't have a budget as a basis for their operations. | 1 | 1 | | | | The deadline for the budget finalization is defined with enough time until the new business year starts. | 1 | 1 | | | yes | yes | |
| 2 | CFO | Operational Risk (Finance) | The budget is not approved/reviewed. | 1 | 1 | | | | The budget must be approved by the management. | 1 | 1 | | | yes | yes | |
| 3 | CFO | Operational Risk (Finance) | No approved budget. | 1 | 1 | | Budget amendments are necessary. Budget didn't get finished on time. | | The management can approve a intermediate budget until the final budget is created and approved. | 1 | 1 | | | yes | yes | |
| 4 | CFO | Operational Risk (Finance) | The responsibilities during the budgeting process are not defined. | 1 | 1 | | | | The tasks and responsibilities are defined in a budget checklist. | 1 | 1 | | | yes | yes | |
| 5 | CFO | Operational Risk (Finance) | The budget is not broken down on a monthly basis making it difficult to validate the performance. | 1 | 1 | | | | The budget is split up on a single month basis. | 1 | 1 | | | yes | yes | |
| 6 | CFO | Operational Risk (Finance) | Important information are missing. | 1 | 1 | | | | Budget information are collected from different departments. | 1 | 1 | | | yes | yes | |
| 7 | CFO | Operational Risk (Finance) | The monthly closing tasks are not well defined. | 1 | 1 | | | | A monthly closing checklist exists defining the responsibilities. | 1 | 1 | | | yes | yes | |
| 8 | CFO | Operational Risk (Finance) | The annual closing tasks are not well defined. | 1 | 1 | | | | An annual closing checklist exists defining the responsibilities. | 1 | 1 | | | yes | yes | |
| 9 | CFO | Operational Risk (Finance) | The annual financial audit tasks are not well defined. | 1 | 1 | | | | An audit checklist exists defining the responsibilities. | 1 | 1 | | | yes | yes | |
| 10 | CFO | Operational Risk (Finance) | The reporting tasks are not well defined. | 1 | 1 | | | | A reporting checklist exists defining the responsibilities. | 1 | 1 | | | yes | yes | |
## Abbreviations

28
Processes/07_Management.md
View File

@ -6,42 +6,42 @@
## Planning
The management has to plan and layout the vision as well as the strategy for the organization. This is documented in the [Business Plan](./Management/Business%20Plan.md) and annual budget described in the [Finance](./06_Finance.md) process.
The management has to plan and layout the vision as well as the strategy for the organization. This is documented in the [Business Plan](./Management/Business%20Plan.md) and annual budget described in the [Finance](./06_Finance.md) process. (**R1**)
## Organizing
### Implementation
The management has to check if the organizational structure fits the needs of the company or if changes/improvements need to be made. The company structure is defined in the [Organigram](./Organigram.md). This includes but is not limited to ensuring sufficient resources are available. Resources are checked during every meeting described in the [Information Flow](./Management/Information%20Flow.md). The management also determines how information is appropriately and effectively shared between the different employees. This is defined in the [Information Flow](./Management/Information%20Flow.md).
The management has to check if the organizational structure fits the needs of the company or if changes/improvements need to be made. The company structure is defined in the [Organigram](./Organigram.md). This includes but is not limited to ensuring sufficient resources are available. Resources are checked during every meeting described in the [Information Flow](./Management/Information%20Flow.md) and during the [employee evaluation](./HR/Evaluation%20Forms/Self-Evaluation%20Form.md). The management also determines how information is appropriately and effectively shared between the different employees. This is defined in the [Information Flow](./Management/Information%20Flow.md). (**R2**)
### Staffing
Staffing is handled primarily by the HR department. However the following aspects are handled as described below:
Staffing is handled primarily by the HR department. However the following aspects are handled as described below (**R3**):
* Hiring
* [HR](./05_HR.md) process
* Resource definition
* [Budget](./06_Finance.md)
* [Regular meetings](./Management/Information%20Flow.md) (i.e. [executive committee meeting](./Management/Executive%20Committee%20Minute%20Template.md))
* Training
* Training (**R4**)
* [Training plans](./HR/Onboarding/Sample%20Training%20Plan.md)
* [Employee evaluation](./HR/Evaluation%20Forms/Employee%20Evaluation%20Form.md)
## Leading
The leadership and responsibilities of the organization is defined in the [Organigram](./Organigram.md). Additionally, responsibilities are also defined in the processes, risk control matrices, [Document Owners](./Document%20Owners.md) and individual contracts.
The leadership and responsibilities of the organization is defined in the [Organigram](./Organigram.md). Additionally, responsibilities are also defined in the processes, risk control matrices, [Document Owners](./Document%20Owners.md) and individual contracts. (**R5**)
## Controlling
The following controlling instruments are implemented.
The following controlling instruments are implemented (**R6**).
* [Internal audits](./Quality%20Management/Internal%20Quality%Management%Audit%Form.md)
* [Risk Management](./COSO/Risk%20Management) and Process Risk Control Matrices
* [Whistleblower System](../Policies%20&%20Guidelines/Whistleblower%20System.md)
* Executive Committee Meeting where all key people exchange information
* [Regular meetings](./Information%20Flow.md) for information exchange
* Checklists as described in the processes
* External audits
* [Internal audits](./Quality%20Management/Internal%20Quality%Management%Audit%Form.md) (correctness & completeness: processes & guidelines)
* [Risk Management](./COSO/Risk%20Management) and Process Risk Control Matrices (risks)
* [Whistleblower System](../Policies%20&%20Guidelines/Whistleblower%20System.md) (compliance)
* Executive Committee Meeting (information sharing, controlling, planning and organizing)
* [Regular meetings](./Management/Information%20Flow.md) (information sharing, controlling, planning and organizing)
* Checklists as described in the processes (completeness)
* External audits (completeness and correctness)
* Tax audits (approx. every 3-5 years)
* Annual accounting audit
* Monthly financial reporting (e.g. cash, investments, sales, costs, deviations to budget/previous year)
@ -49,7 +49,7 @@ The following controlling instruments are implemented.
## Optimization
From the controlling activities optimizations arise which can be brought forward by anyone in [meetings](./Management/Information%20Flow.md) and changes can be made to the processes by the responsible persons defined in the [Document Owners](./Document%20Owners.md)
From the controlling activities optimizations arise which can be brought forward by anyone in [meetings](./Management/Information%20Flow.md) and changes can be made to the processes by the responsible persons defined in the [Document Owners](./Document%20Owners.md).

11
Processes/07_Management_Risk Control Matrix.md
View File

@ -1,8 +1,13 @@
# Management Risk Control Matrix
| No. | R | Category | Risk Event | L | C | O | Cause | Mitigation Type | Mitigation Strategy | L* | C* | Changes | Comments | ES | EY |
| ---- | ---- | -------- | ---------- | ---- | ---- | ---- | ----- | --------------- | ------------------- | ---- | ---- | ------- | -------- | ---- | ---- |
| 1 | | | | | | | | | | | | | | | |
| No. | R | Category | Risk Event | L | C | O | Cause | Mitigation Type | Mitigation Strategy | L* | C* | Changes | Comments | ES | EY | Evidences |
| ---- | ---- | ----------------------------- | ------------------------------------------------------------ | ---- | ---- | ---- | ----- | ------------------------------- | ------------------------------------------------------------ | ---- | ---- | ------- | -------- | ---- | ---- | ------------------------------------------------------------ |
| 1 | CEO | Operational Risk (Management) | The business operations are not planned appropriately (risks, chances, resources, ...). | | | | | Preventing (Manual) | Annual budget process as described in the finance process. | | | | | yes | yes | |
| 2 | CEO | Operational Risk (Management) | Critical information are not appropriately shared in the company. | | | | | Preventing (Manual) | Regular meetings such as executive committee meetings, head of department meetings and department meetings. Publicly available organization structure and processes which clearly communicate tasks and responsibilites. Annual employee evaluations for additional information sharing. | | | | | yes | yes | |
| 3 | CEO | Operational Risk (Management) | Insufficient resources (incl. HR) | | | | | Preventing & Revealing (Manual) | Resources are checked in various meetings, the budget process and during the annual employee evaluation. | | | | | yes | yes | |
| 4 | CEO | Operational Risk (Management) | Insufficient HR competencies | | | | | Preventing & Revealing (Manual) | HR competencies are evaluated in the hiring process and annual employee evaluations. The employee training is performed during the onboarding process and after identifying deficiencies during the annual employee evaluations. | | | | | yes | yes | |
| 5 | CEO | Operational Risk (Management) | Tasks and responsibilities are not clearly defined. | | | | | Preventing (Manual) | The leadership and responsibilities of the organization is defined in the Organigram. Additionally, responsibilities are also defined in the processes, risk control matrices, Document Owners and individual contracts. | | | | | yes | yes | |
| 6 | CEO | Operational Risk (Management) | Risks are not identified and/or prevented. | | | | | Revealing (Manual) | Various controling mechanisms are implemented to ensure the organization operating towards it's goals while considering risks and benefits. | | | | | yes | yes | [Internal audits](./Quality%20Management/Internal%20Quality%Management%Audit%Form.md)<br />[Risk Management](./COSO/Risk%20Management)<br />Process Risk Control Matrices<br />[Whistleblower System](../Policies%20&%20Guidelines/Whistleblower%20System.md)<br />Executive Committee Meeting<br />[Regular meetings](./Management/Information%20Flow.md)<br />Checklists as described in the processes<br />External audits<br />Monthly financial reporting<br />Quality control |
## Abbreviations

17
Processes/08_Quality Management.md
View File

@ -4,19 +4,24 @@
| ---------------------- | ----------------------------------- | -------- |
| High quality standards | Pass annual quality audit checklist | YES |
## Internal Audits
## Internal audits
### Internal Auditors
### Internal auditors
Internal auditors are chosen based on the following characteristics by the DQM:
* Trustworthy
* Incorruptible
* High intellect to evaluate and investigate quality deficiencies
* 3-5 internal auditors must be active in the company
### Audits
Every department needs to be audited once every quarter by an internal auditor who is not part of the department. The DQM organizes and controls these internal audits. The results of the internal audits must be documented by the internal auditors on the [Internal Quality Management Audit Form](./Quality%20Management/Internal%20Quality%20Management%20Audit%20Form.md).
The results of the internal audits are reviewed by the DQM and appropriate steps are taken by the DQM in case of audit findings.
The results of the internal audits are reviewed by the DQM and appropriate steps are taken by the DQM in case of audit findings. (**R1**)
## Quality Control
## Quality control
Quality control is performed manually and continuously. Additional quality control tasks besides the quality control activities which are directly implemented in the various processes are:
@ -27,9 +32,11 @@ Quality control is performed manually and continuously. Additional quality contr
* open bugs, time until bugs are closed
* open feature requests, time until feature requests are resolved
The quality management department can improve some of the *deficiencies* by themselves (i.e. documentation improvements) or create a quality control report for a specific supposed *deficiency* for further investigation in the project tasks. Some of the supposed *deficiencies* may be ruled as intended and will not require a change. This decision is made by the CTO together with the DQM.
The quality management department can improve some of the *deficiencies* by themselves (i.e. documentation improvements) or create a quality control report for a specific supposed *deficiency* for further investigation in the project tasks. Some of the supposed *deficiencies* may be ruled as intended and will not require a change. This decision is made by the CTO together with the DQM. (**R2**)
## Document management
The quality management department is responsible for ensuring the correctness, completeness and overall quality of the process documentation as well as the related documents. For this reason the quality management department has to check these documents once a year and ensure that all documents have the necessary approvals, are still up-to-date, correct and complete. The basis for this check is the [Document Owners](./Document%20Owners.md) list. (**R3**)
2022-01-01 - Version 1.0

17
Processes/08_Quality Management_Flowchart.md
View File

@ -1,11 +1,20 @@
# Quality Management Flowchart
## Internal Audit
## Internal audit
```mermaid
graph TD;
PICK_AUDITOR-->AUDIT
AUDIT-->FINDING
FINDING-->IMPROVEMENT
PICK_AUDITOR[DQM: Appoint internal auditor]-->AUDIT_APOINTMENT[DQM: Requests internal audit];
AUDIT_APOINTMENT-->AUDIT[Auditor: Perform audit];
AUDIT-->FINDING[Auditor: Report findings];
FINDING-->IMPROVEMENT[DQM: Implement measuers if necessary];
```
## Document management
```mermaid
graph TD;
DOCUMENT_OWNER_CHANGES([Owner: Draft document change])-->APPROVAL[Owner: Approval acc. to Document Owners list];
APPROVAL-->UPDATE([DQM: Replace old document with new version]);
```

11
Processes/08_Quality Management_Risk Control Matrix.md
View File

@ -1,8 +1,10 @@
# Quality Management Risk Control Matrix
| No. | R | Category | Risk Event | L | C | O | Cause | Mitigation Type | Mitigation Strategy | L* | C* | Changes | Comments | ES | EY |
| ---- | ---- | -------- | ---------- | ---- | ---- | ---- | ----- | --------------- | ------------------- | ---- | ---- | ------- | -------- | ---- | ---- |
| 1 | | | | | | | | | | | | | | | |
| No. | R | Category | Risk Event | L | C | O | Cause | Mitigation Type | Mitigation Strategy | L* | C* | Changes | Comments | ES | EY | Evidences |
| ---- | ---- | ------------------------------------- | ------------------------------------------------------------ | ---- | ---- | ---- | ----- | ------------------ | ------------------------------------------------------------ | ---- | ---- | ------- | -------- | ---- | ---- | --------- |
| 1 | CEO | Operational Risk (Quality Management) | Processes are not correctly implemented, no longer up-to-date or insufficient. | | | | | Revealing (Manual) | Every department is audited at least once a quarter by internal auditors. | | | | | | | |
| 2 | CEO | Operational Risk (Quality Management) | The products and services contain insuficciencies which are not detected during the regular development controls and checks. | | | | | Revealing (Manual) | The software, documentation and services are manually tested like a normal customer/user would use them. | | | | | | | |
| 3 | CEO | Operational Risk (Quality Management) | Processes and related documents are incomplete, incorrect or not correctly approved. | | | | | Revealing (Manual) | Internal audits and annual checks by the quality management department. | | | | | | | |
## Abbreviations
@ -22,4 +24,5 @@
2022-01-01 - Version 1.0
2022-01-01 - Version 1.0

4
Processes/09_IT.md.md
View File

@ -25,7 +25,7 @@ The IT department has to ensure that the IT systems are running according to the
### Permission changes
Permissions for data access must be handled carefully and users should only receive permissions according to their functions and tasks (**R6**). A General permission overview can be found in the Permission List and a guideline how to handle permission change requests is defined in the Change Management policy. This list contains a basic guideline for permission handlings but can be deviated from in special situations.
Permissions for data access must be handled carefully and users should only receive permissions according to their functions and tasks (**R6**). A General permission overview can be found in the Permission List and a guideline how to handle permission change requests is defined in the Change Management policy. This list contains a basic guideline for permission handling but can be deviated from in special situations. Deviations must be approved by the head of department and head of IT.
### Software changes
@ -35,5 +35,7 @@ New software or software updates must be tested by the IT team in a sandbox envi
The IT Security policy defines additional best practices and guidelines how to handle IT security.
2022-01-01 - Version 1.0

55
Processes/09_IT_Flowchart.md
View File

@ -0,0 +1,55 @@
# IT Flowchart
## Daily backup
```mermaid
graph TD;
CHECK_CHANGES([System: Check changes])-->CREATE_LOCAL_BACKUP[System: Create/update backup];
CREATE_LOCAL_BACKUP-->VALIDATE_LOCAL[System: Validate local backup];
VALIDATE_LOCAL-->IS_VALID1{System: Is valid?};
IS_VALID1--Yes-->COPY_ONLINE[System: Copy backup to cloud];
IS_VALID1--No-->REPORT[System: Inform IT department];
COPY_ONLINE-->VALIDATE_ONLINE[System: Validate remote backup];
VALIDATE_ONLINE-->IS_VALID2{System: Is valid?};
IS_VALID2--No-->REPORT;
```
## Permission changes
```mermaid
graph TD;
REQUEST_HOD([Request from HOD])--->IT_CHECKS{IT: Other approvals necessary?};
REQUEST_STAFF([Request from employee])-->APPROVAL_HOD[Approval by HOD];
APPROVAL_HOD-->IT_CHECKS;
IT_CHECKS--Yes-->FORWARD[IT: Forward request];
FORWARD-->APPROVAL_RESPONSIBLE[Approval by responsible person];
APPROVAL_RESPONSIBLE-->VALIDATE{IT: Is approved and appropriate?};
IT_CHECKS--No-->VALIDATE;
VALIDATE--Yes-->IMPLEMENT[IT: Implement permission changes];
VALIDATE--No-->INFORM([IT: Inform employee and HOD]);
IMPLEMENT-->INFORM;
```
## Software changes
```mermaid
graph TD;
REQUEST_HOD([Request from HOD])--->IT_CHECKS{IT: Other approvals necessary?};
REQUEST_STAFF([Request from employee])-->APPROVAL_HOD[Approval by HOD];
APPROVAL_HOD-->IT_CHECKS;
IT_CHECKS--Yes-->FORWARD[IT: Forward request];
FORWARD-->APPROVAL_RESPONSIBLE[Approval by responsible person];
APPROVAL_RESPONSIBLE-->VALIDATE{IT: Is approved and appropriate?};
IT_CHECKS--No-->VALIDATE;
VALIDATE--Yes-->IMPLEMENT[IT: Implement change in test environment];
VALIDATE--No-->INFORM([IT: Inform employee and HOD]);
IMPLEMENT-->INFORM;
INFORM-->TEST[Employee/HOD: Test change];
TEST-->VALIDATE_TEST[IT: Test successful?];
VALIDATE_TEST--Yes-->MIGRATE[IT: Migrate change to live];
```
2022-01-01 - Version 1.0

25
Processes/09_IT_Risk Control Matrix.md
View File

@ -0,0 +1,25 @@
# Quality Management Risk Control Matrix
| No. | R | Category | Risk Event | L | C | O | Cause | Mitigation Type | Mitigation Strategy | L* | C* | Changes | Comments | ES | EY | Evidences |
| ---- | ---- | -------- | ---------- | ---- | ---- | ---- | ----- | --------------- | ------------------- | ---- | ---- | ------- | -------- | ---- | ---- | --------- |
| 1 | | | | | | | | | | | | | | | | |
## Abbreviations
* R: Responsible
* L: Likelihood (1-5)
* C: Consequence (1-5)
* L\*/C\*: Likelihood and Consequence after mitigation
* O: Occurrence (many times a day, daily, weekly, monthly, annually)
* ES: Effective
* EY: Efficient
2022-01-01 - Version 1.0

2
Processes/COSO/CLC.md
View File

@ -1,6 +1,6 @@
# Company Level Controls (CLC)
| No. | Component | Control Area | Question | Answer | Evidence |
| No. | Component | Control Area | Question | Answer | Evidences |
| ---- | ----------------------------- | ------------------------------------- | ------------------------------------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------ |
| 1 | Control Environment | Principle of financial reporting | Do you have basic financial reporting policies? | Yes, the organization follows the German law regarding financial reporting and internal reporting guidelines. | Financial laws (i.e. HGB, AO, Ustg, ...)<br />Policies: Reporting<br />Process: Finance |
| 2 | Control Environment | Understanding accounting policies | Are the selected accounting principles approved? | Yes, employees are required to act according to the the German law and follow the accounting policies. | Financial laws (i.e. HGB, AO, Ustg, ...)<br />Policies: Accounting |

56
Processes/COSO/ITGC.md
View File

@ -11,7 +11,7 @@
## General
| No. | Component | Control Area | Question | Answer | Evidence |
| No. | Component | Control Area | Question | Answer | Evidences |
| ---- | --------- | ------------ | ------------------------------------------------------------ | ------------------------------------------------------------ | ----------------------------------------------- |
| | IT | IT Strategy | Do you have a IT investment strategy or plan? | Yes, investments are evaluated at least annually during the budget process. Additionally, resources are also checked regularly (e.g. executive committee meeting). | Budget<br />Executive Committee Meeting Minutes |
| | IT | IT Strategy | Are the IT investment strategies or plans reviewed and approved by the management? | Yes, during the budget process and if outside the budget in the executive committee meeting. | Budget<br />Executive Committee Meeting Minutes |
@ -20,7 +20,7 @@
### Points to consider
| Overview | Component | Situation | Evidence |
| Overview | Component | Situation | Evidences |
| -------------------- | --------- | ------------------------------------------------------------ | ---------------------------------- |
| Frequency of changes | A | Often changes are required for various reasons (e.g. functionality enhancement changes in business processes, etc.) | CHANGELOG<br />Software validation |
| Frequency of changes | OS, DB | Changes are made for each release of security patches/upgrades | Software validation |
@ -28,7 +28,7 @@
### Assessment of Design Effectiveness
| No. | Question | Component | Situation | Evidence |
| No. | Question | Component | Situation | Evidences |
| ---- | ------------------------------------------------------------ | --------------- | ------------------------------------------------------------ | ------------------------------------------------------------ |
| 1 | Policies and procedures for development and maintenance are described in a formal way | A, OS, DB, N, O | Documentations are prepared by the IT team and authorized by the head of IT | Process: Development<br />Process: Support & Service<br />Policies: IT |
| 2 | Roles and responsibilities concerning development and maintenance are clearly defined | A, OS, DB, N, O | IT personnel incl. service vendors perform changes | Process: Development<br />Process: Support & Service<br />Organigram |
@ -40,7 +40,7 @@
### Points to consider
| Question | Component | Situation | Evidence |
| Question | Component | Situation | Evidences |
| ------------------------------------------------------------ | ------------ | ------------------------------------------------------------ | ------------------------------- |
| Number of users | A | Large number of users in large number of user locations/departments | Organigram<br />Permission List |
| Number of users | OS, DB, N, O | Number of users and user locations/departments is limited | Organigram<br />Permission List |
@ -48,7 +48,7 @@
### Assessment of Design Effectiveness
| No. | Question | Component | Situation | Evidence |
| No. | Question | Component | Situation | Evidences |
| ---- | ------------------------------------------------------------ | --------------- | ------------------------------------------------------------ | ------------------------------------------------------------ |
| 1 | User authentication is required | A, OS, DB, N, O | User-ID and password are assigned on an individual basis | Application login screen<br />OS login screen<br />DB login screen<br />Server login screen |
| 2 | User and access rights granted to each user are documented | A | A list of users is prepared with the rights granted to each user. This list is generated from the system | Application permission List |
@ -69,42 +69,42 @@
### Points to consider
| Question | Situation | Evidence |
| ------------------------------------- | ------------------------------------------------------------ | -------- |
| Frequency of problems/incidents | Material failure such as miscalculation or malfunction of the system has not occurred. | |
| Frequency of changes to job schedules | Changes to job schedules occur frequently but most of them are those in execution date | |
| Frequency of Non/Scheduled job | Non/Scheduled job is required in some cases but its frequency is low | |
| Question | Situation | Evidences |
| ------------------------------------- | ------------------------------------------------------------ | --------- |
| Frequency of problems/incidents | Material failure such as miscalculation or malfunction of the system has not occurred. | |
| Frequency of changes to job schedules | Changes to job schedules occur frequently but most of them are those in execution date | |
| Frequency of Non/Scheduled job | Non/Scheduled job is required in some cases but its frequency is low | |
### Assessment of Design Effectiveness
| No. | Question | Situation | Evidence |
| ---- | ------------------------------------------------------------ | ----------------------------------------------------------- | -------- |
| 1 | Policies and procedures for backups | Exists | |
| 2 | Completion of backup is ensured | All backup job records are reviewed by monitoring personnel | |
| 3 | Backup and recovery are periodically tested | Every backup is automatically tested | |
| 4 | Policies and procedures for job operation are described in a documentation | | |
| 5 | Job schedule changes are approved | | |
| 6 | Procedures are in place for preventing/detecting unauthorized changes to job schedules | | |
| 7 | Completion of job execution is ensured | | |
| 8 | Requests for non-scheduled job execution are authorized | | |
| 9 | Policies and procedures for identifying, resolving, reviewing, and analyzing IT operations problems or incidents are described in a documentation | | |
| 10 | IT operations problems or incidents are identified, resolved, reviewed, analyzed, and follow-ups are evidenced in a timely manner | | |
| No. | Question | Situation | Evidences |
| ---- | ------------------------------------------------------------ | ----------------------------------------------------------- | --------- |
| 1 | Policies and procedures for backups | Exists | |
| 2 | Completion of backup is ensured | All backup job records are reviewed by monitoring personnel | |
| 3 | Backup and recovery are periodically tested | Every backup is automatically tested | |
| 4 | Policies and procedures for job operation are described in a documentation | | |
| 5 | Job schedule changes are approved | | |
| 6 | Procedures are in place for preventing/detecting unauthorized changes to job schedules | | |
| 7 | Completion of job execution is ensured | | |
| 8 | Requests for non-scheduled job execution are authorized | | |
| 9 | Policies and procedures for identifying, resolving, reviewing, and analyzing IT operations problems or incidents are described in a documentation | | |
| 10 | IT operations problems or incidents are identified, resolved, reviewed, analyzed, and follow-ups are evidenced in a timely manner | | |
## Outsourcing Contract Management
### Points to consider
| Question | Situation | Evidence |
| Question | Situation | Evidences |
| ---------------------------- | ------------------------------------------------------------ | ------------------------- |
| What services are outsourced | Some of the services are outsourced concerning development/maintenance related to ITGCs | Software vendor contracts |
### Assessment of Design Effectiveness
| No. | Question | Situation | Evidence |
| ---- | ------------------------------------------------------------ | --------- | -------- |
| 1 | Outsourced service are clearly defined and agreed with the service vendor in writing e.g. in contract and/or SLA | | |
| 2 | Service vendor's compliance to the service level is periodically reviewed | | |
| 3 | Regular review of service vendors is conducted in terms of appropriateness of the services defined, service vendor's ability to render the required service level, etc. | | |
| No. | Question | Situation | Evidences |
| ---- | ------------------------------------------------------------ | --------- | --------- |
| 1 | Outsourced service are clearly defined and agreed with the service vendor in writing e.g. in contract and/or SLA | | |
| 2 | Service vendor's compliance to the service level is periodically reviewed | | |
| 3 | Regular review of service vendors is conducted in terms of appropriateness of the services defined, service vendor's ability to render the required service level, etc. | | |

12
Processes/COSO/Risk Management/Risk Management Review Template.md
View File

@ -32,9 +32,9 @@ For details see the [Risk Register](Risk%20Register.md) and the Risk Control Mat
### New risks
| Risk No. | R | Category | Risk Event | L | C | O | Cause | Mitigation Type | Mitigation Strategy | L* | C* | Changes | Comments | ES | EY |
| -------- | ---- | -------- | ---------- | ---- | ---- | ---- | ----- | --------------- | ------------------- | ---- | ---- | ------- | -------- | ---- | ---- |
| | | | | | | | | | | | | | | | |
| No. | R | Category | Risk Event | L | C | O | Cause | Mitigation Type | Mitigation Strategy | L* | C* | Changes | Comments | ES | EY | Evidences |
| ---- | ---- | -------- | ---------- | ---- | ---- | ---- | ----- | --------------- | ------------------- | ---- | ---- | ------- | -------- | ---- | ---- | --------- |
| | | | | | | | | | | | | | | | | |
Abbreviations:
@ -48,9 +48,9 @@ Abbreviations:
### Old risks (no longer applicable)
| Risk No. | R | Category | Risk Event | Reason for removal |
| -------- | ---- | -------- | ---------- | ------------------ |
| | | | | |
| No. | R | Category | Risk Event | Reason for removal |
| ---- | ---- | -------- | ---------- | ------------------ |
| | | | | |
Abbreviations:

2
Processes/COSO/Risk Management/Risk Management.md
View File

@ -94,7 +94,7 @@ While dealing with individual risks, decision makers should understand the overa
During analysis, each risk should be evaluated in terms of impact should the risk be fully realized. Risk consequence is measured as a deviation against historic company or business specific baselines.
| Level | Likelihood | Cost over Budget | Schedule | Performance |
| Level | Impact | Cost over Budget | Schedule | Performance |
| ----- | ------------------ | ---------------- | ------------------------------------------------------------ | ------------------------------------------------------------ |
| 5 | Critical Impact | > 10% | Schedule slip will require a major schedule rebaselining | Degradation precludes system from meeting a KPP or key technical/supportability threshold. Unable to meet mission objectives |
| 4 | Significant Impact | \> 5% ≤ 10% | Schedule slip puts funding at risk | Degradation impairs ability to meet a KSA. Technical design or supportability margin exhausted in key areas. Significant performance impact affecting System-of System interdependencies. Work-arounds required to meet mission objectives |

16
Processes/COSO/Risk Management/Risk Register.md
View File

@ -2,14 +2,14 @@
The risk register is a central repository to describe and track risks as well as record actions. It includes information for each risk such as risk category, likelihood, consequence, mitigation measures, risk owner and documentation of changes. Additional risks can be found in the corresponding **Risk Control Matrix** of every process.
| No. | R | Category | Risk Event | L | C | O | Cause | Mitigation Type | Mitigation Strategy | L* | C* | Changes | Comments | ES | EY |
| -------- | ---- | ---------------- | ------------------------------------------------------------ | ---- | ---- | ---- | ------------------------------------------------------------ | ---- | ---- | ------- | ------------------------------------------------------------ | ---- | ---- | ---- | ---- |
| 1 | DE | Operational Risk | Loss of source code | 1 | 5 | | | | Avoiding: Store source code in cloud (github). At least one local developer PC and project server. | | | | | yes | yes |
| 2 | DE | Operational Risk | Source code leak | 5 | 1 | | | | Controlling: The programming language is compiled at runtime. The value of the software lies in the updates, support and licenses. | | | | Many companies transferred the revenue model to subscriptions (e.g. Adobe, Microsoft) in order to avoid similar problems. | yes | yes |
| 3 | DE | Operational Risk | User acquires additional permissions without authorization (every software which uses permissions) | 2 | 5 | | | | Avoiding: Permissions can only be granted by users which have received the permissions to do so. Users which can change permissions may also only have the permission to change specific users/permissions (single application elements, not the whole application.). We provide a documentation on who to manage permissions incl. best practices. Customers with a maintenance contract also receive additional advice based on their account permission handling. We also check regularly if features can be used by default without the necessary permissions. | | | | The consequences or severities depend on the permissions which can be acquired. | yes | yes |
| 4 | DE | Operational Risk | User code execution (every software which allows data upload/input) | 3 | 5 | | | | Avoiding: User provided code is a critical part of some modules (e.g. Helper, Job). These modules provided by OMS execute code user code in iframes. We provide guidelines regarding this sensitive topic which explains that only developers in a company should have access to such functionalities. | | | | | yes | yes |
| 5 | DE | Operational Risk | Data leak (e.g. database data, file uploads) (every software which stores data) | 2 | 5 | | | | Avoiding: We regularly check if users have access to data without the necessary permissions. Our modules may use encryption for extremely sensitive data. Media files are only accessible through the media module which allows to check the necessary reading permissions. We also provide a general policy for customers who to secure and maintain their servers. | | | | This is a big problem for almost every company working with data. The biggest known leaks happened among others to Adobe, ebay, Equifax, LinkedIn, Yahoo, ... | yes | yes |
| 6 | DE | Operational Risk | Corrupt/malicious data injection (every software which accepts data input) | 3 | 3 | | | | Avoiding: Data is validated client side (minimal protection) and server side. Generally, user input is only accepted if it matches the specified allowed format. Data is usually not sanitized to avoid mistakes during the sanitizing process. Database query statements are prepared and encoded. | | | | | yes | yes |
| No. | R | Category | Risk Event | L | C | O | Cause | Mitigation Type | Mitigation Strategy | L* | C* | Changes | Comments | ES | EY | Evidences |
| -------- | ---- | ---------------- | ------------------------------------------------------------ | ---- | ---- | ---- | ------------------------------------------------------------ | ---- | ---- | ------- | ------------------------------------------------------------ | ---- | ---- | ---- | ---- | ---- |
| 1 | DE | Operational Risk | Loss of source code | 1 | 5 | | | | Avoiding: Store source code in cloud (github). At least one local developer PC and project server. | | | | | yes | yes | |
| 2 | DE | Operational Risk | Source code leak | 5 | 1 | | | | Controlling: The programming language is compiled at runtime. The value of the software lies in the updates, support and licenses. | | | | Many companies transferred the revenue model to subscriptions (e.g. Adobe, Microsoft) in order to avoid similar problems. | yes | yes | |
| 3 | DE | Operational Risk | User acquires additional permissions without authorization (every software which uses permissions) | 2 | 5 | | | | Avoiding: Permissions can only be granted by users which have received the permissions to do so. Users which can change permissions may also only have the permission to change specific users/permissions (single application elements, not the whole application.). We provide a documentation on who to manage permissions incl. best practices. Customers with a maintenance contract also receive additional advice based on their account permission handling. We also check regularly if features can be used by default without the necessary permissions. | | | | The consequences or severities depend on the permissions which can be acquired. | yes | yes | |
| 4 | DE | Operational Risk | User code execution (every software which allows data upload/input) | 3 | 5 | | | | Avoiding: User provided code is a critical part of some modules (e.g. Helper, Job). These modules provided by OMS execute code user code in iframes. We provide guidelines regarding this sensitive topic which explains that only developers in a company should have access to such functionalities. | | | | | yes | yes | |
| 5 | DE | Operational Risk | Data leak (e.g. database data, file uploads) (every software which stores data) | 2 | 5 | | | | Avoiding: We regularly check if users have access to data without the necessary permissions. Our modules may use encryption for extremely sensitive data. Media files are only accessible through the media module which allows to check the necessary reading permissions. We also provide a general policy for customers who to secure and maintain their servers. | | | | This is a big problem for almost every company working with data. The biggest known leaks happened among others to Adobe, ebay, Equifax, LinkedIn, Yahoo, ... | yes | yes | |
| 6 | DE | Operational Risk | Corrupt/malicious data injection (every software which accepts data input) | 3 | 3 | | | | Avoiding: Data is validated client side (minimal protection) and server side. Generally, user input is only accepted if it matches the specified allowed format. Data is usually not sanitized to avoid mistakes during the sanitizing process. Database query statements are prepared and encoded. | | | | | yes | yes | |
## Abbreviations

1
Processes/Finance/Budgeting/Budgeting Checklist.md
View File

@ -2,6 +2,7 @@
| Task | Responsible | Shared with | Signature | Date |
| ------------------------ | --------------------------------- | ------------------------------------------------------------ | --------- | ---- |
| Product budget | CTO | CEO + executive staff members + Head of Sales | | |
| Sales budget | Head of Sales | CEO + executive staff members + Head of Sales | | |
| Marketing budget | Head of Marketing + Head of Sales | CEO + executive staff members + Head of Marketing | | |
| HR budget | Head of HR | CEO + executive staff members + Head of HR + Head of Departments (headcount changes only) | | |

22
Processes/Finance/Financial Closing/Monthly Closing Checklist.md
View File

@ -1,10 +1,22 @@
# Monthly Closing Checklist
| Task | Responsible | Signature | Date |
| ----------------------------- | --------------- | --------- | ---- |
| Verify bank balance | Head of Finance | | |
| Book general invoice accruals | | | |
| Book wages | | | |
| Task | Responsible | Signature | Date |
| ------------------------------------------- | --------------- | --------- | ---- |
| Inform HOD about monthly closing | | | |
| Verify bank balance | Head of Finance | | |
| Book bad debt | | | |
| Book wages | | | |
| Book general invoice accruals and deferrals | | | |
| Book depreciations | | | |
| Create sales reporting | | | |
| Create income statement | | | |
| Create balance sheet | | | |
| Create investment report | | | |
| Create cash reporting | | | |
| Create HR reporting | | | |
| Create KPI reportings | | | |
| Verify reporting | | | |
| Submit reporting | | | |

7
Processes/Management/Department Minute Template.md
View File

@ -58,4 +58,9 @@ None
## Important upcoming events
None
None
2022-01-01 - Version 1.0

2
Processes/Management/Information Flow.md
View File

@ -8,7 +8,7 @@ flowchart TD;
EXECUTIVE_COMMITTEE<--Monthly: Head of Department Meeting-->HEAD_OF_DEPARTMENTS[Head of Departments]
HEAD_OF_DEPARTMENTS<--Monthly: Department Meetings-->EMPLOYEES[Employees / Teams]
MANAGEMENT--Annually: Company Meeting-->EMPLOYEES
EMPLOYEES-->WHISTLEBLOWER[Anonymous whistleblower System]
EMPLOYEES--For compliance violations-->WHISTLEBLOWER[Whistleblower System]
```

2
Processes/Organigram.md
View File

@ -70,7 +70,7 @@ flowchart TD;
| Ladder Officer | |
| Officer for Severely Disabled | |
| Internal Auditor | |
| Compliance Manager | |
| Compliance Officer | |
## Responsibilities