> ## Documentation Index
> Fetch the complete documentation index at: https://www.docusnap.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Justifying Why a Server Is Critical

> Create department, person, application, process and business service, connect them to the technology and derive the protection need from that.

We build the chain that gives a system its significance: from the department
through process and business service to the server. At the end the protection
need of the server is derived from this chain, and traceable.

**Prerequisite:** an inventoried estate.

## Starting point

Docusnap Sports GmbH runs its merchandise management on an SAP system. The scan
has captured operating system, services and hardware. What consequences an
outage has for the business does not stand in the scan. We map that now.

## 1. Create the organization

Four types describe the organization. No scan creates them:

| Type | Meaning |
| - | - |
| *Business Service* | a service the company delivers or consumes |
| *Process* | a business workflow that depends on IT |
| *Department* | an organizational unit |
| *Person* | an employee, regardless of a sign-in account |

All four carry only a name. We create them through *Asset* in the lists under
*Organization*: the department *Sales* and the people in that department.

<Note>
  The dialog's type selection is restricted to the types of the opened list. If
  the type is missing, the list is the wrong one.
</Note>

<Tip>
  We create several people or departments at once: set the switch to *Multiple*,
  paste the name column from a table. See
  [Taking Over an Existing Inventory List](/docs/en/assets/tutorial-import).
</Tip>

## 2. Create application and information

The scan captures installations, not applications. That a database, an
application server and a web front end together make up the merchandise
management is something we establish with two further types:

| Type | Meaning |
| - | - |
| *Application* | an application used for business purposes, regardless of the systems it runs on |
| *Information* | a data holding worth protecting |

We create the application *Merchandise Management* and the information *Customer
Data*.

## 3. Create process and business service

<Steps>
  <Step title="Name the business service">
    The service the company delivers: *Order Processing*.
  </Step>

  <Step title="Name the process">
    The business workflow beneath it: *Order Entry*. Keeping process and
    business service apart makes sense once several processes carry the same
    service.
  </Step>
</Steps>

## 4. Set relations

The types get their meaning through [relations](/docs/en/assets/relations). We open
*Order Entry* and its *Beziehungen* tab.

<Steps>
  <Step title="Add a relation">
    Above the *Defined Relations* zone we open the *Add Relation* dialog.
  </Step>

  <Step title="Target first, then type">
    We choose the business service *Order Processing* as the *Target Object*,
    then the *Relation Type*. If the field reads *Determined automatically*, a
    rule from *Data Model* applies; we choose nothing.
  </Step>

  <Step title="Mark the critical connection">
    We connect *Order Entry* to the application *Merchandise Management*, and
    that to the SAP system. On the connection to the SAP system we set
    *Critical* and write into the description why.
  </Step>

  <Step title="Connect the department">
    We connect the department *Sales* to the process.
  </Step>
</Steps>

<Note>
  A relation type carries a label per direction. From the server the relation
  reads "trägt", from the process "läuft auf". The arrow in the dialog shows the
  direction.
</Note>

## 5. Set the protection need

We open the SAP system and its *ISMS* tab. For each security objective —
*Confidentiality*, *Integrity*, *Availability* — we choose *Normal*, *High* or
*Very High*. *Total Protection Need* results from the highest value. Details:
[Determining Protection Needs](/docs/en/isms/protection-needs).

We set *Availability* to *Very High*. The justification stands in the relations:
the server carries the merchandise management, that carries the order entry,
that carries the order processing.

<Tip>
  Through the same relations you rate the server's *Criticality* in ITAM, and a
  risk in the ISMS points to the affected assets.
</Tip>

## Next steps

How a risk reaches these assets: [Assessing Risks](/docs/en/isms/assess-risks). What
the ITAM side makes of the rating:
[Recording ITAM Data](/docs/en/itam/manage-data).

Labels without an English interface value, kept in German: *Beziehungen* (the
relations tab on an asset), *trägt* and *läuft auf* (the two directional labels
of a relation type).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.