> ## Knowledge Base Index
> Fetch the complete knowledge base index at: https://docs.brainframe.com/sitemap.xml
> Use this file to discover available pages before exploring further.
> Pure-Markdown content can be obtained by appending a '.md' suffix to the content URLs listed in the sitemap (without the trailing slash).

# Asset Management

# 📦 **Asset Management in Brainframe**

> **"Know what matters to the business — and what supports it — so you can govern risk using data instead of ad-hoc."**
> *Brainframe helps CISOs and compliance teams build a risk-focused asset register: primary business assets at the centre, digital and physical supporting assets linked around them, all connected to risks and controls.*

Asset management in Brainframe is built for **governance, risk and compliance (GRC)** — not for IT service management (ITSM). You will not find ticket queues, CMDB serial-number tracking, or per-device lifecycle workflows here.

Instead, Brainframe answers a different question: **"If this were compromised or unavailable, would it hurt the organisation's ability to deliver its mission?"** That question drives everything — from how many records you create, to how you link dependencies, risks, and controls.

---

## 1️⃣ Why Asset Management Exists

Every serious security and compliance programme starts with knowing **what you need to protect**. ISO/IEC 27001:2022 places this front and centre:

| ISO 27001 theme | What Brainframe supports |
| ---- |
| **A.5.9 — Inventory of information and other associated assets** | Structured registers for core business, digital, and physical assets |
| **A.5.10 — Acceptable use of information and other associated assets** | Documented assets with owners, criticality, and descriptions |
| **A.5.11 — Return of assets** | Ownership metadata and governed records (not HR offboarding automation) |
| **A.5.12 — Classification of information** | Criticality and impact metadata on asset documents |
| **A.8 — Technological controls** | Linking assets to controls and risks that protect them |
| **Clause 6.1.2 — Risk assessment** | Maximum impact configuration on assets, feeding risk readings |

Brainframe is designed so asset data **feeds risk assessments and control evidence** — not so it replaces your endpoint management or procurement systems.

> 💡 **Think GRC asset register, not ITSM CMDB.** Operational tools tell you *how many* devices you have. Brainframe tells you *which assets matter for compliance* and *what happens if they fail*.

---

## 2️⃣ Primary Assets vs Supporting Assets

The most important concept in Brainframe asset management is the **two-layer model**:

### 🏛 Primary (core business) assets

These are what the organisation **delivers, performs, or fundamentally depends on** as part of its business mission:

* Customer-facing **services** (e.g. online booking portal, payment processing)
* End-to-end **business processes** (e.g. payroll run, clinical patient intake)
* Critical **information or datasets** where the data itself is the value (e.g. customer PII register, trade-secret formula)
* Core **business capabilities** (e.g. same-day delivery promise, 24/7 helpdesk)

If a primary asset were unavailable or compromised, the organisation's ability to **deliver products or services would be directly affected**.

**Where to manage them:** **Resources → Core business assets**

---

### 🔧 Supporting assets (digital & physical)

These **enable** primary assets but are not the business outcome themselves:

| Category | Examples |
| ---- |
| **Digital assets** | Applications, databases, cloud platforms, APIs, SaaS tools, virtual servers |
| **Physical assets** | Data centres, office buildings, production lines, network equipment, **classes** of end-user devices |

**Where to manage them:**

* **Resources → Their dedicated document type (e.g Software, Data, Hardware, Employee,...)**

---

### 📌 The "100 identical laptops" principle

Brainframe deliberately avoids ITSM-style **one-record-per-device** tracking.

If your organisation has **100 identical corporate laptops** running the same standard image, you typically represent them as **one asset** in Brainframe — for example *"Corporate Windows laptop (standard build)"* — not 100 separate records.

| ITSM approach | Brainframe GRC approach |
| ---- |
| 100 laptop records with serial numbers | 1 laptop **class** asset representing the fleet |
| Track every patch per device | Track **risk and non-compliance** for that asset type |
| Focus on operational state | Focus on **impact if the asset class fails** |

You link that single laptop-class asset to the **primary business processes** it supports, assign an **owner**, set **criticality**, connect **controls** (encryption, MDM, patching policy), and attach **risks** (theft, malware, data leakage). When a specific incident involves one machine, you document it in your **incident** or **risk** records — not by duplicating the asset register.

The same logic applies to cloud VMs, database clusters, and standard SaaS subscriptions: model the **governed asset**, not every instance.

|| ⚠️ Decision rule: Ask "Does the organisation deliver or perform this, or does it merely enable something else?" If it enables another asset, it is a supporting asset.

---

## 3️⃣ The Resources Module — Three Asset Registers

Open the left sidebar → **Resources**. The asset registers most teams use are:

| Menu item | Purpose |
| ---- |
| **Core business assets** | Primary services, processes, information, and business capabilities |
| **Digital assets** | Applications, systems, data platforms, and technology that supports the business |
| **Physical assets** | Facilities, hardware classes, and tangible infrastructure |
| **All resources** | Cross-register view of configured resource document types |
| **Dependencies** | Helicopter-view graph of relationships across selected document types (see [Section 8](#8️⃣-resources--dependencies--the-helicopter-view)) |

Each register opens as a **table view** — a filterable list of asset documents with columns for metadata, status, and governance fields.

---

## 4️⃣ Creating and Documenting Assets

### ✨ Create new (with template)

The standard way to add an asset:

1. Open the relevant register (**Core business**, **Digital**, or **Physical** assets).
2. Click **Create new** in the table header.
3. Choose the document type.
4. Complete the **template** — Brainframe document types for assets ship with structured sections to fully describe the asset (purpose, scope, dependencies, ownership, etc.).

Templates give consistency across the organisation: every "Application" or "Core business service" follows the same documentation pattern — important for audits and handovers.

### 🤖 AI-assisted wizards

Two guided workflows accelerate onboarding:

#### **Identify and document primary assets** (Core business register only)

Launched from:

* The **✨** button next to **Create new** on the **Core business assets** table, or
* **My Compliance** → wizard card *"Identify and document primary assets"*

The wizard:

1. Collects **company context** (once per workspace, if not already set).
2. Shows **existing** core business assets so you do not duplicate work.
3. Lets you **add assets manually** or use **AI discovery** to propose services, processes, information sets, and business capabilities.
4. Creates each selected asset as a governed document with **AI-filled template content** (when Confidential AI is enabled).

#### **Create asset wizard** (Digital & Physical registers)

Launched from the **✨** button next to **Create new** on digital or physical asset table views.

A five-step guided flow:

1. **Asset details** — Name, type, description (AI-assisted), metadata (owner, criticality, etc.), optional **supporting asset links**, and **maximum impact** grid
2. **Existing controls** — Link controls from search, bundles, or framework requirements; set implementation levels
3. **Risk assessment** — Identify risks from the workspace, risk register, or with AI
4. **Mitigation plan** — Missing controls and optional linked mitigation plan document
5. **Summary** — Review everything before the asset is created with all links persisted

> 📌 Wizards are optional. **Create new** with the standard template is always available for teams that prefer manual documentation.

---

## 5️⃣ Metadata — Owner, Criticality, and Filtering

Asset document types can be configured with **metadata properties** (document tags) such as:

| Typical property | Why it matters |
| ---- |
| **Owner** | Accountability for the asset — required for ISO asset inventory |
| **Criticality** | Quick triage: High / Medium / Low (or your workspace scale) |
| **Business unit** | Scope filtering for decentralised organisations |
| **Location / region** | Physical and data-residency context |
| **Classification** | Information sensitivity where relevant |

These properties appear as **columns and filters** in the table view. Compliance teams use them to answer questions like:

* *"Show me all High-criticality digital assets without an owner."*
* *"Which physical assets in Region X support our payment service?"*

Workspace administrators configure which properties are **mandatory and optional** per document type under **Workspace Settings → Document types**.

---

## 6️⃣ Governance Type: "This is an Asset"

Asset document types are configured with governance classification **"This is an asset"** (as opposed to "This is a control" or "This is a risk").

This expands the **Governance** tab on each asset document — your single place to manage how the asset participates in risk and compliance:

### What you configure on the Governance tab

| Area | Description |
| ---- |
| **Risk type** | Select the risk methodology (matrix) that applies to this asset |
| **Linked risks** | Risk documents that apply to this asset — threats, scenarios, compliance gaps |
| **Linked controls** | Control documents that protect this asset — with implementation status |
| **Maximum impact (Max impacts)** | Consequence grid: for each impact dimension (financial, reputational, operational, legal, etc.), set the **worst credible outcome** if this asset is compromised or unavailable |
| **Mitigation overview** | Visual summary of how well linked controls cover linked risks |
| **AI identify** | Suggest additional controls, risks, or related assets (when AI is enabled) |

### How max impact feeds risk management

Maximum impact values set an **upper bound** on consequence when assessing risks linked to this asset. Risk readings that use **asset & control** methodology can reference these configured impacts rather than guessing severity from scratch.

For auditors, the Governance tab is evidence that:

1. The asset has been **assessed for consequence**
2. **Controls** are explicitly mapped
3. **Risks** are tied to the asset, not floating in a generic register

> 💡 On **risk** and **control** documents, the Governance tab works in reverse: risks link to affected assets; controls link to assets they protect. The asset remains the anchor.

---

## 7️⃣ Dependencies — Linking Primary and Supporting Assets

Dependencies express **"this supports that"** relationships between documents.

### On a single asset document

Open any asset → **Dependencies** panel (or accordion):

| Section | Meaning |
| ---- |
| **Parent documents** | What this asset **depends on** (supports it from above — e.g. a digital application whose parent is a core business service) |
| **Child documents** | What **depends on** this asset (supported below — e.g. a database child of an application) |

Use **Add Parent** or **Add Child** to link existing documents, or **Create new** from the link dialog to add a missing record on the fly.

**Show dependencies in graph diagram** opens an interactive graph centred on the current document — ideal for explaining a service's technology stack to auditors or management.

---

### Table view — Dependencies tab

From any asset register table, switch the view mode from **List** to **Dependencies**:

* See a **tree** of each asset and its linked children, indented by level
* **Expand** branches to explore multi-level chains (primary → application → database → hosting)
* **Add link** (+) on a row to attach a child dependency without leaving the table
* Click a row to open the asset document; return navigation preserves your place in the tree

When primary and supporting assets are linked correctly, you can immediately see **which asset is parent and which is child** — for example:

```
Customer Portal (core business)
  └── Payment API (digital)
        └── Azure SQL production DB (digital)
              └── EU West data centre (physical)
```

---

### Table view — Graph tab

Switch to **Graph** for a **collection-style network diagram** of documents in the current table scope. Useful for workshops and management presentations where a visual map communicates faster than a list.

Layout controls (**Auto layout**, **Random layout**) help organise dense graphs.

---

## 8️⃣ Resources → Dependencies — The Helicopter View

**Resources → Dependencies** is a dedicated module for **cross-cutting relationship maps** — a "helicopter view" above individual registers.

### What it does

* Displays a **full graph** of linked documents for a **visual collection** you configure
* Shows how core business, digital, and physical assets (and other types you include) **connect across the organisation**
* Supports **Include Subfolders** to widen or narrow scope
* Lets you **drag nodes** to arrange the layout and **export the graph as an image** for reports
* Provides **Auto** and **Random layout** buttons for quick reorganisation

### Visual collections

A visual collection defines **which document types** appear in the helicopter graph — for example:

* Core business service + Application + Database + Physical facility
* Or only digital asset types for a technology architecture review

Create collections from the Dependencies toolbar (**Add collection**). Pick document types individually or **quickly add all from a group** (e.g. all digital asset types). Collections are saved as workspace documents you can reopen and share.

### Typical use cases

| Audience | Use |
| ---- |
| **CISO** | Board slide: primary services and their technology dependencies |
| **Compliance manager** | ISO audit walkthrough: trace from business process to supporting systems |
| **Risk workshop** | Identify single points of failure in a dependency chain |
| **BCM / resilience** | Map which physical assets underpin critical digital services |

> 📌 Configure collections to include **Core business**, **Digital**, and **Physical** asset types together to see the complete primary → supporting chain in one diagram.

---

## 9️⃣ ISO 27001 Best Practices in Brainframe

### Start with primary assets (top-down)

1. Run **Identify and document primary assets** or workshop your core services manually.
2. Limit the list to what truly affects **customer delivery or business mission** — usually tens of records, not thousands.
3. Assign **owners** and **criticality** before diving into technology.

### Add supporting assets (bottom-up validation)

1. For each primary asset, ask: *"What systems, data stores, and facilities must work for this?"*
2. Create **one governed record per asset class** (not per instance).
3. Link children under parents in the **Dependencies** panel or table **Dependencies** tab.

### Connect governance (risks + controls)

1. On each asset's **Governance** tab, set **max impacts** using your risk type's consequence dimensions.
2. Link **controls** that are actually implemented (with implementation level).
3. Link or create **risks** that reflect credible threats to that asset.
4. Use the **asset wizard** for new digital/physical assets when you want AI help identifying gaps.

### Keep the register lean (audit-friendly)

| Do | Avoid |
| ---- |
| One record per **asset class** or **governed system** | One record per laptop, VM, or user account |
| Link to **integrations** (Entra, Defender, Aikido) for live technical context | Duplicating CMDB data that goes stale |
| Use **Dependencies** and **Helicopter view** for relationship evidence | Flat spreadsheets disconnected from risks |
| Review **High criticality** assets quarterly | Boiling the ocean on Low-impact records |

### Evidence for certification audits

Auditors commonly ask:

* *"Show your information asset inventory."* → **Resources** registers with owners and criticality filters
* *"How do you know what depends on what?"* → **Dependencies** tree or **Helicopter view** export
* *"How is impact determined?"* → **Governance** tab **Max impacts** on primary assets
* *"Which controls protect this system?"* → **Governance** tab linked controls with implementation status

---

## 🔟 Day-to-Day Workflows

### CISO / security lead

| Task | Where |
| ---- |
| Review critical asset coverage | **Core business assets** table → filter Criticality = High |
| Check dependency chains for crown jewels | **Dependencies** tab or **Helicopter view** |
| Validate controls on key systems | Open asset → **Governance** tab |
| Import endpoint context | **Add from integrations** (e.g. Microsoft Defender devices as workstation-class assets) |

### Compliance / GRC manager

| Task | Where |
| ---- |
| Build ISO asset inventory | **Resources** registers + mandatory Owner/Criticality metadata |
| Map Annex A controls to assets | **Governance** tab → link controls |
| Prepare audit evidence pack | Export helicopter graph + governance screenshots |
| Onboard new business service | **Create new** or **Identify primary assets** wizard |

### Risk owner

| Task | Where |
| ---- |
| Understand what a risk affects | Risk document → **Governance** → linked assets |
| Set consequence bounds | Asset → **Governance** → **Max impacts** |
| See supporting technology | Asset → **Dependencies** → expand children |

---

For AI-assisted onboarding, see the [Confidential AI](https://docs.brainframe.com/en/article/confidential-ai-in-brainframe-1hbq43b/) **in Brainframe** guide. For bringing endpoint data into supporting assets, see the **Microsoft Defender** and **Microsoft Entra ID** integration guides.