Warning: The magic method FotonCore\CPT\PostTypesRegister::__wakeup() must have public visibility in /home/users/7dots/public_html/flowaysystem.com/wp-content/plugins/foton-core/post-types/post-types-register.php on line 30

Warning: The magic method FotonInstagramApi::__wakeup() must have public visibility in /home/users/7dots/public_html/flowaysystem.com/wp-content/plugins/foton-instagram-feed/lib/foton-instagram-api.php on line 71

Warning: The magic method FotonTwitterApi::__wakeup() must have public visibility in /home/users/7dots/public_html/flowaysystem.com/wp-content/plugins/foton-twitter-feed/lib/foton-twitter-api.php on line 95

Warning: The magic method FotonMikadoNamespace\Modules\Header\Lib\HeaderFactory::__wakeup() must have public visibility in /home/users/7dots/public_html/flowaysystem.com/wp-content/themes/foton/framework/modules/header/lib/header-factory.php on line 39

Warning: The magic method FotonCore\Lib\ShortcodeLoader::__wakeup() must have public visibility in /home/users/7dots/public_html/flowaysystem.com/wp-content/plugins/foton-core/lib/shortcode-loader.php on line 28

Warning: The magic method FotonInstagram\Lib\ShortcodeLoader::__wakeup() must have public visibility in /home/users/7dots/public_html/flowaysystem.com/wp-content/plugins/foton-instagram-feed/lib/shortcode-loader.php on line 28

Warning: The magic method FotonTwitter\Lib\ShortcodeLoader::__wakeup() must have public visibility in /home/users/7dots/public_html/flowaysystem.com/wp-content/plugins/foton-twitter-feed/lib/shortcode-loader.php on line 28
Security - Floway

Security workflow

Security workflow solutions from Floway enable improving your company’s safety with minimal effort. Discover our ready-to-use security workflow templates and let it flow!

Floway workflow - Security software

Security incident report

Category

 Security

Area

Company’s organisation

Innovation

Drive Process

Final states

  • Case Closed
  • Rejected (Security Department)
  • Rejected (Manager)

Assumptions

  • Security Incident impact on the company may vary depending on the scale of the incident.
  • Problem typically has not been foreseen and has to be solved quickly. Actions are concentrated on containing the incident not to improve the company’s business.

Description: Incident report template is similar in structure to the vulnerability report. The main difference is that actions are taken after something happened not as prevention measures. An employee who noticed the incident starts the process describes the case and should suggest a solution to the problem. Actions taken so far should be described clearly – the incident may need performing immediate actions before the report is entered to the system. The data entered is sent to the Manager responsible for solving the problem. In some rare cases Manager may reject the report (only if incident is not really an incident). Later the report is sent to the Security Department. Security Department prepares action plan on how to deal with the issue and decides if it is necessary to consult the plan with the Management Board. Depending on the decision taken, Management Board may comment the plan and approve the realisation. In the template Management Board has a consulting role in the process. The Security Department is responsible for realisation of the action plan approved by Management Board. Process ends when the action plan is realised. Please note that the process purpose is to contain the incident, not to enhance the organisation – other processes (e.g., KAIZEN) should be started to boost the change.

Roles engaged: Manager, Security Department, Management Board.

Common adjustments (configuration):

  • Companies having distinct IT and non-IT Security Departments / Teams can split this role into two different ones. Template may be duplicated and differentiated for this purpose.
  • Management Board might be more engaged in the process in some companies and take active role in the planning not only consulting. The possibility of the rejection of the action plan and effectively stopping the process may be added for Management Board, also some other transitions may be added.

Request for access

Category

Security

Area

Current issues

Innovation

Get task done

Final states

  • Access Granted
  • Rejected (Manager)
  • Rejected (Security Department)

Assumptions

  • The same template covers both the request for physical access (to the room/ building) and access to the IT resources.
  • The access level must be strictly defined so that no access above required by tasks performed by the employee is given.

Description: An employee fills the request form containing fields that strictly describe the permissions needed. These permissions should be minimal for getting employees’ work done. This will prevent unwanted GDPR or other data access problems. The primary decision, if the request is valid, is taken by the Manager (indicated by the employee). The Security Department should double-check the decision and if everything is legitimate access should be given. Please note that, after the access is given, monitoring should be performed on regular basis, and it is outside the scope of this process.

Roles engaged: Manager, Security Department.

Common adjustments (configuration):

  • Some companies require more acceptance steps (for example from the System Administrator or some other department) – the process can be configured with additional paths.
  • Request for permissions verification can be added as a separate process or managed with a revoked access process.

Vulnerability report

Category

Security

Area

Company’s organization

Innovation

Boost change

Final states

  • Vulnerability removed
  • Rejected (Security Department)
  • Rejected (Manager)

Assumptions

  • Employees often notice vulnerabilities much earlier than the company’s management.
  • Elimination of the vulnerability may trigger a change in the company’s activities.
  • Slight changes summed up boost the company’s effectiveness.

Description: An employee fills the request form containing fields that strictly describe the permissions needed. These permissions should be minimal for getting employees’ work done. This will prevent unwanted GDPR or other data access problems. The primary decision, if the request is valid, is taken by the Manager (indicated by the employee). The Security Department should double-check the decision and if everything is legitimate access should be given. Please note that, after the access is given, monitoring should be performed on regular basis, and it is outside the scope of this process.

Roles engaged: Manager, Security Department.

Common adjustments (configuration):

  • Some companies require more acceptance steps (for example from the System Administrator or some other department) – the process can be configured with additional paths.
  • Request for permissions verification can be added as a separate process or managed with a revoked access process.

Security workflow solutions -
Free Demo

Try our 30-day Free Demo and experience for yourself how easy security management is with Floway.