Accepting Processes
Purpose
The processes defined in the central process catalog do not automatically apply for all organizational units because each organizational unit can have a process flow that differs from that defined centrally. Furthermore, a process can have more significance for one organizational unit than for another. You decide which process is relevant for an organizational unit during the scoping of processes. The processes that fall within the project scope for an organizational unit must be taken over from the central process catalog by that organizational unit (with or without the corresponding process steps). Only then does the process become relevant for the organizational unit.
You can make other settings for the accepted processes; such process settings are then only valid for that organizational unit. Which particular settings can be changed depends on whether you have copied or referenced a process with its process steps, or accepted it without any process steps. If a process step is a control, you have to use attributes to document this control (see Documenting Controls)
You make the settings in the Web application Process and Account Groups of the Org Unit that you can access from the MIC start page. Different tasks are delivered for the various settings, thereby allowing the tasks to be performed by different persons (see Tasks: Structure Setup Specific to Organizational Units).
Prerequisites
● The organizational hierarchy and the central process catalog have been defined.
● The processes falling within the project scope have been specified.
● You have authorization for the relevant task.
● The tasks are scheduled (see Task Scheduling).
Process Flow
...
1. Display processes in the project scope
Establish which processes in the central process catalog fall within the project scope of your organizational unit so that you can adopt these processes.
2. Assign processes to the organizational unit
You can implement a central process as follows:
○ Without the central process steps
In this case, you have to create all process steps yourself as local process steps.
○ With a local copy of the central process steps
In this case, the process steps lose their reference to the central process catalog. You can adjust the steps flexibly to meet the requirements of the organization unit. You can also add additional local process steps.
Using a pushbutton, you can check whether any new process steps were created for a process in the central process catalog after the central process was transferred, and transfer any that were created.
○ With a reference to the central process steps
In this case, you copy the process steps of the central process unchanged. You cannot change the steps or define any additional steps locally. If changes are made to the steps in the central process catalog, they automatically become valid for the organizational unit as well.
The process groups to which a process belongs are also automatically copied when the process is adopted.
3. Assign a referenced control to the P-CO-R structure
On the Control - P-CO-R tab page, you can assign a risk mitigating control to a risk from the P-CO-R structure. Here, the controls from the other processes of the organizational unit are available so that you can reference them. If you are responsible for individual controls, these are also available.
4. Create local process steps
Besides copying steps from the central process catalog, you can also create process steps locally, which are then only valid for the organizational unit. If you reference the steps of a process, it is not possible to add additional local steps for this process.
5. Define process group attributes and process attributes specific to the organizational unit
You can overwrite the centrally defined attributes in Customizing for the validation of process or control assessments and remediation plans.
6. Document the copied controls and controls created locally
You do this in a different Web application. For more information, see Documenting Controls.