4. Document the system

The Context tab holds the system's identity and business context:

• System Name and System Description: what the system is and what it is for. The description supports rich text.
• Country and Region: where the system operates.
• Functional Domain: the business function it supports (for example HR, IT, Finance).
• Business Unit: the unit or units it belongs to.
• Criticality: Critical, Non-Critical or NA.
• Environment Stage: for example Production or Non-Production.
• Operational Status: for example Operational, Under Development, Major Modification or Decommissioned.

The Architecture tab captures the technical shape of the system:

• Internet Facing: whether the system is reachable from the internet.
• Architectural Domain: for example Applications, Platforms, Infrastructures or Data.
• System Domain and System Type: classify the system's role within your environment (server, network, user device, application and so on).
• System Accessibility: whether the system is external, internal or isolated.
• System Management: whether it is managed within the organisation or by an external provider.
• System Hosting: the hosting arrangement, from internal hosting to external shared or dedicated environments.
• Cloud Type: IaaS, PaaS or SaaS where applicable.
• Cloud Stack Components: the cloud layers involved (for example network, compute, storage, application, data).

This tab describes the data the system processes:

• CIA Levels of Processed Data: a table with one row per information type the system processes (for example customer personal data). For each row you select a Confidentiality, Integrity and Availability level from your workspace's CIA Levels catalogue. The table then computes the Security Objectives (the highest level selected in each column) and the Overall System Security Categorization (the highest of the three objectives).
• Data Classification: the sensitivity of the data (for example Public, Internal, Confidential).
• PII and PHI: switches indicating whether the system processes Personally Identifiable Information or Protected Health Information.

Define the recovery objectives that support business continuity:

• Recovery Time Objective (RTO): the maximum acceptable downtime.
• Recovery Point Objective (RPO): the maximum acceptable data loss period.

Free text for anything that improves the understanding of the system's context: scope, interfaces, operational considerations, dependencies or specific configurations.

Tip: use this section to define the system's boundaries. Specify what is in scope and out of scope, highlight interfaces with external systems, and clarify who is responsible for each area, including responsibilities shared with external parties.

The rest of the documentation lives in the header actions of the details panel:

• Owners & Contacts: assign the workspace members accountable for the system, so ownership is explicit and reviewable.
• Evidence: attach supporting files or links. If your workspace restricts evidence storage (Settings, Evidences), the drawer accepts links only.
• Comments: keep the discussion about the system next to the record.
• Risk assessments: click the assessment badge in the header to link the system to completed risk assessment demands (searched by their RAD reference) and to set the review periodicity. When a new assessment is linked, the earlier one moves to Previous Assessments for historical tracking.
• Share Forms: collect information about the system through forms and track the responses.

Edits made in the tabs are committed together through the save bar at the bottom of the page.